Section 2.6. Running an Unattended Installation

2.6. Running an Unattended Installation

Unless you have only two or three servers, it's likely that you tire fairly quickly of being a high-paid installation babysitter, shoving disks and CD-ROMs in and out of machines while telling them all what country you live in. For all but the smallest of Windows shops, it is a good idea to use the Windows unattended installation featurethat is, installations run by files constructed by an administrator ahead of time that answer all of Setup's questions. This will save you time and make deploying and rolling out the operating system less tedious.

You can automate Windows installations using one of three main methods. The first is through the use of unattended installation scripts, which are simple to configure and use but lack some flexibility in deploying to machines that are configured with different hardware. Scripts are best when you have a uniform hardware base.

The second method is through the use of Remote Installation Services (RIS), a very useful feature that enables you to boot from the network and install Windows without any sort of distribution media. With this method, you have a lot of upfront configuration, but on the other hand, you can deploy to nearly any base of hardware, and you can customize certain aspects of the user experience during the installation, too. RIS is most appropriate when you have a diverse hardware base, plenty of network bandwidth, and computers that can boot from the network.

The third and final method to use unattended installations is through the deployment of system images. It requires quite a bit of upfront installation, but it's a great timesaver when you need a computer redeployed and reformatted in less than 30 minutes.

Let's discuss each method.

2.6.1. Using Scripts

Perhaps the simplest method of automating a Windows Server 2003 deployment is to use scripts, or more specifically, unattended setup answer files. These files use a syntax not unlike that found in Windows 3.1 INI files, providing answers for questions such as computer name, your CD key, your name, where you live, and the like.

Windows is instructed to read these files using an argument switch on its main setup program executable file, winnt32.exe. Table 2-4 lists all the switches this program will accept.

Table 2-4. winnt3 command-line switches

Command-line switch	Function
/checkupgradeonly	Verifies that Setup can run and perform an upgrade on the current system.
/cmd:[command]	Launches the command specified before Setup completes, giving you an opportunity to customize an installation by running an additional program.
/cmdcons	Installs the Recovery Console and modifies the boot configuration so that it appears on the boot menu.
/copydir:[folder]	Copies a file or folder to the local system where it can be accessed during Setup; useful for copying files that reside on a network that are used to install drivers or the like in the OS.
/copysource:[folder]	Similar to the /copydir option, but will delete the specified folder after Setup completes.
/debug[level][:filename]	Logs error messages and/or activity to the specified file. The levels available arein increasing comprehensiveness0 for serious errors; 1 for common, nonfatal errors; 2 for warnings; 3 for any informational prompts or messages; and 4 for detailed activity reports on every aspect of the installation.
/dudisable	Disables Setup's Dynamic Update feature.
/duprepare:[folder]	Prepares a given directory for the installation of private dynamic updates by downloading said updates from a Microsoft site. You can find more information on this feature later in this chapter.
/dushare:[folder]	Instructs Setup to download Dynamic Update files from the folder specified in the argument syntax.
/m:[folder]	Specifies an alternate location for all installation files; useful for applying hotfixes or using alternate versions of files in multiple installations.
/makelocalsource	Copies all installation files locally to the $win_nt$.~ls directory to ensure availability during the installation process.
/noreboot	Performs all functions within Setup's text-based phase but does not automatically reboot the machine.
/s:[folder]	Enables you to specify multiple source paths from which Setup can download files; useful over slow links or on slow hardware.
/syspart:[drive]	Starts Setup, marks the drive active, and then prepares the installation so that you can physically transplant that drive between systems.
/tempdrive:[drive]	Specifies an alternate location for temporary, or "scratch," files.
/unattend	Specifies a hands-off upgrade installation using all configuration data from a previous installation.
/unattend:[file]	Specifies a hands-off installation, but using an answer file that allows direction of a clean installation without an existing reference installation.
/udf:[id][,file]	Instructs Setup to use a specific UDF file; you can find more information on this later in this section.

As we continue, you'll find that one of the simplest ways to control an unattended setup using a script is to call winnt32.exe from the command-line using the following, assuming your script is in C:\Deploy:

Winnt32 /unattend:c:\deploy\winnt.sif

If you want to create a boot floppy for your unattended scripts so that you can simply truck it around to each workstation, just copy your script to the floppy and name it WINNT.SIF. Then, use the distribution CD-ROM to install Windows Server 2003 and boot directly from it, and Setup will automatically look for a file on a floppy in the A: drive named WINNT.SIF. If it finds one, Setup will read the instructions from it; if it doesn't, Setup will continue along a normal, user-interactive process.

Regardless of how you instruct Setup to use an unattended script file, you must create one. The next section details this process.

2.6.1.1 Constructing unattended setup scripts

It's easy to create the setup files used by an unattended setup in Windows Server 2003. Microsoft has included a utility called the Setup Manager, which is a graphical utility that asks you most of the questions Setup would ask during an installation, notes your answer, and constructs a WINNT.SIF answer file based on your inputs. Although the file that's created is very basic, it certainly works, and it's a great starting point for further customizations on your own. You'll see some of these options in action as we step through this process. To access the Setup Manager program, follow these steps:

1. On the Windows Server 2003 distribution CD, navigate through the Support\Tools folder hierarchy.

2. Double-click the deploy.cab file.

3. From the Edit menu, select all files inside the new folder, and select Copy to Folder.

4. Copy the files to a directory on your hard disk. You might need to create this directory using the Make New Folder button. Use any convenient path, as long as you can get to it easily to rename, copy, and edit your scripts.

5. Inside the new folder, launch Setup Manager by double-clicking setupmgr.exe.

Once Setup Manager has started, you'll be prompted to either create a new answer file or edit an existing one. Choose to create a new one, and click Next. Now, you're presented with several options, depending on the particular application for which your new answer file will be used. You can create a basic unattended setup answer file, one that can automate the Mini-Setup program inside an installation that has been SYSPREPed, or a file that will control installations started with RIS. I'll cover the latter two options later in this section. For now, select to create a normal, basic unattended setup answer file, and click Next.

The next screen prompts you to choose the operating system for which you're creating an unattended install. You can create files for all editions of Windows XP and all editions of Windows Server 2003 except Datacenter, too, so the Setup Manager utility is more useful than it might otherwise appear. Choose to install Windows Server 2003 Standard Edition and click Next. At this point, you can now choose what level of "hands-off" you want to achieve: a completely hands-on installation with customized defaults read from the answer file, a fully hands-off installation which is started from the command-line and not finished until Windows Server 2003 is completely installed, and most options in between. Choose Fully Automated to get the full breadth of options that Setup Manager can configure, and click Next.

Here, Setup Manager offers to assist you in creating on your network a distribution share, or a file share that contains an entire copy of the Windows distribution files for the purposes of kicking off network-based automated installation sequences. For our purposes, click Set up from a CD because we just need to create an answer file, not generate an infrastructure for more complex rollouts. Click Next, accept the End-User License Agreement, and click Next once more. You have completed the wizard portion of the Setup Manager process, and the screen shown in Figure 2-6 is displayed.

Figure 2-6. Setup Manager's detailed configuration screen

The remaining portion of Setup Manager involves customizing the many details of a Windows Server 2003 installation:

1. The first section, General Settings, enables you to enter your name and organization, display settings such as color depth and resolution, your time zone, and your Windows product key. Enter the appropriate values and click Next in each section.

2. In Network Settings, select per-seat or per-server licensing, and click Next.

3. The Computer Names screen appears. You have some options as far as assigning names to newly deployed computers: you can type the names directly into Setup Manager, import names from a text file, or tell Setup to automatically generate them based on the values entered for the name and organization earlier in the process. Click Next to proceed.

4. Now, you need to generate an administrator password. Because you've chosen the fully automated type of answer file, the option for the user to provide a password is not available. Instead, enter one yourself. The news of note on this screen is the option to encrypt the administrator password in the answer file. With Windows 2000, the only truly secure way to use answer files was to use a dummy password for the administrator and then manually change it later after the installation completedobviously that wasn't very convenient. Now you can use a real password without fear of untoward viewing of your answer file by password snoops. Click Next to move on.

5. You're prompted on the next screen to select the appropriate networking components for these systems. The Typical option's settings configure the computer to use DHCP to get an IP address; it also installs file-sharing capabilities. You can opt to use a static IP address. Click Next once you've configured the relevant options.

6. On the Workgroup or Domain page, choose whether to be a part of a workgroup or to join an existing NT or Active Directory domain. Also specify the names of either the workgroup or the domain to join. Click Next.

7. You're now in the Advanced Settings portion of Setup Manager, and the first screen is very useful: it enables you to determine exactly what parts of Windows are installed on a machine. Now you can get rid of WordPad or not install IIS on all your machines by default, a useful feature of the Windows installation program that Microsoft inexplicably removed first in Windows 2000 Professional and then in all later versions. Select the appropriate Windows components to include or not install, and click Next.

8. The Telephony settings page appears, but only if the server detected a modem during the installation process. Enter your area code and outside dialing preferences, and then to proceed, click Next.

9. On the next page, adjust any regional settings, such as keyboard, currency, time zone, and the like. Click Next, and again, specify your region-specific language settings. Click Next when you are finished.

10. The Browser and Shell Settings page appears next. Using this feature, you can customize your browser's (let's be realisticInternet Explorer's) home page, security, and personalization settings so that these are automatically set up during installation. Click Next once you've configured these options appropriately.

11. Specify the name of the folder where the Windows system files should reside (the default is C:\Windows). This also is known as the SYSTEMROOT for other purposes, as in the context of the Recovery Console. Click Next to continue.

12. The Install Printers screen appears. Here, you can specify the names of network printers that will be automatically configured and available to the new installation. You can specify any number of network printers. Click Next once you've entered your list of printers.

13. The Run Once page enables you to specify commands and programs that will run after the first boot of the newly installed operating systemthat is, just after it's finished. This is useful if you want to kick off the domain controller upgrade program, DCPROMO. These settings are stored in the Windows Registry. Click Next.

14. The Additional Commands screen appears. These commands are executed at the end of Setup, but before the first restart. This feature is great if you're interested in installing the Recovery Console automatically after an installation is completed. To continue, click Next.

15. Finally, you'll be prompted to select a location for the answer file. Select one and click OK. You have successfully created your answer file.

    

    Before using your unattended installation script, you'll need to rename it from UNATTEND.TXT to WINNT.SIF. Not doing so will result in a nonfunctional script. Understand that these are essentially the same file: UNATTEND.TXT is used when winnt32.exe is called from a script. WINNT.SIF is used when an unattended install is required and needs to be run from the CD.

    
    

2.6.1.2 Privatizing the dynamic update process

Microsoft has begun releasing updated system and setup files which can be accessed by Setup for new installations. The net benefit of this initiative is the immediate updating of a newly deployed machine: problems with the installation and upgrade process are eliminated with updated Setup executables.

Although Microsoft allows these updates to be downloaded directly from their Windows Update service, you might want to run the dynamic update feature directly from your own network to control what updates are applied to which workstations or servers. To internalize this process, you must first download the dynamic update package, expand the files onto a network share, and then instruct the Setup program to use the localized version of the updated files and not those on the Windows Update web site. Here are the steps involved:

1. Surf to the WindowsUpdate Catalog at http://windowsupdate.microsoft.com/catalog.

2. Click Find Updates for Microsoft Windows Operating Systems.

3. Select Windows Server 2003 under Operating System.

4. You need to display additional search criteria to filter the dynamic update package; to do so, click Advanced Search Options.

5. Under Update Types, check the Service Packs and Recommended Downloads checkbox. Clear the remaining checkboxes, and proceed by clicking Search.

6. Under Your Search Returned n Results, click Service Packs and Recommended Downloads.

7. Under Dynamic Setup Updates, click Add, and then click Go to Download Basket.

8. Select the path to the network share that contains the update package and click Download Now.

Once the download has completed, navigate through your filesystem to the place where you downloaded the update package. Double-click to open it. This will open a window that contains the package's contents, which should consist of a few cabinet (.CAB) files in a structure similar to that shown in Figure 2-7.

Figure 2-7. Relative folder structure of a dynamic update package

To use the package, you must prepare the network share where the update package currently resides. Use the following command to complete this preparation, substituting the path to your network share for [path]:

Winnt32 /DUPrepare:[path]

Your share is now ready to use. For manual installations, you can use the /DUShare switch, specifying the path to the private dynamic update network share as an argument much like the /DUPrepare switch. But by default, in unattended installations, dynamic update is disabled. You must include a line in the answer file to direct Setup to enable Dynamic Update and to specify a location where the updated packages can be found. Insert the following line into WINNT.SIF, in the [Unattended] section:

DUShare = "Path to privatized update package share"

2.6.1.3 Understanding and creating UDF files

You might be wondering how to deploy several computers using one file when one crucial requirement remains unaddressed: how do you assign unique names to each installation? The answer lies in a single file: the uniqueness database file (UDF), which provides a method for Setup to select values for variables that are unique to each individual system deployed. Some of the settings you can customize with UDFs include computer names, descriptions, and administrator passwords. The UDF files themselves are very simply constructed: like an old .INI file, they contain a list of identification values and pointers to full sections for each value later in the file. Here is a sample:

;SetupMgrTag [UniqueIDs]     MERCURY=UserData     VENUS=UserData     EARTH=UserData     MARS=UserData [MERCURY:UserData]     ComputerName=MERCURY [VENUS:UserData]     ComputerName=VENUS [EARTH:UserData]     ComputerName=EARTH [MARS:UserData]     ComputerName=MARS

Note that under the UniqueIDs section, each value is identified along with the specific section in the standard unattended answer file to replace with the information in the UDF. Then, Setup reads the files, and in each individual computer's section it identifies the key to be replaced as defined in the file, and uses the replacement value given to actually make the change. How does it all come together in the end? Setup reads this file as instructed from the command-line with an argument that tells it which value the current deployment is; that is, computer MERCURY, VENUS, EARTH, or MARS from my sample UDF. Once Setup knows that, it looks in the individual section and replaces the standard responses to the prompts given in the standard answer file with the specific ones listed in the UDF file. Issue the following command to kick off this process for computer EARTH, assuming this UDF file is called UNIQUE.UDF:

Winnt32 /unattend:c:\deploy\winnt.sif /udf:EARTH,unique.udf

2.6.2. Using RIS

If you have a larger network, in which you might receive five or 10 new machines a week to deploy initially, or in which you might need to completely reformat and reinstall some computers, you'll probably be longing for a more hands-off procedure than simple unattended scripts can give you. Microsoft, answering the call, has combined the convenience and features of unattended scripts with a tool that will allow your computers to boot from the network, select a preconfigured operating system image, and transfer that image to the hard drive of the target computer, all with just a few short answers at the beginning of the process.

And it's not too good to be true, I promise. RIS makes it simple to install hundreds of machines by booting them off the network. It's remarkably flexible. You can perform three types of installations with RIS.

A simple installation

In this scenario, the files in the I386 directory of the distribution CD are copied to a network share and subsequently used for normal, user-interactive setups.

A scripted installation

In scripted installations, the computers boot off the network and are tossed into an installation using a specific unattended install script (which can make Setup completely hands-off).

A disk image transfer

In this scenario, a computer is completely set up with OS and applications, an image of that computer is created and uploaded to the RIS server, and then clients can retrieve that image and copy it to their local computer.

2.6.2.1 RIS limitations

RIS has a few key hardware limitations that you should be aware of. They are detailed as follows:

All client machines must support the Pre-boot eXecution Environment (PXE) boot feature

This is the stickler here. PXE allows a computer's BIOS to hand off boot control to the Ethernet card installed on the computer. The Ethernet card searches for an Active Directory-authorized DHCP server, applies the address assigned by that server, and then launches a TFTP transfer client that downloads the necessary files to boot into the Client Installation Wizardthe first step of an RIS installation. If your network card doesn't support PXE booting, you can't get on the network, and therefore can't take advantage of RIS.

However, if you own one of 32 specific models of network cards, you are in luck: Microsoft provides a network boot disk that takes care of the PXE logic for the network card, enabling you to use RIS on a machine that otherwise would not qualify. Microsoft has made many promises to expand this boot disk's coverage of network cardsclaims of such modifications exist back before the release of Windows 2000but as of yet, Microsoft has made no additions.

Laptops must be able to boot off the network

The aforementioned boot floppy works with only two PC Card-based Ethernet adapters, and those are fairly old. So, most likely, if your laptop is not fairly new, you still will need to deploy it manually, or at least without RIS. However, notebook manufacturers have begun to include built-in Ethernet connections using the miniPCI standard, and these commonly are PXE-compliant. If it's time to reevaluate your baseline corporate laptop configuration, you would do well to ensure that your laptops are PXE-compliant.

RIS imaging, using either a scripted install or a flat image installation, can install only the system root (all the operating system's core files) to the C: drive

If you have a computer with multiple physical disks, RIS will only transfer an image of a C: drive to a C: drive, and nothing else. RIS will only build images of C: drives, and it will only service C: drives on the client side. This works similarly for partitions, too, however you should be careful about partitioning because RIS tends to reformat the entire hard disk (although a warning is provided, it's easy to overlook), which will blow away your existing partitions as well. Either pay careful attention when performing RIS deployments to computers with many partitions or use another scheme to organize your computers.

You must have a separate partition or physical disk on the server to use for the RIS subsystem

RIS cannot cope with having Windows system files on the same volume where flat images and RIPrepped images are located. This is mainly because of interactions between critical copies of active Windows system files and the Single Instance Storage (SIS) Groveler service, which allows one copy of one file to be placed on a disk, and links to be placed in all other locations on the disk where a copy of that file resided. It's like mail aliasing, in that small links to one copy of one file save space that otherwise would be wasted with multiple copies of the same file. Enterprises with eight different Windows Server 2003 images available to RIS obviously have eight copies of many files. SIS reduces the disk space usage almost eightfold.

Some people have reported that it's not possible to use RIS on the server side on a machine that is functioning as a DHCP or DNS server. I'm happy to explain that that is false. In my test lab, I have two domain controllers, the first of which is also a DHCP server, a DNS server, and the RIS server for my network. I have no problems delivering any sort of image to any compatible client on the network. So, for the server consolidation advocates among you, I don't see any problems with using a server acting in multiple roles and as an RIS server as well.

Software requirements are a little less stringent than the hardware RIS needs. You must have a DHCP server on your network, and you must be conducting RIS deployments in an Active Directory-based domain. RIS cannot handle static IPs, mainly because the PXE protocol has no such provision for them. RIS also uses DHCP as a mechanism to control the entry of unauthorized RISes to your network: before an RIS server can be used for deployments, it must be authorized within Active Directory.

2.6.2.2 Activating an RIS server

To begin using RIS on your network, you must first authorize the RIS server as a DHCP server in your network. Then, you install the RIS component onto your server, reboot, and add images. The process is outlined here:

1. Go to a DHCP server, and log in with an account that has Enterprise Administrator privileges.

2. Select Start All Programs Administrative Tools DHCP.

3. The Manage Authorized Servers dialog box appears. Click the Authorize button, enter the IP address of the RIS server you want to authorize, then click OK.

4. You will be prompted to confirm the decision. Click Yes to confirm or No to change your entry.

5. The newly entered address will appear in the white box. Click OK to close the box.

Now it's time to actually install the RIS component on the server:

1. Navigate to the Add/Remove Programs applet in the Control Panel.

2. Choose Add/Remove Windows Components in the left menu bar.

3. After a short wait, the Windows Components Wizard will appear. A list of optional Windows components will be displayed. Scroll to Remote Installation Services, check the checkbox, and click Next. The wizard will copy necessary files and then prompt you to reboot.

Finally, you must configure RIS and install an image to be used with RIS. In this example, we'll use a basic Windows XP Professional image that can be used to deploy on new computers later in the chapter. To get started, follow these steps:

1. Run RISETUP from a command prompt to launch the Remote Installation Services Setup Wizard. Click Next on the splash screen.

2. The wizard will determine the best place to put image files. Remember that this must be either a separate partition or a separate physical drive. You also can change the name of the directory the wizard will create. Click Next to continue.

3. The next screen asks you if you want to begin accepting new clients for deployment immediately. By default, RIS will not answer requests for network booting until you configure it to do so. To override this default, select Respond to Client Computers Requesting Service and click Next.

4. The Installation Source Files Location screen appears. Insert your Windows XP Professional CD-ROM into the server, or find a location on the network where XP's I386 directory can be found, and click Browse to show Windows where it is. Click Next when you've finished.

5. Here you're prompted to select a name for the folder where the basic XP image will be installed. Because you likely will have many images, it's advisable to use a specific name for the folder, such as XPPRO-BASIC or XP-SP1. Click Next when you've typed an appropriate name.

6. The Friendly Description and Help Text screen appears. Type a one-line description to identify the image; this will appear in the Client Installation Wizard text-based setup files during network booting as a menu option. Then, in the Help text box, enter a short description of the image. This is for your records only. Click Next once you've done so.

7. The Review Settings screen enables you to ensure the wizard has obtained the inputs that you want. Click Finish if everything looks right, and Windows will begin copying the image.

The image copying procedure takes a whileon the order of 15 to 20 minutes per image, usually, depending on the speed of your server and CD-ROM. When you come back, though, the image will be installed into RIS and available for deployment. A reboot is not required.

2.6.2.3 Deploying an image to a client

Once you've activated your RIS server and added images to deploy, you can then network-boot your client computers and transfer the images to them. The process to do so depends somewhat on the client computer. Some corporate-targeted PCs have options in the machine's BIOS to boot from the network, usually found in the area that determines the boot order of the storage devices. Other computers offer an option directly during the POST process to press F12 or some similar key to perform a network service boot (the Compaq Armada E550 I'm using to write this now uses the latter method, whereas the Dell Precision Workstation that is my main desktop computer uses F10).

However, some older computersand yes, some newer computers as welldon't have the option to boot to the network in their BIOS or during POST. In this case, you'll need to use the RIS remote boot disk, mentioned earlier in this chapter as the saving grace for some machines. The Windows Server 2003 RIS disk supports 32 network adapters, all of which are PCI cards. If your Ethernet card is on that list, RIS will work even if the machine doesn't support PXE directly. To generate the network boot disk, navigate to the \RemoteInstall\Admin\i386 directory on your RIS server machine, and double-click RBFG.EXE. It will prompt you to insert a disk which it will then format and reconstruct as the RIS remote boot disk.

On to actually performing the deployment: insert the boot floppy or select the option to boot from the network, whichever applies in your case. If you use the boot floppy, you will see text similar to the following:

Microsoft Windows Remote Installation Boot Floppy Copyright 2001 Lanworks Technologies Co., a subsidiary of 3Com Corporation All rights reserved. 3Com 3C90XB / 3C90XC Etherlink PCI Node: 00115A5E3E12 DHCP.... TFTP........... Press F12 for network service boot

During that process, no matter which method you used to activate the network boot, the computer contacted a DHCP server and requested an address. That address was sent in a packet, containing a pointer to a server which has files needed to continue the RIS boot process. These files were transferred using the TFTP protocol, a cousin of the commonly used FTP protocol. Once the boot files were transferred, the program prompts you to confirm that you want to boot from the network. Press F12 to confirm this, and the blue background, text-based Client Installation Wizard appears.

The first screen prompts you to enter your username, password, and account domain membership information. Then, you will be prompted whether to do an automatic or custom setup, or if you'd like to restart a previous failed setup attempt. Here is the difference between the two: automatic setups generate the computer name from a combination of your username and the computer's MAC address and set up an unattended installation with all the defaults. They also can retrieve existing data from Active Directory with regard to computer name and identification if you're redeploying a machine already in the directory. On the other hand, custom setups enable you to define a specific computer name for each RIS installation regardless of whether the machine is already in the directory. Restarting a failed setup attempt is as functional as it is obvious; it begins either back at the text-based portion of Setup or at the graphical portion, depending on where in the process Setup stopped.

When using the Custom Setup option, you will be expected to know where in Active Directory the computer account should be located. If you do not specify a location, the default [domainname.com]/Computers, the Computers container, will be the home of the newly deployed machine.

2.6.2.4 Slipstreaming service packs

Because deployment and initial installation are now so convenient, you likely will find yourself longing for a streamlined post-Setup process. One of the most common tasks that must be performed before you can hand off a computer to an employee is installing the latest service pack and security updates. This is especially important in light of the latest wave of worm attacks: newly installed machines can be infected with these worms before you even have a chance to install patches!

All hope is not lost, however. Using a special command-line function of the service pack executable, you can instruct all versions of Windows 2000-, Windows XP-, and Windows Server 2003-based service packs to replace old files in a central distribution share with updated ones. This process, known as slipstreaming, works very well with RIS images because you already have the requisite distribution share. Let's walk through the process. You'll need the network/administrative (in other words, the full) version of the service pack for your respective platform, not the regular user version. To create the slipstreamed installation, follow these steps:

1. Create a directory called c:\winsp, and copy the downloaded service pack file there. I'll assume the service pack file is named ws2k3sp3.exe.

2. Extract the service pack to that directory by executing the following command from the command-line or from Start, Run: ws2k3sp3.exe -x.

3. Now, update the files from the regular Windows distribution CD with the new service pack files by executing the following command from the command-line or from Start, Run: D:\wins2k3sp3\i386\UPDATE\UPDATE.EXE -S:C:\windist.

The files are then updated, and the process is complete. Slipstreaming is an easy way to make sure that new systems are updated before they're ever put into production.

2.6.2.5 Using the OEM option for further customization

System builders and solution integrators have a wonderful set of tools at their disposal to customize the first-use, or "out-of-box" experience. Manufacturers such as Dell and Gateway can use OEM installation options to install software, add support information, and generally make a plain-vanilla Windows installation their own. So, if they can do it, why can't you, the system administrator? After all, you're creating your own "brand" of computer, specifically for your company. Using the OEM folder, you can apply hotfixes during Setup so that your machines are as updated as possible, customize a browser, and add support information to the System applet in the Control Panel.

You can use the instructions in this section with plain, non-RIS unattended installations as well. I note the differences in processes between the two methods of deployment where applicable.

The Setup program is hardcoded to perform special actions when it finds certain files and folders within an $OEM$ folder in the installation directory or CD-ROM. To use this folder, create it at the same level as I386 in your RIS distribution share. (If you're using these instructions to create a special CD-ROM for computers that can't use RIS, create the $OEM$ folder inside I386. For some reason, the $OEM$ folder for RIS installations needs to be at the same level as the I386 folder.)

Next, open your RIS script, RISTNDRD.SIF, which you can find at \\RISServerName\Reminst\Setup\English\Images\imagename\I386\templates, and find the [Unattended] section. There should be a line called OEMPreinstall with a value of No. Change this to Yes and save the file. This instructs Setup to look for the $OEM$ directory.

First, let's add some updated drivers to our installation. Although Windows Server 2003 likely has reasonably up-to-date drivers for the most common hardware available, as time goes on new hardware obviously comes out for which Windows Server 2003 doesn't have native support. You can instruct Setup to look inside the $OEM$ directory for updated drivers and install them before the machine ever finishes the installation. This worksthe principle and the procedure we're about to go throughnot only with Windows Server 2003, but also with any NT-based client operating system, including Windows 2000 and Windows XP. To make this work, follow these steps:

1. Create a directory called $1 inside $OEM$.

2. Create individual directories inside $1 for each peripheral for which you have updated drivers. I'll assume you're installing new audio drivers, so for the purposes of this example, create a directory called SOUND inside $1. Place the driver files for the audio card within $OEM$\$1\SOUND. Make these names as short as possible, for reasons described in the next step.

3. In RISTNDRD.SIF or your alternative unattended installation script, add the line OEMPnPDriversPath="SOUND" and save your work. Note that you describe directories in this command only by their location under $OEM$\$1. It's also important to limit the length of the path portion of this command to more than one character but less than 40 characters; otherwise, Setup will fail.

If you have multiple new drivers to install, separate each directory in the preceding command with a comma and a space. Make sure to enclose the paths in double quotation marks.

Next, let's describe installing hotfixes using the $OEM$ options. When the OEMPreinstall option is set to Yes inside your unattended installation script, Setup looks for a file called CMDLINES.TXT inside the $OEM$ directory. If it finds one, it executes the commands listed in the file near the end of setup, before the first reboot. There are two catches to this: one, the programs which those commands listed in that file execute must reside in the $OEM$ directory, not in subdirectories above or below it; and two, the file CMDLINES.TXT itself must be inside the $OEM$ directory.

Now, the hard part of this tip is actually finding the hotfixes and transporting them to the correct location for use within Setup. Microsoft recently reorganized the way hotfixes are obtained outside of the automated, user-blind Windows Update process. To obtain these "network administrator"-style patches, you must connect to the Windows Update service at http://windowsupdate.microsoft.com. Click Windows Update Catalog in the left bar. Then, follow these steps:

1. Click Find Updates for Microsoft Windows Operating Systems.

2. Select Windows Server 2003 under Operating System.

3. You need to display additional search criteria to filter the hotfixes; to do so, click Advanced Search Options.

4. Under Update Types, click Security Patches and Hotfixes.

5. Under Your search returned n results, click Security Patches and Hotfixes.

6. Click Add for each hotfix, and then click Go to Download Basket.

7. Select the path to the network share that contains update package and click Download Now.

The really frustrating part about this process is that when you download these hotfixes, the Download Manager creates this supremely convoluted directory structure in which each particular hotfix resides in its own directory, with the executable file and an HTML document describing the fix. Because using CMDLINES.TXT requires that all the executable files to be run reside in the same directory, you have to manually extract the executables from this directory structure and copy them to the $OEM$ directory. Although it's not much of a problem with Windows Server 2003 hotfixes, if you happen to be deploying Windows XP without Service Pack 2 with this process, the 60-odd files you must drag and drop out of this structure will either drive you mad, put you into the advanced stages of carpal tunnel syndrome, or perhaps both. If any Microsoft people are reading this, give us the option to put all these executables into one directory!

Simplifying Hotfix Catalogs

Technical reviewer Eddie Phillips provided me with the following method that might make the process of sorting out these downloaded hotfixes a bit less tedious.

Simply put the following in a batch file, and called it WUFix.bat:

for /F "tokens=1 delims=!" %%i in ('dir %1\*.exe /s /b') do @copy %%i %2 for /F "tokens=1 delims=!" %%i in ('dir %1\*.exe /s /b') do %%i /?

Now, if D:\Temp\WU\WUpdate is the directory where you saved the hotfixes you downloaded from the Microsoft web site, and you want the meat of those packages to go to D:\Temp\WU, run the batch file you just created with the following parameters:

WUFix.bat D:\Temp\WU\WUpdate D:\Temp\WU

You should have all your patches in one directory now.

Thanks again to Eddie for this tidbit.

The next frustrating part of this process is actually using the updates. Microsoft has said repeatedly that patch management would be quite a bit easier in the future, and the first step, it said, was to create patches with standard nomenclature and standard methods of execution and application. The news isnot surprisinglythat this utopia hasn't been reached yet. When you download hotfixes from Windows Update, some are named using one system, such as Q823980_WXP_SP2_ENU.exe, and others are named using some other system, such as WindowsXP_Q329834_ENU.EXE, and still others are named using what seems like no convention at all. Further, the switches that control the installation and execution of these hotfixes are not standard either. Some require /q and /z to install silently without reboots, while some require -q and -z, some need /noreboot, and others don't have switches at all. This is a sad state of affairs, and at this point, the only workaround is to manually test each patch on a system, note their behavior, and adjust the line in CMDLINES.TXT that calls that patch accordingly.

You might think that with all these negatives, it's not worth the time it takes to create this $OEM$-based solution. But if you're installing machines using RIS and are not behind a firewall, the 45 minutes it takes to use Windows Update after the first reboot is more than enough time for a worm to infest your system before the applicable update is installed. These days, it's nearly a necessity to use this procedure. Hopefully, once Service Pack 2 for Windows XP and Service Pack 1 for Windows Server 2003 come out, there'll be a better way to perform these updates. But for now, once you've dragged 60-odd hotfixes out of their individual directories, tested each one individually for its command-line behavior, and iced up your wrists, generate CMDLINES.TXT using the following formula:

[Commands] "q823980_wxp_sp2_enu.exe -q -z" "WindowsXP_Q329834_enu.exe -q -z"

Make sure the commands are fully surrounded in double quotes, and that the switches you use tell the hotfix to install silently and without a reboot. (If in doubt, run the executable with the /? argument: this will list the switches to which that program will respond.)

2.6.3. Deploying a System Image: RIPrep and Sysprep

If RIS and unattended installations are great for deploying operating systems and hotfixes to a varied hardware base, RIPrep and Sysprep are wonderful helpers to deploy a complete "image" of a system, including the operating system, applications, customizations, settings, and restrictions, to a base of hardware that is identical in every respect. This is great for lab environments, and even better if your organization has a standard hardware base for all its new purchases within a year or two. The process is simple, too. You first create a prototype system, with the operating system, any applications, any environmental customizations, and anything else you want to pass on. Next, you run RIPrep, the Remote Installation Preparation Wizard, which gets rid of personal and security-related information and copies the image to the RIS server. You then deliver the image to the appropriate systems using the regular RIS network boot process.

There is a limitation to using RIPrepyou cannot image the following types of systems:

• A domain controller because security information is stripped out of any RIPrepped image

• A DHCP server because multiple rogue DHCP servers on a network can wreak havoc

• An RIS server because each RIS server is authorized to be a DHCP server and these are prohibited as mentioned previously

Let's pick up the step-by-step process after you've created your prototype system, the one you want to be duplicated. Install and configure a system exactly as you like. Then, follow these steps:

1. Navigate to the REMINST share on your RIS server and open up the Admin\I386 folder.

2. Double-click RIPREP.EXE. The Remote Installation Preparation Wizard welcome screen appears. Click Next to continue.

3. Type the name of the RIS server where you want to store the image, and click Next.

4. Generate the name of the folder that will house the image, and click Next.

5. The Friendly Description and Help Text screen appears. Much like with a flat RIS image, select the text that will describe the image and a short statement about the image and enter it into the appropriate boxes. Click Next to continue.

6. The Report System Compatibility screen appears. Here, RIPrep will look over your system and tell you whether it's suitable to be imaged. You'll also note that multiple local profiles won't work because all security identifier information is stripped out of the image. Click Next.

7. RIPrep notifies you of its need to suspend some services, and then prompts you to confirm your choices on the Review Settings screen. Click Next to create the image.

Reboot the prototype once RIPrep is finished. You'll note that it looks like Setup is being performed all over again; this is again because of RIPrep scrubbing the security identifier information from the prototype. Basically, it's all of the graphical setup, without the Plug-and-Play installation process. Just proceed through it, including reactivating the installation after Setup is finished, and you'll have the machine back for use.

To deploy an image that was RIPrepped, simply go through the RIS boot process, and from the menus that allow you to select which image to deploy to the target computer, select the RIPrep image with the friendly description and help text that you specified in the previous procedure. The remainder of the process works exactly like a flat RIS installation.

2.6.3.1 Sysprep: the system preparation tool

Sometimes, though, using products such as Symantec Ghost and PowerQuest DriveImage is the quickest way to lay down an image onto multiple systems at once. The difference is that Ghost and DriveImage take what amount to photographs of the drive, copying whole partitions and physical disks without regard to individual files. RIPrep and RIS, on the other hand, look at individual files, which sometimes make it a little difficult to exactly replicate advanced prototype images. There's a catch, though: although products such as DriveImage and Ghost contain security identifier (SID) generators, which scrub out security identifier information in an image and replace it with a fresh, randomly generated SID, Microsoft doesn't support SIDs created with these generators. The company wants you to use Sysprep, which does just that in Microsoft's fashion, and in such a way that the company will support if you ever need technical assistance. Because the price is right (Sysprep is shipped free with Windows Server 2003), and it could save some headache in the future, it's a smart move to use it instead of the SID generators in third-party products.

Sysprep will not re-image a domain controller, a member of any cluster, or a machine functioning as a certificate server because of the inherent machine-specific characteristics of those services. However, after Sysprep has completed, these services are certainly supported and available to be installed.

Here's an overview of how Sysprep works.

• You generate a prototype image, much like with RIPrep, and configure everything on that system as needed.

• You put Sysprep on that image, in a separate directory, along with an ancillary program called SETUPCL.EXE.

• You then copy the profile of the local administrator account, which likely has the settings and customizations you've been performing, to the Default User profile so that all future users of the system get those tweaks.

• Then, you run Sysprep. This scrubs SIDs and personal information from your prototype and shuts down the machine.

• Next, you boot the computer from a floppy disk and let your third-party imaging software take over, "photographing" the disk.

• Finally, you reboot the computer without the floppy, and proceed through mini-Setup again so that all personal information can be restored and new SIDs can be generated. (You can script this process so that a mini-unattended installation is performed.)

To start Sysprepping a machine, follow these steps:

1. Install and configure a system as you like it, using the local Administrator account.

2. Create a new local administrator. See Chapter 5 for instructions on creating local users.

3. Log out of the local Administrator account and log on to the new account you created.

4. Navigate to the System applet inside the Control Panel. Click the User Profiles tab.

5. Select the one called Administrator that has the local machine's name in it, and click Copy To.

6. The Copy To dialog box is raised. Click Change in the Permitted to Use section.

7. Select Everyone is the list. This gives permission for anybody logged onto the computer to use the contents of the profile. Click OK.

8. Click OK to get out of the Copy To dialog box.

9. Finally, copy the contents of Documents and Settings\Administrator to Documents and Settings\Default Users. Ensure that you are displaying hidden files and folders so that you copy all configuration files.

10. Now, run Sysprep with the following command:

    Sysprep -reseal -quiet -mini -pnp

    
    

Sysprep will strip the SIDs off the system, scrub any personal identifying information from the image, and then shut down the machine. This is where you need to take over with your third-party tools to deploy these images.

You also can run Setup Manager, as described earlier in this chapter, to create an unattended mini-Setup script that will make setup on newly deployed Sysprepped images a hands-off process. Setup Manager even includes an option whereby you are prompted to select the type of script to create to generate a Sysprep script. Set this, follow the screens using the guide presented earlier in this chapter, and copy the created filerenamed SYSPREP.INFto C:\SYSPREP on your image.