2. Installation and Deployment

IN THIS CHAPTER

• Automating Windows Server 2003 installations

• Activating Windows Server 2003

• Remotely deploying the operating system

• Using Automated Deployment Services (ADS)

• Upgrading to Windows Server 2003 from previous versions

What's New

Much of installing and deploying Windows Server 2003 is the same as in Windows 2000. As you will see in this chapter, some changes have occurred, primarily in the way of improvements and extensions to the previous methodologies. Improvements have also been made in the creation of unattended setup files and extensions to Remote Installation Services (RIS) to include support for deploying more operating systems, including the Windows Server 2003 server platforms. A new feature that affects installation and deployments, Windows product activation, is also discussed, including the differences between deploying with retail and volume product license keys. Finally, this chapter takes a look at what's involved in upgrading to Windows Server 2003, such as supported upgrade paths, deployment methodologies, and considerations for mass upgrades.

Installation Changes

The installation process for Windows Server 2003 is basically the same as that for Windows 2000. You can perform network installations or CD-based installations, including booting from CD. Similarly to the setup process for the previous version, the setup process for Windows Server 2003 has several phases. There is a DOS-style initial phase for configuring and formatting drives and selecting the installation location. This is followed by a graphical user interface (GUI) phase in which system hardware is detected; licensing is configured, including entering the license key; the computer name and administrator password are specified; network settings and regional options are configured; and the computer can be joined to a domain. All this is basically the same as in previous versions—the differences in the installation process are in the available options and what you can configure.

Attended Installations

As in previous versions of Windows, you can perform an installation from the Windows CD or from source files across the network. We'll start with a walk-through of a CD-based installation—specifically, booting from CD—and then take a look at network-based installations. As we walk through the installation process, you'll note how similar it is to that for Windows 2000.

CD-Based Installation of Windows Server 2003

To start installing Windows Server 2003 on a new system, simply insert the Windows Server 2003 CD and turn on the system. If the system is configured to boot from CD and there are no configured disk partitions, the Setup program launches automatically and begins installing Windows Server 2003. If disk partitions are configured, the system displays the following prompt: Press Any Key to Boot from CD. You must then press a key to launch the Setup program. If you don't have a bootable CD-ROM drive, you can boot to a DOS floppy disk with CD-ROM drivers and launch Setup by running winnt.exe from the i386 directory of the Windows CD. Alternatively, if you have a previous installation of Windows on your system, you can perform an upgrade or fresh installation by running winnt32.exe, which is also in the i386 directory. We will look at upgrading from previously installed operating systems later in this chapter.

When booting from the Windows Server 2003 CD, the initial phase looks exactly as in Windows 2000. You get the familiar blue Windows Setup screen, as shown in Figure 2.1. If you need to install device drivers for your disk array, press F6 when prompted at the bottom of the screen, just as in Windows 2000. After the system detects initial hardware devices and loads the Setup application, you are prompted to set up Windows, repair a previous Windows installation, or quit.

Figure 2.1. Windows Server 2003 Setup starts off looking exactly like Setup in previous versions of Windows NT and Windows 2000.

Assuming that you choose to continue with the installation of Windows, the license agreement is displayed, and you must press F8 to agree to the terms and continue. Next, you are given the opportunity to create or delete partitions and select the installation drive. When booting from CD, you can do just about anything to the drive partitions. You can create new partitions and delete any or all of the existing partitions. After you have the drives partitioned the way you want, you select a partition on which to install Windows Server 2003. Next, Setup detects whether there is an existing version of Windows on the partition you chose. If there is, you are prompted to upgrade it or erase it and start fresh. Next, you are prompted about what to do to the existing file system. You can format with NTFS, format with FAT, or leave it unchanged (that is, just like Windows 2000). However, as shown in Figure 2.2, if previous partitions exist, you have the option to perform quick formats with NTFS or FAT to save time.

Figure 2.2. You have new choices for formatting existing partitions using NTFS or FAT.

The default is to format the partition using NTFS. The system then formats the drive (if that's what you chose). It checks the integrity of the drive and then copies the Windows files. After the file copy is complete, Setup reboots, and the GUI phase starts.

After the reboot following the DOS phase, Setup enters the GUI phase. The first option you have during the GUI phase of the installation is to configure regional and language options.Next, you can personalize the installation by entering your name and company name. You are then prompted to enter the product license key and to select the licensing mode—per server or per seat. Next, you configure the computer name and administrator password. One new feature is a warning about less-than-secure passwords: If you enter a password that doesn't meet the minimum requirements for length and complexity, as shown in Figure 2.3, Setup pops up a message warning that your password is too simple and suggests criteria for a stronger password.

Figure 2.3. Setup detects whether the password you entered doesn't meet the minimum requirements for length and complexity and prompts you to enter a stronger one.

The next step is entering the date, time, and time zone. Setup then detects any network components (such as network cards) that might be installed and prompts you to configure them. If you have multiple cards, you can configure the settings individually for each card. You have two configuration options: Typical Settings (Client for Microsoft Networks, File and Print Sharing for Microsoft Networks, TCP/IP configured to use DHCP) and Custom Settings. Selecting Custom Settings enables you to specify static IP addresses or add or remove services and protocols. Next, you have the option to join a domain or specify a workgroup. After that, Setup finishes copying files and configuring the system, reboots, and starts Windows Server 2003. The first time you log on, the Manage Your Server Wizard starts; it enables you to configure your server for its custom role, as shown in Figure 2.4.

Figure 2.4. The Manage Your Server Wizard starts automatically after Windows Server 2003 installation and enables the configuration of the server for its particular role.

You might have noticed that, unlike in setting up Windows 2000, there is no opportunity in this installation process to specify which server components and services (DNS, WINS, DHCP, RIS, IIS, and so on) to install. Installation and configuration of server components are performed after the operating system is installed, unless you specify otherwise in an unattended installation script. You build those scripts the same way that you do in Windows 2000; for more details, search Windows Server 2003's online Help and Support Center for “unattended installation.” We'll also touch on unattended installations later in this chapter.

Network-Based Installations

Installing Windows Server 2003 from a network is basically the same as installing it from a CD; there is just an extra initial phase for copying the setup files prior to the DOS-based setup phase. It is also the same as in Windows 2000: You simply map a drive to the network location that contains the Windows Server 2003 CD files and run winnt.exe or winnt32.exe from the i386 directory. The main difference between running Setup using winnt.exe or winnt32.exe (either across the network or from CD) and running it by booting from CD is the restrictions on what you can do when partitioning drives in the DOS phase. When you're installing from the network, the files for the Setup program itself must be downloaded to the local system. Consequently, the partition containing those files cannot be deleted during the drive partition phase of setup.

After Setup gets past the drive configuration step, the rest of the setup process for a network-based installation is identical to that for a CD-based installation.

Emergency Management Services Installation

A new feature of Windows Server 2003 is Emergency Management Services. This new feature (actually, it's a set of features) is available on systems that have special hardware that supports firmware console redirection and that have a Serial Port Console Redirection (SRPC) table. Essentially, Emergency Management Services provides out-of-band access to your servers. It is a sort of text-mode console into the server that you can use even when the operating system is down. This gives you access to do anything on the server, short of physically removing and installing hardware.

Therefore, Emergency Management Services provides an additional option for installing Windows Server 2003. For example, you could perform remote installations of Windows Server 2003. After the console is redirected, you can insert the Windows Server 2003 CD, boot the system, and run through an installation. Unfortunately, because of the way Emergency Management Services works, you don't see the GUI phase of setup. Consequently, when Setup reaches the end of the DOS phase, it prompts to automatically configure the GUI portion. Selecting this option enables you to proceed with the GUI installation; however, you don't have any choice in what it installs. It installs with the default options, but at least it gets the operating system installed. One way to overcome this drawback is to do an automated installation with an unattended answer file.

Unattended Installations

For the most part, unattended installations are the same in Windows Server 2003 as in Windows 2000: They can be launched from the network or CD by using winnt.exe or winnt32.exe. Windows Server 2003, however, supports the use of an unattended installation file and an optional uniqueness database file to specify the answers to setup questions.

Because new and different features and components are available in Windows Server 2003, the main differences from Windows 2000 are in the answer files themselves and the methods for creating them.

The Setup Manager Wizard

The Setup Manager Wizard, which is used to create the answer files, has been improved to ease the creation of automated installation files. It walks through all the questions asked during Setup, allowing you to specify the answers. It then creates the appropriate unattended installation file(s) based on your answers. You can install the Setup Manager Wizard by extracting setupmgr.exe from deploy.cab in the SupportTools directory of the Windows Server 2003 CD. (Windows 2000 also requires an additional file, setupmgx.dll.) You can use the Setup Manager Wizard on the Windows Server 2003 CD for creating answer files for all Windows XP and Windows Server 2003 editions, except Datacenter Edition. To create answer files for Windows 2000, you use the Windows 2000 Setup Manager Wizard.

The main improvement in the Setup Manager Wizard is the interface. Rather than having a screen-by-screen prompt for each question and answer, all the main options are on one screen, as shown in Figure 2.5.

Figure 2.5. The new consolidated Setup Manager Wizard options screen streamlines the setup process.

The Windows Server 2003 Setup Manager Wizard also includes a number of additional options. First, in Windows 2000, the Setup Manager Wizard does not prompt for the product license key, so you have to manually edit the answer files or get prompted for the license key during setup. In the Windows Server 2003 Setup Manager Wizard, you can specify the product license key to use.

Another problem with the Windows 2000 wizard has to do with specifying the local administrator password. If you enter it in the wizard, it is stored in the answer file in clear text. Obviously, anyone who has access to the file would then know the local administrator password, which is a potential security risk. In the Windows Server 2003 Setup Manager Wizard, when you specify the local administrator password, you have the option to encrypt it in the answer file. This eliminates the potential security risk of the local administrator password being stored in clear text.

Two additional options the Windows Server 2003 Setup Manager Wizard prompts for that the Windows 2000 version does not prompt for are Windows Components and Additional Commands. Windows Components enables you to specify the installed Windows components, such as World Wide Web service, SMTP service, Remote Installation Services, Terminal Services, and so on. Additional Commands enables you to automatically run programs after the unattended setup completes, while the computer is starting up. You can use this option to further customize the installation by installing programs or setting configuration settings—anything that can be executed without requiring a user to be logged on.

Just like the Windows 2000 version, the Setup Manager Wizard in Windows Server 2003 creates the answer file, the udf file, if any, and a sample batch file based on the answers provided. You can then use these files as they are to automate your deployments or you can further customize them with a text editor.

Image Downloads

Yet another method for deploying Windows Server 2003 is by using third-party imaging software. This process is largely the same as in Windows NT 4.0 and Windows 2000. A reference machine is prepared, with all software installed and configured the way you like it. The sysprep.exe utility is then run to remove all machine-specific information, such as SID, computer name, and so on. This generic installation is then copied to a network share, using third-party imaging software, which makes an exact bit-by-bit copy of the hard drives on the system. The image is stored on a server and later downloaded to one or more target machines. When a target machine boots up from the deployed image, a mini-setup wizard starts, asking for all the machine-specific information removed by sysprep.exe, such as the computer name, license key, and the like. When it's done, a brand-new system is up and running, with a hardware and software installation identical to that of the original.

A nice feature of the new sysprep.exe utility is that it is more forgiving of different hardware than are the sysprep.exe utilities in previous versions of Windows. You can use the switch –bmsd to generate a list of available mass storage devices for sysprep.inf. You can then specify any additional mass storage devices that the mini-setup wizard should attempt to detect.

In addition, a new Factory mode is available. If sysprep.exe is run with the –factory switch, when the system reboots and you log on, it comes up into Factory mode, as shown in Figure 2.6, instead of running the mini-setup wizard. When in this mode, you can perform other operations, such as installing software or drivers, which helps to minimize the number of base images you need to store. You can store a few images to boot to Factory mode; then when it comes time to deploy, you can download the images to a target machine and load the software and drivers for the particular machine type. Finally, you can select the reseal option to run sysprep.exe again to clean up, and the system is then ready to be imaged again, to be deployed en masse.

Figure 2.6. The new system preparation Factory mode provides a means to install additional applications or drivers.

Windows Product Activation

Windows Server 2003 has a new antipiracy feature for ensuring software licensing compliance: Windows product activation. When Windows is installed, you are prompted to enter a license key, which forms the basis for your product ID.

When you activate Windows Server 2003, a hash is created from the existing hardware in your machine. This hardware hash is then used to uniquely identify your machine and is sent to Microsoft, along with your product ID, when you activate Windows Server 2003. This associates the product ID with your specific hardware, thus ensuring that the product license key cannot be used on other hardware.

After Windows Server 2003 is installed, you have a limited time (30 days) before you have to activate the installation. If Windows Server 2003 is not activated within this grace period, it ceases to function. A reminder pops up in the Notification Area until you activate it. Clicking the reminder balloon brings up the Activate Windows screen shown in Figure 2.7.

Figure 2.7. Windows product activation is required only when you're using a retail version of Windows Server 2003.

As you can see, a couple different methods are available for activating Windows. You can activate it immediately by selecting Yes, Let's Activate Windows over the Internet Now. Alternatively, you can call Microsoft to obtain an activation key and manually enter it. If you call Microsoft, you need to provide the installation ID for your system (a 54-character numeric string). You are then given a corresponding 42-character string that you must enter—talk about tedious! Obviously, activating over the Internet is much easier, provided that you have an Internet connection.

After you have activated Windows, if you attempt to install Windows Server 2003 on a different machine, using the same product license key, Windows activation fails. Because you are using the same product license key, you have the same product ID; however, because you are on a different machine, you will have a different hardware hash. When this information is sent to Microsoft during Windows activation, the hardware hash doesn't match, and the activation request is rejected. Upgrading the hardware in an existing machine can potentially cause Windows activation to fail as well. If too much hardware is upgraded, the hardware hash could be different than it was originally. Obviously, valid reasons exist for using the same license on different hardware, such as replacing the existing machine with a newer one. You can still use the product license key in these situations, but you must call Microsoft to obtain an activation key and then use that key to manually activate Windows.

Retail Versus Volume Product Keys

The activation process outlined previously is required for any retail or original equipment manufacturer (OEM) version of Windows Server 2003. The product license keys obtained in retail copies of Windows Server 2003 require activation.

What about volume licenses? Must you activate every installation of Windows Server 2003? For large organizations, this could be particularly troublesome because large corporations usually purchase Microsoft licenses in bulk via one of the volume licensing programs such as Select License or Open License. These programs generally have a single license key for each platform that is used for installation of all the machines for the respective platform. What are these organizations to do? Must they call Microsoft and manually key in the activation key for every installation after the first? Of course not—that would be ridiculous, and the industry would revolt.

If an organization purchases a Select License or an Enterprise License agreement, it obtains a special installation CD that has a setup program coded to automatically enter the Select License key. This special license key does not require activation. If you use this Select License CD, you aren't prompted to enter a product license key during setup, and you also don't have to activate Windows after installation.

Other license programs, such as the Open License agreement, allow you to purchase a single physical software copy with a single product license key, but you are allowed to install it on multiple machines because you have purchased (on paper) the appropriate server licenses. In these cases, a single product license key is used for hundreds, even thousands, of installations. With these license programs, a special volume license key is obtained from Microsoft that bypasses the Windows activation; thus, machines installed with these keys do not require activation.

Windows Server 2003 RIS

As with the other deployment methods, RIS in Windows Server 2003 is similar to RIS in Windows 2000. The major difference has to do with the platforms supported for RIS installations. When Windows 2000 was released, it supported only RIS installations of Windows 2000 Professional. Hot fixes and service packs eventually added support for Windows 2000 Server and Windows XP. Windows Server 2003 RIS supports the installation of all versions of Windows 2000, Windows XP, and Windows Server 2003, except Windows 2000 Datacenter Edition and Windows Server 2003 Datacenter Edition, of course.

Installing RIS

You install RIS in Windows Server 2003 the same as in Windows 2000—by installing it in Add or Remove Programs. As in Windows 2000, installing the RIS Windows component only installs the service components. However, installing the service in Windows Server 2003 does not require a reboot as Windows 2000 does. RIS still needs to be configured separately before it can be used. Unlike in Windows 2000, the configuration of RIS is much more straightforward and easy to find in Windows Server 2003. In Windows 2000, you must find the risetup.exe file to launch the configuration program. In Windows Server 2003, however, a shortcut to risetup.exe appears in the Administrative Tools menu. Running this shortcut creates the initial CD-based image and configures RIS to respond to client requests.

Configuring RIS

In Windows Server 2003 you configure RIS properties in the same place as in Windows 2000—on the Remote Install tab of the Computer object of the RIS server in Active Directory Users and Computers. A Verify Server button appears on the Remote Install tab; this button can be useful in troubleshooting a RIS installation. Clicking this button launches the Check Server Wizard, which runs diagnostics to determine whether any problems exist with the RIS installation on the specified computer. It can also restart RIS and attempt to authorize the RIS server as a DHCP server in Active Directory. You can perform the same diagnostics in Windows Server 2003 by running RIS Setup Properties Wizard. After RIS has been configured, this wizard has a new option labeled Check This Remote Installation for Errors. Selecting this option runs the RIS server diagnostics.

Another button on the Remote Install tab is the Show Clients button. This button runs an Active Directory query to display all the RIS installed clients associated with the specified RIS server. This enables you to see how many clients each server is managing, which helps in load balancing RIS deployments.

Furthermore, in Windows Server 2003 the client RIS experience can be managed with the same group policies as in Windows 2000. The RIS group policy settings determine the options available to the user and the amount of interaction during the setup process, whether the user can restart a previously failed setup, whether the user sees the RIS maintenance and troubleshooting tools, how much the user can interact with the installation, whether the installation is fully automated, whether the user is prompted for anything, and whether the user can customize and change anything.

Automated Deployment Services

Released as a freely downloadable Feature Pack for Windows Server 2003, Automated Deployment Services (ADS) makes it easier for administrators to build and manage very large Windows-based environments. ADS can only be installed on Windows Server 2003, Enterprise Edition. Basically, it provides a new set of imaging tools developed by Microsoft, rather than relying on or encouraging the use of third-party imaging software—something Microsoft has always frowned upon for server deployments. ADS can be used to deploy both Windows Server 2003 and Windows 2000 Server products onto completely unprepared servers, all remotely. ADS is designed to provide more consistent server deployments, which can be a big help in maintaining a more secure environment: Servers can be consistently deployed with a secure initial configuration, reducing the chance that manual configuration errors or inconsistencies will create security vulnerabilities on your servers.

ADS differs significantly from other deployment technologies, such as RIS. RIS uses the same unattended setup techniques that have been present in almost every version of Windows, combined with a network-located, file-based distribution system. In other words, RIS isn't technically all that different from sharing a Windows installation CD over the network and using it to perform installations. RIS's primary contribution is that it works with PXE, allowing new servers to boot from the network and display the RIS installation menu.

ADS, on the other hand, compiles a complete, compact image of the server operating system. This image can be more rapidly deployed to remote servers. Like RIS, ADS supports PXE, allowing brand-new servers that don't contain an operating system to boot from the network and retrieve the correct image.

Note that ADS version 1.0 cannot deploy client operating systems, including Windows 2000 Professional and Windows XP Professional. Microsoft's reasoning for this is that ADS currently doesn't provide a way to save a user's personal information, meaning ADS would overwrite a client machine during an upgrade, making such a deployment scenario undesirable. There isn't any good reason ADS can't be used to deploy Windows XP Professional to a new computer, for example, other than the fact that Microsoft currently doesn't want ADS used in that fashion.

ADS System Requirements

ADS runs as a set of services: Controller, Network Boot, and Image Distribution. These services must run on Pentium-based computers, and Microsoft recommends a minimum processor speed of 1GHz. The host servers must run Windows Server 2003, Enterprise Edition, and each must have at lease one partition with 2GB or more free space in order to install ADS. 256MB of RAM is the recommended minimum. You can remotely administer ADS from any Windows 2000 Server or Professional computer that has Service Pack 3 or later, Windows XP Professional with Service Pack 1 or later, or Windows Server 2003 Standard or Enterprise Edition. The Microsoft .NET Framework, v1.1, is required to run the ADS Sequence Editor. The Sequence Editor allows you to create and manage ADS book sequences, which tell ADS how to service computers that contact it for boot information.

You must have a Microsoft volume license for the operating systems you wish to deploy through ADS; deployment of retail products—which requires retail product keys and Windows product activation—is not supported. ADS can be used to administer devices, provided that the ADS Administration Agent is installed on the device, with all editions of Windows 2000 Server, Windows Server 2003 (except 64-bit editions), and Windows Embedded (based on Windows 2000). Service Pack 3 or higher is required for all Windows 2000 Server operating systems. Each device should have an up-to-date BIOS image, as well, and must contain a PXE-compatible network adapter.

Your network might require some special configuration, as well. All devices on the network must reside in the same multicast domain as the server running the ADS Image Distribution service and in the same domain as the ADS PXE service and your DHCP server. You may need to reconfigure your internal routers to create the necessary multicast domain. Any DHCP server software can be used, and it can be running on the same computer that runs the ADS Controller service. Your DHCP server software must support PXE and multicast scopes; the DHCP server provided with Windows 2000 and Windows Server 2003 meets the requirements.

How ADS Works

In ADS, the term device refers to any ADS-managed computer. In other words, any server that you will deploy images to, capture images from, or otherwise administer through ADS is a device. On the server side, ADS consists of several services:

• Controller— This is the central point of control for ADS. The Controller provides boot instructions for devices and manages image capture and deployment.

• Image Distribution— This service handles communications associated with images, such as sending images to the image repository and sending images from the repository to devices.

• Network Boot— This service—actually, a set of services—provides startup control for devices. Included in the set are the PXE service, the Deployment Agent Builder service, and the Trivial File Transfer Protocol Daemon (TFTPD) service.

• Administration Agent— This service runs on devices and handles communications between the devices and the Controller.

In a nutshell, the Controller service decides what to do when a device boots and takes care of adding new devices to ADS as those devices are discovered. The Controller uses a public/private key pair to encrypt communications between itself and devices. Upon installation, the Controller creates a certificate and saves the public key in a file. You can then share that file on your network to make it available to clients. You can optionally use your existing enterprise public key infrastructure (PKI) if desired.

Because you might want the startup of different devices to be handled differently, the Controller allows you to create job templates. A default template is provided for controlled devices that don't have an assigned template of their own. The Controller identifies devices by either looking at their MAC addresses or their SMBIOS GUIDs (globally unique identifiers); you decide which property identifies a device to ADS. Generally speaking, MAC addresses are the easiest and are guaranteed to be unique across devices. You can also decide how the Controller will respond to a PXE boot request from an unknown device: By default, ADS ignores these devices, but you can have it automatically add the device to its list of managed devices and take whatever action is configured in the default job template.

Job templates, then, become the key to how ADS works. A job is any task that is either running or has completed on a device or a set of devices (referred to as a set). A job can be a script, an executable file, an internal command—including imaging actions—or a task sequence. Job templates, then, provide a way to define jobs that you plan to use more than once.

Here's an example of how it all fits together: Suppose you buy a brand-new server from Bob's Server Shack. The server supports PXE, and you'd like to install Windows Server 2003 on it. You've already created a Windows Server 2003 image in your ADS system. You plug in the new server and turn it on. Because the server doesn't contain an operating system, it can't boot from the hard drive. Most servers try the CD-ROM next, but that's empty, too. Next, the server attempts to boot using PXE, which sends out a broadcast request to your DHCP server.

ADS's PXE service receives the PXE request and queries the Controller for device boot instructions. The PXE service does its job by listening for DHCP discovery messages from devices, and it responds to them by using a DHCP broadcast message that includes a program name and path. The device then downloads that program, which is Startnbs. This program is made available through ADS's TFTPD service, and part of the PXE specification ensures that the server's network card and BIOS have enough embedded smarts to download Startnbs via TFTP. You can think of Startnbs as a kind of micro-operating system, and its next task is to query the PXE service for the Controller's boot instructions. The Controller tells the device to boot to the ADS deployment agent, to boot to a virtual floppy disk, or to exit PXE and boot from the hard disk—depending on what the Controller's default job template says to do.

If you've configured ADS to automatically add new devices (rather than ignore them, which is the default), ADS checks whether this new device has been assigned a job template. It probably hasn't because you just bought the server, so ADS looks to see what the default job template says to do. One of those things could be to start the ADS deployment agent. ADS's Deployment Agent Builder service makes sure a deployment agent is available: The PXE service starts a special program that scans the device's hardware and creates a configuration file. The Deployment Agent Builder service uses this configuration file to create a customized deployment agent that will work on the device and then sends the deployment agent to the device via TFTP.

This customized deployment agent is built by using files from the Windows Server 2003, Enterprise Edition CD. In fact, you can think of the deployment agent as a kind of micro-version of Windows itself, using many of the same device drivers that Windows does to support various types of hardware.

The device loads the agent into a RAM disk and starts it. The deployment agent then takes over the image distribution tasks, communicating with the Controller to retrieve the necessary image. The distribution agent is responsible for initializing the server's disks, transferring images and files, editing the Registry of the device, and replacing strings in configuration text files with appropriate device-specific values.

Images are compressed versions of an entire hard disk partition, including whatever operating system and applications are installed there. The deployment agent is responsible for capturing images from full-installed servers and transmitting those images to the Controller for storage and later deployment. Images should be made from partitions that are small (preferably in the 3GB range), so that they are more manageable. Note that an image can be deployed to a much larger partition, if desired. After getting a “template” server in the exact configuration you want it, you use the Windows sysprep.exe tool. This tool, among other things, prepares the hard drive for imaging. ADS's imaging tools are used to create the actual disk image and transmit it to the ADS Controller via the Image Distribution service. Deployed images start in Windows Mini-Setup mode, which allows for the detection of new hardware that might be different from the hardware installed in the template server.

Upgrading to Windows Server 2003 from Prior Versions

As mentioned previously, you can upgrade existing operating systems by running winnt32.exe. This launches the Setup Wizard, where you are given the choice to perform an upgrade or a fresh installation. Next, you are prompted to accept the license agreement and then enter the license key. The next step is new in Windows Server 2003: You are prompted to connect to the Internet to update the setup files, as shown in Figure 2.8. This downloads the latest setup files and drivers, and it updates the compatibility database.

Figure 2.8. Windows Setup can use Dynamic Update to check for critical product updates prior to installing Windows Server 2003.

Setup then scans your system and compares it to the compatibility database in an attempt to detect any known hardware or software incompatibilities. Before performing any upgrade, you should always verify that the current hardware and software are compatible with the new operating system.

After the compatibility scan, a report is displayed, showing any detected incompatibilities and suggestions about how to correct them, as shown in Figure 2.9.

Figure 2.9. The Windows compatibility report displays any applications or drivers that might not be compatible with Windows Server 2003.

If there are no critical incompatibilities, Setup then copies the setup files from the source location (CD or network) to the system and reboots. The rest of the setup process is virtually identical to that for a fresh installation. It proceeds with the DOS phase of setup and then the GUI phase. The only difference is that, if you chose to upgrade the existing system instead of to do a fresh installation, you aren't prompted for anything because Setup uses the same configuration settings as for the previously installed operating system.

Supported Upgrade Paths

One thing that restricts your choice of whether to do an upgrade or a full installation is the supported upgrade paths. The following are the supported upgrade paths to Windows Server 2003, Standard Edition:

• Windows NT Server 4.0 with Service Pack 5 or later

• Windows NT Server 4.0, Terminal Server Edition with Service Pack 5 or later

• Windows 2000 Server

These are the supported upgrade paths to Windows Server 2003, Enterprise Edition:

• Windows NT Server 4.0 with Service Pack 5 or later

• Windows NT Server 4.0, Terminal Server Edition with Service Pack 5 or later

• Windows NT Server 4.0, Enterprise Edition with Service Pack 5 or later

• Windows 2000 Server

• Windows 2000 Advanced Server

• Windows Server 2003, Standard Edition

The supported upgrade paths can be summed up in a single statement: Any Windows NT 4.0 (with Service Pack 5) or Windows 2000 Server platform can be upgraded to the same platform or better, but downgrades are not allowed.

Operating systems prior to Windows NT 4.0, such as Windows NT 3.51, require an upgrade to one of the previously mentioned operating systems first; then you can upgrade to Windows Server 2003 (or reinstall from scratch, of course).

The easiest upgrade to Windows Server 2003 is from Windows 2000 as the underlying technology and much of the processes are basically the same in the two operating systems.

Although upgrading from Windows 2000 is the smoothest, you need to take special care when upgrading domain controllers. Before you can upgrade Windows 2000 domain controllers or install new Windows Server 2003 domain controllers into an existing Windows 2000 domain, you need to extend the Active Directory schema to support the new Windows Server 2003 domain controllers. You perform this schema extension by running adprep /forestprep, allowing it to replicate, and then running adprpep /domainprep. Does this mean you have to raise the domain functional level to Windows 2000 Native or Windows Server 2003? No. You can still have “down-level” domain controllers. Windows Server 2003 maintains compatibility at the lower functional levels with Windows NT 4.0 domain controllers and Windows 2000 domain controllers.

Whenever possible, we recommend doing a fresh installation rather than an upgrade to ensure that no legacy files or Registry settings are left lying around to potentially cause problems. When you do a fresh installation, you also have the opportunity to reconfigure the underlying hardware, such as hard drive partitions, and even reformat the drives to start clean. The choice of whether to upgrade is usually a matter of logistics and what is possible. Usually, it comes down to how difficult it would be to reinstall the existing applications. An upgrade maintains the installed applications and Registry settings, whereas a fresh installation does not. Sometimes taking down a server and doing a complete reinstallation is simply not feasible. For example, you might have an application whose configuration settings are not completely documented. That, of course, never happens, right? All the configuration settings of every application on every server throughout the entire organization are all completely documented, right? Okay, maybe not. In those cases you might be forced to upgrade.

Mass Upgrades

For mass deployments of fresh installations of Windows Server 2003, the same methods are available as for Windows 2000: RIS, automated installations, or third-party imaging applications. However, to perform mass upgrades of existing systems, your only option is to automate the upgrade by using answer files. You can create an unattended installation file that upgrades the existing operating system; the trick is to kick off the upgrade and specify the answer file. If you have some type of software distribution infrastructure, you can use that to deploy the upgrade package. Alternatively, you can use group policy to deploy the upgrade package.