However that still didn't suit all organizations. Some organizations weren't ready for PKI or Azure AD join implementations and still needed to manage Windows 7 devices. ConfigMgr 2002 was generally released last week and includes a real game-changer. We can now used token-based authentication for communication between internet clients and the management point over http. The amazing thing here is that we don't have to do anything additional on the management point or client. All this works out of the box when you upgrade the ConfigMgr site to version 2002. Remember you MUST actually upgrade the clients to 2002 as well.
There are two scenarios and we'll look at both.
- clients that can register on the internal network
- clients that are always internet-based
This is easy. It just works out of the box. When you upgrade a client to 2002 it will immediately register with the management point.
In the ClientIDManagerStartup.log file you will see the client receiving it's self-prove token from the management point.
This is a ConfigMgr 2002 client on the intranet. You will see that it is not configured for PKI (otherwise you would see Client certificate: PKI). It uses a self-signed client certificate (and the self-prove token behind the scenes).
The client is not Azure AD joined.
Now the client roams to the internet. It pairs it's self-signed certificate with the management point-issued self-prove token to communicate with the CMG.
The client is now aware of the CMG.
In the CcmMessaging.log file we can see the client receiving a CCM token which allows the communication to continue.
An important thing to note is that the client renews the token once a month and it is valid for 90 days.
Internet-based
What can we do with clients that are already internet-based? We won't be able to automatically upgrade the client to 2002 and the client won't be able to register with the management point immediately and get the self-prove token. In this case we can use the bulk registration token.
Navigate (as administrator) to the \bin\x64 folder of the ConfigMgr installation directory on the site server.
Run the tool by executing:
BulkRegistrationTool.exe /new
The token is generated. Remember this token has a short-validity period so you should use it straight away.
Copy the token.
Now install the ConfigMgr client on the internet-based device using the additional /regtoken parameter. I've done it manually by copying the installation files to the device and executing this command:
ccmsetup.exe /mp:https://GerryHCMG.emslab.ie/CCM_Proxy_MutualAuth/72186325152220500 CCMHOSTNAME=GerryHCMG.emslab.ie/CCM_Proxy_MutualAuth/72186325152220500 SMSSiteCode=GER SMSMP=https://MEM.hampson.local /regtoken:eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1XUldSbUtVQlZjNlJDSGpCTjQyZnhvZUdEMCJ9.eyJTQ0NNVG9rZW5DYXRlZ29yeSI6IlNDQ01QcmVBdXRoVG9rZW4iLCJBdXRob3JpdHkiOiJTQ0NNIiwiTGljZW5zZSI6IlNDQ00iLCJUeXBlIjoiQnVsa1JlZ2lzdHJhdGlvbiIsIlRlbmFudElkIjoiN0IwQzM4MDYtRDI4Qy00QTQ1LUFEQjItRkI5Rjk0QTQ2MkY4IiwiVW5pcXVlSWQiOiJlYTJmYzUxMC1hM2JlLTRjZWYtOTBiMC0yYTA1MTVjNGU0MGMiLCJpc3MiOiJ1cm46c2NjbTpvYXV0aDI6N2IwYzM4MDYtZDI4Yy00YTQ1LWFkYjItZmI5Zjk0YTQ2MmY4IiwiYXVkIjoidXJuOnNjY206c2VydmljZSIsImV4cCI6MTU4OTcwMTUxOCwibmJmIjoxNTg5NDQyMzE4fQ.Y-6s6_h18cnIZP8OPqdjpxQHUhg_4srICehX5xOfym5AcyQRC3wlN89PAByFD2gfp6QvV7gXX9H7oG198UGHhUuJrthAipSo4KNCSr8t7TcZwjR9awt720tErf9aiflBKnFibAYAGU9xBS3UYTetQ6XYpdh0XsCedsbh0-6ilj6KmP1qWBFIYNkBaL3oP_HJhX02de0wqeh-fWiTtdvbKnOxDrGetoCKsEVp3sJumprzWHZ6ZpRD3powG3AUOOSbAW96c_driDvzwC6x6hoWOo4GPEs-BaoJUdRzi1htY9IJB2X_drIQqLH8X0Ps6B5H5-KGH3gB0tJA45WwERuLxA
As before you will see the client getting it's CCM token from the CMG in the ClientIDManagerStartup.log file.
The client is installed.
In the ConfigMgr console we can see that the device is managed by the CMG over the internet.
There are obviously a few challenges in this scenario:
How does the remote user get the ConfigMgr 2002 client installation files?
I plan to use this scenario in production and I intend to copy the files and installation instructions to OneDrive to make available to users.
How can the user install the client if they are not a local administrator?
This one is more challenging. The users will need some assistance with elevated rights, possibly using screen-sharing software. This also highlights a great use case for a solution like Local Administrator Password Solution (LAPS).
I think this feature will be extremely useful so I hope this walkthrough was helpful.
Until next time......
Will it work with windows 7 devices that are not in azure ad??
ReplyDeleteYes Keshav, it works with any supported client.
ReplyDeletehow do you enable CMG traffic on the primary site MP is its still in HTTP mode?
ReplyDeleteNice wrap up!
ReplyDeleteHow long is the bulk token lifetime?
Hi, can I test this scenario for a SCCM client active device in which client authentication certificate got expired and is unable to auto renew because user is not coming to office
ReplyDeleteYou have to either connect the device to the intranet to install the 2002 client or you have to install the client on the internet with the bulk registration token. That will require admin right so you'll have to remotely connect to the device somehow.
DeleteQQ about this - Let's assume the CMG is bound to an internal PKI certificate. So, when i use the above command to install, I get an error such as Winhttp_callback_status_flag_invalid_CA in ccmsetup. Which is due to the root certificate being absent on the client. So, internal PKI won't work with bulk token, would they?
ReplyDeleteI am trying to figure out if an internet-based bulk-token onboarded client will switch to AzureAD-based token authentication (like the other clients) by itself after it can communicate again with the management point via CMG? Or will this client stick forever with the bulk-token configuration?
ReplyDelete