Hi all,
We are currently investigating an issue with the delivery of enterprise root and intermediate certs and I'm interested to know if others have encountered this problem.
We deployed an offline root CA and Enterprise subordinate CA back in June.  Following the deployment we did some limited manually verification that the certs published in AD were successfully delivered to the enterprise physical cert stores (root and intermediate) on domain member machines as expected.
Recently we swapped some of our Lync infrastructure over to internally issued certs and found a number of machines which are missing the root certificate from the trusted root store and the root and issuing CA certs missing from the intermediate store.  As far as we can tell these machines share the same OU, software, policies, etc. as other machines which have received and maintained the root and intermediate certs.
After a call or two with MS they suggested just clearing HKLM\SOFTWARE\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache which forces the member computers to check for new enterprise CAs. This key apparently keeps track of the USN associated with changes to the enterprise CA objects in AD.  Either clearing the value or changing the CA objects in AD forces the clients to check for updated CAs at the next GP refresh/autoenroll interval.
This fix seems to resolve the issue on an ad-hoc basis but I'm more concerned with how we ended up here to begin with.  Has anyone else experienced this or something similar?  I'm curious how the client would be able to successfully retrieve the USN values corresponding to the most recent CA changes but be missing the corresponding certs from the local stores.
The interwebz has offered a mixed bag of info, including just send the certs down via GPO and be done with it. Before doing so I'd prefer we better understand the root cause and at this point MS has not been able to offer any insight.
I'm really interested to hear what others' experiences have been.  Thanks!
-matt