This is a scenario I ran into, so thought it was worth noting the steps.

I’d pushed out an environment variable in Group Policy Preferences, but a particular person hadn’t got it. I’d confirmed this by running the ‘set’ command on their PC and the environment variable wasn’t listed (shortcut on this, if you use ‘set x’ with x = the first letter of the environment variable, it will only show those with that first letter. ‘set u’ is a quick way to see who’s logged on under the ‘username’ variable’).

After confirming they didn’t have this new variable, I tried to refresh Group Policy with the ‘gpupdate /force’ command. Alarm bells went off when I saw this result:

The processing of Group Policy failed. Windows attempted to read the file \\fakedomain.com\SysVol\fakedomain.com\Policies\{389D2400-A8FE-44CD-B7B7-3914920183F8}\gpt.ini from a domain controller and was not successful. Group Policy settings may not be applied until this event is resolved. This issue may betransient and could be caused by one or more of the following:
a) Name Resolution/Network Connectivity to the current domain controller.
b) File Replication Service Latency (a file created on another domain controller
has not replicated to the current domain controller).
c) The Distributed File System (DFS) client has been disabled.

The important part of that was that it was unable to read a gpt.ini file. I followed the path specified in the user’s context still – the path under Policies didn’t exist! SysVol is normally a DFS share, so I tested for myself and the path existed. What was different between me and them? Lots probably, but I was at a different site connecting to a different DFS server.

Going to the properties of any folder in that DFS path, you can change the server you’re pointing to:

This way you can toggle back and forth. From this, I confirmed that one DFS server was missing the folder in question, along with a lot of others.

From that, I RDP’d to the server and had a look in Event Viewer > Applications and Services > DFS Replication to see if there were any errors or warnings. There was a few warnings around losing connectivity, so I decided to restart the DFS Replication Service to see if it just needed a kick:

After restarting, it was back to Event Viewer to see if it was happy or not. It was not.

Event 2231 DFSR:

The DFS Replication service stopped replication on volume C:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.

Additional Information:
Volume: C:
GUID: 992BDBB2-4593-11E3-93E8-806E5F6E6963

Recovery Steps
1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders.
2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:
wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid=”992BDBB2-4593-11E3-93E8-806E5F6E6963 ” call ResumeReplication

For more information, see http://support.microsoft.com/kb/2663685.

That was nice, it was giving me the exact command to run to fix it, which I did. This showed the next problem in Event Viewer:

Event 4012 DFSR:

The DFS Replication service stopped replication on the folder with the following local path: C:\Windows\SYSVOL_DFSR\domain. This server has been disconnected from other partners for 73 days, which is longer than the time allowed by the MaxOfflineTimeInDays parameter (60). DFS Replication considers the data in this folder to be stale, and this server will not replicate the folder until this error is corrected.

To resume replication of this folder, use the DFS Management snap-in to remove this server from the replication group, and then add it back to the group. This causes the server to perform an initial synchronization task, which replaces the stale data with fresh data from other members of the replication group.

Additional Information:
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: SYSVOL Share
Replicated Folder ID: 0CD8DE8C-6293-4640-8911-67FCEBE60CD1
Replication Group Name: Domain System Volume
Replication Group ID: F84F2F63-3623-4911-B7B7-FBBD8968DBFE
Member ID: A45C340E-F890-4FD9-9FE5-9E38DB4EB590

Yikes, older than 60 days and nobody had even noticed. This can get tricky to try and remove and re-add a SYSVOL share, so it’s worth changing the MaxOfflineTimeInDays value. I set it to 300 with this command:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=300

After that, restarting the DFS Replication service and running the previous command from Event Viewer did the trick. It started syncing up and from looking in the Policies folder, I could see more folders turn up, including the original missing one from the gpupdate command.

Waiting a few minutes for this to stop, I changed the MaxOfflineTimeInDays value back to the 60 default.

Going back to the original user, running ‘gpupdate /force’ worked without any errors, and after a reboot, the missing envrionment variable being pushed by Group Policy Preferences had deployed.

Now on my ‘things to do’ list, is to work out DFS replication monitoring to resolve this in a lot less than 60 days! :)