After a bit of research it transpired that the group policy management console tries to connect to the PDC when working with group policies. I tried browsing to my SYSVOL share on the new domain controller and low and behold it was not there! As you can imagine this concerned me greatly. The first place to check was the File Replication Service log in the Event Viewer of both servers. The older of the two domain controllers log was full of Errors with Event ID: 13568
The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR....
This error had been present for more than two years. The second server's log was full of Event ID: 13508 warnings
The File Replication Service is having trouble enabling replication fromto for using the DNS name . FRS will keep retrying.
Following are some of the reasons you would see this warning......
This seemed like more of a generic error and so I suspected my fault lied with the first server. I tried restarting the netlogon and ntfrs services as a first resort but the problem still remained. A bit of Googling later and I came across this Microsoft article which sounded like it could be of help.
After reading the article I stopped the ntfrs service on both servers and navigated to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup registry key. I only had one copy of the SYSVOL directory and so had to be careful to get the next step the right way round, otherwise I would be restoring from backup. On the first server I modified the BurFlags DWORD value to D4 which means do an authoritative restore and on the second server I modified Burflags to D2 which means do a non-authoritative restore.
I started the ntfrs service on the first server and then on the second server. Voila the SYSVOL directory was now replicated and the netlogon service was automatically notified, which in turn shared the SYSVOL directory out. I opened the group policy management console and the network errors were no longer present. A 5 minute group policy change had turned into a nerve racking couple of hours research and fault fixing! However, I am now a wiser man and I hope somebody else will be able to make use of this blog one day.
Good night
Thank you for the this.
ReplyDeleteI have been working at solviong the same issue for 2 days now until I found your thread.
It solved ir right away :-)
That's great news, if it helps one person then it was a post worth writing :)
ReplyDeleteNeil,
ReplyDeleteabsolute lifesaver. I had just removed a failed DC from the WIN2K8 domain and added a new DC (WIN2K8 R2) and was in the process of decomming the original when I hit this problem. Good job I checked group policy manger on the new DC first!! All good now. Thanks Kristian
Yesterday and today I had 2 different customers with this exact same issue. Your detailed step by step instructions saved the day twice. Thanks a lot!!!
ReplyDeleteIs it ok for Windows Server 2012 R2? I have no sysvol folder on it and the first DC is a WS2003sp1
ReplyDeletethx
Thank you! Great workaround !
ReplyDeleteWorks good on Win 2003 DC and Win 2012R2 DC.
Great but what one is the "first server"? The one with the SYSVOL still present?
ReplyDeleteTook the time to write this comment just to say... Moved a server into Azure and transfer FSMO and had this issue. Your write up totally worked and saved me hours of research... I think I love you.
ReplyDelete8 years later this works thanks for writing a blog all those years ago.
ReplyDeleteStill works today! Thank you so much.
ReplyDeleteThank you so much Neil! Even now your fix is still awesome!!!!
ReplyDelete