Hey everyone, Theron (aka T-) here, Senior Consultant with Microsoft Consulting Services (MCS) specializing in Active Directory, amongst other technologies, including Advanced Group Policy Manager (AGPM).
Have you ever deployed a GPO via AGPM only to experience either of the two situations?
- EventID 1058 (GroupPolicy) in a client’s System log
or
- The follow message when using ‘gpupdate’ on a client:
The actual details included in the message returned by ‘gpupdate’ will differ depending on the version of Windows you’re using.
So, what’s the message telling us? Well, it’s pretty self-explanatory…the gpt.ini file located in \\<domain.fqdn>\SysVol\<domain.fqdn>\Policies\{7F2C98CE-3BEE-4CDB-A815-DEF1E2897706}\ is missing. {7F2C98CE-3BEE-4CDB-A815-DEF1E2897706} is the GUID of the GPO in question, so it will obviously differ in each situation.
Now, what happened? Well, that’s the tricky part and I have yet to find an actual cause to the situation. From my research and discussion internally with colleagues at Microsoft, no one else has either. Frustrating, right? Fear not, we may have found a viable work around to prevent it.
In case you didn’t know or think about it, simply re-deploying the policy in question via AGPM usually solves the current GPO’s file issue.
Workaround that may work for you:
I currently support a customer who is dealing with this issue just about every time they deploy a policy. It had gotten to the point that each time a deployment was executed, the person deploying the policy would have to check the GPO folder in SYSVOL to make sure the gpt.ini file was there. Doesn’t sound very efficient, does it? Yeah, I agree.
During some “let’s throw darts at the wall and see what sticks” troubleshooting of this problem, we decided to create an AD DS Site containing one domain controller and put the AGPM server into that site. Basically, we created an AD DS Subnet with one IP address (/32), that of the AGPM server, and assigned it to the newly created site. The thought process was to eliminate the use of any additional domain controller in the original Site the AGPM server was a member of; there were four. The next thing we did was ensure the GPMC being used for deployments during our testing was using that domain controller.
Well, wouldn’t you know it, the issue hasn’t occured since. Each subsequent deployment of policies has yielded the expected results…the GPO works and no issues on the clients! We’re still evaluating and monitoring the situation and yes, SYSVOL is still being checked after each deployment. Once we’re confident the issue is gone, hopefully that won’t have to happen.
The next step on our list of things to do is to move the FSMO roles, more importantly the PDCe to the domain controller for the AGPM Site. Since GPMC defaults to the PDCe, unless changed, by moving it to the AGPM Site, each time a policy is deployed, the domain controller in the AGPM Site will be used. For those of you that don’t know, the AGPM server will randomly pick a domain controller in its AD DS Site when you’re managing policies vs. using the domain controller your GPMC is using. Weird, huh?
Well, that’s all for now. If we have any further development with our testing, positive or negative, I’ll make sure to provide an update.
Roll Tide!
T-