If none of these keys have AEPolicy = 7, Autoenrollment is not turned on.
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
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).
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.
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.
Set the following registry flag:
Rename the current GPO log file, userenv.log, to userenv.old
Check the following log file for any errors: %windir%\debug\usermode\userenv.log
Man you are all over these guides Kurt (from the AD guides to this one). Nicely done!
Thank you, Mike. I am glad to be helpful.