These are the steps to troubleshoot autoenrollment problems. The basis for this article was produced by a veteran field troubleshooting engineer, Roger Grimes. The article assumes that certificates that a user or machine should be receiving automatically from an issuing CA server on the network are not showing up in the end-users’s certificate store (i.e. Personal store in the Certificates console (certmgr.msc)).
First Make Sure:
  • Issuing CA’s computer account is in Cert Publishers group for the domain (can verify using Active Directory Users and Computers)
  • Effective GPOs have Autoenrollment turned on
  • User or computer has Read, Enroll, and Autoenroll permissions on the certificate template being requested
    • You can run certutil.exe –Template when logged in as the end-user to see if the end-user has Read and Enroll permissions (but it will not reveal which certs the user has Autoenroll permissions to)
  • Make sure certificate request isn’t pending or failed status in Certification Authority console. 
Verify that Autoenrollment is turned on:
  • View appropriate effective GPOs (using Active Directory Users and Computers or the Group Policy Management console)
  • On the user’s computer, run rsop.msc and check both user and computer configuration objects,
  • Rsop results will only show what was pushed by GPOs, not what actually was applied.
  • To see that autoenrollment is actually turned on the computer, check the following registry keys for a DWord value of 7 in AEPolicy:
    • HKCU\Software\Policies\Microsoft\Cryptography\AutoEnrollment (for user certs)
  • HKLM\Software\Policies\Microsoft\Cryptography\AutoEnrollment (for PC certs)
If no values are there, check the non-GPO locations (but it means AD GPOs are not working):
  • HKLM\Software\Microsoft\Cryptography\AutoEnrollment
  • HKCU\Software\ Microsoft\Cryptography\AutoEnrollment
If none of these keys have AEPolicy = 7, Autoenrollment is not turned on.
Forcing Autoenrollment and Viewing Results If previous steps above are set correctly, force Autoenrollment and look into Application log to see what happens when Autoenrollment takes place.
First, set  new registry key to turn on more detailed autoenrollment auditing:
In HKCU\Software\Microsoft\Cryptography\Autoenrollment and HKLM\Software\Microsoft\Cryptography\Autoenrollment, create a new DWORD value named AEEventLogLevel and set its value to 0.
Open up Application Log in Event Viewer (eventvwr.exe).
Force Autoenrollment:
gpupdate /force
In the Application event log, refresh the log to see what happens during autoenrollment.
Two computer autoenrollment messages (start, stop) should occur first, followed by two user autoenrollment messages (start, stop) in 30 sec. – 2 minutes. Any issued certs should appear in the log as Event ID 18’s or 19’s. Stop and Start messages are event IDs 2 and 3.
If there are any valid autoenrollment certificates to be issued, they should issue here.
Note: If the CA administrator configured the templates to not duplicate certificates if one already exists in Active Directory, you will have to delete the user’s certificate in Active Directory in order for Autoenrollment to pull down a new certificate.
To Troubleshoot GPO Errors
If you do see any GPO errors, you can turn on Group Policy logging on the client. Trigger Group Policy manually (gpupdate /force). Then check the policy log.
For XP:
-          Set the following registry flag:
  • Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
  • Flag - DWORD: UserEnvDebugLevel
  • Value: 0x00030002
-          Rename the current GPO log file, userenv.log, to userenv.old
-          Run the following in a CMD prompt as the user: gpupdate /force
-          Check the following log file for any errors: %windir%\debug\usermode\userenv.log