It started with an alert from System Center Operations Manager about a failed scheduled task. Of course, the alert references a task name that looks like a SID. Running schtasks /query show a few jobs with a status that warranted inspection. Looking at the Microsoft-Windows-TaskScheduler/Operational log I found that the task “\Microsoft\Windows\CertificateServicesClient\UserTask” is the one the failed and triggered the alert.
I also noted that there were some Group Policy processing errors occurring at about the same time as the task failure, including a problem applying the Group Policy Scheduled Tasks settings. And the failing task starts at user login.
Next, I ran gpresult /h to create a report of the GPOs and settings that applied, and any errors that were generated. The report confirmed that there were failures in applying the Group Policy Files settings and the Group Policy Scheduled Tasks settings.
Some web searching turned up this thread, among others, which pointed me to the Group Policy History files in C:\Users\All Users\Microsoft\Group Policy\History. This directory contained four subdirectories named with the GUIDs for the corresponding GPOs. I was able to find three of the four GPOs by inspecting the details in the GPMC, but I couldn’t find the fourth.
I decided to search more programmatically, and started with an LDAP search with ADFind:
adfind -f "&(objectClass=groupPolicyContainer)(Name={DC257675-89C1-5AA6-5F65-B5D5CFC35E17})"
0 Objects returned
Then, just to be sure, I used the PowerShell GroupPolicy module:
PS Z:\> import-module GroupPolicy
PS Z:\> get-gpo -guid "{DC257675-89C1-5AA6-5F65-B5D5CFC35E17}"
Get-GPO : A GPO with ID {DC257675-89C1-5AA6-5F65-B5D5CFC35E17} was not found in the campus.ad.uvm.edu domain.
So I removed the subdirectory with that name from the GP History directory, and retried gpupdate /force. This time, it completed successfully.
