If you’re still using ConfigMgr (or even MDT) for building devices via Task Sequences, you’ll be familiar with the need to supply an Image (a custom captured WIM or WIM from original media) during the process to apply the OS to drive.
Note: This is not the same as an automated process to build an Image for things like AVD or W365… watch this space for other blogs on that scenario.
When building a device that will be ready for an end user to immediately start using, we should always be looking to ensure it’s fully up-to-date with security patches etc so that we’re both not introducing any security holes to the estate and also not impacting user experience by interrupting them with reboot requests etc shortly after they start using their shiny new fresh machine due to updates required.
There are a few options we have than can assist with this:
- Ensure there is a step in the Task Sequence to apply all updates during the build process
- Use the ConfigMgr “Schedule Updates” feature to inject updates into the Image
- Regularly download a new ISO release from MVLS and use the WIM to create a new Image for use
- Use the awesome community tool OSDBuilder to create updated WIMs yourself
There’s obviously going to be pros and cons for each thing above and at a bare minimum you should be using the Apply Updates step in ConfigMgr/MDT in my opinion, but that will add time to your build process. While the “Schedule Updates” feature would sound like a no-brainer to use to inject updates and therefore reduce build time, this does remove the ability to test updates as it doesn’t create a new image, instead modifying the (likely) main image being used for production and not all updates may inject smoothly this way (SSUs before LCUs anyone?).
You could argue that both downloading a new ISO and using OSDBuilder both require manual effort and downloading and extracting the ISO from MS might even be quicker… except there’s always a time lag between updates released and MS making a new ISO available.
In this first post I’ll outline what I was looking to achieve, the process and then dive deeper into it over some further posts.
To have a new set of source files and WIM Image available each month, updated with the latest MS updates and imported into ConfigMgr ready for use with Task Sequences without interaction/manual effort and not impacting production activities.
Automatically update pre-prod Task Sequences with the updated image for testing and update production upon approval.
There are two main processes required for this – an initial setup process to put the core elements in place, and then a main “doing” process.
At a (very) high level, these look like the below:
Automated process to create a VM in Azure to use for the automation, isolated away from any core networks and containing the source files for the Windows OS.
Automated process to start the VM used for automation, run through all the required OSs to update, compress and upload the updated media files to Azure blob storage, recording the data in Azure Tables for reporting and use later in the process.
Download the compressed files and extract to a storage location used for ConfigMgr and import each updated set as a new Image in ConfigMgr then optionally update any required Task Sequences (with an approval process between pre-prod and production Tasks Sequences).
To support this approach, there’s obviously some key technologies involved. These consist of:
- Azure VM
- Azure Automation
- Logic Apps
- Azure Tables
- Azure Blob Storage
- Windows OS Source Files
The above hopefully outlines what the approach is for this and over the next few posts I’ll be explaining in more detail how it’s configured, the setup of the Azure environment, Logic Apps, the Automation Runbooks etc.
Below will be updated with links as they are published.
- Automating the Build VM Setup
- Creating the Blob Storage Azure Tables for recording information
- Creating the Azure Automation Runbooks
- Implementing the process with Logic Apps
Share on facebook
Share on twitter
Share on linkedin