This short article describes a useful tweak that can be made to SCCM and MDT to script the filename used for saving captured images in build and capture task sequences.
First, we will discuss the reason why you would want to use a build and capture task sequence.
Microsoft SCCM and MDT are mainstream solutions for operating system deployment, and each has the concept of a “task sequence”, which is the mechanism for orchestrating the series of steps that take place during deployment.
Everyone who has used either solution will be comfortable with the concept of a “reference” or “gold” image than is deployed to individual computers.
The next thing to consider is whether to use a “fat” image, where many applications are included in the base image, or whether to use a “thin” image, where the base image contains none or few applications. With both approaches, further applications can be layered on top.
What many SCCM and MDT implementations fail to do is to automate the production of the reference image.
Automating the creation of the reference image means that:
· When the image is regenerated (e.g. to incorporate new security updates, or to update an application in a “fat” image) the process is predictable and repeatable.
· Creation of the reference image can safely be delegated to a junior member of your team.
· Individual preferences, habits, or sloppiness of technicians do not make their way into the build.
· Applications can easily be removed from an image.
· Images do not degrade through repeated modification and tweaking – they can be built afresh easily.
Aside from the most basic of projects, the case for manually building a reference image when you have a tool that is designed to automate the building of images is quite weak.
So, the general method for achieving this involves the creation of a “build and capture” task sequence. The task sequence will be designed to be run in a virtual environment (so that “driver pollution” does not happen). Hyper-V on Windows 10 provides a perfect way to allow a junior team member to regenerate the image without them needing to log in to the virtual server infrastructure.
A build and capture task sequence will, when run, install an OS into the virtual environment and perform a series of steps (applying Microsoft patches, installing applications, etc). As with any Windows deployment sequence, some of the tasks occur in Windows PE and some in the OS being deployed. The final step of a build and capture sequence is for Windows PE to be booted and for the image to be captured and saved to a network share.
Often, the destination filename will be saved in the task sequence, or could be entered on the fly.
Wouldn’t it be a pain to sit through a couple of hours of OS deployment only to receive a “file already exists” error? Wouldn’t it be nice for the capture filename to be dynamically generated based on factors like the current date and time and the OS version being deployed?
Here’s how we do it.
In MDT it’s really easy. We can include variables and VBScript functions in the MDT filename (e.g. BackupFile=Windows10-x64-#year(date) & "-" & month(date) & "-" & day(date)#.wim).
In SCCM, we can’t do this and we also need to include the scripts in a separate package. Here’s how.
Create a text file called “set-tsdate-variable.ps1” in a new folder that contains the following text:
$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment
$tsenv.Value("TSDate") = Get-Date -format "yyyyMMdd-hhmm"
This creates an “environment variable” that can be accessed by other steps in the task sequence, containing our date in the desired format.
Create a new package in SCCM and point the source folder to the folder that contains the text file.
Create a new “Run PowerShell Script” tasks sequence step and place it between the default “Prepare OS” and “Capture the Reference Machine” steps. Set the task sequence’s package to be the one created previously and set the script name to “set-tsdate-variable.ps1”.
Finally, edit the destination field of the “Capture the Reference Machine” task sequence step to be similar to the following (replacing the server and share names to match your capture share):
Once you’ve tested, you can be confident that you will not experience filename clashes.