Failing NETLOGON Replication following Additional DC DCPROMO

Afternoon Experts,

I've currently hit a problem following an attempt to add an additional domain controller into a SBS 2003 domain. Some background:

The network runs 6 servers with the only DC being run from a SBS 2003 box (we'll call it SBS1). The idea of our project is to get rid of SBS1entirely, and migrate to a stand-alone Server 2008 DC (We'll call this FINALDC). We have a separate Exchange 2007 installation which we have migrated most of the functionality over to (just stuck on public folders at present before we can decommission Exchange 2003 on SBS1 box - but that's a different problem). We have taken one of the other servers in the network, running server 2003 standard, and run DCPROMO on it. This server is going to be used as a backup DC to FINALDC, and will act as a 'swing' for the purposes of migration. Essentially, we want AD running on this machine (we'll call it TEMPDC for the sake of argument) so that we can format SBS1 and turn it into FINALDC.

We have run DCPROMO on TEMPDC and installed AD, as a member DC to an existing domain (DOMAIN.local). AD looks to have come across to TEMPDC ok, apart from the 'netlogon' folder has not replicated. The initial tree structure is there, but it is not complete and nothing has been shared.

Looking at eventvwr on TEMPDC, we get the following event (ID 13508),

"The File Replication Service is having trouble enabling replication from SBS1 to TEMPDC for e:\sysvol\domain using the DNS name SBS1.DOMAIN.local. FRS will keep retrying.
 Following are some of the reasons you would see this warning.
 [1] FRS can not correctly resolve the DNS name SBS1.DOMAIN.local from this computer.
 [2] FRS is not running on SBS1.DOMAIN.local.
 [3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.
 This event log message will appear once per connection, After the problem is fixed you will see another event log message indicating that the connection has been established."

Looking at eventvwr on SBS1, we get the following event (13568):

Event ID 13568
Source NtFrs
Type Error
Description The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

Replica set name is    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"
Replica root path is   : "c:\winnt\sysvol\domain"
Replica root volume is : "\\.\C:"
A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.  This can occur because of one of the following reasons.

[1] Volume "\\.\C:" has been formatted.
[2] The NTFS USN journal on volume "\\.\C:" has been deleted.
[3] The NTFS USN journal on volume "\\.\C:" has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal.
[4] File Replication Service was not running on this computer for a long time.
[5] File Replication Service could not keep up with the rate of Disk IO activity on "\\.\C:".
Setting the "Enable Journal Wrap Automatic Restore" registry parameter to 1 will cause the following recovery steps to be taken to automatically recover from this error state.
[1] At the first poll, which will occur in 5 minutes, this computer will be deleted from the replica set. If you do not want to wait 5 minutes, then run "net stop ntfrs" followed by "net start ntfrs" to restart the File Replication Service.
[2] At the poll following the deletion this computer will be re-added to the replica set. The re-addition will trigger a full tree sync for the replica set.

WARNING: During the recovery process data in the replica tree may be unavailable. You should reset the registry parameter described above to 0 to prevent automatic recovery from making the data unexpectedly unavailable if this error condition occurs again.

To change this registry parameter, run regedit.

Click on Start, Run and type regedit.

Click down the key path:
Double click on the value name
   "Enable Journal Wrap Automatic Restore"
and update the value.

If the value name is not present you may add it with the New->DWORD Value function under the Edit Menu item. Type the value name exactly as shown above."

Now, it appears that we have a 'journal wrap error' on SBS1. The event ID talks about how to resolve this by enabling journal wrap automatic restore. I am not, however, familiar with this process and wanted to know if anybody could put me at ease / give me advice on the best way forward before I give it a go? Are we on the right lines here - it's quite a complex issue and difficult to know the best way forward.

Essentially all we want to be able to do is to get AD running on TEMPDC, with all FSMO roles, so that we can format SBS1.

Any help greatly appreciated!

Bolton Wanderer

Who is Participating?
Yes, this is the proper method to fix Journal Wrap.  Change the value to 1 and reboot the server.

You may want to save and clear the logs on SBS1 so that you can see any new errors more easily.

BoltonWandererAuthor Commented:
Thanks for the response. I havn't actually tried this yet, as after reading into it more it seems that this method (a non-authoritative D2 Restore) only works if there is a connection from a fully functional upstream server. In our case we don't have this. We just have SBS1 (which has a journal wrap error) and TEMPDC (which does not have a fully functioning replica because of the SDBS1 journal wrap error).
Has anybody any ideas how to proceed?
Thanks in advance,
Bolton Wanderer
Use the method above.  It will end up doing a D4.

BoltonWandererAuthor Commented:
Thanks, that sorted it - all up and running on a second DC now

Bolton Wanderer
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.