Windows 7

The 10 Things to Do First for Windows 7

Bill Boswell


At a Glance:

  • Getting to know Windows 7
  • Dealing with the latest volume-activation requirements
  • Developing a roadmap
  • Handling new distributed-security features
  • Virtualizing desktops and infrastructures
  • Removing users' local-admin rights


1. Get to know Windows 7 on a first-name basis.
2. Learn Windows PowerShell.
3. Plow through licensing.
4. Focus on strategic improvements.
5. Expand the deployment scope.
6. Prepare for distributed security.
7. Virtualize your desktops.
8. Evaluate enterprise features.
9. Build compatibility safety nets.
10. Remove your users' local-admin rights.
You Can Be Heroes—for More Than One Day

When you run your thumb down the list of new features and improvements in Windows 7 (see the feature comparison chart at, you're bound to wonder how you're going to get your arms around all that new technology so that you can deliver it to your users without too much disruption.

Following are 10 steps that can help you accomplish that goal.

1. Get to know Windows 7 on a first-name basis.

Obviously, the first step is to gain personal experience. And that means more than just puttering around in the lab. Install Windows 7 on every workstation in your organization and on the machine you use at home for remote-access trouble calls. Force yourself to find ways to make everything work.

Most tools for managing Windows servers from Windows 7 are included in the Windows 7 Remote Server Administration Tools (RSAT), which must be downloaded separately. At this writing, the final RSAT package hasn't been finalized. The release candidate is available at

Don't be surprised when your Administrative Tools folder doesn't get populated immediately after you install the RSAT package. The RSAT tools come in the form of a Windows Feature set that must be separately enabled using the Programs and Features applet in the Control Panel. See Figure 1 for an example. For an unknown (but, I'm sure, entirely valid) reason, you must separately click each feature to select it. The parent check blocks don't automatically select their children.


Figure 1 Windows 7 RSAT Feature List (Click the image for a larger view)

The Active Directory RSAT tools will work with Windows 2003 and Windows 2008 domain controllers, although some features, such as the Active Directory Recycle Bin, require Windows Server 2008 R2 functionality level.

Managing Exchange 2003 from a Windows 7 workstation isn't quite so straightforward: The Exchange System Manager (ESM) console that comes with the Exchange 2003 installation CD doesn't run on Windows 7. There's a special version of ESM designed for Vista that you can download from This console will run fine under Windows 7, but the installer makes a specific check for Vista (Windows version 6.0.0) that fails on Windows 7. You can use a free Microsoft tool called Orca to modify the MSI file to remove or modify the version check. Orca comes as part of the Windows Installer SDK; download instructions are at However, I think you'll find it much simpler to load ESM in XP Mode. More on that later.

2. Learn Windows PowerShell.

It's safe to say that the single most important skill a Windows administrator will need in the coming years is proficiency with Windows PowerShell. Windows 7 and Windows Server 2008 R2 both have Windows PowerShell version 2 baked into the operating system and it's enabled by default. You should plan on installing Windows PowerShell v2 on your remaining servers and desktops so that you can use one script technology to manage your entire fleet. (Note that you won't be able to install PowerShell v2 on Exchange 2007 servers or workstations. These machines require PowerShell v1.1. But even v1.1 gives you access to a wide range of functionality.)

Even if you're a die-hard GUI administrator who hasn't opened a command prompt since Y2K, you'll find that most new GUI tools from Microsoft are now taking the form of graphical front ends on top of Windows PowerShell cmdlets. Many of these tools will tell you the underlying command string if you know where to look for it. That's an easy way to see how the cmdlets work.

Many great Windows PowerShell references are available, including the outstanding book "Windows PowerShell in Action" (Manning Publications, 2007), written by Bruce Payette, a member of the Microsoft Windows PowerShell team. A new edition is forthcoming; you can pay a few dollars to read the early chapters, reserve a copy when it's released and get an e-book of the first edition at the publisher's Web site, Also check out "Windows PowerShell Pocket Reference" (O'Reilly Media Inc., 2009) by Lee Holmes, another Windows PowerShell team member. And visit the Windows PowerShell team blog at There, you'll find one of the most interactive developer teams on the planet. Every word on this blog is worth reading. Twice.

Here's more good news: The Windows 7 RSAT suite contains the same Active Directory Windows PowerShell cmdlets that come on Windows Server 2008 R2. See Figure 2 for an example. The best source for more information is the Active Directory PowerShell blog at powershell.gif

Figure 2 ADPowerShell cmdlets in action. (Click the image for a larger view)

You can use these AD cmdlets to manage domains running Windows 2003 and Windows 2008, but you'll first need to install the AD Management Gateway Service (also known as AD Web Services, or ADWS) on at least one domain controller. At this writing, ADWS is in beta; it can be downloaded from

The ADWS service requires Windows Server 2003 SP2 (regular or R2) or Windows Server 2008 plain or SP2. You'll need to install the .NET Framework 3.5 SP1 ( and a hotfix ( that enables support for the Web service flag in Netlogon. (The hotfix is baked into Windows Server 2008 SP2.)

If you work in one of those organizations where getting changes approved for domain controllers takes a lot of time and effort, and you'd like to start using Windows PowerShell to manage Active Directory while you still have your youth and vitality, take a look at the free Active Directory cmdlets from Quest at

3. Plow through licensing.

If your organization didn't deploy Vista, you may not be familiar with the latest volume-activation requirements in Windows. If you're an admin in an enterprise with more than 25 desktops and/or five servers, if your organization takes advantage of a volume-license program such as an Enterprise Agreement or Select Agreement, and if you purchase Windows 7 Professional or Ultimate (or you upgrade to those versions as part of Software Assurance), you should do the following: Print out a short stack of Volume Activation documents from, pour yourself a few ounces of a bold Tuscan wine and start studying.

When you eventually declare yourself completely confused, download an excellent webcast by product manager Kim Griffiths, who does a great job of explaining the program's nuances. You'll find the webcast at

In brief, to deploy Windows 7 desktops using volume licenses, you'll probably need to install a Key Management Server (KMS). I say "probably" because you may not have enough machines in your organization to support KMS activation. A KMS won't begin doling out activation approvals until it receives requests from at least 25 desktops and/or five servers. That's to prevent unscrupulous vendors from using the same volume-license key for multiple small clients. Once activated, a client must reactivate every six months. Despite what you may have read elsewhere, there's no reduced functionality mode in Windows 7. If the activation key expires, the desktop background simply goes black and a notification balloon states that the operating system isn't genuine.

If you have fewer than the required number of devices for a KMS, you can obtain a Multiple Activation Key (MAK) that's stocked with activation allocations based on the number of volume licenses you purchase, plus a fudge factor that allows you to add machines between true-ups. An MAK key is authenticated by a Microsoft hosted service, so you'll need Internet access following the OS installation.

A change introduced with Windows 7 and Windows Server 2008 R2 now allows virtual machines to count against the KMS minimum for activation. This helps to boost your device count if you're a small shop that uses lots of virtual desktops and servers.

If you already have a KMS for Vista and Windows Server 2008, you'll be able to download an update for activating Windows 7 and Windows Server 2008 R2 machines.

4. Focus on strategic improvements.

Once you're familiar with system administration using Windows 7 tools and you've set up the technology to activate your desktops, it's time to start planning for deployment to end users. The most important thing to do at this point—and I know you don't want to hear this—is to hold a meeting.

Steady … steady. Stay with me. This will be a different sort of meeting. You're going to gather all your IT cousins who have been working with Windows 7. Not just architects. Not just desktop folks. Not just the server team or help-desk technicians or internal developers or project managers. You want representatives from every team. Think of it as an ecumenical council. Make it an all-day affair. Tell all potential attendees that only the cool kids will be on this bus, so they certainly don't want to miss out.

Do yourself a favor before the meeting: Arm yourself with numbers. That's because, at some point, somebody is bound to say: "We really should put together an enterprise application catalog that we can use to do our compatibility testing. And can all our machines really run Windows 7?" Then the group will spend an hour or two talking about how to assemble the catalog or why it can't be done or how John on the desktop team already has a spreadsheet with that information but he hasn't refreshed it in a while and it doesn't include the machines in Europe, the Middle East and Africa—and so forth and so on.

You can short-circuit that whole conversation with two free inventory and analysis tools. First, there's the Microsoft Assessment and Planning Toolkit (MAP 4.0), available at This agentless tool will collect statistics on your desktops and give you a report on which ones are ready for Windows 7, which ones need hardware upgrades and which desktops will never be ready—no matter how much lipstick you put on the pig. MAP generates spiffy pie charts for management (see Figure 3) and piles of greasy numbers for the techies (Figure 4).


Figure 3 Microsoft Assessment and Planning Toolkit 4.0 Assessment Summary (Click the image for a larger view)


Figure 4 Microsoft Assessment and Planning Toolkit 4.0 Assessment Details (Click the image for a larger view)

When you run the tool, don't be too restrictive on your hardware requirements. I wrote the first draft of this article running Windows 7 and Office 2007 on a 1.6GHz Celeron desktop with 512MB of RAM and a bunch of line-of-business applications running in the background. Performance was perfectly acceptable.

Next, load up the Microsoft Application Compatibility Toolkit (ACT) 5.5, available at, and use it to get software stats on selected desktops. The ACT assessment doesn't just skim the Installed Software list in the Registry; it looks in crannies and cubbyholes for applications that have been tucked away by all sorts of legacy installers. This capability requires a local agent, which is deployed from an ACT management server and which sends back periodic reports for several days before de-installing itself.

As you can see in Figure 5, ACT does a thorough job of data collection—very thorough—so you'll need a server with moderately good horsepower to run it. You can use SQL Express to store the data unless you want to include thousands of machines in the sample. However, if you have your software loads broken down by department or functional workgroup, you can select a few representative machines from each group as a sample. Even with tens of thousands of desktops, you should be able to sample 2 percent to 3 percent to get an idea of the work ahead of you.


Figure 5 Microsoft Application Compatibility Toolkit 5.5 Application Report (Click the image for a larger view)

Now, let's get back to that big meeting. Do it right. Dip into the department coffers to buy enough donuts and pizza to choke a medium-sized T. rex. Find a room with wall-to-wall whiteboards. If you can't fly everyone to one location, line the perimeter of the meeting room with big screens, fire up your network meeting software of choice and make sure there are microphones and cameras everywhere.

In the meeting's first half, ask attendees how they use Windows 7 to improve their daily tasks. Find out what took them longer to learn. Listen to their gripes. Spelunk around inside those brains looking for a combination of features that will materially improve your users' productivity, enhance security, encourage mobility and simplify work processes.

Spend the second half of the day outlining a deployment plan. Don't spin your wheels trying to resolve potential compatibility or interoperability or work-process problems. Any organization that's been running XP for several years is bound to have evolved procedures that are getting a little, um, creaky. Identify the issues. Categorize them. Move on.

Pretend you're a geologist testing a new oil field. Concentrate on finding the big pools and figure out how to do the extraction later.

The result of this meeting will be a who-what-when-where-how roadmap. It will address questions such as: What features will you deploy? Who will do the prep work? How long will it take? Which users will be most affected? How can you obtain those users' cooperation? How much will deployment cost in hard and soft dollars? Where are the potential failure points? What resources are required for testing? And most important, when can the work begin? Boil it down to five slides, sell it to management and then execute, execute, execute.

5. Expand the deployment scope.

Some of the best features in Windows 7 may require a few changes to your infrastructure. For example: High on my list of favorite features is the combination of Federated Search and Libraries in the new Explorer shell. These work together to provide a centralized and flexible view of distributed data.

The key to using Federated Search is finding or building connectors to Web-based data repositories. A connector is a set of configuration items inside an .OSDX file. These items point at a Web site and describe how to handle the content. Here's an example of a Bing connector:

<?xml version="1.0" encoding="UTF-8"?> <OpenSearchDescription xmlns="" xmlns:ms-ose=""> <ShortName>Bing</ShortName> <Description>Bing in Windows 7.</Description> <Url type="application/rss+xml" template=";query= {searchTerms}&amp;format=rss"/> <Url type="text/html" template="{searchTerms}"/> </OpenSearchDescription>

When you right-click an .OSDX file, Explorer shows a Create Search Connector option in the property menu. Click it and the connector gets added to the list of items under Favorites. Initiate a search of the connector by highlighting it and typing terms into the search field in the upper-right corner of the Explorer window. In a few seconds, Explorer populates the results pane. Click Preview to view the contents of a selected page. Figure 6 shows an example.


Figure 6 Search Connector in Explorer (Click the image for a larger view)

Connectors are simple to build. Convince your internal developers to put a few together for your intranet servers (company portal, SharePoint farm and so on). Point them at the long list of sample connectors at SevenForums (, a massively useful independent site for all things Windows 7-ish. Distribute these connectors to your users using your standard package deployment tools. You can then use them to build a standard view of your distributed Web data.

Although Federated Search can handle Web site content well enough, organizations tend to struggle when it comes to delving into the terabytes upon terabytes of files sitting on file servers. This means that users who have only the vaguest notions of drive mappings and network data storage may need to spend hours sifting through their W: drives trying to find, for instance, the reports they wrote last month.

That's where Libraries come into play. Libraries aggregate files from a variety of sources into searchable objects. The default libraries in Windows 7 include the usual assortment of personal data types and locations—Documents, Music, Pictures and Videos—and it's simple to expand this list to include server-based repositories. Just right-click, select New Library and add a UNC path to a shared folder.

One catch: The target folder must be indexed. On Windows Server 2008 and higher, install the File Services role. Then, under Role Services, install the Windows Search Service. On Windows Server 2003 SP2 servers, install Windows Search 4.0, a free download from In addition, due to a limitation in the Search interface, you won't be able to specify DFS paths even if the ultimate target of a DFS folder is an indexed file server.

There's no command-line utility for creating libraries and, at this writing, no Windows PowerShell cmdlets, either. The Windows 7 SDK includes tools for working with libraries programmatically, so it won't be long before little utilities begin appearing. Keep an eye out for them.

One note about the default action of Libraries: Explorer displays Libraries in the Common File Dialog to enable users to save files to a Library by dragging and dropping. If you have multiple links under a library, one of them must be configured as the default target.

6. Prepare for distributed security.

During your initial strategy meeting, set aside time to discuss how you want to handle the many distributed security features in Windows 7. You'll want to determine a course of action early in the project because those decisions will have a substantial impact on your test matrix.

First, consider whether you want turn on the desktop firewall. When OS-based desktop firewalls were first introduced in XP SP1, many organizations turned them off with a Group Policy and that was that. The firewall in Windows 7 is much more flexible and warrants reconsideration. You can turn off the firewall while the machine is connected to the domain and turn it on when the machine is connected to a home/work network or to the Internet. You can define granular exclusions, too. Try a mix of options with the first wave of pilot users; take their feedback, along with input from your security team, to make a final decision on firewall settings. They're completely configurable by Group Policy.

Second, do you want to use AppLocker to restrict applications permitted to run on your desktops? AppLocker allows you to put together a whitelist of approved executables that you can select individually by file hash, in groups by location or in groups by publisher (that is, signed by the publisher's certificate). Once configured, these rules are downloaded by Windows 7 clients running the Application Identity service. From that point forward, only the whitelisted apps can execute. All other executables are forced to sit on the sidelines, kind of like me during my high-school athletic career.

Because AppLocker permissions are applied via Group Policy, you can tightly target the rules to computers based on OU, group membership or WMI filters.

Sifting through a mountain of applications trying to determine which should be on an AppLocker whitelist doesn't sound like much fun, but the situation shouldn't come to that. Most line-of-business machines have a fixed and limited suite of apps. Start there. After all, if you can keep the night crews from plugging flash drives into your factory kiosk machines to run games rather than build widgets, you've solved quite a few operational problems. Deal with the back-office machines later.

Finally, are you going to protect your laptops and flash drives with encryption? If your executives and managers and knowledge workers are out walking around with data drives filled with valuable intellectual property, then the answer should be a resounding yes. BitLocker allows you to encrypt the entire hard drive and all the data on it. BitLocker To Go extends this encryption to cover flash drives and other portable media. You really do need to deploy it.

Now, I'm not saying that you should simply flip on the BitLocker policy in Group Policies, encrypt a bunch of drives and walk away. As with any other encryption-based technology, you must carefully think through the options. Don't be that person whom others tell stories about for years, as in "Remember when the CEO got locked out of her laptop an hour before the annual meeting and poor old <insert your name here> hadn't arranged for an enterprise recovery key?" It would be smart to engage a consultant who's experienced with enterprise-level drive encryption and BitLocker implementations. The main thing is: Don't let the complexity scare you. The alternative is even scarier. After all, the story people tell for years after the fact could be something like "Remember when we used to have a company before organized crime got its hands on the CFO's laptop?"

7. Virtualize your desktops.

Imagine this: You've spent a few weeks or months designing your standard Windows 7 desktop image. You've worked hard to resolve technical issues and you've found ways to quickly move applications and user data between machines, reducing the migration's impact. (The User State Migration Tool, part of the Automated Installation Kit, is a good place to start for this kind of work. For a walkthrough demo, visit Your field technicians are trained. The help-desk team is mollified with all the guidance you've posted on its SharePoint site. You're finally ready to start the rollout.

But wait. Rather than putting the operating system directly on the hard drive of each new machine, Windows 7 makes it possible to install the OS into a Virtual Hard Drive (VHD) file on the hard drive. The OS boots from the contents of this VHD, which becomes Drive C, and then sees the actual hard drive as Drive D. With proper planning, an OS installed this way could become highly portable. If John moves from Cincinnati to Chicago, the field tech in Cincinnati could copy the VHD over the network to a field tech in Chicago, who would plunk it down onto a machine so that John could get to work in his familiar desktop environment as soon as he steps out of his U-Haul truck.

If you think performance in this lashup would be less than stellar, think again. Check out the disk I/O stats at the Virtualization team blog,

There are some caveats. The first one involves hibernation, which doesn't work at all for VHD-boot machines. That means that you may not want to use VHD boot for laptops. Also, you can't boot to VHD on a drive encrypted with BitLocker, which also reduces its attractiveness for laptops.

It could be that the complexity of dealing with VHD-based deployments aren't worth the benefits, but you should at least include them in your test plan. The steps to perform the legerdemain are too long for this article, but here are some places to go for instructions: You can use Max Knor's method, described at, which essentially boots to the Windows 7 Setup CD, finesses out to a command prompt, creates the VHD and then uses it as the target for the installer—very slick. You can follow the walkthrough instructions on TechNet at; or you can view this TechNet video:

Once you get proficient with these techniques, take a look at what Kyle Rosenthal at the Vista PC Guy blog has to offer in the way of instructions for using WinPE tools to build images. For example, the steps at show how to create a bootable flash drive with the WinPE tools and an installation image on it. Armed with that tool, you can quickly install your standard image on a machine without touching a single piece of flat plastic.

8. Evaluate enterprise features.

VHD boot, along with BitLocker and AppLocker, fall into a class of features that require Windows 7 Enterprise or Ultimate. The Enterprise SKU can only be obtained via a volume license agreement. If you own Enterprise or Ultimate, you should consider deploying a few additional features to improve security and streamline operations.

BranchCache allows you to cache file transfers either at a central server in a branch office or as part of a peer network of desktops. When a client initiates a file transfer, it first checks to see whether the file is locally cached and whether the file hash matches the hash at the authoritative source. If so, it copies the file from the cache. This not only speeds things up for users, it also reduces network load across the WAN, a benefit that's sure to put a smile on the face of the network folks. (They've been known to smile. I've seen it.) I urge you to try BranchCache in your pilot testing to evaluate whether your mix of apps and associated file traffic would benefit.

Next, you could take the VHD-based quasi-virtualization I discussed in the last section to the next level—true virtualization—by deploying a Virtual Desktop Infrastructure, or VDI, on Windows Server 2008 R2 servers. In a VDI, each desktop session exists as a separate virtual machine and users connect via RDP. This setup contrasts with the more mainstream Terminal Services way of publishing a desktop, where all users swim in the same pool of application images. In Terminal Services, if somebody makes a boo-boo, then everyone else suffers. Have you seen "Caddyshack"? Enough said. (You can also avoid unfortunate interactions in a terminal server by virtualizing your applications. Check out the App-V tools in the Microsoft Desktop Optimization Pack.)

VDI can get a little expensive. The cost of supporting user virtual desktops with a full complement of memory and network access on a server can exceed the cost of the PCs. But for disaster recovery in a distributed desktop environment, you can't ask for better protection.

Another Enterprise feature, DirectAccess, allows users to connect through a Windows Server 2008 R2 gateway to the corporate network without the use of a VPN. A user can flip open her EVDO-enabled netbook while sitting in an airport and immediately start working on documents stored on corporate servers. Selling this feature to your security team might take some time, though. (Now there's a group that never smiles.)

9. Build compatibility safety nets.

One issue that you should definitely hash out at your meeting of big brains is whether your organization is ready to deploy 64-bit desktops. New machines deployed as part of a refresh cycle are virtually certain to be 64-bit capable. You're probably putting at least 2GB of RAM into them at today's RAM prices, more likely 4GB if you were able to convince Finance to approve the slightly higher unit costs. The machines are likely to have dual-core processors, possibly even quad-core, with enough video memory to support Aero. These machines will perform very well with a 64-bit OS.

Even if all your current line-of-business and commercial apps are still 32-bit, it makes sense to install the 64-bit version of Windows 7, if for no other reason than to help future-proof your investment. Clearly the world is moving toward a 64-bit standard, and you want to be ready when vendors decide to start jettisoning backward compatibility.

If you decide to roll out 64-bit desktops, test thoroughly for issues with device drivers, anti-virus suites, management agents and so forth. If you currently have 32-bit print servers, you'll need to populate the print queues with 64-bit drivers. As an alternative, you could deploy new x64 Windows Server 2008 or R2 print servers and populate both sets of drivers as you build the queues. The printer-migration wizard in Windows Server 2008 R2 will help with this task. It's worth the effort to deploy new R2 print servers because the print model has been improved to keep drivers in their own memory space so that a bad driver won't take down the spooler.

The most significant potential show-stopper is the need to run legacy 16-bit applications, which won't run at all on a 64-bit host. Your best option in this case is to use a trick that hothouse farmers in Minnesota have employed for generations to raise tomatoes: Build an environment that fools the plants into thinking they're in Dallas instead of Duluth. That is: Use XP Mode to put an instance of x86 XP SP3 on your x64 Windows 7 desktop.

Applications installed in the XP Mode virtual machine can be launched from the Windows 7 Start menu (Figure 7) just as if they were natively installed so that your users won't get confused by living in two universes. (This trick actually comes from a special RAIL hotfix, not directly from XP Mode, so you can do the same Start Menu trick by installing the RAIL hotfix, then running Virtual PC with 32-bit Vista or Windows 7, if you like.)


Figure 7 XP Mode App List in Start Menu

By default, the XP Mode virtual machine runs under a local account inside the virtual machine. The account is called User. You set the password for this account during install time and the password is set to never expire. Alternatively, you can launch the virtual machine and join it to the domain and logon with your domain credentials. You can load Exchange 2003 ESM into XP Mode along with the older admin tools to have a fully compatible admin environment. And did I mention the seamless cut-and-paste between host and virtual machines? Sweet.

XP Mode requires hardware-based virtualization, either Intel VT or AMD-V. Steve Gibson at Laguna Hills, Calif.-based Gibson Research Corp. (famous for SpinRite and ShieldsUP!) offers a free utility called SecurAble ( that will quickly tell you whether a machine meets the criteria. See Figure 8 for an example of a SecurAble report.

boswell.fig8.securable report.gif

Figure 8 Gibson Research Corp.’s SecurAble Report

If you have hundreds or thousands of PCs, you'll need a centralized management package to handle this alternate environment. This is Microsoft Enterprise Desktop Virtualization (MED-V), one element of the Microsoft Desktop Optimization Pack. At the client, MED-V 2.0 works similarly to XP Mode by installing a virtual machine that requires virtualization support in hardware. On the back end, MED-V offers a variety of tools for building and deploying packages to the virtual machines. For more information, see this Windows team blog posting at

10. Remove your users' local-admin rights.

If you haven't already pried away your users' local-admin rights, now is the time. Yes, I know it's hard. Laptop users are especially difficult to wean because the help desk can't walk them through complicated fixes over the phone. But there's also that "shadow" IT organization—department gurus and admin wannabes who find applications that meet certain tactical needs, then scurry around with thumb drives installing the apps with no regard for interoperability testing. And don't even get me started on the kind of trash that average users install on their machines when they have local-admin rights. It's amazing how the most unsophisticated user, incapable of so much as a password reset without help-desk support, can find a way to install complex multi-tiered client-server front-end applications if the reward involves shopping or sports.

Even if you muster the political strength to deny local-admin rights to the majority of users, as soon as you take those rights away, apps start to break. An astounding number of applications insist on writing to protected portions of the file system and Registry.

Windows 7 simplifies the switch to standard-user operation. Background processes redirect changes away from protected areas into user-controlled areas. That alone should resolve many issues that you might have encountered with standard-user operation with XP. There are also some simple but critical improvements that help standard users, such as the ability to change time zones, a task that required local-admin rights in XP and Vista. Ditto for changing screen resolution, doing an ipconfig /refresh to get a new DHCP address and installing optional updates.

The Application Compatibility Toolkit (ACT) contains a Standard User Analyzer (SUA) Wizard to help with vetting your apps. SUA provides an elevated-privilege launch platform for an application. Then, while the app installs and runs, SUA ferrets around inside looking for subtle issues that could keep it from running as a standard user. When it's done, you receive either a clean bill of health for the app or a list of items that need remediation.

When you download ACT, you might as well download the Application Verifier from This is used by the SUA Wizard and isn't included in the ACT package. Also, be sure to read the docs for ACT 5.5. They're a treasure-trove of great information on compatibility issues and fixes. And the June 2009 issue of TechNet Magazine extensively covered application compatibility.

But what about users who absolutely need local-admin rights, such as administrators and developers and users with enough clout to get themselves put back into the local Administrators group? Do you really want these users poking around all day with escalated privileges? I hope your answer is "no," and that's why the much-maligned User Account Control (UAC) should be your friend. Mark Russinovich recently wrote a detailed article on the topic ("Inside Windows 7 User Access Control," TechNet Magazine, July 2009). Before you push the new UAC slider to the bottom to disable it on your machines, go online and read that article.

You Can Be Heroes—for More Than One Day

It's going to take a lot of work to prepare for and deploy Windows 7, but it helps that users really want the new OS. Those who have tried it like the new interface. They appreciate the fit and finish, the responsiveness and the new features.

The opportunity to be popular as a system administrator doesn't come along very often. I'm going to enjoy it while it lasts. You should, too. Good luck with your Windows 7 deployment. Let me know how it turns out.

Bill Boswell ( is a senior consultant for Microsoft Consulting Services in the Phoenix, Ariz., office. Bill's current assignment is serving as an IT Architecture and Planning (ITAP) advisor for a major airline.