Automatically Update your MDT Reference Images

Typical workflow for handling reference images in MDT:

  1. Import OS install media from an ISO you downloaded off Technet / Microsoft Volume Licensing
  2. Build a task sequence to deploy it (I call this my Build Image task)
  3. Capture it to the Captures folder on your deployment share
  4. Import the captured OS
  5. Build a task sequence to deploy it (I call this my Deploy Image task)
This looks mundane, but doing steps 3, 4 and 5 sucks! Trying to remember exactly how you customized your task sequence is no way to live when it’d be way easier to re-use the existing Deploy Image task when updating your reference image.  I also would love it if I’m not the only one who can perform updates to reference images ….so I figured it all out and now I live happily every after!
It’s a little extra work up front, but here’s how you can turn updating your reference images into a one step process that anyone could perform:
  1. Create a script called Relocate.cmd in your Scripts directory off the Deployment Share that contains the following one-liner:
    • move /Y "%DEPLOYDRIVE%Captures%1.wim" "%DEPLOYDRIVE%Operating Systems%1"
  2. Create your Build Image task. Keep the ID short. For example, let’s say we’re deploying a general purpose Windows 8 image.  My Task Sequence ID that builds the reference image is 8_GP
  3. Run this task sequence and capture your reference image. Make sure to save it to the Captures folder and name it after your task sequence. For my example, this is .Captures8_GP.wim
  4. This one time, you’ll need to use the Import Operating System wizard. Be sure to name the folder for this operating system to match your task sequence that builds the reference image. For my example, I have .Operating Systems8_GP8_GP.wim
  5. Go back into your Build task sequence and add a custom task that runs the following command as the final step (you don’t need to set the Start In value):
    • cmd /? %SCRIPTROOT%Relocate.cmd %TaskSequenceID%

      Note: Do to ever-vigilent WordPress Security, I had to change out the letter C to a question mark. Pleaee change it back when trying on your own.

  6. Create your new Deploy Image task sequence using the OS from the previous step. I recommend that for your Task Sequence ID you use something like 8_GP_DEPLOY
You’re done! At this point, to get the latest Windows Updates into an image, just run your “Build Image” task  sequence – the WIM is captured and automatically replaces the OS that gets deployed when someone runs the “Deploy Image” task.
There is one word of caution: Significant changes to the OS in your WIM (Service pack, new IE version, etc.) might break the Deploy OS task. If that happens go through step 3 and step 6 again so that the MDT can “refresh” what it knows about the deployment OS you’re using


Microsoft Deployment Toolkit trickiness

So over the past few days I learned a very long and slow lesson about why the Microsoft Deployment Toolkit only has instructions for using local storage. Turns out, there’s either a bug in WinPE or in certain storage filers’ (NetApp) implementation of CIFS.   Due to one of those two factors, connecting to network storage from WinPE is buggy. It works just enough to make you want to blame everything else in the universe because it should “just work”.

Well, after I got over that, I was still stuck with a server with no available local storage, and a huge NetApp volume sitting there doing nothing. So I decided to get tricky. We have good network performance and an awesome storage admin, so I decided to virtualize my deployment share. I created a fixed disk 200 GB VHD file and had it mount to  path on the local storage. Using the Disk Manager GUI in Server 2008 R2 made this easy, but it also could have been done via diskpart if you want to go all CLI (I have yet to see straight-forward PowerShell stuff for working with VHDs directly).

This was cool and so far has been working pretty well, although I have yet to do an in depth comparison of deployment speeds when I have more than one or two clients doing an install.

One final challenge I had was that on a reboot the VHD would disappear until someone went and remounted it. I fixed that by doing the following:

  1. Create a script with two lines (don’t include the 1. and 2.) and save it in the same folder on the NetApp/filer/whatever as your VHD file. I called my “Dev.dp” because this is a Dev environment and the script will be run with DiskPart
    1. SELECT VDISK FILE=”\uncpathtoyourfile.vhd”
  2. Open Task Scheduler and in the Actions pane pick Create Basic Task…
  3. Give your task a name. For the trigger, pick “When the computer starts”
  4. For the action, choose Start a Program. Use the following info:
  5. Program/script:  c:windowssystem32diskpart.exe
  6. Add arguments:  /s “\uncpathtoyourDev.dp”
  7. Click the check box to open properties when you’re done. In the General tab, change these settings:
    1. Use Change User or Group to set an account that has permissions on the NetApp. For me that was MYDOMAINsvc.deploy
    2. Pick Run whether user is logged on or not
    3. Check Run with highest privileges
  8. In the setting tab, you may want to back off the failure conditions or have the task retry if it fails (but don’t forget if for some reason it was already mounted, the task will fail because of that)

At this point you’re all done. When diskpart mounts the VHD it will automatically restore the mount point or drive letter that was used last time it was mounted. You can now use a filer to store your deployment data, but have it behave as if it were local storage because that’s the only way your deployment server will work. And your system can survive a reboot without manually re-attaching the drive!



I’m Still Alive… I think

Yes, it’s been quite a few months since I blogged, but sometimes life is just busy and you have to concentrate on what matters most. I’m in the midst of some back-to-back training – it’s nice when class gets done early, but since I just moved it’s not worth fighting traffic to head out – so instead here I am blogging. And hopefully I’ll keep it up without having to make a New Year’s resolution!

Virtualization is cool stuff. Last week I finished up a foundational class all about VMware’s vSphere/vCenter products. It wasn’t really “new” to me, but they went really in depth into enterprise storage fundamentals and how to hook up SANs. That’s actually where I got the most benefit! And now this week I’m learning all about Puppet. I’m pretty jealous because we’re diving headlong into wrangling our linux environment and getting things properly managed. Now if only I could convince someone that doing the same with Windows is just as important!

Over the past few months I’ve been prepping my group (Systems Engineering) for taking ownership of our company’s AD environment (previous owner being “….uhh?”). Our boss is pushing hard to align what our customers want/need with specific services that IT provides. And at the same time we’re aligning our department’s strategy on managing those services in a Plan/Build/Run model. I have no idea if it’s an actual thing, but I like the premise – We have a team that plans it out, another that builds it, and another that does daily run tasks.

As an Engineer I’m excited because I might get to be a little more distanced from the daily break/fix distractions and do more quality ‘building’ work.  My real question is where the line is between Planning and Building, but whatever.  I ended up writing about 13 pages of a Word doc that spells out anything and everything related to the AD service and is I believe what all our future projects should embrace when trying to match this PBR model. If we stick with it, I think there’s actually some hope of getting out of technical debt and eventually becoming a much more valuable asset for the business teams our IT group supports.



You Can Lead a Horse To Water…

I recently got back from my trip to Las Vegas for a Symantec conference.  I never really thought that Symantec would be able to throw an event that would hold my interest and actually get me exited, but they pulled through. Just being in the presence of so many other companies struggling with CMS implementations and deployment strategies was a big morale boost for me.  I’m not alone, and the difficulties in getting my company to the Utopia that our Symantec sales rep promised us are common and (more importantly) surmountable.

But not two days back and I’m facing the reality of how things are. We have four Helpdesk teams, all with their own way of doing things.  Someone emailed me and said “Hey Slowest Zombie, we got some new VAIO laptops in and it’s a pain in the butt to get them rolled out to our end-users. Can’t you get this automated like everything else?” Well, my answer was not short. I could have said yes for this one new laptop, but what about the next new laptop and the one after that? I brought up the fact that the end-users we support are currently given the choice of whatever laptop they want with no limits. The complexity of laptop drivers, dealing with custom system image discs, and the fact that (especially with VAIOs) there’s rarely more than two users in the company who end up ordering the same specific laptop brand and model all adds up to the fact that the time to automate the laptop deployment process will probably never generate benefits greater than just dealing with each one manually.

It’s very disheartening to hear the response “This is how we’ve always done it and how we’ll keep on doing it forever” from one of the most senior helpdesk staff members. It’s completely understandable – their customers have come to expect that type of flexibility – but someone somewhere signed a VERY expensive contract that said “Let’s buy Altiris and in the end we’ll save money by making things efficient.”  Well, I’m offering up a path to get there, but no one is interested in even talking about possibilities or discussing things that would change the way they approach support. It makes me wonder if I’m just spinning my wheels trying to engineer a solution that no one really wants, and all this rant is just about dealing with one of the four helpdesk sites – I’ll be honest and say I’m not looking forward to even attempting to build a process that works for all of them.



A Beginner’s Guide

On more than one occasion I’ve been asked where to start when it comes to automating Windows OS and Software deployment processes. I’ve never had a good answer because I couldn’t ever find a one-stop all-inclusive solution.  Most of my experience and expertise has come about by ramming into a wall over and over until I found a way through.  My goal in this post is to help my friends and colleagues who are looking to get started.

Your Environment

Before we get into the how or why, let’s go over what I imagine your current environment might be like. It’s hard to say where we’re going if we don’t know where we’re coming from, right?

  • You’re involved in deploying/maintaining OSes and software
  • Roughly 5-500+ employees are under your jurisdiction
  • Primarily a Windows shop. If you haven’t already moved to Windows 7, it’s looming over you like a black cloud
  • Triple Squeeze Play: Requests are up, responsibilities are increased, budgets are down
  • Hardware could be standardized or could be all over the place: Dell, HP, custom, whatever’s on sale at Best Buy…
  • OS deployments could happen through the 1997 version of Norton Ghost to “stick a CD in there and wing it”
  • You have a list of software to install by person/department, either officially or in your head

Your Goals

So you know what you’re up against, but maybe you’re not quite sure what would make life better for you.  While the business really is the ultimate dictator of your goals, it’s safe to agree on some commonalities:

  • Faster
  • Cheaper

You’re in luck! Without cutting corners or without racking up bills for software / training / professional services, you can be the hero. You may have to dedicate some personal time to pulling this off, but trust me: the payoff will be worth it.

The Plan

There’s two parts to this – the OS deployments and the Software deployments.  But both parts are going to use the same tools.

Setting up your OS and Software deployment server

Before we even get into this too far: If you don’t have Volume Licensing for your Windows licenses, but you support enough people to where you’re reading this article, it’s time to change your ways.  Unfortunately I don’t have personal experience with establishing a volume license agreement, but you can check out Microsoft’s website here. If people chime in and recommend additional resources I’ll be happy to post them here later. Without volume licensing you’re going to have a tough time automating OS installations, as well as Office installations. I think the license agreements for consumer/retail licenses prohibit you from taking advantage of a lot of this stuff anyway.

Now that we’ve got that out of the way, let’s gather up some resources we’ll need:

  • A machine that you can designate as a Deployment Server. In my first setup I used my own desktop PC, running Windows 7 x64 Professional. I highly recommend using this OS (or Enterprise or Ultimate or Server 2008 R2), but if you can have a machine around that can be dedicated for this that’d be great. For all other bullet points in this section, assume I’m telling you to use this machine unless I specifically say otherwise.
  • This machine will need to be on a network that other computers will have access to. Whether it’s expensive Cisco gear or a $30 refurb router from Woot, set up whatever it takes to have DHCP, internet access and (optionally and if applicable) access to your Active Directory domain to bind machines as part of the deployment process. This doesn’t have to be the final network that the machine will connect to when you hand it off to your customer. It could be its own little “build network” that’s just for loading systems before shipping it to Timbuktu.
  • Get some storage space – I recommend a 500 GB drive added as a secondary to the OS/boot drive. Using a pair with RAID 1 and/or making sure you take regular backups would be great but I doubt it’s going to kill you if things go south and you have to recreate everything, especially this early in the game. For something really simple, you can get by with 50 GB or less, but particularly with hard drives I believe that good decisions now will save you a lot in the end.
  • Download and install 7-zip (32- or 64-bit, whatever works). Get the MSI installer version – it installs just like an EXE file but will be used again later to demonstrate automating software installs. 7-Zip s a WinZip / WinRAR alternative that’s free. The GUI for it sucks, but you won’t be using it for this and everything else about it is great. Keep the installer saved on that extra hard drive in its own little folder. In fact, go ahead and download both the 32-bit and the 64-bit versions into separate folders. Do it even if you’re completely sure you’ll never see a 64-bit system at work (I hope the opposite case is true, but regardless to learn good software deployment we want to have both versions for this walkthrough)
  • Have your Windows install discs and product keys handy, or (preferably) download them from Microsoft’s Volume Licensing site. There’s no need to burn the ISO file if you download it – you’d just be copying the data right back onto your server anyway.
  • Either have some blank CD-Rs around, or a thumb drive with at least 256 MB total space. The thumb drive will be a million times better than CDs. I regret not discovering that earlier.
  • Download the Microsoft Depoyment Toolkit (aka MDT). Get the 2010 64-bit Update 1 version. Seriously, even if you are only ever going to deploy 32-bit OSes, just do it.

You’ve now collected all the tools you need. Let’s put things together…

  1. Get your deployment server machine set up – Install the OS and updates (SP1 seems to work just fine from my experience so far), have your extra hard drive installed and formatted. Install 7-zip too, accepting default options. Don’t forget anti-virus protection, either  – you will be sharing out resources across the network and it’s a vulnerability that I’ve seen viruses exploit in my own workplace.  Optionally, bind this machine to your AD domain if it’s an option. This makes controlling access to your deployment server easier.
  2. Get your Windows install media onto that extra storage space. If you have ISO files, select them all and right-click choose 7-Zip > Extract to * to create a subfolder for each ISO and dump the contents to it. If you have CDs/DVDs, just start copying everything off each CD into a subfolder for each OS.
  3. Install the Microsoft Deployment Toolkit, accepting all the defaults. Remember that in the following instructions that when I say”Deployment Server or DS I’m talking about whatever machine has the MDT installed.
  4. Launch Deployment Workbench from either the Start Menu or by running C:Program FilesMicrosoft Deployment ToolkitBinDeploymentWorkbench.msc – MDT is a management console snap-in, so if you’re familiar with AD management tools or Windows administrative tools the layout will be familiar to you.
  5. In the left panel, expand out Deployment Workbench > Information Center > Components. In the upper-middle section highlight Windows Automated Installation Kit (x64) and click Download in the lower-middle section. If there are any other components listed as Required, download those as well, and install them afterwards accepting all defaults.
  6. Highlight Deployment Shares in the left panel, and in the right panel click New Deployment Share. Use the following options while going through the wizard:
    1. For the Deployment share path, use the extra hard drive you added. The Folder name can be whatever you want. Chances are you’re going to have something like E:DeploymentShare. What this does is establish the home base where all your deployment files live.
    2. The Share name is what you’ll use to connect in to access the data from step 1. For this walk-through I’m going to leave it the default, but personally I like to pick something short like DS$. In case you’re not familiar, the $ means that this is a hidden share – if you use explorer to browse to this computer from another, only shares without the $ will be listed. You should take note of the UNC path, which is just \hostnamesharename$
    3. The Deployment share description can be whatever you want. I’m going to leave the default MDT Deployment Share name, but you might want to use something like Company XYZ Deployment Share
    4. For Allow Image Capture, Allow Admin Password and Allow Product Key, leave things default just to keep it simple. Finish out the wizard.
  7. You need to generate some boot media for your target devices. Instead of booting from a Windows install CD or a boot floppy, the Deployment Workbench will help you create custom CDs or bootable thumb drives. You will have separate boot media when installing 32- and 64-bit OSes. If you’re company uses both, you’ll need to create install media for each.
    1. In t he left pane, right-click on the Deployment Share you created (the level just below Deployment Shares with the custom name of your deployment server). Choose Update Deployment Share and accept all defaults for the wizard.
    2. In Explorer, browse to the path of your deployment share. In my case it’s E:DeploymentShare – In there you’ll see a folder structure similar to what you see within the Deployment Workbench. In the Boot subfolder, you’ll find the .ISO files you just created. Burn to a CD-R by double-clicking, or right-click it and use 7-zip to extract to a new folder and follow the next few steps to make a bootable USB drive. If there’s important data on this drive, save it out somewhere first – you’re going to be erasing the whole thing.
    3. Attach a thumb drive, and then open a command prompt by typing cmd into the Start menu search bar. In the shell type diskpart. You may be prompted about elevating privileges, go ahead and accept.
    4. At the diskpart> prompt, type list disk to see all attached physical and USB drives. Identify your thumb drive based on the size and type select disk #, filling in the number for your drive. If you’re not sure about this stop now. Drive zero is more than likely your C: drive and the next step will instantly erase all partitions on that drive.
    5. Type clean to clean out partition data. This is now a raw, unformatted drive. Now type create partition primary and then active to make a partition and flag it as bootable.
    6. Type format fs=ntfs quick to format it, and assign to automatically give it a drive letter. You’re all done and you can exit.
    7. Use explorer to copy the extracted contents of your LiteTouchPE ISO to your thumb drive.

Your environment is now set up. It doesn’t look like much just staring at the screen, but you have all the right framework to deploy operating systems and software easier than ever. There’s just one last thing to do as a best-practice security measure for your server. Open up your hard drive that contains your Deployment Share. Right-click on the DeploymentShare folder (if you went off the beaten path in the previous step, this folder name might be different) and choose Properties. In the Sharing tab click Advanced Sharing… and then Permissions. Click Add… and give either yourself, the Administrators, or a domain admin group Full Control. Then Remove the Everyone group. This prevents random joes from accessing your deployment server which is important for security and to prevent end users from gaining access to your deployment media where they have the potential to wipe out their hard drive by clicking willy nilly all over the place where they shouldn’t.

Adding your first OS and Software to the Deployment Server

If you’ve been comfortable with everything up to this point, the rest is going to be just as much of a breeze. Let’s start by putting your Windows install media into the Deployment Server. In the Deployment Workbench left panel, expand out Deployment Shares < MDT Deployment Share and click Operating Systems. Remember that in your cause the deployment share might be called Company XYZ Deployment Share.

To keep everything as simple as possible, let’s keep our operating systems separated out by folder (even if you only have one OS to deploy for now). In the right panel, click New Folder and complete the wizard.  Make a folder for each OS and be descriptive in the name. Good examples are:

  • Windows 7 SP1 Enterprise x64
  • Windows 7 Professional x86
  • Windows Server 2008 R2 x64
  • Windows XP SP3 x86

After you have your folders, use the left pane to go into one and then click Import Operating System from the right pane. Use the following information to answer the questions in the wizard:

  1. OS Type: Use the Full set of source files. This means you’ll be using a stock vanilla OS. When you get more advanced you may decide to start using custom image files, but that’s a topic for another day.
  2. Source directory: Remember way back toward the start of this whole project when I had you gather your Windows discs or ISOs and copy them to folders on your extra hard drive? Well, now’s when you need them. Browse to the parent folder containing your OS, and click the “Move the files to the deployment share instead of copying them.” This will save you time and disk space, but remember if you end up deleting this OS entry you’ll have to re-copy or re-download the files again later. I’m not sure but I think if you’re pulling OS files from a network share rather than local, you won’t have the option to move instead of copy.
  3. Destination: You can leave it as default if you want. Since I’m using Win7 disks that have SP1 included, my folder name ended up being Windows 7 x64 SP1.
  4. Finish out the wizard. Notice that you might have more than one OS that’s been added. That’s because Windows 7 DVDs can include all the versions from Basic to Ultimate. Server OSes also will generate several. But XP, and Win7 Enterprise discs will just add a single entry. Right-click the new entry for your new entry, and clean up the name.  I renamed mine to be “Windows 7 Enterprise x64 SP1 – Just pick something unique that is easy to find in this list of opearting systems later. If you had more than one entry added in this step, just pick the on you’ll likely be using the most and run with that for the rest of this tutorial.

That’s it! You can repeat this for other OS install files, but your deployment server is now ripe with OS deployment goodness. But before we work on actually pushing these installers out, let’s throw some software in there.  We’re going to start very small.  Let’s go over some quick background info on how installations happen:

Most application installers come to you in the form of a .EXE file. When you run it, usually the first thing you’ll see is a quick progress bar before you even get to answer questions about what directory to install to, what the EULA is, etc. It turns out that usually a .EXE file when used to distribute files is actually a gussied up .ZIP file. That little progress bar? Yep, it’s unzipping the actual install files, and then launching the actual installation program. Microsoft created a standardized way of installing software and it’s done through the Microsoft Software Installer. On every Windows machine you’ll see in the WindowsSystem32 folder there’s an application called msiexec.exe. That program is the helper that presents the installation wizard, makes sure files go in their right place, that the registry updates correctly, etc. Software publishers simply take their files and settings, create a configuration file ending in .msi to tell Windows exactly what to do with those files and settings, and optionally smooshes it all into the .msi file or in .cab files to keep everything orderly. So when you double-click “7-zip.msi” to install it, you’re actually launching MSIExec.exe /install “PathTo7-zip.msi”. If you don’t believe me, uninstall 7-zip and try installing it through MSIExec: In the start menu search bar type MSIExec /i “E:7-zip.msi”.  Remember that your path and filename might be different, but you can figure it out. You’ll get the same wizard as before. Now let’s really blow your mind: Uninstall again, but this time run MSIExec /i “E:7-zip.msi” /passive. You just installed automated an application installation. Admittedly they’re not all this easy, but a simple rule of thumb is that if you can automate an installation on your own machine, making it into something that can be deployed  is probably just as easy. For the full list of options, use MSIExec /?

Since we just figured out the secret to automating a 7-zip install, let’s use it as our first software deployment. In my workplace I always install it and encourage its use to get away from the old stodgy WinZip/WinRAR apps.

  1. There’s one little bit of set up in our environment, but it’s really more of a Best Practice than a hafta. Open the Deployment Workbench and go to Deployment Shares > MDT Deployment Share > Applications. Create a New Folder and name it Components. I’m not going to explain the reasoning for it in this post, but you might figure it out by the end of this tutorial anyway.
  2. In the folder you just created, make another one called 7-Zip. Go into that folder and click New Application. Use the following to answer the questions asked by the almighty Wizard:
    1. Application Type: You are using the .msi file you just downloaded, so pick Application with Source files.
    2. Details: Leave Publisher blank. For application name type 7-Zip x64 or 7-Zip x86 as appropriate. For version and language you can leave them blank but I recommend filling them in. At the time of this post, 7-Zip is on version 9.20
    3. For the Source directory, browse to the folder containing your installer and pick the option to Move files instead of copying them.  Using Explorer, double-check that the folder only contains the single .MSI file. Don’t have the 32-bit version at e:7zip and the 64-bit version at e:7zip64. And make sure you do point to the folder that actually contains the installer and not a directory that contains a directory that contains the installer. No funny business.
    4. The default Destination should be just fine.
    5. For Command Details, use the following Command line: MSIExec.exe /i name-of.msi /passive. The /passive flag means “show a progress bar but don’t ask me any questions during the install.” I always prefer this over the /quiet flag that completely hides everything including the progress bar.
    6. Complete out the wizard. Your first automated installer is now ready, but first let’s get tricky. Double-click on the entry you just created.
    7. In the General tab, check the box for Hide this application in the Deployment Wizard. In the Details tab pick This can only run on the specified client platforms and in the list below check All x86 Pre-Vista and All x86 Vista and Newer if this installer is the 32-bit version, or click the appropriate x64 boxes.  These are the last 4 items listed, and the point of this is to say “Hey, this is a 32-bit app so only let it be installed on a 32-bit OS”. We’re picking these particular boxes to make it available for XP and Win7 OSes. Click OK
  3. Repeat step 2 for the other 7-zip version.  You should now have a 32-bit and a 64-bit 7-Zip installer in the Components7-Zip folder.
  4. Now you’re going to create an Application Bundle that doesn’t hold any particular install files, but creates a list of software to install as if it were all a big single item. Go back up to the main Applications folder and create a new application, similar to before. But this time you’ll use some different options:
    1. This time pick Application bundle
    2. The application name will simply be 7-Zip. Fill in the version number and complete the wizard.
    3. Go right back into this bundle by double-clicking it. In the Dependencies tab, click Add, and (one at a time) add each 7-Zip installer from the Components folder. Then click OK.

You’re all set! You don’t know exactly how it will happen yet, but I can tell you that with this set up you’ll simply have to pick “7-zip” to install, and the correct x86 or x64 version will be put into place.

So now we’ve got hardware and software loaded into this stuff – can we finally get the part where we actually use the deployment server?  Well…  almost.  One last important section to look at: “Task Sequences”.  Task sequences are little mini-wizards that we run on client machines but are prepared on the server. It’s a questionaire that asks: “What OS do you want to install, what software do you want, what should the computer name be, etc?” . Follow these steps to set up a simple task sequence:

  1. In the Deployment Workbench left-hand pane go into Task Sequences and pick New Task Sequence. Use these Wizard settings for the “General Settings” page:
    1. Make up a Task sequence ID. I like to base mine off the OS I’m installing with it, but you have limited space. I’m using WIN764ENT because I want this task sequence to deploy the Win7 Enterprise OS I added earlier.
    2. For the Task sequence name, use Deploy Windows 7 x64 Enterprise from Disc, but change the Windows version to whatever you’re using. The word Deploy is important because later you might add tasks that don’t deploy an OS but just add software or do other things (the sky is the limit really). And the “from Disc” part is important in case you get more advanced and want to make a custom image of Windows with updates and software pre-installed instead of the stock image that comes with the official media.
    3. In Task sequence comments, put something like Last Modified On with the date. If you get a lot of task sequences later on, sometimes it gets hard to keep track of what the newest one is.
  2. In the Select Template section, use Standard Client Task Sequence unless you’re installing a Server OS in which case use Standard Server Task Sequence.
  3. Pick the OS you’ll be deploying, with one exception: for XP or Server 2003 you need to put in your product key and select the bottom option
  4. Fill out the rest as desired and complete the wizard.

Holy crap, you’re done preparing the server! We’re on the home stretch now.

Deploying your OS and Software

Time to get ahold of a victim machine and load an OS. Make sure to back up any important data on this target machine first – The primary hard drive is going to be erased. To keep things simple I recommend making sure only one hard drive is attached. If you can format it before hand or use a new/blank drive even better.

I’m not even going to detail out the steps to do the deployment – it’s so easy! Just check the following things on this target machine:

  • It’s connected to the same network as your deployment server
  • You have inserted either the burned CD or the USB drive we created earlier, and configured it to boot one time off this device.
  • After you boot up, you should see Windows loading and eventually end up looking at a wizard. At this point, remove the boot CD/USB dongle – otherwise, after the OS installs and the system restarts you’ll get a weird error because you were supposed to boot into the newly installed OS and not the custom boot media.
  • Use your best judgement in answering the questions asked by the wizard


If you end up needing to do some troubleshooting, here’s some starting points:

  • Network Drivers – If your custom boot media doesn’t have the necessary drivers, your deployment will not work. Here’s the rule of thumb: If you can install Windows 7 off the install disc and the network driver works without doing anything custom, then this deployment server should work fine too.  But if it won’t take those drivers and add them to the deployment server. In the Deployment Workbench, go to the Drivers section and choose Import Drivers. You’ll want to point to a folder containing the .INF file (plus all the other required files for this driver) which means if stuff is hiding in an .EXE file you’ll first need to use 7-zip to extract them out. After adding drivers, right-click your deployment share within the Deployment Workbench and choose Update Deployment Share. Accept all the defaults, but you’ll need to reburn your CDs or recopy your USB drive files to get the updates.
  • Storage Drivers – This mostly applies to XP, but if you are using RAID, AHCI or other special hard drive configurations, you’re might have some trouble. Make sure to add these drivers in the same way that you’d add network drivers. I’d recommend disabling RAID/AHCI until you can get the deployment to work without it.
  • IP Networking – If you don’t have a DHCP server, the deployment wizard that you run on your target computers needs to know what you want your IP address to be. There is a button toward the beginning of the wizard that will let you set your IP.
  • DNS Networking – If you’re on a domain, or have an advanced network configuration, you might need to help your boot media locate the deployment server. In the Deployment Workbench, right-click your Deployment Share in the left pane and go to Properties. From there go to the Rules tab and click “Edit Bootstrap.ini” toward the bottom. Notepad will open and you’ll see a line that starts with DeployRoot=. Change this line to either reference your IP address or the fully qualified domain name. So for me I might change it to DeployRoot=\$ or DeployRoot=\TSZ.mydomain.comDeploymentShare$. After making changes and saving them, update the boot media as if you were adding drivers, but make sure to pick the option for Completely Regenerate Boot Media in the Update wizard. Don’t forget that you have to re-burn your ISOs or rebuild your USB drives.