Automating Windows Server 2003 Deployments
Computers are supposed to be servants, right? So why should we expend countless hours slaving over repetitive installations to get our servants to the point where they can serve? If you have more than one or two servers to install or upgrade, you might want to look into automating the process. There are three general types of automated deployment methods:
In this section, we'll take a detailed look at each method.
Of the three deployment methods, disk cloning is the fastest. It is also the most likely method to cause compatibility problems due to hardware differences between the server where you made the image and the server where you place the image.
Cloning makes sense for desktop deployments where you have many iterations of the same hardware. For servers, I prefer a process that tailors the installation more closely to the underlying platform. Disk cloning is handy, though, for taking snapshots of a server prior to making a change. If the change causes the server to go to the rings of Saturn, you can quickly re-image to recover functionality.
Cloning involves using a disk-imaging package (Microsoft does not provide one) that takes a sector-by-sector snapshot of the contents of the system drive and saves it to a file. You can come back to the same machine at a later time, or to another machine, and apply the image. If the underlying hardware is fairly close to the same, you get an identical copy. If there are subtle differences in the hardware, your copies might start to act in strange and gruesome ways. If you've ever seen Michael Keaton in Multiplicity, you have an idea how bad things can get when cloning goes awry.
There are two major disk-imaging products:
Both of these products permit you to quickly take an image of a drive, restore the image, and even make changes to parts of the image without disturbing the other parts.
Problems with Disk Imaging
Deployments based on disk imaging start to get complex when you have a variety of server platforms. Thanks to Plug and Play, Windows Server 2003 can forgive certain differences in peripherals, but surprisingly small deltas in critical system components can cause imaged installations to fail or perform erratically. These differences include the CPU model and stepping, firmware revision, chipset, memory configuration, and ACPI (Advanced Configuration and Power Interface) version.
If you change out a major subassembly, though, such as a motherboard, or you place an image on another machine, the Plug and Play Manager may become hopelessly lost and could refuse to recognize the drive interfaces or memory. Be sure to test your cloned configuration on every subset of hardware you have to see whether this is going to be a problem for you.
Disk imaging also causes problems if you use retail versions of Windows Server 2003 that require individual product activation. Because the image has the same Product Key as the master, you will not be able to activate the new server. If you are going to clone servers, be sure to purchase your product using Volume Purchase Agreements that have no activation requirement.
Disk Imaging with Sysprep
You can avoid some of the problems with hardware incompatibilities and product activation hassles by stripping the machine-dependent information out of the Registry prior to imaging the machine. That is the function of Sysprep.
Sysprep makes it fast and easy to image a server without SID or compatibility issues. Sysprep has an advantage over the scripted installation methods described later in this chapter because it preserves applications and their Registry settings along with specialized configurations you may want for your servers.
Sysprep is not a panacea for hardware incompatibilities, though. If the target server has a different mass storage device than the server where you ran Sysprep, you can get a kernel-mode stop error after applying the Sysprep image. This is because the operating system cannot locate the boot files thanks to the incompatible mass storage device.
The Sysprep tool is compressed inside the Deploy.cab file located on the Windows Server 2003 CD in the \Support\Tools folder. You can extract it from the CAB file directly using Explorer and run it from any folder. Sysprep displays the window shown in Figure 2.2.
Figure 2.2. System Preparation Tool window showing options.
You can also run Sysprep from the command line. Run sysprep /? for an option list. Here's an example:
sysprep -quiet -noreboot -mini -pnp
This command runs Sysprep with no prompts, shuts down the system without rebooting after the system has been prepped, initiates a mini-setup at the next restart, and forces a plug-and-play scan of all devices during the mini-setup.
You can use the results of Sysprep to make a drive that can be imaged using Ghost or DriveImage. The image has a full installation of Windows Server 2003 and any applications that were installed on the server but does not have hardware-specific information in the Registry.
When you start a server after imaging it with this Sysprep image, a new SID is generated and a mini-setup launches to collect configuration information. You can include a script in your Sysprep deployment image that automates the mini-setup. See "Scripted Installations" later in this chapter.
Auditing a Sysprep Image
You may want to verify that a particular Sysprep image is correct. For example, you may have several images for different server types. You now have the same problem as a chicken farmer: How do you make sure there's a chicken in an egg without breaking the egg and killing the chicken?
You overcome this obstacle by using the -nosidgen option. You can install the image to make sure it works then run Sysprep again with the -nosidgen option to recreate the image while preserving the configuration files that were generated by the original Sysprep session. You can restart as many times as you like using -nosidgen. The Audit Shutdown option in the GUI interface performs the same action.
Be sure not to change any files while you are auditing the installation. Sysprep does not scan for file and Registry changes with -nosidgen.
Sysprep Factory Options
OEM manufacturers can use Sysprep to create an image that can be cloned onto disks for hundreds of systems. There is a -factory option in Sysprep that permits the manufacturer to slipstream changes into the image for a specific model of hardware.
The -factory option relies on entries in a Winbom.inf script. You must build this Winbom script manually if you intend on using the -factory option. The Ref.chm help file that accompanies Sysprep has a full list of the Winbom.inf options and their syntax. Sysprep looks for the Winbom.inf script on a floppy and, if it exists, incorporates the changes into the image.
The advantage of using the -factory option is that the worker on the assembly line (or you, if you build a lot of servers) can have a single master image with floppies that have settings for various different configuration options.
You can add more drivers or make changes to the content of the automated setup after running Sysprep -factory. Run Sysprep -reseal to prepare the machine for final deployment.
Additional Sysprep Options
If you plan on imaging a domain controller, it is important not to change the server's SID because it uniquely identifies the domain controller in Active Directory. Use the -nosidgen option to retain the current SID.
If a server has legacy hardware—that is, hardware that is not Plug and Play—you can use the -pnp option to force a full scan for installable devices. Don't use this switch unless you have legacy equipment because it increases the time for the mini-Setup to finish.
The server you use to build a Sysprep image cannot be a domain controller or a domain member. You can join it to a domain as part of the mini-setup when the imaged machine first starts. You can script this mini-setup to create a hands-off installation.
The server you want to Sysprep cannot have any encrypted files. This is because the SID will change, making obsolete all existing profiles where the encrypted file keys are stored.
You can only run through three Sysprep cycles on a given machine. This prevents avoiding activation by simply running Sysprep when the grace period expires.
The server cannot be a member of a cluster. It cannot be a Certification Authority. Both of these applications require specific information about the machine, its SID, and its hardware. For instance, you would not want someone to be able to take a Sysprep image of a Certification Authority and use it to clone off another server that would pass out counterfeit certificates.
When Setup runs in interactive mode, it spends a lot of time asking nosey questions before it gets down to the grunt work of copying files and configuring the system. By scripting your answers to these questions, you can do a fully unattended installation.
Because a server typically has a fixed identity (name, IP address, domain membership, and so forth), installing the operating system with a script is a little more difficult than using scripts to deploy desktops. Still, it's possible to submit identity items as part of the script so that a minimal effort is required to install the server after you get the hardware ready to go.
A scripted installation of a server also ensures that the files are copied from a consistent distribution point. Later on, when you need to install a new service, Windows Server 2003 will go back to that distribution server to find the files. A feature in Windows Server 2003 service packs permits you to slipstream a service pack into a distribution point so that you can install a service pack right along with the base operating system. See "Slipstreaming Service Pack Installations" later in this chapter for more information.
Procedure 2.2 shows a quick breakdown of the overall steps for scripting an unattended installation and performing the deployment.
Procedure 2.2 Task List for Setting Up Scripted Installations
Create an unattended setup script that automatically answers configuration questions presented by Setup.
Copy the Windows Server 2003 installation files and scripts to a folder on a distribution server and share the folder.
Build a boot disk that connects a target client to the shared installation directory across the network.
Use the unattended setup script to install Windows Server 2003 on the target server.
Creating an Unattended Setup Script
This section covers creating an unattended setup script using the Setup Manager utility, Setupmgr. This utility is compressed inside the Deploy.cab file on the Windows Server 2003 CD in the \Support\Tools folder. You can extract the file using Explorer and run it from any folder.
In addition to building the setup script, Setup Manager can automate the creation of a distribution share point to hold the installation files. If you want to take advantage of that option, launch Setup Manager at the console of the server where you want the distribution files to be located. When you're ready, proceed as directed in Procedure 2.3.
Procedure 2.3 Using Setup Manager to Create an Unattended Installation Script
Launch Setupmgr. The Setup Manager Wizard starts.
Click Next. The New or Existing Answer File window opens. Select Create New.
Click Next. The Type of Setup window opens. Select one of the three types of scripted installation:
Unattended Setup builds a text-based script that contains entries that configure the text and graphical portions of Setup.
Sysprep Setup builds an INF script that handles the mini-setup that runs the first time a machine starts after having been given a Sysprep image.
Remote Installation Services (RIS) builds a SIF file for use when deploying a RIS image.
Click Next. The Product window opens. Select the Windows Server 2003 product or XP product that you are installing. (The unattended setup script used by Windows Server 2003 differs from Windows 2000 and the two should not be mixed.)
Click Next. The User Interaction window opens (see Figure 2.3). The Fully Automated option scripts the entire installation and should be selected unless you have special requirements.
Figure 2.3. Windows Setup Manager Wizard—User Interaction window.
Click Next. The Distribution Share window opens. Select Create a New Distribution Share. This permits you to copy the contents of the CD to a distribution folder and share the folder.
Click Next. The Location of Setup Files window opens. Select whether to copy the files from the CD or another location. The alternate location option comes in handy when you have slipstreamed various service packs into a network installation point and you want to copy the files from there.
Click Next. The Distribution Share Location window opens (see Figure 2.4). Enter the path and name of the folder and the share name you want to use. You must do this on the distribution server. The wizard cannot create a share across the network.
Figure 2.4. Windows Setup Manager Wizard—Distribution Share Location window.
Click Next. The License Agreement window opens. This is your acknowledgement that the automated installations using this script comply with the End User License Agreement (EULA). Without an entry here, the unattended installation will stop and prompt for a EULA agreement. Check I Accept the Terms of the License Agreement.
Click Next. The wizard closes and leaves the Setup Manager window open.
Unlike earlier versions of Setup Manager, Windows Server 2003 presents you with a tree of the possible options so that you can quickly pick and choose those that you want to use without spending time stepping through the wizard screens one at a time. See Figure 2.5 for an example.
Figure 2.5. Setup Manager main window showing the tree of setup options.
A few of the options require an entry, so the tree doesn't give you truly random access. Some of the options merit special attention:
The Computer Names option permits you to specify a name or to have Setup automatically generate a name. The generated name takes the form of the name you enter in Personalize This Computer followed by a dash and then random letters. If you want to specify a name, you must include an Unattended Difference File (UDF) that specifies the name of each server. The server name must be specified on the Winnt or Winnt32 command line when you initiate Setup.
The Administrator Password option (see Figure 2.6) permits you to specify a password for the local Administrator account. Setup Manager puts this password into the installation script. Windows Server 2003 improves security by permitting you to encrypt the password. Without this encryption option, the password is exposed in the script in clear text.
Figure 2.6. Windows Setup Manager Wizard—Administrator Password window.
The Workgroup or Domain option permits you to join a domain during Setup. This is generally a worthwhile thing to do, but it again raises the possibility of a security breach because the account you use to join the domain is exposed in clear text. See the sidebar, "Joining Domains During Automated Setup."
When you have entered information for the required and optional items, click Next. Setup Manager prompts you for the name and path of the unattended setup script. The default name is Unattend.txt.
Put the file in the I386 folder that holds the installation files. If you create the distribution point as part of Setup Manager, it will automatically place the script in the correct location.
If you want to join a server to a domain during an unattended setup, the best course of action is first to create a computer account in Active Directory. This can be difficult if you use automatically generated names. You won't know what the name will be.
If you choose to create the account during an unattended setup, one alternative is to protect the installation deployment folder with NTFS permissions that permit users to execute files but not view them.
Another alternative is to create an account with the privilege to join computers to a domain but no other administrative privileges. You can periodically change the password of this account to preserve its security.
A third alternative is to initiate the unattended setup script with a batch file that collects information from the deployment technician.
Windows Server 2003 permits any authenticated user to join a computer to a domain. Don't make the mistake, though, of simply entering a user account into the unattended setup script. Non-administrators can only join a computer to a domain ten times. After that, they are blocked from exercising the privilege.
Example Unattended Setup Script
Here's an example of a setup script created using Setup Manager. The entries highlighted in bold deserve special attention:
OemSkipEula=Yes ;This skips the License Agreement window.
DriverSigningPolicy = ignore ; Add this switch manually
to avoid errors with unsigned drivers.
EncryptedAdminPassword=Yes ; The encryption uses a two-way cipher of the password.
AutoLogon=Yes ; This option logs on automatically using the Administrator credentials.
AutoLogonCount=1 ; This option limits the number of automatic logons.
FullName=Admin ; Do not use Administrator or Guest as an owner name.
ComputerName=* ; This enables automatic computer naming.
DomainAdminPassword=JabBorE# ;Domain password in clear text. Protect the file with
Example Unattended Setup Batch File
Setup Manager creates a batch file for initiating the unattended setup. The client maps to the shared distribution folder and executes the batch file. Here is an example:
rem This is a SAMPLE batch script generated by the Setup Manager Wizard.
rem If this script is moved from the location where it was generated, it may have to be
\\S1\netsvrdist\winnt32 /s:%SetupFiles% /unattend:%AnswerFile%
This batch file uses Winnt32, the 32-bit installation management utility. If you connect to the network share from a DOS client using a network boot disk, you must use the 16-bit installation manager, Winnt. If you do so, you need to add a /b switch to the command line, indicating no setup boot disks, and change the word unattend to the letter u as follows:
\\S1\netsrvdist\winnt /b /s:%SetupFiles% /u:%AnswerFile%
If you want to specify a local drive for installing Windows Server 2003 other than the default boot drive, use this syntax:
\\S1\netsrvdist\winnt /s:%SetupFiles% /u:%AnswerFile% /t:%TargetDrive%
Unattended Script Customizations
The script generated by Windows Server 2003 Setup Manager includes only the base operating system files and drivers. If you have additional drivers to install, or you want to include applications or other enhancements to the unattended setup, you must add these manually to the distribution share files and the unattended setup script.
A list of all unattended setup script entries and their uses is included in Deploy.chm help file inside the Deploy.cab file on the Windows Server 2003 CD under \Support\Tools. It helps to be familiar with the standard Microsoft customization file locations and a few of the more common script entries. Here they are:
The top-level folder containing customization files. This folder must be at the root of the distribution point.
This folder contains drivers and INF scripts for any components that must be loaded as part of the text mode portion of Setup. For example, if you have a RAID controller that needs a driver not included in Windows Server 2003 setup files, you would put the driver and its Oemsetup.inf script here. The same is true for OEM versions of kernel files.
This folder contains drivers and files that you want to put in %systemroot%. This is generally C:\Windows. Examples include component drivers not included in Windows Server 2003. You can have subfolders under $$.
This folder contains drivers and files that you want to place at the root of the system drive. This would include any drivers required to load before the operating system has fully initialized. You can have subfolders under $1.
These folders contain files that you want to put in various logical drives after the system has assigned drive letters. This is especially handy for installing application files. You can define subfolders, as well.
Automating Product Key Entry
If you want to automatically enter the 25-character Product Key as part of the unattended script, you can include it as follows:
This is only applicable if you have a Volume Purchase Agreement or a Master License Agreement. Otherwise, you must have a distinct Product Key for each server to successfully activate the installation.
Speaking of activation, if you are deploying the retail version and you want to activate automatically without bothering the user, you can do so as long as you have an Internet connection. If you have a firewall with an Internet proxy server, you must include proxy entries, as well. The following entries in the unattended script file will initiate the Windows Product Activation automatically:
Expanding the System Partition
When you install Windows Server 2003 across the network, Setup first copies the installation files to the local hard drive. This means you need a formatted partition ready to receive the files. The partition must be formatted as FAT or FAT32. To get an acceptable cluster size, you want to keep the size of the FAT partition to the minimum size possible, which is 1.5GB for Windows Server 2003.
You can automatically extend this partition as part of the unattended setup to get more room for the operating system. This can only be done for NTFS partitions, so you must convert the partition, as well. This requires two entries:
If you have a 30GB boot drive, you probably do not want to give the entire drive to the operating system. You can limit the size of the extended partition by specifying the size in megabytes of the final partition. Here's an example:
Running Scripts During Unattended Setup
The easiest way to install applications as part of an unattended setup is to put the application's setup files in a folder under $OEM$ and then kick off a script or batch file that initiates an unattended setup of the application. Many applications use setup scripts similar in concept, if not form, to Unattend.txt.
Scripts can be included in unattended setups by placing the scripts, batch files, and executables in a folder of your choice under $OEM$ and then launching the script using a Cmdlines.txt file stored at the root of $OEM$.
You must construct the Cmdlines.txt file manually. You must also tell Setup to use it by putting this line in the Unattend.txt file:
OEMPREINSTALL = Yes
The Cmdlines.txt file must be formatted as follows:
The script, batch file, or executable launched in Cmdlines.txt must have a short filename. If it has a long filename and you cannot change the name, you can launch it from another batch file with a short name that you can put in Cmdlines.txt.
Because the elements of Cmdlines.txt run before any user logs on, they run in the Local System security context. This means they cannot make network connection to other servers. If you write any information to the Registry, it is written to the Default User profile.
Tailoring Component Installations
In addition to using unattended installation scripts for handling an entire setup, you may want to script specific component installations following Setup. For example, if you want to install IIS, you should always use an unattended setup script so you can designate a location for your web files that are not on the boot drive and to simplify selecting only those web services that you need to support production operations.
The utility that handles the unattended installation of a Windows component is SYSOCMGR. To use this utility, create a text file that contains the component installation settings, then use the file as a parameter of SYOCMGR. Here's an example using a script file called Iis.txt:
Sysocmgr /i: %windir%\inf\sysoc.inf /u:c:\iis.txt
Here is an example of an unattended setup script that installs only web services and places the web files on the D drive:
iis_common = On
iis_inetmgr = On
iis_www = On
iis_ftp = Off
iis_nntp = Off
iis_nntp_docs = Off
iis_pwmgr = Off
iis_smtp = Off
iis_smtp_docs = Off
iis_htmla = Off
iis_w3samp = Off
iis_doc_common = Off
iis_doc_ismcore = Off
iis_doc_asp = Off
iis_doc_sdk = Off
iis_doc_mm = Off
Slipstreaming Service Pack Installations
In classic NT, getting the operating system installed was only half the work. You then had to install the "second operating system" consisting of a service pack containing hundreds, even thousands, of files containing fixes.
Starting with Windows 2000, Microsoft eased this work quite a bit by making it possible to install the fixed files in the service pack right along with the normal Setup files. You do this by slipstreaming the updates into the distribution folder that holds the regular installation files. To perform this slipstreaming, follow the steps listed in Procedure 2.4.
Procedure 2.4 Slipstreaming Service Pack Files
Mount the service pack CD in the CD-ROM drive or copy the contents of the service pack CD to a separate folder.
Navigate to the \I386\Update folder in the service pack files.
Run update -s:e:\softdistro, where e:\softdistro is the folder containing the Windows Server 2003 distribution files. Note that you point at the folder above the I386 folder containing the installation files.
After you have updated the installation files in this manner, running Setup from the distribution point also will install the fixed files.
All service packs are cumulative, so you do not need to retain earlier versions. Update replaces the catalog used by the Windows File Protection system with an updated catalog that has the file signatures for the fixed files. It also puts in place an additional CAB file containing drivers that have been updated or added since the initial release of Windows Server 2003.
You can deploy service packs to installed servers using group policies. See Chapter 12, "Managing Group Policies," for details.
Building a Network Boot Disk
Whether you deploy Windows Server 2003 using Sysprep or a fully scripted installation, if you want to install to a machine that has no operating system installed, you'll need a way to boot from a floppy disk and make network connection to the distribution server holding the installation files.
Building a Windows-based network boot disk isn't simple. Microsoft uses a proprietary open standard for network drivers called the Network Driver Interface Specification (NDIS). (You may see the acronym NDIS broken out as Network Device Interface Specification. Both are acceptable.)
For the ultimate in automating the creation of custom boot disks, I highly recommend visiting Bart's Boot Disks web site at www.nu2.nu/bootdisk. This site has a compilation of CAB files that contain boot files, network files, and configuration files to use for creating boot disks and bootable CD-ROMs.
Real-mode NDIS with TCP/IP support requires a chorus of support files the size of the Mormon Tabernacle Choir.
The Windows Server 2003 CD contains the files required to build a DOS network client but it only provides an eight-year-old installation utility for extracting and configuring the files. You can declare yourself a true Windows networking guru if you memorize the real-mode NDIS files and the contents of the various configuration files to build a boot floppy from scratch.
If you're familiar with NT4, you may know that Microsoft supplied a nifty little utility with NT4 Server called Ncadmin that had a feature for building NDIS boot floppy disks. Microsoft does not include Ncadmin with Windows 2000 or Windows Server 2003. If you need to build an NDIS boot disk, you can get a copy of Ncadmin from an existing NT4 Server CD and use it to build your network boot disks. Ncadmin runs just fine on Windows Server 2003.
If you don't mind spending a few dollars, the major imaging vendors—including Symantec and PowerQuest—provide utilities for building boot disks. These utilities take the real-mode NDIS support files from the Windows Server 2003 CD and the NDIS 2.0 drivers from the network support disk for your adapter and build you a network boot disk. I highly recommend these.
Remote Installation Services
All of the automation techniques we've seen so far require at least some intervention on the part of an administrator. The ultimate automation would be to have a completely hands-off installation where the machine finds its own distribution server, downloads the installation files, installs them, and boots up ready for work. That's the goal of Remote Installation Services, or RIS.
RIS combines the hardware-independent flexibility of scripting with the simplicity of imaging. Using RIS, you can build a file-based "image" of a server and deploy that image completely hands-free. It's like getting beer and fudge for dinner. Unfortunately, you have to eat your Brussels sprouts first. RIS can be a little complex to set up and manage. You'll be repaid for the work, though.
Functional Overview of RIS
RIS consists of a server component and a client component. The server component is the Remote Installation Services itself, running on a Windows 2000 member server or domain controller.
The RIS service controls access to a set of file-based "images" stored on the server. The image files can come from the installation files on the Server or Professional CD, or they can come from an "image" server or workstation that has been processed using a utility called Riprep. See "Creating RIS Images with Riprep" later in this section for more information.
RIS depends on a variety of services, all of which must be configured just right. This makes it a little complex to do the initial setup. Here is a quick list of the services that require special configuration. I'll discuss how RIS uses each one in detail:
Pre-boot Execution Environment (PXE)
Boot Information Negotiation Layer (BINL)
Client Installation Wizard
Single Instance Storage (SIS) Groveler
RIS setup scripts
In addition, because RIS depends on Active Directory, and because changes were made to Active Directory in Windows Server 2003, after you upgrade a domain to Windows Server 2003, you must upgrade the RIS servers to Windows Server 2003 as well.
Pre-Boot Execution Environment
A RIS client must be able to create a small operating environment that has sufficient capacity to download the setup files from a server exactly as a human operator would do. The trick, then, is getting that operating environment delivered to the client. The process that controls this transaction is called the Pre-boot Execution Environment, or PXE.
A PXE client knows how to find a server that contains a startup image that the client can download and execute to create an operational environment. It is called pre-boot because the PXE client loads before an operating system has a chance to boot.
IA32 class machines built to the PC97 standards or later support PXE booting in BIOS. You often must configure CMOS to enable it and to set the boot order. IA64 machines have a boot menu option to launch PXE.
Even if the computer does not have a PXE boot ROM, many network cards have Ethernet controllers that support PXE if the executable code is available in memory via a boot floppy. PXE adapters must use the PCI bus, which eliminates laptops that use PCMCIA network adapters unless the laptop emulates PCI on the PC Card bus.
The PXE boot floppy is built using the Remote Boot Floppy Generator (RBFG) utility in the \RemoteInstall\Admin directory on the RIS server. See the "Creating PXE Boot Disks" section later in this chapter for details.
PXE clients use TCP/IP as a transport protocol, so they need an IP address before they can contact a RIS server. You cannot statically map an IP address for a client that lives completely in memory, so it must obtain its address from a DHCP server.
DHCP works a little like getting a beer at a ball game. You don't know the attendant's name, so you shout, "Hey, beer man, what'cha got?" The beer man shouts back an offer and you accept that offer and get a cold one. Here is a typical DHCP transaction:
The PXE client broadcasts a DHCP Discovery.
A DHCP server answers by broadcasting a DHCP Offer. The offer contains an IP address. At this point, the client has no IP address so the server cannot communicate with it directly.
The client broadcasts back a DHCP Request containing the IP address it got from the DHCP Offer packet.
The DHCP server unicasts back a DHCP ACK, sealing the deal. In this final ACK, the server includes configuration information such as the IP address of the gateway, the DNS domain suffix, the renewal interval of the address lease, and so forth.
If the DHCP server resides in a different subnet than the client, the intervening routers must be configured to pass DHCP broadcasts via DHCP/BOOTP relaying. As part of the relay, the router is configured with the IP address of one or more DHCP servers. It ferries DHCP broadcasts back and forth between the DHCP server and any clients requesting addresses. Keep this helper function in mind as you read the next section.
During a PXE boot, the client console displays the word DHCP with a series of dots during this part of the transaction. When the client gets an IP address, it displays the configuration information and you may see the message change to BINL for a few moments as it proceeds to the next stage.
Boot Information Negotiation Layer (BINL)
At this point, the PXE client has an IP address. Now it needs to know the identity of a server hosting a boot image. The PXE client is not very bright, so it uses the same DHCP transaction process to find a RIS server. The RIS server has a special service called the Boot Information Negotiation Layer, or BINL, that handles these special DHCP requests. Here's how it works:
When a PXE client sends out its initial DHCP Discovery packet, it includes the Globally Unique Identifier (GUID) that is burned into the PXE ROM. If there is no PXE ROM and the client is using a PXE boot disk, the GUID consists of the client's MAC address padded by 20 leading zeros.
When a RIS server sees a DHCP Discovery packet with a GUID payload, the BINL service responds with a DHCP Offer of its own. In this offer, the Client IP address field is left blank, indicating that this is not an offer of an IP address, and the payload includes a copy of the client's GUID.
At first, the client ignores this BINL offer. It is more concerned with getting an IP address. After the new address is bound to the IP stack, the client contacts the BINL server on UDP port 4011 with a second DHCP Request.
The server responds with a DHCP ACK that contains the name and path of the boot image. The name of this image is Startrom.com. See the sidebar, "Potential Problems with BINL," for more information.
The client now sends a Trivial File Transfer Protocol (TFTP) GET request to copy a file called Startrom.com.
The server responds by sending the Startrom.com file to the client.
At this point in the transaction, the client displays its IP address and MAC address and you may see a TFTP message flash by before the screen changes to display the Client Installation Wizard, described in the next section.
Client Installation Wizard
At this point, we're nearly finished with the initial transactions. The client executes the Startrom.com image. The image instructs the client to use TFTP to get two more files:
RIS has a lot of moving parts. It can be frustrating to come up with a configuration where the right clients get their IP and BINL information from the right servers.
Keep the broadcast nature of DHCP transaction in mind and don't forget about the DHCP/BOOTP helpers in the routers. For the most part, if you have one RIS server, it should be running on the DHCP server. This gives you the best chance for reliable packet exchange.
If, on the other hand, you have more than one RIS server, it's important not to put RIS on a DHCP server. This is because PXE clients will ignore additional BINL offers they get if the initial offer came from their DHCP server.
If you use DHCP/BOOTP helpers in your routers, the helper needs to include the RIS server in the list of IP addresses. Even then, depending on your router, this might not work. You might need a separate RIS server in each subnet.
Because BINL uses DHCP, the RIS server must be authorized in Active Directory just as you would authorize a regular Windows Server 2003 DHCP server. If the BINL server is not authorized, it will not respond to DHCP Discovery packets and your PXE clients will time out. Authorize the server by loading into a DHCP Manager console then right-clicking the server name and selecting AUTHORIZE from the flyout menu.
Another potential problem with the BINL transaction is the TFTP file transfer. It is possible to use a TFTP PUT command to copy files from a client to the server. This opens the possibility of putting a Trojan Horse file on the server in the form of a replaced Startrom.com file or one of the other support files. Microsoft has acknowledged this possibility, but at the time of this writing it has not published a fix.
The client then prompts to press F12 to begin the Client Installation Wizard, or CIW. See the sidebar, "Alternative Startrom Files," for ways to avoid the need to press F12. Figure 2.7 shows the Welcome screen of the CIW.
Figure 2.7. RIS Client Installation Wizard—Welcome screen.
The job of the CIW is to authenticate the person doing the installation and to display a list of installation images available for downloading. This list is called the OS Chooser (OSC). When the installer selects an image, the CIW downloads the files associated with the image and commences Windows Server 2003 Setup using those files.
The screens displayed by the CIW come from a set of OSC files on the RIS server in the folder \RemoteInstall\OS Chooser\English. These OSC files are simply text files based on HTML 2.0 format. You can open one with Notepad to see what it looks like. Because they are text, you can change the display, if you want.
Only a limited number of HTML 2.0 tags are supported in OSC files, so you don't get much leeway for creativity, but it's fairly simple to put additional instructions in existing OSC files or to build OSC files of your own. For example, you can create an OSC file that lets an administrator define the computer name and the target OU before continuing with the automated setup. See the "Customizing CIW Screens" topic later in this chapter for details.
After an initial welcome screen, CIW displays a Login.osc screen to obtain the user's credentials. Figure 2.8 shows an example.
Figure 2.8. RIS Client Installation Wizard—Login screen.
In Windows Server 2003, as with Windows 2000, any authenticated user can perform the installation. Users without administrator credentials are limited to ten installations. You can restrict who can perform installations using group policies. The authentication occurs via BINL (UDP port 4011) and uses NTLM Challenge-Response.
The remaining portions of the CIW consist of walking through a chain of linked OSC files until you get to the Choices.osc screen (see Figure 2.9). This lists the images that are on the RIS server.
Figure 2.9. RIS Client Installation Wizard—OS Choices screen.
When you select an item from the image list, the CIW loads the SIF script for the image from the \RemoteInstall\Setup\English\Images\WINDOWS\i386\templates folder. This script defines where to put the files, what name to assign to the machine, and controls other aspects of the installation. If any of these files are missing or incorrectly structured, CIW will give an error.
The final CIW screen, called Install.osc, displays the computer name, its GUID, and the RIS server name. Figure 2.10 shows an example.
Figure 2.10. RIS Client Installation Wizard—Installation Information screen.
In the background, the CIW creates a computer account in Active Directory using this same information. By default, the CIW creates the account in the Computer container, but you can change this default location. See "Configuring a RIS Server" later in this chapter.
SIS and the SIS Groveler
The title of this section sounds more like a cheap British romance novel than a technical discussion, but the topic is an important one for RIS.
A RIS server can host multiple images. It might have an image for Windows 2000 Professional, one for XP Professional, another for Windows Server 2003, Standard Edition, and still another for Windows Server 2003, Enterprise Edition. In addition, as we'll see in the "Creating RIS Images with Riprep" section, you can use the Riprep tool to create images of existing servers or desktops, further adding to the number of image files on the server.
The bootstrap image used by RIS client is contained in a file called Startrom.com. This file is located on the RIS server in the folder \RemoteInstall\OSChooser\I386. This is the path and filename given by the BINL service to the PXE client.
There are alternative Startrom files in the folder. One of them, Startrom.n12, does not require the installer to press F12. By renaming the original Startrom.com and replacing it with the alternative, the PXE client immediately goes into the Client Installation Wizard (CIW) after it gets the BINL acknowledgement.
If there is only one image at the RIS server, the CIW skips the OS Chooser list and goes right to the Install.osc window. So, with the proper setup, an administrator need only press the Enter key to start a RIS-based setup.
The \RemoteInstall\OS Chooser\I386 folder contains four other alternative Startrom files that are used when installing RIS on a headless server (a server without a mouse, keyboard, or video adapter). See section, "Using RIS for Headless Server Installations," later in this chapter for more information.
As you might imagine, these file-based images can consume a lot of disk real estate very quickly. Many of the files are redundant, though, so to reduce the rate of sprawl, Microsoft included a Single Instance Storage (SIS) that shares one copy of a file among the images that use it. The service is called the SIS Groveler, or Grovel.exe.
The SIS Groveler service runs separately from RIS. It maintains a folder called SIS Common Store at the root of the partition that holds the RIS files. The folder has the Hidden and System attributes set, making it a superhidden file. You can set group policies that prevent users from viewing superhidden files.
When you install two or more images on a RIS server, the SIS Groveler uses the idle time of the server to analyze the files and find those that are identical. It first catalogs the files by name and takes a hash of each file to act as a signature. The hashing algorithm is very sensitive to differences between files. If one bit is different, the signatures will be radically different.
Next, SIS decides which files are identical and compares them byte-by-byte. If the comparison validates that the files are identical, SIS copies the file from the two images to the SIS Common Store. It renames the file to a name that uses a GUID format (making it unique) and makes note of its origins in a database located in the same folder.
From a command line, you can determine if a file is real or a reparse point using the Fsutil utility. The syntax is as follows:
fsutil reparsepoint query <file_name>
Unfortunately, Fsutil does not accept wildcards nor will it report on an entire directory of files. A better tool for this purpose is the Remote Storage File Analysis utility, RSDIR, from the Resource Kit. This utility is designed to look for reparse points associated with the Hierarchical Storage Management (HSM) system, but it will also show reparse points created by SIS. Just run RSDIR in a directory to get a listing of the files and their attributes. An example listing looks like this:
non-HSM A------P--Z 0 78716 NA lanma256.bmp
The P means the file is a reparse point, and the Z means it is a sparse file. The logical file size is 78716 bytes, but its actual size is zero.
Finally, SIS replaces the file in the original folders with a reparse point of the same name. A reparse point uses a special NTFS record structure to point at a target file or folder. In the Explorer shell, when you view a reparse point, you see the contents of the target file or folder. The replaced files are also configured as sparse files, meaning that they report the same file size without actually taking up the space. See Chapter 15 for more information about reparse points and sparse files.
The SIS Groveler calculates how much idle time is available for it to do its work. The initial analysis takes a few hours, so don't expect to see any activity right after you install RIS. If you're in a hurry, you can force SIS to work in the foreground with standard resource sharing until it has analyzed and processed all files. This is done with the GROVCTRL utility. The syntax is grovctrl f.
The GROVCTRL utility is not installed by default. You must expand it from the GROVCTRL.EX_ file in the I386 folder on the Windows Server 2003 CD. You can also use it to initiate a volume scan, pause and continue, or stop and start the service.
SIS and File Recovery
It's important to keep the actions of SIS Groveler in mind because they impact your backup and recovery planning. Only backup utilities that use the Windows Server 2003 or Windows 2000 backup API understand reparse points and sparse files. In addition, to ensure proper handling of SIS files, Microsoft included a special filter DLL that exposes function calls that must be used to back up and restore files in the SIS Common Files folder. The backup utility must know that this DLL exists and use it when accessing SIS files.
It is also very important to have the SIS Groveler service running before you do a restore of the RIS files on a partition. The service coordinates with the backup DLL to ensure that reparse points are installed correctly. If you are transferring images to another server via tape restore, you can install RIS and then run Risetup -check to create the RIS folder structure and start the SIS Groveler.
RIS Setup Scripts
RIS uses a Setup Information File (SIF) to control where and how the file-based image is applied to a target drive. This SIF is structured similarly to an unattended setup script with a few different sections that are unique to RIS.
The SIF that controls a particular image is located in the image folder itself under \RemoteInstall\Setup\English\Images\WINDOWS\i386\templates. You can use Setup Manager (or Notepad, if you're familiar with the script layout and syntax) to create additional SIF scripts. For instance, you could have one script for computers in the IT department and another script for ordinary users.
The Client Installation Wizard (CIW) lists all the SIF scripts it finds in the templates folder. It uses a short Description entry and a Help entry in the script to give information about the script's intended use. When the person doing the installation selects the script, it is copied to \RemoteInstall\tmp and renamed using the GUID algorithm to ensure it is unique. The client downloads this script along with the setup files and it is used to guide Setup in its chores.
In addition to customizing the contents of the SIF using Setup Manager, you can capture information from the installer with custom windows in CIW. You can define up to 64 variables that can be instantiated in CIW then applied to entries in the SIF.
For example, let's say you want to use RIS to install the retail versions of Windows Server 2003, Standard Edition. This means you cannot include the Product Key in the SIF because it must be different for each installation. You can code a custom OSC file to ask for the Product Key in a CIW window and put the response in an environment variable. Then, in the SIF, set the ProductID equal to that environment variable. For example,
ProductID = %ProdKey%
See the previous section, "Creating an Unattended Setup Script," for details on using Setup Manager. When you use Setup Manager to build a RIS answer file, the wizard displays an option to specify the Setup Information File Text. This is where you would set Description and Help entries for display by the CIW.
Customizing CIW Screens
Because the screens displayed by the CIW during a RIS installation are simply text-based OSC files, they can be tailored to suit your particular needs. The markup language used to construct the OSC files displayed by the CIW is called OSCML, for OS Chooser Markup Language.
OSCML is a subset of HTML 2.0. Like HTML, you can define variables using OSCML, but a few have been reserved. See the sidebar, "OSCML Reserved Variables," for a list. Here is an example of how you can use those variables.
By default, when the CIW creates a computer account for a RIS client, it puts the account in the cn=Computers container. You can set a different default container as part of the RIS server parameters, but all computer accounts will be created in that OU. Sometimes you want the flexibility of defining where the account will be created.
You could tailor the installation by creating a new OSC file. Call it CHOOSEOU.OSC, although any 8.3 name would be satisfactory. Copy the contents of another OSC for a template. Replace the body with short form that asks for an entry from the user:
OU to create computer account: <INPUT NAME="MACHINEOU" MAXLENGTH=255>
The user input collected by the Input command will be placed in the Machineou variable. The form action sends the user to the Warning.osc window after pressing Enter. This warns about erasing the hard disk and is displayed just prior to the Install.osc screen where Setup is initiated. You can view the results of Chooseou.osc by modifying Install.osc to display the contents of the Machineou variable.
Here is a list of the OSCML variables that have been reserved for a specific use:
Defines the language of the OSC files.
Used for error handling.
The container where the computer account will be created.
The display name of the computer account in Active Directory, such as SERVER1.
The SAM-Account-Name assigned to the computer. This is the MACHINENAME with a $ suffix, such as SERVER1$.
The name of the RIS server.
The domain to which the RIS server belongs.
The domain the RIS client will attempt to join.
The path to the Startrom.com file at the server.
The path to the SIF file. By default, this is the temp file copied from the image template folder.
A variable for holding the results of an Enum command, which lists the SIF files in a given folder.
The path to the source of a Riprep image.
The path to Riprep drivers used for PnP.
The path to the folder holding the initial installation image files. This is sometimes called the "flat" image.
The MAC address of the client.
The GUID of the client. For RBFG clients, there will be 20 zeros and the MAC address.
The client hardware, which would be I386 for an Intel machine.
Username, Password, Userdomain.
Used to perform authentication. Password is not stored at server and is overwritten in memory at the client.
The server's time zone.
Figure 2.11 shows a custom CIW window that uses several of these variables to display information to the installer.
Figure 2.11. RIS Client Installation Wizard—Custom screen using OSCML variables.
You can also check the results of your work at the Install.osc window by going to the domain controller and opening the AD Users & Computers console to verify that the computer account was created in the OU you selected.
Creating RIS Images with Riprep
RIS is a great way to perform a clean install of the operating system, but leaves you with the chore of installing applications. You can avoid this chore by using a utility that comes with RIS called Riprep. The Riprep utility creates an image of an existing server or desktop that is copied to the RIS server and made available as an option in OS Chooser. Like Sysprep, the Riprep image preserves the application files and their Registry settings.
Riprep creates file-based images, not sector-based images such as those created by Ghost or DriveImage. Its primary advantage over the sector-based imaging products (other than its price) is that the resultant image is not as dependent on similar hardware. Riprep images are superior to images created by the other file-based imaging utility, Sysprep, for the same reason. The only hardware dependency in a Riprep image is the Hardware Abstraction Layer (HAL) driver. An image from a machine with an ACPI HAL cannot be installed on a machine with a non-ACPI HAL. Windows Server 2003 can determine a suitable HAL for the client and modify the Riprep image accordingly.
The reason that a Riprep image can be so flexible is that it obtains files from a standard CD-based installation image. This so-called "flat" image contains the additional files that fill in the gaps on a machine that doesn't have similar hardware as the original machine.
Start by configuring a server or desktop exactly as you'd like it to work. Install any applications you want to run. All files must be on the same partition that holds the Windows system files (\Windows or \Winnt directory). Riprep can only image the system partition.
Also, by default, RIS takes the entire boot drive as the operating system partition. The target drive for the Riprep image must be at least as big as the source drive. You'll need 2GB for the operating system plus necessary free space. Allot additional space to applications. Don't create an image on a partition that will be too big to fit on your other servers.
When the source machine is ready for Riprep imaging, proceed as directed in Procedure 2.5.
Procedure 2.5 Using Riprep to Image a Windows Server 2003
At the server you want to image, map a drive to the REMINST share on the RIS server.
Navigate to the \Admin\I386 folder.
Run Riprep. The Remote Installation Preparation Wizard opens.
Click Next. The Server Name window opens. Enter the fully qualified DNS name of the server. (You can use the flat name if you are sure that the DNS resolver will append the correct DNS domain.)
Click Next. The Folder Name window opens. Enter the folder name where you want to place the files at the RIS server. Do not enter a path. RIS will resolve the path for you.
Click Next. The Friendly Description and Help Text window opens. Enter a descriptive name for the image that will help someone to select it from the Client Instal lation Wizard.
Click Next. The Report System Compatibility window opens. This window reports if elements of the image may not work correctly with RIS. Correct any problems and then start over.
Click Next. The Stop Services window opens. This window lists the local services that must be stopped while the RIS image is built. The list comes from a Riprep.INF file in the same folder as Riprep.
Click Next. The Stop Services window shows each service as it stops. If an error is encountered, it will be listed in a Riprep.LOG file in \RemoteInstall\Setup\English\ Images\<Riprep_Image>\i386.
If you have applications open, the Programs or Services Running window opens to prompt you to close them.
Click Next. The Review Settings window opens. Check the entries to ensure they are correct.
Click Next. Riprep processes the request and begins copying files to the RIS server. This may take a while depending on your network speed.
When Riprep images a disk, it creates a folder named with the short name of the image. A Mirror1 subfolder under that main folder contains the installation files. Riprep also creates a Templates folder that contains a Riprep.sif file that acts as the mini-setup script for the image.
You can tailor this script to modify the image installation. If you need to make changes to the image files themselves, you must install the image on a machine, change the files, then re-image the machine.
Here is a recap of the Riprep requirements mentioned elsewhere in this section:
Only boot partition imaged.
Only the partition with the Windows system files (\Windows or \Winnt) is included in the image. If you have separate data partitions, you must deal with them in a separate process.
Pre-existing flat image.
RIS depends on the installation files in a flat image to perform initial functions on a machine. You cannot Riprep a machine until you create a flat image from the CD of the same operating system.
The hard drive of the target machine must be at least as big or bigger than the hard drive of the imaged machine. This is because the image stores a copy of the partition boot sector from the imaged machine. RIS can expand a partition beyond the partition size in the boot sector, but it cannot make it smaller.
The target machine must use the same HAL as the imaged machine.
Creating PXE Boot Disks
Only machines built to the PC97 standards or later will support PXE booting. If you have an older machine, you can still use RIS as long as the machine contains an Ethernet controller that supports PXE booting or a network adapter with a PXE-compatible Ethernet controller.
You can build a PXE boot disk using the Remote Boot Floppy Generator utility, RBFG, in the \RemoteInstall\Admin\I386 folder. Figure 2.12 shows an example of the RBFG interface. The Adapters button opens a window that lists the supported adapters.
Figure 2.12. Remote Boot Disk Generator main window.
There's only one small caveat to using the PXE boot floppy rather than booting to a true BIOS-based PXE session. The network card has no GUID, so the computer account created by the CIW will only use the MAC address for the GUID padded with 20 leading zeros. This means that if you move the network card to another machine and attempt to do a RIS installation, you will get a "duplicate GUID" error.
If this happens, you must delete the original computer object. If the computer object is still in use by the original computer but you swapped out the network card, you can use the ADSI Editor from the Support Tools to change the RemoteBoot-GUID attribute to match the new MAC address. Obtain the MAC address by running ipconfig /all from the command line.
RIS Volume Requirements
Like any remote booting service, RIS depends on an image file loaded across the network to the remote boot clients. RIS gets persnickety about the disk volumes that hold the boot image. The following rules apply:
The volume cannot be the same as that holding the Windows Server 2003 system files.
The volume must be formatted NTFS.
You'll need at least 800MB–1000MB of free space.
If you do not meet these requirements, RIS will not work correctly and you'll end up redoing a lot of work.
To install the RIS driver files, follow the steps given in Procedure 2.6.
Procedure 2.6 Installing Remote Installation Services
Select a server to host the RIS boot images. The server itself does not need to be a domain controller, but it must be a member server of a Windows Server 2003 domain.
In Control Panel, open Add/Remove Programs.
Click Configure Windows. The Add or Remove Windows Components window opens.
Click Components. The Windows Server 2003 Components window opens.
Select Remote Installation Services and click Next. The installer does its work and then prompts you to restart. Do so.
This only installs the services and support files on the server. You still need to install and configure a RIS image.
RIS Image Configuration
After installing RIS, to configure a remote installation image, follow the steps given in Procedure 2.7.
Procedure 2.7 Configuring a Remote Installation Services Image
Insert a Setup CD for the operating system you want to use for an image. Supported operating systems include Windows 2000 Professional and Server and Advanced Server; XP Professional; and Windows Server 2003, Enterprise Edition.
Launch START | PROGRAMS | ADMINISTRATIVE TOOLS | REMOTE INSTALLATION SERVICES SETUP. This starts the Remote Installation Wizard, Risetup.
The Welcome window opens. If the server is not a member of a Windows Server 2003 domain, or cannot find the domain controller in DNS, Risetup will fail with an error telling you that the domain could not be located. If the directory configuration for the RIS server is incorrect, the client may not be able to find the RIS, and you will get a similar error.
Click Next. The Remote Installation Services Options window opens. Select Add A New OS Image To This Remote Installation Server.
Click Next. The Installation Source Files Location window opens. Enter the drive letter of the CD.
Click Next. The Windows Installation Image Folder Name window opens. Enter the name you want to assign to the image folder on the RIS server. An example is Adv_Srvr.
If you have existing remote boot clients in your network, or you have another RIS server, you may want to leave the RIS service disabled until you're ready to initiate deployment.
Also, you must stop and start RIS every time you make the slightest change in the image or the RIS configuration. You'll be making lots of changes at first, so it's easier to leave the service disabled until you're ready to use it.
Click Next. The Friendly Description and Help Text window opens. Enter names that help identify the image from the list in the Client Installation Wizard (CIW).
Click Next. If you already have images on the RIS server, you'll be asked how you want to deal with the existing CIW screens. Select Use The Old Client Installation Screens unless you want to overwrite them.
Click Next. The Review Settings window opens. If you made a mistake in any of the previous windows, now is the time to change it.
Click Finish. Risetup now copies files from the Windows Server 2003 Workstation CD to the RIS directory. You'll get an informative checklist showing the progress. The last item on the checklist is Starting the Remote Installation Service.
Configuring a RIS Server
There is no separate MMC console for managing RIS. All configurations are performed using the computer object in Active Directory. Procedure 2.8 shows how to configure the server.
Procedure 2.8 Configuring a Remote Installation Services Server
Load the AD Users and Computers console from START | PROGRAMS | ADMINISTRATIVE TOOLS.
Find the computer icon for the server running RIS.
Right-click the icon and select PROPERTIES from the flyout menu. The Properties window opens.
Select the Remote Install tab.
Click Advanced Settings. The Remote Installation Services Properties window opens (see Figure 2.13).
Figure 2.13. Remote Installation Services Properties—Advanced Settings window.
In the New Clients tab, under Automatic Computer Naming, click the combo box under Generate Client Computer Names Using (see Figure 2.14). See the sidebar, "Custom Computer Names and RIS," for information about what to select here.
Figure 2.14. Computer Account Generation window.
Under Computer Account Location, select A Specific Directory Service Location.
Click Browse and select a container where you want the computer objects created by this RIS server to be placed.
Select the OS Images tab. The list contains the names of images you have configured with Risetup, Riprep, or custom SIF files you have created with Setup Manager.
If you want to add a new flat image, put the Windows Server 2003 CD in the CD-ROM drive and click Add.
Click OK to return to the Remote Install tab under Properties.
Click OK to save all changes and close the window.
Go to a command prompt. Stop and start the BINLSVC service as follows:
NET STOP BINLSVC
NET START BINLSVC
RIS has several options for automatically naming computers. Some of these options involve associating a computer name with a username. This is rarely a good idea in large organizations where computers get traded regularly between users. A better choice, if you want automatic naming, is to use the MAC address. This is a clean way to get a unique name that won't change unless you change the network adapter.
The default naming format prefixes the MAC address with the letters NP. A character-based prefix is important because some TCP/IP utilities, such as Ping, do not work if the host name starts with a numeral.
Instead of NP, you might want to preface the MAC address with two or three letters that designate the workstation's location. Click Advanced to change the prefix. Prefixes help sort out workstations on Browse lists. They aren't required for directory browsing because you'll probably put workstations into local containers; until you have completed the transition to Active Directory, however, you should make provision for classic NT browsing.
Controlling Access to RIS Images
You probably don't want users or visitors to accidentally or deliberately image their machines. A machine should not commence a PXE boot unless all other media have failed, but it's a strange universe and all sorts of inexplicable things happen.
You can take several precautions to protect your images from accidental download. First, you can set permission on the images so that only members of a selected group can see them. If there are no images available to OS Chooser, CIW will error out. Procedure 2.9 shows how to set the permissions.
Procedure 2.9 Setting Permissions on RIS Images
Load the AD Users and Computers console from START | PROGRAMS | ADMINISTRATIVE TOOLS.
Find the computer icon for the server running RIS.
Right-click the icon and select PROPERTIES from the flyout menu. The Properties window opens.
Select the Remote Install tab.
Click Advanced Settings.
Select the Images tab.
Highlight an image and click Properties. This opens the Properties window for the SIF file representing the image.
Click Permissions and then select the Security tab.
Set the permissions to permit or deny access to the image. Anyone not permitted access to the SIF file will not see the image in the CIW.
You can also restrict a RIS server to distribute images only to computers that have been pre-staged for RIS installation. This permits you to be selective with the machines that can accept an image. For example, you might not want to image a certain class of machine, and by not pre-staging them, you avoid accidental drive erasure.
Pre-staging involves designating a computer object as "managed" in Active Directory. This requires that Active Directory contain a computer object and an associated GUID for each computer that will be given a BINL offer.
The simplest way to pre-stage the computer is to walk through a RIS installation right up to the Install.osc screen, the final information screen where the computer name, RIS server name, and GUID are displayed, using a RIS server in your lab that is configured to distribute images to any client. As part of the Install.osc window, the CIW creates the computer object and populates it with the GUID taken from the PXE network interface. You then stop the machine and deliver it to the deployment team, where it can start the RIS install again on the floor from a RIS server that has been configured to accept requests only from "managed" clients.
As an alternative, you can jot down the GUID from the computer's CMOS, create the computer object, and type the GUID manually into the object's Properties window.
Verifying RIS Server Configurations
The Remote Install properties for a RIS server in Active Directory contain a Verify Server button. This button starts Risetup to check the contents of the top-level RIS folders and then starts the RIS-related services BINLSVC and Groveler. It does not verify the contents of the image folders and it does not verify the OSC files. You can perform the same operations by running Risetup -verify from the command line.
Controlling RIS with Group Policies
As we'll see in Chapter 12, it's possible to control nearly every facet of system operation with group policies in one way or another. Some group policies make their mark in the Registry. Others, like sinister political operatives, make changes to the security database that controls permissions and privileges on a machine. One group policy controls elements of the Client Installation Wizard. Access the policy as described in Procedure 2.10.
Procedure 2.10 Accessing the Remote Installation Group Policy
Open the AD Users & Computers console.
Right-click the domain icon and select PROPERTIES from the flyout menu. This opens the Properties window.
Select the Group Policy tab.
Double-click the Default Domain Policy to open the Group Policy Editor snap-in.
Drill down to USER CONFIGURATION | WINDOWS SETTINGS | REMOTE INSTALLATION SERVICES.
In the right pane, double-click the Choice Options icon. This opens the Choice Options Properties window.
The Remote Installation group policy has four options, all of which are applied depending on the location of the user object in Active Directory. Because we've opened the Default Domain policy, any user in the domain would be bound by the settings made here. Here are the options:
This is the default operation of the CWI. The user gets the settings defined in Active Directory for the RIS server. Disabling this policy means that the user will get the Custom Setup window in the CWI.
This option enables showing an additional window in the CWI where the installer can input a computer name and OU. These options override the AD settings for the RIS server.
This option enables the user to commence a RIS transaction using the inputs that were entered prior to loss of connection. This option does not affect the graphical portion of Setup. If you proceed beyond the text-mode portion of Setup and you select this option, you will overwrite everything downloaded previously. That is the reason it is disabled by default.
Third parties and Microsoft can develop tools that could run in the real-mode environment of PXE. For example, 3Com has a set of tools for modifying the RIS menus so you can change adapter settings and flash the system BIOS using RIS. Part of enabling those tools involves changing this policy from its default setting of Disabled to Enabled.
Using RIS for Headless Server Installations
A headless server has no mouse, no keyboard, and no video adapter. It sits in its rack like a leaf on a tree, doing work and producing output without any noticeable external activity other than a flashing LED or two.
Most IT shops have server rooms that conserve space and power by sharing a single Keyboard/Video/Mouse (KVM) among various servers using a KVM switch. There is a long list of vendors who have cunning solutions that pack features and flexibility into their KVM switches.
Still, the ideal would be to need no KVM at all. This is the concept behind headless servers. All server management is done via terminal services sessions (called Remote Desktop in Windows Server 2003) and command-line consoles such as telnet. Windows Server 2003 is designed to facilitate headless operation as much as possible. There is a large number of new command-line utilities that simplify telnet management and boatloads of scripting features.
Still, there's a chicken-and-egg problem to overcome. How do you get the operating system loaded on a headless server? Sure, you can install a video card and connect the server to a KVM switch long enough to run RIS or Sysprep, but there's something aesthetically displeasing about this approach, isn't there? A headless server should be headless from the beginning, a true species and not some guillotined apparition.
Windows Server 2003 supports operating system installation on a headless server via RIS and a suite of features collectively called Emergency Management Services, or EMS. One EMS feature is the capability to redirect text-based output from the console during startup and setup to a COM port. You can connect a modem to the COM port (or a port from a classic serial port terminal server) and make Out-of-Band (OOB) connection to the server. Using this OOB connection, you can make your selections in the Client Installation Wizard to kick off the RIS installations.
Configuring RIS for Headless Servers
Recall that a PXE client will initiate a RIS session automatically if there is no media with an operating system. All that's necessary, then, is a way to tell the PXE client to redirect its output to a COM port. This is done using a special Startrom image.
Open the \RemoteInstall\OS Chooser\I386 folder on a RIS server and look at the files. You'll see four that start with HDLS*, for Headless. HDLSCOM1.COM redirects output to the COM1 port and HDLSCOM2 does the same for COM2. The *.N12 versions permit you to skip pressing F12, which is something you will want to skip because many terminal emulators don't know how to pass F12 on to its peer. Follow the steps in Procedure 2.11 to run Setup on a headless server using RIS.
Procedure 2.11 Using RIS to Run Setup on a Headless Server
Connect a null-modem cable between the COM ports of the management computer and the headless server.
At the RIS server, rename Startrom.com to another name and rename HDLSCOM1.N12 to Startrom.com.
Launch a terminal emulator console on the PC that is connected (logically or physically) to the COM1 port on the server and make the connection.
When that's ready, start the server with no operating system on any bootable media. (If you have a server that supports OOB control of the hardware or true Wake-On-LAN, you could do this startup from a distance, as well.)
In the console, you should see the server start its PXE boot. Then, when it contacts a DHCP and RIS server, it will bring up the Welcome screen of the CIW. (There's no need to press F12 because of the Startrom version we picked.)
Walk through the CIW. When you're ready to start the installation, press Enter and watch the fun.
You'll only be able to see the text-based portions of Setup. At some point, like the Apollo astronauts hitting the atmosphere at reentry, you'll lose OOB contact. If everything goes well (meaning that you have configured the RIS setup script correctly and there are no hardware glitches), about 30 to 40 minutes later, Setup should be complete.
All Windows Servers come with a two-session version of Remote Desktop as a standard component of the operating system. You must log on with administrator credentials to use one of these sessions. As soon as Setup has completed and the machine restarts for the final time, you should be able to make a Remote Desktop connection so you can make your final configurations.
In Windows 2000, only administrators were given permission to use the two-session Terminal Services connections to manage a server. In Windows Server 2003, access to this feature is controlled by the Remote Desktop Users group. Anyone you put in this group can gain access to a server if he has sufficient privileges.
If you need a fast, convenient way to deploy large numbers of servers and desktops with diverse hardware specifications, RIS is definitely worth the time to configure. Common problems include the following:
Failure to authorize the RIS server in Active Directory. Without authorization, the BINL service will not respond to Discovery packets.
Not running RIS on a server that is in the same broadcast segment as the client or failure to configure DHCP helpers on intervening routers.
Not installing the proper "flat" image from CD prior to running Riprep.
Failure to properly back up and restore SIS files.
Trying to use older PXE clients. The client should be running PXE version .99 or later.
Trying to image multiple partitions using Riprep.
Trying to apply a Riprep image to a machine with a smaller hard drive than the original machine.
Changing the RIS group policy without informing colleagues who might be affected.