Justin Chalfant's Blog

Justin Chalfant's Configuration Manager Blog

Build and Capture in HTTPS only ConfigMgr 2012 R2 Environment

Build and Capture in HTTPS only ConfigMgr 2012 R2 Environment

  • Comments 7
  • Likes

I often run into customers that have HTTPS only Configuration Manager 2012 environments. This will make communication between client to site system servers more secure, but it does bring a new set of challenges regarding certificates. There was a good post my James Bannan about provisioning a certificate into the build and capture machine (Workgroup Client) during a build and capture task sequence Here. This shouldn’t be required in 2012 R2 though since the build and capture machine can pass the certificate from the boot image (WinPE phase) in the full OS parts of the task sequence as well.

This post goes over some issues that I encountered as well as how I successfully ran a build and capture with updates and applications in a HTTPS only ConfigMgr 2012 R2 environment.

Failed attempt at Build and Capture in HTTPS only environment and troubleshooting:

The first attempt of a build and capture in my HTTPS only lab, I used the following properties in the Setup Windows and Configuration Manager step: FSP=CM12PR1.CONTOSO.LOCAL SMSMP=https://CM12PR1.CONTOSO.LOCAL CCMDEBUGLOGGING=1 CCMLOGLEVEL=0 CCMLOGMAXSIZE=52488000 CCMLOGMAXHISTORY=5

The SMSMP is required for build and captures because without it the client will not be able to find a management point (Capture machine does not join a domain so we can’t look at Active Directory in our lookups). The other parameters are enabling debug logging. I enabled that because I was excepting to see some issues during the first attempt.

This did not work the install updates piece didn’t find any updates and the application failed with 87D00269 (Required management point not found). However, I did find some clues with debug logging on why it was failing in the following logs.

CcmMessaging.log

CRLFailure

This is probably the most useful of all the logs to give us a clue as to why we aren’t able to communicate with our site.

WINHTTP_CALLBACK_STATUS_FLAG_CERT_REV_FAILED basically means we aren’t able to access the Certificate Revocation List. In my lab, My CRL is not accessible to any non-domain machines.

Full Description: This error happens when CRL checking is enabled on the client, but the CRL cannot be accessed. The CRL (certificate revocation list) is what the client downloads in order to verify that the certificate for the MP, DP, or other SSL-capable site role hasn't been revoked by the administrator. When this isn't accessible, the client is blocked from communicating until it can download this list (a better safe than sorry approach). The ways to fix this are: make CRLs available to the client (could be challenging for Internet clients); publish additional CRLs that the client can access (this will require publishing new certificates to SSL site roles since CRLs are stamped in the certificates themselves; turn off CRL checking on clients. This is an infrastructure error.

0x2f8f - A security error occured

0x2f8f translates to “A security error occurred”

87d00231 - Transient error

0x87d00231 translates to “Transient error”

LocationServices.log

Failure

We aren’t able to send any request to the MP in LocationServices

Option 63

The Options=63 in this snippet if referring to the CCMHTTPSSTATE 63. 63 means that CRL checking is enabled.

So this led me to believe the client isn’t able to communicate to the site because it is unable to check any CRL.

I changed the Setup Windows and Configuration Manager installation properties to: /NoCRLCheck FSP=CM12PR1.CONTOSO.LOCAL SMSMP=https://CM12PR1.CONTOSO.LOCAL CCMDEBUGLOGGING=1 CCMLOGLEVEL=0 CCMLOGMAXSIZE=52488000 CCMLOGMAXHISTORY=5

Obviously, I wasn’t thinking here because the Setup Windows and Configuration Manager can only set MSI properties so I noticed this was ignored in the ccmsetup.log

CCMSETUP

You can also see that CCMHTTPSSTATE=63. This is requiring CRL checking so the /NoCRLCheck didn’t help us.

Steps for successful build and captures in HTTPS only environment:

Now that we know the issue was related to CRL checking we can fix this. Since we can’t specify the /NoCRLCheck in the Setup Windows and Configuration Manager step we will need to set the CCMHTTPSSTATE MSI property.

The new parameters in the build and capture that worked is: FSP=CM12PR1.CONTOSO.LOCAL SMSMP=https://CM12PR1.CONTOSO.LOCAL CCMHTTPSSTATE=31 CCMDEBUGLOGGING=1 CCMLOGLEVEL=0 CCMLOGMAXSIZE=52488000 CCMLOGMAXHISTORY=5

I added the CCMHTTPSSTATE=31 value to the properties. The 31 value state is HTTPS enabled with no CRL checking.

Things are now looking much better in the logs!

ClientLocation.log: Note the SSLState is 31 (No CRL Check)

Current Assigned Management Point is CM12PR1.CONTOSO.LOCAL with Version 7958 and Capabilities: <Capabilities SchemaVersion="1.0"><Property Name="SSL" Version="1"/><Property Name="SSLState" Value="31"/></Capabilities>

CcmMessaging.log: No issues when sending request to the MP

POST: Host=CM12PR1.CONTOSO.LOCAL, Path=/ccm_system_altauth/request, Port=443, Protocol=https, Flags=512, Options=31

ClientLocation.log

Client is now successfully assigned to site 'PR1'

Setting current Management Point as HTTPS://CM12PR1.CONTOSO.LOCAL

CertificateMaintenance.log

HTTPS is enforced for Client. The current state is 31.

Successfully created certificate

ContentTransferManager.log (This is successfully getting updates/application location on DP)

Started downloading from new location 'http://CM12PR1.CONTOSO.LOCAL/NOCERT_SMS_DP_SMSPKG$/28e56421-c61b-4b6f-969a-fe3d6a233b73'

Started downloading from new location 'http://CM12PR1.CONTOSO.LOCAL/NOCERT_SMS_DP_SMSPKG$/Content_1b7bee2d-050a-47ac-b91b-b87d94b50875.1'

After changing the CCMHTTPSSTATE=31 property, I was able to successfully install all updates targeted to the capture machine and any applications!

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Comments
  • Great stuff!

  • Hi. Do you have anymore info on how the build and capture machine "can pass the certificate from the boot image (WinPE phase) in the full OS parts of the task sequence"? I can not quite get this to work. Is there a special step I need to have in the TS? If I understannd correctly you say that we dont need to copy the certificate to the Client during the TS, we just use the certificate that we import during creation of the Task Sequence Media?

  • @ Roger, you shouldn't have to do anything. It should pass it along for you what exactly is happening?

  • Please disregard my question. I forgot to uncheck the checkbox for "unattend or sysprep answer file" in the "apply os" step. I used that option to import the certificate following James Bannans article for Pre R2 installations. That must have broken something related to the certificate. Now this is working Out of the Box as you said. Thank you for sharing.

  • As I also run against this issue, I am very happy with this post. But alas, after setting the CCMHTTPSSTATE to 31 in the task sequence, I still see the options=63 in the locationservices.log. Why doesn't it work? I'm running SCCM R2.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment