Discussion:
DFS, FRS, roaming profiles and redirected folders
(too old to reply)
colorado99
2006-03-27 05:26:02 UTC
Permalink
I've been using DFS and FRS to replicate roaming profiles and redirected
folders between our branch offices (8). Each branch has a DC and is properly
configured in DNS and Sites. This all worked until recently when one or two
replicas would spew 13508 and 13506 errors until I ran a D2 restore.

All would be fine for a few days and then it would start again. The 13506
assertion message complains about a failed consistency check
(!IS_GUID_ZERO(ChangeOrder->pParentGuid)) in ChrgOrderAccept at line 2373.
The error has appeared on several, but not all replicas.

Replication is set to run during our non-production hours (overnight) and
has plenty of time to complete. We are below all the stated limits of
DFS/FRS, although I am aware that replicating roaming profiles and redirected
folders is not supported as we have it configured.

Sysvol/AD replication is working fine (and has always worked). I have
tested by placing a text file in each of the DCs sysvol and it does appear in
the other DCs folders during the next window. Sonar tells me that everything
is fine with the exception that ntfrs is usually failed on the problem
machine(s).

Repadmin, dcdiag, netdiag, and dns troubleshooting tools all indicate no
problems, except of course ntfrs is not running on the current problem
machine.

Restarting ntfrs manually doesn't help either. The service manager is
restarting at regular intervals too. Ntfrs will run for less than one minute
before failing on assertion.

I've looked through the ntfrs_nnnn.log debug files and am simply overwhelmed
by the volume of information (a tool to parse this would be handy). Using
grep to search for error|access|fail doesn't produce any clues to the problem.

Finally, even with the failures; most of the content would replicate
successfully. However, *most* of the data being replicated is not good
enough.

I've disabled replication this weekend and hacked together a robocopy script
to keep things moving between targets until I can figure this out.

Anyone have any pointers, tips, or suggestions on getting this solved?
Didier GAUTIER [MSFT]
2006-03-27 16:19:10 UTC
Permalink
Hi,



NTFRS assigns a GUID to each file and folder located on a replicated folder.
When a change occurs, it created a change order reflecting the change. This
change order contains the GUID of the element that has been modified as well
as the GUID of the directory it is located in (called parent GUID). In your
case, NTFRS is getting a change order sent by a replication with an invalid
parent GUID value.



In order to identify the culprit element, search the NTFRS log files
(ntfrs_000x.log in %windir%\debug ) for the error "IS_GUID_ZERO" (you can
use findstr). Then look a few lines before the entries for the following
lines:



4/14-20:38:37 :T: CoG: d4ac3a08 CxtG: 106e6423 [RemCo ] Name: MyFile.txt

...4/14-20:38:37 :T: FileG: 11eaef2b-cbd4-4cf7-bc1ac2f678bf0e6d FID:
01c5412e 1fe6bf14.

4/14-20:38:37 :T: ParentG: 48c677ec-a117-48c9-aa0a89cbcbbbc238 Size:
00000000

The first will tell you the name of the item (MyFile.txt in the example),
the second will tell you it's GUID and the 3rd, the parent GUID of the item.

Then, run ntfrsutl idtable > id.txt on the replication partner and edit
id.txt. Search for the parent guid and look at the corresponding "FileName="
entry to get the name of the directory. You can then launch the explorer on
both the local server and it's replication partner and go to this directory
to figure out what's wrong.
--
Thanks,

Didier GAUTIER
Microsoft European Global Technical Support Center
This posting is provided "AS IS" with no warranties, and confers no rights.
Post by colorado99
I've been using DFS and FRS to replicate roaming profiles and redirected
folders between our branch offices (8). Each branch has a DC and is properly
configured in DNS and Sites. This all worked until recently when one or two
replicas would spew 13508 and 13506 errors until I ran a D2 restore.
All would be fine for a few days and then it would start again. The 13506
assertion message complains about a failed consistency check
(!IS_GUID_ZERO(ChangeOrder->pParentGuid)) in ChrgOrderAccept at line 2373.
The error has appeared on several, but not all replicas.
Replication is set to run during our non-production hours (overnight) and
has plenty of time to complete. We are below all the stated limits of
DFS/FRS, although I am aware that replicating roaming profiles and redirected
folders is not supported as we have it configured.
Sysvol/AD replication is working fine (and has always worked). I have
tested by placing a text file in each of the DCs sysvol and it does appear in
the other DCs folders during the next window. Sonar tells me that everything
is fine with the exception that ntfrs is usually failed on the problem
machine(s).
Repadmin, dcdiag, netdiag, and dns troubleshooting tools all indicate no
problems, except of course ntfrs is not running on the current problem
machine.
Restarting ntfrs manually doesn't help either. The service manager is
restarting at regular intervals too. Ntfrs will run for less than one minute
before failing on assertion.
I've looked through the ntfrs_nnnn.log debug files and am simply overwhelmed
by the volume of information (a tool to parse this would be handy). Using
grep to search for error|access|fail doesn't produce any clues to the problem.
Finally, even with the failures; most of the content would replicate
successfully. However, *most* of the data being replicated is not good
enough.
I've disabled replication this weekend and hacked together a robocopy script
to keep things moving between targets until I can figure this out.
Anyone have any pointers, tips, or suggestions on getting this solved?
colorado99
2006-03-28 04:33:01 UTC
Permalink
It appears what has happened is the folder that contained the changed object
(parentGuid) is missing. This kills the ntfrs service and it is unable to
recover since it can't resolve the parentGuid object. I'm basing this
analysis on the first instance of the error I found. I will look at other
instances of the error and see if the cause appears to be the same.

This seems like something that should be routinely handled by multi-master
replication. Objects and their parents may be changed (one or more times)
and then deleted, moved or renamed prior to the next replication window. I
thought this scenario would be handled more gracefully.

I'll post again with further analysis.
Oscar J. Piñón
2006-04-07 19:56:37 UTC
Permalink
Hello,

I am configuring the exact same scenario as described here: Roming profiles
and redirected folders. It caught my attention your statement: "I am aware
that replicating roaming profiles and redirected folders is not supported".

Could somebody please provide me with more info as to why this is not
possible (or recommended)?

Thank you,
Oscar Piñón
Post by colorado99
I've been using DFS and FRS to replicate roaming profiles and redirected
folders between our branch offices (8). Each branch has a DC and is properly
configured in DNS and Sites. This all worked until recently when one or two
replicas would spew 13508 and 13506 errors until I ran a D2 restore.
All would be fine for a few days and then it would start again. The 13506
assertion message complains about a failed consistency check
(!IS_GUID_ZERO(ChangeOrder->pParentGuid)) in ChrgOrderAccept at line 2373.
The error has appeared on several, but not all replicas.
Replication is set to run during our non-production hours (overnight) and
has plenty of time to complete. We are below all the stated limits of
DFS/FRS, although I am aware that replicating roaming profiles and redirected
folders is not supported as we have it configured.
Sysvol/AD replication is working fine (and has always worked). I have
tested by placing a text file in each of the DCs sysvol and it does appear in
the other DCs folders during the next window. Sonar tells me that everything
is fine with the exception that ntfrs is usually failed on the problem
machine(s).
Repadmin, dcdiag, netdiag, and dns troubleshooting tools all indicate no
problems, except of course ntfrs is not running on the current problem
machine.
Restarting ntfrs manually doesn't help either. The service manager is
restarting at regular intervals too. Ntfrs will run for less than one minute
before failing on assertion.
I've looked through the ntfrs_nnnn.log debug files and am simply overwhelmed
by the volume of information (a tool to parse this would be handy). Using
grep to search for error|access|fail doesn't produce any clues to the problem.
Finally, even with the failures; most of the content would replicate
successfully. However, *most* of the data being replicated is not good
enough.
I've disabled replication this weekend and hacked together a robocopy script
to keep things moving between targets until I can figure this out.
Anyone have any pointers, tips, or suggestions on getting this solved?
Ned Pyle (MSFT)
2006-04-07 23:50:55 UTC
Permalink
Certainly possible. PSS does not consider replicating profiles and
redirected folders to be truly unsupported - however, it's not recommended
and there are lot of things we simply cannot fix about it when customers
call in, because they are contrary to the concept of last writer wins, which
is what replication is built on. The biggest issue being that: last writer
wins, a user that can be logged in at multiple places at once, and a user
can have multiple files locked with FRS simultaneously on different DFS
targets that will not reconcile properly or predictably to the end user (i.e
they may start seeing 'old files' reappear that they swear they edited much
later).

DFSR(eplication) in Windows Serevr 2003 mitigates this to a great extend, as
you have much faster and more efficient replication now, and the fact that
the ConflictedAndDeleted folder can store conflicted files as replication
converges, but it's still not perfect.

But to reiterate - no, this is not unsupported. Just not recommended.

Ned
Post by Oscar J. Piñón
Hello,
I am configuring the exact same scenario as described here: Roming
"I am aware that replicating roaming profiles and redirected folders is
not supported".
Could somebody please provide me with more info as to why this is not
possible (or recommended)?
Thank you,
Oscar Piñón
Post by colorado99
I've been using DFS and FRS to replicate roaming profiles and redirected
folders between our branch offices (8). Each branch has a DC and is properly
configured in DNS and Sites. This all worked until recently when one or two
replicas would spew 13508 and 13506 errors until I ran a D2 restore.
All would be fine for a few days and then it would start again. The 13506
assertion message complains about a failed consistency check
(!IS_GUID_ZERO(ChangeOrder->pParentGuid)) in ChrgOrderAccept at line 2373.
The error has appeared on several, but not all replicas.
Replication is set to run during our non-production hours (overnight) and
has plenty of time to complete. We are below all the stated limits of
DFS/FRS, although I am aware that replicating roaming profiles and redirected
folders is not supported as we have it configured.
Sysvol/AD replication is working fine (and has always worked). I have
tested by placing a text file in each of the DCs sysvol and it does appear in
the other DCs folders during the next window. Sonar tells me that everything
is fine with the exception that ntfrs is usually failed on the problem
machine(s).
Repadmin, dcdiag, netdiag, and dns troubleshooting tools all indicate no
problems, except of course ntfrs is not running on the current problem
machine.
Restarting ntfrs manually doesn't help either. The service manager is
restarting at regular intervals too. Ntfrs will run for less than one minute
before failing on assertion.
I've looked through the ntfrs_nnnn.log debug files and am simply overwhelmed
by the volume of information (a tool to parse this would be handy).
Using
grep to search for error|access|fail doesn't produce any clues to the problem.
Finally, even with the failures; most of the content would replicate
successfully. However, *most* of the data being replicated is not good
enough.
I've disabled replication this weekend and hacked together a robocopy script
to keep things moving between targets until I can figure this out.
Anyone have any pointers, tips, or suggestions on getting this solved?
Paranoia
2006-04-21 12:18:02 UTC
Permalink
As http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
says, this environment is unsupport (FRS and Roaming Profiles).
The Microsoft Support gave me the same answere. I hope that DFSR is better
supported für roaming profiles.
Post by Ned Pyle (MSFT)
Certainly possible. PSS does not consider replicating profiles and
redirected folders to be truly unsupported - however, it's not recommended
and there are lot of things we simply cannot fix about it when customers
call in, because they are contrary to the concept of last writer wins, which
is what replication is built on. The biggest issue being that: last writer
wins, a user that can be logged in at multiple places at once, and a user
can have multiple files locked with FRS simultaneously on different DFS
targets that will not reconcile properly or predictably to the end user (i.e
they may start seeing 'old files' reappear that they swear they edited much
later).
DFSR(eplication) in Windows Serevr 2003 mitigates this to a great extend, as
you have much faster and more efficient replication now, and the fact that
the ConflictedAndDeleted folder can store conflicted files as replication
converges, but it's still not perfect.
But to reiterate - no, this is not unsupported. Just not recommended.
Ned
Post by Oscar J. Piñón
Hello,
I am configuring the exact same scenario as described here: Roming
"I am aware that replicating roaming profiles and redirected folders is
not supported".
Could somebody please provide me with more info as to why this is not
possible (or recommended)?
Thank you,
Oscar Piñón
Post by colorado99
I've been using DFS and FRS to replicate roaming profiles and redirected
folders between our branch offices (8). Each branch has a DC and is properly
configured in DNS and Sites. This all worked until recently when one or two
replicas would spew 13508 and 13506 errors until I ran a D2 restore.
All would be fine for a few days and then it would start again. The 13506
assertion message complains about a failed consistency check
(!IS_GUID_ZERO(ChangeOrder->pParentGuid)) in ChrgOrderAccept at line 2373.
The error has appeared on several, but not all replicas.
Replication is set to run during our non-production hours (overnight) and
has plenty of time to complete. We are below all the stated limits of
DFS/FRS, although I am aware that replicating roaming profiles and redirected
folders is not supported as we have it configured.
Sysvol/AD replication is working fine (and has always worked). I have
tested by placing a text file in each of the DCs sysvol and it does appear in
the other DCs folders during the next window. Sonar tells me that everything
is fine with the exception that ntfrs is usually failed on the problem
machine(s).
Repadmin, dcdiag, netdiag, and dns troubleshooting tools all indicate no
problems, except of course ntfrs is not running on the current problem
machine.
Restarting ntfrs manually doesn't help either. The service manager is
restarting at regular intervals too. Ntfrs will run for less than one minute
before failing on assertion.
I've looked through the ntfrs_nnnn.log debug files and am simply overwhelmed
by the volume of information (a tool to parse this would be handy).
Using
grep to search for error|access|fail doesn't produce any clues to the problem.
Finally, even with the failures; most of the content would replicate
successfully. However, *most* of the data being replicated is not good
enough.
I've disabled replication this weekend and hacked together a robocopy script
to keep things moving between targets until I can figure this out.
Anyone have any pointers, tips, or suggestions on getting this solved?
Ned Pyle (MSFT)
2006-04-22 02:10:24 UTC
Permalink
To clarify, no matter what when you call us in PSS, we will do best effort
support to make your environment work, even if we consider the configuration
you have completed 'unsupported'. This means that we will go to the limit of
helping you, keeping in mind that it just may not be possible to have it
work the way you have configured FRS. I've helped plenty of customers get
roaming profiles working in FRS, after making sure they understood the risks
they were undertaking.

If that didn't happen with this engineer you spoke to, a mistake was made on
our part.

DFSR is certainly much more capable of handling roaming profiles than FRS
was, and while still not recommended, it should work. This is mainly because
it copies data so much faster and more robustly than FRS could ever dream of
doing, and the latency of FRS is the usual issue with roaming profiles. :)

Ned
Post by Paranoia
As
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
says, this environment is unsupport (FRS and Roaming Profiles).
The Microsoft Support gave me the same answere. I hope that DFSR is better
supported für roaming profiles.
Post by Ned Pyle (MSFT)
Certainly possible. PSS does not consider replicating profiles and
redirected folders to be truly unsupported - however, it's not recommended
and there are lot of things we simply cannot fix about it when customers
call in, because they are contrary to the concept of last writer wins, which
is what replication is built on. The biggest issue being that: last writer
wins, a user that can be logged in at multiple places at once, and a user
can have multiple files locked with FRS simultaneously on different DFS
targets that will not reconcile properly or predictably to the end user (i.e
they may start seeing 'old files' reappear that they swear they edited much
later).
DFSR(eplication) in Windows Serevr 2003 mitigates this to a great extend, as
you have much faster and more efficient replication now, and the fact that
the ConflictedAndDeleted folder can store conflicted files as replication
converges, but it's still not perfect.
But to reiterate - no, this is not unsupported. Just not recommended.
Ned
Post by Oscar J. Piñón
Hello,
I am configuring the exact same scenario as described here: Roming
"I am aware that replicating roaming profiles and redirected folders is
not supported".
Could somebody please provide me with more info as to why this is not
possible (or recommended)?
Thank you,
Oscar Piñón
Post by colorado99
I've been using DFS and FRS to replicate roaming profiles and redirected
folders between our branch offices (8). Each branch has a DC and is properly
configured in DNS and Sites. This all worked until recently when one
or
two
replicas would spew 13508 and 13506 errors until I ran a D2 restore.
All would be fine for a few days and then it would start again. The 13506
assertion message complains about a failed consistency check
(!IS_GUID_ZERO(ChangeOrder->pParentGuid)) in ChrgOrderAccept at line 2373.
The error has appeared on several, but not all replicas.
Replication is set to run during our non-production hours (overnight) and
has plenty of time to complete. We are below all the stated limits of
DFS/FRS, although I am aware that replicating roaming profiles and redirected
folders is not supported as we have it configured.
Sysvol/AD replication is working fine (and has always worked). I have
tested by placing a text file in each of the DCs sysvol and it does appear in
the other DCs folders during the next window. Sonar tells me that everything
is fine with the exception that ntfrs is usually failed on the problem
machine(s).
Repadmin, dcdiag, netdiag, and dns troubleshooting tools all indicate no
problems, except of course ntfrs is not running on the current problem
machine.
Restarting ntfrs manually doesn't help either. The service manager is
restarting at regular intervals too. Ntfrs will run for less than one minute
before failing on assertion.
I've looked through the ntfrs_nnnn.log debug files and am simply overwhelmed
by the volume of information (a tool to parse this would be handy).
Using
grep to search for error|access|fail doesn't produce any clues to the problem.
Finally, even with the failures; most of the content would replicate
successfully. However, *most* of the data being replicated is not good
enough.
I've disabled replication this weekend and hacked together a robocopy script
to keep things moving between targets until I can figure this out.
Anyone have any pointers, tips, or suggestions on getting this solved?
Jeff Vandervoort
2006-05-16 00:01:10 UTC
Permalink
Ned Pyle wrote: "DFSR is certainly much more capable of handling roaming
profiles than FRS
was, and while still not recommended, it should work."

"...while still not recommended..."

Ned, or anyone, is this documented anywhere? I've searched Technet in vain
for best practices information for DFSR. All I get is information on tested
limits...but that doesn't answer the critical "Is it supported" question
that anyone in IS is going to want answered. If there's even an official
"not recommended" statement, I have a client that needs to see it before we
move forward with an imminent project.
--
Jeff Vandervoort
JRVsystems
Post by Ned Pyle (MSFT)
To clarify, no matter what when you call us in PSS, we will do best effort
support to make your environment work, even if we consider the
configuration you have completed 'unsupported'. This means that we will go
to the limit of helping you, keeping in mind that it just may not be
possible to have it work the way you have configured FRS. I've helped
plenty of customers get roaming profiles working in FRS, after making sure
they understood the risks they were undertaking.
If that didn't happen with this engineer you spoke to, a mistake was made
on our part.
DFSR is certainly much more capable of handling roaming profiles than FRS
was, and while still not recommended, it should work. This is mainly
because it copies data so much faster and more robustly than FRS could
ever dream of doing, and the latency of FRS is the usual issue with
roaming profiles. :)
Ned
Post by Paranoia
As
http://www.microsoft.com/windowsserver2003/techinfo/overview/dfsfaq.mspx
says, this environment is unsupport (FRS and Roaming Profiles).
The Microsoft Support gave me the same answere. I hope that DFSR is better
supported für roaming profiles.
Post by Ned Pyle (MSFT)
Certainly possible. PSS does not consider replicating profiles and
redirected folders to be truly unsupported - however, it's not recommended
and there are lot of things we simply cannot fix about it when customers
call in, because they are contrary to the concept of last writer wins, which
is what replication is built on. The biggest issue being that: last writer
wins, a user that can be logged in at multiple places at once, and a user
can have multiple files locked with FRS simultaneously on different DFS
targets that will not reconcile properly or predictably to the end user (i.e
they may start seeing 'old files' reappear that they swear they edited much
later).
DFSR(eplication) in Windows Serevr 2003 mitigates this to a great extend, as
you have much faster and more efficient replication now, and the fact that
the ConflictedAndDeleted folder can store conflicted files as replication
converges, but it's still not perfect.
But to reiterate - no, this is not unsupported. Just not recommended.
Ned
Post by Oscar J. Piñón
Hello,
I am configuring the exact same scenario as described here: Roming
"I am aware that replicating roaming profiles and redirected folders is
not supported".
Could somebody please provide me with more info as to why this is not
possible (or recommended)?
Thank you,
Oscar Piñón
Post by colorado99
I've been using DFS and FRS to replicate roaming profiles and redirected
folders between our branch offices (8). Each branch has a DC and is properly
configured in DNS and Sites. This all worked until recently when one
or
two
replicas would spew 13508 and 13506 errors until I ran a D2 restore.
All would be fine for a few days and then it would start again. The 13506
assertion message complains about a failed consistency check
(!IS_GUID_ZERO(ChangeOrder->pParentGuid)) in ChrgOrderAccept at line 2373.
The error has appeared on several, but not all replicas.
Replication is set to run during our non-production hours (overnight) and
has plenty of time to complete. We are below all the stated limits of
DFS/FRS, although I am aware that replicating roaming profiles and redirected
folders is not supported as we have it configured.
Sysvol/AD replication is working fine (and has always worked). I have
tested by placing a text file in each of the DCs sysvol and it does appear in
the other DCs folders during the next window. Sonar tells me that everything
is fine with the exception that ntfrs is usually failed on the problem
machine(s).
Repadmin, dcdiag, netdiag, and dns troubleshooting tools all indicate no
problems, except of course ntfrs is not running on the current problem
machine.
Restarting ntfrs manually doesn't help either. The service manager is
restarting at regular intervals too. Ntfrs will run for less than
one
minute
before failing on assertion.
I've looked through the ntfrs_nnnn.log debug files and am simply overwhelmed
by the volume of information (a tool to parse this would be handy).
Using
grep to search for error|access|fail doesn't produce any clues to the problem.
Finally, even with the failures; most of the content would replicate
successfully. However, *most* of the data being replicated is not good
enough.
I've disabled replication this weekend and hacked together a robocopy script
to keep things moving between targets until I can figure this out.
Anyone have any pointers, tips, or suggestions on getting this solved?
Ned Pyle (MSFT)
2006-05-22 22:43:40 UTC
Permalink
This post might be inappropriate. Click to display it.
colorado99
2007-03-06 02:29:50 UTC
Permalink
Everything Ned has said about DFSR is true. After rebuilding all our DCs
with Server 2003 R2 everything fell into place. The roaming profiles,
redirected folders and DFSR do in fact play quite nicely together. Whether
it is supported, recommended, or otherwise; it does work when properly
configured on Server 2003 R2.
Ned Pyle [MSFT]
2007-03-08 15:37:33 UTC
Permalink
That's a great testimonial, thanks for the update!
--
Ned Pyle
Microsoft Enterprise Platform Support
This posting is provided "AS IS" with no warranties, and confers no rights.
Please read http://www.microsoft.com/info/cpyright.htm for more information.
Post by colorado99
Everything Ned has said about DFSR is true. After rebuilding all our DCs
with Server 2003 R2 everything fell into place. The roaming profiles,
redirected folders and DFSR do in fact play quite nicely together.
Whether
it is supported, recommended, or otherwise; it does work when properly
configured on Server 2003 R2.
Continue reading on narkive:
Loading...