Active Directory Domain Services unable to establish a connection with Global Catalog
As part of my lab setup, I used to run an older physical server which was my Primary Domain Controller and file server. This server also owned all the FSMO roles. In addition to this DC, I also had another virtual DC. All was going well until the hardware finally gave up, and I couldn’t boot the server any more. I said OK, nothing to worry about, I’ll just move all FSMO roles to the virtual DC, and clean up the Active Directory. Only to find out that the AD on the virtual DC was unable to start properly, and I had no access to AD or DNS.
There were 2 events in the Active Directory Domain Services log that seemed to be most relevant to the issue. The first event was a warning Event with ID 2092:
This Server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role. Operations which require contacting a FSMO operation master will fail until this condition is corrected.
The second event was an error event with ID 1126:
Active Directory Domain Services was unable to establish a connection with the global catalog.
Additional Data
Error Value:
1355 The specified domain either does not exist or could not be contacted
Initially I tried all the usual tricks, even doing a full system state restore, but every time the result was the same. At the time, I had other priorities and left the thing to sit for a while. As I had no investment in the existing AD, I even considered to just scrap the whole AD, and deployed a fresh one. But that didn’t feel quite right. Eventually, I returned to it and after a lot of searching around I came across a response to a fairly obscure post that suggested to make a registry change:
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Set SysvolReady from 0 to 1, restart Active Directory Domain Services, and voila, all is back to normal.
And as life happens, shortly after I managed to find the solution to my problem, i was asked to assist with an exact same scenario, but this time it was a production system. This time it was easy just to check the Registry for the SysvolReady key, and have the system back operational in no time.