Mark Minasi's Windows Networking Tech Page
Issue #89 May 2010

Document copyright 2010 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.

What's Inside

• News
  • Join Me at a Seminar!
• Tech Section
  • Changing Windows 7's Default User Profile... And a Few Sysprep Tricks
  • Answer File Cleanup:  How to Keep Users From Seeing Passwords in Your XML Setup Files
• Conferences
• To Subscribe, Unsubscribe, Read Old Newsletters or Change Your Email Address

News

Hi all —

Need to set up a uniform Default User profile on your Windows 7 boxes but you're finding that the old XP ways don't work any more?  I did too, and in searching for an answer on the Internet, I found to my chagrin that 99% of the pages on the Internet about how to create default users in Win 7 are completely wrong.  It turns out that solution's relatively easy, even if the tool you've got to use to get that thing accomplished is about the last thing I'd have guessed.  In short, to change the Default User profile on a system, you log onto your reference system, get the system the way you want it, create a Sysprep answer file with Windows System Image Manager that includes the "CopyProfile" setting and set it to True, and run Sysprep with that answer file.  I will explain all that in detail in this newsletter but let me back up a bit and explain what all of this "default user" stuff is all about for those just joining the party, and before I do that, here's a word from our sponsor....

Changing Windows 7's Default User Profile... And a Few Sysprep Tricks

Not that long ago, companies employed one PC desktop support person for every fifty to one hundred users, so when a user's desktop started acting up or when a new PC arrived and needed to be deployed then support folks could take the time to build and customize every PC essentially by hand.

Nowadays, in contrast, one PC desktop support expert must be able to support hundreds or even thousands of users.  PC support folks must, therefore, be able to solve the "my PC doesn't work!" or the "we just got a new PC, it needs to be ready for such-and-such bigwig stat!" problem in a manner that gets it done in minutes rather than hours.  As a result, many of us have become deployment experts, whether we wanted to or not.  Thus, when most of us want to build a new system, many of us no longer shove a CD/DVD into a drive when we need to build a system; instead, we try to

• Seek to make desktop systems as uniform as possible in terms of their operating system, applications and OS/application settings, and 
• Tend to make heavy use of "cloning" or "imaging" tools that let wipe a computer's hard disk and install a whole hard disk image that contains the organization's standard operating system, applications and settings in twenty minutes or so, tools like Symantec's Ghost, the open source community's Clonezilla, or Microsoft's free ImageX, to name a few.

Introduction: Creating the Standard Image

The imaging part is pretty easy nowadays, thanks to a plethora of imaging tools.  The tough part is in creating a prototypic computer that, once converted to an image, can be quickly and usefully copied ("deployed") to zillions of machines.  In a sense, it's sort of like publishing books, post-Gutenberg, in that while cranking out thousands of copies of a book is pretty easy, writing a book that's accurate, well-organized, complete and readable for many people is fairly difficult.

Simplified, we can create a good, useful, massively-duplicatable-image if it's got a good operating system, applications, and a useful-for-the-organization set of default user settings for that OS and those apps.  Handling the first two is fairly easy.  The last, however, can be a pain:  while PCs offer us many degrees of freedom when it comes to configuring our desktops, the needs of the modern "one support person for a few bazillion users" model means that the more uniform the desktop, the more easily supported and deployed is that desktop.  And in the Microsoft world, one way to deliver a fairly uniform set of desktop settings -- power configuration, autorun settings, folder preferences and the like -- is to modify something called the "default user profile."  The idea is that a deployment expert gets the perfect Windows 7 prototype image down in these steps:

• Build a Windows 7 system
• Add applications
• Configure the system with a set of user preference defaults (power, wallpaper, the number of previously-opened Word documents to remember, user account control behavior, and so on), which is collectively known as the "user profile"
• Copy those profile settings into something called the "default user" profile
• Sysprep that system
• Create an image of that system with some imaging tool onto a file

From Standard Image to "User With Standard Profile"

The result, that image file is called the "standard image."  Copying that image onto some desktop PC -- "deploying" the image -- yields a system with, as we've seen, a standard OS and applications.  But when a user sits down at that newly-imaged system, how can we ensure that the OS and applications are pre-configured to the organization's OS and app settings?  That's where the default user profile does its magic.  If I sit down to a newly-imaged system and log on, that Windows system must create a basic "starter" local profile (the user settings and data, recall) for me.  The Windows system does that in one of three ways.

• First, looks to see if my account has a roaming profile.  While roaming profiles are a great idea, the realities of users (who drop gigabytes of junk in their desktop and Documents folders) and networks (which aren't really equipped to download those gigabytes every time that users log on) make most of us forgo the immense potential of roaming profiles.
• Failing the existence of a roaming profile for that user account, Windows then looks to exploit a neat (but largely unknown and sadly unused) feature whereby the Windows system looks in the folder "\\DCname\Netlogon\Default User" for a user profile.  (It's neat, but understand that you can only have one default profile for a domain.  So as long as you've got both new Win 7s and the odd new XP system, then making them both face the same new profile might not be an optimal idea.)
•  If Windows doesn't find a roaming profile or a Default User folder on Netlogon, then Windows looks on its local hard drive for a user profile named "Default User" in C:\users\Default User.

For most of us, then, the easiest way to deliver our users a fairly uniform desktop is to give our users desktops that include a fine-tuned local Default User profile.  So how do we do it?

Modifying the Default User Profile in Windows 2000 and XP

Well, for anyone reading this who's been rolling out Windows 2000 or XP images for the past ten years -- that is, the folks who've been patiently waiting for me to get past the basics so far (thanks!) -- the answer has been pretty well-known:  log on the prototype PC, get things the way you like, and then log off that account and log onto a different account (one with administrative powers) and do a bit of Control Panel fiddling.  More specifically, 

1. Log onto the prototype machine as some user (let's call it "testuser")  That account usually needs to have local administrative powers because basic application setup usually requires the ability to write to HKEY_LOCAL_MACHINE and Program Files. 
2. Set up the operating system and applications to whatever standards exist in the organization -- wallpaper, sounds, power preferences, items to pin to the Start menu and the like -- and then log off to "cement" those settings into testuser's profile.
3. Log back on with a different account having administrative powers.  (In some cases you can log on as testuser, provided that testuser is a local admin account, but whenever messing with profiles it's always more foolproof to log on as a different user so that the profile folders that you're about to copy are not locked by some process, which can gum up the works.)
4. Open an elevated command prompt and type C:\Windows\system32\rundll32.exe sysdm.cpl,EditUserProfiles and then press Enter.  (You could alternatively open Control Panel and go to System and Security, then System, then Advanced System Settings, then finally in the "User Profiles" section you'd click "Settings...")
5. You'll then see a dialog box like this:

6. In a pre-Vista version of Windows, this dialog box would show all of the profiles on the system (as this one does) but, when you clicked on Testuser's profile, you could then click the button labeled "Copy To...," and you'd then copy Testuser's profile to the folder where Windows keeps the Default User's profile.  (It's "C:\Documents and Settings\Default User" on Win 2000 and XP, "C:\Users\Default User" on Vista and later.)  Unfortunately, as you can see from the above screen shot, the "Copy To..." button has been grayed out.

Clearly, then, we'll need A Better Way.

Modifying The Default User Profile (Windows 7 and Windows Vista)

In Windows 7, you redefine the Default User's profile with these steps (just an overview for the impatient and expert, step-by-steps coming):

1. Configure the prototype PC, using a local account with administrative powers. 
2. Customize as desired.
3. Log off and log back on, using the same account.
4. Create a Sysprep answer file, using a setting "CopyProfile" to True in Pass 4, Specialize.
5. Add a second item to the answer file named "SkipRearm" and set it to 1 in Pass 3, Generalize.
6. Save the answer file.
7. Run Sysprep using that answer file, and use the resulting system to create your master image.

More specifically:

Configure the System, Log Off and Back On

First, log onto the prototype PC -- the one that you're going to create your master image from, recall -- as a local user with administrative powers.  (Again, let's call the account "Testuser."  Microsoft claims that it's got to be a local user or else the profile won't get written just right, so let's take them at their word and avoid any domain accounts for this.)  The account will need local administrative powers because, as we'll see, we must run Sysprep from the same account that we used to do the customizing, and Sysprep requires admin powers to run.

Next, set up the prototype PC as desired to make it look and act like your organization's standard desktop:  adjust the wallpaper, change the autorun settings, the sound settings, power profiles, etc.  Not every customization that you do will get copied to the Default User profile that you're going to create, as profiles only retain settings in HKEY_CURRENT_USER, not HKEY_LOCAL_MACHINE.  For example, whenever I change the list of things that the Action Center annoys me about and then Sysprep a system, then Windows 7 forgets those settings.  (I would have imagined that they went into HKCU, as I apparently needn't elevate to make the changes, so it's a bit of a puzzle.  But heck, that's part of the fun of Windows administration, right?)

Once you've got the system the way that you like it, log off and log back on to ensure that all of those settings get completely written to Testuser's account.

Use WSIM (or Notepad and Clipboard) to Create an Unattend Sysprep Answer File

Next, create a Sysprep answer file.  (Here I'm going to explain how to create the answer file, but in truth it's just a few lines of XML, so I've created that XML for you and will present it below.  Thus, if you'd prefer to skip the WSIM steps that follow, then just grab my XML below.)

You create a Sysprep answer file using a tool called "Windows System Image Manager" or WSIM.  You find that in a software suite called the "Windows Automated Installation Kit or WAIK, a free download from www.microsoft.com/downloads.  If you're unfamiliar with the WAIK, creating WSIM answer files or working with Windows 7's Sysprep, then you can find some helpful background information and examples in my newsletters 59, 60, 62 and 71.  (Or, again, just skip down a bit to the ugly-looking XML file that I'm including below and you won't have to WSIM at all.)

As you saw in #60 and #62, open up WSIM and associate it with a Windows image. I'm using Windows 7 64-bit Ultimate for my screen shots (I found it in \sources on my Windows 7 installation DVD), so yours may look a bit different if you've started from a different version.  Then

• Click File / New Answer File...
• Open the Components box in the "Windows Image" lower left-hand pane of the WSIM window.
• Locate and right-click on the blue box labeled "amd64_Microsoft-Windows-Setup_6.1.7600.16385_neutral" if you're running 64-bit Windows 7, or "x86_Microsoft-Windows-Shell-Setup_6.1.7600.16385_neutral" if you're using 32-bit Windows 7.
• In the drop-down menu that results, choose "Add Setting to Pass 4 Specialize."
• To the right and up, under the "Properties" section, click "CopyProfile."
• In the small down-facing triangle that appears just to the right of CopyProfile, choose "true."  WSIM will look like the following screen shot:

The CopyProfile setting you've just implemented will tell Windows to copy Testuser's profile to the Default User profile when the prototype image (which we're about to create) gets deployed to a system, which is how we achieve our goal of changing the default Windows profile.  But Sysprep has a troublesome side-effect in Windows Vista and later, as you may have read in Newsletter #71:  it "rearms" the Windows image, and you can only rearm a Windows image three times before it can no longer be imaged Sysprepped at all, which sort of hamstrings our ability to do any future work on the standard image.  The answer, as explained in #71, is to set a value "SkipRearm" in a Sysprep answer file and set it to 1.  We can do that like so:

• Back in Components, right-click "amd64_Microsoft-Windows-Security-SPP_6.1.7600.16385_neutral" if you're running 64-bit Windows 7 or, if you're using 32-bit Windows, "x86_Microsoft-Windows-Security-SPP_6.1.7600.16385_neutral."
• In the resulting drop-down box, choose "Add Setting to Pass 3 Generalize." 
• To the right and up, under the "Properties" section, click "SkipRearm."
• To the immediate right of "SkipRearm," enter the numeral "1."  WSIM will look like the following screen shot:

Tell WSIM to save this answer file to whatever name and folder that you like.  In my case, I've called it makedefaultuser.xml and put it in a folder on C: called "\files."  If you open it with Notepad, it'll look like this:

 <?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="specialize">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<CopyProfile>true</CopyProfile>
</component>
</settings>
<settings pass="generalize">
<component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
</settings>
<cpi:offlineImage cpi:source="catalog:e:/install_windows 7 ultimate.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
 

If you're running a 32-bit version of Windows 7, just do a global search-and-replace, changing all instances of "amd64" to "x86."

Notice that most of the file is basically just "boilerplate" -- I've colored the "meat" of the file in blue.  As I promised, you needn't download WAIK nor run WSIM to create this file; instead, all you need do is to copy the XML above (starting at "<?xml version" and ending at "</unattend>"), copy it to Notepad, and save that file in any folder under any name that you like (you needn't even use the "XML" suffix -- again, I've saved mine as "c:\files\makedefaultuser.xml," but anything will work -- just be sure to remember the name and location for the next step!

Sysprep the System from the Command Line

We're now ready to Sysprep.  You can find Sysprep on every Windows 7 system in the  c:\windows\system32\sysprep folder, so open up an elevated command prompt (don't just click "Command Prompt," right-click it and choose Run as Administrator) and navigate there by typing

cd c:\windows\system32\sysprep

And then type net stop wmpnetworksvc & sysprep /generalize /oobe /reboot /unattend:filespec-of-the-XML-file

For example, on my system I'd type

net stop wmpnetworksvc & sysprep /generalize /oobe /shutdown /unattend:c:\files\makedefaultuser.xml

That line is actually two commands.  The first, "net stop wmpnetworksvc," is a workaround to a Windows 7 bug.  For some reason, running the "Windows Media Player Network Sharing Service" (and why in blazes does a business-oriented version of Windows run that automatically anyway?) kills Sysprep, leading to the quite disturbing and not particularly illuminating "A fatal error occurred while trying to sysprep the machine" error message.  (And if you're thinking "hey, I've never seen that error," it's because wmpnetworksvc is a "delayed auto-start service," meaning that it takes a minute or two to get started after you log on, and so if you're quick about rebooting your target system, logging on and running Sysprep, then wmpnetworksvc isn't yet running and so never gums up the works.)

Once Sysprep has run as desired and shut your prototype system down, then reboot the system not from its hard disk but instead from WinPE -- if you let the system boot from the OS on its hard disk, then you'll un-do Sysprep's effects -- and then create your basic system image from the prototype computer's hard drive.  (If you want to use ImageX, the free Windows tool, then you can read about it in Newsletter #61.)  Deploy that image to a new system, start it up and it'll show you the familiar first-time-run screens asking you to create a user account, name the machine, set Windows Update settings and the like and, when you start up the newly-imaged system and log on as any user (except for one with a domain-based roaming profile), you'll find that your session behaves according to whatever settings you created for the default user. 

Before I finish this, let me add two quick notes. First, KB 2101557 notes that if your prototype machine has more than one account in it, then Sysprep might well get confused about which one to copy over, so I guess it's a best practice to just work from one account on your prototype machine. Second, my friend Dan Holme points out to me that the whole idea of a "Default User" profile just plain doesn't work on many apps, as their developers never really built their apps' profile areas to be robust enough to survive being Default User-ed, so to speak. So if your app's not getting set up as you expect, it might be a good idea to talk to the vendor, or ... gulp ... start scripting!

Answer File Cleanup:  How to Keep Users From Seeing Passwords in Your XML Setup Files

It's sort of a side-issue, but I'm often asked, "where does the answer file go after I've deployed an image?"  Deployment techies wonder about this because after all the XML file is just a text file that anyone can open with Notepad, and -- as you've seen if you've looked at Newsletters #60 and  #62 -- those XML files can, in some circumstances, contain domain administrator passwords, and the idea of any old user stumbling across a file that contains the keys to the kingdom is a somewhat frightening one.  I'm not 100 percent sure why Microsoft doesn't just delete the silly thing as a matter of course, but they don't, so here's a bit of background info and a workaround.

No matter what you call your Sysprep answer file, Windows renames it to "unattend.xml" and stores it in c:\windows\panther.  As every authenticated user has "read" access to that folder, that means that any user can view the file and, as I've already noted, any passwords or other sensitive data within.  It would be nice, then, to tell Windows to delete c:\windows\panther\unattend.xml once it's finished setting up a new system -- and you can.

The key is in a WSIM feature that lets you add any command-line command that you like to an answer file.  Just open up WSIM and load your existing answer file, then do this:

1. Click Insert / Synchronous Command / Pass 7 oobeSystem...
2. That raises a dialog box with title "Create Synchronous Command and a text box labeled "Enter a command line:"
3. In the text field, type "cmd /c del c:\windows\panther\unattend.xml" (without the quotes)
4. Click OK
5. Save the answer file.

Specify the modified answer file as you did earlier with the /unattend: option on Sysprep, and you'll find that your deployed systems no longer contain a kryptonite-laden unattend.xml.  And in case you don't want to have to mess with WSIM (who could blame you?), here's the XML that you can copy and paste yourself:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
<settings pass="specialize">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<CopyProfile>true</CopyProfile>
</component>
</settings>
<settings pass="generalize">
<component name="Microsoft-Windows-Security-SPP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SkipRearm>1</SkipRearm>
</component>
</settings>
<settings pass="oobeSystem">
<component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<FirstLogonCommands>
<SynchronousCommand wcm:action="add">
<Order>1</Order>
<CommandLine>cmd /c del c:\windows\panther\unattend.xml</CommandLine>
</SynchronousCommand>
</FirstLogonCommands>
</component>
</settings>
<cpi:offlineImage cpi:source="catalog:e:/install_windows 7 ultimate.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>
 

Again, if you're doing 32-bit, change the "amd64" references to "x86." 

Best of luck in building images that incorporate your preferred user settings... and that protect admin passwords from users!

Upcoming Conferences

If you can't make it to a Server 2012, Windows 8 or PowerShell seminar, perhaps I'll see you at...

TechMentor Vegas

TechMentor returns to Las Vegas this September 30-October 4 and I'll be doing a bunch of talks, so don't miss it!  Find out more at http://techmentorevents.com/Home.aspx.

TechEd

I'll be at TechEd North America and TE Europe this year doing a talk on Server 2012 networking and Windows 8 goodies, if you'll be at either show please stop by!

To Subscribe/Unsubscribe, Read Old Newsletters or Change Your Email Address

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 2010 Mark Minasi.  I encourage you to quote this material, SO LONG as you include this entire document; thanks.