Benefits of using Windows Reference Image

March 6, 2017

Benefits of Using Windows Reference Image

In this post, you will get an introduction to what reference images are, key terminologies, strategies and a high-level view of deployment and ongoing management.

I am sure you have been in one of the following scenarios as either an end user getting a new device or an IT Pro looking after your device estate.

Written by

06 Mar 2017

End User; You get a new device, with no updates. Before logging in you have to wait for 100s of Windows updates to install. The updates should get done before the device landed on your desk.

IT Pro; You get a new device out the box to configure it ready for an end-user. For example, join the machine to the domain and install Line of Business Applications. Then at some point, you get hit with having to do a bucket load of updates. Doing these updates will kill your productivity and reduce the speed of getting the device out of the IT build room and to the end user.

The scenarios above are to give you a small slice of the pain, of course, your Reference Image can save you.

The low down on Reference Images

A Reference Image is used to take for example a vanilla Windows 10 image and customise it to fit your organisation. Your end game is to have a new Windows Imaging format (WIM) file to meet your company needs. For example, being update to date with patches and maybe the C++ Runtimes installed.

What other of customisation might you be able to make to the reference?

Install Windows updates, install applications, add Windows Features, for example, Hyper-V, add additional files and folders, tweak the Operating System settings and many more things.

The idea of creating Reference images has been around for a long time. For example, products like Symantec Ghost which used to be a very popular product that some of you may remember using (some people still may be) created what we called Golden Images.

Often in the Microsoft world, the terminology we use is a reference image, but the premise stays the same.

Reference Image Common Terminologies

When it comes to Reference Images, we have a few standard terminologies that you will probably hear when digging in your research or from your colleagues. The Terminologies are as follow:

Thick images.Thick images are monolithic images that contain everything your organisation would put on a device. Applications, Language packs, software updates, Drivers, Plugins, OS customisation and more.
Thin images.Thin images are as streamlined as possible. Containing the Operating System, Patches and some applications, for example, the C++ runtimes. The rest of the customisations and applications and done at the deployment stage.
Hybrid images.Hybrid images are a mix of the thin and thick image strategies, taking an 80% / 20% approach. The image may have core applications everyone in the organisation will need, Patches, OS customisations. The Benefit over thick images is that it will allow for customisation at the time of deployment.

Use cases for Thick, Thin or Hybrid Images

Here are some of my thoughts when you may want to use these different strategies:
Thick: If your organisations desktop environment is standard across all users. As an example, everyone has the same operating system, same applications and operating system tweaks. You could create a thick image. As discussed before this will mean compared to a thin image your deployment will be faster. However, this can raise management overhead for example if you have to maintain Java or Adobe products to the latest version the Thick image will have to keep being updated. The bottom line typically used in scenarios where a bulk of machines need deploying and are to be identical.
Thin Images: This will give your organisation a lot more flexibility but requires that you have some form of deployment technology say MDT or Configuration Manager to do the additional customisations at deployment. You will find traditionally this will take longer to deploy the image, but the benefits or being able to change for example what applications get installed based on the user’s role in the business can outweigh that. Commonly used in environments that require high customisation.
Hybrid: As this is somewhere in the middle of thick and thin images at has a few pros and cons from both camps. Typically this is used if you have certain applications that are standard across the company for example office. However still do not want to put applications like Java that constantly update as this will cause additional management. Then above that standardisation a hybrid image has much more scope for additional steps at deployment than a thick image.

Tools to Build a Reference Image

By now you have the foundations of reference images and conventional approaches to image management with pros and cons.

let’s look at how you can go about creating a Reference Image to fit your needs.

Like most things in technology there are plenty of ways to go about this but here are few mainstream options:

Manually – Configure the device to corporate standard and SysPrep
Microsoft Deployment Toolkit (MDT)
Microsoft System Center Configuration Manager (ConfigMgr)

For this discussion let’s take out the way of doing manually for now and focus on automation methods, we like automation! (I want to put it out there I would not recommend doing this manually)

With Both MDT and Configuration Manager we can automate what would otherwise be a time-consuming task, especially if you support lots of different operating systems within your environment.

One of the most common questions that I get now I have mentioned Configuration Manager and MDT is Which One should I use?

To not bloat this post out too much I found an excellent post from MVP Johan Arwidmark

The Battle – MDT V ConfigMgr and on the whole I agree with his points, so I put this as recommended reading.

Verdict: I am a fan of MDT, but from the pros and cons above you can make an educated decision within your organisation.

MDT Build Process

Before going further into the topic, I want to lay out a good rule to live by when you create reference images.

Always create them on Virtual Machines
Don’t use Physical Machines

Couple great thing about MDT if you do not already have it in your environment is that:

It is FREE, can’t beat that
Easy to setup

MDT Build Resources:

I am sure by now you want something more technical. These technical resources on building an MDT environment will get you started:

MDT Getting Started: https://technet.microsoft.com/en-us/itpro/windows/deploy/prepare-for-windows-deployment-with-mdt-2013

Create MDT Reference Image: https://technet.microsoft.com/en-us/itpro/windows/deploy/create-a-windows-10-reference-image

Ongoing Reference Image Management

One thing I see when out talking to customers is they have nothing in place to make sure that these Reference Images get updated. This of course means before you know you are a year behind on Software Updates. This would result in slower deployment times, and you are going to be making your WSUS or Software update point work harder. Other reasons you need may need to create new Images:
- One of the most obvious scenarios maybe if you are starting moving to Windows 10 from say 7 you are going to want to create a new WIM to support your operating system upgrade project.
- Core application may need updating or adding, for example, a new C++ Runtime could have been released, and you want to add it to your WIM Image.
I recommend you look at automating your whole process. Luckily with Modern virtualisation platforms and PowerShell, this can be made rather easy.
For example, you may want a process that automatically Creates your virtual machine, starts the machines runs the MDT Task Sequence and then creates your WIM. Once done the files could be copied to a share and the virtual machines deleted till next month.
There are a couple of really nice examples out in the community to get your feet wet into automating references images. Commonly you will hear this being called an image factory.
Mikael Nystrom Image Factory (Hyper-V): https://deploymentbunny.com/2017/02/23/powershell-is-king-building-a-reference-image-factory-v-3-2/
Jonny Radek Image Factory (VMware) http://deploymentresearch.com/Research/Post/560/Creating-Reference-Images-using-the-VMware-platform-Image-Factory-script-by-Johnny-Radeck

Outcome

If you followed through this post, you should be well aware of reference images and have some links to be able to start getting into creating your MDT environment and hopefully move on to the next stage and automating the whole process. You should find keeping those reference images from now on something you can do in your sleep.

Keep Up To Date – Join The Mailing List

The team are here to help

If there are any questions and want to learn more about PowerON’s services or Solutions, please get in touch and a member of the team will be in touch shortly.