Starting in Configuration Manager 2010, we can use OS boot media from SCCM to reimage internet-based devices that connect through a Cloud Management Gateway (CMG). Do note that, this method cannot join the devices to domain but only in a workgroup as there is no domain connectivity for internet-based clients. This scenario is useful to support remote workers. Though the devices are in workgroup, these can be managed via Configuration Manager for application deployment, patching, and other features that support a client over CMG.
In case of any issues with remote worker windows OS, we can use the OS Boot media (send over USB) to reinstall the windows. All this happens through the cloud management gateway.
For more information about how to do task sequence over the internet using cloud management gateway using the bootable ISO, please refer here.
Prerequisites for boot media via CMG refer here
When i was doing some testing on this feature in my lab, i encountered some issues and i would like to discuss them in this blog post with fix.
My lab is running on HTTP (no PKI) and the CMG server authentication cert is using enterprise cert (On-prem CA). All of my clients are hybrid Azure AD Joined.
So when my clients move to internet, they use hybrid azure AD join for authentication.
As per this guide, I have created boot media that uses CMG as a management point. Since my SCCM is not running PKI infra, I don't have to import any certificate (PKI) into boot image while creating it. you only need it when your site is running on HTTPS (and clients too). The boot image uses a self-signed media certificate ONLY.
When booting the device which is on internet using the ISO that we created above, it failed with error code as listed below.
asynccallback(): winhttp_callback_status_secure_Failure encountered
The device is authenticating with my CMG (https://cmcb1.cloudapp.net) which is using enterprise CA cert.
The boot image that we created is using self-signed certificate which is not enough to authenticate with CMG.
How do we fix this certificate issue for CMG bootable using self-signed certificate?
Since my CMG server authentication certificate using enterprise CA, I will need to have root CA into the boot image. That can be verified from your site properties, communication security.
As you can see above, there is no root CA specified. For a successful task sequence deployment over CMG using boot media, I would need to import the root CA.
To import the cert, click on set, click on start burst, import the cert and click Ok.
Now go back to your task sequence and create new boot media using the self-signed certificate. This time, it will allow you select the task sequence that are deployed to unknown collection and continue from there.
When I choose the task sequence, i hit with another error. The device unable to verify the content located on a distribution point.
I did verified that, the content is distributed to cloud DP and can located in blog storage as well.
After checking my client settings, it was found that, I had custom client settings for CMG and is deployed to collection. This will restrict desktops/servers from receiving the CMG settings.
For unknown clients on internet, you will have to make the changes in the default client settings for CMG.
Edit the default settings, cloud services, choose the CMG settings as listed below.
Once you make the changes in default settings, you don't have to re-create the boot image.
Now go back to the internet device, retry the task sequence.
Client is able to connect to CMG, cloud DP for content download.
Depends on the speed of the internet, the deployment may take time.
Hope it helps!
Hi IT expert Eswar,
which log Files mostly asking interviews as I'm begginers. I hope your answers as soon as ....
SCCM has various components/features that it can support endpoints. Based on the features that SCCM support, the logs are huge for deep dive investigation the issues.
There is no particular order or logs for you but most of the orgs will use the features such as applications, packages, OSD and software updates.
For applications, it will be appenforce.log, packages, execmgr.log, OSD, smsts.log and software updates, updatesdeployment.log. But it is not enough. These logs are spot on to check the deployment status.
If you want to troubleshoot the issue such as application, why does the app failed, is the client able to communicate with MP, SUP etc, the logs will vary.
Likewise, there are other logs for content download, client registrations etc.
you should have brief idea on all the logs and based on the feature you look, logs will vary.
Here is the article for all the client logs https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/hierarchy/log-files