Intel® vPro™ Technology

Remote System Repair Using Intel® vPro™ Technology

RSR Architecture Overview

RSR is a succinct solution architecture using two key technological ingredients present in platforms with Intel® vPro™ technology, Fast Call for Help and IDE-Redirect (IDE-R).

Fast Call for Help
Fast Call for Help allows platforms outside the enterprise firewall to trigger a connection to the Internet with a gateway enabled by Intel vPro technology, as shown in Figure 1. The platform user presses a special button or key combination to initiate the platform connection to a remote gateway enabled with Intel vPro technology. Upon establishing a successful connection, a standardized event, such as a Platform Event Trap (PET) or WS_Event is propagated to the enterprise network to register the client, either in the enterprise or in the remediation network. Full details of this technology are provided in [2].

Once this secure connection to the enterprise is established by the platform firmware, all of the traffic originating from the client can be routed through this connection. Any console can potentially connect to this remote platform and subsequently trigger the remediation process.

Figure 1: Intel Fast Call for Help
Source: Intel Corporation, 2008
click image for larger view

IDE- Redirection
The IDE-R feature in Intel vPro technology platforms provides the capability to boot a platform to a remote CD/DVD drive or to a bootable image file present in a server. Basically IDE-R creates the illusion that a remote CD drive or an ISO image is on a local drive. Intel vPro technology internally intercepts all read/write requests and transports them over a pre-established, secure, network connection set up just for this purpose. This gives the platform an opportunity to boot over the network by using IDE-R, and upon successful boot, it provides access to a remote CD/DVD drive. Usually, images, such as a diagnostic OS, are used for remote heal.

RSR Solution Outline
By using Fast-call for Help and IDE-R, a two-stage RSR solution can be created with appropriate sequencing.

The first stage involves booting the platform to a small OS as follows:

1. Instruct the end-user to press a key and initiate a secure Fast-call for Help session.
2. Upon successful connection, the console should take control of the system with user acceptance and remotely redirect the client to boot to a small OS, such as MS-DOS, from the server.

In the second stage, utilities from stage one will help copy the diagnostic OS image or the spare-tire OS image, from the remote drive, to a storage device in the client. Once the image is present locally, the client can be booted to it as many times as necessary until it is fully functional, without having to download the image every time.

RSR Use Cases

Case 1: Re-use Local Diagnostics and Repair
Many OEMs build in some basic hardware diagnostic routines into their BIOS. Since BIOS setup usually runs in text mode (or can be run in text mode), it can be remotely controlled via SOL. Using SOL, IT support personnel can boot the system into BIOS and perform diagnostics remotely to determine if major hardware components are functioning properly. A typical example of this use case is to verify if the hard disk is functional by remotely performing hard-drive diagnostics from BIOS.

Some OEMs also install a diagnostic OS in a separate partition in the hard disk drive (HDD). Such an OS can be booted when the main OS is inoperable, by pressing a special key during boot. Typically a diagnostic OS is a trimmed-down version of the main OS, and therefore it comes with many of the same system tools as the main OS, tools that can be used to diagnose and repair problems. With IDE-R, additional tools and updated drivers can be downloaded at runtime and patched into the main OS. To remotely display and control this OS, some type of remote keyboard/video/mouse (KVM) capability is needed, since the OS typically runs in graphical mode, and SOL is effective only in text mode. Alternatively, an OEM can build software-based remote-control applications, such as KVM redirection software, into the diagnostic OS for systems without hardware KVM features. This is shown in Figure 2.

Figure 2: Reuse of local diagnostic utilities and tools
click image for larger view

Case 2: Download and Store Diagnostic OS Using a Two-stage Boot Process
If the system does not have a resident diagnostic OS, IT support personnel can remotely download or install one at runtime. IDE-R and SOL can be used to boot a small footprint OS, such as MS-DOS or a trimmed-down Linux* OS. Once the small foot-print OS is running, then a full-featured diagnostic OS can be downloaded to the user’s system. It can be installed on a Universal Serial Bus (USB) flash drive or the main HDD, if the drive and its file system are in a healthy state. The system can then be booted into the diagnostic OS for interactive diagnostics and repair. If the diagnostic OS runs in text mode, SOL is all that is needed to remotely control this OS. But, if it runs in graphical mode, a remote KVM (either hardware or software) capability is needed. This use case is shown in Figure 3.

Figure 3: Downloading diagnostic OS using Intel® vPro™ technology
click image for larger view

Case 3: Download and Store a Spare-Tire OS on Local Resources
When all remote diagnostics fail to repair the problem, IT support personnel can remotely download and install a spare-tire OS on the user’s system. A spare-tire OS is a locally resident OS that allows a user to regain basic functionality of the system on a temporary basis, until the system can be permanently repaired. A spare-tire OS can be a version of Windows* (such as Windows XP Embedded or WinPE* 2.0), or any other OS that can be downloaded and stored as a ready-to-run disk image–such as a file in International Standards Organization archival format (ISO). It can be installed on a USB flash drive or the main HDD if the OS is in a healthy state. From the spare-tire OS, the user can access data in the main partition of HDD, run essential office productivity applications, access the Internet, and so on.

In addition, for use cases 2 and 3, there are tools available to download large images in a robust manner—especially for unreliable network connections. This can simply be achieved by downloading the image in chunks and resuming downloads from the point where the connection was broken.

This procedure makes the system usable in a relatively short time and allows the user the option of delaying the repair until later. This can be particularly useful if the user is away from the office but needs a computer to access his/her data: the repair of the user’s system can be put off so it doesn’t interfere with the user’s productivity. The spare-tire OS download use case is shown in Figure 4.

Figure 4: Downloading spare-tire OS using redirected storage
click image for larger view

Sample Implementation of RSR
We have implemented use cases 2 and 3 in Figure 4 by using a two-stage solution based on a diagnostic OS. This method was chosen due to its small footprint, but also because it can use the IDE-R capabilities of Intel® vPro™ technology. The sample two-stage DOS-based RSR solution relies on the native BIOS USB stack for storage purposes. The overall flow of this two-stage solution is shown in Figure 5.

Figure 5: DOS-based, two-stage RSR solutions
click image for larger view

Software Disk Unlock Scenario—Solution
With RSR in place, we can create a solution for the software disk unlock scenario presented earlier. If a software-based disk encryption solution is used and it has to be unlocked for any reason, the remote console can boot the system to a remote CD image by using Fast-call for Help and IDE-R. Doing so allows an IT shop’s disk recovery solution code to be run from the remote location and present the authentication credentials to the verifying application. By using SOL/keyboard replication, the remote console can provide the master key or the escrowed key so that the disk can be unlocked and the system subsequently booted.

Back to Top