[INFO] Certificate Services fail to start after installing CM CA Modules

Issue

Upon installation of the FIM CM certification authority modules the certificate services fail to start. The following event is logged in the FIM Certificate Management event log on the CA.

Log Name:      FIM Certificate Management

Source:        FIM CM CA Modules

Date:          12/23/2013 2:45:42 PM

Event ID:      0

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      CA02.contoso.com

Description:

"2013-12-23 14:45:42.62 -05"        "Microsoft.Clm.PolicyModule.Policy"        "Void Initialize(System.String)"        ""        "NT AUTHORITY\SYSTEM"        0x000007E0        0x00000001

 

 

1) Exception Information

*********************************************

Exception Type: System.Runtime.InteropServices.COMException

ErrorCode: -2147467260

Message: Cannot copy registry settings from the default Policy Module. Registry location: SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\CONTOSO CA 01\PolicyModules\Clm.Policy.

Data: System.Collections.ListDictionaryInternal

TargetSite: NULL

HelpLink: NULL

Source: NULL

 

Troubleshooting and Cause

In the event log the registry path from the error had the CA name of CONTOSO CA 01. The CA name was actually CONTOSO CA 01A. The certificate services were originally installed as CONTOSO CA 01. The server was subsequently reinstall with the CA name of CONTOSO CA 01A. There was also an HSM attached to the CA.

The crux of the problem appeared to be the CM policy modules being written to the incorrect registry path, using the old name.

Much troubleshooting was done to discover from where the incorrect CA name was being found and put into the registry. Using verbose MSI logging along with Process Monitor logs the FIM CM module installer never referred to the incorrect name. While exonerating FIM CM the culprit was still undiscovered.

 

Research found that the CA names may be obtained from active directory. A search of the Enrollment Services container in AD uncovered two pKIEnrollmentService objects. One object with the original (undesired) name and the current name exist in the container.

CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

  • CN=CONTOSO CA 01,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com
  • CN=CONTOSO CA 01A,CN=Enrollment Services,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com

 

Remediation

Removal of the invalid pKIEnrollmentService object alleviated the issue. As long as no active CA object is removed there should be no CA issues. Only an orphaned object was removed.