Mark Minasi's Windows Networking Tech Page
Issue #62 Late February 2007

To subscribe, visit http://www.minasi.com/nwsreg.htm. To unsubscribe, link to http://www.minasi.com/unsubs.htm. To change e-mail address or other info, link to http://www.minasi.com/edit-newsletter-record.htm.  Visit the Archives at http://www.minasi.com/archive.htm.  Please do not reply to this mail; for comments, please link to www.minasi.com/gethelp.  Document copyright 2007 Mark Minasi; see below for copying permission.

What's Inside

• News
  • Join Me At a Seminar!
  • Our one-day Vista Hands-On Deployment class comes to Dallas next Tuesday
  • My New Book Administering Windows Vista Security: The Big Surprises Now On Sale
  • I'm doing a webcast on Vista deployment next Friday, March 2
• Tech Section
  • Using and Automating Vista's Sysprep
• Conferences
• Bring a Seminar to Your Site

News

Hi all —

More deployment this month, but this time we add Sysprep to the mix.  Thus far all we've really accomplished is to deploy a very specific image — too specific, in fact.  In order to build an image that you can deploy to many systems, that image must be, in Microsoft's words, "generalized."  If you're already experienced in imaging earlier OSes then you'll know that the tool of choice for that generalizing is called Sysprep.  But while Sysprepping an image solves the generalizing problem, it raises an issue of its own:  Sysprepped images require a bunch of user interaction when first started, and that's not really desirable.  This month, we'll see how to build a "Sysprep answer file" to add those finishing touches to a smooth Vista rollout.

But first, a word from our sponsor...

My New Book Administering Windows Vista Security: The Big Surprises Now On Sale

Vista is the most secure Windows that Microsoft has released, so there's lots of new stuff to learn, and much of it is good news for anyone looking to keep the bad guys away.  But while it is good news, and while we all say we want security, facing new security technologies sometimes means having to learn to do familiar tasks differently and dealing with application compatibility puzzles, which can be a pain.  In some cases, it can be enough of a pain to cause someone to choose to deploy Vista later, and that'd be a shame — and that's why I wrote my new book,  Administering Windows Vista Security:  The Big Surprises.  It focuses on the eight new Vista security technologies that I feel are pretty good when understood, but that could either scare away the casual evaluator or that are so subtle — but nonetheless important — that they might not be noticed.  And at 266 pages, it's a quick but in-depth read!

Find out more and read a sample chapter at www.minasi.com/vistsecbook.

I'm Doing a Webcast on Vista Deployment for TechTarget March 2nd

TechTarget has asked me to do a short (45 minutes or so) Webcast on the Vista deployment technologies that I've been covering in the past few newsletters.  It's running at noon on Friday, March 2nd.  Sign up for it here.

Tech Section

Introduction

In the last newsletter, I showed you how to use ImageX from the Windows Automated Installation Kit to create Windows image files — large single files that contain the entirety of a computer's operating system drive, much like the image files that you've probably worked that were created by a tool like Ghost — out of working PCs, and then how to deploy such an image to a PC.  But all we accomplished in the last article was to create an image that's pretty much only good as a backup of an existing system.  The image can't be deployed to a lot of other systems because it contains a set of specific SIDs, and Windows networks don't like seeing a bunch of computers with identical SIDs.

This month, we'll complete the process by ripping the SIDs (and a bunch of other data) out of a computer before imaging it.  That process is called "generalizing" by Microsoft.  It's done with a tool that should be familiar to many — Sysprep.  Sysprepping is easy, but imaging a system that's been generalized with Sysprep forces the user to put up with a sort of mini-Setup wizard wherein the user's got to accept the End User License Agreement, punch in a product key, pick a computer name and so on.  Our other, and larger, task for this month, then, is seeing how to build a script that answers Sysprep's questions, allowing for a no-user-input-required deployment.

Generalizing With Sysprep

About ten years ago, tech support people started saying to themselves, "I'm really tired of installing operating systems by shoving a CD into a computer and babysitting its Setup program!"  So sector-based imaging tools like Ghost and DriveImage Pro appeared, and things seemed good... for a brief while.  As long as people used sector-based imagers to deploy things like Windows 95 and 98, then everything was all right.  But once they moved into the NT family of Windows, then the duplicate SID issue appeared... and the problems that we face to this day began.

At first, Microsoft tried to ignore the problem, telling people that the only way to do mass deployments of operating systems in the NT family was to build winnt.sif-style answer files, and thus create every new system as a virgin OS built out of the I386 directory and scripts.  "Cloning" systems, they warned, was a no-no.  But no one really wanted to get involved with NT 4's lame answer file system and the fact is that deploying a few thousand NT 4 workstations with identical SIDs didn't really do the sort of awful damage the Microsoft balefully implied that it would, so the fact is that most folks just ignored Microsoft... but worried that Redmond might, one day, make good on their threat.

In the late 90's, Microsoft made an open secret of the fact that there was this magic deployment thing called "Sysprep" that would serve as the missing piece for users of Ghost, DriveImage Pro and the like.  This "Sysprep" tool would snip off all of the specific information about a computer, including those bad old SIDs, and create a system that was "generalized" enough to be safely Ghosted.  Such an image lacked a computer name, SIDs and the like, but automatically fixed that upon first booting by asking the user a few questions — what is my name? should I join a domain and so on.  The process looked like a shortened version of Setup, and so came to be known as the "mini-Setup wizard."  Prior to Windows 2000, however, most folks didn't have the chance to even play with Sysprep, as Microsoft was only handing it out to a select few.

With Windows 2000, that changed, and Sysprep was released to the masses along with winnt.sif, Remote Installation Services, Riprep, and, well, a whole lot of other 2000 rollout tools that it seems that almost no one but me used, except for Sysprep.  Even people eschewing Microsoft's rollout tools needed Sysprep to neuter a computer well enough to make it a useful image.  And that hasn't changed with Vista:  Sysprep's still the pre-imaging generalizing/neutering tool of choice.

So where do you find Sysprep?  Well, I would have guessed that Sysprep would be in the WAIK... but it's not.  For some reason, that tool shrouded in mystery just a scant eight years ago has become apparently so quotidian that it's the only deployment tool shipped with every single copy of Vista, in the \windows\system32\sysprep folder.  You can just type "sysprep" to invoke its limited GUI, but the better way to use it is from the command line.  The syntax that you'll find useful most of the time is

c:\windows\system32\sysprep\sysprep /generalize /oobe /shutdown /unattend:scriptfile

The first option, /generalize, tells Sysprep to do that all-important generalizing.  /oobe stands for "Out Of the Box Experience," which isn't very illuminating but basically is a "must-use" option.  "/shutdown" should be obvious, and "/unattend" is the key to making a Sysprepped image useful, as we'll see.

What if you don't specify an unattended installation file?  What if you just go to a Vista box, open an elevated command prompt and type

c:\windows\system32\sysprep\sysprep /generalize /oobe /shutdown

In that case, you'll see Sysprep work for a short while, and the system will then shut down.  When you restart it, you'll see the system boot and start up the mini-Setup wizard.  The wizard first asks you what language to use for Setup.  After you answer that question, then it'll ask you to approve the end-user license agreement, punch in a product code, create a user account, give the machine a name and so on.  But believe me, you'll only have to run the mini-Setup wizard once, because after you've done it once by hand, then you'll feel extremely motivated to figure out how to to automate it  — hence the rest of this article.

How To Deal With the Mini-Setup?

Clearly rolling out a system to a user that will assail the user with questions the first time that she turns on the system isn't very useful, so we'll need to return to the subject of my earlier article on building scripts for unattended installs.  In case you missed it, it's newsletter #60 at www.minasi.com/newsletters/nws0701a.htm.

I'd be nice to have a WIM already built and ready that we could just deploy to a computer without a lot of user interaction, as WIMs deploy so quickly and conveniently.  Ideally we'd just boot the target system with WinPE, partition and format its C: drive, start up ImageX and tell it to apply the WIM, and then walk away.  After 15 or so minutes, we'd come back and find that our target computer not only had the Vista WIM installed, but was completely up and ready to go, without the need for responding to the mini-Setup wizard and without the need to wait 10 minutes while Vista goes through the "now evaluating your computer's performance" stuff. 

The good news is that we can do those things, and in fact if you've read the previous three articles then you've got most of the pieces to do them.  But before we lay out the last pieces in the puzzle, let's take a moment and look at the overall plan for deploying The Perfect Desktop in a way that lets you push as few keys and click as few mice as possible.

• First, create your prototype system, the machine that you'll "clone" onto other systems as a sort of standard desktop.  One way to build that initial computer is to start from the installation DVD and run it unattended by constructing an XML installation script — an "answer file" in Microsoft jargon — with the Windows System Image Manager (WSIM), as discussed in Newsletter #60.
• Add whatever applications to it that you like.
• Build an answer file for the mini-Setup on that system, using WSIM and the information in the rest of this article.  You can call that file anything, but in this article I'll call it "sysprep.xml."
• Generalize that system by removing its SIDs and the like by running sysprep /generalize /oobe /shutdown /unattend:sysprep.xml, as you've already read earlier in this article.  The /unattend part in combination with the answer file ensures that any systems imaged from this one don't bug users with the mini-Setup wizard by creating a script for the mini-Setup. 
• Create a CD-ROM with Windows PE 2.0 on it, being sure to add the ImageX program as we discussed in Newsletter #59.
• Using the Windows PE CD-ROM, boot your Sysprepped prototype system.
• As we discussed in Newsletter #61, use the ImageX program on your Windows PE CD-ROM to capture the prototype system's image to an external hard disk or network share.
• Now that you have that image on a network share or external hard disk, you can deploy it to any system that you like with the ImageX /apply command, as we also covered in Newsletter #61.

At that point, you've completed one approach to rolling out Vista!  So it's time to look into the last component, the mini-Setup answer file.

Scripting the Mini-Setup

Recall from Newsletter #60 that scripting a from-the-ground-up installation involved using Windows System Image Manager (WSIM), a part of the Windows Automated Installation Toolkit or WAIK.  (You can download the WAIK at www.microsoft.com/downloads, as you read in Newsletter #59.)  It allowed you to pick options from a somewhat complex menu, which in turn caused WSIM to create an ASCII text file formatted as XML.  You also use WSIM to create an answer file for a Sysprepped system so as to make the mini-Setup unattended, but building one of those Sysprep answer files is just a trifle different from creating an answer file for a complete installation.  To see why, let's review a few things about answer files from the earlier article.

• To build an answer file, you first start up WSIM and then a Windows Image (WIM) file.  Then you tell WSIM to create a new answer file.
• On the left-hand side of the WSIM, you see a list of "components," things in Windows that can be configured like "create a user account," "specify a language" and the like.  There are many of these components, but most answer files will be silent about the majority of them.
• You tell WSIM to include a given component in the answer file by right-clicking the component and choosing a "pass" — a phase of the installation and deployment process — to include the component in.
• There are seven passes in theory, but most aren't used in any given answer file.  For example, an answer file for a complete unattended install only employs three passes:  Pass 1 or the "WinPE" pass, which sets up things pre-Setup like partitioning a hard disk; Pass 4, the "specialize" pass ("specialize" because it basically does the opposite of Sysprep's "generalize") which is the main pass for configuring Windows itself; and Pass 7, the "oobeSystem" or "out of the box experience" pass, which affects the questions that Vista asks users the first time that it starts up, like "create a user," "give the machine a name," and the like. 
• You signal to Vista's Setup program that a file is an answer file by naming the file "autounattend.xml" and putting the file on some removable device on the target computer, like a CD-ROM disc, a USB stick drive, or a floppy disk.

How is creating a Sysprep unattended script, a mini-Setup answer file, different from creating an answer file for a clean installation?  There are two main differences.

• Telling mini-Setup to use an answer file:  instead of giving your XML file a special name, as we did to accomplish a clean installation, you can call your answer file anything that you like.  You tell the mini-Setup to use an answer file, and the answer file's name, by adding the /unattend:answerfilename option on Sysprep.
• Passes:  recall that before you can use ImageX to apply an image to a target system that the target system must have a partition prepared and formatted; mini-Setup won't prepare a disk.  Thus, a mini-Setup doesn't do pass 1.  Anything that you want to control via a mini-Setup answer file must be done in passes 4 and/or 7, and in fact any Pass 1 component settings in an answer file will be ignored by the mini-Setup.

That second point is very important because it leads to something that will drive you crazy:  a lot of what you learned while creating answer files for clean installations doesn't work in building mini-Setup answer files.  Remember what a pain it was to have to spelunk through all of those blue cubes to find the particular settings to make an install happy?  Well, recall that we found a lot of those settings in pass 1... which doesn't exist in a mini-Setup, which means we'll have to either leave them out (as in the case of disk partitioning) or find their analogs in other passes.  So put that miner's helmet on, we're goin' in again!

Let's review what we wanted to accomplish with our autounattend.xml answer file, and comment if it's still relevant for mini-Setup:

• Specify setup language, which was necessary to keeping a clean installation unattended and will still be necessary for mini-Setup
• Partition and format a C: drive; unnecessary as we'll already have done that from WinPE
• Tell Setup which drive to install to; unnecessary as we tell ImageX which drive to install to before mini-Setup even starts
• Tell Setup not to show the EULA, give it a product key, and specify an owner and organization (still necessary for mini-Setup)
• Specify the computer name and time zone (still necessary)
• Create a user account (still necessary)
• Tell Vista how to do automatic updates (still necessary)
• Direct Vista to skip the "Welcome to Vista" stuff (still necessary)
• Tell Vista not to automatically activate (still necessary)

Creating the Mini-Setup Answer File

As before, we start creating a mini-Setup answer file by starting up the Windows System Image Manager.  On a system with the WAIK installed, just click Start / All Programs / Microsoft Windows AIK / Windows System Image Manager.  As you saw in Newsletter #60, choose a Windows image, and then click File / New Answer File....  As before, I'll use Vista Business as my example.  In the "Windows Image" part of the WSIM screen, click the plus sign next to "Components" and you will, as before, see several dozen components.  Now we're ready to start building a mini-Setup script.

Specifying a Language

In creating the answer file for the clean install, we found the place to tell Setup to communicate in English in a component called (I'm sticking with the shortened component name convention that I adopted in Newsletter #60) ...International-Core_WinPE..., but the fact that there's "WinPE" in its name is an immediate clue that the component won't help us in this case.  Sure enough, if you right-click that component then you'll see that the only available pass for it is Pass 1.  Where, then, to go?  Not far, fortunately:  look just above that component and you'll see one with a similar name of ...International_Core... without the WinPE part.  Right-click and you'll see that you can add it to either Pass 4 or Pass 7.

And that's where our trouble starts.  Which pass to choose, Specialize (Pass 4) or oobeSystem (Pass 7)?  Well, let me save you some time — don't bother asking Help.  It would be great of WSIM's Help said something like, "when creating a mini-Setup answer file, set InputLocale in Pass 7, not Pass 4," but it doesn't.  How, then, do you figure out if this or any other setting belongs in Pass 4 or Pass 7?  Trial and error.  Ugh.  Fortunately, however, I've already done the testing for you.  Continuing the format that I introduced in Newsletter #60, you can tell mini-Setup to use English like so:

• Component: ... International-Core_6.0.6000... (Notice that this is not the International-Core-WinPE)
  • Pass 7
  • InputLocale = en-us
  • UserLocale = en-us
  • UILanguage = en-us
  • SystemLocale = en-us

Continuing with the settings that were Pass 1 settings in the answer file for the clean setup, we need to specify the product key, accept the EULA, identify the machine's owner and organization.  Now, in the earlier answer file, it was in ...Setup_6.0.6000.../UserData, but right-clicking ...Setup_6.0.6000... shows that it can only go into Pass 1.  Where, then, to enter a product key?  A bit of searching yielded the second component below ...Setup_6.0.6000..., the  ...Shell-Setup... component.  A look back at Newsletter #60 will show that we used that in our clean install answer file to do a number of things.  A look at the top level settings afforded by ...Shell-Setup... component include not only ProductKey but ComputerName, Registered Organization, Registered Owner and ShowWindowsLive.

But what pass does the top level of ...Shell-Setup... go into?  Well, WSIM's not much help, as right-clicking ...Shell-Setup... shows that it can go into any pass between two and seven.  More experimentation shows that, well, you won't believe this, but you're going to end up adding this in Pass 4 and Pass 7.  When you add ...Shell-Setup... to Pass 4, then you can employ the TimeZone, ProductKey, ComputerName and ShowWindowsLive settings, but under no circumstances should you try to set RegisteredOwner or RegisteredOrganization — in my experiments it appears that putting either RegisteredOwner or RegisteredOrganization in Pass 4 will actually cause the mini-Setup to crash, rendering the image completely unusable.  So we can, then, add those settings like so:

• Component: ...Shell-Setup...
  • Pass 4
  • ComputerName=* or a name
  • ShowWindowsLive=true/false
  • ProductKey=<whatever>
  • TimeZone=<name of your time zone, like "Eastern Standard Time">, as discussed in the earlier article

(And to reiterate one more time, resist the temptation to change RegisteredOwner or RegisteredOrganization from their values of AutoBVT and Microsoft in Pass 4.  We will get to them in Pass 7!)

Once you include ...Shell-Setup... in your answer file and fill in those settings, you'll notice that ...Shell-Setup... has a bunch of sub-components, none of which you've set, but that are in the answer file anyway.  In WSIM's "Messages" field, you'll see a bunch of warnings, but don't worry about them.  WSIM's just telling you that when you write this answer file out that it'll remove any unused settings in the XML automatically.

Then, add that exact same component again, this time to Pass 7, and set the RegisteredOwner and RegisteredOrganization:

• Component: ...Shell-Setup...
  • Pass 7
  • RegisteredOwner=<whomever>
  • RegisteredOrganization=<whatever>

Next, let's consider user accounts.  As you probably recall, the last part of a clean install — the part that you can now sagely call Pass 7, oobeSystem — forces you to create a user account, as Vista disables the built-in Administrator account.  Vista's Sysprep is a bit odd in that it does not delete any existing user accounts on a system when it generalizes a system.  So you might think that what the heck, since the Sysprepped image already contains a user account, then the mini-Setup shouldn't make me create another user account... but you'd be wrong, unfortunately.  The mini-Setup just isn't happy unless it's done something with a user account, but it needn't create one; it'll settle for just modifying any existing ones.  (Yes, this does seem strange.)  My experiments show that mini-Setup can change a password or group membership on existing user accounts, but can't change those accounts descriptions or display names.  In any case, as far as I've been able to determine, the only way to make a mini-Setup completely unattended is to make it change the password and/or group membership on a local account (or, of course to tell mini-Setup to create a whole new account).

So, supposing that you're building a mini-Setup for a system that already has a local account on it named "Mark," then you could tell it to change Mark's password and assign him to a few groups — and satisfy mini-Setup's need to mess with at least one local account — with a subset of a group of settings that we've already met in Newsletter #60:

• Component: ...Shell-Setup.../UserAccounts/LocalAccounts/LocalAccount
  • Pass 7
  • Group = administrators;power users
  • Name = Mark
  • Subcomponent: Password
    • Value = swordfish

The ugly part of creating this file is over; from this point on, our settings have the same values and locations as they did when we created the answer file for an clean install back in Newsletter #60.  Hide the EULA page, set the network type, turn on automatic updates, skip the OOBE:

• Component: ...Shell-Setup.../OOBE
  • Pass 7
  • HideEulaPage = true
  • NetworkLocation = Work
  • ProtectYourPC = 1
  • SkipUserOOBE = true

Note that it doesn't matter whether or not you add this component, as it's in ...Shell-Setup... and so you've already added it to Pass 7.  Then set Vista not to automatically activate itself:

• Component: ...Security-Licensing-SLC-UX...
  • Pass 4
  • SkipAutoActivation = true

With all of these settings in place, save your new answer file as sysprep.xml.  (Again, any name will do just fine.  It's not like when we did the answer file for the clean install, which requires that it have the specific file name of autounattend.xml.)  The XML looks like this, in case you'd rather just copy it to Notepad and save it.  (Don't forget to enter your product key, and note that your XML file may look a bit different, as I added carriage returns to mine to keep the newsletter from forcing your browser to open a really wide screen.)

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="oobeSystem">
<component name="Microsoft-Windows-International-Core" processorArchitecture="x86" 
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" 
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<InputLocale>en-us</InputLocale>
<SystemLocale>en-us</SystemLocale>
<UILanguage>en-us</UILanguage>
<UserLocale>en-us</UserLocale>
</component>
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" 
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" 
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<OOBE>
<HideEULAPage>true</HideEULAPage>
<NetworkLocation>Home</NetworkLocation>
<ProtectYourPC>1</ProtectYourPC>
<SkipUserOOBE>true</SkipUserOOBE>
</OOBE>
<UserAccounts>
<LocalAccounts>
<LocalAccount wcm:action="add">
<Password>
<Value>cABhAHMAcwB3AG8AcgBkAFAAYQBzAHMAdwBvAHIAZAA=</Value>
<PlainText>false</PlainText>
</Password>
<Description>New Mark Description</Description>
<DisplayName>New Mark Display Name</DisplayName>
<Group>administrators; network configuation operators</Group>
<Name>Mark</Name>
</LocalAccount>
</LocalAccounts>
</UserAccounts>
<RegisteredOrganization>Mark&apos;s Lab</RegisteredOrganization>
<RegisteredOwner>Mark Minasi</RegisteredOwner>
</component>
</settings>
<settings pass="specialize">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" 
publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" 
xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ComputerName>NWSTest</ComputerName>
<ProductKey>ENTER YOUR KEY HERE</ProductKey>
<ShowWindowsLive>false</ShowWindowsLive>
<TimeZone>Eastern Standard Time</TimeZone>
</component>
<component name="Microsoft-Windows-Security-Licensing-SLC-UX" 
processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" 
versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipAutoActivation>true</SkipAutoActivation>

</component>
</settings>
</unattend>

Taking the new Sysprep Answer File Out for a Spin

Either work your way through the WSIM or copy the above XML to Notepad.  Then insert your product key.  This XML file will, if used as a Sysprep answer file, do the following:

• It will rename the system "NWSTest"
• It will create an account called "Mark" with password "password," or, if there is already an account named Mark, it will change the password of that account to "password."  It will also make that account a member of the Administrators and Network Configuration Operators groups
• It will tell Vista not to automatically activate
• It will tell Vista to use US English
• It will set the owner and organization to Mark Minasi and "Mark's Lab"
• It will tell Vista not to show the Welcome Center

Here's how to try it out, assuming that you have the above XML in a file called "sysprep.xml."

1. Start from a working Vista "sacrificial" system that you don't mind wiping out.
2. Put your product key into the sysprep.xml file if you haven't done so already.  Remember that OEM, retail and volume license copies are different and use different product keys, so if you want this to work out without a hitch then I strongly recommend inserting the same product key used to initially build the "sacrificial" system.
3. Boot the sacrificial system.
4. Open an elevated command prompt.
5. Copy the sysprep.xml file into c:\windows\system32\sysprep
6. Type cd sysprep, then Enter, then sysprep /generalize /oobe /shutdown /unattend:sysprep.xml and Enter.
7. The sacrificial system will shut down.
8. Boot the system with a WinPE CD-ROM of the kind that we created in Newsletter #59 -- it needs to have imagex.exe on it.
9. Connect the system to wherever you want to store the WIM image that we're about to create:  a network share, an external hard disk or whatever.  Let's assume that the external drive is on drive E:.
10. Image the Sysprepped system to E: by typing imagex /capture c: e:\sptest.wim "Sysprep test" and press Enter.
11. Once it's done, clean off the C: drive by typing format c: /y /q.
12. Still working in WinPE, tell the system to restore the "generalized" image from E: to the computer by typing imagex /apply e:\sptest.wim 1 c:\ and press Enter.
13. When that's done, type exit and press Enter to reboot the system.
14. Walk away for about twenty minutes, come back and your Sysprepped image will now be up and running... and "de-generalized."

Caveats and Comments

As with the answer file that we discussed in Newsletter #60, this is a very basic mini-Setup answer file, but it's a complete enough example to use as a starting point for your needs.  Before I finish this article, though, let me pass along a few notes about mini-Setup scripts.

First, recall that Vista product keys vary in a number of ways.  Not only do they identify the version of Vista that you'll end up with — Home, Business, etc — but also the type of release: OEM, retail, volume license and the like.  Mini-Setup answer files are very picky about the kind of product keys that you include in them, and so if you were to build, for example, a prototype system with Vista Business from an OEM copy and try to use an answer file containing a Vista Business retail key, then you'd get any one of several extremely unhelpful error messages to the effect that Windows either "doesn't work on this hardware," "cannot be configured on this system" or the like, and if you see one of those messages, then there's nothing to do about it but to just wipe and rebuild from scratch.

Second, a look at a Vista answer file shows that passwords are now obscured, so a casual glance at an answer file's XML will not reveal the password of whatever account or accounts you've told the answer file to create or modify.  That sounds like a good thing, but I'm not so sure about it.  The obscured value — notice I am not calling it the "encrypted" value, because I don't think it is encrypted — appears to be obscured with something called "Base64" or something similar.  People use Base64 as a way to write text into a public message when they don't want that text to be read easily.  What I mean by that is this:  suppose you've just seen some movie with a much-touted "surprise ending" that turns out to be trite nonsense, and so you want to vent about it on some forum about movies.  But you don't want to spoil the ending for others, so you encode your comments in Base64.  Anyone who cares enough to read the obscured stuff can easily find a Base64 encoder/decoder, as there are lots of them on the Internet — there's one on my site at www.minasi.com/opinion.htm, for example — and cut and paste your comments into the decoder to see them.

Now, don't misunderstand me, Microsoft's not using the precise Base64 algorithm to encode and decode the passwords in the text file, but they're using something very much like it.  Why is that bad?  Well, you'd think that taking a simple encode/decode routine like Base64 and modifying it just a trifle, and then not revealing the new method, would make for a pretty good encryption algorithm... but it doesn't.  Such algorithms crumble under attacks by determined experimenters, and I predict that this one will, also.  Yes, it's nice that a casual glance at an answer file will not reveal a password, and from that point of view I applaud what Microsoft's done by encoding passwords in answer files.  But I wish the Help file, or perhaps the WSIM itself flagged the fact that the passwords are not encrypted, just obscured, and that administrators should therefore treat these files as if they contained cleartext passwords — which they do, in essence.  As security types often say, a false sense of security is worse than no security at all.

Third, while this whole system of XML files, WSIM and a vastly improved help file are very welcome, it ain't all perfect.  It took me hours to figure out whether these handful of settings went into Pass 4 or Pass 7, and there are many, many other settings.  I wish Microsoft had been more specific about what settings go into which passes under what circumstances.  So again it's a great overall set of tools, but building mini-Setup answer files will require a lot of experimentation time, and so I sincerely hope that I've saved you some time with this article!

Conferences

TechMentor and Windows Connections in Orlando in March/April

In late March and early April I'll be at TechMentor and Windows Connections doing my Longhorn keynote as well as a variety of breakout sessions.  Both shows are in Orlando, on adjoining weeks — TechMentor's the last week in March, and Connections is the first week in April.  If you decide to sign up for TechMentor, then please notice that the registration form includes a field "Promo Code;" if you enter "Minasi" then they'll know that you read this newsletter; I'd appreciate it, and thanks.

The MR&D Forum "Tech-O-Rama" in Virginia Beach May 3-6 2007

Join me and a whole bunch of techies at the annual event where the hard-working members of our online Forum get together to swap stories, listen to technical talks from some of our luminaries and just generally have a great time.  Info, speakers and talks at http://web2.minasi.com/forummeet2007/. 

Bring Mark to your site to teach

I'm keeping busy doing Vista seminars and researching Longhorn, but I've still got time to visit your firm.  In just two days, I'll make your current NT techies into Vista, security, XP, Active Directory or 2003 experts.  (And better yet they won't have to sit through any Redmondian propaganda.)  To join the large educational, pharmaceutical, agricultural, aerospace, utility, banking, government, telecommunication, law enforcement, publishing, transportation, military and other organizations that I've assisted, either take a peek at the course outlines at www.minasi.com/presentations.htm, mail our assistant Jean Snead at Assistant@Minasi.com, or call her at (757) 426-1431 (only between noon-5 Eastern time, weekdays, please).

Until Next Month...

Have a quiet and safe month. 

Please share this newsletter; I hope that it is a useful source of NT/2000/2003/XP/Vista information.  Please forward it to any associates who might find it helpful, and accept my thanks.  We are now at over 40,000 subscribers and I hope to use this to get information to every single Mastering 2003, XP, NT and 2000 Server reader. Many, many thanks to the readers who have mailed me to offer suggestions, errata, and those kind reviews.  As always, I'm at http://www.minasi.com/gethelp and please join us at the Forum with technical questions at www.minasi.com/forum.  Thanks for letting me visit with you, and take care. 

To subscribe, visit http://www.minasi.com/nwsreg.htm. To change e-mail or other info, link to http://www.minasi.com/edit-newsletter-record.htm.  To unsubscribe, link to http://www.minasi.com/unsubs.htm. Visit the Archives at http://www.minasi.com/archive.htm. Please do not reply to this mail; for comments, please link to http://www.minasi.com/gethelp.

All contents copyright 2007 Mark Minasi. You are encouraged to quote this material, SO LONG as you include this entire document; thanks.