Deploying Windows 7 with WDS and MDT 2010 – Part4

This is going to be the last part of these series, and in this part I’m going to discuss how to deploy a captured image, and create rules that will automate those client installation wizards.

To start let’s import the captured image in MDT and create a task sequence for it, so right-click the Operating Systems folder in MDT and choose Import Operating System.

Select the Custom image file option.

Here select the image we captured in part three. If you saved the image in the default path, then is located in the Captures folder in your Deployment Share. If you want to move the image instead of copying it check the box Move the file to the deployment share instead of copying them.

On the Setup screen select the first option, Setup and Sysprep files are not needed. Since we already have a Windows 7 operating system imported in MDT with full set of source files (not a .wim image) we don’t need the second option. The deployment wizard needs the Setup.exe and other files from the Windows 7 DVD for deployment. If your MDT Operating Systems folder is empty, and no operating system with full set of source files is present, then you will need to select the second option Copy Windows Vista, Windows Server 2008, or later setup files from the specified path. The version of the operating systems must match, meaning you can’t have a Windows Vista or a Windows 7 Starter image with full set of source files and you deploy Windows 7 Enterprise.

Specify a directory name for the image and click Next.

Click Next on the Summary screen then Finish to close the wizard.


Now let’s create a task sequence for this image. Right click the Task Sequence folder and choose New Task Sequence. Complete the required information in the General Settings page and click Next.

Choose Standard Client Task Sequence and continue the wizard.

Select the captured operating system and click Next.

Do not specify a product key here, we are going to use rules for that in just a moment.

Complete the boxes on the OS Settings and continue.

Provide a local Administrator password and click Next. Finish the wizard.

If you want to update the Deployment Share, don’t do it, because we need to create some rules for automation. To create those rules right-click the Deployment Share name and choose Properties.

Here click the Rules tab, and as you can see we already have some rules, but they are not enough for our environment.

I’m going to paste here the rules I am using for my Windows 7 deployments, and you are welcome to use them for your environment. Remember, this rules are not going to work if you deploy Windows Vista or Windows XP, because the wizards are different on those operating systems. Modify this settings according to your environment; the last line is if you have a WSUS server in your network.


_SMSTSORGNAME=Adrian Costea's blog.
TimeZoneName=GTB Standard Time


We are not done yet, the log on-screen still appears when the clients boot from the network and try to connect to the Deployment Share. To resolve this, click the Edit Bootstrap.ini button on the Rules tab. Put the following text at the end:



Again modify the settings according to your environment. Close the Bootstrap.ini file and save the changes. Click OK on the Deployment Share Properties.


Now update the Deployment Share using the default settings. As you can see in the screen, the wizard detected some changes and it needs to regenerate the boot images.

After the update process is done, we need to replace the boot image in the WDS server with this new one, the one that contains the log on credentials to the Deployment Share. Delete the old image from the WDS server, then right-click the Boot Images folder and choose Add Boot Image.

Choose the x64 boot image and finish the wizard. Sometimes the new boot image is not recognized by the WDS server; in that case I just restart the WDS service.


Now is time to deploy and see how it works. I recommend you test o a single machine, and if everything works well, deploy to the rest of the systems. Force a client to boot from the network, and after the WinPE loads into the client memory, the system starts formating and copying files automatically, skipping the deployment wizards. This is what we wanted, a fully automated deployment of Windows 7.


Looks like we had a success here, and I want to thank you for bearing with me all this time. Feel free to ask any questions.

Want content like this delivered right to your

email inbox?

24 thoughts on “Deploying Windows 7 with WDS and MDT 2010 – Part4

  • 05/05/2014 at 19:00

    I just wanted to say that this site basically saved my skin. I recently took a new job and the WDS/MDT server had to be completely redone. To add to the pressure my new boss just ordered 300 new PC’s and needed the imaging process up and running asap. I used this guide and along with my own knowledge, was able to get the process running like a finely tuned American V8 muscle car!

    Many, many thanx for your blog. I can’t say thank you enough!

  • 23/04/2014 at 03:45

    Awesome writeup….I was recently assigned the task of managing the WDS/MDT server and I basically needed to start over as the previous admin did a poor job. In part 4 you show the final process, which I like. However, can you limit the amout of wizards that run and also prompt for a computer name that will apply to the new build and then join it to the domain without interaction?

    • 23/04/2014 at 07:47

      Off course you can. If you want to join your workstations to the domain you can put this in the CustomSettings.ini (the Rules tab in MDT):


      Just replace the domain and credentials with your own. Cheers…

  • 31/10/2013 at 01:10

    Excellent articles.

    Although updating the Deployment Share is primarily for boot wim purposes, does it have any impact on Task Sequences ts.lxm or unattend.xlm modifications?

    I’ve heard from some people that running the update has fixed some other strange deployment issues.

    What is your opinion?

    Thanks in advance.

    • 31/10/2013 at 08:05

      Yes it does. I update the deployment share after any modification to a task sequence, rules etc. I recommend you do the same and everything will work smoothly.


  • 18/05/2013 at 01:05

    Hello, actually I have a question.
    I’m deploying a customized image and using WDT DB for naming and adding to a domain, but the process for installing the image works fine, but the naming process didn’t work, there is a setting in the bootstrap or something that you can help me with ?

  • 08/04/2013 at 16:07

    Sorry for the crazy you saw up there, things were a little hectic with trying to revamp my company’s website and I was running short of patience on this imaging process. The problem I had above was that I was PXE booting into the PE environment to do the capture rather than launching it from Windows and letting it reboot into the PE – figured it out after rereading through the steps and was able to capture the reference system one time, but now I’m facing a new issue.

    After taking an initial image, a coworker pointed out that I had forgotten to install a patch. I applied the patch to the reference system (a Hyper-V) and attempted to recapture it. After it asks for domain credentials and and what to set the Admin password to I click Begin. A couple of progress bars flash by the screen (too quick to read them) then the ‘completed successfully’ screen appears saying that there were no errors or warnings, even though it never went through the Sysprep step and definitely never booted into the PE environment to do the actual capture. I rolled back to a snapshot I took before the initial sysprep and got the same result. Is there something I have to do on the server end that will allow me to run a second sysprep and capture on the reference system? Thanks again.

    • 09/04/2013 at 17:12

      Hi again,

      There is Microsoft TechNet article that describes the process here, but I don’t know how it works because I never used it. I usually use the task sequence or rules to apply updates during deployment from a WSUS server.

  • 29/03/2013 at 18:29

    Again, love this article, but I’m having an issue now. We recently set up WDS and MDK on our central server rather than running it from my desktop as I had previously. When attempting to do a new capture, I’m now getting a failure that says “There is not enough space on the disk.” The image we’re trying to capture is about 21GB on a 30GB virtual drive (Windows 8 Hyper-V) and the server that I’m trying to capture to has 57GB on the drive, not sure why this is coming up?

    • 29/03/2013 at 18:44

      In troubleshooting, we found that MDT appears to have created the folder structure correctly in the Deploy folder, but that everyone has the read-only flag set. I imagine it won’t bother anything if I turn this off and hit apply? Thanks.

      • 29/03/2013 at 18:49

        Nevermind, disabling the read-only flag had zero effect. I’m stuck at this point.

    • 08/04/2013 at 14:06


      When the message appears do a Shift+F10 and verify the volumes space using the terminal, and you should see which drive is out of space.

  • 27/02/2013 at 12:52

    Many thanks!! All the deployments articles are great and they were very helpful to us.
    Just one more question: We didn´t use any customized rule in the last step, we just created a new task for the deployment and updated the deployment share.
    Do we need to replace the boot images on the WDS or we can keep using the boot images we used to capture?

    Thanks again!!

  • 06/02/2013 at 19:30

    Great article, but there seem to be a lot of steps. Is there any reason I can’t just sysprep an existing computer and create a deployment from that? Do we have to push the base Win 7 installation before customizing it? Thanks!

    • 06/02/2013 at 22:36

      No, not at all. You can sysprep an existing system, capture then deploy. I’ve made the deployment part for those that start from the begging.

  • 15/01/2013 at 20:00

    I’ve been put in charge of WDS and MDT at work, this is uncomplicated and very informative. Many thanks.

  • 11/01/2013 at 10:56

    Thanks Adrian, very helpful articles about WDS


Leave a Reply

Your email address will not be published. Required fields are marked *