Replication unstable,ntfrs.jdb large,dcdiag erroneous

[FrauW]

Hello all,
Lately my replication has been acting berzerk. My ntfrs.jdb file on my root dc (under C:\WINNT\ntfrs\jet) exploded and sucked up all the space on the C: drive. After deleting the file, the space was once again freed up. However, deleting this file had the result of messing up replication on the root server and I had to manually copy info. from the backup to the main.
Since these lovely happenings, been looking into this. Found recommendations and one was to run dcdiag. I got the following as the only error in my results:

Starting test: frssysvol
There are errors after the SYSVOL has been shared.
The SYSVOL can prevent the AD from starting.

So...
1. How do I prevent my ntfrs.jdb file from blowing up overnight i.e. how does one control its 'growth'?
AND
2. How do I resolve the dcdiag error?

...and just a general one...

3. Why does replication just stop working after working for weeks when nothing was done on the server i.e. what initializes file corruption?

THANKS.
FYI.. I searched posts with this error and never found anything.

 

[FrauW]

Hello out there? No one has an idea about this ntfrs.jdb file and how I keep its growth down or how I resolve the frssysvol error that comes up in DCDIAG results? Please help!

 

[FrauW]

Hello,
How do I keep my ntfrs.jdb file (registers all replication transactions) from growing out of control? Please see my first entry. Any tips, even if you think they might not be useful, will be of use to me. Thanks!
File is located under C:\WINNT\ntfrs\jet.

 

[i601254]

First of all, sorry but I don't have any solution for you. However, I did want to chime in to say that we recently had a big mess with FRS and Sysvol.

Our problems started when I noticed all login scripts and the domain group policy were missing from Sysvol. And like you, we did nothing. It finally got to the point that I had to call in a consultant. Their solution was to create a Win2k domain in their lab then copy that group policy over to our Sysvol. They indicated that they've done this before since, in their experience, Sysvol corruption is guaranteed. This did not seem to fix our problems though.

I do know that Microsoft does not recommend any type of cut-and-paste or copy-and-paste activity in or to the Sysvol directory. Apparently this wreaks havoc with junction points. In their article "Best Practices for Sysvol Maintenance" (KB 324175), they do discuss Sysvol and junction points but do not really point out any specific preventative measures.

Long story short, we ended up having to pay the rather salty fee and contact Microsoft for assistance. After running a number of different tools, we were able to restore the Sysvol and all junction points.

In hindsight, it would have probably been easier and cheaper to simply remove each DC one at a time and reinstall the OS (we only have two DC's and one Exchange server).

If anyone does have any insight, suggestions or experience with this, I be glad to hear them.

 

[FrauW]

Hey, thanks for the input. After much guess work I eventually solved the problem. Well I still don't know how we would 'control the growth' of the ntfrs.jdb file however I moved it to a partition that has much more space than our SYSTEM partition. Default location for ntfrs.jdb is always
%systemroot%ntfrs. Here is a copy and paste of Knowledge Base Article 221093:
___________________________________________________________
NT File Replication Service (NTFRS) transactions are stored in the Ntfrs.jdb Jet database and in a set of log files in the default paths %SystemRoot%\Ntfrs\Jet and %SystemRoot%\Ntfrs\Jet\Log. Administrators can relocate the Ntfrs.jdb and log files to another logical partition or physical drive as necessary. WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

No user interface exists to change the location of the NTFRS database during or after Setup.

back to the top

Moving the Ntfrs.jdb File
Stop the File Replication Service (FRS) service by typing net stop ntfrs at a command prompt.
Copy the NTFRS folder from the current to the desired location.

The default location for the NTFRS database is %systemdrive%\winnt\ntfrs.
Using explorer or a command line equivalent (xcopy /o), copy and paste the \NTFRS folder to the target location. For simplicity, consider using the same relative path as the default. For example, if the default path is c:\winnt\ntfrs, then use d:\winnt\ntfrs.
Modify the Working Directory (REG_SZ) key located in the following registry subkey to reflect the new path (the default is %SystemRoot%\Ntfrs):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentCcontrolSet\Services\NtFrs\Parameters

Verify permissions on the NTFRS directory structure.

Make sure you configure Administrator and system accounts with full control for all files and folders in the tree, including the Ntfrs.jdb file in the Jet folder. The structure of the NTFRS directory tree is:
Ntfrs
Ntfrs\Jet
Ntfrs\Jet\Log
Ntfrs\Jet\Sys
Ntfrs\Jet\Temp

Start the FRS Service by typing net start ntfrs. Confirm successful startup in the FRS event log.
Verify inbound and outbound replication of all Distributed File System (DFS) and SYSVOL replica this computer participates in.
When the FRS service starts, the FRS database tree is created in the path defined in step 2. The structure of the tree is:
Ntfrs
Ntfrs\Jet
Ntfrs\Jet\Log
Ntfrs\Jet\Sys
Ntfrs\Jet\Temp

NOTE: If you did not copy the NTRFS folder and its child folders in step 2 from the original location to the new folder in step 2, and simply defined an alternate working directory in step 3, the FRS database tree structure and Ntrfs.jdb file in step 4 are automatically created when the service next starts in step 5. In other words, an implicit non-authoritative restore (burflags = d2) occurs along with the change to the working directory.

;-)