Remote Installation Services, or RIS, is not new to Windows Server 2003. RIS was first released in Windows 2000. However, the Windows 2000 version of RIS had some major limitations, many of which have been overcome by the Windows Server 2003 version. Here's what's new in the Windows Server 2003 version of RIS and some of the limitations that still exist within RIS.
What's Remote Installation Services?
As you might have guessed from the name, Remote Installation Services provides you with a way of remotely installing an operating system onto a remote machine. When RIS was originally introduced, it could be used to deploy Windows 2000 Server or Windows 2000 Professional. The Windows Server 2003 version of RIS can still deploy Windows 2000, but it can also be used to deploy Windows Server 2003 and Windows XP.
When using RIS to deploy an operating system, there are several techniques that you can use for the deployment. You can do a standard deployment, a scripted deployment, or an image deployment. In all instances, the new computer (I'll call this machine the RIS client) boots from a floppy disk or from a PXE-enabled NIC, attaches to the RIS Server, and accesses the installation files.
If a standard deployment is being used, then the installation files consist of nothing more than the contents of the Windows installation CD. So why not just place these files on a network share somewhere? Because in most cases, you need an operating system before you will be able to access a network share. The RIS boot disk takes the place of the client operating system and allows the client machine to access the installation files. The problem is that the installation process is still manual. You will have to answer all of the questions asked by the Windows Setup program during the setup process.
A scripted deployment works in pretty much the same way as a standard deployment except that it makes use of an answer file. An answer file provides the answers to the various questions asked by Setup so that you don't have to answer these questions manually.
The third type of deployment is an image deployment. This type of deployment allows you to manually install Windows onto a machine and then make an image of that machine. You can then deploy the image to other machines through RIS. This type of deployment makes use of a utility called RIPREP.
The nice thing about deploying an image rather than relying on Setup files is that your image file can contain more than just the Windows operating system. You could, for example, install Microsoft Office and your antivirus software onto the workstation prior to building the image file. This would allow those applications to be deployed along with the operating system. You will just have to verify any time you perform a deployment that you have enough licenses for Windows and for any applications that are being deployed.
Setting up a RIS image and preparing for your first deployment can be a real pain. So why not just use an imaging utility such as Symantec's Ghost instead? The reason is the way that Windows makes use of SIDs. When you install Windows, it creates a unique SID for the machine. It also creates unique SIDs for all of the local user accounts that are based on the computer's SID. If you use a utility like Ghost to duplicate a machine, you will also duplicate the machine's SIDs as well. If you place two machines with common SIDs onto the same network, you will have some really strange access control problems.
There are SID randomizer programs that can supposedly change all of the SIDs that exist on a machine, but Microsoft has indicated on more than one occasion that such utilities are "inadequate" and should not be used. I have never personally used such a utility, so I can't tell you if they really work or not. At any rate, RIS will guarantee that each deployment receives a unique set of SIDs.
What else is new?
I mentioned that RIS has been extended to allow for the deployment of Windows XP and Windows Server 2003, but you might be wondering what else is new. There are a couple of things. First, Windows 2000's implementation of RIS was less than secure. It had a nasty habit of transmitting passwords in clear text format, for example. The Windows Server 2003 version of RIS has addressed this and other security concerns.
If you ever used Windows 2000's implementation of RIS, you know that RIS clients used PXE to access the RIS Server. Since many computers don't have built-in PXE capabilities, RIS allowed you to create a boot floppy that could be used to emulate PXE. The problem was that there were a lot of cases in which this floppy disk just didn't work. In Windows Server 2003, you can still create a RIS client boot floppy, but the floppy has been improved to make it compatible with more systems.
Before you set up your own RIS Server, you need to know about some of RIS's many limitations. Some of the most important limitations that you need to know about involve the way that RIS works with hard disk space. RIS will only image a single partition. Therefore, when creating the client machine that you will image, you must make sure that only a single partition is used.
There are also disk partition requirements on the RIS Server. RIS is very picky about where it will allow you to store RIS images. You can't store a RIS image on the boot partition or on the system partition. The partition used to store RIS images must be formatted to use the NTFS file system because of the way that RIS makes use of the Single Instance Storage (SIS) service.
A couple of other limitations that you need to be aware of involve the RIS server. The server cannot be multihomed. (A multihomed server is a server with multiple network cards.) The server must also be a member of an Active Directory-based domain, which must also include at least one DHCP server. I have also heard rumors that the DHCP server service must be running on a different server from the one used as a RIS server.
RIS isn't installed by default. To install RIS, open the Control Panel and select the Add/Remove Programs option. When you do, Windows will display the Add/Remove Programs dialog box. Click the Add/Remove Windows Components button to display a list of all of the programs included with Windows Server 2003. Click the Remote Installation Services check box and then click Next. You will then be prompted to insert your Windows Server 2003 installation CD. Windows will copy a few files and will then prompt you to reboot your system.
After the system reboots, select the Remote Installation Services Setup command from the server's Administrative Tools menu. When you do, Windows will launch the Remote Installation Services Setup Wizard. Click Next to skip the Welcome screen and you will be prompted for the path that Windows should use for Remote Installation Services. When selecting a path, remember that RIS can't be installed onto the boot or system drive. The next screen contains a check box that you can use to determine whether or not the RIS server should respond to client requests. Go ahead and select the Respond To Client Computers Requesting Service check box and click Next.
At this point, the setup wizard will ask you for the path to the Windows installation files. For demonstration purposes, go ahead and insert a Windows XP installation CD and point the wizard to it, then click Next. After doing so, the wizard will ask you to name the folder that will contain the installation files. Name this folder WindowsXP and click Next.
The wizard will now prompt you for a description of the folder. Since Microsoft Windows XP Professional is already entered for you, just click Next. You will now see a summary of Remote Installation options. Review the various settings and click Finish to complete the installation. RIS will now complete the installation process and copy the Windows XP installation CD.
When installation completes
One of the areas where I think that RIS has a few shortcomings is in the user interface department. For all practical purposes, there really isn't a user interface. The Administrative Tools menu has a Remote Installation Services Setup option, but this is just a link to the same wizard that you have already been through. You can use this wizard to create additional deployments.
So if there really isn't a user interface for RIS, how do you know if it's even running? You could try to do a remote installation on a new system, but there are other ways. Begin by opening the Service Control Manager and verifying that the following services are running: Remote Installation, Trivial FTP Daemon, and Single Instance Storage Groveler. If these services are running, then you can be sure that RIS is installed, although it may not be completely functional.
I recommend taking a look at your server's Application Log. Specifically, you are looking for information event ID numbers 1003 and 1024 from BINLSVC. You also want to look for Event ID 4096 from Groveler and Event ID 100 from ESENT. If these events are all present, RIS is definitely up and running. It still doesn't mean that RIS is going to be functional, though. RIS must be authorized in the same way that you would authorize a DHCP Server.
To find out if RIS is properly authorized, take a look at the System log and look for Event ID 1046 from DhcpServer. If the event exists, the description will say something like, "The DHCP/BINL service on the local machine belonging to the Windows Administrative domain test.com has determined that it is not authorized to run." The message might go on and list some possible reasons for the error, but if you see an event like this, RIS isn't going to function until you authorize it.
It might seem odd that the description that went with the Event ID 1046 referred to a DHCP server and not to a RIS server. It might seem even stranger that to authorize RIS, you must treat the RIS server as a DHCP server. Remember, though, that one of the first things a RIS client has to do is to acquire an IP address. In that sense, RIS is acting like a DHCP server.
To authorize your RIS server, select one of the DHCP servers that already exists on your network and log into the server as a member of the Enterprise Admins group. If you don't presently have a DHCP server, you can load the DHCP services onto any server just for the purposes of authorizing your RIS server.
After logging into the server, select the DHCP command from the server's Administrative Tools menu. This will open the server's DHCP console. Now select the Manage Authorized Servers command from the console's Action menu. This will cause Windows to open the Manage Authorized Servers dialog box. This dialog box displays a list of all of the DHCP servers that are already authorized. To authorize your RIS server, click on a blank area of the dialog box so that no servers are selected and then click the Authorize button.
When you do, Windows will prompt you for an IP address or computer name for the server that you want to authorize. Enter this information, click OK twice, and you're in business. Keep in mind that it might take a little time for the new authorization to propagate to the other domain controllers in the forest.
Creating a RIS boot disk
As you may recall, a new system initiates communications with the RIS Server through the Preboot Execution Environment (PXE) protocol. PXE is normally implemented at the hardware level. Many network cards have PXE built in, and some computers even support PXE at the BIOS level. So what do you do if your workstations don't natively support PXE? Well you could buy new, PXE-compliant network cards, but there is an easier technique.
Windows Server 2003 allows you to create a RIS boot disk. This boot disk emulates a PXE boot. Best of all, you don't have to create a separate disk for each machine. You can create one disk and use it for all of your OS deployments regardless of whether they have similar network cards or not. Windows 2000 was very limited in the network cards that it would support from the RIS boot Disk. Windows Server 2003's RIS boot disk supports more network cards than its predecessor did and tends to be more stable.
To create the RIS boot disk, go to your RIS Server and navigate to the \RemoteInstall\Admin\i386 folder. Once there, run the file RBFG.EXE. Creating the RIS boot disk is as simple as clicking the utility's Create Disk button. However before doing so, I recommend clicking the Adapter List button. The RIS boot disk only supports a couple dozen different network adapters, so it's a good idea to make sure that your workstation's network adapter is supported.
Once you finish creating the RIS boot disk, boot one of your new workstations from the disk. The boot process will quickly detect your network adapter and will then take a second to acquire an IP address from a DHCP server (or from your RIS server if it is emulating a DHCP server). You must then press the [F12] key to continue the boot. Otherwise, the boot process will abort if you don't press [F12] fast enough.
At this point, you will see the Client Installation Wizard appear. Press [Enter] to bypass the wizard's Welcome screen. The next screen that you will see prompts you to enter your username and password for the domain. The domain name is filled in for you by default, although it can be changed. Press [Enter] and you will be given a choice of which operating system you want to install from the RIS server. The bottom of the screen contains a full description of each operating system. Select the operating system that you have just created the image for and press [Enter]. Now, just follow the prompts to begin the operating system installation.