The Remoteboot service works by providing two kinds of resources at the server:
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:
1. 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.
2. Copies Windows 95 real-mode files from the remoteboot server to the RAM disk.
3. 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.
4. Connects to a server that has a machine directory with files specific to this client.