Service configuration stopping with credentials

I am testing a configuration (using PUSH mode) which configures two windows services on a server (along with many other things) including credentials. I have setup a certificate for encrypting the credentials and followed what I believe are all the steps to do this. Pushing the config produces a strange result where the credentials for the first service work correctly but the second service fails and the configuration stops. Both services are being configured with the same credentials that are being inputted once when the MOF files are created.

I can’t find anything useful in the DSC configuration logs and the error in the console looks pretty generic…

VERBOSE: [TESTN4APP01]: LCM: [ Start Resource ] [[Service]svc_Node2_name::[N4_Common] ]
VERBOSE: [TESTN4APP01]: LCM: [ End Set ]
The SendConfigurationApply function did not succeed.
+ CategoryInfo : InvalidArgument: (root/Microsoft/…gurationManager:String) [], CimException
+ FullyQualifiedErrorId : MI RESULT 4
+ PSComputerName : testn4app01

One thing I’m unsure about is the LocalConfigurationManager shows the configured certificate thumbprint prefixed with a “?” eg:

CertificateID : ?db27ee7410b3ba43c16b382a076d55183685f43c

Is this normal for the CertificateID? I’ve double checked the config and meta MOF and the strings look correct. Has it been mangled and are there any other logs that will hint at what the issue is with decrypting the credentials?

Have you done any troubleshooting?

For example, can you push a config that only attempts to configure Service B, to see if that works? If you can individually configure Service A and Service B, but not together, that’s useful information. If you can’t configure Service B on its own, using the same approach that works for Service B, then it’s less likely the problem is in DSC and more likely something to do with that service.

So before we chase things in DSC, let’s try and verify that it is indeed DSC.

And, no, I’m not accustomed to seeing the certificate thumbprint preceded with a question mark.

Also, make sure you’re using the DSCDiagnostics module (from the DSC Resource Kit) to start a diagnostics trace. Those log details can be a lot more meaningful.

I’ll check out the DSCDiagnostics module. I had tried changing the DSC configuration by removing the Credentials property and using the Builtin property to see if the services would work and they did. I’m pretty confident the issue isn’t with the services but with the credentials in DSC. I’ll try a test config to configure just the second service on its own as well just in case.

I had a similar problem. I had copied pasted the cert thumbprint into my configuration script, and somehow it was adding sometype of ascii character to the front.

Try manually typing it in there and see if that works.

Thanks Jim, yes copying and pasting was what was creating the question mark in the thumbprint. Didn’t solve my problem but I did stumble over a solution.

The Service resource (I’m not using the xService resource yet) seems to by default attempt to start the service. It was timing out on starting the first service (that was getting its credentials configured) after two seconds but would then carry on the configuration as normal.

I decided to set the service state in the config to be “Stopped” and then re ran the config, blow me down if the second service is now configured with the credentials and the DSC configuration run continues on with the rest of operation.