My name is Brad Lund; I work in the Enterprise End User Integration Lab (EIL) as a Senior Systems Engineer. This article is the first in a series of blogs I plan to deliver describing how, with the aid of some very useful tools, we can use IDE Redirection (IDE-R) and Serial over LAN (SOL) to provide the console operator with a more user friendly approach to remotely diagnosing and repairing client systems.
SOL is a great technology that has been around for a number of years. It is generally used in data centers for taking control of a computer in order to make changes to its BIOS. Since output from BIOS is by nature "pure text", SOL, whose interface is based on VT-100 terminal emulation, works fine. But what if the problem requires the console operator to interact with the client in a manner that dictates a graphic interface be present to load and run diagnostic applications?
Since the Enterprise Integration Lab are End User focused, we have had several customers ask us how they could leverage this Usage Scenario to take control of an AMT client while providing the operator with a more intuitive and useful interface. Additionally, every one of the End Users we interact with has a set of tools they use to perform diagnostics and repair. But if the client system is out-of-band, meaning no O/S present, it is NOT a BIOS related issue and the diagnostic tools require the operator to have a graphic view of the client system, how can we deliver on this request?
This series of blogs will attempt to show various ways to address these questions and more. I will start this blog series with the client residing inside the Enterprise using AMT to contact the console operator and utilizing very basic tools - take control. Upcoming blogs will show how to do this for clients residing outside the Enterprise (in the internet cloud) using Client Initiated Remote Access (CIRA) to contact the console via of a Management Presence Server in the DMZ and more robust tools - very cool!
So let's get on with it shall we?
The Tool Set
For this first installment I am using AMT Commander from the AMT DTK to initiate a client connection and perform console redirection (IDE-R). The client platform is Montevina (AMT v4.0). I will also push a Pre-installation Environment (PE) down the wire to boot the client into a graphic environment; either WinPE 2.0 or BartPE can be used. Whichever the choice, the greatest thing about a PE is its ability to be customized. You can build a PE to include not only the necessary drivers to bring a system up, but also all the required software for a technician to truly diagnose and practically correct any problem. A full explanation of PE's is beyond the scope of this blog but easily searchable via your favorite search engine. Lastly, to complete the process I will use UltraVNC, a publicly available application that gives the console operator the ability to view the remote client screen; graphically!The Scenario
In this setting we have a client system where the O/S fails to boot-up (see Figure 1 - left image). This could happen if the client did something to their system which caused the registry to become unreadable by the O/S. Or perhaps the owner of the system accidentally deleted a critical file(s) required by the O/S to boot properly. In any case, the client calls their support center and is walked thru the required steps to perform BIOS initiated AMT. Once initiated, the console operator can then connect to the client; Figure 1 - right image.
Figure 1: Remote client screen on left - Console operator screen on right
After connecting to the client, the console operator opens the SOL/IDE-R mapping interface and assigns the appropriate .iso images for Floppy and CD-R redirection (see Figure 2 - left image). Note: You must assign both a Floppy and a CD image for SOL/IDE-R to operate properly. Also, while you can use IDE devices physically attached to the console system, working with .iso images are faster and more flexible.
Figure 2: Point device mapping to .iso images, start SOL/IDE-R, take control of client system.
The next step after starting redirection is to take control of the remote client as shown in Figure 2 - right image and indicate which image to boot from. In this case since we have our PE stored as a CD-R .iso image we tell it to "Remote Reboot to Redirected CD" Figure 3.
Figure 3: Remote reboot to CD-R image
At this point the client system has started a reboot and loading the PE image from the console. However, because we are using SOL the console operator can only see the "text" generated information. Notice the screen in the foreground of Figure 3 titled "PuTTY", this is the SOL interface and portrays only the "please wait" line from the boot loader; not very intuitive or useful. As a result the console operator will have to ask the client to inform them when the PE has finished loading on their system (see Figure 4).
Figure 4: Client system completed boot to PE and ready for remote control
Here is where the fun begins. After the PE loads onto the client system, the console operator starts UltraVNC; pointing it to the client, Figure 5 - left image. Part of the PE build includes the necessary network drivers to give this system an IP stack so it can be accessed via UltraVNC Once UltraVNC connects it opens a graphic window where we can actually see and control the client as though we are sitting at their machine, Figure 5 - right image. Again, we are using the SOL interface to show us text information and the TCP/IP protocol to allow UltraVNC to connect an OOB client - pretty cool huh?
Figure 5: UltraVNC to display client screen on console operator system
From here we can invoke a whole series of commands and view the results in real-time. In the example shown in Figure 5 - right image, I am running regedit - OK I realize it is showing the PE registry but with the right tools we can load and analyze the client registry or any other application and/or device.
Remember I said the beauty of PE's lie in their ability to be customized? If your shop use specific diagnostic tools you can include them into the PE at build time and use them here by simply clicking on the orange "GO" button (different PE's have different ways to access applications).
What I have shown here is the ability to use some very rudimentary protocols along with widely available tools to perform very powerful diagnostic and repair functions on a broken client. Keep in mind however this is only one of many ways to achieve this capability. In fact, this particular example can take a fair amount of time to load depending on network traffic and size of .iso image. But it is much better than the down time required to bring the remote system into the support center.
EIL are constantly finding solutions to answer the hard questions for our End Users. In upcoming blogs I plan to show similar capabilities using different techniques to minimize load times while maximizing efficiency. I hope you found this blog useful if you have any questions please feel free to ask. See you soon...
