Intel® Active Management Technology Use Case #4: Remote Diagnosis, Remote Repair (Heal)

Intel® Active Management Technology (Intel® AMT) can help to reduce the support overhead associated with repairing platform boot failures. By enabling remote resolution of a greater proportion of such failures, costly, reactive repair processes can be avoided. Additionally, both the end-user and IT technicians save valuable time through the elimination of time-consuming diagnostic. In this use case an end-user platform will not complete a boot due to a missing or corrupt DLL. Intel AMT is used to facilitate remote diagnosis and repair of the end-user’s platform.

Conventional Limitations to Remote Diagnosis and Repair

In the typical scenario where an end-user's system will not boot, the user calls the help desk for assistance, and the help desk technician attempts to diagnose the problem. Because the system will not boot, however, support technicians are unable to address the problem down the wire, resulting in an on-site visit by a support technician to diagnose the problem.

In this conventional scenario, it’s often the case that one or more desk-side visits are required to repair the system, since the problem may be a failed piece of hardware that the technician did not bring along. This impacts user productivity and pulls IT resources off of other tasks.

Using Intel® AMT to Overcome Limitations

If the end-user's system supports Intel AMT, then, depending on the nature of the platform failure, an alert could be sent to a management console identifying a soon-to-fail hardware unit before the fail-to-boot problem occurs. If the system failed without warning and refuses to boot, then as above, the end-user could contact the help desk directly by phone. Using Intel AMT capabilities to redirect the platform to a known good boot image (using IDE Redirection or IDE-R) and interfacing to the platform remotely (with Serial-Over-LAN or SOL), the help desk technician can diagnose the problem and perform remote remediation (utilizing third-party management software) if hardware replacement is not necessary. Furthermore, the technician can perform these operations without the end-user being present and even if the end-user’s platform is powered off.

In this Intel AMT-enhanced scenario, no desk-side visits are required to repair the system.

Key Functionality Enabled by Intel AMT that Underlies this Use Case

The following table summarizes the features and functionality utilized in this use case that are provided by Intel AMT or enabled by Intel AMT in third-party software:

Feature	Functionality
Out-of band (OOB) access	Platform is diagnosed and repaired in a crashed state via OOB access to Intel AMT, SoL/IDE-R, and third-party diagnostics
Remote troubleshootin g and recovery	Third-party management application's diagnostics/recovery capabilities used remotely
Tamper-resistant agent	Accessible by the third-party management application to gain remote control, with little risk of agent tampering by a user

The Advantage of Intel AMT

Intel AMT enables support organizations to reduce or eliminate technician visits that would otherwise be required to resolve software-related problems on platforms where the operating system is not functioning. The remote, out-of-band solution reduces mean time to repair and end-user down time.

Business Value of the Intel AMT Solutions

This use case enables IT organizations to save on support and productivity costs:

Savings from Eliminating Desk-side Visits: Out-of-band, down-the-wire diagnosis and repair can reduce the need for desk-side visits, producing substantial cost savings.
Savings in End-user Productivity: By improving average time to repair, organizations can realize savings in terms of avoided end-user downtime.

Remote Diagnosis, Remote Repair Usage Case Implementation

A typical 'remote diagnosis, local repair' scenario may consist of using IDE-R (IDE Redirect) to boot a client with a corrupt operating system or hardware failure. The following actions would be taken:
A valid boot disk is loaded into the management console disk drive.
This drive is then passed as an argument when the management console opens the IDE-R TCP session.
Intel AMT registers the devices as a virtual IDE device on the client, regardless of its power or boot state.

Note: Both SOL and IDE-R may be used together, since the client BIOS may need to be configured to boot from the virtual IDE device.
The client is booted to the remote IDE device.
The diagnostics agent is loaded, and diagnostics are carried out on the client system.
If needed, a repair agent is uploaded.
The repair is performed.
The platform is restored to the normal boot device and status.

The following table shows the actions that would be taken in a SoL scenario.

Step	Action/Call	Description
1	IMR_Init	Intel® AMT Redirection library initialized (needs *.ini file) Management Console (MC) catalogs client (needs client list)
2	IMR_SOLOpenTCPSession	MC opens SOL Session w/Client
3	IMR_SOLSendText IMR_SOLReceiveText (and other API’s outside the Intel AMT Redirection Library)	Terminal session initiated between MC and client Client rebooted through Intel AMT web service Client redirects BIOS console to serial port/terminal session
4	IMR_SOLCloseSession	MC closes SOL session with client
5	IMR_Close	Intel AMT redirection library closed

The table below shows the functions available for SOL Handling:

Function	Description
IMR_SOLOpenTCPSession ()	Opens an SOL session with the specified client over a new TCP connection
IMR_SOLCloseSession()	Closes an open SOL session with the specified client
IMR_SOLSendText()	Sends text (keyboard input) to the client, where it will be received as incoming data from the serial controller
IMR_SOLReceiveText()	Data sent by the client on the serial controller is received by the library and stored in an internal buffer. This function retrieves SOL data that has been stored

The following table shows the actions that would be taken in an IDE-R scenario.

Step	Action	Description
1	IMR_Init	Intel® AMT Redirection library initialized (needs *.ini file) Management Console (MC) catalogs client (needs client list)
2	IMR_IDEROpenTCPSession	Establish Connection with client and IDE device on MC
3	These steps occur as if the MC IDE device is physically installed in the client. The steps are outside the scope of the Intel AMT Redirection Library.	Client rebooted through Intel AMT web service. Client boots to disk in MC drive MC diagnoses Client through Management Application
4	IMR_IDERCloseSession	MC closes connection with client and IDE device on MC
5	IMR_Close	Intel AMT redirection library closed

The table below shows the functions available for IDER Handling:

Function	Description
IMR_IDEROpenTCPSession()	Opens an IDER session with the specified client over a new TCP connection
IMR_IDERCloseSession()	Closes an open IDER session with the specified client
IMR_IDERClientFeatureSupported()	Queries the client about the special features that it supports. Currently the only special feature defined is an ability to disable/enable host IDE devices.
IMR_IDERGetDeviceState()	Queries the state of client IDE devices.
IMR_IDERSetDevice State()	Controls the client IDE device(s) state. Devices can be disabled and enabled through this function.
IMR_IDERGetSessionStatistics()	Polls the active IDER session

§ The following assumptions underlie the analysis in this use case:

The third-party remote management application supports Intel AMT
This is a software issues that can be repaired remotely (e.g., corrupt or missing DLLs)
All research was data gathered from global, US-based IT organizations
Platforms connected to a power source (Desktop mode) or are in S0 and connected to an AC or DC power source (Mobile mode), but the platform does not have to be powered on
Platforms are physically connected through a working Ethernet connection to the corporate LAN as in Desktop mode or wirelessly connected to the corporate network as in Mobile mode (and not over VPN) for OOB access
Assumes a mostly wired environment or one where laptops are often wired

RESOURCES: