RIS Documentation
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 \\<RIS Server>\<RIS Share> UNC, the
share created during the initial setup of RIS. In the paths,
<architecture> refers to the processor architecture (for example, i386),
and <language> refers to the default language of the source install (for
example, English):
\Admin\<architecture>: 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
<language> subfolders, and platform-specific boot files used to run the
OSCHOOSER boot loader are under <architecture> subfolders.
\Setup\<language>\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 \\<RIS
Server>\<RIS
Share>\Setup\<language>\Images\<image>\<architecture>
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 \\<RIS
Server>\<RIS
Share>\Setup\<language>\Images\<image>\<architecture>
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
<language> 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
(\\<RIS Server>\<RIS Share>\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 t