This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
I am trying to experiment with the bulk enrollment feature of our SCCM Version 2010 environment. I have created the bulk enrollment token, and copied it to my installation USB drive. The CCMSetup.log shows CCM_E_NO_TOKEN_AUTH, followed by a DownloadFilebyWinHTTP error 0x87d00455. I would like to validate the Token is actually being used, and is being recognized at the CMG. I have an internally generated cert manageing the traffic between my CMG, and the connection point on-prem, My intention is to use eHTTP for client communication, but this system isn't AD, or AAD joined (yet). Can anyone offer any advice where to begin looking? TY!
Does the client device trust the PKI that issued the cert used for the CMG?
No, I was thinking the bulk enrollment token was my authentication token. the system is just off the shelf from my local vendor. maybe I am misunderstanding what the bulk enrollment process is for. I was thinking this would be similar to a DMZ client install, but the CMG would be the MP, and DP...
Hi Jason, No the client is an out-of-the box system fresh off the shelf. I thought the token was the authentication key, to bypass any on-prem/AD cert requirements. I was expecting to deliver the client, then a VPN client, and then perform an AD join, and move the client into a fully managed state. We are not co-managing at this point, (hopefully soon) but this was "my" way to leverage the CMG for those new systems. Thanks
The token is simply an identity and bulk token is a temporary identity useful for initial enrollment. It in no way bypasses other security requirements. In this case, that's specifically an SSL/TLS channel from the client to the CMG which requires a server auth cert on the CMG. In order for this channel to be established properly because HTTPS involves server authentication by the client and thus the client must trust the PKI that issued the server auth cert on the CMG. This is in no way specific to ConfigMgr, it's standard for all web traffic protected by HTTPS. This is generally transparent though because by default, nearly all web sites use certificates issued by public CAs (like DigiCert) that Windows trusts by default. Thus, the best path here if you to purchase a server auth cert from a public CA and use that on your CMG instead of an internal PKI that your clients don't trust by default.
Thank you Jason. I continue to struggle with certs and their implementation. I appreciate your short lesson, and will move forward with implementing a complete chain for these systems in our environment! Thanks again.