This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
One feature I noted in Configmgr version 2010 was the option to be able to use OS deployment task sequence using boot media for Internet-connected clients, for example if they needed to be rebuilt / reimaged.
We use the token-based option in our Cloud Management Gateway which has been working well. I created the task sequence and the boot media, ensuring that the CMG was used as the management point. All good.
However, the boot media does boot, can see the CMG and attempts to get its necessary token from it in order to get the policies for the task sequence deployments, but returns this error, almost as if it's actually attempting PKI authentication to get the token when it doesn't need to:
Is this a limitation of using the token-based authentication that it cannot get a bulk registration token for OSD (and if so, does that need documenting) or are there any other suggestions which may be able to work around this issue?
If token-based wasn't working at all, then there'd be no communication between the CMG, the internal MP and clients - but comms for those are working fine with token-based auth.
Correct and I concur.
but would the CA also need to be visible in order for it to be reachable in terms of trust?
No specifically, no, however, the CRL for the CA needs to be accessible and that can be hosted in a variety of ways, one of which must be accessible. I don't believe there is a way to disable CRL checking during WinPE.
You may be able to add the cert from the internal root CA to your site's configuration (on the Communication Security tab of the site's properties). This is meant to add the CA as trusted on managed devices as well as within boot images although this was specifically designed for sites using HTTPS client communication, so I don't 100% know if it will work for this newer scenario. I think that it should, but I haven't tested explicitly. You will have to regen the boot image after adding the cert. And further, disabling CRL checking on this same page may also disable CRL checking in the boot image as well -- it does normally for the HTTPS client communication scenario but not sure for this scenario.
Here's a random screenshot from the web for reference in case you are not familiar with this property page: https://www.bing.com/images/search?view=detailV2&ccid=jwWIntbt&id=2D27B2A53759DBE7725E3FB4300EA443E9661D94&thid=OIP.jwWIntbt19DgotM5Cnr62AHaHH&mediaurl=https%3a%2f%2fsocial.technet.microsoft.com%2fForums%2fgetfile%2f1605721&exph=568&expw=591&q=%22Communication+Security%22+sccm&simid=608043979562289357&ck=704C8B3066F7C6706CBF4F2E8E41CFF6&selectedIndex=1&FORM=IRPRST&ajaxhist=0
Thanks for the feedback Jason, much appreciated.
In our case, CRL checking is already turned off and the root CA isn't specified (because we're not using PKI)
The boot image had been generated with those turned off already, but when attempting to retrieve the task sequence list, it communicates with the CMG using HTTPS and therefore fail.
I do think it may be a limitation with the way the token-based authentication works, because as you say the client in the boot image doesn't have a token to authenticate to the CMG against or that the CA is trusted either. I suppose you could attempt using a bulk registration token using a pre-start command, but I suspect actually if that was the case, an option would exist in the create task sequence media options to do that?
As noted initially, the actual issue here is completely unrelated to the token. It is 100% a certificate trust issue no different than you using a browser to access an HTTPS protected URL where your system doesn't trust the certificate used on the web server. In fact, that's exactly what's happening here as the CMG is just that (a web server hosting an HTTPS protected URL) and the boot image is just making a web call). The error message also clearly indicates this.
Jason,
Thanks for that. If using a public CA isn't an option, how would I establish trust in the boot media so that when the CMG is contacted, it knows that the authority is valid and can proceed?
Looking at SMSTS.log in X:\windows\temp\SMSTSLog\ using the boot media, I can see that after setting the TS variables once WinPE has booted, it mentions this:
Missing root CA environment variable from variables file
The next part of the log is as below, I've blocked out the CMG address but it appears in all the blocked out parts of below:
This is just before the callback status secure failure.
Your above issue is unrelated to the bulk registration token but is instead related to the certificate used on your CMG and the client (running the boot image in this case) not trusting that certificate or the PKI that issued it.
Did you use an internal PKI to generate the CMG certificate? If so, then there's no built-in method for this system to trust that PKI. You'll either have to switch to a certificate issued from a public CA or use a pre-start script to add the PKI as trusted during the startup of WinPE.
Hi Jason,
The CMG certificate was generated as per documentation from our Enterprise CA (with the correct subject name of the CMG name of course) and exported as a PFX - then added as the PKI cert during setup when the cloud management gateway was added.
If token-based wasn't working at all, then there'd be no communication between the CMG, the internal MP and clients - but comms for those are working fine with token-based auth.
So in terms of adding the PKI as trusted during WinPE startup, I would imagine we'd need a pre-start command to trust that - but would the CA also need to be visible in order for it to be reachable in terms of trust?
how would I establish trust in the boot media so that when the CMG is contacted,
As noted, by adding the PKI to the Trusted Root Certificate Authorities on the Communication Security page and recreating your boot media (you may also have to update your boot images but I'm not 100% sure on that).
I had already tried adding the root CA cert there and once added, then generated the boot image (and noted it had a SHA256 checksum when the boot image generation was completed).
Exactly the same failure unfortunately, despite the fact smsts.log could actually see that there was a cert generated from the CA and it was referenced in WinPE - it still came back with the same error as the boot image and client without the root CA cert.
I suspect this is because (as I mentioned earlier) we're not using full PKI for client auth when domain connected, and using enhanced HTTP with the inbuilt ConfigMgr certs.
OK, as noted initially, I wasn't sure if that was going to work or not. I'm kind of surprised it didn't.
That leaves you with two options:
Good news - I now have it working and the boot media authenticates with the CMG. The suggestion from @Jason Sandys was correct, but I missed something crucial as below.
What I worked out was that the root CA cert to be specified in the site properties needed the root and the intermediate CA (so two .cer files imported) - so that the full certification path was available in the boot image to authenticate the path in the PKI certificate uploaded to the CMG (the cert on the CMG showed the path to intermediate then root)
In addition, any changes made in the site properties also seems to increase the version of the configuration for the CMG in the ConfigMgr cnsole, so it was then a case of ensuring the CMG configuration was synchronised (for consistency), and once done, then create the media. I was able to create as a self-signed cert, and the two CA certs were embedded in the boot image. I could then see in SMSTS.log that this then added the certs to the store:
followed by a successful authentication:
So I can see the task sequences now.
So it does work if not using full PKI, but the key as Jason mentioned is to have the right CA certs in site properties so the full cert path of your PKI cert on the CMG (the one with your CMG as the CN name), check the config on the CMG has updated, then do the boot media.