In this Chapter
With each successive operating system release, Microsoft has traditionally made the installation process more intuitive and easier to perform. In keeping with that tradition, Windows Server 2003 is one of the easiest operating systems to install. Given some adequate hardware and install media, even novice system administrators will be able to build a Windows Server 2003 server with little effort. So, why dedicate a chapter to the subject? Well, in addition to making the install process a simple one, Microsoft has added a variety of ways to install its operating system that provides solutions to a myriad of real world business needs. It is important for the system administrator to be aware of the options available in order to streamline the process for deploying Windows Server 2003.
So, instead of simply providing instructions for installing Windows Server 2003 from the standard installation CD media, this chapter will cover more advanced deployment methods such as automation, customizing installs, licensing, and other best practices.
This first section will detail some tried and true methods used to ensure a successful server deployment. Although this chapter is focused on installing Windows Server 2003, many of the tips provided here can serve as guidelines for any server installation in an enterprise environment.
Essentially, a successful server deployment strategy relies on three major components: planning, testing, and the actual execution or install.
Installing Windows Server 2003 is a fairly easy process, but without a solid plan, administrators might find themselves performing this easy process more than a few times before they get it right. Because there are so many options available when building a server, it is important to plan the installation process beforehand. A good server installation plan includes the following items:
The first step in planning the installation involves verifying the intended target hardware meets the minimum system requirements. Keep in mind that in addition to minimum system requirements, there are recommended system requirements. It is always a best practice to stick with recommended (or better) hardware for servers. Table 11.1 lists the system recommendations for Windows Server 2003 Standard and Enterprise Editions.
Table 11.1. System Requirements
Requirement | Standard Server | Enterprise Server |
|---|---|---|
Minimum CPU Speed | 133MHz | 133MHz for x86-based computer 733MHz for Itanium-based computer |
Recommended CPU Speed | 550MHz | 733MHz |
Minimum RAM | 128MB | 128MB |
Recommended RAM | 256MB | 256MB |
Maximum RAM | 4GB | 32GB for x86-based computer 64GB for Itanium-based computer |
Multiprocessor Support | Up to 4 | Up to 8 |
Disk Space for Setup | 1.5GB | 1.5GB for x86-based computer 2.0GB for Itanium-based computer |
The next step in the planning process is deciding whether to do a clean install or an upgrade. Installing the server from scratch has the benefits of starting with a clean system from which change control can be tightly tracked. You can also take advantage of new hardware with a new installation. Even if the hardware is not new, the operating system will usually be installed on a freshly formatted hard drive, which has the benefit of removing old or possibly corrupt software.
Back Up the Existing Server
If the install will be an upgrade, it is important to back up the existing server. This will provide a fallback plan if the installation fails. It is also important to verify that a backup can be restored.
Creating a Domain Controller
As with Windows 2000, creating a domain controller is accomplished through the promotion of a member server through the DCPromo tool.
Performing an upgrade also has advantages though. By performing an upgrade, existing users, settings, groups, rights, and permissions are kept intact. Depending on the requirements of the installation, preserving these settings might be mandatory and re-creating them on a new server would be an additional burden. Upgrading servers to Windows Server 2003 has its own requirements. These requirements can be found in Part IV, “Migration and Integration Solutions.”
The next planning requirement involves choosing the type of server to install. The new (or upgraded) server can be a domain controller, a member server, or a standalone server. Domain controllers play a role in a new or existing domain, whereas the standalone server is not joined to a domain.
Finally, there are pieces of information that the Windows Server 2003 setup process requires during the installation process that should be determined beforehand. These include the following:
Computer name. Each computer on a network must have a unique name. It is valuable to follow a naming convention that limits server names to 15 characters or less. The characters should match Internet standards, which includes the letters A–Z (upper, and lowercase), the numbers 0–9, and the hyphen (-).
Workgroup or domain name. If the server will be joined to the domain as part of the installation process, provide the domain name; otherwise, the server can be joined at a later time.
Network information. When the server is installed, network information must be supplied in order for it to communicate with other machines on the network. If the TCP/IP protocol is installed, the server should be given a static or dynamic IP address.
Whenever possible, it is important to run through the deployment in a lab environment on non-critical systems. The test lab is an investment that can pay for itself many times over in reduced support and redeployment costs that arise from poorly tested solutions. Always be sure to test the server deployment in an environment that simulates, as well as protects, the production environment. Verify the functionality of the test server by devising and conducting tests that reflect the conditions of the production IT infrastructure.
The following is a list of stages that can be used as a general roadmap for your predeployment testing process. These steps can apply to a large-scale multiserver implementation, just as they can be applied to evaluating application compatibility with Windows Server 2003:
Create a test plan that describes the scope, objectives, and methodology of the proposed change to the environment.
Design test cases that describe how to conduct tests.
Conduct the test and evaluate the results.
Document test results.
Escalate problems to the appropriate groups for resolution.
Throughout the testing stage, the following types of risks to the production environment might be identified and resolved before any business critical systems are affected:
Because most administrators planning to deploy Windows Server 2003 have installed Microsoft server operating systems in the past, it should not be necessary to do a step-by-step instruction here because the setup process has changed very little with this latest OS. Instead, this section will highlight some of the new options, and provide best practices for executing the setup process.
As with previous Windows operating systems, the first step in installing Windows Server 2003 involves creating and formatting the partitions. With Windows Server 2003, there are two additional options added to the familiar FAT or NTFS formatting options, as shown in Figure 11.1.
These two new options enable the administrator to do a quick format as opposed to a true full partition format. It is important to realize that a quick format, which can take up to 25 times faster to complete than a normal format, is only a high-level format of the disk. This means that the format is using tracks that a previous format has defined. Use this option only if the target system did not previously contain confidential information.
The recommended file system to use for Windows Server 2003 is NTFS. NTFS provides support for volumes as large as 16 terabytes (minus 4KB), with maximum file sizes of 16TB (minus 64KB). NTFS also provides file security, disk compression, encryption, and fault-tolerant disk configurations. The only scenarios in which the server should be installed on a FAT partition are the following:
The remainder of the Windows Server 2003 setup process will be pretty familiar. The installer will be prompted for computer name, administrator password, date and time settings, and networking information. If the deployment process was well planned, these pieces of information should be readily available during the actual installation.
The only other piece of the install puzzle that might be new to you is the licensing and activation process. This topic will be covered in the next section.
As with earlier versions of Microsoft operating systems, the installation of a Windows Server 2003 server requires a product license key. The product key that is entered as part of the server installation depends on the type of license purchased. Depending on the type of license purchased, there might also be a process by which the operating system software must be activated in order to continue working past a grace period. This section will provide some help in determining licensing modes and activating Windows Server 2003.
For those who have installed a Windows 2000 server product, the product key is a familiar concept. Usually found on a label stuck to the back of retail CD media, the product key is a unique combination of numbers and letters that is used during the product installation to “unlock” or open the product.
There are two types of keys that can be used during the installation process:
Retail Media Activation Key. If the operating system software is purchased by a retail source, each key is unique to that specific installation of Windows Server 2003. Using this type of key will require the installer to activate the product after each installation.
Volume Licensing Activation Key. If the operating system is purchased as part of a Microsoft volume licensing program (such as Open, Select, or Subscription), a single key can be used to unlock all installations. Using this method also satisfies the activation requirement.
As with Windows NT and 2000, Windows Server 2003 can be licensed in either a Per Server or Per Device mode.
Choosing Per Server mode essentially means that the server will need to have enough client access licenses (CALs) purchased to support the maximum number of concurrent client connections to the server. If the number of concurrent connections exceeds the number of configured CALs, clients might be denied access to the server’s resources. Choose Per Server mode for small organizations that only have a single server. This mode also makes sense for Web and Remote Access Service (RAS) servers where the maximum number of concurrent connections is configured. By setting the maximum number of concurrent connections, the licensing mode can be maintained.
Choose Per Server
If it is not clear which licensing mode to choose at the time of installation, choose Per Server. The licensing mode can be changed at a later time from Per Server to Per Device, but cannot be changed from Per Device to Per Server.
Choosing Per Device mode, on the other hand, means that a CAL is required for each client machine that accesses any licensed server. In this scenario, the licensed client machines are allowed to access any server within a Windows network. This is the common licensing mode because most companies have more than one server. A CAL is more costly than a Per Server license, but the client license buys access to an unlimited number of servers.
If you install Windows Server 2003 from a retail media source, the operating system will need to be activated. Product activation takes place after the operating system is installed. The activation process can be initiated by either clicking the icon in the system tray that looks like a pair of keys, or by choosing Activate Windows from the Programs folder.
Windows Server 2003 can be activated over the Internet or by telephone. To activate over the Internet, select that option, and then click Next. An option to register the product with Microsoft is then provided. This step is optional and not required to activate the product. If the installer chooses to register at this time, the Collecting Registration Data screen will appear, as shown in Figure 11.2.
Fill out the required information and then click Next to continue. After connectivity to the Internet is verified, a window confirming the product activation is displayed. Click OK to finalize the process.
To activate Windows Server 2003 by telephone, select the option that reads: Yes, I Want to Telephone a Customer Service Representative to Activate Windows. Click Next to continue.
The wizard then generates a new installation and the Activate Windows screen shown in Figure 11.3 appears.
Providing a location exposes a phone number to call. After the customer representative is reached by phone, provide her with the new installation ID on the screen. The representative will then give a confirmation ID that can be entered in step 4. Entering the confirmation ID concludes the activation process.
For those who have worked with Windows 2000 networks, Remote Installation Service (RIS) is a familiar Windows component used for creating and deploying on-demand desktop images. Though the desktop deployment features are still included, Windows Server 2003 now extends the functionality of RIS to include the ability to create on-demand server images for all versions of Windows 2000 and 32-bit versions of the Windows Server 2003 operating system.
The primary benefits of using RIS for building Windows Server 2003 servers include the following:
Rapid deployment of multiple servers. If an enterprise needs to deploy multiple servers that have similar hardware and software specifications, RIS can accelerate the deployment process that used to involve a manual install of one server at a time.
Rapid recovery of mission critical servers. If a server is lost due to disaster, a RIS image of that lost server can be used to quickly build a replacement.
Standardization of servers. For a company that manages many servers, having standard RIS server images in line with company policies and specifications takes the guesswork out of server configurations deployed across the enterprise.
To take advantage of RIS, there are certain hardware and software system requirements that must be met. The following list describes the hardware requirements for building a RIS server:
The server hardware must meet minimum requirements for the product version of the Windows Server 2003 family that is being imaged. For example, if you are installing Windows Server 2003, Enterprise Edition, your computer must meet the minimum requirements for this product.
A minimum of 4GB of disk space is required for the RIS server folder tree. Because RIS images take up a great deal of space, it is recommended to dedicate an entire partition to the RIS folder tree.
A 10 or 100Mb/sec Windows-compatible network adapter that supports TCP/IP (100Mb/sec recommended) is required. A RIS server cannot be a multihomed computer; that is, it can contain only one network adapter.
For the machine that will serve as the template, in other words, the machine from which an image will be taken, there are a couple of hardware requirements as well:
To Obtain a List of Network Adapters that RIS Supports...
run the Rbfg.exe utility that is installed with Remote Installation Service. This file can be found in \server-name eminstadmin i386 bfg.exe.
The networking environment in which you install a RIS server must meet a few requirements as well. These requirements are listed here:
There must be a DHCP server in the environment to assign addresses to machines being imaged. DHCP is also used to identify which RIS servers are available on the network.
A DNS server is necessary in order to locate the directory service that will authenticate the client machines.
Active Directory is required to set security parameters around the RIS process. Specifically, AD will restrict or control which RIS servers will respond to specific client requests for operating systems.
Finally, some additional considerations that are more software-based are needed when planning to use RIS. These include the following:
RIS cannot be installed on the same partition as the system volume or boot volume.
The volume on which RIS is installed must be formatted with NTFS.
RIS does not support Encrypting File System (EFS).
A Distributed File System (DFS) share cannot be used as a target for a RIS image. RIS can be installed, though, on a server running DFS.
Although there seems to be a rather long list of prerequisites to using RIS, most Windows Server 2003 environments will have all of the elements mentioned previously present already. As such, most companies would be able to add this service to their infrastructure quite easily with a single additional server with a good size data partition.
There are two types of operating system images that can be used with RIS. The first type is a flat image, which is similar to using a CD install, only the installation files are located on a RIS server. The benefit of using a flat image type is that RIS supports flat images for all Windows 2000, XP, and Windows Server 2003 editions, including 64-bit editions.
Riprep Images Cannot Be Used for 64-Bit Versions of Windows Server 2003
RIPrep images cannot be used for 64-bit versions of Windows Server 2003 and cannot be used to create images of Windows 2000 if Internet Information Server (IIS) is installed.
The second type of RIS image is a Remote Installation Preparation Wizard (RIPrep) image. The RIPrep image type enables you to add application installations and other customizations to the image. RIPrep also uses the Plug and Play feature; therefore computers targeted with these images do not have to be exactly the same, though they do need to share the same Hardware Abstraction Layer (HAL). Because of this flexibility to customize the image, the RIPrep image has the most practical utility for most companies.
The remainder of this section will detail the process by which a RIPrep image is created. To install a RIPrep image of a Windows Server 2003, perform the following steps:
Install Windows Server 2003 on a computer that you will use to create the installation image. The operating system can be installed using either Remote Installation Services (RIS) or the product CD. Using RIS to do the install is the recommended practice.
Install any additional applications and modify the local configuration settings of the source Windows Server 2003 computer.
From the Run line, type the Universal Naming Convention (UNC) path of the RIPrep utility on the RIS server, for example: \ServernameRIS eminstRiprep.exe, and then click OK.
Click Next at the Remote Installation Preparation Wizard welcome screen.
Type the name of the server to which the image will be copied, and then click Next. By default, this is the RIS server you typed in step 3.
Type the name of the folder to which to which the image will be copied, and then click Next.
Type the friendly description and the Help text, and then click Next. This information is displayed by the Client Installation Wizard when RIS clients request network services.
Click Next two more times to initiate the replication of the source machine image to the RIS server.
Multiple Profiles on the Source Machine
At this point, a screen might appear indicating multiple profiles on the source machine, or services that are still running that should be stopped. See Figure 11.4 for an example of this screen. It is recommended to stop these services before proceeding.
Installer Must Be An Administrator
To run the RIPrep utility, the installer must be an administrator on the source machine and have permission to write to the RIS server data folder.
When the replication process completes, the source server will shut down.
When the source server starts up again, it will run a mini-setup.
RIS in Windows Server 2003 provides functionality for securing the imaging process of servers and desktops. RIS has an authorization feature that will prevent unauthorized RIS servers from making images available on an Active Directory network.
RIS can be used to specify which RIS servers can accept and process requests, and which RIS servers can only service clients on the network. Before a RIS server can accept requests, it must be authorized to run in Active Directory. To authorize a RIS server in Active Directory, run RISETUP –Check.
RIS also offers the capability to individually secure particular images. Using this feature allows flexibility on who is able to install the various images from the RIS server. For example, to limit access to install a Windows Server 2003 image from a RIS server to the Domain Admins group, the Authenticated Users group should be removed from the permissions on that particular image.
RIS is a valuable deployment tool for companies that use it correctly. To gain the efficiency, security, and disaster recovery benefits of using RIS, consider the following best practices in designing and maintaining an enterprise RIS solution:
Use the security features of RIS. Take advantage of both authorizing RIS servers in Active Directory and restricting access to RIPrep images. The PXE architecture on which RIS relies is inherently insecure. Without the RIS safeguards in place, there is little stopping a malicious user with a PXE-enabled network card from pulling images from a RIS server on the network. This is especially important with server images. Likewise, an intruder could set up a rogue RIS server that can interfere with a company’s deployment plans.
Install RIS servers appropriate to your network topology. For a small company located in a single subnet, a single RIS server can serve all PXE-related deployment needs. For distributed companies with sites connected over slow links, it makes sense to include RIS servers at the remote sites. Do not use RIS to deploy images over slow links.
Install RIS on a physical disk separate from the disk that houses the operating system. Giving RIS its own physical hard drive will ensure optimal performance.
Choose to create RIPrep images over RISetup flat images if capturing application installation and customizations in the image is desired. RIPrep can accommodate some differences in the hardware because it utilizes Plug and Play. Using RISetup with a scripted install can enable you to install to hardware that have different HALs.
If your servers do not use PXE-enabled network cards, create boot disks using the rbfg.exe utility. The boot disks can be customized to access your RIS server images.
Another method of creating images for the deployment of Windows Server 2003 involves using the System Preparation tool or Sysprep. Sysprep is very similar to RIPrep in that it is an image preparation tool. Unlike RIPrep, though, Sysprep does not take advantage of RIS server management or deployment. Sysprep is used for standalone image preparation. After a Sysprep image is created from a template system, one of several third-party applications can be used to capture the image to a file for redeployment to other systems.
Sysprep was introduced with Windows 2000 with a purely command line interface intended for desktop image creation. Many updates were made to Sysprep when Windows XP was introduced, including a wizard-based setup manager, but it was still primarily a tool designed for preparing images for desktops. With Windows Server 2003, Microsoft has made Sysprep a supportable method for preparing server-based disk images.
As mentioned earlier, Sysprep is very similar to RIPrep. For example, both image types can include applications that might have already been installed on the image system, and the images can be customized before and after deployment of the image. Also, both image types require the same HAL for target systems. It follows from these similarities that the steps necessary to prepare a Sysprep server image are similar to creating a RIPrep server image. The following steps outline the process:
A template system is prepared by installing the operating system, installing applications, and customizing settings according to company specifications.
Sysprep is run on the computer, which then powers off.
Using a third-party tool, an image of the Sysprepped system is copied to a file server.
A new system is booted using a third-party tool, and the image is installed.
The new system is started and a mini-setup runs. The mini-setup is a pared down version of the full Windows setup.
The new system reboots and is ready to go.
HAL
HAL must be the same on the source and target systems for Sysprep to function. This is especially true when it comes to ACPI and non-ACPI computers. ACPI images cannot be deployed on non-ACPI systems, and non-ACPI images cannot be installed on ACPI systems.
There are some key differences between this process and the RIPrep process of which deployment administrators should be aware:
Sysprep images cannot be deployed or managed with a RIS server. There are several third-party tools that can be used to capture the image. Xcopy can even be used to copy the system to a network share.
Because RIS is not involved, Active Directory is not required. Sysprep can be used to create Windows Server 2003 images in an environment that does not have AD.
A mini-setup is run when the newly imaged system is powered on. The mini-setup only prompts for information necessary to make the installation unique again, such as computer name, network configuration, or domain membership. The mini-setup can be completely automated by creating an .inf answer file. With RIPrep, there is a longer setup process for RIS imaged systems.
In addition to enabling Sysprep to support server images, Microsoft has further enhanced the tool for Windows Server 2003.
The new Sysprep can image a fully configured server with Internet Information Server (IIS) installed. For companies that support several Web servers, this would be a key deployment option.
Sysprep has a new mode of operation called Factory. By running Sysprep with a -factory switch, updated or out-of-the box drivers will be picked up by the image before the system is fully set up.
In conjunction with the Factory mode of operation, Sysprep can include an answer file, winbom.ini, that goes beyond driver installation and can actually gather and install applications from a network share at install time. This feature enables you to use a smaller image for deployment, with applications installing automatically from the network.
Finally, the -PnP switch commonly used with Windows 2000 systems is no longer necessary. Because the Plug and Play functionality in Windows XP and Windows Server 2003 is dramatically improved, getting an image to work on systems with different hardware components is a lot easier.
Another tried and true method for automating the deployment of Windows operating systems is the use of the unattend.txt answer file. An answer file is simply a text file that answers the questions one would normally have to enter manually during the installation process. In this way, unattend.txt is like sysprep.inf. The unattend.txt is the answer file for the setup.exe file of Windows operating systems, including Windows Server 2003.
Answer File Name
Although the answer file for Setup is commonly called Unattend.txt, for a network preinstallation the filename can be whatever you choose. For a CD-based Setup, the answer file must be named Winnt.sif.
Unattend.txt can be created and modified by using a text editor, or by using Setup Manager. Setup Manager is also the tool used to create sysprep.inf files and RIS-based answer files. The Setup Manager tool can be found on the Windows Server 2003 CD in the Support oolsdeploy.cab file.
The Setup Manager that ships with Windows Server 2003 has been enhanced with a cleaner GUI that helps you build answer files easier and faster than previous versions.
One primary improvement in Setup Manager for Windows Server 2003 is the ability to encrypt the local administrator password. With this feature, an unattend.txt file can be placed on a network share, with little concern for giving away the administrator password on all the machines that were used to install them. The password is fully encrypted, which prevents those machines from having a publicly available administrator password.
Because unattend.txt is just a text file, it is easy to modify to meet different requirements. This is very helpful when automating installs to different hardware platforms.
There are a variety of configurable options that can be included in an answer file. To build a fully automated install of Windows Server 2003 using an unattend.txt answer file, the following sections of the file must be completed:
[GUIUnattended]—. This section must include the completed AdminPassword and Timezone entries.
[Identification]—. This section requires either JoinWorkgroup or JoinDomain.
[LicenseFilePrintData]—. This section requires the AutoMode entry that handles Per User or Per Server licensing. It also requires the AutoUsers entry if Per Server licensing is chosen.
[Networking]—. This section is required if you want to configure networking as part of the install. If static TCP/IP addresses are to be used, this is a section that will likely be modified with a text editor on a per server basis.
[Unattended]—. This section requires the unattendmode value be set to FullyUnattended. This section also requires a TargetPath for the installation.
[Userdata]—. This section requires ComputerName and FullName. If ComputerName is set to *, a random name will be generated based on the specified Organization name.
Because it is a wizard-based tool, Setup Manager is easy to use to create an answer file for a fully automated installation of Windows Server 2003. The wizard will prompt for entries necessary to automate an install from a specified distribution point. The first two sections shown in Figure 11.5 outline the requirements for a fully automated installation.
Another method for automating server installations of Windows Server 2003 is by building custom bootable CDs. By combining some of the other methods described in the previous sections, you are able to distribute via CD or DVD media a fully automated customized installation of the operating system.
The benefit of doing a CD-based install is the same as doing an unattended install except there is not the requirement for a network share to play the role of a centralized deployment point. You have the capability to customize the install so that it will work on different hardware platforms. It will also allow for the execution of scripts or installations through the GUIRunOnce parameters or cmdlines.txt
There are several third-party tools available that can be used to build the custom CD for a server install. You can leverage the answer files created with System Manager, and then use a third-party tool to capture the prepared image. The prepared image and answer files can then be copied to CD or DVD. Third-party tools can then be used to make the CD bootable, and autostart the customized installation.
Additionally, the tools required to create a bootable ISO image, which is the image that would be copied to a CD, are available in Windows Preinstallation Environment, or WinPE for short.
WinPE is a bare bones operating system, based on the Windows XP kernel, that provides the functionality required to automate Windows Setup. In essence, WinPE replaces the MS-DOS and Windows 95 boot environments administrators are familiar with using to make their bootable CDs in the past. WinPE has the advantage of being able to access NTFS file systems and network environments, and supports all mass storage devices that use Windows 2000, XP, or Windows Server 2003 drivers.
Leveraging WinPE
A big advantage of leveraging WinPE is the creation of automated multi-partition server installations.
WinPE is designed to be hardware-independent. The idea here is that a WinPE CD will boot on any system and then perform a scripted install. To do this, the first step would be to prepare the system volume on the new hardware. The Diskpart and Format tools that seasoned administrators will be familiar with are also included in WinPE. Diskpart is extremely valuable for server installs because it enables you to script a multipartitioned installation on the target hardware. The Format utility, which is also scriptable, allows for a fast format of the drives. After these two steps have completed, the scripted install proceeds from the CD media in this case, but can also reference a RIS server or other network share for the source files.
After the operating system is installed, Windows Server 2003 can begin to take on the responsibilities for which it was designed. To get the most out of the new server, though, it is a best practice to confirm that everything is operating as expected. Running through a post-deployment checklist to make sure performance and security settings are in place will ensure the new system can reliably support its intended functionality. This section provides common recommendations for confirming and configuring optimal baseline settings in Windows Server 2003.
After setup has completed, log in to the new server with an administrator account, and perform the following routines to confirm the system is performing at an expected level:
Review events in the Event Viewer. Pay special attention to the System log in Event Viewer to determine if there were any errors associated with the installation, or if any startup services failed to start.
Set the Event Viewer log size and wrap setting. Set the log sizes appropriately depending on the type and severity of events logged. For example, increase the Security log if you will need to view a large number of security events. Also, set an overwrite setting that meets with security requirements. The default setting is for the log to overwrite when the maximum log size is reached.
Adjust Server Optimization. Adjust the server optimization setting to correspond with the role the new server will play in the organization. Server roles are discussed in the section, “Customizing Servers with Setup Wizards,” later in this chapter.
To configure memory-related settings in Windows Server 2003, perform the following steps:
Open Network Connections from the Control Panel.
Right-click Local Area Connection, and choose Properties.
Under This Connection Uses the Following Items:, double-click File and Printer Sharing for Microsoft Networks.
Under Optimization, notice that Maximize Data Throughput for File is selected. To turn this option off to reduce paging activity, click Maximize Data Throughput for Network. Some of the setting options that need to be reviewed and updated include the following:
Verify Network settings. The quickest way to do this is to open a command prompt, and type ipconfig /all. Make sure the IP, DNS, WINS, and default gateway information is correct.
Verify full computer name. The quickest way to perform this check is to open a command prompt, and type net config rdr. Compare the full computer name to the Active Directory name and make sure they match.
Set the pagefile size. Set the size and placement of the pagefile based on the memory size and server usage. It is recommended that the same value be set for both the minimum and maximum pagefile size. This keeps the file size static.
Set the options for how the operating system behaves in the event of an unexpected stop. For example, to configure Windows Server 2003 to send an alert to an administrator in the event of an unexpected stop, perform the following:
Open System from the Control Panel.
On the Advanced tab, under Startup and Recovery, click Settings.
Under System Failure, check the box next to Send an Administrative Alert, as shown in Figure 11.6.
Click OK twice, to finalize the setting.
Configure for Remote Administration. If the server will be managed remotely, specify settings for making the server available for remote administration. Remote administration is detailed in Chapter 8, “Administering Windows Server 2003 Remotely.”
In addition to basic performance settings, it is important to verify the proper security settings are in place after a new server is deployed in the IT environment. The security settings enforced on a particular server will depend on the role that server plays in the environment and on company security policies. Security solutions are detailed in Part I “Microsoft Exchange Server 2003 Overview” of this book. The following are recommendations that can apply to any server implementation:
Change the local administrator account name. This account can also be disabled. In either case, it will make it a bit more difficult for the server to be compromised. The guest account should also be renamed or disabled.
Review open network ports. Use either the netstat command or an external port scanner to determine if any unnecessary ports are open. Because an open port is a potential access point for an attacker, close any open ports that are not needed for the server to perform properly.
Set up auditing, and install virus scanning software. Auditing security events help track changes made to the system and help to prevent unwanted changes to the new server. The importance of protecting the server from a virus attack goes without saying.
Finally, after the server is configured to the desired specification, it is important to set up a backup routine and install the Recovery Console. Backups can be performed using the NTBackup utility provided with Windows Server 2003, or any number of third-party tools might be employed. It is also a good practice to simulate recovery procedures from time to time to confirm that the backups are really working.
To install the Recovery Console as a Startup Option for Windows Server 2003, perform the following steps:
As with Windows 2000, Windows Server 2003 takes some of the manual step out of customizing the server to perform common roles within the organization. By using the Configure Your Server Wizard, and the Manage Your Server utility, you can add/remove and customize a Windows Server 2003 server based on previously defined roles. This section will describe how to customize a server to support common roles in a Windows network environment.
Windows Server 2003 provides several roles for which the server can be configured with the Configure Your Server Wizard. Although the roles available through the wizard are mostly the same as were available in the Windows 2000 server family, the GUI interface looks a bit different. Figure 11.7 displays the list of server roles available in Windows Server 2003.
The wizard automatically starts when you log in for the first time after the setup process is complete, and the wizard can be started from the Administrative Tools program group.
When a particular role is chosen in the Configure Your Server Wizard, the appropriate files and services are installed to satisfy that role. For example, if an administrator chooses to configure the Application Server role, the wizard will install IIS, as well as COM+ and ASP.NET, automatically. The wizard will then offer to install FrontPage extensions and enable ASP.NET.
Of course, you still have the capability to install these services and components individually through the Add or Remove Components applet in the Control Panel. The wizard simply streamlines the process. The Configure Your Server Wizard can also be used to remove roles from a previously configured server.
After the Configure Your Server Wizard completes (depending on the role installed, this often includes a reboot), the Manage Your Server utility will automatically start allowing the administrator to further customize the server based on the new role(s) installed.
There are a few important items to be aware of when assigning server roles to Windows Server 2003:
When installing the Terminal Server role, you must ensure that there is a licensing server available on the Windows network to handle Terminal Server licensing. If there is no Terminal Server licensing server available on the network, the new Terminal Server will stop accepting connections after 120 days.
The Domain Controller role cannot be installed on a server that is a Certification Authority (CA). If the server is already a CA, the Domain Controller role is not an available option in the Configure Your Server Wizard.
If the DNS server role will be installed, it is important to choose a unique registered domain name if the DNS server will store records for computers that exist on the Internet. DNS configuration is detailed in Chapter 13, “Infrastructure Integration (DNS, DHCP, Domain Controllers).”
When the Configure Your Server Wizard completes, the Manage Your Server utility launches automatically. This utility can also be found under the Administrative Tools program group. The Manage Your Server utility will display all the roles configured for the particular server. For each role, the utility will provide a list of specific actions appropriate for administering the functionality available to that role.
For example, if the server is configured with a Domain Controller role, the Manage Your Server utility will present options for executing the following management tools:
Active Directory Users and Computers
Active Directory Domains and Trusts
Active Directory Sites and Services
If a particular role requires additional configuration, the Manage Your Server utility also provides a link to a help file that includes next steps. For example, for the File Server role, the next steps include information for configuring EFS, setting disk quotas, or installing the indexing service.
Because much of this chapter has been devoted to customizations related to installing the Windows Server 2003 operating system, it seems appropriate to end with a discussion of that component through which Windows operating systems can be customized to the greatest degree. That component is of course the Registry. The Windows Registry has been around since Windows 95. It is the database containing hardware, operating system, policy, file association, application, and user configuration.
Rather than going into a detailed account of the Registry’s architecture, this section focuses on best practices for using the Registry to secure and maintain the newly installed Windows Server 2003 server.
In earlier versions of Windows, Registry editing was conducted through two different but similar tools: Regedit.exe and Regedt32.exe. Each tool could do some of the tasks involved in making Registry configuration changes, but one could not be used to the exclusion of the other. With Windows XP and Windows Server 2003, Microsoft has consolidated the features of the two tools into a single Registry Editor that has the look and feel of the old Regedit.exe but includes the security and remote access features of Regedt32.exe. Interestingly, both commands still exist in Windows Server 2003, but they each launch the same utility.
It is important when a new Windows Server 2003 server is built to verify that it meets or exceeds the security policies for the company. Because the Registry is a critical component of a server’s capacity to perform, securing the server’s Registry should be a part of that process.
The default security for the Windows Server 2003 Registry has improved over earlier Windows operating systems. There are sections of the Registry that are even locked down for administrators. For example, the HKEY_LOCAL_MACHINESAM and HKEY_LOCAL_MACHINESECURITY keys allow only read and write DAC access to administrators.
Some best practices for protecting the Registry include the following:
Audit the Registry. An audit log of changes made to the Registry can be a crucial tool in troubleshooting, as well as uncovering security breaches. Auditing can be enabled either through group policy or local security settings.
Prevent Remote Access. In some cases, it might be wise to limit or prevent remote access to a server’s Registry. To do this, simply change the permissions on the following key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurePipeServerswinreg.
Include the Registry in backups. As part of a disaster recovery procedure, in addition to backing up files and folders, always back up a server’s Registry. Using the built-in backup utility, NTBACKUP.EXE, the Registry can be backed up by simply including the System State Data option.
Though Windows Server 2003 automatically performs maintenance on the Registry, there are some tools and best practices related to the Registry that help improve performance:
Manage the Registry size. In earlier Windows operating systems, administrators had the option to limit the size of the Registry. Because Windows Server 2003 manages the Registry in the computer cache rather than in paged, pooled memory, administrators no longer need to specify a Registry size. It is recommended, though, to provide an adequate amount of free space on the system partition. There should always be 25% free space at all times.
Use the Windows Installer Cleanup Utility (MSICUU.EXE). This utility is installed with the Windows Server 2003 Support Tools. It can be used to remove Registry entries from applications installed with Windows Installer. This tool is useful in repairing a server’s Registry after a failed or corrupted Windows Installer installation.
Use Windows Installer Zapper (MSIZAP.EXE). This is the command-line version of MSICUU.EXE, which includes more features than the GUI version. For instance, MSIZAP can remove folders in addition to Registry entries. It can also be used to change access control list (ACL) permissions and remove rollback information.
As this chapter demonstrates, Although the installation of Windows Server 2003 can be a simple process, there are many customization and automation features available to administrators. Proper planning and testing are key to a successful implementation. After these steps have been accomplished, the speed, reliability, and security of the installation process will enable organizations to rapidly deploy and maintain new Windows servers in small or global IT environments.