Automated Deployments


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:

  • Scripted install from CD or Distribution Share This is the most basic type of automated install. Setup runs using the usual winnt.exe or winnt32.exe installer, and a preconfigured answer file is passed in from a command-line switch. The answer file supplies the information that would normally have to be entered manually.

  • Scripted install using boot CD In this process, the system boots from the install CD, and Windows XP Setup reads an answer file from the A: drive.

  • System image prepared with Sysprep With this scheme, you install and configure one system to your exact specifications, use a disk image (an exact duplicate of a system drive) to deploy identical copies to a large number of systems.

  • Remote Installation Services (RIS) This more sophisticated method for deploying Windows XP over the network involves booting from a network interface card (NIC), ROM, or ROM emulator disk.

Figure 2.23. Four scenarios for automatic deployment of Windows XP.


Licensing Issues

Whether 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.

For more details on product activation, refer back to "Product Activation," p. 60.



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

Program

Description

Open License

For academic institutions, charities, corporations, or government organizations needing licenses for five or more systems.

Select License

For academic institutions, charities, corporations, or government organizations with decentralized purchasing needing licenses for 250 or more systems.

Enterprise Agreement

Software purchasing agreement for corporate customers with centralized purchasing, needing licenses for 250 systems or more. In this type of agreement, the company pays for the licenses needed, after which it can use those licenses as long as it wants.

Enterprise Subscription Agreement

Software leasing agreement for corporate customers with centralized purchasing, needing licenses for 250 systems or more. In the leasing agreement, companies pay less for the OS licenses up front, but they pay additional fees to renew their subscriptions yearly to continue using the operating system. This type of agreement usually includes future OS upgrades as part of the deal.


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 Tools

As 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 :

  • DEPLOY.CHM Windows Help file for the Microsoft Windows XP Corporate Deployment Tools User's Guide. This Help file contains a great deal of useful information. To view it, double-click its icon, or type start deploy.chm at the command prompt.

  • SYSPREP.EXE Executable used to prepare a system for disk imaging.

  • SETUPCL.EXE When preparing a system for disk imaging, this executable must be included in the SYSPREP folder with the SYSPREP.EXE and SYSPREP.INF files.

  • SETUPMGR.EXE This is the Windows Setup Manager Wizard. It will run through a series of questions, resulting in a properly formatted answer file suitable for framing.

  • REF.CHM This Windows Help file provides full documentation for all sections used in answer files. In addition, you can find a couple of sample answer files under both the Unattend.txt and the Sysprep.inf sections. Many of the sections listed in this Help file are not exposed by the Windows Setup Manager Wizard.

Using Interactive Answer Files for Installation

The 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 File

Creating 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:

1.
The first screen is the welcome screen for the wizard. Click Next.

2.
The second screen, New or Existing Answer File, lets you select between creating a new file or modifying an existing file. Select Create a New Answer File and click Next.

Note

The Help button becomes active after you reach the second screen of the Setup Manager Wizard. The Help files in the Windows XP Setup Manager are very well developed and provide excellent on-the-spot information if you find yourself questioning the intricacies between multiple options. Be aware that there are different versions of the wizard that may display variations in the options explained here. If you are using a CD that is slipstreamed with SP2, there will be no help button and some of the options will vary.

3.
Next is the Product to Install screen. On this screen, select whether to create a file to use with a Windows Unattended Installation, a Sysprep Install, or an install using Remote Installation Services. For our purposes, select Windows Unattended Installation and click Next.

4.
The fourth screen, Platform, is where you select between Windows XP Home Edition, Windows XP Professional, and Windows 2002 Server versions. Note that the wizard was released before the server family officially changed names to Windows .NET Server (unless you have a CD with SP2). Select Windows XP Professional and click Next.

5.
On the screen titled User Interaction Level, decide how automated the automated install process should be. Table 2.9 details the different options for this screen. After reviewing the table, select Fully Automated and click Next. If using retail media, you actually need to select Hide Pages or Read Only for the user interaction level, which I'll explain further in Step 11.

Table 2.9. Automated Install Interaction Levels

Interaction Level

Description

Provide defaults

Questions posed by Windows Setup are filled in with defaults provided by the answer file, but the user is able to review or change any answers you have supplied.

Fully automated

If you select this option, you must supply all required answers in the answer file. Windows Setup will not prompt the user for any answers, and setup will complete with no action required from the user. If you select this option, the wizard will require you to answer all necessary questions.

Hide pages

Any page for which all answers are provided by the answer file will not be displayed. If an answer is missing, the page will be displayed and the user will be prompted to fill in the blanks.

Read only

If you provided answers for questions posed by Windows Setup, the page will still be displayed, but the end user cannot change the answers you have provided. The user will be prompted for any answers left out of the answer file.

GUI attended

The text mode portion of install is automated, but the user must manually complete the graphical portion of Windows Setup.


6.
On the sixth screen, select whether to create a distribution folder or run the installation from a CD. If you select the option to create a distribution folder, the Setup Manager Wizard will prompt you to insert a Windows XP CD from which it can copy the required files. For now, select No, This Answer File Will Be Used to Install from a CD.

7.
On the License Agreement screen, check the box to accept the EULA. Click Next.

8.
The remainder of the screens will prompt for answers to the questions normally presented by the graphical portion of setup. The first of these asks for a name and organization. Enter your name and organization, and click Next.

Note

If you plan to use the option for automatic computer naming (see step 12), you must enter an organization name at this screen.

9.
You should see the Display Settings panel. Here, configure the default colors, screen area, and refresh frequency. Sticking with the Windows default for all three options is the safe bet, but if you want different options and know your target hardware will support the exact configuration you select, feel free to adjust accordingly . When done, click Next.

10.
Select your time zone and click Next.

11.
The next screen is Providing the Product Key. If you're using retail media, you won't really get much use out of this screen; leave it blank and manually enter the product key at this point in each installation. In addition, you'll probably need to go back and select Hide Pages or Read Only for the user interaction level on step 5. If you have your volume license media and volume license product key (refer to the first section of this chapter), this is where you enter it. Enter a product key, and click Next.

12.
In the Computer Names screen, click the check mark next to Automatically Generate Computer Names Based on Organization Name at the bottom of the screen. This lets you use the same answer file for any number of systems without naming conflicts. Automatically generated computer names are composed of the first word of the organization name, followed by a hyphen and a randomly generated alphanumeric string.

13.
The next screen prompts you for the Administrator password. Unlike previous versions of Windows, you have the option of encrypting the password in the answer file. In Windows 2000 and earlier, the password was stored as clear text, which meant that anyone who found your answer file could compromise your local administrator passwords. Enter your password in both boxes, select the option to encrypt, and click Next.

Note

When using with a disk image, you must clear the Administrator account's password on the system used to make the master image. If you do not, setting the password in the answer file ( SYSPREP.INF , in this case) will have no effect, and the target systems will retain the same local administrator password as on the master system.

14.
In the Networking Components screen, select Typical Settings to configure your machine for standard settings (TCP/IP using DHCP for addressing, File and Print sharing for Microsoft Networks, and the Client for Microsoft Networks). Click Next.

Note

If you are in a small office or home office environment, rather than setting up a server just to use as a DHCP server, I recommend the Etherfast Cable/DSL Router from Linksys (www.linksys.com). It offers one-port, four-port, and eight-port versions, all of which can uplink into a hub. Not only do these devices provide full DHCP services for up to 253 clients , but also they act as both an Internet gateway to a broadband connection and as a hardware-based firewall to protect your internal network from outside influences.

15.
On the Workgroup or Domain screen, select the option for Windows Server Domain. During mass-production installations, you probably won't want to manually set up domain computer accounts in advance, so enter your domain name in the requisite blank, and select the option to create a computer account in the domain during installation. Enter a username and password with rights to add a computer to the domain. If you do not have an accessible domain to use for this, are setting up standalone workstations, or use workgroups instead of domains in your organization, you can select the option for Workgroup and provide a workgroup name.

Note

Strangely enough, even though you can use encryption for the local administrator account password, it is not an option for this area. That means the account information you enter here will be stored in the answer file in clear text. For this reason, it is recommended that you do not use a domain administrator's account to join computers to the domain. You might want to create a special domain account that does not have permission to log on as an interactive user but does have permission to create computer accounts in the domain, and enter the account information in these spaces.

16.
On the Telephone screen, fill in your country, area code, and the number to access an outside line. Select whether your phone system uses pulse or touch-tone, and enter any number sequence required to access an outside line. When you've filled out all the boxes, click Next.

17.
On the Regional Settings screen, select Use the Default Regional Settings for the Windows Version You Are Installing. Click Next.

18.
The Languages screen provides an opportunity to install additional default language groups. For now, stick with the defaults and click Next.

19.
On the Browser and Shell Settings screen select Use Default Internet Explorer Settings and click Next.

20.
On the Installation Folder screen, specify where to install Windows XP. By default, Windows XP uses Windows as the folder name. If you want Windows to install to the same location as Windows NT 4.0 or Windows 2000, select the option labeled This Folder and enter Winnt . For now, let's stick with the default, a folder named Windows, and click Next.

21.
If you want, you can automatically install network printers after the first user logon. You'll configure the default printers at this screen, the Install Printers screen. To use this feature, enter a network printer UNC in the form \\ servername \printername , and click Next. If you don't have any network printers, leave this blank. It is not required for a successful fully automated setup.

22.
The next screen, Run Once, lists commands to run after the user logs in for the first time. Any printers you added on the previous screen will show up here as AddPrinter \\server\share . Do not change anything on this screen; click Next. Any additional commands can be manually added to the script later.

23.
After installation, the final screen in this section, Additional Commands, allows you to run commands that do not require a user to be logged on. Commands entered here will execute before the Windows Logon screen shows up the first time. For the purposes of this walk-through , do not add anything at this screen; click Finish.

24.
Windows Setup Manager prompts you for the location and filename under which to save your answer file. Save your file somewhere you can find it, with the filename Winnt.sif .

25.
In the final window, Setup Manager Complete, if the Next button is not available, click the X in the upper right to close the dialog.

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 File

To 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 Use

Four 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

Filename

Purpose

RISETUP.SIF

Automate the setup wizard for RIS-based installs. You'll put this file in the \I386\Templates subdirectory of the folder created for any RIS image.

SYSPREP.INF

Provides answers for the SYSPREP Mini-Setup Wizard. SYSPREP.INF should be placed in the C:\SYSPREP directory before running SYSPREP.EXE to prepare a drive for imaging.

UNATTEND.TXT

Provides responses for the installation process when running an install using WINNT or WINNT32 from a network share or from a command-lineinitiated installation from the CD. This file can actually have any name and can be saved in any location that you will be able to access while running the install.

WINNT.SIF

Provides answers for the setup wizard when installing by booting to the Windows XP CD. Save this file to the root of a floppy, and insert the disk right after the installation starts from the bootable Windows XP CD.


Local and Network-Based Unattended Installation

With 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 CD

Caution

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 Services

If 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 Server

If 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 Tool

Unless 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

File

Description

ScanState.exe

Collects user data and settings based on the information contained in Migapp.inf, Migsys.inf, Miguser.inf , and Sysfiles.inf .

LoadState.exe

Applies the collected user state data on a computer that has a clean installation of Windows XP Professional.

Migapp.inf

Used to collect application settings; can be modified to customize a migration.

Migsys.inf

Used to collect system settings, such as fonts, accessibility settings, and Internet Explorer settings, among others; can be modified to customize a migration.

Miguser.inf

Used to collect personal settings and files from the My Pictures, My Documents, and other user-specific folders; can be modified to customize a migration.

Sysfiles.inf

Used to specify files specific to each version of Windows that USMT can migrate settings from; not normally modified unless the version of Windows that you are migrating settings from is not supported.


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:

  • Accessibility

  • Classic desktop

  • Cookies folder

  • Dial-up connections

  • Folder options

  • Fonts

  • Internet Explorer settings

  • Mouse and keyboard settings

  • My Documents folder

  • My Pictures folder

  • Network drives and printers

  • Office settings

  • Outlook Express settings and store

  • Outlook settings and store

  • Phone and modem options

  • Regional options

  • Screen saver selection

  • Sounds settings

  • Taskbar 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.

1.
On the server, create a shared directory called USMT, and copy the entire USMT directory from the \VALUEADD\MSFT\ directory of the Windows XP Installation CD into this directory. Create a subdirectory named DATA.

2.
Log on to the "used" system and map the U: drive to the USMT share on your server.

3.
Open the command prompt. Switch to the U:\USMT directory, and type the command SCANSTATE U:\DATA .

4.
You will see the line ScanState is running... . Wait. When ScanState finishes, you will see the line The tool completed successfully .

5.
Move to the clean system and map the U: drive to the USMT share on your server.

6.
Open the command prompt. Switch to the U:\USMT directory, and type the command LOADSTATE U:\DATA .

7.
You will see the line LoadState is running... . Wait. When LoadState finishes, you'll be back at the command prompt, and you should have the same data and settings as on the system from which SaveState was run.

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:

1.
On the source computer, logged on as the user in question, run the ScanState file to copy the settings to an intermediate storage location. This can be done via script, shortcut, or manually.

2.
Prepare the target computer with a clean installation of Windows XP Professional. There are no restrictions on performing Remote Installations or other automated deployment methods .

3.
On the target computer, logged on as the local administrator, run the LoadState file to apply the user's settings. This, again, can be done using a script, a shortcut or a scheduled task using the local administrator's credentials.

4.
The user logs on to their account and the process is completed.


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

Switch

Description

/c

Instructs ScanState not to stop on filename_too_long errors. These errors will be logged in the Longfile.log log file for later analysis.

/f

A troubleshooting switch that specifies that files will be migrated; not normally used.

/i

Specifies the .INF file (or multiple .INF files) that is to be used with ScanState to define the settings that are to be collected for transfer.

/l

Specifies the file to log errors that may occur during the collection process.

/u

A troubleshooting switch that specifies that user settings will be migrated; not normally used.

/v

Enables verbose output. Use the format: /v # , substituting 1 (least verbose) to 7 (most verbose) for the # symbol.

/x

A troubleshooting switch that specifies that no files or settings will be migrated; not normally used.

migration_path

Specifies the path to the location where files should be written to. You must have the appropriate NTFS and share permissions to this location.


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

Switch

Description

/i

Specifies the .INF file (or multiple .INF files) that are to be used with LoadState to define the settings that are to be migrated.

/f

Specifies that files will be migrated. This is a switch for troubleshooting only.

/l

Specifies the file to log errors that may occur during the collection process.

/u

A troubleshooting switch that specifies that user settings will be migrated; not normally used.

/v

Enables verbose output. Use the format: /v # , substituting 1 (least verbose) to 7 (most verbose) for the # symbol.

/x

A troubleshooting switch that specifies that no files or settings will be migrated; not normally used.

migration_path

Specifies the path to the location where files should be read from. You must have the appropriate NTFS and share permissions to this location, as appropriate.


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.




Upgrading and Repairing Microsoft Windows
Upgrading and Repairing Microsoft Windows (2nd Edition)
ISBN: 0789736950
EAN: 2147483647
Year: 2005
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net