Additional ConfigMgr Post Restore Step

After performing a System Center Configuration Manager (ConfigMgr) Current Branch (CB) site restore with a customer recently, I started noticing a lot of the following error message in distmgr.log:

 Failed to decrypt cert PFX data

The number of occurrences corresponded with the number of distribution points in the environment before the restore but gave no further details or insight into what was going on. No actual functionality seemed to be affected but having this message reoccur 40+ times periodically certainly makes distmgr.log hard to follow and it doesn’t look good to the customer either. Cranking up the debug logging and log level for distmgr.log didn’t add any detail either.

After a fruitless web search that revealed nothing truly related I resorted to asking my friends in high places: the product group. They initially responded with a few things to look at but so did another friend from another high place: Kent Agerlund. Kent suggested that the message had to do with the certs assigned to the DPs and the fact that a site restore does not restore stored passwords. This implied that the certs were lost and needed to be re-created or in the case of an HTTPS DP with a PKI issued cert, reimported.

So based on this info, I set out recreating the certs for each DP since this site was fully HTTP. I did this by opening the properties for each DP and changing the expiration date of the self-signed certificate. This doesn’t really change the expiration date of the existing cert (as that’s not possible) but instead blocks the existing certificate in ConfigMgr and creates a new one with the newly entered expiration date (once you hit OK or Apply of course). Slowly but surely as I made my way through the DPs and the number of times the above message occurred went down until it went away completely after updating the certificate on all of the DPs that existed before the restore.

There’s no direct way to automate creating these new certs so I did end up doing it manually. I think it could be automated using the technique that David O’Brien used in his post titled How to install new Distribution Point–SCCM 2012. Note that the latest PowerShell cmdlet library for ConfigMgr includes an Add-CMDistributionPoint cmdlet (with a CertificateExpirationTimeUtc parameter for use when creating the self-signed certificate) so most of what David did in this post is obsolete now. Unfortunately, the Set-CMDistributionPoint cmdlet does not include a similar argument to recreate the certificate.

On an HTTPS DP, you should only need to re-enter the password protecting the certificate file (assuming that the file still exists in the location specified).

Finally, I did suggest to the product group to add a better message to distmgr.log including which certificate it’s having problems with and to add info to the site restore documentation on handling this so hopefully that’ll happen sometime in the near future.