Windows 8.1 Reference Image Planning Checklist

We recently started evaluating Windows 8.1 at work and, quite frankly, I forgot how much effort went into creating a fully customized reference image.  I did the work several years ago when we migrated to Windows 7 and I can build out that infrastructure in my sleep.  But, it seems that there are even more settings that we’ll need to tweak in Windows 8.1 so that our customers don’t revolt when we start rolling it out.

Don’t get me wrong, I’m not a Windows 8.1 hater.  But, we try to strike a balance between what our end users are used to using in their current environment and the new features they’ll be getting when they move to the new OS.  A little up front planning can go a long way toward ensuring a smooth roll-out!

The List

Be warned, this is a work in progress.  I’m not making any claims that it is complete… yet.  I’ll be coming back as I progress through the process and adding links and tutorials for how we did things. 

  • Make sure you’re building from the latest ISO
  • Do you need to support both x86 and x64?
  • Pull inventory of machine models so you can start the process of pulling updated drivers.
  • Does the WSUS (or SCCM) server need to be updated to include Windows 8.1 updates?
  • Update Office 2013 files to latest ISO
  • Update .msp for Office 2013 deployment since we’re updating the install source.
    I had to find out the hard way that the .msp file that is generated by the setup.exe for Office 2013 doesn’t seem to work quite right with the setup.exe for Office 2013 SP1.  I ended up completely regenerating our .msp file just to be on the safe side.
  • Do you need/want to customize the Start Screen?
    • If yes, does it need to be in the Reference Image, OS deployment, or forced with Group Policy?
    • Plan out what will be on the customized Start Screen
  • Customize logon screen wallpaper
  • Customize default user wallpaper
    • Do you want the Start Screen wallpaper to be the same as the Desktop?
  • Add additional custom wallpapers for user to select
  • Change default color scheme to match organization logo colors.
  • Remove inbox Metro/Modern apps that we don’t want users to have
    Ben Hunter has a great script on The Deployment Guys blog that you can use to remove inbox apps.
  • Plan for end user of OneDrive and whether it needs to be blocked.
  • Update file extensions to open specified file types in desktop apps instead of Metro apps.
  • Plan for BitLocker if some or all systems are going to be encrypted.
  • Review/Test Group Policy to determine need for updates to support Windows 8.1.

See something missing?  Let me know in the comments!

What kind of reference image should I use and what should be in it?

I had a great question come in last week and the writer agreed to let me respond as an article:


Last July, I started my first real systems administrator job at a school system here in the Midwest. One of the things I inherited was Ghost for imaging computers in classrooms, computer labs and so on. Now that Symantec is killing off Ghost, I’ve been tasked with figuring out how we’re going to re-image computers this summer. We’ve settled on using SCCM for our OS deployments, but I had a question about reference images after reading your series on creating base images in MDT. What do you typically include in your reference images? Our Ghost images include literally everything from Office to Java to other random education apps… just about all of them.  We even found an image with some old gradebook software in it. The gradebook software went fully web-based years ago (before I even got here) and the software just never got taken out! The problem is that it feels like we’re constantly updating the reference image (all 40-something of them!!!!), people have apps they don’t need, many of the apps like Java and Flash have to be updated immediately after a re-image, there are remnants of old software, and so on.

Any help or advice you can provide would be really helpful!

Jeremy S.


First off, thanks for letting me answer your question in the form of a blog post!  And, thank you for responding to my followup questions so crazy fast.  Here we go:

I too came from the school of Ghost imaging; so, I totally understand where you’re coming from. A lot of people that use sector-based imaging solutions build these massive monolithic catch-all images and tend to update them for years on end before re-creating them from scratch (or they just keep using the same base forever!).  And for good reason… you tended to have to have a whole lot of them to cover all of your hardware types and use cases.  The good news is that when Vista came out, the whole OS deployment process got an overhaul and it made OS deployment far more customizable and predictable without the need to create these massive reference images (unless your particular environment requires it).

MDT and SCCM have really changed the game for OS deployments.  You don’t need to create a monolithic reference image that includes every single piece of software someone needs if you don’t want to.  You can install as much or as little as your want and then use MDT or SCCM to customize that deployment at install time.  So before we can really get into a discussion about that what of your reference image, you’ll need to decide what kind of reference image you’re going to create first.

There are three schools of thought when it comes to creating reference images:  Thin Images, Thick Images, and a Hybrid Images that are somewhere between Thin and Thick.

[Short Answer] Which do I recommend?  Honestly, it depends on your environment and what you’re trying to accomplish.  If you just need to test something like a script where you don’t need any applications or to be fully patched, a Thin Image is probably all you need.  If you’re imaging a computer lab full of computers that all need to be identical, then you probably need a Thick Image. Most people I know (including me) are using a Hybrid Image.  I use a Hybrid Image because the applications used by my end users vary and I like to be able to customize the deployment to their specific needs.

[Long Answer] —

Thin Images

For me, a Thin Image is OS only.  I’ve seen some people use just the RTM media to deploy Windows 7/8 and then lay down all their software, but there’s one huge problem with doing it that way…  If you use the RTM bits, you now have to install all of the Windows Updates too.  Ouch.  That can be really time consuming.  Personally, I like to keep a Windows  reference image that is using our currently supported version of Internet Explorer and the latest Windows Updates installed available as a Thin Image with no other 3rd party software.  Even if I don’t update it every single month, I’m not having to wait while over a year’s worth of updates are installed on the computer.  There’s also the added benefit of speeding up the process of building a Thick/Hybrid Image if I base it off my fully patched Windows 7/8 Thin Image.


  • Smaller image since since you’re just dealing with the base OS (and possibly Windows Updates).
  • Very customizable since there isn’t any software installed.
  • Speedy install of a base OS (assuming you’re including Windows Updates).


  • Requires months (if not years worth) of Windows Updates if you don’t make a reference image that has the latest updates.
  • The full deployment process of laying down the OS and installing all your software on a computer may be slower since you’ll have to potentially install Office, Adobe products, plugins, etc.
  • Potentially eats up additional CPU cycles and disk IOPS in a virtualized environment while software installs.


  • Any time you just need Windows on a system… whether that be testing or systems that don’t require additional software.
  • When you need to customize the install of each and every computer that will be deployed.


  • Windows Base OS
  • Latest version of IE your applications support
  • Latest Windows Updates
  • [Consider] Visual C++ Runtimes

Thick Images

A Thick Image is everything and the kitchen sink (ok, well maybe not the kitchen sink…):  Windows, Office, all the latest Windows/Office Updates, plugins, custom apps, and everything else you can think to install.


  • PC is ready faster since all necessary software is installed as part of the image.
  • Works well as a “cookie cutter” deployment to large numbers of identical systems like in computer labs or corporate environments where every PC should be identical.
  • Easier to hand to junior level staff or temps since everything is already installed.
  • Less chance for a piece of software to be missed at deploy time since everything intended for the system is already in the image.


  • May require more frequent updates since you’ll need to update it monthly for Patch Tuesday updates from Microsoft and third-party products.
  • May require patching after image is deployed since third-party products like Adobe Reader, Adobe Flash, Oracle Java, etc. may have been updated since the image was built.
  • May require building multiple reference images since software needs may differ between different departments, computer labs, etc.
  • An error like a misconfiguration or a piece of software that wasn’t installed in a Thick Image means the error goes out to more computers.
  • Users end up with software that they potentially don’t need.  Unneeded software will still need to be patched/updated even if the users doesn’t use it.


  • Computer labs where a room full of systems will all be identical.
  • Server deployments where all the systems will be identical.
  • Large scale deployments where all the systems will be identical (see a trend here?).
  • Time sensitive deployment when you need to deploy the OS and all software as quickly as possible to a system.


  • Windows Base OS & EVERYTHING else
  • Latest version of IE your applications support
  • Latest Windows Updates
  • Visual C++ Runtimes
  • Office (and latest updates)
  • Browser Plugins (Flash, Java, etc.)
  • Adobe Reader/Acrobat
  • Antivirus software
  • Management agents
  • VPN Client

Hybrid Images

A Hybrid Image is somewhere between a Thin and a Thick Image.  It would typically include applications that everyone gets that [hopefully] aren’t updated constantly like Office, Visual C++ runtimes, various agents, OS customizations like adding wallpapers, etc.


  • Smaller images than Thick Images since unnecessary software isn’t installed.
  • More customizable as unnecessary applications aren’t installed and the image can be customized to the needs of the user of the system at deploy time.
  • Sped up deployment since larger common packages like Office and Windows/Office Updates are already installed.


  • Still may require updates after deployment if the image isn’t updated regularly.
  • Slightly slower deployment if large packages are left out of image and need to be installed as part of the OS deployment process.


  • You have applications that all users get (like Office for example), but you still want the ability to customize the experience for each department or user.
  • You don’t want to constantly update images to update things like Java and Flash.


  • Windows Base OS
  • Latest version of IE your applications support
  • Latest Windows Updates
  • Office (and latest updates)
  • Visual C++ Runtimes
  • Management agents
  • Antivirus Software
  • Install everything else at OS deployment time

Create a [Mostly] Automated Reference Image in MDT – Part 4: Building the Image

In the previous parts of this series, I covered setting up MDT and all the customizations that are necessary to automate the process of creating a reference image.  Now that MDT is configured, we can capture our first reference image.

Continue reading

Create a [Mostly] Automated Reference Image in MDT – Part 2: MDT Setup

Now that you have MDT and the ADK installed, we need to set up a deployment share in MDT.  Regardless of whether this is a clean install of MDT on a dedicated box or your existing MDT server, we’re going to start off by creating a new Deployment Share that will be dedicated to reference image creation. Continue reading

Create a [Mostly] Automated Reference Image in MDT – Part 1: Prerequisites

When it comes to deploying an operating system to a computer, speed and accuracy are the name of the game.  If you’re installing applications that are common across your organization as tasks in your OS deploy or installing the latest Windows updates after the deploy finishes, you can save tons of time by using a reference image.
Continue reading