Chapter 15 - Remoteboot

Chapter 15 - Remoteboot

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The Remoteboot service is a Windows NT Server feature that starts MS-DOS, Microsoft Windows 3.1, and Microsoft Windows 95 clients over the network. You install and configure the Remoteboot service on the server and then customize it to be more effective for your particular network and for your users' needs.

For updated information about the Remoteboot service, see the <systemroot>\Rpl\Readme.txt file. The default location of the remoteboot directory is \systemroot<systemroot>\Rpl. If you choose a different location to install the remoteboot directory, substitute that location for <systemroot>\Rpl throughout this chapter.

Understanding the Remoteboot Service
Setting Up and Starting the Remoteboot Service
Managing Remoteboot Clients
Optimizing the Remoteboot Service
Directory, File Index, and Configuration File Details
Supporting Multiple Network Adapters and Protocols
Backing Up the Remoteboot Database
Troubleshooting Remoteboot

Understanding the Remoteboot Service

This section describes the architecture and operation of the Windows NT Server Remoteboot service.

For complete information about Windows NT file systems, security, and network planning issues, see Windows NT Server Concepts and Planning. This information will help you take best advantage of Windows NT Server at your site.

The Remoteboot Process

When you start, or boot, a computer, the operating system is loaded into its memory. The Windows NT Remoteboot service supports personal computers running MS-DOS, Windows 3.1, and Windows 95 (also called clients or workstations) that boot using software on the server's hard disk instead of the client's hard disk. Each of these clients has a network adapter, with a Remote Initial Program Load (RPL) ROM chip, that retrieves startup and configuration software from the server when the client starts. The client does not need a hard disk. This process is known as booting remotely or the remoteboot process.

Figure 15.1 shows a possible configuration of remoteboot clients and servers.

Figure 15.1: The remoteboot process

How Does Remoteboot Work?

The Remoteboot service works by providing two kinds of resources at the server:

A boot block, which contains all the information needed to start the client when it boots
The remoteboot profile, which defines the operating system environment of the client after it boots

The boot block and remoteboot profile are sent across the network in frames. A frame is a chunk of data, with some extra information. Sending a frame can be thought of as mailing a package of data, with the address and instructions for its use written on it.

When a remoteboot client is powered up, the network adapter is initialized and broadcasts a FIND frame (a boot request), as shown in Figure 15.2. The Remoteboot service receives the FIND frame, which contains the client's adapter ID.

Figure 15.2: The remoteboot process: boot request

The Remoteboot service checks the remoteboot database on the server to see if a workstation record (a remoteboot database entry) already exists with this adapter ID. If it doesn't, the Remoteboot service records this adapter ID but does not boot the client. To boot the client, the administrator must convert this adapter ID record to a workstation record using Remoteboot Manager.

If a workstation record does exist with this adapter ID, the Remoteboot service sends a FOUND frame, containing the server's adapter ID, to the RPL ROM on the client. This is called a boot acknowledgment and is illustrated in Figure 15.3.

Figure 15.3: The remoteboot process: boot acknowledgment

The RPL ROM accepts the first FOUND frame it receives (it may receive more than one if several servers are running the Remoteboot service), and returns the SEND.FILE.REQUEST frame to the adapter ID of the server that sent the first FOUND frame. The following Figure shows the remoteboot client sending a boot block request.

Figure 15.4: The remoteboot process: boot block request

When the Remoteboot service receives the SEND.FILE.REQUEST frame, it uses FILE.DATA.RESPONSE frames to send a boot block to the RPL ROM (as shown in Figure 15.5). The workstation record in the remoteboot database specifies which boot block to send (either MS-DOS or Windows 3.1). When the RPL ROM receives the last FILE.DATA.RESPONSE frame, it transfers execution to the entry point of the boot block.

Figure 15.5: The remoteboot process: boot block transfer

The RPL ROM boots the operating system specified by the boot block as appropriate for the client. For a client running MS-DOS or Windows 3.1, this completes the basic boot process.

For a client intended to run Windows 95, the boot process continues. The client is now running Windows 95 real-mode (also identified as MS-DOS 7.0), using files on the remoteboot server. To complete the boot to Windows 95, the client does the following:

Creates a RAM disk. A RAM disk is an area of the computer's RAM memory set aside to operate as if it were a disk drive.
Copies Windows 95 real-mode files from the remoteboot server to the RAM disk.
Loads the Windows 95 real-mode network drivers and establishes a connection to a Server-Based Setup (SBS) server. The SBS server can be the same computer as the remoteboot server. An SBS server, described in the Microsoft Windows 95 Resource Kit, supports over-the-network installation of Windows 95 as well as shared installations (where some or all Windows 95 files reside on the server). For Windows NT remoteboot, the SBS server provides the Windows 95 files which the client uses to complete the Windows 95 boot process.
Connects to a server that has a machine directory with files specific to this client.

Why Use Remoteboot?

The Remoteboot service promotes the use of diskless clients by eliminating the need for a hard disk on each client. This has several advantages:

Increased network security by using clients that do not have disk drives that can be used to illegally copy data and to introduce viruses
Greater control over the distribution of information and software resources
Ease of updating software centrally
Reduced cost in buying and maintaining client computers

Using the Remoteboot service has advantages for clients with hard disks as well:

Easy upgrading of software and operating systems on many clients
Greater flexibility in standardizing clients while allowing custom configurations

In general, the Remoteboot service offers greater control to the network administrator.

Top Of Page

Setting Up and Starting the Remoteboot Service

Before you can use the Remoteboot service, you must install a network adapter containing an RPL ROM chip on each client computer you plan to boot remotely. These adapters are available directly from network adapter manufacturers or from independent vendors. For more information about network adapters and RPL ROMs, contact your solution provider. A list of supported network adapters is provided in the next section of this chapter.

To set up the Remoteboot service (summary)

Install Windows NT Server on a computer that will be the remoteboot server.

There are three special considerations for the Remoteboot service:
- The server's computer name must not have spaces in it.
- It is strongly recommended that you install remoteboot files on a disk partition formatted with NT File System (NTFS) so that permissions are correctly set. Users will be able to read and write their own files in the remoteboot directory but not write to shared files or system configuration files. Also, the File Allocation Table (FAT) file system does not support more than approximately 100 remoteboot clients.
- Install the Data Link Control (DLC) and NetBIOS Extended User Interface (NetBEUI) protocols and ensure that clients can communicate with the server using these protocols (arrange proper routing, bridging, etc.).
Install the Remoteboot service on the remoteboot server.

Or, convert an existing Microsoft LAN Manager for OS/2 remoteboot installation to run on Windows NT Server, and then install the Remoteboot service.

Note: Windows NT Server does not support remote booting of OS/2 clients, Windows for Workgroups clients, Windows NT Workstation clients, or Windows NT Server clients.
Install MS-DOS and/or Windows 3.1 operating system files on the remoteboot server.

If you are converting from LAN Manager remoteboot, this may not be necessary.
If you will have Windows 95 remoteboot clients, install Windows 95 real-mode (also identified as MS-DOS 7.0) files on the remoteboot server.
Start the Remoteboot service.
Check the installation for errors, including checking the Event Viewer log.
Create profiles (these define the working environment shared by one or more clients).
If you will have Windows 95 remoteboot clients, install a Server-Based Setup (SBS) server.

This can be the same computer as the remoteboot server or it can be a separate server on the network. The SBS server must run the NetBEUI protocol.
If you will have Windows 95 remoteboot clients, create a location for machine directories.

This can be on the same computer as the remoteboot server or SBS server, or it can be on a separate server on the network. The server containing machine directories must run the NetBEUI protocol.

This section provides step-by-step instructions for these actions. For instructions on managing remoteboot clients, see "Managing Remoteboot Clients" later in this chapter.

Disk Space Requirements

The first step in preparing to use the Remoteboot service is to ensure that the server has enough disk space for the files needed by the remote clients. Use the values in the following table as a guideline.
Table 15.1 Disk Space Requirements

Component	Disk space required
Microsoft Network Client version 2.2 for MS-DOS (LAN Manager version 2.2)— required for all client configurations	5.1 MB
MS-DOS 3.30	0.7 MB
MS-DOS 4.01	1.5 MB
MS-DOS 5.00	2.8 MB
MS-DOS 6.x	5.9 MB
Windows 3.1	12.4 MB
Windows 95	2.0 MB

Use this table to calculate the amount of disk space you need on the remoteboot server. For example, to install the Remoteboot service for a configuration of clients running MS-DOS 6.22, some with Windows 3.1, you need 23.4 MB of disk space, broken down as follows:

5.1 MB for the Network Client 2.2 for MS-DOS files
5.9 MB for the MS-DOS 6.22 files
12.4 MB for the Windows 3.1 files

In addition, you need room for personal copies of remoteboot profiles (if needed) and for directories for each client, where people store their own data. The amount of space to allot per client is up to you. You can also define a separate server (or servers) to contain machine directories for Windows 95 clients, to distribute the load of storing client-specific data. Each Windows 95 client needs its own machine directory with a minimum of 8 MB of disk space; more if users install additional software.

Windows 95 remoteboot clients require 8 MB of RAM and must be 386-based or higher. The server you use as a Server-Based Setup server requires 90 MB of disk space to store Windows 95 files.

Supported Network Adapters

These specific network adapters are supported by the Remoteboot service for Windows 95, Windows 3.1, and MS-DOS on the client (for the latest list see <systemroot>\Rpl\Readme.txt):

Note: Only the ISA versions of these network adapter cards are supported for Windows 95 remoteboot clients. Note especially that the Remoteboot service does not support PCI, Token-Ring, or PNP adapters for Windows 95 remoteboot clients:

3Com EtherLink II

3Com EtherLink III

AMD Series 2100 Ethernet

Intel EtherExpress 16

Intel EtherExpress PRO

Novell NE2000

Western Digital/SMC EtherCard Plus (8000 series) (see Readme.txt for information about using the 8000 series with Windows 95)

The following network adapters are supported by the Remoteboot service for Windows 3.1 and MS-DOS on the client (for the latest list see <systemroot>\Rpl\Readme.txt):

3Com EtherLink

3Com EtherLink Plus

3Com EtherLink /MC

3Com EtherLink II

3Com EtherLink III

3Com TokenLink

3Com TokenLink III

3Com 3Station

AMD Series 2100 Ethernet

HP Ethertwist

IBM Token Ring

IBM Ethernet

Intel EtherExpress 16

Intel EtherExpress PRO

Madge Token-Ring

Nokia/ICL Ethernet IIe

Novell NE1000

Novell NE2000

Racal Interlan NI 5210

Racal Interlan NI 6510

Western Digital/SMC Ethernet

Western Digital/SMC EtherCard Plus (8000 series)

Most network adapters work best with the Remoteboot service when using their default settings. However, if you need to modify these default settings in the Protocol.ini files, these files are located in <systemroot>\Rpl\Bblock\Netbeui\adapter\Protocol.ini, where adapter is the name of the particular network adapter. For example, a Windows 95 client can have conflicts with interrupt 3 (IRQ3) for the network adapter.

Installing the Remoteboot Service on the Remoteboot Server

Have on hand the Windows NT Server compact disc. You will also need original product disks for any operating system that you want the remoteboot clients to run, such as MS-DOS or Windows 95 disks.

The installation procedure differs depending on whether you are installing a new remoteboot directory or converting an existing LAN Manager for OS/2 remoteboot directory. Use one of the two following procedures.

To install the Remoteboot service (with a new remoteboot directory)

If they are not already installed, install the DLC and NetBEUI protocols on the server. The Remoteboot service requires DLC and NetBEUI.
Click Start, point to Settings, and click Control Panel.
Double-click Network.
In the Network Settings dialog box, click Add Software.
In the Add Network Software dialog box, select the Remoteboot Service.
In the Remoteboot Setup dialog box, type the full path and directory name where you want to install the remoteboot directory.

The default value is <systemroot>\Rpl. This is the directory shown in descriptions and examples.
Click OK.
Complete the dialog boxes that appear.

For help with any dialog box, press F1.

See the post-installation information after the next procedure.

To install the Remoteboot service (converting a LAN Manager for OS/2 remoteboot directory)

Use the Windows NT Server Upgrade for LAN Manager tools to convert the LAN Manager server's user accounts and file permissions. Then the remoteboot conversion can properly assign permissions and user account properties.
On the Windows NT Server computer, delete the RPLUSER global group (it is created by the Upgrade for LAN Manager tools). The Fix Security command of Remoteboot Manager will create an RPLUSER local group.

Note that users who administer the Windows NT Remoteboot service must be members of the Administrators local group. The Upgrade for LAN Manager tools convert the LAN Manager RPLADMIN group to a Windows NT RPLADMIN global group, but it has no function under Windows NT.
Copy the entire remoteboot directory from the OS/2 server to the Windows NT Server computer.

For example, if the LAN Manager remoteboot directory is \\SERVER3\C$\LANMAN\RPL and the Windows NT remoteboot directory is C:\Winnt\Rpl, type the following command at the Windows NT Server computer:

xcopy /e \\server3\c$\lanman\rpl c:\winnt\rpl

Keep a copy of the Rpl directory for later reference. Be especially sure to keep backup copies of any .ini, .cnf, and .fit files that were modified from their default state.
If they are not already installed, install the DLC and NetBEUI protocols on the server.

The Remoteboot service requires DLC and NetBEUI.
In Control Panel, double-click Network.
In the Network Settings dialog box, click Add Software.
In the Add Network Software dialog box, click the Remoteboot Service.

In Remoteboot Setup, make the following choices:
- In the Remoteboot Directory box, type the full path and directory name of the remoteboot directory on the Windows NT Server (for example, C:\Winnt\Rpl).
- Select the Migrate Remoteboot Directory From LAN Manager 2.2 check box.
Click OK.
Complete the dialog boxes that appear.

For help with any dialog box, press F1.
Copy the new LAN Manager client software to locations in the Windows NT Server computer's Rpl directory, using the following commands:

xcopy /e d: \clients\rpl\bblock c:\ systemroot \rpl\bblock
xcopy /e d: \clients\rpl\fits c:\ systemroot \rpl\fits
xcopy /e d: \clients\rpl\rplfiles c:\ systemroot \rpl\rplfiles

where d: is the computer's compact disc drive.
Run the rplcnv conversion program after remoteboot installation.

The rplcnv program converts the RPL.MAP and RPLMGR.INI files used by the LAN Manager Remoteboot service into the System.mdb and Rplsvc.mdb files used by the Windows NT Remoteboot service database.

This is the syntax for rplcnv:

rplcnv [path]

where path specifies an absolute path to the directory containing the RPL.MAP and RPLMGR.INI files. If this parameter is omitted, it is assumed that the files are in the current directory or in <systemroot>\Rpl.
Compare the new .ini, .cnf, and .fit files in the remoteboot directory to the backup copies you made before conversion.

If you had modified the OS/2 versions of these files, you may want to transfer those modifications to the Windows NT versions. Do not simply copy the OS/2 versions over the Windows NT versions, because you might overwrite new data.

In Step 11 you installed new configurations. If you have profiles that you want to preserve from the LAN Manager installation, modify the profiles' Autoexec.bat and Config.sys files as follows:
- Autoexec.bat: @Rpllink is no longer needed; this file has been replaced with Rpllnk.sys, which is loaded from Config.sys.
- Config.sys: Add the following line as the first line in the file:
```
DEVICE=C:\BINR\RPLLNK.SYS
```

Whether you install a new Rpl directory or migrate from OS/2, the installation process creates the following major directories:

Rpl (at the location you specify during installation and with a different name if you want). This is the remoteboot directory.
Rpl\Bblock. This directory contains boot blocks for each client configuration.
Rpl\Fits. This directory contains file index table (FIT) files that translate references to a file on the client to a true path to the file on the server. For example, for a client using a profile shared with other clients, the FIT file would map C:\Config.sys to \\server\Rplfiles\Profiles\profile\Config.sys, where server is the server's name and profile is the profile for this client.
Rpl\Rplfiles. This directory contains files specific to each client as well as shared files such as profiles and operating system files. This directory is shared with the name Rplfiles.
Rpl\Rplfiles\Binfiles\Dosxxx. These directories contain shared MS-DOS system files.
Rpl\Rplfiles\Binfiles\Lanman.dos. This directory contains Microsoft Network Client version 2.2 for MS-DOS, the network software used by all remoteboot clients.
Rpl\Rplfiles\Binfiles\Win95. This directory contains shared Windows 95 real-mode (also identified as MS-DOS 7.0) system files.

The first time you run Remoteboot Manager and choose the Fix Security command, it creates the RPLUSER local group and assigns permissions as appropriate throughout the Rpl directory.

For a complete explanation of the remoteboot directory structure, see "Directory, File Index, and Configuration File Details" later in this chapter.

Installing MS-DOS Files on the Remoteboot Server

When a client starts and requests an MS-DOS remoteboot, the remoteboot server gives it a boot block, which will load some version of the MS-DOS operating system. The server can also provide Windows 3.1 for the client. You must copy MS-DOS and Windows 3.1 files to the server; they are not shipped with Windows NT Server.

Note: You must have a separate, valid, software license for each client computer, including remoteboot clients, that runs MS-DOS, Microsoft Windows 3.1, or Microsoft Windows 95.

In the following procedure you install MS-DOS files on the server. For information about how to install Windows 3.1 files, see "Installing Windows 3.1 for MS-DOS Clients" later in this chapter. For information about how to install Windows 95 files, see "Installing Windows 95 for Windows 95 Clients" later in this chapter. You cannot install Windows 3.1 or Windows 95 until you have at least one MS-DOS remoteboot client running.

To copy MS-DOS 6.2 x files to the server

Check that the <systemroot>\Rpl\Rplfiles directory is being shared on the remoteboot server. It should have the share name Rplfiles.
From an MS-DOS client (running a version of MS-DOS 6.2x that you want to support on the remoteboot server), connect to the remoteboot server's Rplfiles share by typing:

net use v: \\ server \rplfiles

where server is the name of the remoteboot server.
Copy all the MS-DOS files to the <systemroot>\Rpl\Rplfiles\Binfiles\Dosxxx directory, where xxx is the version number (for example, Dos622), by typing:

copy c:\dos\*.* v:\binfiles\dos622
attrib -s -h c:\io.sys
attrib -s -h c:\msdos.sys
copy c:\io.sys v:\binfiles\dos622
copy c:\msdos.sys v:\binfiles\dos622
attrib +s +h c:\io.sys
attrib +s +h c:\msdos.sys

As shown, you may need to remove the hidden file attribute in order to copy these files and then reset the attribute after copying. You can do this with the MS-DOS attrib command.

Note: Do not set the hidden or system file attributes on the new copies of the files in the <systemroot>\Rpl\Rplfiles\Binfiles\Dosxxx directory.

Copy files to an existing Dosxxx directory only; do not create a new directory. For example, any version of MS-DOS 6.2x must be copied to the existing Dos622 directory.
If you copied DOS files other than MS-DOS (such as PC-DOS), you must rename the following files. From the <systemroot>\Rpl\Rplfiles\Binfiles\Dosxxx directory on the remoteboot server, type:

rename ibmdos.com msdos.sys
rename ibmbio.com io.sys

Starting and Stopping the Remoteboot Service

The Remoteboot service is installed as a manual service, meaning that you must start it intentionally each time you want it to run. If you want it to start automatically each time the server starts, see the instructions in online Help for the Services icon in Control Panel.

To start or stop the Remoteboot service

Click Start, point to Settings, and then click Control Panel.
Double-click Services.
Click the Remoteboot service.

You may need to scroll down the list of services to reach it.
Click Start or Stop.

Pause and Continue have no effect on the Remoteboot service.
In the Services dialog box, click Close.

You can also use the net start remoteboot command to start the Remoteboot service and net stop remoteboot to stop it.

Starting Remoteboot Manager

Remoteboot Manager is an administrative tool for controlling the remoteboot process and managing remoteboot clients.

xng_s07

To start Remoteboot Manager

At the Windows NT Server computer, log on to a user account that belongs to the Administrators local group.
From the Network Administration program group, click the Remoteboot Manager icon.
If you want to administer a remoteboot server other than the local computer, click Set Focus on the Remoteboot menu.

Type the name of the remoteboot server, or choose the name from the Select Computer box.

Or, from the command line, type rplmgr (or rplmgr \\server, where server is the name of a Windows NT Server computer).

Checking the Remoteboot Installation

After you start the Remoteboot service for the first time, check the server's event log for entries related to the Remoteboot service. Use Event Viewer in the Administrative Tools group.

You should also use Remoteboot Manager's configuration and security checking features after installation and after you add or remove support for an operating system.

To check the remoteboot configuration

On the Configure menu, click Check Configurations.
Click Yes.

This checks which operating systems are available for remoteboot clients. Remoteboot Manager offers these as choices for profiles.

To check security settings in the remoteboot directory

On the Configure menu, click Fix Security.
Click Yes.

This overwrites permissions throughout the <systemroot>\Rpl directory, creates accounts for remoteboot clients and the RPLUSER local account (if they don't already exist), and updates the domain entry in Lanman.ini files for remoteboot clients to match the server's own domain/workgroup.

Managing Profiles

When you use Remoteboot Manager for the first time, you must decide which profiles you need. A profile is the working environment shared by one or more clients. It consists of the operating system, the client computer and architecture type, the network adapter type, and all the other information needed to boot a client.

Note: Remoteboot profiles are completely different from user profiles, which are used elsewhere in Windows NT Server.

To establish and name profiles, you choose from a list of configurations. A configuration is actually a template profile; a profile is created as a copy of one of the base configurations. Generally, you can find a configuration for any profile you want to create. Once the profiles are defined, it's easy to add clients.

Clients use profiles in either of two ways: sharing a profile or using a personal copy of a profile. The profile is the same in either case; the difference is in how the client uses it.

A profile can be shared by a group of similar client computers that use the same startup information. (All of the clients have the same Config.sys, Lanman.ini, and other configuration files, and those files are read-only.) For example, you may want to have a common profile that is shared by accounting, and another profile for sales and marketing. Or, you may want to create a profile shared by all Windows 3.1 users. Keep in mind, however, that the client computer architecture must be similar enough that the clients can share startup files. Clients that share profiles get their environment from a <systemroot>\Rpl\Rplfiles\Profiles\profile directory (where profile is the name of the profile).

Sharing profiles is not practical in all cases. For example, a client may need customized system configuration files (like Config.sys). In this case, the client should use a personal copy of a profile. Changes to the startup information affect only the single client. Clients that have a personal copy of a profile get their environment from a <systemroot>\Rpl\Rplfiles\Machines\cname\profile\Pro directory (where cname is the computer name and profile is the name of the profile). Users can edit any of the files in that directory, such as Config.sys.

When you upgrade operating systems and make software changes, you need to install them separately to each profile and copy of a profile.

To create a profile

On the Remoteboot Manager Remoteboot menu, click New Profile.
In Profile Name, type a name for this profile [no more than 16 characters, with no spaces or backslashes(\)].
In Configuration, enter a configuration.

If the configuration you want is not present, you must install the appropriate operating system (see "Installing MS-DOS Files on the Remoteboot Server" earlier in this chapter) and check the configuration (on the Configure menu, click Check Configurations).
In Description, type a comment for the profile.

The description should summarize the profile for easy recognition, such as MS-DOS 6.22 VGA & 3Com 503 EtherLink II adapter.
Click OK.

To change a profile

Select an existing profile in Remoteboot Manager.
On the Remoteboot menu, click Properties.
Change the description of the profile, and then click OK.

You can change only the description. To change any other settings, you must create a new profile.

To delete a profile

Select an existing profile in Remoteboot Manager.
On the Remoteboot menu, click Delete.

If a message appears telling you that clients (workstation records) are still assigned to this profile, you can delete or reassign all of the clients at one time:
- In the error message dialog box, click OK.
- Select the profile.
- On the View menu, click Workstations In Profile.
- Select all of the workstation records (press CTRL and click all of the workstation records).
- On the Remoteboot menu, click Delete.
  
  Or, on the Remoteboot menu, click Properties. Choose a new profile for all of the clients, and then click OK.
In the Confirmation dialog box, click OK.

Once you have profiles set up, most remoteboot administration consists of managing the individual clients.

Top Of Page

Managing Remoteboot Clients

When you have installed the Remoteboot service and the MS-DOS operating system files, and you have defined some profiles, you can use Remoteboot Manager to manage the remoteboot clients. You must boot at least one client on MS-DOS before you can install Windows 3.1 or Windows 95 remoteboot clients.

This section provides procedures for:

Enabling and disabling the hard disk on a client.
Adding a client to the Remoteboot service.
Removing a client from the Remoteboot service.
Installing Windows 95 for Windows 95 clients (includes setting up a Server-Based Setup server and, optionally, a server to hold machine directories).
Installing Windows 3.1 for MS-DOS clients.

When a user starts a remoteboot client, what appears as the client's C drive is actually mapped to various locations on servers, such as a personal directory on a separate server. For an MS-DOS or Windows 3.1 client, the remoteboot server maps directories and files from various locations to the virtual C drive using a File Index Table (FIT) file; for more information, see "File Index Tables" later in this chapter. If the remoteboot client has a hard disk, the hard disk appears as drive D. Floppy disk drives keep their original drive letters.

Before you can use the Remoteboot service, each remoteboot client must have a network adapter with an RPL ROM chip installed. For a list of supported network adapters, see "Setting Up and Starting the Remoteboot Service" earlier in this chapter.

Enabling Remoteboot on a Client's Hard Disk

Before a client with a hard disk can be booted remotely, its hard disk must be properly configured for the Remoteboot service. This does not prevent users from accessing the hard disk after the client is booted.

Use the Microsoft Network Client version 2.2 rplenabl utility to prepare the client to use the Remoteboot service. Later, if you want to boot the client using its hard disk, run the rpldsabl utility to disable the remoteboot configuration.

Note: Some RPL ROMs will take control of the client even though the hard drive is enabled, and so you may not need to run the rplenabl (or rpldsabl) utility on these clients. Try simply booting the computer, and then use rplenabl if needed.

To configure a client's hard disk for the Remoteboot service

Insert a formatted MS-DOS floppy disk in the remoteboot server's floppy disk drive.
Copy the Rplenabl.exe and Rpldsabl.exe programs to the floppy disk by typing:

copy c:\systemroot\rpl\rplfiles\binfiles\binr\rpl??abl.exe a:

where a: is the floppy disk drive.
Start the remoteboot client, booting MS-DOS from the local hard disk.
Put the disk with the Rplenabl.exe program in the client's floppy disk drive and type:

a: rplenabl

where a: is the client's floppy disk drive.
Remove the disk and press CTRL+ALT+DEL.

The Remote Program Load Module information is displayed as the RPL ROM chip initializes the network adapter.

For instructions on using the rpldsabl utility, see "Deleting a Client" later in this chapter.

Adding a New Client

As described earlier in "Setting Up and Starting the Remoteboot Service," you created profiles for clients. You can add a new remoteboot client in two ways:

Create a new remoteboot database record for the client and manually fill in the necessary data, including the client's network adapter ID number and the profile you want this client to use. This is only recommended when you know the network adapter ID number and you are copying an existing workstation record.

When you copy an existing workstation record, you also copy the personal configuration information. For example, if the original workstation record uses a personal copy of a profile and has a customized installation of Windows 3.1, the profile and the Windows installation will be copied for the new client.
Boot the client remotely with no special preparation on the server. This creates an adapter record on the server, which you can then convert to a workstation record by adding the client's name and profile. This is easier because you don't need to know the client's network adapter ID number.

To create a new workstation record manually

Start Remoteboot Manager.

Remember to log on to a user account that belongs to the Administrators local group.
On the Remoteboot menu, click New Workstation.

Or, select an existing workstation record. On the Remoteboot menu, click Copy.
In Adapter ID, type the client's network adapter ID number.

This is a unique number supplied by the network adapter firmware. The adapter ID is 12 hexadecimal digits; the first six digits identify the adapter type. If you don't know the adapter ID, stop this procedure and go to the next procedure.
In Wksta Name, type a name for the client.

The name can have no more than 15 characters [with no spaces or backslashes (\)]. The Remoteboot service will create a Windows NT user account with this name, not for the user but for the client computer itself.

If the server's Rpl directory is on a FAT file system, use standard MS-DOS 8.3 format (eight characters, with an optional period and three more characters).
In Description, type a comment that describes the client.
In Password, type a password for the client computer's account (not for the user using the client computer).

Choose a configuration type:
- Click Shared if this client can share its profile with other clients.
- Click Personal if this client must use a personal copy of a profile so that you can customize the environment for the client.
In Wksta In Profile, enter a profile for this client.

If none of the profiles are suitable, see "Setting Up and Starting the Remoteboot Service," earlier in this chapter, for instructions on creating profiles.

If you see a profile in the list that appears to be appropriate, but it is marked as incompatible (or you see an error message about it being incompatible), then you may need to create a new configuration for this adapter type. See "Creating Remoteboot Configurations for New Adapters" later in this chapter.
In TCP/IP Settings, enter appropriate addresses only if the client will use TCP/IP and will not use DHCP for automatic address handling.
Click Add.

To create a new workstation record automatically

Start Remoteboot Manager on the server.

Remember to log on to a user account that belongs to the Administrators local group.
Start the remoteboot client.

The client does not actually boot, but it does send a boot request to the server.
In Remoteboot Manager on the server, click Refresh on the View menu.
In Remoteboot Manager, select the adapter record that has appeared with the network adapter ID number in place of the client name.
On the Remoteboot menu, click Convert Adapters.

Or, select more than one adapter record (hold down the CTRL key while clicking with the mouse). On the Remoteboot menu, click Convert Adapters. You will convert each of the selected records, one at a time.

Or, do not select any adapter records. On the Remoteboot menu, click Convert Adapters. You will convert all of the adapter records to workstation records, one at a time.
In Wksta Name, type a name for the client.

The name can have no more than 15 characters [with no spaces or backslashes (\)]. The Remoteboot service will create a Windows NT user account with this name, not for the user but for the client itself.

If the server's Rpl directory is on a FAT file system, use standard MS-DOS 8.3 format (eight characters, with an optional period and three more characters).
In Description, type a comment that describes the client.

The box already contains a comment provided by the network adapter itself.

Choose a configuration type:
- Click Shared if this client can share its profile with other clients.
- Click Personal if this client must use a personal copy of a profile so that you can customize the environment for the client.
In Wksta In Profile, click a profile for this client.

Profiles that are unsuitable for this type of adapter (determined by the first six digits of the network adapter ID number) are marked with a red X.

If none of the profiles are suitable, see "Setting Up and Starting the Remoteboot Service," earlier in this chapter, for instructions on creating profiles.
In TCP/IP Configuration, enter appropriate addresses only if the client will use TCP/IP and will not use DHCP for automatic address handling.
Click Add.

If you are converting more than one adapter ID record, the next record appears in the dialog box.

What You See on an MS-DOS or Windows 3.1 Client

When you boot the client, a remoteboot logon prompt appears:

Type Remoteboot username, or press enter if it is <workstation>:

This asks for the account name and password associated with the client itself, not for the user's own account name and password.

Once the boot is complete, the user should type a net logon command to log on with his or her own username and password.

When the client has completed a remote boot, the current directory is C:\, and the C drive is a virtual hard drive, parts of which are mapped to various places on the remoteboot server by the FIT file. For information about FIT files and translation pairs, see "Directory, File Index, and Configuration File Details" later in this chapter.

The C:\Wksta directory contains client-specific and profile-specific configuration files (such as Win.ini) and is different for each profile to which the client is joined. The C:\Data directory will always be the same, regardless of the profile used; the user can create files and directories there.

The C:\Dos and C:\Lanman.dos directories provide access to MS-DOS and network utilities. The C:\Binr directory provides access to shared real-mode utilities.

Local hard disks, if present, are assigned drive letters starting with D, unlike the local boot case, where the drive letters start with C.

Note: If the server uses NTFS, a client assigned to a profile (rather than to a personal copy of a profile) can add or modify files only in certain directories on its virtual C drive. It cannot affect directories on the C drive that are shared with other clients (unless you explicitly grant permission to do so on the server).

A remoteboot client always runs the NetBEUI protocol. To run other protocols as well, see "Supporting Multiple Network Adapters and Protocols" later in this chapter.

Changing a Workstation Record

You can change any of the properties of a workstation record except the network adapter ID number.

To change a workstation record for a client

Start Remoteboot Manager on the server.

Remember to log on to a user account that belongs to the Administrators local group.
Select the workstation record.

Or, select more than one record (hold down CTRL while clicking) to change properties for a group of clients at once.
On the Remoteboot menu, click Properties.
Update the information as needed.
Click OK.

Deleting a Client

When you no longer want to boot a workstation remotely, you can remove it from the list of workstations in the Remoteboot service.

To remove a client from the Remoteboot service

Start Remoteboot Manager on the server.

Remember to log on to a user account that belongs to the Administrators local group.
Select the workstation record for the client.

Or, select more than one record (hold down CTRL while clicking) to delete a group of workstation records at once.
On the Remoteboot menu, click Delete.
Verify that you want to delete this workstation record.

If Remoteboot Manager originally created an account while creating a workstation record, removing the workstation record also removes the account associated with that client. If the account existed before the workstation record, then the account will remain after removing the workstation record.

If the client was a Windows 95 client, you may want to delete the client's machine directory.

If the client has a bootable hard drive, you need to disable the remoteboot process and allow the client to use the hard drive again.

To disable the Remoteboot process

Start the client, booting MS-DOS remotely or from a floppy disk.
Put the disk with the Rpldsabl.exe program in the client's floppy disk drive and type:

a: rpldsabl

where a: is the client's floppy disk drive.

(If you don't have the disk anymore, see the section "Enabling Remoteboot on a Client's Hard Disk," earlier in this chapter, for instructions on making this disk.)
Remove the disk and press CTRL+ALT+DEL.

Installing Windows 95 for Windows 95 Clients

To support Windows 95 remoteboot clients, you must install Server-Based Setup (SBS) on a server, install the first Windows 95 client, and then install subsequent clients.

Installing SBS for Windows 95 Clients

For greater technical detail about SBS servers, see the Microsoft Windows 95 Resource Kit. When you set up an SBS server, you can use the server for remoteboot and for other purposes described in the Microsoft Windows 95 Resource Kit.

You will need a Windows 95 installation compact disc (not floppies) and a Windows 95 client computer.

To install an SBS server

On the server that will contain SBS files, create a shared directory with 90 MB of space available. The shared directory can have any name.

As you share the directory, assign read-only permission for regular users and full access for administrators. For example, use Server Manager to focus on the shared directory and set read-only permission for the Users group and full permission for the Administrators group. In File Manager, click Share As on the Disk menu, not Permissions on the Security menu.
Install one regular Windows 95 client on the network or use an existing one.

You will use this client to configure the SBS server.
Log on to the Windows 95 client using an account that has write access to the shared directory on the SBS server.
Put the Windows 95 compact disc in the client's CD-ROM drive. In Windows Explorer, switch to the Admin\Nettools\Netsetup directory.
Double-click Netsetup.exe.

Note that you must run Netsetup.exe at a Windows 95 client. It will encounter errors on a computer running Windows NT.
In the Server-Based Setup dialog box, click Set Path, and specify the path to the SBS server; then click OK.

You can type a drive letter for a mapped drive, a network name for a server (for example, \\server1\sharedir), or a network path to a specific directory (for example, \\server1\sharedir\rpl\win95).

The button name becomes Change Path if a server was defined previously.
Click Install.

Server-Based Setup presents a series of dialog boxes so that you can complete these actions:
- Specify an "install policy" for how users can install Windows 95 from the server. If you support only remoteboot clients, click Server. If you support other SBS functions as well, click User's choice. Do not click Local hard drive.
- Set the source path for Windows 95 files.
  
  This is the path to the compact disc on the client.
- If asked, specify that you do not want to create a default setup script.
  
  Setup scripts for Windows NT remoteboot installation require special settings.
- Provide a CD Key number for product identification.
Server-Based Setup copies Windows 95 files to the SBS shared directory.
At the remoteboot server, put the compact disc or floppy disk containing the Windows NT remoteboot for Windows 95 files into a drive. Change to the drive and then change to the Update\Win95 directory. Run win95srv.bat to update the Windows 95 files for remotebooting. For example:
```
 d:
 cd \update\win95
 win95srv.bat <dest>
```
where <dest> is the shared directory on the SBS server.
If you are updating from version 3.51 or earlier of the Remoteboot service, start the Remoteboot service at the remoteboot server if it is not already started. Then, run the rbootsrv.bat program to update the remoteboot files and database for Windows 95 remotebooting. At the server's command prompt, type:
```
 d:
 cd \update\win95
 rbootsrv.bat  <SBS_path>  <RPL_path>  [\\servername]
```
where:
- <SBS_path> is the path to the installed SBS server's Windows 95 files.
- <RPL_path> is the path to the remoteboot directory.
- \\servername is the name of the remoteboot server ; you can omit this if you are typing at the remoteboot server.
At the remoteboot server, start Remoteboot Manager.
On the Configure menu, click Check Configurations to activate the new configurations.

Installing the First Windows 95 Client

Installing the first Windows 95 client requires booting that client first to MS-DOS 6.2x, running Windows 95 Setup on the client, and then copying selected files from the client's machine directory to the remoteboot server. Once you have installed this first client, you can easily install subsequent clients by using SBS to make a modified copy of the original machine directory without having to run Windows 95 Setup again.

Each remoteboot client has a "machine directory," a directory on a server that contains client-specific configuration information and data. For example, the machine directory contains the following:

Appropriate initialization and configuration files (including Win.ini and System.ini)
System.dat and User.dat (the Registry)
Files that define the Desktop, Start menu directories, and other programs
The spool directory for printing
The swap file and Temp directory

Machine directories can reside on the remoteboot server, on the SBS server, or on any designated server on the network. You may want to spread the load of machine directories across servers. The only qualifications for a machine directory server are sufficient disk space and running the NetBEUI protocol. To create a location for machine directories, simply make a shared directory on a server and share it with a name that does not contain spaces. For example, on a computer running Windows NT Server that will contain machine directories, type:

mkdir c:\rplmachines
net share machines=c:\rplmachines

Note: The machine directories may not be subdirectories of the SBS directory.

Assign permissions to a machine directory so that only the users or administrators who will use the client have read and write permissions in the directory. If the machine directory is on an NTFS partition, assign permissions directly to the machine directories. If the machine directory is on a FAT partition, assign permissions to the shared directory containing the machine directories.

To install the first Windows 95 client

Boot the new client to MS-DOS 6.2x, using procedures in "Adding a New Client" earlier in this chapter.

You will need to run Windows 95 Setup while the client is booted from the Remoteboot service rather than when the client is booted from a floppy disk or hard drive.
Use the net logon command to log on using an account that has read access to the SBS server and write access to the shared directory that will contain this client's machine directory.

A good example is the account of someone who will use this client because they will need this access anyway.
Synchronize the time and date settings of the client, the SBS server, and the remoteboot server. Differing settings can interfere with Windows 95 Setup.
Use the net use command to map drive letters to the SBS server and machine directory location, and then determine the highest drive letter in use on the computer.

C: is a virtual hard drive mapped to parts of the remoteboot server. Each local hard drive partition (if any) takes another drive letter after C: (for example, D: and E: for two partitions). One more drive letter is reserved for use as a RAM drive during the Windows 95 boot process. Drive letters after that are available for use.

For example, if you have a local hard drive with one partition, C: will be mapped to the remoteboot server, D: will be the local hard drive, E: is reserved for use as a RAM drive, and F: and higher are available for use. You would type:
```
 net use f: \\sbs_server\win95_share
 net use g: \\mach_server\mach_share
```
Change to the drive letter mapped to the SBS directory.
Run the Windows 95 Setup program by typing:
```
setup  /t:temppath
```
where /t: is required and temppath is a path to a directory in which to store temporary files during installation. For example, if G: is mapped to the shared directory containing the client's machine directory, you could type:
```
setup  /t:g:\client1.tmp
```
to store temporary files on that server.

Do not delete the t:\temppath directory until you have completed Step 12. Also, if you are installing two Window 95 clients simultaneously (for example, to support clients with different network adapters), choose separate temporary directories for each client.

Make the following decisions during setup:
- In the Server-based Setup dialog box, click Set up Windows to run from a network server if asked.
- In the Startup Method dialog box, click Start Windows from the network (remote boot server).
- In the Machine Directory dialog box, when asked where to install Windows 95, type the path of the machine directory (using the drive letter specified in Step 4, for example, g:\client1).
- In the Setup Options dialog box, click Custom setup.
- In the Analyzing Your Computer dialog box, click No, I want to modify the hardware list.
  
  Exclude as many hardware types and items from autodetection as possible. If autodetection crashes, run Setup again and exclude more items from autodetection. One problem could be that your network adapter is on IR2 or IRQ3; this conflicts with serial port detection with some network adapters.
- In the Select Components dialog box, click to clear the Communications check box (unless the client has a modem and you intend to use dial-up networking).
- In the Network Configuration dialog box, check that your network adapter and desired protocols are present and configured correctly.
  
  If there are no network adapters shown, you must add and configure your network adapter.
  
  If you add your network adapter, you must confirm the resource settings for the adapter. Select the adapter name in the Network Configuration dialog box, click Properties, and then click the Resources tab. Check that the settings displayed are correct (for example, the interrupt level). Then, click OK to force the Setup program to accept the settings; do not click Cancel.
  
  For details about protocols on Windows 95 remoteboot clients, see "Supporting Multiple Network Adapters and Protocols" later in this chapter.
- In the Identification dialog box, make sure that the workgroup for this client is the same as the workgroup or domain of the SBS server and machine directory server.
When the Windows 95 Setup program is done, reboot the client. The client will not yet boot to Windows 95; however, you must complete more steps first.
At the remoteboot server (or a client running Remoteboot Manager focused on the remoteboot server), start Remoteboot Manager.
Create a profile for the Windows 95 client. In Configuration, click the Windows 95 configuration corresponding to the client's network adapter type.

If you are not sure which configuration to choose, check the profile that is currently associated with this client for booting MS-DOS and use the equivalent Windows 95 profile.
Edit the client's workstation record to assign the client to the Windows 95 profile.
At the remoteboot server (or a client with write access to the remoteboot server's Rpl directory), run the Rpl\Bin\Win95clt.bat program by typing:
```
 cd <systemroot>\rpl\bin
 win95clt  mach_directory  \\rpl_server  profile_name
```
where:
- mach_directory is the path to the client's machine directory.
- \\rpl_server is the name of the remoteboot server.
- profile_name is the name of the Windows 95 profile associated with the client.
For example, you could type:
```
 cd \winnt\rpl\bin
 win95clt  \\mach_server\mach_share\client1  \\rpl_server  win95elnk2
```
The Win95clt program copies client-specific Windows 95 real-mode (also identified as MS-DOS 7.0) boot files from the client's machine directory to the Rpl\Rplfiles\Profiles\<profile_name> directory on the remoteboot server.
At the SBS server (or a client with write access to the SBS directory), edit the Machines.ini file in the SBS directory and add the following lines for the new client:
```
 [adapter id]
 SYSDATPATH=g:\machine_dir
 g=\\mach_server\mach_share
```
where:
- adapter id is the network adapter ID, specified in the remoteboot workstation record for this client.
- g:\machine_dir is the location of the client's machine directory on a server; g is the drive letter assigned on the next line to the shared directory where the client's machine directory is located.
- g=\\mach_server\mach_share identifies the drive letter assigned to the shared directory where the machine directory resides. You must use the same drive letter and share name established in Step 4.
For example, you might add the following lines to Machines.ini:
```
 [02608C8EAA2D]
 SYSDATPATH=g:\client1
 g=\\mach_server\mach_share
```
Reboot the Windows 95 client.

The client will now boot to Windows 95 and complete the Windows 95 Setup program.

Installing Subsequent Windows 95 Clients

Once you have installed a single client, subsequent clients of the same type will be much easier to install. These subsequent clients do not have to be exactly the same as the first, but they must use the same type of network adapter and the same adapter settings (IRQ, I/O address, etc.).

If you need to install a Windows 95 client that does have different configuration settings, you must treat the installation as a fresh installation; see "Installing the First Windows 95 Client" earlier in this section.

To install subsequent Windows 95 clients

Boot the new client to MS-DOS 6.2x, using procedures in "Adding a New Client" earlier in this chapter.
Log on to a regular Windows 95 client (for example, the one you used to run netsetup when you established the SBS server).

Use an account that has write access to the shared directory on the SBS server and to the shared directory containing machine directories.
Put the Windows 95 compact disc in the client's CD-ROM drive. In Windows Explorer, switch to the Admin\Nettools\Netsetup directory.
Double-click Netsetup.exe.
In the Server-Based Setup dialog box, click Set Path, and specify the path to the SBS server; then click OK.

You can type a drive letter for a mapped drive, a network name for a server (for example, \\server1\sharedir), or a network path to a specific directory (for example, \\server1\sharedir\rpl\win95).

The button name becomes Change Path if a server was defined previously.
Click Add.

In the Set Up Machine dialog box, click Set Up One Machine and then type the following information:
- Computer name: type a computer name of the client (you must create a unique name).
- Path to machine directory: type a network pathname for the machine directory you want to create for the client.
- Existing machine directory: type the network pathname for an existing machine directory of a client similar to this one.
For example, you might type the following values:
- Computer name: client2
- Path to machine directory: \\mach_server\mach_share\client2
- Existing machine directory: \\mach_server\mach_share\client1
Click OK.

You may see an error message about creating the machine directory. Check that the directory was created and that it contains several files; if so, then disregard the error message.
At the remoteboot server (or a client running Remoteboot Manager focused on the remoteboot server), start Remoteboot Manager.
Edit the client's workstation record to assign the client to the same Windows 95 profile as the first client.
Edit the Machines.ini file in the SBS directory. Add the following lines for the new client:
```
 [adapter id]
 SYSDATPATH=g:\machine_dir
 g=\\mach_server\mach_share
```
where:
- adapter id is the network adapter ID, specified in the remoteboot workstation record for this client.
- g:\machine_dir is the location of the client's machine directory on a server; g is the drive letter assigned on the next line to the shared directory where the machine directory is located.
- g=\\mach_server\mach_share assigns a drive letter to the shared directory where the machine directory resides. Use the same drive letter used by the original Windows 95 remoteboot client.
For example, you might add the following lines to Machines.ini:
```
 [02608C8EAA2E]
 SYSDATPATH=g:\client2
 g=\\mach_server\mach_share
```
Reboot the Windows 95 client.

The client will now boot to Windows 95 and complete the Windows 95 Setup program.

What You See on a Windows 95 Client

When you boot the client, a remoteboot logon prompt appears:

Type Remoteboot username, or press enter if it is <workstation>:

This asks for the account name and password associated with the client computer itself, not for your own user account name and password.

Windows 95 then prompts you twice for your username and password: once from a command prompt and again in a dialog box. At both of these prompts, enter your user account name and password.

Once Windows 95 has started, the C: drive is unassigned; it was assigned during the remoteboot process and is no longer needed. Each local hard drive partition takes another drive letter after C: (for example, D: and E: for two partitions). One more drive letter was used as a RAM drive during the Windows 95 boot process; you can now use it as a RAM drive for your own purposes. Two more drive letters, usually the next two drive letters in sequence, are mapped to the SBS server and to the shared directory containing the client's machine directory. When setting up the client, you choose exactly which two drive letters to map and they will always be the same for this client. Do not unmap or remap these drives elsewhere.

For example, if you have a local hard drive with one partition, C: is unmapped, D: is the local hard drive, E: is a RAM drive, F: is mapped to the SBS server, and G: is mapped to the shared directory containing the client's machine directory.

Installing Windows 3.1 for MS-DOS Clients

You can install Windows 3.1 in similar client environments simply by creating a profile for Windows 3.1 users and installing the Windows 3.1 environment in the profile. In this way, you can add as many new clients as you need without having to install the Windows 3.1 environment with each new addition. Keep in mind, however, that all the clients sharing the profile must be similar enough to share the same startup information.

If the clients are not similar, you create personal copies of profiles. If Windows 3.1 is already installed for a profile, and you create a new personal copy of that profile, the Windows 3.1 installation is part of the new copy, and you do not have to reinstall it. If you have established a personal copy of a profile and later want to add Windows 3.1, you must add it separately for that personal copy of the profile, or delete the personal copy of the profile and create a new one from a profile that does have Windows 3.1 installed.

To support Windows 3.1 for remoteboot clients:

Install Windows 3.1 files on the remoteboot server. This makes the files easily available for client installations.
Create a profile for Windows 3.1 users. Install Windows 3.1 once for all clients using the profile.
Install Windows 3.1 separately for clients using a personal copy of a profile (if the profile did not support Windows 3.1 at the time you made the personal copy). Or, delete the client account and recreate it, making a personal copy of a profile that does support Windows 3.1.

Installing Windows 3.1 Files on the Server

Installing Windows 3.1 files on the server makes the files easily available for client installations.

To install Windows 3.1 files on the server

Create an MS-DOS profile, if one does not exist. (For details, see "Setting Up and Starting the Remoteboot Service" earlier in this chapter.)
Boot a remoteboot client that will use Windows 3.1, and join it to the MS-DOS profile using Remoteboot Manager. (For details, see "Adding a New Client" earlier in this chapter.)

Note: If you will use the shared Windows 3.1 profile method for similar clients, assign the client to use a profile, not a personal copy of a profile. If you will use the personal profile user method for different clients, assign the client to use a personal copy of a profile.
Reboot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.

If the client does not have a floppy disk drive, use the floppy disk drive of a server on the network:
- First, at the server (it doesn't have to be the remoteboot server), use File Manager or the net share command to share the server's floppy disk drive.
- Then, at the client, use File Manager or the net use command to connect to the shared floppy disk drive.
Put the Windows 3.1 Disk 1 in the floppy disk drive.
Run setup /a on the Windows 3.1 Disk 1 and install to C:\Win.

Windows 3.1 files are expanded and put into the <systemroot>\Rpl\Rplfiles\Binfiles\Win directory on the remoteboot server.

Continue the installation. Depending on how you want to set up profiles, proceed to "Installing Windows 3.1 for a Profile" or to "Installing Windows 3.1 for a Personal Copy of a Profile."

Installing Windows 3.1 for a Profile

When you install Windows 3.1 for a profile, all clients that share that profile use Windows 3.1. Also, if you later assign a personal copy of the profile to a client, that client uses Windows 3.1.

To install Windows 3.1 for a profile

Create a profile for Windows 3.1 users on the remoteboot server.

Give the profile a specific name that suggests the Windows version and the operating system associated with it. For example, D62WIN31 tells you that this profile is for MS-DOS 6.2x with Windows version 3.1.
In Remoteboot Manager, assign a remoteboot client to the new profile (not using a personal copy of the profile).
Reboot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.
On the client, change to the Windows 3.1 directory by typing:

cd \win
On the client, run setup /n to install Windows 3.1 in C:\Windows (do not choose to upgrade any existing Windows installations). Choose the express installation.

If the client has memory trouble while running Setup, see "Configuring Memory for MS-DOS and Windows 3.1" later in this chapter.
Follow the instructions in the Setup program to modify the Autoexec.bat and Config.sys files.

Note: If Setup displays an error message saying that it cannot update your system files on drive C, choose Cancel. This creates Autoexec.win and Config.win files in the C:\Windows directory. Copy these files to C:\Autoexec.bat and C:\Config.sys, respectively.
Add the following lines to the end of the [386enh] section in the C:\Windows\System.ini file:
```
 TimerCriticalSection=5000
 UniqueDosPSP=True
 PSPIncrement=2
```
Return to the MS-DOS prompt and copy all the files and directories in C:\Windows to C:\Wksta.pro\Win by typing:

xcopy /e c:\windows c:\wksta.pro\win

This makes the Windows 3.1 files available to all remoteboot clients that are joined to the profile.

If the xcopy command does not work on the client, you can copy the files from a command prompt on the server by typing the following command, all on one line:

xcopy /e c:\systemroot\rpl\rplfiles\machines\client\profile\wksta\win
c:\systemroot\rpl\rplfiles\profiles\profile\wksta\win

where client is the name of the client and profile is the name of the profile.
Reboot the remoteboot client and log on.

Installing Windows 3.1 for a Personal Copy of a Profile

If you assign a personal copy of a profile (without Windows 3.1) to a client, and then later decide that you want to install Windows 3.1 for that client, you can install Windows 3.1 separately for this client. Or, delete the client account and recreate it, making a personal copy of a profile that does support Windows 3.1.

You may want to install a separate copy of Windows 3.1 for a client if the client requires customized Windows 3.1 configuration files.

To install Windows 3.1 for a personal copy of a profile

On the remoteboot server, assign the remoteboot client to an MS-DOS profile. Specify a personal copy of the profile.
Reboot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.
On the client, change to the Windows 3.1 directory by typing the following:

cd \win
Run setup /n to install Windows 3.1 in C:\Windows (do not choose to upgrade any existing Windows installations). Choose the express installation.

If the client has memory trouble while running Setup, see "Configuring Memory for MS-DOS and Windows 3.1" later in this chapter.
Follow the instructions in the Setup program to modify the Autoexec.bat and Config.sys files.

Note: If Setup displays an error message saying that it cannot update your system files on drive C, choose Cancel. This creates Autoexec.win and Config.win files in the C:\Windows directory. Copy these files to C:\Autoexec.bat and C:\Config.sys, respectively.
Add the following lines to the end of the [386enh] section in the C:\Windows\System.ini file:
```
 TimerCriticalSection=5000
 UniqueDosPSP=True
 PSPIncrement=2
```
When the Setup program is finished, reboot the client and log on.

Top Of Page

Optimizing the Remoteboot Service

Once the Remoteboot service has been configured and customized for your network needs, Windows NT Server offers some additional ways to optimize the service. Most of the topics in this section deal with increasing performance. Other topics tell you how to further customize your configuration.

This section contains information on how to:

Use the rplcmd utility to change the remoteboot database.
Create remoteboot configurations for new adapters.
Configure memory for MS-DOS and Windows 3.1.
Configure memory for Windows 95.
Set local swapping.
Use a RAM drive on the client.
Set hardware buffers.

Using the Remoteboot Command Utility (RPLCMD.EXE)

The rplcmd utility can be used to view and update records in the remoteboot database, including those that are inaccessible through Remoteboot Manager. This utility is for advanced administrators, not for casual use.

Before you use rplcmd, make sure that you have a backup copy of the remoteboot database. For details, see "Backing Up the Remoteboot Database" later in this chapter.

This is the syntax of rplcmd:

rplcmd [\\computername]

where \\computername specifies a remote computer where the Remoteboot service is running. If this parameter is omitted, rplcmd manages the Remoteboot service on the local computer.

The main rplcmd command prompt appears as:

Adapter Boot Config Profile Service Vendor Wksta [Quit]

Each command has the following effect:

Adapter modifies adapter records (records of remoteboot clients that have been started but do not yet have a workstation record assigned).
Boot modifies boot block records.
Config modifies configuration records.
Profile modifies profiles.
Service controls the Remoteboot service.
Vendor associates a vendor "name," or six-digit hexadecimal prefix, with a text comment describing the vendor.
Wksta modifies workstation records.

To select a command, type the first letter in the command name and press ENTER. To return to the main menu, press CTRL+Z at any prompt and press ENTER.

Each of the main commands has further command prompts, including these common commands:

Add — to add a new record.
Del — to delete a record (or all records).
Enum — to enumerate, or show information for, a record (or all records). You can enumerate information at different levels; level 0 gives you the least information per record.

Creating Remoteboot Configurations for New Adapters

The following section is for advanced administrators.

Note: Before you use rplcmd, make sure that you have a backup copy of the remoteboot database. For details, see "Backing Up the Remoteboot Database" later in this chapter.

When the Remoteboot service receives a boot request, it looks up the workstation record associated with the client's network adapter ID (if there isn't one, then it creates an adapter record and does not attempt to boot the client). It then determines the profile associated with the workstation record and the configuration record that was used to create the profile. The configuration record contains a boot block record name, and more than one boot block record may have the same name. The Remoteboot service looks for a boot block record with this boot block record name and the vendor ID contained in the client's network adapter ID. The configuration record and the boot block record provide the information needed to boot the client.

Windows NT Server provides boot block and configuration records for the most popular network adapters.

Use the following procedure if Remoteboot Manager cannot assign a workstation record to the correct profile because the network adapter type is incompatible. This can happen when there is no existing boot block record mapping the network adapter vendor ID to the correct network adapter type. You must create a new boot block record specifying the vendor ID and the network adapter type. If any client with this network adapter type will boot to Windows 95, you must create an MS-DOS boot block record and a Windows 95 boot block record.

To create a new boot block record for a supported network adapter type

Use the rplcmd utility to add boot block records for the adapter and vendor ID. For details about the rplcmd utility, see the preceding section, "Using the Remoteboot Command Utility (RPLCMD.EXE)."

For BootName, use the name of an existing boot block record that boots clients with network adapters of this type (but with a different vendor ID).

For example, the following sequence of commands creates sample boot block records for MS-DOS and Windows 95:
```
 C:\winnt\rpl> rplcmd
 Adapter Boot Config Profile Service Vendor Wksta [Quit]: b
 Add Del Enum: a
 BootName=DOSX
 VendorName=012345
 BbcFile=BBLOCK\NETBEUI\dirname\DOSBB.CNF
 All other parameters are optional
 BootComment=Name of this adapter
 WindowSize=0
 Adapter Boot Config Profile Service Vendor Wksta [Quit]: b
 Add Del Enum: a
 BootName=W95X
 VendorName=012345
 BbcFile=BBLOCK\NETBEUI\dirname\W95BB.CNF
 All other parameters are optional
 BootComment=Name of this adapter
 WindowSize=0
 Adapter Boot Config Profile Service Vendor Wksta [Quit]: v
 Add Del Enum: a
 VendorName=012345
 BootComment=Name of this adapter
```
Note: In this example, and in those that follow, the value 012345 represents the "vendor name" or network adapter prefix. Replace this with the first six digits of the network adapter type's adapter identification number.

If the adapter prefix for the new adapter type matches that of an existing adapter type, modify the BootName field of the boot block and workstation record field to be unique among all boot block or workstation records corresponding to that adapter prefix. For example, use DOS for IBM Token Ring and DOSI for IBM Ethernet.

If you want to use a new remoteboot-compatible network adapter that is not already supported by Windows NT Server, you must manually create a new boot block, boot block record(s), and a configuration record corresponding to the new adapter. This allows the Remoteboot service and Remoteboot Manager to recognize the new adapter type.

Microsoft does not guarantee support for adapters that are not on the list of supported adapters (see "Supported Network Adapters" earlier in this chapter). Note especially that the Remoteboot service does not support PCI, Token-Ring, or PNP adapters for Windows 95 remoteboot clients.

To support Windows 95 clients with a particular network adapter type, you must create both an MS-DOS 6.2x configuration and a Windows 95 configuration.

To create an MS-DOS configuration for a new adapter

Copy the MS-DOS device driver for the network adapter to the <systemroot>\Rpl\Bblock\Ndis directory.

Create the directory <systemroot>\Rpl\Bblock\Netbeui\adapter, where adapter is the name of the adapter. Within this directory, create these files:
- Dosbb.cnf
- Protocol.ini
Pattern these files after existing files in a corresponding directory, but substitute the new driver names in the Dosbb.cnf file, and the correct driver information in the Protocol.ini file.
Use the rplcmd utility to add a boot block record for the new adapter. For details about the rplcmd utility, see the preceding section, "Using the Remoteboot Command Utility (RPLCMD.EXE)."

For example, the following sequence of commands creates a sample boot block record:
```
 C:\winnt\rpl> rplcmd
 Adapter Boot Config Profile Service Vendor Wksta [Quit]: b
 Add Del Enum: a
 BootName=DOSX
 VendorName=012345
 BbcFile=BBLOCK\NETBEUI\dirname\DOSBB.CNF
 All other parameters are optional
 BootComment=Name of this adapter
 WindowSize=0
```

Use the rplcmd utility to add the new configuration.

For example, the following sequence of commands creates a sample configuration:

 C:\winnt\rpl> rplcmd
 Adapter Boot Config Profile Service Vendor Wksta [Quit]: c
 Add Del Enum: a
 ConfigName=DOS622X
 BootName=DOSX
 DirName=DOS
 DirName2=DOS622
 FitShared=fits\dos622.FIT
 FitPersonal=fits\dos622p.FIT
 All other parameters are optional
 ConfigComment=DOS 6.22 <adapter name>
 DirName3=
 DirName4=

For BootName, enter the name of the boot block record you created in step 3.

To create a Windows 95 configuration for a new adapter

Boot the client to MS-DOS 6.2x to confirm that the MS-DOS configuration is correct. For details, see "Adding a New Client" earlier in this chapter.
In the <systemroot>\Rpl\Bblock\Netbeui\adapter directory, where adapter is the name of the adapter, copy the Dosbb.cnf file to W95bb.cnf.
Edit the new W95bb.cnf file to change the following line:
```
EXE BBLOCK\I13.COM ~ ~ ~
```
to read:
```
EXE BBLOCK\W95I13.COM ~ ~ ~
```
Use the rplcmd utility to add a boot block record for the new adapter. For details about the rplcmd utility, see the preceding section, "Using the Remoteboot Command Utility (RPLCMD.EXE)."

For example, the following sequence of commands creates a sample boot block record:
```
 C:\winnt\rpl> rplcmd
 Adapter Boot Config Profile Service Vendor Wksta [Quit]: b
 Add Del Enum: a
 BootName=W95X
 VendorName=012345
 BbcFile=BBLOCK\NETBEUI\dirname\W95BB.CNF
 All other parameters are optional
 BootComment=Name of this adapter
 WindowSize=0
```

If there is not already a Windows 95 configuration for this BootName, then use the rplcmd utility to add the new configuration.

For example, the following sequence of commands creates a sample configuration:

 C:\winnt\rpl> rplcmd
 Adapter Boot Config Profile Service Vendor Wksta [Quit]: c
 Add Del Enum: a
 ConfigName=W95X
 BootName=W95X
 DirName=DOS
 DirName2=W95X
 FitShared=fits\win95.FIT
 FitPersonal=fits\win95p.FIT
 All other parameters are optional
 ConfigComment=Windows 95 <adapter name>
 DirName3=
 DirName4=

For BootName, enter the name of the boot block record you created in step 4.

Configuring Memory for MS-DOS and Windows 3.1

Here are two tips for configuring the remoteboot client to use memory most efficiently while running MS-DOS version 5.0 or later, Windows 3.1 Setup, or Windows 3.1 itself.

Configuring EMM386.EXE

The Config.sys file contains a device line for Emm386.exe. This line is disabled (the line starts with REM) because you must calculate the parameters. This procedure is for a 386-based (or higher) client running MS-DOS 5.00 or later.

To configure Emm386 for more upper memory

Find out how much conventional memory the client has (in decimal terms) by typing mem at the MS-DOS prompt.
Convert this number to hexadecimal format and drop the rightmost digit. To convert, you can use the dectohex command in the <systemroot>\Rpl\Rplfiles\Binfiles\Binr directory.

Edit the device=Emm386.exe line in the Config.sys file.
- Remove the REM designation at the beginning of the line. Check that the path specified for the file is the root (C:\) directory, not the C:\Dos directory.
- Use the remaining four digits of the hexadecimal value for the first x= value. (The second x= value is 9FFF and should not be changed.)
For example, if conventional memory is 598016, the hexadecimal value is 92000. In this case, use x=9200-9FFF.

Disabling SMARTDRV.SYS

Windows 3.1 installs a device command in the Config.sys file to use Smartdrv.sys. If your Windows 3.1 client seems to be operating slowly, experiment with disabling this line. Disabling Smartdrv.sys may speed the process up by giving Windows 3.1 memory on the client rather than on a disk cache.

To disable SMARTDRV.SYS

Disable the device=SMARTDRV.SYS line (precede it with REM) in the client's Config.sys file.

Configuring Memory for Windows 95

With Windows 95, you generally do not need to load Emm386 in the Config.sys file. When you need to exclude ranges of memory used by a network adapter card or other peripheral device, edit the System.ini file in the client's home directory. In the [386Enh] section, add a line like the following:

[386Enh]
EMMExclude=CC00-CFFF

Setting Up Local Swapping

You can increase performance on your Windows 95 and Windows 3.1 remoteboot clients by using the client's hard drive for swapping.

To set up local swapping on Windows 95 clients

Add a pagingfile=path entry in the [386Enh] section of the System.ini file in the client's machine directory.

To set up local swapping on Windows 3.1 clients

Edit the swapfile line in the client's System.ini file to point to drive D.

Using a RAM Drive on the Client

You can optimize post-boot performance on your remoteboot clients by using a RAM drive. Use of a virtual disk, such as the Ramdrive.sys provided with most MS-DOS versions, can reduce network traffic by storing commonly used files and utilities locally. (If, however, the client does not have RAM to spare, using a virtual disk could increase swapping.)

The RAM drive should be placed first in the PATH environmental variable. Giving memory to file caches may also help performance, especially on the remoteboot server. For more information about memory management, see the documentation for the MS-DOS operating system and for the network client software.

Setting Hardware Buffers

To achieve maximum possible usage of upper memory blocks (UMBs) for MS-DOS 5.0 or later, set hardware buffers to be contiguous and as low as possible within the C000-F000 range.

By making sure that the address ranges (ROM and RAM) are as contiguous as possible, you will be able to create the largest single, free address range. This will provide more UMBs for MS-DOS than fragmenting the address ranges.

On PC/AT computers, refer to the hardware and software manuals that came with your adapters to determine the address ranges that can be set. Usually, this is done with jumpers on the adapter, but occasionally it must be changed with a setup program. Once you have determined the address ranges, arrange them to be as close together as possible without overlapping.

On PS/2 computers, you will need to run the reference disk and supply the ADF files (if they are not already on the disk) for all the adapters. Using the reference disk program, you can determine address ranges for each adapter, and then set them.

Top Of Page

Directory, File Index, and Configuration File Details

The following sections describe the structure of the RPL directory and the formats of remoteboot configuration files.

The RPL Directory

The following illustration shows the subdirectories created in the <systemroot>\Rpl directory when you install the Remoteboot service.

xng_s11

Directories that are automatically installed should not be deleted (for example, do not delete C:\Tmp from a remoteboot client). If a directory is deleted, you must recreate it and set the permissions with the Remoteboot Manager Fix Security command, or you can use Remoteboot Manager to delete the affected workstation record and recreate it (after first saving any client-specific files).

In the <systemroot>\Rpl directory, the System.mdb and Rplsvc.mdb files contain the remoteboot database. The Jet.log file contains information used in recovery from power failures or other catastrophic interruptions.

File Index Tables

File index tables (or FIT files) are ASCII files containing filename lookup tables that enable file translation. Remoteboot client software translates a directory name or filename typed by the client user into the true directory name or filename on the server. In general, the client translates references of the form C:\... to \\servername\Rplfiles\... (that is, to locations in the <systemroot>\Rpl\Rplfiles directory on the server).

Windows 95 clients use a .fit file only in the early stages of their boot process. Once the client is running Windows 95, it uses storage defined by the SBS server and machine directory server.

File translation pairs consist of a prototype filename or prefix, followed by a space, and an actual filename or prefix, relative to the directory named on the first line [usually (Rplfiles)]. If the prototype matches a proper prefix of the name to be matched, the matched portion is replaced by the actual prefix. If there is an exact match (not just a prefix), the actual filename is substituted. If several prefixes match, the longest one is selected for substitution. A network path of the form \\any_servername\sharename may be included in the actual filename or prefix, in which case it overrides the directory listed on line one.

Examples:

If the client requests access to C:\Win386.swp (for example, to open it for writing), the client software will use the .fit file to translate it into:
```
\\servername\RPLFILES\TMPFILES\(CNAME)\SWAPFILE.DAT
```
where (CNAME) is the client name.
If C:\Config.sys is requested, the following will be used because it has the longest matching prefix (C:\):
```
\\servername\RPLFILES\PROFILES\(PROFILE)\CONFIG.SYS
```
where (PROFILE) is the profile name. The line near the top of each .fit file that starts with C:\ sends all C:\ references that aren't at least partially matched by other lines to the directory \\servername\Rplfiles\Profiles\(Profile).

Note that the "machine writeable files" section of each .fit file lists the files and directories to which the user has write access.

By convention there are usually two .fit files for each profile: one to be used when sharing the profile and one to be used with personal copies of the profile. For example, Dos622.fit is for clients that share the Dos622 profile, and Dos622p.fit is for personal copies of the Dos622 profile. The file format is the same, but the personal profile .fit translates most references to directories specific to the client rather than to directories shared with other clients. The .fit file used for Windows 95 clients has no differences between the shared and personal versions.

Fields in .fit files are separated with white space. The maximum line length is 512 characters. A comment line has a semicolon (;) as the first non-space character.

The following keywords have special meaning in a .fit file:

(PROFILE) is the name of the profile assigned to this client.
(CNAME) is the name of the client.
(RPLFILES) is the <systemroot>\Rpl\Rplfiles directory, shared by the server with the sharename Rplfiiles.
(BINFILES) is a directory for executable files. It is assumed to be relative to Rplfiles (\systemroot\Rpl\Rplfiles\Binfiles).
(TMPFILES) is a directory for temporary and swap files. It is assumed to be relative to Rplfiles (<systemroot>\Rpl\Rplfiles\Tmpfiles).

Boot Block Configuration Files

The boot block configuration file specifies the contents of the boot block sent to the client by the Remoteboot service and is designated by the .cnf extension. The boot block normally includes the Rplboot.sys, Rplstart.com, and Rpldisk.sys files and the real-mode network drivers. The boot block also contains some client-specific data (a copy of the workstation record from the remoteboot database) and some profile-specific data (the .fit file associated with the profile used).

A line in a .cnf file typically has three fields:

Type
Filename (path is relative to the <systemroot>\Rpl directory)
Parameter(s)

All valid types are listed next, along with their expected filenames and parameters.

Fields in .cnf files are separated with white space. Spaces within a field are represented with a tilde (~). The maximum line length is 512 characters. A comment line has a semicolon (;) as the first non-space character.

Note: The DRV and EXE types of boot block configuration files must be specified in the reverse order in which they would normally occur in a Config.sys file. For example, if ABC.DRV must appear before DEF.EXE in Config.sys, DEF.EXE must appear before ABC.DRV in the .cnf file.

RPL Type

The filename specified with the RPL type is the initialization program that runs on a client. There must be exactly one RPL type in a .cnf file. The initialization program is normally Rplboot.sys.

BASE Type

The value specified with the BASE type is a hexadecimal segment number that identifies the base address of the boot block. There can be only one BASE type in a .cnf file. If none is specified, 00C0h is used as the default base address.

DAT Type

Files listed with the DAT type specify data files that should be stored on the boot block. The filename is relative to <systemroot>\Rpl.

LDR Type

The filename and parameters listed with the LDR type specify which loader to use on the client. The loader is the program that Rplboot.sys will pass control to; there can be only one LDR keyword. The loader is normally Rplstart.com.

DRV Type

The filename and parameters listed with the DRV type specify the device drivers used to form the boot block. The filename field specifies the name of the device driver. The DRV type has three parameter fields:

The first field specifies parameters used by the device driver.
The second field specifies any additional memory used by the device driver (in decimal kilobytes).
The third field is M if the device driver can be moved in memory to reuse space that it doesn't need; it is ~ if the device driver cannot be moved.

If the driver can be moved after initialization and its memory requirements are less than for the original driver image, Rplboot.sys moves the driver to reclaim some of the unused memory and adjusts all interrupt vectors that point into the driver's memory area. Some drivers cannot be moved because they record segment addresses that are correct during initialization but not after the driver has been moved.

EXE Type

Files listed with the EXE type specify executables (.exe and .com files) that are run during the boot process. The filename is the name of the executable, and the parameters field specifies arguments passed to the executable. EXE lines must be specified in reverse order—that is, the last one listed in the boot block configuration file will be the first one executed.

Top Of Page

Supporting Multiple Network Adapters and Protocols

The method of supporting multiple network adapters or multiple protocols depends on whether the client runs Windows 95 or MS-DOS/Windows 3.1.

Using Multiple Network Adapters and Protocols with Windows 95

If the client has multiple network adapters, only one should have a RPL ROM. When you configure the client's workstation record in Remoteboot Manager, specify a profile corresponding to the network adapter with the RPL ROM.

You need NetBEUI and DLC connectivity to the remoteboot server in order to set up and boot a Windows 95 client. The network adapters and protocols defined in Windows 95 Setup become active once the Windows 95 real-mode client is booted. You no longer need NetBEUI or DLC at this phase, as long as you can access the SBS server and the shared directory containing your machine directory.

Using Multiple Network Adapters with MS-DOS and Windows 3.1

If a remoteboot MS-DOS or Windows 3.1 client computer has multiple network adapters, you will need to modify the boot block information for the adapter that has the RPL ROM chip.

To modify the boot block information

Using Remoteboot Manager, create a new profile.
Add the network adapter driver to the <systemroot>\Rpl\Bblock\Netbeui\adapter\Dosbb.cnf boot block configuration files, where adapter is the name of the adapter that has the RPL ROM chip on the client computer.
Update the <systemroot>\Rpl\Bblock\Netbeui\adapter\Protocol.ini file with sections for the new network adapter driver.

Using Multiple Protocols with MS-DOS and Windows 3.1

A remoteboot MS-DOS or Windows 3.1 client always runs the NetBEUI protocol. This section describes how to install support for TCP/IP, DLC, and IPX protocols for use by remoteboot clients.

Installing TCP/IP Support

Before you set up clients to use TCP/IP, you must either enable DHCP to assign addresses automatically, or you must assign IP addresses and subnet masks for each client that will use TCP/IP. (See the Windows NT Server TCP/IP manual for more information about TCP/IP addresses.)

When you have arranged for addresses, you can then enable TCP/IP support.

To enable TCP/IP support

Edit the <systemroot>\Rpl\Bblock\Netbeui\adapter\Dosbb.cnf file, where adapter is the name of the network adapter. Remove the semicolon (;) in column one of this line:
```
;DRV    BBLOCK\TCPDRV.DOS /I:C:\LANMAN.DOS ~ ~
```
For each profile (or personal copy of a profile) that will support TCP/IP, edit the following files as described:
- In <systemroot>\Rpl\Rplfiles\Profiles\profile\Autoexec.bat, where profile is the name of the profile, enable umb.com, nmstr, and load tcpip by removing the REM designations at the beginnings of those lines.
- In <systemroot>\Rpl\Rplfiles\Profiles\profile\Config.sys, where profile is the name of the profile, enable nemm.dos by removing the REM designation at the beginning of that line.
Boot a client using one of the profiles altered in the last step.

Installing MS-DLC Support

To install MS-DLC support

At the client, type load msdlc.

Or, add this command to the end of the client's Autoexec.bat file.

Installing IPX Support

When you install IPX support, you will need the Microsoft Network Client version 2.2 NetWare Connectivity disk and the Novell NetWare SHGEN-1 and SHGEN-2 disks (or the WSGEN disk).

Note: IPX support is installed per adapter and is MS-DOS version specific. Follow the installation procedure for each adapter that will support IPX; define profiles for each version of MS-DOS that will support IPX.

To install IPX support

On the server, edit the <systemroot>\Rpl\Bblock\Netbeui\adapter\Dosbb.cnf file, where adapter is the name of the network adapter. Remove the semicolon (;) in column one of this line:
```
;DRV    BBLOCK\IPXNDIS.DOS ~ ~ ~
```
Create a new profile with a name that describes IPX support (for example, DOS62IPX).

Note: IPX is MS-DOS version specific. You must create a separate profile for each version of MS-DOS that will support IPX.
Assign a client to the new profile.
Boot the client.

At the remoteboot logon prompt (the prompt that first appears when you start the client), supply the name and password of an account that is a member of the Administrators group on the Windows NT Server computer.

If the client does not have a floppy disk drive, use the floppy disk drive of a server on the network:
- First, at the server (it doesn't have to be the remoteboot server), use File Manager or the net share command to share the server's floppy disk drive.
- Then, at the client, use File Manager or the net use command to connect to the shared floppy disk drive.
Put the Microsoft Network Client NetWare Connectivity disk in the floppy disk drive.
On the client, run the NetWare Connectivity Setup program by typing a:nwsetup (use a different drive letter if needed).

When prompted, insert the Novell NetWare SHGEN-1 and SHGEN-2 disks (or the WSGEN disk).
Reboot the client.

Supply the client password (if any).
Log on to the client with a normal user account.
To start using the IPX protocol, type nwload. Or, add this command to the end of the client's Autoexec/bat file.

IPX is now installed on the client's profile and is available for use by other clients using this profile.

Top Of Page

Backing Up the Remoteboot Database

The remoteboot database holds the configuration, workstation, and profile records and other data for the Remoteboot service. You should back up the database before and after you make significant changes and save the copies. The Remoteboot service automatically backs up the database every 24 hours (counting from when you start the service).

Because the Remoteboot service makes automatic backups (overwriting the current backup copies), and for good administrative procedure, you should occasionally archive copies of the backup files.

To back up the remoteboot database

On the Configure menu of Remoteboot Manager, click Backup Database.

The Jet.log, Rplsvc.mdb, and System.mdb files are backed up to the <systemroot>\Rpl\Backup directory.

To restore a backup copy of the remoteboot database

Copy the files from <systemroot>\Rpl\Backup (or other saved versions of the files) to the Rpl directory.

In the event of an emergency (such as a corrupted database), the Remoteboot service restores automatically from the <systemroot>\Rpl\Backup directory.

Top Of Page

Troubleshooting Remoteboot

This section lists some common problems you may encounter using the Remoteboot service. For more troubleshooting information, see the \CLIENTS\RPL\README.TXT file on the Windows NT Server compact disc.

Remoteboot Service Won't Start

Check the server's event log, which can provide useful diagnostic information. In the Administrative Tools group, select Event Viewer.

Remoteboot Manager Won't Start

Be sure that you are logged on using an account that is a member of the Administrators local group.

Remoteboot Service Stops

Be sure that the server's own network configuration is correct, including hardware settings for the network adapter.

Remoteboot Client Won't Start

If a client won't boot remotely, or if you're having problems with the way the client is booting:

Be sure that the server is running and that the Remoteboot service is running.
The client must be on the same subnet as the server.
Check Remoteboot Manager's list of adapters that have not yet been converted to workstation records. To update the list, choose Refresh from the View menu. If the client's adapter is on the list, convert the adapter record to a workstation record.
Check the <systemroot>\Rpl\Fits directory. The server must have a .fit file for each profile that is to boot remotely.
Each client must have an RPL ROM chip installed on or built into its network adapter. This ROM chip may need to be enabled via jumpers or a configuration program.
Check the defaults for hardware settings in the <systemroot>\Rpl\Bblock\Netbeui\adapter\Protocol.ini file.
If the client has a hard disk, the hard disk may need to be prepared for the Remoteboot service using the rplenabl utility.
If the remoteboot server is a backup domain controller, wait until the account you've added has been replicated (or force synchronization to the primary domain controller using Server Manager).

No Profiles Available

You have not yet created any profiles. See "Managing Profiles" earlier in this chapter.

No Configurations Available

On the Remoteboot Manager Configure menu, click Check Configurations. If there still are no configurations available, you have not yet copied MS-DOS files to the server. See "Installing MS-DOS Files on the Remoteboot Server" earlier in this chapter.

Top Of Page

Site Feedback

On This Page

Understanding the Remoteboot Service

The Remoteboot Process

How Does Remoteboot Work?

Why Use Remoteboot?

Setting Up and Starting the Remoteboot Service

Disk Space Requirements

Supported Network Adapters

Installing the Remoteboot Service on the Remoteboot Server

Installing MS-DOS Files on the Remoteboot Server

Starting and Stopping the Remoteboot Service

Starting Remoteboot Manager

Checking the Remoteboot Installation

Managing Profiles

Managing Remoteboot Clients

Enabling Remoteboot on a Client's Hard Disk

Adding a New Client

Deleting a Client

Installing Windows 95 for Windows 95 Clients

Installing Windows 3.1 for MS-DOS Clients

Optimizing the Remoteboot Service

Using the Remoteboot Command Utility (RPLCMD.EXE)

Creating Remoteboot Configurations for New Adapters

Configuring Memory for MS-DOS and Windows 3.1

Configuring Memory for Windows 95

Setting Up Local Swapping

Using a RAM Drive on the Client

Setting Hardware Buffers

Directory, File Index, and Configuration File Details

The RPL Directory

File Index Tables

Boot Block Configuration Files

Supporting Multiple Network Adapters and Protocols

Using Multiple Network Adapters and Protocols with Windows 95

Using Multiple Network Adapters with MS-DOS and Windows 3.1

Using Multiple Protocols with MS-DOS and Windows 3.1

Backing Up the Remoteboot Database

Troubleshooting Remoteboot

Remoteboot Service Won't Start

Remoteboot Manager Won't Start

Remoteboot Service Stops

Remoteboot Client Won't Start

No Profiles Available

No Configurations Available