Image Factory Automation

One area where MDT Litetouch excels is with Image Creation. I know of several groups within Microsoft (including Microsoft Consulting) who recommend using MDT LiteTouch to create images, even if those images are eventually used within SCCM OSD (Operating System Deployment).

Background

Back in the Windows XP days, the OS came with it’s own proprietary installation system. Say you spent some time getting XP updated to the latest Service Pack, along with all the necessary security updates, and the latest version of Office. You might want to take a snapshot (or checkpoint) of this reference disk (Image) to reload on other machines. That’s where Sysprep and 3rd party products like Ghost came to the picture.

Starting with Windows Vista, Microsoft started distributing the OS using a new file archival format: Windows Imaging Format (*.wim files). *.wim files are compressed archives with space to store extra metadata. It’s also intelligent to hold multiple archive sets within a single *.wim file, and only keep a single instance of the same file, so a single wim file can hold Windows Starter, Home Premium, and Ultimate on the same disk!

The main difference between Ghost (*.gho) files, and WIM (*.wim) files is that Ghost Files store the contents of a hard disk in block format (partitions and all), whereas the WIM files are stored as files. That means that when you apply a *.gho file to a disk of different size, Ghost itself needs to do some resizing of the partitions to make it fit. Whereas the *.wim file can only hold those files and streams it knows about (boot sectors and deleted files are ignored).

One of the coolest features of *.wim files is that Microsoft allows customers the ability to capture the contents of a Drive (volume) into your own *.wim file. In fact for some versions of Windows, you can replace the install.wim file on the Install DVD with your own captured *.wim file, and continue with the installation process like it came from Microsoft.

Imaging

So how do you create your own image for use?

  • First off, you should setup a machine *just* the way you want it.
    Install the OS, Install Apps, Configure Settings, Add drivers if necessary.
  • Next, run Sysprep on the machine. This will prepare the machine to re-run OOBE Setup.
  • Finally, boot into WinPE and capture the image using imagex.exe or dism.exe into a *.wim file.

Of course this is a major oversimplification of a complex process. For example, adding Drivers to the image depends on the scenario. If you *know* for certain that this image will only be applied against a single kind of computer system you could perform the capture on that reference system so that the image contains all necessary drivers, ready to go. Otherwise, if you are targeting several kinds of hardware, I would strongly recommend using Hyper-V Virtual Machines to create your images, since the OS won’t load any extra drivers into the image.

Enter MDT LiteTouch

The MDT LiteTouch Client and Server deploy Task sequences were designed from the start to handle the full deployment installation process. OS installation, Application Installation, Sysprep and Capture, all from the default Client and Server Task Sequence templates.

One of the cool things to do is to make the LiteTouch process into a Fully automated No-Touch process (we reserve the ZeroTouch name for SCCM with MDT extensions :^).

Let’s start off with a Deployment Share setup specifically for image creation in our lab. To automate the process I have created an account on the local machine that has read/write permissions on the Deployment Share but is *not* a member of the local users group. I have also given it a random password.

In our Bootstrap.ini file, we add four lines to the bottom:

[Settings]
Priority=Default

[Default]
DeployRoot=\\PICKETTV\Create$

;  # NEW LINES FOR AUTOMATION:
SkipBDDWelcome=YES
UserID=MDTUser
UserDomain=PICKETTV
UserPassword=de36c86a4340#

This will allow us to skip over the MDT LiteTouch Welcome Wizard, and connect directly to the Deployment Share.

I have created a virtual Machine used to capture Windows 8.1 x64 images, I booted up the machine and found out it’s machine BIOS GUID (check the bdd.log file), and in this case the GUID is: {29c80ff5-4dc4-4497-a035-472118542fd7}. Some people use the MAC address of the virtual machine.

IN our CustomSettings.ini file, in addition to the standard settings used by our regular deployments, I have added the following entries:

[Settings]
Priority=UUID,Default
[...]
[29c80ff5-4dc4-4497-a035-472118542fd7]
TaskSequenceID=Win81Ux64
SkipWizard=YES
AdminPassword=P@ssw0rd
FinishAction=shutdown
SkipFinalSummary=YES
DoCapture = YES
ComputerBackupLocation = %DeployRoot%\Captures
BackupFile = %TaskSequenceID%.wim
MandatoryApplications001={524d3d3d-bc51-4624-b014-4777aa75a99b}

First off I have changed the [Settings]Priority to add UUID. This means that the first thing processed in the CS.ini file will be the matching GUID section found in the file (if any). Within my GUID Section, I have created an application bundle to install my preferred applications set, Defined the settings to capture the machine back to the imaging server, and set everything else to full automation.

As one last trick, I take a Snapshot/Checkpoint of my Virtual Machine so that I can roll back the machine and restart this *automated* imaging process from scratch. This can be great for Patch Tuesday, just roll back and re-image. The only work on my part is to kick off the imaging, and review the logs when finished.

SCCM

What about SCCM you ask? SCCM OSD (with MDT integration) has the same ability to install an OS, Applications, Sysprep, and Capture. Why not use that system?

Well, if you have a fully functional SCCM OSD deployment system ready, along with all the applications pre-packages, then yes, it may be a good idea to continue using SCCM OSD to create your images. However… if you do not have a fully functional system ready with all of your applications packaged (fully automated). I would not recommend starting with LiteTouch instead.

Running in the Administrator context in MDT LiteTouch allows us more leeway when building our images with unproven systems and components. We can see what’s being installed, see error messages on the screen, and debug in real time on the console. There is just no need to install the overhead of SCCM for a small contained process like imaging creation if you have not already automated everything in SCCM.

Automation

Now there is an important point to make here. If we can Automate as much as possible in the imaging process, typically the installation of our Applications, we can rebuild our core images over and over again with little efforts.

Of course there are some scenarios where Component “X” is difficult to install in a fully automated fashion (or we don’t know how to install). Some times we can *RePackage* the application using some 3rd party tool, or perhaps we can push the installation of this application to another process, perhaps during OS deployment, rather than during Image Creation. MDT LiteTouch also has a “Manual” step that can be added to the Task Sequence to allow an Imaging team to perform non-automated steps.

However, for the most part, my recommendation (and the recommendation from many at Microsoft) is that if you can automate the installation of applications, you should. As you can now leverage no-touch image building.

Image Factories

Once you have some of the basic settings defined for creating your image, the next step would be to automate the whole thing with PowerShell.

We can use PowerShell to Create User Accounts, Create Virtual Machines, Assign Network Switches, Apply our the LitetouchPE_x86.iso, and start. We can also use PowerShell to inject our No-Touch settings from above dynamically into the MDT Process.

While working for Microsoft’s own IT department, we would create multiple images at once, each for a different use ( Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012, With *and* without Office ). Why would we provide an image *without* Office? Well, there are groups within Microsoft who don’t want Office, they are developing and DogFooding the *next* version of office :^).

We call this whole system an “Image Factory”. There are a lot of moving parts, but when done properly, rebuilding your image set for patch Tuesday is no problem.

Advertisements