Systems Server OS - Windows 2003 R2Root CA OS- Windows 2003 Enterprise RootDesktop Systems OS - Windows XP SP2 (Global Standardized Build enforced with SCCM and Group Policy)SCCM 2007 SP1 R2Active Directory - Single ForestPatch level - Current to September 2009 User Account Rights Least Privilege by design - User accounts are standard Users with Domain Privileges. Scenario and SituationAll users (~23K) have auto-enroll/renewal certificates used for authentication, EFS and internal S/MIME from internal CAThere is a small group of users out of 7000 total who have their Certificate Store corrupted. These 7000 make up a portion of the field base staff, These 7000 are unique in the following ways. There are about 40-60/year who experience this problem.1. They are totally field based.2. They rarely if ever complete a standard login process from their standardized XP builds. The Juniper VPN connection uses the User Certificate and AD credentials for authentication.3. All AD password changes are completed through a manual process and notification does not utilize the standard domain expiry notifcation4. All group policy is enforced via either a scripted GPUPDATE /Force or normal policy updates. Symptoms and indicators+The problem does not become evident until the certificate is up for renewal. The certificate does not autorenew. The device can ping the CA but cannot manually renew.+Review of GPResult and Policy logs indicate Group Policy enforcement failure+In some instances, the Globally Recovery Agent (DRA) is missing from some of the files encrypted with the user certificate. This renders the Global Recovery Certificate useless.+In some instances, the User certificate disappears and must be reapplied from the CA. Once applied, the certificate store must be repaired using CertUtil and the private key reassociate with the public key.+In some instances, the User certificate disappears and cannot be reapplied from the CA or repaired using CertUtil. This renders all files which do not have a DRA associated unaccessible.+In many instances the new User certificate provisioned disappears after applied. Certificate store repair using CertUtil does not work either. Existing Solution and work around.1. Decrypt all files possible 2. Move user to duplicated new profile with new decrypted files3. In some instances, the only solution is deletion of NTUser.dat and allow new creation of profile4. Have user continue work. Comment: If the user logs in to the network even on a irregular basis, 90-180 days,the problem is not found Assumed cause:The indicators are a corrupt delivery or implementation of Group Policy. Requested assistance:+ Help identify the trigger which may cause certificate store corruption and/or Group Policy corruption.+ Identify options other than certutil -repairstore for certificate store resolution+ Identify options of reapplying GRC/DRA when it is absent from a EFS encrypted file. NOTE: In all instances, the file was encrypted with a Root CA provisioned cert, and the certificate store private key associate with the provisioned cert is missing.Core question which I think I know the answer: Is it a difference how Group Policies are applied during login vs. general update? Or am I missing something?Any Suggestions gladly accepted.

This sounds like a very esoteric problem, at least I've never seen nor heard of a similar problem. I'd suggest that your best hope of a resolution is to open a case with CSS.Paul Adare CTO IdentIT Inc. ILM MVP

Quite similar problem. After DC migration from W2000 to W2008, certificate stores in some PC users with W2000 prefessional have became corrupted, I mean, it's not possible export user certificates with the primary key. Everything points to the corruption of the certicate storage. Applying steps explained at article 943358, in some users the restore have been successful, but not in other ones. Maybe the problem come from other side, but chage in the DC's is a great coincidence. Thanks for any usefull suggestion.

Problem discovered! Thanks to this article: http://support.microsoft.com/?scid=kb%3Ben-us%3B309408&x=15&y=8 Is not a problem with the certificate store. Is a problem with the DPAPI, and some kind of password validation against the domain controllers. The real problem is in the authentication with de W2008 DCs. Good luck