If you're planning to deploy Windows XP to a number of systems, you're probably considering automating the installation process. And if you're not, you should be. Automating a deployment may take a bit of development time up front, but it saves time in the long run when compared to manually installing a large number of systems. Automation ensures consistency by removing most of the opportunities for human error. So who should use automated deployment? Well, if you're a home user , and you're only planning on installing Windows XP Home Edition on that old machine your kid uses to surf the Web, you probably just want to run with the standard out-of-the-box install process. But if you happen to have 50 such kids , if you need to frequently install the same base configuration on a system or two for testing purposes, if you configure Windows XP systems for resale, or if you're developing a deployment scenario for an organization's IT department, you'll definitely want to consider automating. A number of options are available when automating the installation of Windows XP, which are listed as follows and illustrated in Figure 2.23:
Figure 2.23. Four scenarios for automatic deployment of Windows XP.
Licensing IssuesWhether you choose to automate using the bootable Windows XP CD with an answer file, using a disk image, or using a scripted install over the network, the first thing you'll want to do is make sure you're properly licensed. If I had a dollar for every time I'd created an image using the wrong media for my licensing, I'd have exactly one dollar...because after the first time I screwed it up, I've always remembered to double-check my media before starting development on a new automated install. Note Microsoft revises its licensing policies almost as often as it releases service packs . For the latest twists and turns, check out http://www.microsoft.com/licensing. Under Microsoft's current licensing model, retail Windows XP media cannot be used for multiple installations. Using a scripted install with a separate retail CD for each system is still an option, as long as you aren't trying to fully automate the install. To script installs from retail media, though, you'd need one retail CD with a retail product key for each system, and you'd still need to prompt for the unique retail product key on each machine. Additionally, you'd need to run through the product activation wizard on each system. This method wouldn't be practical for most organizations, but if you're only worried about a handful of systemsin a very small office or in your home, perhapsit is a valid option. Using an answer file to simplify individual installations is exactly like using an answer file for large-scale installations, except you won't need to spend nearly as much time on development and testing. I prefer the scripted install using the bootable Windows XP installation CD when developing a setup process for a small-scale environment.
If you're planning to install Windows XP on five or more systems, you're eligible for one of Microsoft's Volume Licensing programs. There are four basic programs available for Windows XP volume licensing, listed in Table 2.8. Machines loaded with Windows XP using media acquired through one of these programs and using a valid volume license product key are not required to run the product activation wizard. Table 2.8. Windows XP Volume Licensing
If you've ever used the Select or MSDN media to install a previous version of a Microsoft operating system, you might have noticed that the product key was preconfigured on the CD. With XP, this feature is no longer there. Additionally, the Worldwide Fulfillment media no longer includes a product key on the CD packaging. For these media, you must use the unique Volume License Product Key assigned to your organization. Adding and Using the Deployment ToolsAs with Windows 2000, the deployment tools are in the DEPLOY.CAB file under the \SUPPORT\TOOLS directory of the installation CD. Extract these files to a directory of your choice. For the sake of future reference, we'll assume the files have been extracted to C:\DEPLOYTOOLS Note While in this directory, it wouldn't hurt to install the Support Tools by running SETUP.EXE . Select Complete Installation for the full toolset. The Support Tools are unsupported utilities included to provide support personnel and experienced users with handy tools for diagnosing and resolving computer problems. About 70 executables and half a dozen script files are documented in the supporting files included with the install. Not all the included support tools are listed in the Support Tools Help (this Help file shows under the Support Tools program group after installing the tools). For a full list, be sure to read \SUPPORT\TOOLS\README.HTM . Let's look at some of the key files you have under C:\DEPLOYTOOLS :
Using Interactive Answer Files for InstallationThe answer file is the cornerstone of any automated installation routine. If you used answer files under Windows 2000, the concept and purpose haven't changed: The answer file provides the answers for both the text mode setup and GUI mode setup portions of the install, relieving end users or technicians from manually completing this repetitive task. Naturally, this speeds up the install process, increases the accuracy over manual data entry, and serves as a form of documentation. The basic structure of the file is the same for a CD-based unattended install, an over-the-network scripted install, an RIS-based install, or an OS image using SYSPREP. Note The procedure in the next section can vary if you have a Windows CD slipstreamed with Service Pack 2. Creating an Answer FileCreating an answer file can be as easy as running a wizard or as complex as manually creating the entire file in Notepad. Personally, I prefer the wizard to create the initial file and Notepad for post-wizard tweaking. To start the Windows Setup Manager Wizard, go to the C:\DEPLOYTOOLS directory and run SETUPMGR.EXE . Note You do not have to run the Setup Manager Wizard under Windows XP. It will run on Windows 2000, allowing you to create distribution share points and answer files for Windows XP without having XP installed. Let's walk through using the wizard to create a complete answer file for a fully automated CD-based installation of Windows XP Professional. If you're following along in the wizard, this should take about 30 minutes to complete. I'm not going to take up space with screen shots, but I will identify and explain all the screens you should expect to see:
You should now have a complete answer file named Winnt.sif . If you open the file in a text editor, it should look a little like the following: Note If you copy the following example file for your own use, I strongly recommend changing the product key I've used to a valid product key for the media you are planning to use. The listing shows a Microsoft-provided generic product key that's suitable for testing purposes only. Refer to http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/default.mspx for a full list of generic Windows XP product keys. These keys are blocked from activation at the Microsoft clearinghouse. If you use one of the generic keys, you will have approximately 14 days to experiment with and test your system before Windows will require activation. ;SetupMgrTag [Data] AutoPartition=1 MsDosInitiated="0" UnattendedInstall="Yes" [Unattended] UnattendMode=FullUnattended OemSkipEula=Yes OemPreinstall=No TargetPath=\WINDOWS [GuiUnattended] AdminPassword=eadb1736119939abdd99a9b993edc9a87a44c42236119ae1893bd142a2bbaead EncryptedAdminPassword=Yes OEMSkipRegional=1 TimeZone=20 OemSkipWelcome=1 [UserData] ProductID=DR8GV-C8V6J-BYXHG-7PYJR-DB66Y FullName="Jeff Ferris" OrgName="Ferris Technology Networks" ComputerName=* [TapiLocation] CountryCode=1 Dialing=Tone AreaCode=512 [GuiRunOnce] Command0="rundll32 printui.dll,PrintUIEntry /in /n \printserver01\laser" [Identification] JoinDomain=FERRISTECH DomainAdmin=ComputerAddAccount DomainAdminPassword=ferristechCA [Networking] InstallDefaultComponents=Yes Customizing the Answer FileTo modify an existing answer file, you have two options: First, you can take the easy way out by rerunning the Setup Manager Wizard. After starting the wizard, select Modify an Existing Answer File on the second wizard screen. The rest of the process is the same as in the walk-through under the "Creating an Answer File" section in this chapter. Answers already provided by the existing answer file will show up in the proper locations as you go through the wizard. Change what needs changing, resave the file, and you're good to go. You'd probably want to use the wizard when making major changes to your answer file, such as when changing from a domain to a workgroup model. Your second option is to modify the answer file using a text editor. Most of the answer file options are fairly self-explanatory, and the REF.CHM file from the DEPLOY.CAB contains full documentation for all sections, keys, and options in case you need additional guidance. I'd document everything for you here, but it would translate to about 150 pages of text that wouldn't be indexed and couldn't be searched (unlike the Help file), and you'd probably fall asleep reading through it all anyway. You'd probably prefer using a text editor to modify an answer file when changing things like the username ( FullName=<answer> ), the organization name ( OrgName=<answer> ), or the username and password used to join a computer account to the domain ( DomainAdmin=<answer> and DomainAdminPassword=<answer> ). If you are going to use the answer file installation method with standard retail Windows XP licenses, you will need to either edit the product ID in the answer file each time you use it, or you must delete the product ID line from the answer file so that the setup program will prompt for a unique product ID for each installation. Changing the Answers in a SYSPREP.INF File After you've created a SYSPREP.INF file, saved it in the SYSPREP directory, executed Sysprep, and created your image, the SYSPREP.INF file becomes a permanent part of that image. So, if you need to make changes to something in the answer file, you must create a new image, update the SYSPREP.INF file, and rerun Sysprep. Suppose you only need to change the answer file for a couple of systems. You wouldn't want to go through the whole reimaging process just to change some of the options in the answer file. Fortunately, there's a rarely documented out. Simply make the changes to your SYSPREP.INF file, and save SYSPREP.INF to the root of a floppy disk. Apply your image to a target system and boot the target system. As soon as the system starts to boot, insert the floppy disk containing the updated SYSPREP.INF in the A: drive. The Windows XP Setup Wizard will use the answer file on the floppy disk to override the settings specified in the Sysprep file stored with the image. Putting an Answer File to UseFour main types of installations can be performed using an answer file. The name of your answer file will be different depending on the type of install you intend to use it for. Table 2.10 lists the four standard filenames for answer files, as well as their purpose and location. Table 2.10. Types of Answer Files
Local and Network-Based Unattended InstallationWith the answer file created in the "Creating an Answer File" section earlier in this chapter, you might have noticed that the Setup Manager Wizard created a batch file in the same directory as your answer file. This batch file can kick off a Windows XP install from a machine that is already running Windows 95, Windows 98, Windows Me, Windows NT, Windows 2000, or Windows XP. The install will take advantage of the answer file as long as you leave both the batch file and the answer file in the same directory. By default, answer files created to install from the Windows XP CD expect to find your Windows XP CD in the D: drive. If your CD-ROM uses a different drive letter, you must edit the batch file using Notepad to reflect the correct drive letter. You may remember a point in the walk-through under "Creating an Answer File" (step 6) where the Setup Manager Wizard asked whether to create an answer file to install from CD, or to create or modify a distribution folder. You selected the option to install from CD. Had you selected the distribution folder option, the batch file would point to the UNC to which the install files were copied . Additionally, from within Windows 95/98/Me/NT/2000/XP, you could manually run the installation using the answer file with the WINNT32.EXE command and the optional /unattend switch, using the following syntax: <path_to_install_files>\winnt32 /unattend: filename If you want to complete an over-the-network installation from a system without an operating system, you need to create a DOS-bootable disk capable of connecting to the network and map a drive to the location of the shared Windows XP install files. Instead of running WINNT32.EXE as when running a local or network install from Windows 95/98/Me/NT/2000/XP, use the WINNT.EXE command. To use the answer file, the full command will be Winnt /s: install_source_directory /u: answerfile_name Unattended Install from the Bootable Windows XP CDCaution The following paragraph starts a fresh unattended install of Windows XP Professional. This will wipe your drive clean. And after you've started, you can't go back. Do not attempt to run the bootable CD setup process unless you are willing to clear the primary drive on the target machine. In the walk-through in the "Creating an Answer File" section of this chapter, the answer file was named WINNT.SIF , allowing it to be used to run a fully automated installation simply by booting from the Windows XP Professional install CD. To make this work, you don't need to worry about the batch file. Just copy WINNT.SIF to the root of a floppy disk. Go to your target system, insert the Windows XP Professional CD in the CD-ROM drive, and boot to the CD. As discussed in the "Licensing Issues" section earlier in this chapter, you must use volume license media and a volume license product key to use the same product key on multiple systems. If you're not using volume license media with a volume license product key, you must either update the Product ID line in the WINNT.SIF file before loading each different system or leave the Product ID line out of the WINNT.SIF so the system will prompt for the key during the mini-setup wizard. Note If setup isn't starting when you attempt to boot to the CD, check two things: First, ensure that your system boot order is configured with the CD-ROM as the first boot device under your system BIOS. Second, pay close attention while booting your system. If you have no operating system, Windows Setup will start on its own. If, however, an active partition with a bootable OS exists, at one point booting to the CD will prompt you with "Press any key to continue booting from CD." Press the Any key at this point. Look closely, the label for the Any keyusually the long key at the bottom centerfrequently falls off before a keyboard leaves the factory. As soon as your system starts to read the CD and recognizes it as bootable, insert the floppy disk containing the answer file into the A: drive. After a few minutes, setup will prompt you to partition and format the drive. This is a safety mechanism to give you one last chance to back out of the install before wiping out your system. After partitioning the disk, you should be able to sit back and relax for about 45 minutes while Windows XP Professional completes installation to your system without prompting you to answer any additional questions. Now, I know what some of you may be thinking: Hey! If this is automated why is setup asking for my input before it partitions and formats the disk? Although you selected Fully Automated in the Setup Manager Wizard, the partitioning and formatting of the disk does not complete without user interaction unless you know about this rarely documented trick: Open your WINNT.SIF file in Notepad, and add the following two lines under the (Unattended) section header: FileSystem = ConvertNTFS Repartition = Yes If you find that this isn't working for you and booting from the Windows XP CD still runs a normal setup, make sure you've named your answer file WINNT.SIF and saved it to the root of the A: drive. Windows Setup will not check for any other filename, and it will not check in any other location. In addition, double-check that you're getting the disk inserted as soon as the system starts to boot from the CD, or Windows Setup will not read the answer file. If you're having difficulty getting the disk inserted at the right time, you could go into your system BIOS and disable booting from floppy, or move the floppy drive to the end of your boot order. You should then be able to leave the floppy disk containing the WINNT.SIF file in your drive from the beginning of the boot process. Remote Installation ServicesIf you are familiar with using RIS under Windows 2000, not much has changed with the upgrade to Windows XP. RIS is an optional server-side service provided with Windows 2000 Server and Windows Server 2003 that enables you to deploy Windows XP to a new system by booting to the NIC using an NIC with a Preboot Execution Environment (PXE) boot ROM enabled. Other than booting client systems using a PXE boot ROM rather than a network boot disk, installing Windows XP using RIS is similar to installing over the network from a network share point. All files are copied over the network to the client station, and Windows XP runs a full install. From an infrastructure perspective, RIS requires a TCP/IP-based network that uses a DHCP server, a Windows 2000-compliant DNS service conforming with both RFC 2052 and RFC 2136, and Active Directory to provide client authorization and configuration information to the RIS server during the client install process. If you are still using Windows NT 4.0 Server DNS, it does not support the required protocols. If using Unix BIND, versions 8.1.2 and later support the required protocols. To add a Windows XP Professional installation to your RIS server, follow the same procedure as adding a Windows 2000 Professional image, but using the source files and answer file for Windows XP. Remember, you can create the RISETUP.SIF answer file by using the Setup Manager Wizard and selecting the option to create an install for RIS on the third screen of the wizard. Note For full details on setting up and configuring RIS under Windows 2000, see the Remote Installation Services chapter excerpt from the New Riders title, Windows 2000 Deployment and Desktop Management , available online at http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/depopt/remoteos.mspx. Systems Management ServerIf so inclined, you can use Microsoft Systems Management Server (SMS) to deploy a Windows XP upgrade. The question is, should you? To be honest, I've tried it, and I don't like it. Part of the problem is that you can only deploy Windows XP via SMS if doing an upgrade. You cannot use SMS to deploy a clean installation of Windows XP. So rather than telling you how to use SMS to deploy a Windows XP upgrade, I'm going to tell you why you probably shouldn't . Note If, after reading the rest of this section, you still want to attempt an upgrade to Windows XP using Microsoft SMS, refer to the Microsoft-provided documentation at http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/default.mspx. When planning for a mass-scale operating system upgrade, I usually opt to develop a single clean install process to use for all systems in an environment, rather than developing one install process for people who need a clean install and an additional upgrade process for systems that can handle the upgrade. Upgrading an operating system tends to result in a number of difficult-to-diagnose technical inconsistencies; a clean install does away with any questions. I'm sure if you've been working with any Microsoft operating system for very long, you've eventually reinstalled just to improve system performance, get rid of unneeded files, and start with a clean slate. Major operating system upgrades provide an excellent opportunity for a wide-scale cleanup of all systems in an organization. Using the User State Migration ToolUnless you're lucky enough to be running in a fully managed environment with roaming user profiles and all unique user data stored on the network, you need to find a way to migrate the settings and documents from the old systems to the new. The User State Migration tool (USMT) helps with this endeavor. If the Files and Settings Transfer Wizard is like a shiny new Porsche 911 sitting in your driveway , the User State Migration Wizard (USMT) would be a HUMMV. The Files and Settings Transfer Wizard is sleek, easy to get along with, and can be used by end users. The User State Migration Tool is powerful, complex, and intended for administrators and advanced support personnel. The same thing that makes the User State Migration Tool so powerful is what makes it so complicated to most people: its arcane command-line interface that relies on .INF files to control the migration process. The User State Migration Tool can be found on the Windows XP Setup CD-ROM in the \VALUEACC\MSFT\USMT folder. In addition to various .DLL files, there are two executable files in this folder: SCANSTATE.EXE and LOADSTATE.EXE as well as four predefined .INF files that you can use to perform a default migration. That said, the whole point of the USMT is to have granular control over what gets migrated and how the migration is applied to the target computer, so you may well want to modify the files to suit your needs. Table 2.11 explains the primary files and their purposes in more detail. Table 2.11. The Core USMT Files Explained
USMT and Upgrade Installations The User State Migration Tool does not support the application of collected settings to computers that have been upgraded from a previous operating system. Install Windows XP in a clean installation before attempting to use the USMT. Out of the box, USMT migrates the following files and settings:
As mentioned previously, the User State Migration Tool's .INF files are highly customizable. By modifying the .INF files in the USMT directory, you can change the files and settings that USMT will migrate in order to fit your specific needs. Customizing the .INF Files For information on customizing the .INF files that control the migration process in the USMT, see "User State Migration in Windows XP: Modifying the Migration Rule INF File," located at http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/usermigr.asp. For complete online documentation for the USMT on Microsoft's website, go to http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/default.mspx. As mentioned previously, the User State Migration Tool consists of two executable files, four migration .INF files, and several supporting .DLL files. The migration process takes place in just four major steps, just the same as when using the Files and Settings Transfer Wizard. Additionally, the information provided for the Files and Settings Transfer Wizard in the "Before Starting the Transfer" section as detailed in the next chapter apply to using the USMT as well. Let's run through a quick data and settings migration using the default .INF files. To accomplish this task, you need a "used" system with a configured user profile directory, a server (or a workstation on which you can create a data share), and a clean system to which to copy the user state.
Using USMT for a Single System Transfer You don't have to use USMT in a client/server environment. If you just want to migrate data between a handful of systems, use the following steps instead:
Using the default settings, that's really all there is to it. Of course, there are any number of switches you can use with the executable files to further modify how USMT works. The ScanState file has the following syntax, which is explained in Table 2.12. scanstate [/c /i input.inf]* [/l scanstate.log] [/v verbosity_level] [/f] [/u] [/x] migration_path Table 2.12. ScanState Switches
The LoadState file has the following syntax, which is explained in Table 2.13. loadstate [/i input.inf]* [/l loadstate.log] [/v #] [/f] [/u] [/x] migration_path Table 2.13. LoadState Switches
Change and Configuration Management See the "Change and Configuration Management Deployment Guide" at http://www.microsoft.com/windows2000/techinfo/reskit/deploy/CCM/ for more information on migration user's settings. The next chapter discusses performing an installation of Windows XP as an upgrade to a system with a previous version of Windows already installed. It may be tempting to skip over this chapter should you not intend to perform an upgrade installation; however, this chapter also includes crucial information on how to migrate key user data and applications from an existing installation to a new one as well as information on installing Windows XP Service Pack 2. |