Author Posts

February 20, 2017 at 3:20 pm


I`have been working with DSC to automatically deploy and configure Exchange servers. Since our future Exchange environment has to be installed on Windows 2012 R2 I am limited to WMF4 (WMF5 is not supported on Windows 2012 R2 and Exchange 2013/2016 -> the Exchange management Shell breaks)
Deploying and configuring Exchange in a pure WMF4 or pure WMF5 (DSC host and target nodes have the same version) everything is working fine, either in Pull or Push mode.
Once I start mixing the WMF enviornments (DSC host = WMF5 & target node = WMF4), the target node can´t decrypt the credentials anymore.

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = PerformRequiredConfigurationChecks,'className' = MSFT_DSCLocal
ConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer S099-01-01151 with user sid S-1-5-21-1134438006-2143739420-97094743-500.
VERBOSE: Executing Get-Action with checksum: DA3803295709FE154A8C80002CBE538E6B09DF5016B29FACD5C2633F2E538579.
VERBOSE: Executing Get-Action returned result status: GetConfiguration.
VERBOSE: [S099-01-01152]:                            [] Checksum is different. LCM will execute GetConfiguration.
VERBOSE: [S099-01-01152]:                            [] Configuration document is pulled from server.
VERBOSE: [S099-01-01152]:                            [] Applying the configuration document pulled.
VERBOSE: [S099-01-01152]: LCM:  [ Start  Resource ]  [[xExchWaitForMailboxDatabase]WaitForDB.DAG1DB2]
VERBOSE: [S099-01-01152]:                            [] Executing Get-Action returned success but didn't return any status.
Decryption failed.
    + CategoryInfo          : InvalidArgument: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : Windows System Error 87
    + PSComputerName        : s099-01-01152

VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 1.839 seconds

I configured the certificates according the guidleine:

I know that the way the mof files are encypted has been chaned with version 5.

WMF4 MOF file password section:

instance of MSFT_Credential as $MSFT_Credential1ref
Password = "nMIIB5gYJKoZIhvcNAQcDoIIB1zCCAdMCAQA......

WMF5 MOF file password section:

instance of MSFT_Credential as $MSFT_Credential1ref

Questions: Can a WMF4 target node decrypt the password in a MOF file generated by a WMF5 host? Is there a backward compatibility? If not, what is the recommended way to workaround this issue?

February 20, 2017 at 3:30 pm

Yeah, there were some changes to the way the certificates were handled in v5, including the DocumentEncryption purpose in the certificate itself. I'm not sure there _is_ a workaround for this; a lot of the v5 stuff did, in fact, break backward compat.