[secretagentbill]

Hello. Perhaps this is beyond the scope of this forum, but if so just let me know and close the thread. At any rate, I have two servers, primary and backup domain controllers, both running Win2k server. I had a distributed file system set up, replicating my data between the two. Well it got to the point that this was not working out because the backup domain controller was lagging so far behind that it was dangerous to leave it in the replica set (some users might access old data). Also I noticed that ntfrs.exe was running at 100% of the cpu constantly. I removed the backup domain controller from the replica set and rebooted, but for some reason, when I start the File Replication Service, it runs ok for a couple of minutes and then shoots up to 100% and stays there. Does anybody have any suggestions? Thanks.

Athlon 64 3200+
1.5 GB RAM

[Advertisements]

Well, since I didn't get a reply, I'll just update everyone. I found the following on a different forum...

Are you still seeing these invalid partner errors in the FRS debug logs?

If so, I have a hunch on root cause and ultimately how to fix it.

The server that reported this error thinks SB-2$ has a machine SID of
S-1-5-21-484763869-1972579041-1417001333-1809
If SB-2$ lost its computer account in the domain and it had to be rejoined,
it would get a new SID.
However, FRS stores this info in its local database and has no way to
dynamically update it if this event occurs.
Therefore FRS replication breaks down.
You can actually determine what the current machine SID for SB-2$ is by
using a resource kit tool. (I can't think of the name of it.)

You were right on in your original post. I should have caught
on.....completely glossed over it in favor of the nosubscriber errors.

The only way to update the FRS database is to blow it away (the one that is
reporting the errors), and force the replica to re-initialize.
couple of ways to accomplish this.

stop FRS
rename %systemroot%\ntfrs\jet folder.
start FRS

or

stop FRS
HKLM\system\ccs\services\ntfrs\parameters\backup/restore\process at startup
modify "burflags" to a HEX value of D2
start FRS.

Both of these processes will reinitialize the database forcing the member to
rejoin the replica set (and learn the SIDs of its upstream neighbors)
ALL DATA in the set will be moved into the ntfrs-preexisting folder.
then an optimized synchronization will take place. any data that is the same
on an upstream neighbor will be moved from the ntfrs pre-existing
anything different will be copied across the network.
This can take a considerable amount of time depending on the number of
files, processor, memory, and to a lesser extent bandwidth.

If this is what you are experiencing, then it is rather rare.
But it is common enough for MS to provide a bit more resiliency in FRS IMHO.

--
Glenn L
CCNA, MCSE 2000, MCSE 2003 + Security


So, I had already reconfigured some stuff in DNS to make sure that my two servers were communicating. I renamed that JET folder as Glenn suggested and restarted NTFRS and it seems to be running ok, at least the processor doesn't shoot up to 100% like it did before. I haven't yet tried letting my server rejoin the data replica set, so right now it should only be replicating the sysvol stuff. I may try adding it to the root replica in DFS later, but I think it is working as it should now.

Here's a link to the post on the other forum for those that are experiencing the same problem...
http://www.winserver.../ftopic926.html

[secretagentbill]

Well, since I didn't get a reply, I'll just update everyone. I found the following on a different forum...

Are you still seeing these invalid partner errors in the FRS debug logs?

If so, I have a hunch on root cause and ultimately how to fix it.

The server that reported this error thinks SB-2$ has a machine SID of
S-1-5-21-484763869-1972579041-1417001333-1809
If SB-2$ lost its computer account in the domain and it had to be rejoined,
it would get a new SID.
However, FRS stores this info in its local database and has no way to
dynamically update it if this event occurs.
Therefore FRS replication breaks down.
You can actually determine what the current machine SID for SB-2$ is by
using a resource kit tool. (I can't think of the name of it.)

You were right on in your original post. I should have caught
on.....completely glossed over it in favor of the nosubscriber errors.

The only way to update the FRS database is to blow it away (the one that is
reporting the errors), and force the replica to re-initialize.
couple of ways to accomplish this.

stop FRS
rename %systemroot%\ntfrs\jet folder.
start FRS

or

stop FRS
HKLM\system\ccs\services\ntfrs\parameters\backup/restore\process at startup
modify "burflags" to a HEX value of D2
start FRS.

Both of these processes will reinitialize the database forcing the member to
rejoin the replica set (and learn the SIDs of its upstream neighbors)
ALL DATA in the set will be moved into the ntfrs-preexisting folder.
then an optimized synchronization will take place. any data that is the same
on an upstream neighbor will be moved from the ntfrs pre-existing
anything different will be copied across the network.
This can take a considerable amount of time depending on the number of
files, processor, memory, and to a lesser extent bandwidth.

If this is what you are experiencing, then it is rather rare.
But it is common enough for MS to provide a bit more resiliency in FRS IMHO.

--
Glenn L
CCNA, MCSE 2000, MCSE 2003 + Security


So, I had already reconfigured some stuff in DNS to make sure that my two servers were communicating. I renamed that JET folder as Glenn suggested and restarted NTFRS and it seems to be running ok, at least the processor doesn't shoot up to 100% like it did before. I haven't yet tried letting my server rejoin the data replica set, so right now it should only be replicating the sysvol stuff. I may try adding it to the root replica in DFS later, but I think it is working as it should now.

Here's a link to the post on the other forum for those that are experiencing the same problem...
http://www.winserver.../ftopic926.html