Discussion:
FRS-Staging keeps building
(too old to reply)
TC
2006-09-15 21:29:48 UTC
Permalink
Hello,
I pre-staged a dc -> member file server share replica. I've got one way
replication from the dc to the member server and I used MS backup to
pre-stage 15GB of data.

Replication appeared to complete based on comparing the # of files but
the pre-existing folder still had all of its files and files keep
building in FRS-Staging. The only warning I got was that the staging
folder got to 68% and comparing files changed today on both server
share they are identical. This is the third time I've tried to
replicate and I just can seem to get FRS-staging to settle down on the
member server. There are no staged files on the dc and no glaring
event errors. Any ideas are appreciated.

Thanks,
Todd
Ned Pyle [MSFT]
2006-09-16 14:18:42 UTC
Permalink
When you use NTBACKUP to prestage the files, was there ever a 3rd replica in
the mix? If you only ever had 1 server and you used NTBACKUP to move the
data to a new replica, this is expected behavior.

See http://support.microsoft.com/kb/266679/
--
Ned Pyle
Microsoft Enterprise Platforms Support

All postings on this newsgroup are provided "AS IS" with no warranties, and
confer no rights.
For more information please visit
http://www.microsoft.com/info/cpyright.mspx to find terms of use.
TC
2006-09-18 17:34:33 UTC
Permalink
Post by Ned Pyle [MSFT]
When you use NTBACKUP to prestage the files, was there ever a 3rd replica in
the mix? If you only ever had 1 server and you used NTBACKUP to move the
data to a new replica, this is expected behavior.
See http://support.microsoft.com/kb/266679/
--
Ned Pyle
Microsoft Enterprise Platforms Support
All postings on this newsgroup are provided "AS IS" with no warranties, and
confer no rights.
For more information please visit
http://www.microsoft.com/info/cpyright.mspx to find terms of use.
Ned,
I don't have a third server option and it looks like that's where I
went wrong trying to do the NTBACKUP scenario. Do you have any
references or ideas for my situation where I need to initially
replicate this much data? I could increase the staging folder size to
say, 8 GB to avoid filling up the staging area initially. In general
are there any pitfalls to stopping replication, deleting frs-staging
files on server2 and re-configure replication. Are there any more
advanced 'cleaning' techniques to get FRS to a starting point that it
works reliably on DFS shares?

Todd
Ned Pyle [MSFT]
2006-09-18 19:24:10 UTC
Permalink
Increasing the staging area to that size should help - technically speaking,
FRS' staging folder only needs to be as large as the largest file
replicated, but it's always best to provide as much space as you can so that
there are no bottlenecks.

There really aren't any other advanced steps other than what you mentioned.
techincally, none of those steps are really necessary - simply adding a new
replica and upping the staging size appropriately should almost always be
'enough'.

For good best practices info when configuring FRS replication via DFS, I'dd
recommend:

Design Decisions, Defaults and Behavior for FRS File and Folder Filters in
DFS and SYSVOL Replica Sets - http://support.microsoft.com/kb/229928/en-us

Configuring Correct Staging Area Space for Replica Sets -
http://support.microsoft.com/kb/329491/

File Replication Service Stops Responding When Staging Area is Full -
http://support.microsoft.com/kb/264822/en-us

How to Troubleshoot the File Replication Service and the Distributed File
System - http://support.microsoft.com/kb/272279/en-us

File Replication Service (Additional tuning) -
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsdh_frs_leca.asp
--
Ned Pyle
Microsoft Enterprise Platforms Support

All postings on this newsgroup are provided "AS IS" with no warranties, and
confer no rights.
For more information please visit
http://www.microsoft.com/info/cpyright.mspx to find terms of use.
TC
2006-09-18 21:16:21 UTC
Permalink
Post by Ned Pyle [MSFT]
Increasing the staging area to that size should help - technically speaking,
FRS' staging folder only needs to be as large as the largest file
replicated, but it's always best to provide as much space as you can so that
there are no bottlenecks.
There really aren't any other advanced steps other than what you mentioned.
techincally, none of those steps are really necessary - simply adding a new
replica and upping the staging size appropriately should almost always be
'enough'.
For good best practices info when configuring FRS replication via DFS, I'dd
Design Decisions, Defaults and Behavior for FRS File and Folder Filters in
DFS and SYSVOL Replica Sets - http://support.microsoft.com/kb/229928/en-us
Configuring Correct Staging Area Space for Replica Sets -
http://support.microsoft.com/kb/329491/
File Replication Service Stops Responding When Staging Area is Full -
http://support.microsoft.com/kb/264822/en-us
How to Troubleshoot the File Replication Service and the Distributed File
System - http://support.microsoft.com/kb/272279/en-us
File Replication Service (Additional tuning) -
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsdh_frs_leca.asp
--
Ned Pyle
Microsoft Enterprise Platforms Support
All postings on this newsgroup are provided "AS IS" with no warranties, and
confer no rights.
For more information please visit
http://www.microsoft.com/info/cpyright.mspx to find terms of use.
Ned,
Thanks for the info. I meant by cleaning that there are legacy
replication sets with information still in the registry and ntfrs
configuration.
Below is an example of one of the tomstoned replicas in the registry
(there are several more) and apparently ntfrs configuration still has
info about
replica sets that were decomissioned. Probably my fault for starting
over so many times but this information is causing havoc with diag
tools such as
ultrasound and frsdiag. dfsutil /viewdfsdirs shows correct info about
my dfs structure and it's working fine.

Do you have any other references that might help me scour these out.
I've looked and can't seem to find any.

Sample tombstoned Registry entry diagnosed by frsdiag ntfrs_reg.txt
file

SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets
Database Directory = c:\windows\ntfrs\jet
SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica
Sets\0c008266-7763-4ef7-83cc4ab26c1ff54b
Replica Set Name = DFS|PROGRAMS
Replica Set Root = d:\programs
Replica Set Stage = f:\frs-staging
Replica Set Type = DFS
Replica Set Tombstoned = 1

Sample from ntfrsutl sets also reflected in frsdiag ntfrs_config.txt
file. None of these sets exist in the dfs gui as replica sets.

ACTIVE REPLICA SETS
DFS in state STOPPED
DFS|SHARE in state STOPPED
DFS|SHARE in state STOPPED
DFS|SHARE in state STOPPED
DFS|TEMP in state STOPPED
DFS|PROJECTS in state STOPPED
Ned Pyle [MSFT]
2006-09-18 22:17:06 UTC
Permalink
If not, here's a writeupon manually yanking stuff out (warning - it's
heinous and you may want a case here in PSS for assistance; always get
NTBACKUP of SYSTEMSTATE before doing this stuff, on a DC and on the FRS
members). This is from an MS internal article.

=====
Occasionally situations may occur where an existing domain based
DFS (root and links which were replicated on it) has been
incompletely removed from the environment or is otherwise not in use.

When that DFS root will no longer be in use, or in situations where you need
to
manually remove a replica set member for the DFS FRS replicas set or sets,
you can
follow these steps.

One scenario where this would be useful is when you are adding a server to
be an
additional target for a link and the data sourcing from the first target(s)
is
failing since the FRS is in an error state from the old replica set
membership.
Typically you may expect to see 13552 and 13555 events indicating an FRS
failure
relating to the old replica set, but it does not always appear.

Gather FRSDIAG
(http://www.microsoft.com/downloads/details.aspx?familyid=43CB658E-8553-4DE7-811A-562563EB5EBF&displaylang=en)

Examine the NTFRS_SETS log.

ACTIVE REPLICA SETS
INETPUB (ALL SITES)|DFS-NEW in state ERROR
WEBDFS in state STOPPED
WEBDFS in state STOPPED
WEBDFS in state STOPPED

DELETED REPLICA SETS

In this case, INETPUB is the DFS replica set which needs to be removed, and
WEBDFS
is the new one where the sourcing is failing.

=====

Resolution:

To resolve this scenario, and to succesfully remove the server from the old
DFS FRS
replica set, follow these steps.

Examine the logs from the affected server again, this time opening the
NTFRS-REG.TXT to find the registry specific information (the GUID) for the
old DFS
named INETPUB, then delete the registry based information to the old DFS
root named
INETPUB:

HKEY_LOCAL_MACHINE\system\currentcontrolset\services\NtFrs
Cumulative Replica Sets
9e055375-2284-4181-809e0d40abebfcb3
Number Of Partners = REG_DWORD 0x00000000
BurFlags = REG_DWORD 0x00000000
Replica Sets
9e055375-2284-4181-809e0d40abebfcb3
Replica Set Name = INETPUB (ALL SITES)|DFS-NEW
Replica Set Root = w:\dfs-new
Replica Set Stage = c:\frs-staging
Replica Set Type = DFS
Replica Set Tombstoned = REG_DWORD 0x00000000

Next, locate the Active Directory specific information relating to the
server's
membership in the old replica set. That information is in the log file
called NTFRS_DS.TXT:

SUBSCRIPTION: INETPUB (ALL SITES)
DN : cn=inetpub (all
sites),cn=7613dd47-bfbe-407f-a8dc-43cc00c878ca,cn=dfs
volumes,cn=ntfrs
subscriptions,cn=vm-iis-2,cn=computers,dc=domain,dc=contso,dc=com
Guid : 9b992b00-68d9-4ba5-a0a11dd289623ba4
Working : (null)
Actual Working: c:\winnt\ntfrs
WhenCreated : 12/31/2002 13:43:10 Mountain Standard Time Mountain
Daylight
Time [420]
WhenChanged : 8/8/2003 14:20:49 Mountain Standard Time Mountain
Daylight
Time [420]

SUBSCRIBER: INETPUB (ALL SITES)|DFS-NEW
DN : cn=inetpub (all sites)|dfs-new,cn=inetpub (all
sites),cn=7613dd47-bfbe-407f-a8dc-43cc00c878ca,cn=dfs volumes,cn=ntfrs
subscriptions,cn=vm-iis-2,cn=computers,dc=domain,dc=contso,dc=com
Guid : 044ce73c-9abd-4358-b0d11acc2486f9cb
Member Ref: (null)
Root : w:\dfs-new
Stage : c:\frs-staging
WhenCreated : 12/31/2002 13:43:10 Mountain Standard Time Mountain
Daylight Time [420]
WhenChanged : 8/8/2003 14:20:49 Mountain Standard Time Mountain
Daylight
Time [420]

You may have additional information for the old replica set in
CN=INETPUB,CN=DFS
VOLUMES,CN=FILE REPLICATION SERVICE,CN=SYSTEM,DC=DOMAIN,DC=CONTOSO,DC=COM.
If the
information is not visible or is not removable from within the DFSCMD.MSC
you can
use ADSIEDIT.MSC.

Once the removal of this information is finished, you will need to do a
BURFLAGS D2
of the remaining DFS replica set. The registry key location for that is
here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative
Replica Sets\<NEW REPLICA SET GUID>
Value name is BURFlags, DWORD, and the data is D2.

Once you have done the D2 entry above, then stop and then restart the File
Replication Service.

=====

Not the easiest thing in the world, as you can see. I again recommend
opening a case with PSS if you're not comfortable with all this...
--
Ned Pyle
Microsoft Enterprise Platforms Support

All postings on this newsgroup are provided "AS IS" with no warranties, and
confer no rights.
For more information please visit
http://www.microsoft.com/info/cpyright.mspx to find terms of use.
Continue reading on narkive:
Loading...