I have three Win2k3 domain controllers. When I make a group policy change on two of them, they replicate to one another without any problem. The third DC does not pick up these changes. I have to manually make the change here seperately. What can I check so it picks up these changes like the other two?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Sync Domain Controllers
- Thread starter mpapier
- Start date
porkchopexpress
IS-IT--Management
Any errors in the event log?
Has this DC been offline at any point or had the time set manually?
You know what Jack Burton always says at a time like this...
Has this DC been offline at any point or had the time set manually?
You know what Jack Burton always says at a time like this...
porkchopexpress
IS-IT--Management
It might also be worth testing if the replication service is working, place a small file in the Netlogon folder and see if it appears in the Netlogon folder on the other servers.
I've fixed problems like this in the past using the "Allow Replication With Divergent and Corrupt Partner" reg edit but wait and see first this can be a tricky path and a last resort.
You know what Jack Burton always says at a time like this...
I've fixed problems like this in the past using the "Allow Replication With Divergent and Corrupt Partner" reg edit but wait and see first this can be a tricky path and a last resort.
You know what Jack Burton always says at a time like this...
- Thread starter
- #5
Simple setup: one domain, one geographic locale, all in the same sites and services. Just noticed eventID 2087 which followed a series of EventID 1864s. I am going to look at this:
Active Directory could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources.
Source domain controller:
upg-main
Failing DNS host name:
a81108b8-22ca-424e-9b8e-4de521a170e7._msdcs.unitypg-domain.com
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur. To log all individual failure events, set the following diagnostics registry value to 1:
Registry Path:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client
User Action:
1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498.
2) Confirm that the source domain controller is running Active directory and is accessible on the network by typing "net view \\<source DC name>" or "ping <source DC name>".
3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on
dcdiag /test:dns
4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows:
dcdiag /test:dns
5) For further analysis of DNS error failures see KB 824449:
Additional Data
Error value:
11004 The requested name is valid, but no data of the requested type was found.
For more information, see Help and Support Center at
Active Directory could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources.
Source domain controller:
upg-main
Failing DNS host name:
a81108b8-22ca-424e-9b8e-4de521a170e7._msdcs.unitypg-domain.com
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur. To log all individual failure events, set the following diagnostics registry value to 1:
Registry Path:
HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics\22 DS RPC Client
User Action:
1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498.
2) Confirm that the source domain controller is running Active directory and is accessible on the network by typing "net view \\<source DC name>" or "ping <source DC name>".
3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on
dcdiag /test:dns
4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows:
dcdiag /test:dns
5) For further analysis of DNS error failures see KB 824449:
Additional Data
Error value:
11004 The requested name is valid, but no data of the requested type was found.
For more information, see Help and Support Center at
porkchopexpress
IS-IT--Management
Hmm it does look more like a DNS issue than my previouse post.
Have these DC's ever communicated?
You know what Jack Burton always says at a time like this...
Have these DC's ever communicated?
You know what Jack Burton always says at a time like this...
- Thread starter
- #7
One of the two that are replicating fine is actually the new server - entered into the environment about one month ago. So, it is replicating fine with one of the pre-existing ones.
Since this is a new job for me, its hard to say whether the two old ones used to relicate fine or not.
Since this is a new job for me, its hard to say whether the two old ones used to relicate fine or not.
- Thread starter
- #8
The DC having the replication issues is also a name server. When I look at the Network Connection properties, in the Use the following DNS server addresses, it only lists itself as the preferred DNS server. Should I add an alternate? Could these things be related?
- Thread starter
- #9
I followed these steps to fix the issue. All replication is working now.
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:\windows\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.
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
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.
For more information, see Help and Support Center at
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:\windows\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.
Expand HKEY_LOCAL_MACHINE.
Click down the key path:
"System\CurrentControlSet\Services\NtFrs\Parameters"
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.
For more information, see Help and Support Center at
- Status
Similar threads