The latecomer's guide to deploying Windows 7
- 06 August, 2012 10:12
Even though Windows 8 is just a few months away from formal release, most businesses -- about 70 percent, in fact -- are still running Windows XP. And while Windows 7 has been available for nearly two years, fewer than half of businesses have switched to it. Most plan to deploy Windows 7 this year or next, now that it has had a service pack and user familiarity has grown through home installations. Plus, the April 2014 end of formal Microsoft support for XP has become a convenient deadline for many IT shops to make the switch to Windows 7.
Despite all that prep time, I'm amazed by how lackadaisical many companies are about deploying Windows 7 even after they make the decision -- I've never seen that in my 30-plus years in IT. For example, one client gave IT three weeks to put together a corporate deployment plan and one week to deploy 200 Windows 7 PCs -- including users' XP data and settings. IT had 8,000 more desktops to migrate in three weeks after that initial run. Another client gave its IT organization five days to come up with the deployment plan -- for 20,000 PCs!
[ Get all the details you need on deploying and using Windows 7 in the InfoWorld editors' 21-page Windows 7 Deep Dive PDF special report. | Stay abreast of key Microsoft technologies in our Technology: Microsoft newsletter. ]
The cold, hard truth is that there is a lot you have to do to deploy Windows 7 in a business environment. You need to determine which existing PCs can run Windows 7 at an acceptable level of performance and which need to be replaced. You need to have application experts test your key software as it is used day in, day out. You need to consider whether you want to deploy Windows 7 locally as a fat client, over the network as a thin client, or mix the two approaches -- and figure out whether your network can handle remote deployment and access.
Then there's the decision you probably didn't think you had to make: which deployment tool to use. Microsoft offers several.
Based on my experience with dozens of clients, here are the key steps to take to ensure a successful migration to Windows 7. And before I get into all the hows and whys, one tip for those readers wit enterprise licenses: Deploy the Windows 7 Enterprise Edition! I'm amazed at how many enterprise clients don't know they have access to the Enterprise Edition -- you need only to ask for it.
Step 1: Assess your hardware's ability to run Windows 7Start with the Microsoft Assessment and Planning (MAP) Toolkit 7.0 to assess your current equipment and create an inventory that covers the hardware (including drivers), software, and operating system information -- there are no client agents to install!
In MAP, the first action is to inventory your environment by clicking the Go button next to the Perform an Inventory step. In the wizard that runs, select the Windows Computers inventory scenario, then click Next and choose the method you'd like to use to discover your clients, such as from Active Directory Domain Services (AD DS) or an IP address range; you can also manually enter computer names or import them from a file.
The Microsoft Assessment and Planning (MAP) Toolkit
With the inventory in place, you can assess your Windows 7 readiness. (Windows 8 readiness, Office 2010 readiness, and Internet Explorer Discovery are other reports you may want to run at other times.) Click the Inventory and Assessment option in MAP's Action pane, then open the Assessment Properties dialog box. In that dialog box, set your readiness criteria, such as CPU speed and RAM amount, or use Microsoft's default options. Click the Run Assessment button to get the results of which PCs meet your Windows 7 readiness criteria. The reports are shown on screen and saved in your Documents/MAP folder as an Excel spreadsheet.
The MAP readiness report
Microsoft has detailed instructions on using MAP.
Step 2: Assess your applications' compatibility with Windows 7Microsoft also has a free tool to help you validate your applications' compatibility with Windows 7. Application Compatibility Toolkit (ACT) tracks applications you have tested and their level of compatibility. It can provide compatibility information for applications, devices, Windows updates, User Account Control (UAC)-related issues, and Web applications with new versions of Internet Explorer.
You need a SQL server to run ACT, as it uses SQL databases for its compatibility data. After you create the ACT database, you next install client agents to gather the application inventory information.
To do so, create a deployment package by double-clicking the Collect option. In the Details pane that appears, give the collection a name and select the type of compatibility you want to evaluate: OS or Windows Update. Click the Advanced button if you want to select UAC and Windows Compatibility. UAC detects applications trying to run as a standard user (not as an admin), whereas Windows Compatibility detects issues related to Session 0, Gina, and components that have been deprecated but are still used in applications. Specify when you want the ACT client agent to begin monitoring the client, how long it should monitor, how often the data should be uploaded to the SQL database, and where to output collected data.
The Microsoft Application Compatibility Manager
To actually deploy the collection package, you can use group policy objects, Microsoft Deployment Toolkit 2012 (MDT) or System Center Configuration Manager (2007 or 2012), or you can simply email the package to your users -- it's a small .msi file. On the client PCs, users should double-click the .msi file to run it.
The ACT database will list all applications found. It's up to you to do the testing to ensure they work appropriately in Windows 7 (as compatibility is about more than binary compatibility), and the ACT database has various fields for you to use to track your progress. Normally, evaluating applications takes a few months, so be sure to set aside enough time to do a thorough job.
3. Determine what type of OS images to deployA tough question for many organizations is whether they should deploy just the operating system (a thin image) and install the applications afterward, deploy the OS and all apps (a thick image), or deploy the OS and just the core apps required by all users (a hybrid image), with other apps installed separately later based on user needs and roles.
My preference is for the hybrid image; it is the fastest way to deploy the core capabilities to everyone and has the least labor impact on both IT and users. A thick image might be tempting, but if any application in the mix is updated, you have to remake the image each time, creating a management burden. A thin image may seem tempting as well, but it nearly doubles the IT deployment workload (two runs for every user) and creates a productivity gap where the user has Windows 7 but no applications to use with it.
4. Pick the image-deployment toolWhatever type of installation image you choose, there are several tools available to create, manage, and deploy the Windows 7 image. Microsoft has several of its own: Windows Automated Installation Kit (WAIK), Windows Deployment Service (WDS), Microsoft Deployment Toolkit 2012 (MDT), and System Center Configuration Manager (SCCM ) 2007 or 2012. WDS and MDT are free; WDS is a role that ships with Windows Server, and MDT is a free download.
Windows Automated Installation Kit. WAIK contains all the command-line tools needed to perform a complete Windows 7 installation to a new computer or to migrate from an XP PC. It gathers user state (user data, user settings, and application settings) and lets you create, manage, and deploy images. MDT, SCCM , and other tools use WAIK, so you can opt for friendlier interfaces and wizards rather than learn all the syntax for the various command-line utilities like copype, oscdimg, ImageX, DISM, Scanstate, and Loadstate. (Note that Microsoft is replacing WAIK with the Windows Assessment and Deployment Kit for deploying Windows 8.)
Windows Deployment Service. To use WDS, you need hefty infrastructure requirements (Active Directory, DNS, and DHCP), and you're limited to thick images -- WDS can't deploy applications separately later. If you do go with WDS, I recommend you use Windows Server 2008 R2 because it supports multiple streams of multicast traffic. To use WDS for Windows 7 deployments, first configure your WDS server. Then add the main components of the deployment package.
The first component is your boot image. Add the boot.wim from a Windows 7 or Windows Server 2008 R2 DVD's \sources folder (or its .iso file equivalent) to the Boot Images node in the WDS snap-in. (Caution: Do not add into WDS a WinPE file for booting the client PC, as you'll get a Command Prompt window at the X: drive and never get a list of OS images to deploy. You'll use a separate WinPE at the client computer instead.)
The Windows Deployment Service (WDS)
In the Install Images node in WDS, add the OS images you have created. Or to install a thin image, just use the install.wim file from a Windows 7 DVD's \sources folder. Remember, you can't install applications via WDS, so don't add any application images.
After your newly deployed machine is ready, sysprep the client PC using the -generalize and -oobe switches. (I like to run the GUI version from C:\Windows\System32\Sysprep\Sysprep.exe. Check the Generalize option in the System Preparation Tool dialog box that appears and choose Shutdown as the Shutdown Options pop-up menu rather than the default Reboot.
Next, boot the client PC using a WinPE that has the ImageX utility. Run ImageX capture with the /flags switch to capture an image of the PC:
You can store the image locally (the faster option) or put it on a network server. When the image is created, you can import your new custom .wim file into WDS as an OS image. I strongly recommend that you put it in an ImageGroup, so you don't end up with huge WDS file sizes. (ImageGroups help WDS store only the bits needed by saving only the differences in each subsequent .wim, much like how a differential backup works.)
Before you deploy Windows 7, you also need to add your drivers to WDS. You can set up groups of drivers for various manufacturers or types of BIOS, among other filters. When you're ready, do a PXE network boot of your client; the client should get an IP address from a DHCP server. If there is only one WinPE on the WDS server, that WinPE will boot; if you have multiple WinPEs, you'll see a list to choose from. Select your OS image and answer a few deployment questions. After about 30 minutes (the actual time depends on your network), you will have set up a Windows 7 PC. Repeat the client part of the installation for each PC.
Microsoft Deployment Toolkit. This tool runs on WAIK, providing friendly wizards that ask a few questions to do all the setup needed to deploy the complete Windows 7 OS, your applications, packages (such as security patches and language packs), and drivers.
To deploy an OS image from MDT you add the OS, applications, and drivers to MDT's Deployment Workbench. Then create a task sequence. You can add all kinds of tasks to your task sequence -- even PowerShell 2.0 scripts -- by opening the properties of your newly created task sequence and clicking the Add button.
Over time, you will have multiple OS images to deploy via MDT. You determine the OS, apps, and drivers based on the task sequence.
System Center Configuration Manager. SCCM is the only Microsoft tool that lets you remotely and automatically install an OS. What you need to set up are the distribution points that contain the OS images, including applications, and drivers. Because of the amount of data sent through the network to each PC, you'll want a lot of bandwidth available and fairly short hops between the client PCs and the distribution points assigned to them.
The System Center Configuration Manager
In SCCM, you create installation task sequences by selecting the Task Sequences node in the Computer Management/Operating System Deployment node and choose Create Microsoft Deployment Toolkit Task Sequence from the Actions menu. Instruct the wizard to create a new boot-image package, MDT files package, SCCM Configuration Manager (ConfigMgr) client package, User State Migration Tool package, and Settings package. Send all the packages to the distribution points and advertise them to a collection.
I recommend you enable "unknown" computer support in ConfigMgr, as that allows any client PC connect to the ConfigMgr server, so you can select a task sequence for it to use to deploy your OS image -- that'll make it easier to get Windows 7 on all your PCs. Configuring ConfigMgr for PXE boot also makes your life a lot easier, as it allows for more remote execution.
SCCM task sequences are complex, but the payoff in automated deployment and the ability to customize the degree of automation is worth the effort. If you prefer to design your own deployment wizard, SCCM's User Driver Interface (UDI) feature lets you do just that.
This story, "The latecomer's guide to deploying Windows 7," was originally published at InfoWorld.com. Follow the latest developments in Microsoft Windows at InfoWorld.com. For the latest developments in business technology news, follow InfoWorld.com on Twitter.
Read more about microsoft windows in InfoWorld's Microsoft Windows Channel.
Join the Computerworld Australia group on Linkedin. The group is open to IT Directors, IT Managers, Infrastructure Managers, Network Managers, Security Managers, Communications Managers.
Telstra hits 300 Mbps in LTE-A trial
Telstra hits 300 Mbps in LTE-A trial
With look ahead to manned mission, China launches lunar rover
Store closure marks the end of an era in Tokyo's Akihabara (+15 photos)
Planned new USB connector will fit both ways