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).
/ Johan
Hi NinjaEpisode,
I normally just allow WSUS to handle the updates, and not worrying about install the rollup updates first.
/ Johan
Hi Arad,
Unfortunately the offline servicing have proven not very reliable as well as not all updates can be serviced offline. Also the built-in install software update action in SCCM still has issues when there are many updates.
I recommend using MDT 2013 Lite Touch because it always work, with all kinds of updates.
/ Johan
So here's my question Johan, how do you best handle the Update Rollups for 8.1? Do you deploy these first and then patch or do you just patch via WSUS and let the system handle what's what? I'm troubleshooting a Surface Pro 3 deployment where the Pen isn't working right unless we apply a horde of patches, but we're in the midst of testing if we just need the rollups or everything Windows Update tells us we need.
With regards to the capturing a referenced image, and WSUS, i would have thought that the ability to use the "Offline Servicing" component of SCCM 2012 to directly inject updates into a wim file would make things much easier than using MDT and tip the balance in favour of using SCCM. With regards to the copy profile issue, this is a very old school way of doing things, and i personally dont even use that feature, and use a build script to where i add all my customisations to teh default user profile.Also I have seem probably 90% of organisations… Read more »
The second WSUS can be the MDT server, no problem.
/ Johan
So can the second WSUS server be on the same server as the MDT or would you need three total servers – SCCM2012+WSUS, MDT, and WSUS?
So can the second WSUS server be on the same server as the MDT or would you need three total servers – SCCM2012+WSUS, MDT, and WSUS?
It has to be separate from the ConfigMgr 2012 SUP which is also using WSUS (but using WSUS differently than MDT does).
/ Johan
Out of curiousty why the need for a dedicated WSUS server? I have started my migration from SCCM2007 and WSUS to a single SCCM2012+WSUS server as I believe Microsoft recommends (less than 250 devices). I also installed MDT on that same server and would like to keep everything on one box if possible.
Hi Joseph,
By adding updates (and possibly large apps like office) to a reference image you reduce deployment time, and the amount of data being transfered over the network. Just updating a Windows 7 image can take one hour, and I rather wait for that only one time, than on every single deployment.
/ Johan
Hi Johan – Can you elaborate a bit more about the "Yes, you do need a reference image" section? What exactly makes a reference image faster than the default WIM? How is it more network efficient?
Thank you!
joseph
I would go with MDT, simply because in many cases I see, the person building the image has no or not need to have access to the SCCM infrastructure.
With MDT, you can essentially build an image on a laptop including having a stand alone WSUS, use the free Virtual Box and do it any where.
Hey Roland, Thanks for taking your time commenting here, and nice to meet you at TechEd as well. I'm not too worried about duplicating the same content, and when building thin images, even if I start from scratch, it simply will be faster than doing the same job in ConfigMgr, and it will be more reliable. Eventually software updates action in ConfigMgr may be fixed, I agree on that, but currently it's not. For me it comes down to the following: It's easier and faster to build reference images in MDT 2013 Lite Touch, it's more reliable, I get more… Read more »
As I started that thread on myitforum (sorry for actually hijacking the original one), I do have a few comments to add to your post.But one thing first: Thanks Johan for putting this up, I'm sure it will get quite a bit of attention as your great blog does in general. I agree with many of the statements, but obviously not all of them 🙂What to use (first) depends highly on where you are with building up anything and what you need at that time. If you just started and have nothing else, you may start with MDT. If you… Read more »
Agreed Johan, never fails.
thanks for all the books and sharing the knowledge, you make our life so easy, too easy!
I strongly recommend to have a local WSUS for the following reasons: 1. The built-in update action in the task sequence works perfectly against a local WSUS, all fully automated.2. If not a local WSUS is defined, the same script will go to Microsoft Update directly and pull the updates, but it takes longer time and is less reliable. It may work, it may not.. and I prefer always work.3. It's easier to control what updates that goes into the image.4. Why reinvent the wheel with custom scripts, when there is a free solution that works perfect!5. Offline patching is… Read more »
No need for a dedicated WSUS in MDT. I pause the TS and can get the update I need from the internet. It is also possible to do a vanilla image, import to SCCM, apply update online and take it back to SCCM? I have done that with my recent 2012 R2 and MDT 2013. at one point I also wrote a PS script to poll the missing updates from the SCCM based WSUS server, but got lazy towards the end 🙁All that said, the easiest way is the good old way, and a descent laptop will suffice for building… Read more »
If the offline servicing would have been reliable, yes, but it isn't, so please avoid it.
/ Johan
And what about offline servicing thru the configmgr 2012 r2 console? It is not a point in favor of sccm?
Un saludo,
Pablo
Hi Dean, Thanks for taking the time commenting the post, and you are absolutely right, the post is biased (and based) from my own experience. Like you I'm working as a consultant and over the years I have worked with customers having everything from 500 – 300.000 clients, during that time I have learned what works the best, at least for us. So far most of the projects ended up using MDT Lite Touch for the reference image. I may have been lucky, but our customers didn't mind to learn a simple tool for a specific purpose, especially when the… Read more »
Challenge accepted! Most of your arguments around not using SCCM for reference image creation relate to the additional costs of consultants and even list paying for consultants as a negative. I have extensive knowledge of not just creating reference images but also very large scale SCCM deployments for OSD spanning hundreds of business units each with their very own business and technical requirements. MDT does not stand a chance! It does not mean that I don't use it, it just means that I am very selective about which components I do use and the OS deployment portion is not one… Read more »
The Windows update engine can handle a max of 512 threads (W7 at least). Each patch contains a number of threads. When the update que reaches 512 threads a deadlock occurs with SCCM. SCCM will try to add thread 513. WU cannot do it and SCCM waits until WU will do it. This was improved in 2012 (lower number of threads per patch) but the problem isn't gone. Be aware that big patches/rollups can contain a number of patches inside and each of these will eat threads. Therefore it's a good idea to prepatch you image during build so that… Read more »
I appreciate you addressing this in such a way as to point out that there is no "one best way", I find with my customers that its best to present them with the best practices you mention here, then we adjust to what fits their needs best.
Good stuff, thx
Idea, how about creating a hydration kit to create the image build lab?