Using Win2K's Remote Installation Service

Microsoft seems determined to ship Windows 2000 (Win2K) this year, so those of us trying to assess the product's capabilities before it ships are in the 11th hour. This month, I want to save you some time and trouble by passing along what I've discovered about Remote Installation Service (RIS). This column updates the information in "Windows 2000 ZAW Update," August 1999.

RIS lets you place images of built systems onto a central server and then download those images to a computer with an empty hard disk. All the target computer needs is a NIC and a special boot disk to get the process rolling. RIS also lets you do a simple unattended installation over the network, which is a convenient way to put Win2K Professional (Win2K Pro) on a system without a CD-ROM or an already-copied i386 directory. Of course, you can make such installations easier with unattended installation scripts, which RIS also supports. Out of the box, RIS helps you install Win2K Pro from the i386 directory or with a prebuilt image. You can't use RIS to install Windows NT Server, Windows 9x, or similar OSs yet, but Microsoft is working with third parties to enable RIS to roll out images that programs such as PowerQuest's Drive Image Pro and Symantec's Ghost build.

First, the bad news. One of my greatest hopes for RIS was that it would let me periodically wipe my laptops' hard disks clean and then lay down fresh images of Win2K Pro. I'd hoped to be able to switch a laptop's personality to suit my needs for teaching, writing, and general experimenting. I thought I could just put a disk into its disk drive, boot from the disk, choose a particular image, walk away for a half hour, and return to find the new personality installed. Unfortunately, that scenario isn't possible because the boot disk process supports only PCI network cards. Most laptops use PC Card NICs, so the RIS image transfer process won't work—unless the laptop is seated in a docking station with PCI slots and a PCI NIC. However, most laptops don't support that arrangement.

I discovered more bad news: RIS copies only the C drive to the server. If you want to create a prototype machine with an OS on the C drive and applications on the D drive, RIS will copy only the OS to the server. Therefore, if you want to build a workstation and propagate its drive image to other systems, be sure to put everything on the C drive.

When you want to put the RIS image onto a new computer, put the boot disk that the rbfg.exe utility creates into the disk drive of the new computer, then boot. The RIS transfer process will repartition your hard disk, so be absolutely sure that you have nothing on the disk that you'll miss. RIS's installation routine formats a completely new C drive in one of two ways, depending on whether you choose a prebuilt image or an i386-based installation. If you transfer a prebuilt image, RIS creates a C drive that is the same size as the imaged system. In other words, if your prototype machine has a 1.5GB C drive, any systems you create from that machine's image will also have 1.5GB C drives. (RIS leaves any remainder of the target drives unpartitioned.) RIS follows this pattern regardless of how much free space it finds on the prototype machine's drive. If only 600MB of the 1.5GB drive is full, then any systems you create from that prototype's image will have a 1.5GB C drive with 900MB free.

RIS stores each image on the RIS server on a file-by-file basis, so a RIS image essentially contains the same number of files as the original system. I had assumed that, as with Drive Image and Ghost, storing the image of an OS and applications would produce one large file.

Who cares? Well, a RIS server containing numerous images has a tremendous number of duplicated files; every image has an atapi.sys, an ntoskrnl.exe, and so on. You might think that a large number of images would fill up the RIS server's hard disk quickly—but they don't. Here's why.

The Single Instance Store (SIS) function is now operational, and the only time Win2K sets up SIS is in conjunction with RIS. You might recall from previous articles that SIS is a background task that looks for duplicate files on a hard disk. When SIS finds a duplicate, it saves space by deleting the duplicate, keeping only one copy of the file on the hard disk. However, SIS lists the file in all the directories in which the file is supposed to exist. For example, if 20 RIS images on a hard disk contain atapi.sys, SIS will delete all but one of the atapi.sys files. Someone browsing the server's directories will still see 20 copies of atapi.sys, but they're an illusion; only one copy exists.

Another thing I've learned from experimenting with RIS is that it's fast. While researching "Windows 2000 ZAW Update," I wrote that the RIS demonstration I'd seen took about a half hour to transfer and start up. Another Windows NT Magazine editor told me that he'd seen 15-minute transfers, so I amended the text accordingly. But after I received a version of Win2K with working RIS code, I set up a desktop image on one computer and transferred it to another computer. The transfer took 10 minutes from disk boot to ready-to-go. I performed this test on a 100Mbps Ethernet with virtually no other traffic, but 10 minutes is still an impressive time.

When I first tried to set up RIS on a server, I received an unpleasant surprise. The system boots from a FAT C drive, and the OS is on an NTFS D drive. The D drive had 6GB of free space, which I thought was plenty of space for RIS images. RIS disagreed. I found that RIS doesn't store data on the server's boot drive or its system drive. Consequently, I repartitioned the system so it had another logical drive (i.e., an E drive) with 4GB of space. RIS accepted this new drive, but required it to be in NTFS format. After I set up RIS, SIS controlled the entire hard disk to save space.

My first few attempts to use RIS were unsuccessful because I missed the Help entry advising that Active Directory (AD) must authorize each RIS server. You need to start up the DHCP snap-in and authorize each RIS server, even if your RIS server isn't a DHCP server. Microsoft established this requirement to prevent people from setting up RIS servers or DHCP servers without sufficient justification and planning. Improperly set up servers can confuse the network by offering bogus IP addresses or computer images. This requirement is a great innovation after you figure it out.

I'll leave you with one last essential tip: Put RIS on any server that you want to administer your RIS servers from. After you make a machine a RIS server, you're supposed to be able to run Win2K's replacement for User Manager, Active Directory Users and Computers. However, using Active Directory Users and Computers, I found the Remote Installation tab on only the RIS server. To address this problem, I installed RIS on the domain controller, but didn't run RISETUP, the program that configures RIS. After I rebooted, the Remote Installation tab suddenly appeared in Active Directory Users and Computers as I looked at the RIS servers from the domain controller. Problem solved.