Reaper's Edge

Welcome to Reaper's Edge, my site for sharing some of the pain, suffering, and successes I've had with Windows imaging and deployment.

Reaper's Edge, One Year On

posted Oct 27, 2011, 1:10 PM by Michael Wilson

As you may have noticed from the dates on my posts, I haven't been very active this last year. Partly that's because imaging tends to go in spurts where I work, and I haven't done much that's really new. But, rather than waiting for Windows 8, I thought I'd share a few little tidbits I've picked up in the last year. Don't expect anything Earth shattering, but a couple trivia questions might come out of this :)

First off, I've been doing a lot of imaging with Windows 7 in the last year, as I gradually phase out Windows XP. Along the way I was forced to make a rather difficult choice with repercussions that might interest you. If you paid close attention to some of my earlier post you may know that where I work we have two basic categories of PCs: Staff and Public. Staff PCs are nothing special, but as you can imagine, Public PCs require some extra effort to protect and maintain.

Given all of the myriad differences between the two PC types it made since for me to use two separate images for them. Then, when we began transitioning from XP to 7, we moved all of the Staff PCs first, and waited a while for the Publics. Quite simply, it was because the Publics require so much more mental energy. For Staff PCs I decided to use Windows 7 Pro x64. I chose this based on the knowledge that with RAM quantities in PCs doubling every couple years, and PCs already shipping with in excess of 4GB of RAM preinstalled, it would be foolish and wasteful to do otherwise. Publics were another story.

In our environment Public PCs are also hand-me-down PCs. At the time of the transition most Public PCs were still skating by on 1GB of RAM, with some running 2GB. That, combined with the increased compatibilty issues, led me to choose Windows 7 Pro x86 for Public PCs. The big question then, what kind of consequences arose from maintaining images for two different architectures?

Honestly, the biggest headache was going back and getting drivers for every model of PC in my environment, then extracting them. What you really want to know, though, is whether they can coexist in the same WIM file. Answer: Yes, with a qualifier. My Windows 7 WIM files are usually around 8 or 9GB. Adding additional images (of the same architecture) only nominally increases that (8GB becomes 8.2GB with an additional image). Combining x86 and x64 is less clean because there is less file duplication. Combined my two 8-9GB images take up 11-12GB of space. Still, better than using separate files.

Update Added - A Walkthru Page

posted Oct 27, 2011, 12:41 PM by Michael Wilson

I've added a new page to the site, meant to be a starting off point for people who want to learn everything in a more sensical order than the random slop I though out as blog posts. Instead of making it yet another post, I've made it it's own page, and linked to it on the new Navigation bar on the left sidebar. Enjoy.

KMS - Keys, Keys everywhere... which one am I supposed to use?

posted Oct 29, 2010, 7:18 AM by Michael Wilson

Welcome to KMS Hell. I call it that because for two days it was my own personal nightmare. I'll spare you the gorier details and get down to what you need to know.

As a volume license customer who plans on imaging, and reimaging, your PCs several times over their lifespan, you decided to use KMS instead of MAK. Good call. The hard part is getting it setup right. Now a lot of places will say it is stupid easy, and it is, if you know which keys to use where. If not... welcome to KMS Hell. First lets look at the keys you have: 

Courtesy of the MS Licensing found here: you probably have a whole bunch of keys for a slew of different operating systems. KMS and MAK for Vista, KMS and MAK for Windows 7, KMS and MAK for Server 2008, KMS and MAK for Server 2008 R2, and whatever else you may own.
Then you stumbled across a webpage that showed these keys off:
So what are you supposed to use where? After all, the PC's you're imaging will need keys, and so will the KMS server. 

(Quick little note. You'll hear me talk a lot about KMS servers and KMS clients. Microsoft prefers to call them KMS hosts and KMS clients.)

First off, all the systems (PC or Server) that are validating against a KMS server need to be using their respective KMS client keys. That's right, every single Windows 7 Pro KMS PC in the entire world has the same product key. Same for Vista, other Windows 7 versions, and for Windows Server OS's.

So what does the KMS server use? Beats me. That all depends on what your KMS server is running on. For example, my KMS server is running on Server 2008 R2 which means the that the KMS key it's using is the KMS key for Server 2008 R2. Using that key it can validate other Windows Servers, Windows 7 clients, and Windows Vista clients. All this happens without you using your Windows 7 KMS key from MS Licensing, anywhere... ever... for all time.

Wait, if I don't need to use the Windows 7 KMS key, why did they give it to me? That key is used if you're running a really small business and decide you need to host your KMS server on another Windows 7 PC. To put it simply, inputting the Windows 7 KMS key from MS Licensing immediately turns your humble Win7 box into a big bad KMS server, whether you wanted to or not.

Okay, so now I know what key to use. How do I actually set it up and what do I need to do to my PCs to make sure they use it? First let's get that server turned on. This part is easy (if you remember which key to use). On the system that will host the KMS server run the following commands from an elevated command prompt:
slmgr /ipk <KMS key for the OS that's hosting the KMS server>
slmgr /ato
net stop sppsvc && net start sppsvc
Done. You've successfully setup a KMS server. Congratulations. There a couple... issues to know about though. The first is obvious, really. You need to make sure the network traffic can make it to your server and that means checking out the firewalls. Checkout the bottom of this page to know what to look for:

Now for a little on how the clients work. When a Windows PC is loaded with a KMS client key and you try to activate it will automatically contact DNS and look for a nearby KMS server. It just so happens that when you run those commands listed above and turn on a KMS server it automatically publishes it's information to DNS. That means very little work you, unless you want to be special. If you do, check out the list of links I'll be posting at the bottom of this page for more information.

Now, you probably already know this, but it bares repeating. When you first setup KMS and try to use it, it won't work. To avoid using this nifty tool for piracy Microsoft won't let a KMS server start activating clients until it receives activation requests from 25 separate clients. So how do you know what's going on? Use one of these two commands, again, from an elevated command prompt.
slmgr /dli    or    slmgr /dlv
They do the same thing, the second one just gives you more information. Interestingly enough, those commands can be run on either the server or the client, but will give slightly different results. Still, they're handy for troubleshooting. Another thing to keep in mind, especially early on, is that the slmgr /ato command from earlier can be used on a KMS client to tell it to try and activate immediately, instead of waiting the default period of time.

That should cover most of what you need to know but I do want to add one more thing. If you're like me, you're deploying Windows 7 and Office 2010 together. In Office 2010 Microsoft decided to punish it's customers, I mean pirates, by introducing activation for volume license holders. That means that Office too relies on either MAK or KMS for activation. Luckily, we can setup our existing Windows KMS server to be a KMS server for Office 2010 as well. I could tell you how to do it, but you'd be just as well off reading this other fellows blog post on it here:

KMS can be a real pain to get working. Over the course of figuring all this crap out I came across a number of good resources. They're all posted below. Good look and as always, please comment if you have any questions or if this helped you out in any way. Enjoy.
Basic SLMGR commands:

List of KMS Client Keys

Extra KMS Commands

Long version of KMS commands et al.

Setting up KMS Server on Server 2008 - non R2

KMS Error codes

Check activation status:

Setting up KMS for Office 2010

More Office 2010 KMS information

Setting up a Windows 7 KMS Server

List of KMS Client Keys for Office 2010

List of KMS Client Keys for Win7, Vista, 2008, and 2008 R2

WIM files - Why you should use them for more than just Windows 7

posted Sep 26, 2010, 1:06 PM by Michael Wilson   [ updated Sep 26, 2010, 1:44 PM ]

WIM files came out along with the Windows AIK as part of the release of Windows Vista. That said I've used them with Windows XP as well and they work great, provided you can deal with their one... hinderance.

WIM files do a lot of things well. They're fast, they compress extremely well, you can have multiple images in one file with only small increases in file size, and they can be easily worked on offline. The one pseudo downside to them is that they only capture one partition at a time, so if you want to image a system with more than one partition, you're going to have to do some extra work.

First, lets talk about their compression. It's amazing. WIM files make use of single-instancing and can pack a large system install into a small file. Furthermore, they only grow slightly when additional images are added, because they only save the differences between the images. Let me give you an example. When I first started using WIMs for Windows XP my unsealed image took up 5.2GB of disk space. When I added a sealed image to the same file it grew to 5.25GB. Realizing I made a mistake I reloaded the unsealed image, tweaked it, and added a new unsealed image to the WIM. By the time I was done all done I had a WIM file of 5.8GB containing 9 different images. Cool huh.

Now for the catch, you knew there'd be one. The file doesn't just grow with added images, but deleted ones as well. When I was all done I used Gimagex to delete some of the bad images I'd made along the way. After reducing the number of images from 9 to 2 my WIM file had gone from 5.8 to 6.1 GB. Apparently it doesn't understand the concept of deletion and simply keeps adding changes, even if the changes are deletions. Now the good news, there's a simple workaround. Create a new text document and rename it Image.wim. Then, using Gimagex, export the image files you want out of the large WIM file and in to the new empty one. When I did that the image size of the new WIM file was back down to 5.2GB. The easiest way to think of it is as having a rough draft WIM (with a bunch of comments and edits) and a final draft WIM.

The next thing to look at is offline servicing. For that you first need to decide what you want to do. If it's something simple like adding or deleting a file from the image, then just mount it using gimagex, make the change, and unmount it saving changes. But what if you want to do something more complicated, like adding drivers. You do add new drivers to your images to keep them ready for new hardware, right?

For that there are two resources I highly recommend you look at:
Getting drivers from the Widnows Update Catalog:

Now I know what you're thinking. He didn't just say we should rely on Windows Update for drivers, did he? No, I didn't. Think of the second link as a last resort destination. Whenever possible get drivers from the manufacturer, but sometimes they don't put them out in a form you can use. An example of this would be a graphics driver that only assembles itself after an exe is run on the system with that particular hardware. In those cases the Windows Update Catalog can provide you with functional drivers to get, atleast until the PC is finished installing an image.

If you don't feel much like reading their documentation let me give you the command line highlights for adding drivers:
Find the name of the image within the WIM:
    Dism /Get-WimInfo /WimFile:C:\test\images\install.wim
Mount the image:
    Dism /Mount-Wim /WimFile:C:\test\images\install.wim /Name:"Windows 7 HomeBasic" /MountDir:C:\test\offline
Add a single driver:
    Dism /Image:C:\test\offline /Add-Driver /Driver:C:\drivers\mydriver.INF
The big one, add all the drivers from a folder and it's subfolders:
    Dism /Image:C:\test\offline /Add-Driver /Driver:c:\drivers /Recurse
Make Windows add an unsigned driver:
    Dism /Image:C:\test\offline /Add-Driver /Driver:C:\drivers\mydriver.INF /ForceUnsigned
Save changes to the Image:
    Dism /Unmount-Wim /MountDir:C:\test\offline /Commit

Keep in mind that those commands add drivers to only one image from a WIM file. If you want to add drivers to multiple images within a single WIM file you have to do them each one at a time.

One more little thing about WIM files. Do you hate backing up all your data? Keep in mind that adding new images of a system to an exitsting WIM file only makes it grow a little bit. It almost reminds me of incremental backups. Of course, WIM files are easy to open and pull files out of onsie twosie. But you'd never need to do that, right? Enjoy.

One Image to Rule them All - Intel and AMD without BSOD

posted Sep 26, 2010, 12:34 PM by Michael Wilson   [ updated Sep 26, 2010, 1:44 PM ]

If you've ever made images of Windows before you know that one of the biggest headaches is the need to make one image for Intel based systems, and another image for AMD based systems. If you put the image for one on the hardware of the other you end up getting a Blue Screen of Death at every boot.

One thing you'll figure out about me after reading a few posts is that I like to do all the complicated stuff on the back end and make things stupid easy for whoever actually has to deploy the image. With that in mind I set out to make one image that would boot on either system. My search eventually led me here:

The author is brilliant in that his stuff really works, both for Windows XP and Windows 7. I don't see any reason to restate all his stuff here, you can read it for yourself, but I will post some of the files and such that I use to make it work. The checkforintel.txt file should really be a vbs file as discussed on sys admin blog. In fact, I think it may be a word for word copy. As for the sysprep.txt, it should be sysprep.bat. It has been modified though, to work with Windows 7 and to work with MySysprep2. 

Basically, rather than running MySysprep2 or sysprep you would run sysprep.bat instead. That will setup your image to go either way. The catch is that you also need to do a little cleanup after the image and that's where checkforintel.vbs comes in. It needs to be run on all PC after they receive an image. You basically have two options for that, automated or manual. 

To automate the process your best option is to sneak it in as a task for your unattend.xml.
If you're okay with manual you just need to remember to run the script once during your post imaging build process.
If you're crazy you could even try and push it via Group Policy or SMS.

Unattend.xml for Windows 7

posted Sep 26, 2010, 9:36 AM by Michael Wilson   [ updated Oct 29, 2010, 7:14 AM ]

When you installed the Windows AIK earlier one of the tools that was installed was called the Windows System Image Manager. This is the tool Microsoft put out to help you assemble the unattend.xml file for use with Sysprep. Given how monstrously complicated the unattend.xml file is, WSIM actually does a decent job managing the chaos. That said, I was thinking I'd post a copy of the unattend.xml that I'm using and help you pick it apart.

There's a lot of code here, so to keep it all street I'll be making all my comments in red. Enjoy.

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="generalize">
        <component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
            <SkipRearm>1</SkipRearm> This setting here covers whether or not you want to reset the Windows activation timer. During testing you'll want to leave this set to 1 and switch it to 0 for actual deployment. 
        <component name="Microsoft-Windows-PnpSysprep" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
            <PersistAllDeviceInstalls>true</PersistAllDeviceInstalls> These two settings have to do with whether or not you want your image to keep the device drivers that were on the template PC. If you're like me and you use a template PC that is common in your environment then you'll probably want to keep them.
    <settings pass="specialize">
        <component name="Microsoft-Windows-Security-SPP-UX" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
            <SkipAutoActivation>true</SkipAutoActivation>  Do you want Windows to automatically activate itself, or wait for someone to do it manually. Personal preference I suppose.
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
            <ProductKey>11111-11111-11111-11111-11111</ProductKey> The Windows product key. If using KMS, use a KMS client key found here:
            <ComputerName>%Please input a computer name%</ComputerName> The source of all my problems. Note that WSIM does not like this setting and will not allow you to enter it through that program. You'll have to manually add it if you're using MySysprep2. You are using MySysprep2 right? If not, you may want to leave this setting out altogether.
            <TimeZone>Pacific Standard Time</TimeZone> The time zone.
        <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
                    <Domain></Domain> These four settings cover joining the domain automatically. 
        <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
                <RunSynchronousCommand wcm:action="add">
                    <Path>net user administrator /active:yes</Path> This tells the PC to run a command line argument that activates the local Administrator account. Don't leave home without it.
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
            <InputLocale>en-us</InputLocale> These four settings all cover your language pack and country. 
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
                <HideEULAPage>true</HideEULAPage> These settings here seem to half work. They keep you from getting pestered during the oobeSystem pass about things like the EULA and Windows Update settings, but expect to get pestered again when you first login to Windows.
            <RegisteredOrganization>CompanyName</RegisteredOrganization> I generally use my company name for both of these.
                    <Value>giberishadminpassword</Value> If you add an Adminsitrator password here and leave plaintext set to false it will convert it to a long string of giberish, and still work.
                    <LocalAccount wcm:action="add">
                            <Value>giberishlocaluserpassword=</Value> These settings are for the creation of a local account. As it happened I wanted to add one, but you may not. The thing is, if you don't add a local account here it will force you to add one in OOBE. One strategy is to specify one here then setup a script that deletes at first login. I know, I hate it too.
        <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="" xmlns:xsi="">
                <Mode>OOBE</Mode> Two options here OOBE and Audit. I haven't played much with Audit but if you're using this unattend as part of your image for deployment, you'll want it set to OOBE.
    <cpi:offlineImage cpi:source="wim:c:/users/mikew/desktop/windows%207/sources/install.wim#Windows 7 PROFESSIONAL" xmlns:cpi="urn:schemas-microsoft-com:cpi" />

That's it for my unattend.xml. If you have any tips for me please post them to the comments.

Dear Sysprep from Windows 7... I hate you.

posted Sep 26, 2010, 9:26 AM by Michael Wilson   [ updated Sep 26, 2010, 9:29 AM ]

If you're reading this blog and are even moderately interested then I think it's safe to assume you've messed with Sysprep for Windows XP. It was a great product with a simple setup. I miss it dearly. For Windows 7 Microsoft decided to change Sysprep and make it more 'featureful'. What they really did was turn it into a complicated mess while stripping out some of the mission critical pieces. Fail.

I discovered all of this while banging my head against the wall trying to get the new Sysprep to do what I need it to do. I never did. 

First you need to understand a little bit about my environment. Nothing real special, just an Active Directory domain with roughly 1000 PCs. Under XP we used an imaging setup where when the PC booted from being imaged it would run mini-setup. Again, nothing shocking there. During mini-setup it would prompt one of my techs to input a computer name and from there it would join the domain automatically. See, I'm a fat image kind of guy and I customized our images to eliminate every single click and keystroke that I could spare to reduce the time it would take to do a build, and to reduce the number of places a mistake could be made. Naturally, I wanted to do the same thing with Windows 7... that's where my life became miserable.

Windows 7 doesn't have mini-setup. Okay, no big deal. I'm sure they left us with something. I mean, look at Windows System Image Manager and all the settings I can put in my unattend.xml file. Alas, there was a bug.

Windows 7 handles the setup following Sysprep in a number of Passes. Each pass has certain options you can set, and they can only be set in particular passes. As you may have guessed, these passes are sequential. That said, lets set this up for you.

During one of the passes you have the option of assigning a computer name. Okay, unfortunately you can only either hard code the name in the Unattend.XML (giving every PC imaged the same name) or let it randomly generate a name for you. You can't have it prompt you to input a name. That said, you can have it ask you for a name much later, during the OOBE setup. OOBE stands for Out Of Box Experience and is what you normally see when you pick a PC from Bestbuy and turn it on for the first time. 

Here's the problem, auto-joining the domain happens before OOBE. That means that when it joins the domain it does so with either a hard coded name or a randomly generated one. Then, when you name the PC during OOBE, it breaks the trust relationship with the domain and you have to essentially start over.

I poked at this for days before finally giving up and going third-party. Meet my new best friend, MySysprep2.

It lets you do something very special, take all of the work you've already done setting up Sysprep and your unattend.xml file, and add a prompt for computer name before it joins the domain.

Coming up in a later post I'll talk more about the unattend.xml file and show you a copy of the one I'm using. 

WinPE + Gimagex = Your core imaging tool

posted Sep 25, 2010, 3:51 PM by Michael Wilson   [ updated Sep 26, 2010, 8:52 AM ]

To be able to capture an image you need to be able to access the hard drive offline and make a copy of it. The best way I've found to do that is to use Gimagex from within WinPE. Unfortunately you can't just download this tool and will have to assemble it. The good news is that all the parts are free and I'm here to help you.

Step 1: Download and install the Windows AIK
    You can download it here or just do a search for WAIK and Windows 7. You can only install this on Windows 7 or Vista SP1, but if that's a problem there's an older version you can download that should work just as well. The download comes in the form of an ISO file containing the software. Lame, I know, but either burn it to DVD or just mount the ISO with something like Daemon Tools and get to installing.

Step 2: Create a WinPE image.
    Now it starts getting a little more complicated, and I'm afraid the command prompt is involved, sorry.
    1. WAIK should have installed a shortcut to an item called the Deployment Tools Command Prompt. You'll need to open this with admin privileges.

    2. From this command prompt run the following commands in order
        copype.cmd x86 c:\winpe_x86        (Note that the x86 is for WinPE itself and will still allow to capture both x86 and x64 PC images.)
        copy c:\winpe_x86\winpe.wim c:\winpe_x86\iso\sources\boot.wim
    3. Open Notepad and create a file called wimscript.ini and include the following text:

    4. Save a copy of wimscript.ini to c:\winpe_x86\iso

    5. Go back to the Deployment Tools Command Prompt and run the following command
        oscdimg -n -bC:\winpe_x86\ c:\winpe_x86\iso C:\winpe_x86\winpe_x86.iso

    At this point you've created a functioning WinPE image, but it doesn't contain any tools yet.

Step 3: Burn or Mount the winpe_x86.iso and copy all of the contents to a new folder
    The iso is irrelevant at this point, we just need the contents.
    For this example lets say we copied the contents of the ISO to the folder c:\Image

Step 4: Download the gimagex tool here. This is the famed ImageX tool, wrapped in a functional GUI shell. Make two copies of the tool in two different folders, because we're going to run it and copy it at the same time coming up.

Step 5: Mount the boot.wim file and insert tools into it.
    1. Create an empty folder, for this example I'll use c:\wimmount
    2. Run one of the copies of Gimagex (it will only run as an admin, fyi)
    3. Go to the Mount tab and set the following:
        Mount Point = c:\wimmount
        Source = c:\image\sources\boot.wim
        Image = 1
        Check Read and Write
        Click Mount
    4. Once the mount completes successfully navigate to c:\wimmount and notice it contains a mini Windows install.
        Navigate to the folder c:\wimmount\windows\system32
        This is where we are going to dump all of our tools and customizations

Step 6: Prepare our contents for the WinPE image.
    There are only a few things we truly need at this point, but there are several that will make our lives tremendously easier down the road.
    Create the following files and tuck them away for later
    Below you'll find each of the files attached and saved as text files. You'll want the contents of the files to match, though feel free to tinker.

Step 7: Copy all of our stuff into the WinPE Image 
    Return to the folder c:\wimmount\windows\system32 and copy in all of the following, overwriting existing files where necessary:
        imagex.exe - from the folder "c:\program files\windows AIK\tools\x86\"
    Once you have all the files copied close all open windows that point to c:\wimmount directory or any subdirectories. Miss this step and it will corrupt your image. That's bad.

Step 8: Save changes to the WinPE image.
    Go back to the Giamgex program you opened in step 5
    On the Mount tab, highlight the image you're working on, check the box Commit Changes, and click Unmount
    At this point we have an awesomely automated WinPE image, now we need to put it somewhere. In this example I'll show you how to use it to make a bootable WinPE USB drive

Step 9: Prep the USB drive
    The size of the drive is up to you, but should be based on whether you intend to store PC images on the USB drive along with WinPE. If not, you only need a 256MB stick. If you will carry images on it I recommend at least an 8GB and preferably 16GB, the faster the better.
    To prep the USB drive, insert it into the PC and open an elevated command prompt, then run the following commands:
        list disk    (Take note of which disk number is your USB drive. You don't want to accidentally wipe the wrong drive, right?)
        select disk n    (Where n is the disk number for the USB drive.)
        create partition primary
        format fs=ntfs

Step 10: Copy WinPE to the USB drive
    Copy all of the contents of the folder c:\image to the USB drive

That is it, you are done.

To use, simply plug the drive into a PC and boot to it. It will take you to command prompt with some well written text explaining what the valuable commands are, including how to launch the GUI tool Gimagex.

A couple more closing thoughts; this USB stick can be used to both capture drive images, and to apply drive images. Also, with a little bit of modification to the text of formatbat.cmd you can create an automated drive that will ask the user to pick a number, and based on that number, image the drive using one of several images. Incidentally, it makes use of the imagex tool I had you include earlier, just in case. Here's a sample text to help you a long if you're interested:
REM This file will wipe the hard drive and install a wim image
REM Written by Michael Wilson on 5/20/2010

@echo off
echo "Input number to select image type:"
echo "1 - Staff XP from 5/18/2010"
echo "2 - Public XP from 4/29/2010"
SET /P ImageNum=[promptString]

if "%ImageNum%"=="1" diskpart /s delpart.txt
if "%ImageNum%"=="1" imagex /apply e:\combinedxp.wim 1 c:
if "%ImageNum%"=="2" diskpart /s delpart.txt
if "%ImageNum%"=="2" imagex /apply e:\combinedxp.wim 2 c:

wpeutil shutdown


Imaging Process Overview - How I do it.

posted Sep 25, 2010, 2:19 PM by Michael Wilson

I thought I'd start out by giving a general overview of how I go about the process of building and deploying a new Windows image where I work.

Step 1: Pick a template PC. 
    Generally speaking people will tell you to make your image on a relatively generic or older PC. I don't. Instead, I always build my image on the most common model of PC the image will end up being used on. When you get down to it, I don't think it matters much what you pick, but I always look at the most common model as the one that 'has' to work so I might as well start there.

Step 2: Setup the PC.
    Start with a piece of Windows volume license media and install Windows on your template PC. Then update, and install software, and update that, and basically setup the PC so it is ready, or almost ready, to be put on an end users desk. Quick note, some software can't be included in the image. In particular, keep an eye out for software that requires activation, is custom from PC to PC, or is otherwise cataloged and unique.

Step 3: Setup a sysprep.inf or unattend file.
    The specific name of the file will depend on your version of Windows. This file should contain things like your Windows Product key, credentials to join a domain, and a bunch of generic system settings like what language pack to use and what time zone  you're in.

Step 4: Make an Unsealed image.
    This step is crucial. Once you actually run Sysprep and generalize your template PC you can't go back. By taking an image of the PC before you run Sysprep you'll be able to go back and make corrections if anything goes wrong without completely starting over. And believe me, things WILL go wrong. This is also helpful becuase in a few months when a new update or piece of software comes out and they want you to make a new image you can just throw your unsealed image on a box, add the new stuff, and make a new unsealed image.

Step 5: Run Sysprep and make a Sealed image.
    After you run Sysprep and shutdown the PC it is critical that you make an image of it before it boots even once. Miss it and you'll be starting over with your unsealed image. You did make one, right?

Step 6: Test, test, test
    Install your new sealed image on as many different pieces of hardware as you can get and see what breaks. Take notes, you will be quized on this later.

Step 7: Reload the unsealed image and fix the broken crap you found in Step 6

Step 8: Go back to Step 4 and keep going back through until you squash all of your bugs

Step 9: Deployment
    There are many different ways to deploy an image but if you're like me, and you don't have the resources to do fancy server-based deployments, look at high speed flash drives. Where I work we use the Patriot Xporter and the Corsair FlashVoyagerGT. In my experience a 16GB drive is more than enough, depending on how much crap you put in your image. Expect Windows XP with Office 2007 or Windows 7 with Office 2010 to both weigh in between 5 and 6 GB of space. Loading the image on Pentium 4 based system should take about 10 to 15 minutes. Look for a Core2duo or newer to take less than 10 minutes.

So, there's the broad outline of how I image PCs. It's a little generic, but expect more detailed posts to follow.

Yo dawg...

posted Sep 25, 2010, 2:05 PM by Michael Wilson   [ updated Sep 25, 2010, 2:06 PM ]

I heard you like Windows IT blogs, so I put a blog on my blog, so you can read my blog while reading my blog

1-10 of 10