What Is RIS?
Remote Installation Services (RIS) is an optional feature included with Windows 2000 that enables you to install operating systems on remote boot-enabled clients. Files are transferred across the network to the local system, and the standard Windows 2000 Setup process runs in unattended mode, including text-mode and GUI-mode setup. RIS uses PXE (Pre-boot Execution Environment) to boot directly from the network card to initiate an OS install. Some systems without a PXE-enabled network card can use a simple boot disk with a PXE emulator to emulate the PXE ROM of a NIC card and PXE BIOS support.
PXE and BINL:
A workstation with a PXE-enabled NIC must first be configured to boot to the network in the computer's BIOS. When a PXE client is turned on it sends out a DHCP discovery packet and as part of the initial DHCP discover request, and identifies itself as being PXE-enabled. It requests an IP address and the IP address of a RIS server through the DHCP protocol and the PXE extensions to the DHCP protocol. As part of the initial request, as a DHCP option, the client sends out its GUID, which is used to identify the client in Active Directory. The client receives an IP address from the DHCP server and the IP address of the RIS server. After the client receives this information, it contacts the RIS server, using the Boot Information Negotiation Layer (BINL). BINL provides the location and filename of the bootstrap image to the client. The client then uses the Trivial File Transfer Protocol (TFTP) to download and execute the image. In the case of RIS, this file is Startrom.com. Startrom.com uses TFTP to download the OSChooser, and presents the user with the Client Installation Wizard.
The process of initial communication between PXE clients and RIS servers can differ depending on how RIS is deployed in relation to DHCP services. MIT’s implementation is slightly different from the way Microsoft outlines it below because our PXE clients don’t get DHCP offers from the RIS server, so the behavior is more like the DHCP and RIS on the Same Server scenario even though we are using DHCP and RIS on Separate Servers.
DHCP and RIS on Separate Servers
1. DHCP discover from client (asking for IP address and PXE boot server).
2. DHCP offer from DHCP server (offers IP address and other network configuration settings).
3. DHCP offer from RIS server (offers PXE boot server).
4. DHCP request from client to DHCP server (requesting IP address).
5. DHCP acknowledge message from DHCP server (you can have this IP address).
6. DHCP request from client to RIS server (requesting the boot server).
7. DHCP acknowledge message from RIS server (this acknowledgment contains the address to the RIS server and the first file that the client needs to send a TFTP request to start the boot process).
DHCP and RIS on the Same Server
1. DHCP discover from client (asking for IP address and PXE boot server).
2. DHCP offer from DHCP/RIS server (offers IP address and PXE boot server).
3. DHCP request from client to DHCP server (requesting IP address, network configuration settings, and PXE boot server).
4. DHCP acknowledge from DHCP server (contains IP address and the RIS server IP and the first file to download).
If you configure the RIS server to respond only to known clients — that is, clients prestaged in Active Directory or previously installed computers — and the computer object is not located in Active Directory, the RIS server fails to respond to the client's DHCP request. If the RIS server is not on the same server as the DHCP server, then the DHCP offer from the RIS server (step 3) is not sent and therefore step 6 and step 7 do not occur. If the RIS server and DHCP server are on the same computer, the DHCP offer from the DHCP/RIS server (step 2) only contains IP information and no information about any available servers to support the client's network boot process.
MIT’s DHCP servers currently have PXE enabled on a per subnet basis. This means that for those subnets, special DHCP scopes have been created for PXE clients. We are also using DHCP Vendor Classes to distinguish PXE clients on the network. When the MIT DHCP server receives a PXE request, it supplies the client with an IP lease from such a scope plus the IP address of the RIS server. Once the client has obtained an IP lease, it can then use the information (the IP of the RIS server) it obtained from the DHCP server to contact the RIS server directly. If a DHCP request is made with the vendor-identifier = 'PXE*', the DHCP servers will assign it an address if the client asks for one and return server=rin.mit.edu, boot file="OSChooser\\i386\\startrom.com" if the client asks for that.
On MIT’s network, if the PXE client is not on a subnet where a scope has been created for PXE requests, we found that when the MAC address of the client is first registered as if it were a regular DHCP client, the DHCP server will then pass along to the client the IP of the RIS server for it to contact directly.
Once the client has successfully downloaded and executed the Client Installation Wizard, someone must log onto the client. After a successful user logon, RIS checks the Active Directory to see whether the machine account has been pre-staged. If so, RIS takes client configuration information from the Active Directory and starts the installation of Windows 2000. If the client hasn't been pre-staged, the Client Installation Wizard prompts the user to select an image, and then runs a complete unattended install of Windows 2000 Professional.
MIT RIS clients are prestaged in Moira with their container mapping. The machine account is created in Active Directory when the Client Installation Wizard is run after the machine information is entered. The user logs on to the domain via the Wizard and enters machine name, IP, and subnet mask. There is an option to specify OU, but it is not used because we have already prestaged the container mapping in Moira.
PXE Emulator Disk:
When PXE is used when installing systems with RIS, the NIC must have a PXE ROM with version .99c or greater, and the system BIOS must support booting from a network card. If you have an out-of-date PXE ROM, it may be flash-upgradeable. Otherwise, 3COM provides a PXE ROM emulator included in RIS to allow a client to take advantage of the PXE connection process by booting to a floppy disk. You can run the Remote Boot Floppy Generator utility directly on the RIS server, or remotely from the “reminst” share. It resides in %systemroot%\SYSTEM32\REMINST\RBFG.EXE. The following list shows the NICs supported by the remote boot floppy:
3Com 3C900B-Combo
3Com 3C900B-FL
3Com 3C900B-TPC
3Com 3C900B-TPO
3Com 3C900-Combo
3Com 3C900-TPO
3Com 3C905B-Combo
3Com 3C905B-FX
3Com 3C905B-TX
3Com 3C905C-TX
3Com 3C905-T4
3Com 3C905-TX
AMD PCnet Adapters
Compaq NetFlex 100
Compaq NetFlex 110
Compaq NetFlex 3
DEC DE450
DEC DE500
HP DeskDirect 10/100 TX
Intel Pro 10+
Intel Pro 100+
Intel Pro 100B
SMC 8432
SMC 9332
SMC 9432
RIS and Active Directory
Your RIS server must be a member of an Active Directory domain. To allow a DHCP or RIS server to service network clients, you must authorize the server providing the service in Active Directory.
DHCP must assign TCP/IP configuration information to PXE clients, or they won't be able to access the RIS server. A Windows 2000–compliant DNS service is normally required so the RIS server will be able to find the domain controller. Active Directory provides client authorization and configuration information to the RIS server during the client install process.
DNS must be updated to a version compliant with the Windows 2000 Dynamic DNS requirements, which includes support for the following standards. RFC 2052: The service location resource record (SRV RR). Support for SRV records is mandatory—if your DNS server doesn't handle these resource records, you can't use it in conjunction with Active Directory. The NT 4.0 Server DNS Service is not compliant with these requirements and won't support RIS. If you're using BIND, versions 8.1.2 and above support the required protocols. The SRV RR is the DNS component that tells any Active Directory–aware DNS client where to find a domain controller. Active Directory then tells the client where to find a RIS server. The Dynamic Update standard allows the client to register in DNS, so the RIS server will know how to find and address the client.
However MIT’s implementation differs from Microsoft’s standards here. The DHCP servers are pointing all PXE clients to a specific RIS server instead of looking for an appropriate server within Active Directory. However, to respond to PXE clients, the RIS server still requires that it be registered within Active Directory. WinAthena clients cannot use the Dynamic Update standard to register in DNS, and this option can be turned off on the clients
Installing RIS:
RIS puts a load on a server's network bandwidth and disk usage. Never run RIS in a production environment on an Active Directory domain controller. The high traffic load from the RIS client installs could potentially affect the ability of the domain controller to authenticate clients.
You install RIS on a Windows 2000 server just as you would install any other server component. You can select Remote Installation Services as an optional component during the initial OS install, or use the Add/Remove Windows Components screen in the Add/Remove Programs applet in Control Panel. You must already have installed and configured the DHCP, DNS, and Active Directory services in your environment.
Once installed, to setup RIS, run RISETUP.EXE if not prompted automatically by the RIS Installation Wizard. You will be prompted for drive and folder location for the RIS server data. The will be the root directory for RIS images and other data. RIS requires that you format this drive as NTFS. You should select a folder on a volume that will be dedicated to RIS. You can't select the same volume on which your system files are located. Preferably, the RIS volume should be on a dedicated physical disk to reduce system performance degradation associated with the RIS disk activity.
After selecting the RIS files location, RISSETUP asks whether to enable the service at the end of setup. By default, RIS won't service client requests at the end of setup unless you check the box on this Initial Remote Install Server Settings screen. If you choose to configure the server to respond to client computers on completion of the wizard, you can select the Do Not Respond to Unknown Client Computers option to prevent computers without accounts in the Active Directory from receiving an image. If you select this option, you must pre-stage the computer account in Active Directory.
To authorize a DHCP or RIS server, follow these steps: Start the DHCP management console from the Administrative Tools menu. Select the DHCP node. From the Action menu, select Manage Authorized Servers. In the Manage Authorized Servers dialog box, click the Authorize button. In the Authorize DHCP Server dialog box, enter the IP address or the computer name of the DHCP or RIS server and click OK. Even though this dialog doesn't mention RIS, you can authorize RIS servers or DHCP servers from this box. The server name and IP address should now appear in the Authorized DHCP Servers list. Select the Close button to close the Manage Authorized Servers dialog.
Services Installed by RIS
Boot Information Negotiation Layer (BINL): Provides the ability to install Windows 2000 and XP on PXE remote-boot–enabled client computers. This is the part of RIS that negotiates the handling of the OSCHOOSER executable on the client, initializing the Client Installation Wizard.
Trivial File Transfer Protocol (TFTP): Implements the Trivial FTP Internet standard, which transfers files without the requirement of a username or password. This server protocol passes both the Client Installation Wizard *.OSC menus and the source files from the server to the client.
Single Instance Store Groveler (SIS): Scans Single Instance Store volumes—in this case, the RIS volume—for duplicate files, and points duplicate files to one data storage point, conserving disk space.
SIS Groveler service:
The SIS groveler service periodically scans the disk, looking at filenames, dates, and sizes, making sure to get all original files. If you have two identically named files with the same file date and file size, SIS compares the contents of the files to make sure that they're identical before adding the instance to the file store. If identical, both files are replaced by links into the Single Instance Store, and the original file is renamed with a 128-bit GUID and stored in the common store. SIS tracks the number of links to any files in the data store so the system can delete original files when they're no longer required. When there's sufficient space on the RIS partition, the SIS groveler will only perform linking operations during relatively idle times. After reaching a certain free-disk-space threshold, the SIS groveler becomes somewhat more aggressive, scanning drives as files are copied.
File links on the RIS volume still appear as individual files; the link file even appears to occupy the same amount of disk space as the original file. In reality, the file link only occupies a single cluster of physical disk space. When SIS file links are accessed, the link file points to the location of the original file in the common store, and the file is retrieved and manipulated accordingly. If you save additional files to the RIS volume—meaning files not required for RIS or RIPREP images—the SIS Groveling Agent still processes the files. This is why it's recommended to dedicate an entire drive to the RIS file store. Files that change frequently are not recommended for storage on a SIS volume
Adding RIS Managed Computer Accounts to the Active Directory
If you choose to configure the server to respond only to authorized clients, you must add accounts for authorized computers to Active Directory before the users will be able to install their systems. You must know the GUID (Global Unique IDentifier) for the computers
The GUID is a 128-bit (32 hex characters) unique identification number, and it should be available either in the BIOS or on the initial screen visible when booting via PXE. Some vendors provide the GUID associated with a system on the outside of the box or on a spreadsheet or floppy disk included with a new system. The GUID can also be obtained during the PXE boot sequence from the DHCP discover packet. If a machine doesn't have a GUID, you can calculate it by prefixing the MAC address with enough zeroes to create an address of exactly 32 characters.
To add a GUID manually: Open the Active Directory Users and Computers management console. Add a new computer account in the desired organizational unit (OU), enter the computer name as you would for any other computer account, and click Next. The next screen provides a check box labeled This Is a Managed Computer. Select this option to enable the GUID entry box, and enter the GUID for the PC you want to add. The next screen enables you to select a specific RIS server to service a request from the managed client. This allows rudimentary selective load balancing and location-based installation services.
When the client machine with the associated GUID connects, you have pre-staged the computer account in Active Directory. The client will be forced to comply with the information in Active Directory; the end user doesn't need to worry about assigning the correct computer name, choosing the correct organizational unit, or specifying the correct RIS server.
Assigning permissions to RIS accounts:
The account used to run RIS installations requires the Logon as a Batch Job right and the right to create computer accounts in the required computer containers. From the RIS server, open the mmc with the Group Policy snap-in, and make sure that the group policy is for managing the local computer. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment, and double-click the Logon as a Batch Job right. Add the group containing the user accounts for users that need permission to set up RIS clients. Next, right-click the destination container for computer accounts in the Active Directory Users and Computers mmc, select Delegate from the pop-up menu, and use the Delegation Wizard to configure RIS users with the right to join computers to the domain.
MIT’s WIN domain uses an account called .ris which can be used for any RIS install unless special acl’s have been placed on certain images by administrators for special use. This account has already been granted the necessary rights described above. The account credentials are entered by the user when the Client Installation Wizard is run.
Creating a RIS image:
After you install RIS, setup will start the RIS setup wizard, RISETUP.EXE. This wizard is used to create images on your installation. It will ask you for source files for your install such as a CD-ROM or some other customized source you have created. After you point to the source files, the next screen requests an installation image folder name. This is where the server will store the image files. The folder will be created as a subfolder under the RIS server service main folder. After selecting a subfolder, name and describe the install you're creating. This descriptive name and help text will be displayed during the text-based Client Installation Wizard, which the user will see when installing a machine using RIS. The final screen of the wizard summarizes and confirms the options you selected from the wizard. Once you've confirmed or corrected any necessary entries, click Finish, and the initial RIS server installation and configuration will be complete.
Once the RISETUP wizard has completed, the files needed to create a basic image are present and available on the RIS server. This image uses a generic default answer file. You can create a custom remote install answer file through the Setup Manager Wizard, and associate that answer file with the existing default CD image installation installed on the RIS server, or modify the file manually.
Limit RIS Options with NTFS Permissions:
To limit the images that can be selected by a user, use NTFS security on the associated *.SIF answer file. To prevent an image from showing in the selection list, simply remove or deny the read permission for the appropriate user groups.
Customize OSCHOOSER Screens with OSCML:
The OSCHOOSER screens are the text screens displayed to the user during the Client Installation Wizard. These screens are formatted in OSCML, an OSCHOOSER-customized version of text-only HTML, based somewhat on a subset of HTML 2.0. The files have an *.OSC extension, and can be found in the RIS share in the oschooser directory. These files can be customized to fit specific needs.
RIS Default Configuration:
The default options during the setup and configuration places the files and folders as \\\ UNC, the share created during the initial setup of RIS. In the paths, refers to the processor architecture (for example, i386), and refers to the default language of the source install (for example, English):
\Admin\: Location of RIPREP.EXE and RBFG.EXE files.
\OSChooser: Location of default *.OSC files used by the Client Installation Wizard. Language-specific client screens are under subfolders, and platform-specific boot files used to run the OSCHOOSER boot loader are under subfolders.
\Setup\\Images\: Subfolders containing source files for both CD-based and RIPREP based image can be found under this location. Important files and folders under the \\\\Setup\\Images\![]()
\ subfolder are as follows:
\: Source files
\Templates: The STARTROM.COM and NTDETECT.COM boot files used to initialize the OSCHOOSER boot loader are in this folder, as are any additional customized templates associated with the \\\\Setup\\Images\![]()
\ folder. Additional templates can be associated with a folder.
*.SIF: Image configuration files created during the RIS setup or by manual configuration, and are usually located in the i386\templates directory within the image. RINORPRT.SIF is a default install with no repartitioning; RISTNDRD.SIF is a default install with repartitioning.
In the MIT WIN domain, we changed the options to correspond to “Advanced”, “Default” and “Test” This change was implemented both in the \Setup and \OSChooser directory structures of the RIS server, and the content of the .osc files themselves.
Current Default Image .sif file, pro.sif:
[data]
floppyless = "1"
msdosinitiated = "1"
OriSrc = "\\%SERVERNAME%\RemInst\%INSTALLPATH%\%MACHINETYPE%"
OriTyp = "4"
LocalSourceOnCD = 1
[SetupData]
OsLoadOptions = "/noguiboot /fastdetect"
SetupSourceDevice = "\Device\LanmanRedirector\%SERVERNAME%\RemInst\%INSTALLPATH%"
[Unattended]
OemPreinstall = yes
DriverSigningPolicy = Ignore
OemPnpDriversPath = \Drivers\Nic;\Drivers\Video;\Drivers\Audio;\Drivers\other;\Drivers\SCSI
NoWaitAfterTextMode = 0
FileSystem = LeaveAlone
ExtendOEMPartition = 0
ConfirmHardware = no
NtUpgrade = no
Win31Upgrade = no
TargetPath = \WINNT
OverwriteOemFilesOnUpgrade = no
OemSkipEula = yes
InstallFilesPath = "\\%SERVERNAME%\RemInst\%INSTALLPATH%\%MACHINETYPE%"
[UserData]
FullName = "Pismere User"
OrgName = "Massachusetts Institute of Technology"
ComputerName = %MACHINENAME%
ProductID = "[CD-KEY]"
[GuiUnattended]
OemSkipWelcome = 1
OemSkipRegional = 1
TimeZone = %TIMEZONE%
AdminPassword = "*"
[Branding]
BrandIEUsingUnattended=Yes
[URL]
Home_Page=http://mit.edu/
[Proxy]
Proxy_Enable=0
Use_Same_Proxy=1
[LicenseFilePrintData]
AutoMode = PerSeat
[Display]
ConfigureAtLogon = 0
BitsPerPel = 16
XResolution = 1024
YResolution = 768
VRefresh = 75
AutoConfirm = 1
[Networking]
ProcessPageSections=Yes
[Identification]
JoinDomain = %MACHINEDOMAIN%
CreateComputerAccountInDomain = No
DoOldStyleDomainJoin = Yes
[NetAdapters]
Adapter1=params.Adapter1
[params.Adapter1]
InfID=*
[NetProtocols]
MS_TCPIP=params.MS_TCPIP
[params.MS_TCPIP.Adapter1]
SpecificTo=Adapter1
DHCP = No
IPAddress = %IP_ADDRESS%
SubnetMask = %IP_MASK%
DefaultGateway = %IP_GATEWAY%
DNSServerSearchOrder = 18.72.0.3,18.70.0.160,18.71.0.151
NetBiosOption = 1
DNSDomain = mit.edu
[params.MS_TCPIP]
InfID=MS_TCPIP
AdapterSections=params.MS_TCPIP.Adapter1
; UseDomainNameDevolution = No
; DNSDomain = mit.edu
[NetClients]
MS_MSClient=params.MS_MSClient
[params.MS_MSClient]
InfID=MS_MSClient
[NetServices]
MS_Server=params.MS_Server
[params.MS_Server]
; service: SRV (Server)
InfID=MS_Server
BroadcastsToLanman2Clients = No
[Components]
iisdbg = On
[ServicesSection]
[RemoteInstall]
Repartition = Yes
UseWholeDisk = Yes
[OSChooser]
Description ="Athena Workstation Default Image (SP3 Plus Intel update Pro 100/1000)"
Help ="Automatically installs a WinAthena Workstation without prompting the user for input. This consists of Microsoft Windows 2000 Professional with Service Pack 3."
LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com"
ImageType =Flat
Version="5.0"
Multiple sif files for one image:
You can use the same image for multiple sif files if they can share the same source files but require different configurations. Although the SIS groveller will save disk space on multiple images with the same files, this method saves even more space and may be more simple to manage.
To create a customized sif file for use with the same RIS image, use the following steps. Open the Active Directory Users and Computers management console. Find the computer account associated with the RIS server. Right-click the computer account and select Properties from the pop-up menu. Select the Remote Install tab. Click the Advanced Settings button and select the Images tab. Click the Add button. In the resulting Add wizard, select the first option, Associate a New Answer File to an Existing Image, and click Next. In the Unattended Setup Answer File Source window, select an alternate location and click Next. On the Location of Answer File screen, enter the full path to the new sif file in the Path text box and click Next. Select the image from the list. Click Next. The Friendly Description and Help Text page lets you change description and help text associated with the image you're creating. The description is presented to the user during the Client Installation Wizard in the list of images that can be installed, click Next. The Review Settings box displays summary information before creating the answer file, click Finish. The configured image should now show up under the Images tab in Active Directory Users and Computers (see below in the Notes section under, “Creation of images via GUI vs. manually”).
Another way to setup an additional sif file is to simply edit a copy of the file manually with a new Friendly Description and other options you want and save the file under a new name with the .sif extension in the \i386\templates directory of the image.
Installing a Workstation:
RIS Is a Clean Install, Not an Upgrade! FDISK and format are an automatic, integrated component with a RIS install. RIS will install to the first physical hard disk. If you want to have a specific partition size, you can pre-partition the drives before running a RIS install. Otherwise, to extend a RIS-based install over the entire first physical disk, add the Repartition="Yes" key and value to the [Unattended] section of your remote install *.SIF file. In addition, create a [RemoteInstall] section, with the Repartition="Yes" key and value. This will delete all partitions on the first drive, and create one partition formatted as NTFS. Currently, RIS can support multiple partitions, but this has not been implemented in the MIT WIN domain’s RIS server images.
Now, set the target client workstation BIOS to boot from the network card—from the floppy drive if you're using the remote boot floppy—and reboot the PC. During the initial boot sequence, you'll be prompted to press F12 to boot from the network. At this point, the network boot process will automatically contact a DHCP server, assign DNS and IP address information, query the DNS for an Active Directory controller, query for the location of a RIS server, and tftp the Client Installation Wizard from the RIS server.
MIT’s PXE install has a default image you can use simply by pressing enter at the first screen. To get the advanced image selections, press F1 instead. Then enter the login credentials for the WIN domain required by RIS, press enter on setup machine, and select advanced. The list of available images will then be displayed. Use the down arrow key to select the desired image and pres enter. The next screen will require machine name, IP and subnet mask. You do not need to enter the name of an OU, this should have been prestaged in moira. When complete press enter, then enter again after the warning screen.
RIPREP:
RIS includes a mechanism by which to image a machine—including all application installations, OS configuration settings, and application preferences—up to a RIS server. That image can then be applied to additional machines with similar hardware. This process is called Remote Installation Preparation or RIPREP. RIPREP images are similar to SYSPREP images. RIPREP images have the same hardware difference limitations as SYSPREP images. Target machines must use the same HAL, the same hard disk controller, the same number of processors, and the same power management technology (ACPI or non-ACPI) as the system used to create the master image. RIPREP only works on single-drive, single-partition systems. The target drive must be the same size as or larger than the source drive. RIPREP won't pick up or apply changes outside the system partition.
Without defining the Repartition keys in a RIPREP image answer file, RIPREP-based image target machines will have system partitions of exactly the same size as the master image. So if you take a RIPREP image of a 2GB system and apply it to a 6GB hard drive, you end up with a 2GB system partition, and 4GB of unpartitioned space. Including the Repartition keys ensures that the system drive will format and utilize the additional space.
An even bigger drive-related limitation occurs when applying an image to a smaller hard drive. If you make a RIPREP image of a 3GB drive and try to apply it to a 2GB drive, the install will fail, even if the data doesn't require all the space available on the drive. When the RIS client image is selected under the Client Installation Wizard, Setup checks the partition size of the target drive against the partition size from the master system. If the target partition is smaller, the Client Installation Wizard displays an error message, and the RIS image isn't installed. The target drive must be greater than or equal to the size of the source drive. This problem can occur with even a single megabyte of difference in the partitions.
To create an RIPREP image, run the RIPREP wizard on the client machine you want to image from the Admin folder of the RIS server (\\\\Admin). Follow the steps of the RIPREP wizard. The wizard is very similar to the initial RISETUP wizard used to create the initial image. After the introductory screen, you'll be prompted for the server name. By default, the text box will contain the name of the RIS server from which you're running RIPREP. Enter the name of the subfolder where you want to create the RIPREP files. This folder will be located at the same level as the base image folder. Enter a friendly description and help text. If any services or programs are running, Windows 2000 displays a window with the program, service, or process names. Close any listed programs, stop any listed services, and kill any listed processes before continuing. You'll get an opportunity to review your answers, if everything is correct, click Next to initiate the RIPREP image upload. RIPREP creates the new image option on the RIS server. After it completes, you need to reboot the source workstation and let mini-setup run. You can customize existing CD-based installs simply by modifying the associated answer file (*.SIF).
When a machine is installed with this image, the disk is partitioned and formatted, installation files are copied to the local machine, including all additional non-OS files from the master image. The base RIS install is applied. Configuration changes, new files, registry entries, third-party applications, and application settings are all added to the install. Mini-setup runs, which is similar to the SYSPREP mini-setup wizard, then the system reboots and is ready for use.
Notes
Adding support for the IntelliStation to a new RIS IMAGE
Much of this procedure is covered in Microsoft article Q254078 with some very important additions.
1). First, following Microsoft’s instructions, following directory tree must be created at the same level as he i386 directory (i.e. not in the i386 directory):
\$OEM$\$1\Drivers
Then create subdirectories for the categories of oem drives you wish to add, in the case of the IntelliStation add the following directories and place the Windows 2000 drivers and .inf files directly in them, not in a nested subdirectory:
Audio [SoundMAX integrated Digital Audio drivers]
Nic [Intel Pro 100 VE drivers]
Other [Intel oem chipset drivers]
Video [Matrox driver]
These drivers are all currently stored on RIN D:\IntelliStationOEMDrivers in the $OEM$ directory tree. You can actually just copy this $OEM$ directory into your image at the same level as the i386 directory.
****Make sure that ICH2AUD.INF in the “other” directory of your OEM tree has its extension renamed or the file is deleted, otherwise the wrong sound card will be detected.
2). Next edit the pro.sif file in the \i386\templates directory of your image, add the following entries:
Under the [Unattended] section add:
DriverSigningPolicy = Ignore [this is actually not needed for the IntelliStation but included in Q254078]
OemPreinstall = yes
OemPnpDriversPath = \Drivers\Nic;\Drivers\Video;\Drivers\Audio;\Drivers\other
Under [OSChooser]
Name your image to be displayed in the advanced menu under “Description”
3). SP2 only (new drivers support SP3)
Copy the .inf files from RIN D:\IntelliStationOEMDrivers\100pbeta to the i386 directory of your image, but not to the $OEM$ path for your Nic drivers. These files are for RIS only.
Copy e100bnt5.sys from RIN D:\IntelliStationOEMDrivers\100pdisk to the i386 directory of your image; overwrite the existing version of the file.
Delete e100bnt5.sy_ from the i386 directory of your image:
------
4). Restart the “Boot Information Negotiation Layer” service on RIN
Adding support for the Intel 1000 Pro NIC to a new RIS IMAGE (SP2)
This is in addition to the procedure of adding support for OEM drivers to a RIS image. Post SP2 hotfix Q315074 was added to the RIS server RIN, the file setupldr.exe from this hotfix was copied from RIN D:\ IntelliStationOEMDrivers\Q315074\2k to the \i386\templates directory of the image and renamed as ntldr. Add intelnic.dll to the i386 directory. Next, edit the pro.sif file in the \i386\templates directory of your image, add the following entry:
Under the [Unattended] section add:
DriverSigningPolicy = Ignore
Linkd:
This is a command run locally on the RIS server, it makes a hard link between the directories we actually keep the images in and the directory we link it to in the Reminst share. The reason for doing this is that it gives us the ability to link one image to multiple interfaces without having to maintain multiple copies of the image on disk. For example, the default RIS image is linked both to the Default and Advanced interfaces. Also, we can delete the link to take it offline from users without moving or deleting the data. On RIN, the RIS server, the data is stored in a directory in D:\RemoteInstall.x\images\current, the default image resides in the “current” directory is linked to a directory name within the path D:\RemoteInstall\Setup\Default\Images. An example for linking the current default image would be the following:
Linkd D:\RemoteInstall\Setup\Default\Images\win2000.pro.sp2.intel D:\RemoteInstall.x\images\current\ win2000.pro.sp2.intel
To delete the link use the following:
Linkd D:\RemoteInstall\Setup\Default\Images\win2000.pro.sp2.intel /d
Support for Server images and XP:
Microsoft has support for creating Windows 2000 Server and XP images for both RIS and Riprep. The staging RIS server RIN2 has been updated with the Q308508 and Q313069 hotfixes required to support this. This support is also included in SP3.
Riprep issues:
Domain Join: Q245263: Riprep.exe Images with DEC 500AA or 500BA or 3C920 do not Join Domain. The Dell Precision’s used in Building 37 have the 3C920 integrated into the motherboard, and we have had this problem when mini-setup runs to join a client machine created with an RIPrep RIS image to the domain. The NIC does not get initialized until after the install is complete and the machine is rebooted. This issue was escalated to PSS. Also, this may be related somewhat to the instloop problem we are having with some of our Pismere installs. The current workaround is to join the domain and reinstall the Pismere msi manually after the install. In the end, PSS said RIPrep does not support static IP’s. The solution for us would be to register the MAC addresses of the clients for DHCP, and make sure the source machine uses DHCP.
ACL’s to run Riprep. Local admin on the source machine and on the RIS server the image is being created on. The Reminst share on the RIS server and NTFS rights on the files must allow the account creating the image to create the new directory within the share and write the data.
CD-Based Image: The RIS server that the Riprep image is being created on must already contain an image the same version of NTOSKRNL.EXE as the source machine. This means it must be slipstreamed with the same service pack and hotfixes as the source machine.
One drive only supported: Riprep only supports creating an image from one system drive, other partitions will be ignored. We found that the Perl msi looked for the drive with the most free space and installed the binaries there. The msi was modified to install on the system drive to avoid this problem.
Riprep prompts you to shutdown “unkown” services. In case it could not copy open files. With testing RIPREP and creating the Building 37 images, we did not find this to be necessary. The only thing we found was that it did not copy some eventsyslogger logs.
While installing a machine with the Building 37 image, setup was asking for vgafix.fon, even though it was in the fonts directory. I added the file to the WINNT directory in the image and it stopped prompting for it.
MMC interface and DNS:
To see images in the AD interface in the MMC on the RIS server [machinename].win.mit.edu must be added to the hosts file. This was discovered because the interface showed that there were no installed images when in actuality there were. When running Netmon, it showed that the client was doing a lookup for RISserver.domainname. When the entry was added to the hosts file, the images were displayed in the interface.
Creation of images via GUI vs manually:
There was a procedure Danilo made to create a RIS image via a Perl script that runs against another file that contains a file list to copy. This list appears to have been generated from a directory listing of a RIS image created by the Microsoft GUI interface. Now that we are moving from SP2 to SP3 and adding Server and XP images, this procedure is no longer relevant and the GUI interface should be used when creating RIS images from scratch.
The GUI interface can be launched by either of two ways. First by the MMC by opening Active Directory Users and Computers, getting the properties of the RIS server, selecting the Remote Install tab, hitting the Advanced Settings button, selecting the Images tab, hitting the add button, and selecting the “Add a new installation image” option. Second, by simply running rissetup.exe and selecting the “Add a new OS image to this remote installation server” option.
Only the MMC method will bring you to the “Associate a new answer file to an existing image” option. Using this option will merely create a new .sif file for you which you can also do manually with any text editor. This will allow the same image to be used for more than one configuration, which can conserve on the amount of physical disk space required to maintain all of the RIS functionality you may want to provide. Although the SIS Groveler is running which will reduce the amount of redundant files that must reside on the NTFS partition that holds the RIS images, using multiple .sif files will still greatly reduce disk usage where you need multiple configurations for something such as an RIPrep image.
Once an image is created, it can be manually copied and modified into a second custom image without running any special utilities since the RIS server merely looks for .sif files within it’s RemoteInstall directory and parses those files to determine where to find the image source files.
Another feature of the GUI interface is that it automatically restarted the BINL service for you. This must be done after making many changes to the data in a RIS servers RemoteInstall directory.
Our current process is to create the images on RIN2, which is a staging RIS server. If the service pack and hotfix level of the image will be the same as an existing image, then a copy of that image can be used as the source, otherwise a new CD image would be slipstreamed and created with the GUI interface. This server is running RIS but the DHCP servers don’t point to it so clients are only directed to RIN. Images are created on RIN, including RIPrep images, they are modified if necessary and then manually moved over to the primary RIS server RIN and are in the D:\RemoteInstall.x\images\current directory. They are then linked to D:\RemoteInstall\Setup\Advanced\Images using linkd. If this were to be a default image, the process would be the same, except that it would be linked t the D:\RemoteInstall\Setup\Default\Images directory.
Configuration of Server RIS images:
Currently, the server RIS images used by ops have two configuration requirements. The first is not to install IIS, which is contrary to Microsoft’s default to install it. Second is to enable and start Terminal Server Services. The latter also requires a manual configuration afterward to allow 128-bit sessions only, this will be automated in the future. Also, the default Athena root password is not used in this image and the .sif file has ACL’s only allowing Domain Admin’s to read it.
Changes to the sif file for this image are the following:
[Components]
iis_common = off
iis_doc = off
iis_ftp = off
iis_htmla = off
iis_inetmgr = off
iis_nntp = off
iis_nntp_docs = off
iis_smtp = off
iis_smtp_docs = off
iis_www = off
iisdbg = On
TSEnable = on
[TerminalServices]
ApplicationServer = 0
[GuiUnattended]
AdminPassword = [This is different from the default]
[UserData]
ProductID = "[server CD key]”
Slipstream:
Slipstreaming is adding a service pack or hotfix image to a CD image. This image can then be used a source for a new RIS image with the updates built in. I noticed that the RIS images we had for service pack 2 did not appear to have all of the files added to the image. This was discovered while trying to run RIPrep on a workstation that was running SP2. When running RIPrep, the workstation must have a CD based image on the RIS server at the same service pack and hotfix level for any updates that modify NTOSKRNL.EXE in the event that it must copy additional files from the image in case they will be needed to install on a client machine with slightly different hardware. When RIPrep was run, we got an error saying that there was no server-based image. The RIS image turned out to have the original version of NTOSKRNL.EXE and not the SP2 one. Also, following the current Microsoft documentation for slipstreaming SP2 gave us an error saying not all the files needed were found in our image. This did not happen for SP3 and above, so we used a pre-prepared SP2 integrated CD from Dell to create our SP2 level images.
Microsoft states in Q256868, that Slipstream Switch for Windows 2000 Service Pack Update.exe Does Not Work with RIS Images. Therefore, service packs and hotfixes must be slipstreamed against CD images instead. Then these can be used as the source for RIS images created with the GUI interface.
There are issues slipstreaming XP Pro media for volume licenses with SP1. Pushing SP1 out via group policy is the current workaround.
Restarting the BINL Service:
The BINL Service is a service that runs on Windows 2000 Server that acts on client boot requests. For example, by using RIS the BINL service listens for and answers DHCP (PXE) requests. It also services Client Installation Wizard requests. BINL directs the client to the files needed to start the installation process. This service also checks Active Directory to verify credentials, determine whether a client needs service, and whether to create a new or reset an existing computer account on behalf of the client
Microsoft claims that after making changes to your RIS images and configurations you should restart the BINL [Boot Information Negotiation Layer] Service. This is because BINL needs to read all the new network interface card-related .inf files and create .pnf files in the image. Because this is a time consuming task, it is only done once, which is when the BINL service starts. See Q279112 for more information on how Plug and Play detection works.
Spanning Tree latency Issues:
We found that the switches the servers are on are slow to have the port rejoin spanning tree after the machine reboots, since for a period of time the port shows down and then must rejoin the group. Ports are taking about 10 seconds to rejoin and the PXE timeout is about 20 seconds, which is apparently not enough time with the bootup sequence to process the requests. DHCP's timeout is around 30 seconds, which is why we don't see this problem there. The 10-second spanning tree time was unusually long and it should have been more like 3 seconds.
By putting a small mini hub between the machine we were testing and the switch so the port would not look down while the machine was rebooting and PXE is one immediate workaround that can be done, but a more permanent solution is to have network operations use the fastport setting for these ports. This has worked for W92 machine room ports that were having his problem.
Restore of RIS images from backup:
When restoring RIS images that have been deleted from a RIS server, the SIS Groveler directory must also be restored or the image may be missing many files after the restore is completed. The SIS Groveler directory always resides on the same partition that the RIS Remote Install source share resides on.
SIF file Help Text:
The Help Text field in the sif files should never have a line feed, or you will get an error trying to parse the file during a RIS installation.
Configuring a RIS image to load a SCSI Mass Storage Device driver in textmode
In some instances systems require an OEM SCSI Mass Storage Device driver to begin the installation. The reason for this is if the controller of the boot drive is not supported by drivers included in the Windows 2000 CD, an OEM driver must be loaded before setup can access the disk. This is regardless of whether the controller has BIOS loaded or not. The user can either hit F6 and use drivers from an OEM floppy during the install, or we can configure the RIS image to load the driver.
Microsoft has documented a process for loading a Mass Storage Device driver in the textmode portion of setup for unattended installations. I did not see specific instructions for this pertaining to RIS, so I substituted the unattended.txt file for the .sif file in their documentation, and the installation was successful.
The second change made was to add the driver files to i386 in case RIS would only look there and not in the OEM path. Additional testing need to be done to see if this was necessary. It was done only as an insurance measure to get the Building 37 cluster image ready without too many iterations of testing.
What we found was that setup did not try to detect this device, it merely forced the driver to load regardless of the hardware of the system, so if another machine without this controller were to use this image, the result would be the infamous BSOD, with the message, "Inaccessible boot device". This means any time we need to have RIS load such a driver during textmode there must be a dedicated RIS image for that hardware, or at least that disk controller.
See the following URL for Microsoft's documentation [this particular doc was for XP, but the same applied to 2000. I used it because it was much more brief and to the point of what I needed than the 2000 doc]:
http://search.microsoft.com/gomsuri.asp?n=9&c=rp_Results&siteid=us/itresources&target=http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/prbc_cai_qcxl.asp
Here is the procedure as it applied to RIS after you create a new image for this hardware:
1). In the distribution folder, create the Textmode folder in the \$OEM$ folder.
2). Copy the driver files into the Textmode folder.
3). Copy the driver files to \$OEM$\1\Drivers\SCSI
4). In the beginning of the .sif file, add an [OEMBootFiles] section and then the following entries:
oemsetup.inf
driver.sys [substitute the name of the driver]
txtsetup.oem
5). Add a [MassStorageDrivers] section to the .sif file and determine the device name From the txtsetup.oem. For example for the LSI Logic Ultra 320 you will find the this line:
SYMMPI = "LSI Logic PCI SCSI/FC MPI Miniport Driver",symmpi
The name you would use here will be "LSI Logic PCI SCSI/FC MPI Miniport Driver"
So the syntax you will use in the sif file under [MassStorageDrivers] will be look like:
"LSI Logic PCI SCSI/FC MPI Miniport Driver" = "OEM"
6). In the [Unattended] section of the .sif file, make sure the DriverSigningPolicy = Ignore entry exists. Also verify that the OemPnpDriversPath includes \Drivers\SCSI.
7). Stop and restart the Boot Information Negotiation Layer (BINL) service on the RIS server.
This step is required for these changes to take effect.
XP RIS installations do not support the old RIS boot floppy
The following stop message comes up while attempting net boot to text mode setup:
NETWORK_BOOT_INITIALIZATION_FAILED (0xBB).
We do not support the RIS boot floppy for XP network installs.
XP Customizations
[Components]
Msnexplr = Off Don’t install MSN Explorer
WMAccess = Off Don’t install Windows Messenger
OEAccess = Off Disable access to Outlook Express
Zonegames = Off Don’t install Zonegames
XP Media
Retail and volume license keys each need their own type of media, one kind of media cannot be used for both. Two types of images will be maintained, one for each media type. Also, the volume license media does not work when slipstreamed, so the service pack will be pushed out via group policy.
No comments:
Post a Comment