Document copyright 2010 Mark Minasi; please see below for info on subscribing, unsubscribing or copying portions of this text.
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
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:
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.
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,
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):
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
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:
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"?>
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
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:
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"?>
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!
If you can't make it to a Server 2012, Windows 8 or PowerShell seminar, perhaps I'll see you at...
TechMentor returns to Las Vegas (the Tropicana) 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. This year, TechMentor has moved away from the standard 75-minute talks to more in-depth three- and four-hour talks. I'm doing a precon on Monday of that week where I will be explaining and demonstrating the cool new file server system introduced by Server 2012's "Dynamic Access Control" all-new feature. Later that week, I'll take you through the various kinds of failover and high availability options in Hyper-V -- clusters, live migration and the whole shebang. Lots of cluster explanation, lots of demos, and lots of PowerShell!
Windows Connections Vegas
This year, Connections and TechMentor appear in Vegas on the same week! Connections will be at the Mandalay Bay and they've got an all-star lineup. Info at http://www.devconnections.com/dev13/public/mainhall.aspx -- I'm keynoting about Windows 8.1 and Server 2012 R2 on Monday, as well as assisting my friend Mark Russinovich in his don't-miss-it look at Microsoft clouds, and finally doing my "How to Manage Server 2012 like a Pro or, Better, Like an Evil Overlord!" talk.
If you're going to DevIntersection, drop by one of my talks. I'm delivering the world's fastest 2012R2 and Windows 8.1 overview keynote, a soon-to-be-famous breakout session called "Windows 8 Doesn't Suck as Much as You Think it Does," a fun look at PowerShell and why you care about it called "Learn-PowerShell or Leave-Industry," and a look at Server 2012's nifty new networking tools. If you're at Intersect, I hope you'll drop by! Info is at http://devintersection.com/ and they're in Vegas from October 27-30.
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.