Written by I recently assisted a customer with an issue where users where unable to connect to Citrix on the thin clients. The problem seemed to be related to an error on the server stating that group policy could not be processed on the computer. There was an error that pointed to not being able to access the GPT.ini file associated with a GPO and that GPO processing stopped at that point. So I opened up Windows Explorer and pointed it to \\domain.com\SYSVOL\domain.com\Policies and discovered the GPO GUID didn’t exist. I guessed that someone accidentally deleted the GPO folder and suggested they unlink the current one (the one flagged as not processing), create a new GPO with the same settings and then link the new one to the OU. While they were doing that, I dug a little deeper. I opened Windows Explorer and pointed it to \\DomainDC02\SYSVOL\domain.com\Policies and discovered the GPO GUID didn’t exist. However, when I went to \\DomainDC01\SYSVOL\domain.com\Policies the GPO GUID did exist. Aha! I logged onto DomainDC02 and restarted the NTFRS service (Powershell: restart-service ntfrs). I checked the FRS log and sure enough – Journal Wrap.
Microsoft describes FRS as follows:
“FRS is a multi-threaded, multi-master replication engine that Windows Server 2003 and Windows 2000 domain controllers use to replicate system policies and logon scripts for Windows Server 2003, Windows 2000, and earlier-version clients. In Microsoft Windows NT, the LanMan Replication (LMREP) service handled replication. FRS replaced LMREP in Windows 2000. You can also use FRS to replicate content between Windows 2000 servers that host the same fault-tolerant Distributed File System (DFS) roots or child node replicas.”
FRS monitors all changes to the NTFS file system and is interested in any updates to files that is in the SYSVOL folder structure. When a file/folder update occurs in the SYSVOL folder, it is logged in the NTFS Journal. FRS keeps its own log to keep track of what NTFS updates it knows about. So, if the NTFS Journal has performed modification #152, FRS checks its log to see if it has a record of 152 and then if it is contained in the SYSVOL folder structure. If it is, then FRS stages the change and then replicates it to a SYSVOL replica, aka a Domain Controller. The problem comes in where FRS is stopped for a while due to low disk space (the issue I encountered), system failure, the service was stopped and never restarted, or some other reason the FRS service stopped running. Once it starts up again, it checks the NTFS Journal for the last update number. If the last update number is beyond the number range FRS has in its log, a Journal Wrap occurs since FRS can’t be certain that all updates have been properly processed. When FRS is in a Journal Wrap state, it stops replicating since SYSVOL is inconsistent on that server and no longer advertises SYSVOL as Ready.
Journal Wrap means that changes on this DC may be lost since the SYSVOL on this DC needs to be recreated. That process is detailed in Microsoft KB #290762 (the infamous Burflags article). KB 290762 describes how to set a registry key (Burflags) to D2 to resolve a SYSVOL problem on a single DC (typical Journal Wrap scenario) or to set it to D4 to wipe SYSVOL throughout the domain (make sure you have a good backup to restore SYSVOL afterwards).
I freed up space on the server’s drive hosting SYSVOL (the root cause – the drive had only a few MB free) and followed article KB 290762 to set burflags in the registry to D2. This reinitialized SYSVOL on the problem DC (DC02) and fixed the issue.
When I went back to \\DomainDC02\SYSVOL\domain.com\Policies everything was there. I also checked \\domain.com\SYSVOL\domain.com\Policies and all was right with the world. Running gpupdate on the server showed that GPO processing occurred successfully.
Key takeaways from this:
- Monitor your servers.
- Monitor your servers and use the monitoring product – at least glance at it once a day.
- Check your servers regularly for volumes low on drive space – Monitoring is a great way to do this.
- Did I mention monitoring?
- Don’t put a lot of junk in SYSVOL. This is not the place to store files you want to access from anywhere. That’s what DFS is for.
