Automating Client Installation and Upgrade

Using Remote Operating System Installation

Remote Operating System Installation is an optional component included with Windows 2000 Server and is based on Remote Installation Services (RIS) technology. Because RIS uses Pre-Boot eXecution Environment (PXE)-based remote-boot technology and server-based software, you can remotely install an image of Windows 2000 Professional on supported computers, eliminating the need to physically visit each computer to perform an installation. You must ensure that the hardware for each computer is compatible and that a bootable network adapter is installed. You can set up a different RIS image for each configuration specific to a group of computers. During Setup, a list of installation choices are provided that can be limited according to the policies set for that particular user or group. There might be as many RIS images to maintain as there are different sets of group policies. In this case, it would be beneficial if only the installation choices common to all configurations were installed by this method.

For more information about Remote Operating System Installation, see "Applying Change and Configuration Management"in this book, and see "Remote OS Installation" in the Microsoft® Windows® 2000 Server Resource Kit Distributed Systems Guide.

RIS Server Network Load Implications

Because a RIS server is used to install operating system images on client computers, the amount of traffic the server produces is similar to that of other servers performing as software installation points on your network. Generally, the traffic from RIS servers is more predictable than traffic from a general-purpose software installation point that provides applications and regular updates. RIS-generated traffic is higher when many users are loading images — for example, during a new deployment of operating system images or when a group of new computers is added to the network. After systems are installed, daily traffic is going to be lower.

As a general rule, place a RIS server near the client computers that it services. This will localize the resulting network traffic and reduce its impact.

If your environment requires either of the following processes, make sure that these processes can be optimized without affecting other applications:

Frequent reinstallation of systems, as in a classroom.
Regular installation of a large number of systems, as in preinstallation of all new systems before delivering them to users.

For the classroom example, consider segmenting the physical network and providing a dedicated RIS server for each classroom or set of classrooms that your RIS server hardware can support.

For the preinstallation example, consider implementing preinstallation labs where computers can be processed in volume by using high-speed networking and RIS server hardware to reduce installation time.

Optimizing Performance

Because Remote Operating System Installation is primarily a file-copy process, the common RIS server performance factors are similar to those of other file input/output (I/O) intensive servers such as Web servers and file and print servers. These factors include server disk throughput and network bandwidth. When optimizing performance of your RIS servers, evaluate these factors and other constraints that might exist on the network between RIS servers and the clients that are being serviced. When a RIS server or its network connection is overloaded, the result is increased installation time for client computers and TFTP time-outs during the initial file-copy phase.

DHCP and DHCP Servers

Because Remote Operating System Installation (PXE-enabled) clients use the DHCP discovery mechanism to obtain a network address and to locate RIS servers, the relationship of RIS to DHCP in your organization plays a key role in determining your RIS server placement strategy.

In simple environments, adding RIS to each DHCP server in use is a common solution. When a combination Windows 2000 DHCP/RIS server approach is used, the number of initial network packets sent between the RIS client and the DHCP and RIS servers is reduced, and the initial server response is faster. In addition, a combination Windows 2000 DHCP/RIS server always answers a client together. This provides a simple form of load balancing by taking advantage of any existing planning that groups client computers to DHCP servers, and it also simplifies troubleshooting and administrative procedures.

Although RIS servers must be located close to client computers and can generate large network loads, often requiring these servers to have high-end hardware, DHCP servers are just the opposite. DHCP servers generate far less traffic, do not typically require high-end server hardware, and are sometimes centralized rather than close to client computers. Therefore, you might find that simply adding RIS to your existing DHCP servers is impractical. In such cases, you might want to add RIS services to existing software installation point servers because they have similar planning and placement requirements as RIS servers, or you might want to make your RIS servers independent of other supporting servers.

When RIS servers are separate from DHCP servers, or when non-Windows 2000 DHCP servers are in use, controlling which RIS servers answer specific clients becomes a primary consideration. This is because the PXE-based remote boot process does not provide a way to determine from which server a client is going to receive service. For information about methods for controlling this process, see "Controlling RIS Server Selection and Balancing Load" later in this chapter.

Regardless of the approach that you take to combine DHCP and RIS servers, every RIS server must be authorized in Active Directory as a method of preventing unauthorized servers from servicing clients on the network. The authorization process for both RIS and Windows 2000 DHCP servers takes place through the Windows 2000 DHCP snap-in in Microsoft Management Console (MMC). The process has no direct relation either to combining or separating RIS and DHCP servers or with using Windows 2000 DHCP. The Windows 2000 DHCP snap-in is simply reused as an authenticating mechanism and can be run without installing the DHCP service on any Windows 2000–based computer that has the Administrator Tools pack installed.

Caution

Do not attempt to install Windows 2000 DHCP on a RIS server simply to obtain the snap-in. To service RIS clients, any combined Windows 2000 DHCP and RIS server must have a fully functional DHCP service (including defined and active scopes). This is because the Windows 2000 DHCP service on a combined server is aware that RIS is also installed. If a client indicates that it requires both DHCP and remote boot services in its DHCP discovery broadcast, DHCP will issue a single reply containing the specific details on DHCP and remote boot for that server. If the Windows 2000 DHCP service on the server is not properly answering clients, that server will not generate a remote boot reply.

Controlling RIS Server Selection and Balancing Load

By default, when a PXE-based client broadcasts its request for service, all servers that receive the request will reply. The first server to respond is the one that provides service; preference is given to responses from combined DHCP/RIS servers over responses from separate servers. Although this provides fundamental load balancing when multiple servers are available to clients in order to prevent clients from using improper servers, it is often best to restrict which servers can answer specific clients. An example is a server that is local to the client and is busy or down when the client requests service.

The first way to control server selection is to physically control network routing so that DHCP discovery broadcasts are forwarded only when it is appropriate. This physically allows answers by only those DHCP/RIS servers that are permitted to receive the client service requests. If your DHCP/RIS servers are in similar locations on the network in relation to clients, this might be all that is necessary.

To accommodate a variety of scenarios, Remote Operating System Installation provides additional features for controlling server selection. These features involve configuring client computer accounts within Active Directory to use a specific RIS server, which is a process known as "prestaging." Prestaging can be performed on existing computer accounts, as well as when creating new computer accounts before the system joins the domain. When a RIS server answers a service request from a client, the server checks Active Directory (the entire forest) for the existence of a computer account with a globally unique identifier (GUID) that matches the GUID that is included in the service request. If a matching computer account is found, the account is also checked to see whether it has been configured to use a specific RIS server. If so, the RIS server specified in the computer account is always supplied in the reply to the client, even if it is a different server from the one providing the initial reply to the client. This is known as a server referral and provides a simple way to control which RIS servers end up providing operating system installation services to specific client computers, regardless of which particular RIS server replied to the initial request for service from the client.

To allow additional flexibility and security, the prestaging and referral concepts can also be combined with RIS server settings that control how servers respond to clients. Each RIS server has two settings: "Respond to client computers requesting service" and "Do not respond to unknown client computers." By prestaging all computer accounts and selectively controlling which RIS servers are configured to respond to clients, servers can become dedicated to either replying to client service requests and providing the appropriate referrals, or to providing the actual Remote OS Installation services to clients.

Figure 25.3 illustrates an example of how client computers can relate to RIS servers.

Enlarge figure

Figure 25.3 Example of How Client Computers Relate to RIS Servers

In Figure 25.3, only server B will reply to client computers that request service. Because client computers 1 and 3 have been prestaged and configured to obtain service from a specific RIS server, they will receive a reply that refers them to the appropriate server (A or C). If it is appropriate, multiple dedicated referral servers such as server B can be established, all of which will use the prestaged computer accounts in Active Directory to determine the proper referral to make. Servers A and C will never reply to initial client service requests; but through referrals, the servers provide the actual operating system installation services to clients.

You can then determine whether the "Do not respond to unknown client computers" configuration option needs to be selected on referral servers such as server B. Selecting this option ensures that:

Server B sends replies only to client computers that have been prestaged.
If any clients are configured to receive service specifically from it, server B will effectively become a dedicated referral server or will also provide the actual operating system installation services.

If the "Do not respond to unknown client computers" option is not selected, server B will reply to service requests from nonprestaged clients (client computer 2 in the example), offering itself as the remote boot server.

Whether or not referral servers are used, selecting "Do not respond to unknown client computers" provides a measure of security by preventing client computers that have not been prestaged from performing operating system installation from RIS servers. In addition, not all vendors offering solutions based on the same remote-boot protocol as Remote Operating System Installation provide options for controlling which client service requests are replied to. By using prestaging and restricting all RIS servers to respond to known client computers, you allow Remote Operating System Installation to be implemented without disruption on a network containing other remote-boot products.

Working with Routers

Because client service requests are based on the DHCP discovery process, configuring your network to support Remote Operating System Installation across routers has the same requirements as doing so to support DHCP across routers.

Routers that are configured to forward DHCP broadcasts will also automatically forward client service requests; however, you must ensure that the requests are forwarded to the proper RIS servers in addition to any DHCP servers. Depending on the router models in use, the specific router configuration of DHCP broadcast forwarding might be supported to either a subnet (or router interface) or to a specific host. If you use Windows 2000 DHCP but have your RIS servers on separate computers, or if you use non-Windows 2000 DHCP, you must ensure that the routers forward the DHCP broadcasts to both the DHCP and RIS servers. Otherwise the client will not receive a reply to the remote boot request.

Because of the amount of network traffic involved in installing an operating system, carefully consider where to place your RIS servers and how to use prestaging and referral servers to accommodate your existing network design so that the impact of client installations is minimized.