In Cloud OS Deployment, Part 1, you learned how to run MDT task sequences via Microsoft Intune for Computer Refresh and Inplace Upgrade / Windows 10 Servicing scenarios. And in Cloud OS Deployment, Part 2, you learned how to do bare metal deployments from the cloud via MDT, with or without any local infrastructure.
In this part 3 guide, you learn how to do bare metal deployments from local boot media, but downloading all the content (OS image, drivers, applications) over Internet (https) using ConfigMgr. This feature was released in ConfigMgr 2006, and was improved heavily in ConfigMgr 2010.
Note #1: The initial cloud imaging release in ConfigMgr 2006 required the client to have access to the non-Internet ConfigMgr infrastructure (the MP), before it could download the content from the CMG Cloud DP . That limitation was removed in ConfigMgr 2010, and now you can specify a CMG to use directly when creating the boot media. (Yay 🙂 ).
Note #2: I'm currently researching what P2P options that are available for this platform. Since outbound traffic from Azure is connected to a cost, ideally you only want to pay for the first deployment, and use P2P for subsequent deployments.
The Cloud Imaging Scenario
In this guide I cover the scenario for imaging machines with ConfigMgr without using the ConfigMgr on-premises DP for content, and instead using the CMG Cloud DP. Useful when imaging machines at a small remote office that have a fast local Internet break out, and you don't want to overload the WAN or VPN link to the internal ConfigMgr infrastructure.
Behind the scenes
When using the CMG Cloud DP for imaging, each ConfigMgr package becomes its own container in your Azure storage account. The container is named container-<packageid>. Within each container you find all the blobs that makes up the files in the package, for example a Windows 10 image, or the the ConfigMgr client.
To access the blobs without any certificates or regular username/password needed, each container is protected by an access policy that is frequently generated/updated. You can see references to the current access policy in the smsts.log file when deploying a machine. And if you're quick, you can snatch the URL from the smsts.log file, paste the link in any browser (or PowerShell), and download the file without any additional authentication. That is until the shared access signature (SAS) info in the smsts.log URL expires, meaning the access policy expired. Each generated link is valid for 8 hours, and hopefully your deployment don't take longer than that.
Here is an example link from a deployment on June 5, 2020. The si=d200605080000.0000 info is the named of the access policy used.
If you try to access the above link after it expires you see something like this
<Error> <Code>AuthenticationFailed</Code> <Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:5a428012-101e-0008-433a-3cb354000000 Time:2020-06-06T19:38:34.3617262Z</Message> <AuthenticationErrorDetail>Signed expiry time [Fri, 05 Jun 2020 20:00:00 GMT] has to be after signed start time [Sat, 06 Jun 2020 19:38:34 GMT]</AuthenticationErrorDetail> </Error>
ConfigMgr Pre-Requisites – The CMG
To make this scenario work you need to have a ConfigMgr 2010 site server configured with a CMG. The CMG feature is not free, and will typically cost you about $100 per month for a lab and test environment.
The CMG feature can be configured in quite many difference ways, but I prefer to keep it simple, and don't be depending on Azure AD-joined, or Hybrid-joined machines. I recommend using the Enhanced HTTP feature that has been available since ConfigMgr 1806, and I use an internal PKI infrastructure to auto-enroll the client certificates (device-based).
For the Server authentication cert you can either buy a Standard SSL certificate from companies like Digicert, or generate one from your internal PKI infrastructure. For more info on setting up CMG, see the official docs: Set up cloud management gateway for Configuration Manager, or use any of the many blog posts covering the topic.
ConfigMgr Pre-Requisites – Content, Boundaries and Client Settings
There are very few settings in ConfigMgr that must be configured in Default Client Settings, but this is one of them. Make sure clients are allowed to use content on a cloud DP, but setting the Allow access to cloud distribution point setting to Yes in the default client settings.
Per the ConfigMgr documentation, you should also configure the boundary group(s) that you want to use for these clients to prefer content from a cloud DP. But that isn't needed if the CMG Cloud DP is the only DP in that boundary group. Not that it hurt enabling it, but still 🙂
Also, don't forget to distribute all content your task sequence(s) are using to the CMG Cloud DP.
Deploying the Task Sequence
When deploying the task sequence, in addition to allowing the deployment from media like usual, don't forget to select the "Allow task sequence to run for client on the Internet" check box (User Experience wizard page).
Next step is boot a client from a boot media (USB stick), and deploy as usual. If you open up the smsts.log file during deployment, you will see that content is being downloaded from the CMG Cloud DP.
Create a media for cloud imaging by selecting the boot media option, and later in the wizard, select your CMG as the Management point.
Speeding up imaging from a CMG Cloud DP
Since you are downloading content from the CMP Cloud DP, via https, you want to avoid having packages with many small files. For example, by archiving your driver packages per this blog post: https://deploymentresearch.com/speed-up-driver-package-downloads-for-configmgr-osd/
As an example, downloading the driver package during deployment of a single Dell XPS 15 machine, with the Dell driver package not compressed, took 20 minutes from the CMG Cloud DP. When the driver package was archived to a single zip file, the download time was only 5 minutes.
For a more detailed step-by-step guide, please check out this great post by Niall Brady (@ncbrady):
Deploy an OS over CMG using bootable media