Mark Minasi's Windows Networking Tech Page
Server 2012 Is the Biggest Server in Ages; Understand It in Just Two Days in Chicago June 10/11, SF, DC, Alpharetta, Stamford or San Diego
Windows Server 2012, the latest in a nearly twenty-year-long series of versions of Windows Server, is out. I've been tracking 2012 since we got our first glimpse of it early September 2011, and it is huge. That means that if you're the person who's got to plan for 2012, to make the "do we upgrade or skip?" call about 2012, or to get 2012 up and running, then you've got a lot of things to learn. Which 2012 features will matter to your particular organization, and which can you ignore? The answer's easy... just download a zillion white papers, watch a year's worth of videos, and stay up late trying it all out...
... Or you could join me for a two-day comprehensive, independent and fun explanation of what Server 2012 offers. If you'd like to find out more, the course outline is at http://www.minasi.com/2012 and I'm delivering it in several locations in the next few months, as you can see at http://www.minasi.com/pubsems.htm. I hope you can join me, or perhaps invite me to present this material exclusively for your organization.
Time to Learn PowerShell! Learn it in One Day with Mark in the Same CitiesAs someone who's worked with programming and scripting tools for, well, um, many years, I have to say that PowerShell is one of the best, and it's something that I think that every admin can and should learn. Join me at a one-day seminar on AD administration with PowerShell — AD administration is just a sneaky excuse to teach you PowerShell while you're not looking — and see how to save time by PowerShelling. Course outline at http://www.minasi.com/adposh1/ and, again, see our dates and locations at www.minasi.com/pubsems.htm .
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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:
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:
(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:
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:
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:
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:
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'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>
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:
Here's how to try it out, assuming that you have the above XML in a file called "sysprep.xml."
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!
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.
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/.
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).
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.