Deploying an OS in a large corporate environment is a challenge. Traditionally, organizations installed the OS and applications before delivering systems to users or sent technicians to users' desktops to install and configure workstations individually. Although some organizations ask the vendor to install a custom image when they purchase new systems, this approach doesn't always work because most large corporations require multiple configurations. In these organizations, IT professionals must continually manage users' computing environments, including upgrading and removing software.
Software and hardware vendors have tried to provide organizations with mechanisms for large-scale OS and application deployment. Microsoft has offered several solutions in the past few years (e.g., unattended install capability, Sysdiff). In Windows 2000 (Win2K), Microsoft offers new deployment and management tools under the Change and Configuration Management (CCM) umbrella. (For more information about Win2K's CCM features, see Mark Minasi, "Windows 2000 ZAW Update," August 1999.) You can use this set of features to deploy Win2K Professional (Win2K Pro).
Win2K Pro's CCM deployment features include Remote OS Installation via the Remote Installation Service (RIS) and Remote Installation Preparation (RIPrep) technologies, scripts, and IntelliMirror. These features let IT administrators use centrally administered policies to manage Win2K Pro users. To evaluate Win2K's deployment and management features, I used Win2K beta 3, build 2031, which was the latest build available at press time. For information about other new features in Win2K, see Mark Minasi, "Windows 2000 Overview," page 54.
Remote OS Installation
Remote OS Installation provides a mechanism for computers to connect to a network server during initial boot-up and lets the server send a local installation of Win2K Pro across the network to the computers. This feature uses as a remote source a Win2K Server-based computer running RIS.
RIS provides the network equivalent of a CD-ROM-based Win2K Pro installation or a preconfigured Win2K Pro desktop image. The CD-ROM-type installation works similarly to using the Unattended Install options on the Win2K Pro CD-ROM to set up a computer directly. However, this installation places source files on the Win2K servers and makes the files available on the network rather than storing them on the CD-ROM. The preconfigured desktop image installation lets a network administrator clone a standard Win2K-based corporate desktop image, complete with OS configurations, desktop customizations, and locally installed applications. Computers running Win2K Server then store the cloned image. On request, a server downloads this image to a new computer. The new computer's hardware doesn't have to be identical to that of the computer on which the administrator created the image because Win2K Pro's support for Plug and Play (PnP) can adjust for hardware differences.
RIS. RIS is a mechanism that lets you deploy Win2K Pro on desktop computers by connecting machines to a RIS server after the initial boot and download of an image over the network. A RIS server is a Win2K server that is a domain controller or a member server in an Active Directory (AD) domain. A RIS client is a computer that can boot remotely. RIS clients must support industry-standard Preboot Execution Environment (PXE) DHCP-based boot ROM version .99c or later. The PXE standard lets computers receive OS images and installations over a network.
If your organization doesn't have PXE boot ROM computers, you can use PCI NICs that mimic PXE boot ROM. You use the Remote Boot Floppy Generator utility (rbfg.exe) to create a remote installation boot disk in Win2K. This utility is in the \RemoteInstall\Admin \i386 folder. (For more information about PXE, see the sidebar "Preboot Execution Environment," page 78.)
The RIS process is simple. The PXE-compliant RIS client boots up and obtains an IP address from the DHCP server. The client also obtains the RIS server's IP address. The PXE protocol includes an extension of DHCP and uses several new DHCP Option tags, which ensure that the normal DHCP services aren't disturbed. When a PXE client boots up, it uses the DHCP protocol to request an IP address for itself and an IP address for a RIS server. The user booting the PC must then log on. AD verifies the user's credentials and gives the user a list of OS images and installation options.
A RIS server needs access to DHCP, DNS, and AD. The DHCP server lets remote-boot clients obtain IP addresses, the DNS server locates an AD server, and AD locates RIS clients and servers.
You can install RIS when you install Win2K Server, or you can use the Control Panel Add/Remove Programs applet to install the service later. The RIS server must have at least two partitions because the remote installation folder to which you copy the files can't be on the same partition as the OS. Furthermore, the folder must reside on an NTFS 5.0 partition.
After you install RIS, you need to authorize the RIS server to respond to client requests. Authorizing a RIS server is similar to authorizing a DHCP server in AD. You must grant the Create Computer Objects right to users who will install images on the clients' computers. You use the Active Directory Users and Computers console to grant this right. In the window that opens, right-click the domain name or the organizational unit (OU) in which you want users to create computer accounts, and use the Delegation of Control wizard to assign the custom task Create Computer Objects. Although the Remote OS Installation walk-through says the Logon as a batch job user right is required, this step is unnecessary in beta 3 and will be unnecessary in the final product. Unfortunately, the modifications you make to user rights at a domain controller don't take effect immediately. To apply the changes immediately, use the Secedit command. Go to a command prompt and type
secedit /refreshpolicy machine_policy
To configure a default OS image on the RIS server, go to a command prompt and type
RISetup
to start the Remote Installation Services Setup Wizard, which Screen 1 shows. This wizard creates the remote installation folder structure, copies Win2K files, creates the unattended setup answer file, and updates the Registry.
At press time, you could install only Win2K Pro with RIS. Microsoft hopes to support RIS deployment of Win2K Server in the future. For more information about RIS, see Mark Minasi, "Using Win2K's Remote Installation Service," September 1999.
RIPrep. Enterprise systems administrators have used third-party system-imaging techniques for several years. Win2K's RIPrep tool helps you image a hard disk. RIPrep lets you create a replica of a hard disk and save the replica on a network distribution server. You can then use this hard disk image as a template to deploy Win2K Pro to multiple client computers. RIPrep doesn't support multiple disks or multiple partitions. Clients can have only one disk with one partition. Therefore, the C drive is both the system and boot partition. The source and destination machines can have different hardware as long as they use the same hardware abstraction layer (HAL) driver. For example, the image installation will fail if the source computer is Advanced Configuration and Power Interface (ACPI)-based but the destination PC isn't.
Imaging involves two components: a reference computer and a RIS server. A reference computer is a machine with a preconfigured image of the hard disk, which typically includes the OS and applications. A RIS server is a Win2K server that contains all the image files you need to distribute to remote-boot clients.
You run RIPrep after you configure your reference computer. The RIPrep .exe utility is in the \Reminst\Admin\ i386 folder (the utility was formerly in the RemoteInstall folder). The RIPrep wizard removes the SID and the computer name associated with the generic image to create an image for the remote installation. The wizard also removes Registry settings that are unique to the computer. The goal is to create a completely generic image that doesn't conflict with other computers on the network.
Because RIPrep copies an image to only one RIS server, you'll want to put images on multiple distribution servers in a large environment. To achieve load balancing, you need a way to replicate images to multiple RIS servers (e.g., copying the images manually, using fault-tolerant Dfs, using Microsoft Systems Management Server—SMS). You need to thoroughly test your image on the reference computer before you run RIPrep. Customizing and tweaking your Win2K Pro installation before you deploy it to thousands of machines can save you valuable time.
Scripts
Using scripts to deploy Win2K is easy if you're familiar with Windows NT 4.0 automated installations. To automate the Win2K setup process, you must create an answer file that contains answers to questions that the setup program asks during an installation or upgrade. This method lets you create a custom configuration based on your organization's needs and eliminates the need for user input during setup. You can use a text editor (e.g., Notepad) to create an answer file, or you can use the Windows 2000 Setup Manager Wizard. The Setup Manager (setupmgr.exe) is in the Microsoft Windows 2000 Server Resource Kit. By default, the Setup Manager saves the answer file as unattend.txt, but you can change the filename. After you create an answer file, you must associate the file with a RIPrep image before you can use automated scripts to deploy Win2K Pro.
You can use the Setup Manager to preset the administrator's password. But you need to be careful because the answer file contains this password in clear text. Therefore, avoid using your domain administrator's password, and ensure that users don't have access to the answer file.
The Setup Manager has five user interaction levels, which Screen 2 shows. These levels give you a high degree of control. Selecting the Fully automated option eliminates the need for users to answer any questions. If you select the Read only mode, users must accept the answers you preconfigure in the answer file.
Although the Setup Manager streamlines certain tasks, the tool has some limits. For example, you can use the wizard to configure only display devices. To add other devices, you must use a text editor to manually tweak the unattend.txt file. In addition, you must manually enter the parameters that the wizard doesn't include. Microsoft will provide a list of answer file parameters in an Unattended Setup Parameters Guide on the Win2K Pro and Win2K Server CD-ROMs. The resource kit's Tools Help section discusses this guide, but beta 3, build 2031, doesn't include the document. To read about the guide, go to the resource kit's Tools Help shortcut and search the unattend.txt file.
If you want to automate application installation, you can use the resource kit's sysdiff.exe tool. Sysdiff has the same functionality as in NT 4.0: The utility creates a difference file that you can deploy to clients' machines to automatically install applications. (For an explanation of Sysdiff, see Clayton Johnson, "12 Steps to Cloning Windows NT Systems with SYSDIFF.EXE," August 1997, and Mark Russinovich, "NT Rollout Options," June 1998.)
IntelliMirror
IT professionals must install applications and keep up with OS and application upgrades and new service packs and patches. Win2K's IntelliMirror feature uses group policies to help administrators centrally deploy and manage software and coordinate the management of user settings and data. (For more information about group policies, see Darren Mar-Elia, "Introducing Group Policy," September 1999.)
IntelliMirror uses group policies to let you publish or assign applications to users and assign applications to computers. When you publish an application, users can use the Control Panel Add/Remove Programs applet to install that application. When you assign an application to a user, you create an icon on the user's desktop or a shortcut on the user's Start menu. The user can then install the application by double-clicking the desktop icon or selecting the application from the Start menu. When you assign an application to a computer, the application installs automatically when the computer boots, and anyone who logs on to the computer can access the application.
You can also use group policies to reinstall, upgrade, or remove applications on clients' computers. Using Group Policy Objects (GPOs) to redeploy software reduces your support staff's number of trips to clients' workstations.
To use group policies to deploy software, you must use Windows Installer-based software packages (.msi files). These packages are replacements for software packages' standard setup programs. You define policies for targeting software deployment under the Group Policy Software Installation extension. In the Group Policy console, select User Configuration or Computer Configuration, depending on whether you want to assign an application to users or computers. Then, select Software Settings, Software Installation. The Windows Installer package you create contains instructions for installing and removing software. Screen 3, page 76, shows the properties of a Windows Installer package.
Two types of Windows Installer packages exist: native and repackaged. Software vendors typically create native packages and include them in software packages. You can use a third-party tool (e.g., VERITAS Software's WinINSTALL) to repackage an application that doesn't have a native package. Microsoft includes WinINSTALL on the Win2K Pro and Win2K Server CD-ROMs. Another method to publish applications that don't have a native Windows Installer package is to create a .zap file. Like an .msi file, a .zap file contains instructions for installing applications. You can publish .zap applications, but you can't assign them.
You can also use group policies to remove applications. If you remove an application from clients' computers, you can uninstall the software immediately or let users continue to use the application but prevent new installations.
Management
In NT 4.0, you can use administrative templates (i.e., .adm files) to customize group policies. Win2K likewise lets you create custom group policies to manage user configurations. For example, you can prevent certain GPOs from overriding specific containers' policies. Screen 4 shows example configuration options for a new group policy.
Win2K also includes support for disk quotas. Administrators can set quota limits to control the amount of disk space users have available.
In addition to providing software installation and maintenance, IntelliMirror gives administrators tools for managing mobile or roaming users. Mobile users access the network remotely. Roaming users are clients who log on from multiple computers to access the network. IntelliMirror supports roaming user profiles, redirection of users' personal folders, and offline documents. These tools benefit administrators and users. Users see a familiar desktop environment regardless of where they log on from. In addition, administrators can point users' private folders to the network, where the folders are backed up, although the folders appear to be local to the users. Finally, users can work on network documents offline because files automatically synchronize when a user reconnects to the network. This concept is similar to working with Microsoft Outlook email files offline.
Cautiously Optimistic
Microsoft has worked hard to include useful deployment and management tools in Win2K. Although these solutions have limitations, they're a step in the right direction. Only time will tell how well the tools work in your environment. Several third-party tools already offer similar capabilities, and I expect a barrage of additional utilities in the coming months. As an IT professional, you'll need to compare the pros and cons of these tools with Win2K's native tools. For large corporations, ease of use, effectiveness, and speed will be more important than price. Microsoft's efforts are encouraging, and I'm cautiously optimistic that Win2K's native deployment and management tools will be sufficient.
