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.

When capturing a reference image, I highly recommend using a virtual machine.  (Personally, I use Hyper-V, but a number of people out there also use VMware products.)  Why?  First, using a VM gives you functionality (namely snapshots) that you don’t get with physical hardware.  If you have manual processes that you have to perform for your reference image, snapshots will become very important to you (I’ll go into more detail in a later post).  Second, not all third-party drivers handle Sysprep correctly.  VM’s are typically very general hardware that, for lack of a better term, “just work” because the drivers for the important hardware (storage and networking) are included in Windows.  Quite a few hardware drivers out there for physical hardware like to install helper utilities that many times don’t get removed during Sysprep like they should.  Capturing on a VM eliminates the problem.

In the Hyper-V Manager, create a new using the defaults.  For Startup memory, you’ll probably want to make at least 1GB (if not more) available.  Also make sure that the network connection is connected to a network that can access your MDT Deployment Share for creating reference images.

Once the VM is created, right-click on the VM and choose Settings.  Find the DVD Drive under IDE Controller 1 and connect it to your LiteTouch Windows PE ISO image.01-capturing_the_reference_image

Click OK and then start the VM and the Windows PE 4 ISO should boot.

After it boots and loads, you should be prompted with a list of the OS deployment tasks that you’ve created.  Select one and click Next.04-capturing_the_reference_image

Next, change the name of your reference image (if necessary) and click Next.  05-capturing_the_reference_image

Now sit back and wait for the OS to install… 05-capturing_the_reference_image

After rebooting, the OS will come up and start installing updates (unless you’ve added additional application installs) and will probably reboot a few times.06-capturing_the_reference_image

After the updates are finished, Sysprep will run to generalize the image so it can be reused on other computers.   07-capturing_the_reference_image

Once Sysprep finishes, the VM will reboot back into Windows PE and will start capturing the WIM image.08-capturing_the_reference_image

When the WIM image creation completes, MDT will let you know that the process has finished.09-capturing_the_reference_image

You should now have a WIM image in the Captures folder of your Deployment Share.10-capturing_the_reference_image

Series Navigation<< Create a [Mostly] Automated Reference Image in MDT – Part 3: CustomSettings.ini and Bootstrap.iniCreate a [Mostly] Automated Reference Image in MDT – Part 5: Pause/Suspend the Task Sequence >>

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

  1. VCrn August 1, 2013 / 5:45 PM

    Can you go into detail on what network connection you set up for this to work? I’ve tried this several times and I am getting a network configuration error. Also, is your deployment share on the C: drive of your machine? or on the network?

    • Kyle Beckman August 1, 2013 / 8:13 PM

      In my lab environment, my MDT share is on the C:\ drive. In my production environment at work, it is on the D:\ drive (available via the network) of a dedicated MDT server. In both situations, the Hyper-V VM that I use for capturing the reference image is connected to a Virtual Switch on an External network which is the same network/subnet where the deployment share is located. The VM is getting an IP from DHCP.

  2. aa September 19, 2014 / 4:29 AM

    when should custom applications be installed on reference pc?

    • Kyle Beckman September 24, 2014 / 12:45 PM

      I typically create a new group before the “Windows Update (Post-Application Installation)” task and put all my applications there.

  3. Andrew October 29, 2014 / 3:29 PM

    Now that we have that WIM image do we create another Standard Client Task Sequence to Deploy that WIM image?

    • Kyle Beckman October 29, 2014 / 9:12 PM

      That’s correct… import the WIM file and create a new Task Sequence that uses the new WIM you created.

  4. Matt December 6, 2014 / 1:10 PM

    I keep getting BSODs when trying to install from the RefBuild ISO. Missing driver changes between fltmgr.sys and cdrom.sys.

    Changing the boot image to the Win7 ISO from Microsoft, it boots fine. Any ideas?

  5. Charles Roddy December 19, 2014 / 5:57 AM

    Instead of using a base Windows image and updating that everytime, can I change the OS to the last updated WIM everytime I want to run updates, or will this break something?

    Thanks for the great guide!

    • Kyle Beckman December 29, 2014 / 12:41 PM

      As far as I know, it won’t break anything. I’ve done this before and it worked fine for me.

  6. slade April 7, 2015 / 12:18 PM

    Presume no virtual environment is available. How do you capture the reference image properly after you have it setup, so that you can lay it back down later on to make updates/changes? Essentially run a capture without the sysprep, but what exactly needs to be un-selected/changed in the TS?

    • Kyle Beckman April 7, 2015 / 12:32 PM

      Every time I’ve tried doing this in a physical environment, the image doesn’t work on other hardware types. Grab a box, put Windows 8 on it, install Hyper-V, build your Reference Image.

      • slade April 8, 2015 / 9:55 AM

        Kyle thanks for the feeback. The hardware will be the same for the entire environment. The issue is the customer admins don’t have the pre-requisite knowledge to work with hyper-v and maintain snapshots and manipulate them and I cant hand hold them on it. That’s why I was asking about a way to grab a physical image without sys prepping so the site can lay it down later on if need be to update it.

  7. Kristian Slot May 7, 2015 / 9:44 AM

    Thanks for taking your time to write this tutorial. Everything went smooth, only bump for me was, that my deploymentshare could not be pointet to the root of a second drive added to my MDT-server. So just added a subfolder like: E:\MST\”Deploymentshare”.

  8. Erik February 11, 2016 / 1:04 PM

    I got as far as getting the image talking to WSUS, but it’s not pulling any updates. It pauses at “Searching for updates” and no network activity. in WSUS, I see the computer, and I have updates set for unapproved computers, but all I see on that object is “computer hasn’t reported in yet”.

    • Kyle Beckman February 12, 2016 / 9:16 AM

      I’ve seen the behavior you’re describing for the computer being in WSUS, but showing that it hasn’t reported in yet and, I don’t really have an explanation. I’ve seen the same thing happen on just a normal computer that’s had a forced check in… even though you know the box has checked in, WSUS doesn’t reflect it initially for whatever reason.

      The default retry for Windows Updates in MDT is something like 10 if I remember correctly. If the computer can’t talk to WSUS, it should continue on and give you a Warning at the end of the deploy. Does it eventually error out? I’ve seen this behavior before with brand new WSUS servers. If the WSUS server is new, it most likely hasn’t downloaded the updates that are needed by the client system. If that is the case, WSUS is downloading all the updates. Depending on the speed of your Internet connection that could take a while.

      • Erik February 12, 2016 / 11:48 AM

        I’m not seeing any glaring errors in the logs – the task sequence just goes through the steps like there aren’t any updates being given out. It goes through both passes (pre and post application), sits at ‘searching for updates’ for a while, and then proceeds through the sysprep.

        The odd thing is, I tried running it again last night, and it actually pulled updates from WSUS.

        I don’t know if it’s a setting hidden somewhere, but I’m seeing something like ‘default time =22″ with the frequency of when it checks for updates. So while MDT might be saying “searching for updates”, nothing is actually happening on the box.

        Honestly, I resorted to this.

        – link redacted –

        One of the proposed solutions was to install a hotfix, which I did. Strangely enough, it did grab updates, but not all of them – syspreped and captured. So, what I’m trying now is to deploy from that updated image and grab the remainder of the updates but now I’m running into the same problem – Not getting updates at all.

        Frustrating 😛

Leave a Reply