Build and Capture in HTTPS only ConfigMgr 2012 R2 Environment
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
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 translates to “A security error occurred”
0x87d00231 translates to “Transient error”
LocationServices.log
We aren’t able to send any request to the MP in LocationServices
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
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 'https://CM12PR1.CONTOSO.LOCAL/NOCERT_SMS_DP_SMSPKG$/28e56421-c61b-4b6f-969a-fe3d6a233b73'
Started downloading from new location 'https://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
- Anonymous
January 01, 2003
@Stephan sorry for the delay, Is CRL checking enabled in your site properties? If so, it's likely getting the policy from the MP to re-enable CRL checking. - Anonymous
January 01, 2003
The comment has been removed - Anonymous
May 08, 2014
Great stuff! - Anonymous
May 08, 2014
Pingback from Build and Capture in HTTPS only ConfigMgr 2012 R2 Environment | MS Tech BLOG - Anonymous
May 08, 2014
Pingback from Build and Capture in HTTPS only ConfigMgr 2012 R2 Environment | MS Tech BLOG - Anonymous
July 28, 2014
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? - Anonymous
July 29, 2014
The comment has been removed - Anonymous
August 21, 2014
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. - Anonymous
March 27, 2015
Great article and thought this might finally fix my issue but I was wondering if this is for a self signed certificate or using a PKI infrastructure? I tried these steps and I'm using PKI with a CA and at the application and Updates install it can't download the content. Basic error in Content Transfer Manager log is "encountered error 0x80072f0c" which based on google searches is a certificate error. - Anonymous
June 06, 2015
I have different error message when trying to do Windows 10 inPlace upgrade. WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA is set.. - Anonymous
December 30, 2016
Hi Justin,did you had a chance to verify if this still works on current branch 1610 ?- Anonymous
May 02, 2018
Hey, no I haven't tested it for 1610. I usually use MDT for Build and Captures these days.
- Anonymous
- Anonymous
January 04, 2017
Are you finding new issues connecting to MP after update to CB 1610? This was working 12/23 before upgrade.smsts.log:Policy Evaluation failed, hr=0x87d00269MP list missing in WMI after policy evaluationLocatioServices.log:LSGetLookupMP: Unable to find any lookup MP(s)LSIsSiteCompatible : Failed to get Site Version from all directoriesClientLocation.log:Failed in WinHttpReceiveResponse API, ErrorCode = 0x2f0c - Anonymous
January 05, 2017
This was working in Current Branch prior to 1610 upgrade. Have you run in to any issues?MDT integrated Windows 10 build and capture task sequence. Installs OS from ISO and install programs and applications before configuration scripts. System is never domain joined. Upgraded to 1610 last week and applications will no longer install during the task sequence. Programs will.smsts.log:Policy Evaluation failed, hr=0x87d00269MP list missing in WMI after policy evaluationSending message to location service to refresh client, retrieve MP list and try again (after delay of 120l sec - up to 1 times).Install application action failed: 'Firefox'. Error Code 0x87d00269LocationServices.log shows:LSDetermineManagementPointType: Failed to determine the type, if any, of [server.domain.LOCAL] (80004005)ClientLocation.log:Failed in WinHttpReceiveResponse API, ErrorCode = 0x2f0cWorkgroup client is in Unknown location. Default to internet to be conservative