During the last month, a really long thread has been running in the OSD mailing list at myitforum, a discussion about what solution to use when building reference images for ConfigMgr 2012.
Then some idiot (me), against better judgment, promised to write a blog post about it… 🙂
Yes, you do need a reference image
Can’t you take the default Windows 8.1 image and deploy as is? Sure you can, technically… BUT it’s usually really smart to create a reference image since it reduces deployment time drastically, and is also a bit nicer to your network. So if you ask me, YES, you often do need a reference image.
Now when you know you need a reference image, how do you create one?
Let’s start with what NOT to do…
- Do NOT install Windows 8.1 manually, run sysprep manually, and capture it manually
- Do NOT take an existing machine you already have prepared manually, run sysprep, and capture it.
- Do NOT use a physical machine.
If you don’t agree about the above items, please stop reading and save you the frustration 🙂
The right way – Build and Capture is King!
And yes, Automation is King to!
What I have learned over the years is that an automated build and capture process, deployed in a VM, is the best way to create a reference image, and currently Microsoft provides two solutions for that: MDT 2013 Lite Touch and ConfigMgr 2012 R2.
Both solutions can be fully automated, so by running a single PowerShell script, you can build your entire image…
Why using MDT 2013 Lite Touch
Here follows a list of pros and cons for using MDT 2013 Lite Touch, let’s start with the good stuff
- Using MDT 2013 Lite Touch is simply faster in most cases. This means less hour spent (in total) creating and maintaining the image.
- Software Updates (via WSUS) is extremely reliable ind MDT 2013 Lite Touch.
- You can use the same image for every type of OS deployment (VDI, SCVMM, MDT, ConfigMgr, WDS, and more).
- You don’t need to worry about any challenges related to running everything in the LocalSystem context
- You can use old school techniques like CopyProfile
- You don’t need to worry about the ConfigMgr task sequence suppressing UI interaction.
- You can use a Suspend action that allow for reboots, useful when needing to installing/configuring something manually, or just want to check the reference image before it’s automatically captured.
Note about “faster”: Even if ConfigMgr is already up and running for OSD, processes are in place, and people know how to use it, MDT 2013 Lite Touch is still faster when you look at the hours in total dedicated to the task of creating and maintaining the ref image. With hours here, I mean more work time when using ConfigMgr.
And the not so good stuff
- For the best software updates experience (making sure the image is patched) using MDT 2013 Lite Touch, you need to install a separate WSUS server, and approve more or less the same updates that you have already approved in ConfigMgr. That will “cost” you at least 10 minutes every month…
Why using ConfigMgr 2012 R2
And the same goes for ConfigMgr, let’s start with the good stuff.
- If you’re a consultant, there is good money to made here… Obviously more billable hours means a larger LED TV in your house.
- You don’t need to duplicate the software updates management in a separate WSUS, meaning you’re saving at least 10 minutes every month.
- You don't need to dupliacte software packages (apps), which means if you are building really thick images (30 – 40 apps in the image), and those apps are already in ConfigMgr, it’s probably faster to build the image in ConfigMgr.
- You don't need to duplicate any drivers. Most times you don't need any drivers at all in the ref-image, but if building in vmware you may want to, or if you are building a refimage for Windows To Go.
And the not so good stuff
- If you’re the customer paying the consultants bill, more hours means more costly.
- Software Updates of reference image via the SUP is simply not very reliable, it may succeed, it may fail… It’s been like that since ConfigMgr 2007, and even to this day (March 2014, with ConfigMgr 2012 R2) I run into customers were the software updates action dies when you feed it with too many updates at once. Just a few updates, and it works perfect, feed 120 updates to the task sequence, and it’s likely to die. See the post comments for more info.
- If you are using HTTPS for ConfigMgr, it’s a bit painful to get the ref-image build going (can be done though).