Intel vPro Expert Center Blog

9 Posts tagged with the sol tag
Click to view dbrunton's profile
2

Did you know that vPro has the capability to give you remote GUI access out-of-band (OOB) using the serial-over-LAN (SoL) interface? It's true.

Normally we think of SoL as a solution for remotely accessing BIOS or as a tool for running text based remote diagnostic utilities as part of an IDE redirection (IDR-R) session. SoL is capable of doing more than console redirection. If you look in the device manager on a vPro client and expand the Ports (COM & LPT) you will see an entry for the SoL interface:


http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/1903/com+ports.jpg

This port allows the local operating system to interact with AMT's out-of-band connection to a management console. You can try this yourself with the following steps:

  1. Open up a SoL session to your vPro client using your management console. (you can use the Manageability DTK if you do not currently have access to a management console)
  2. Open up a command prompt on the vPro client you are connected to via SoL.
  3. Enter the following command:
    1. echo hello>com3
    2. Note: the actual COM port number for your SoL interface may be different, check device manager to see what it is.
  4. Look at your SoL session on your management console. You should see the word "hello" appear in your console window.

So what does this all mean? It means that if you have some software monitoring the SoL port that you can send and receive data to your OS OOB.

A great example of how to leverage the SoL interface can be found in the Manageability DTK. The DTK gives you the ability to redirect TCP traffic over the SoL interface by utilizing an agent, the Manageability Outpost, on the vPro client. There is corresponding functionality available in the Manageability Commander tool and Manageability Director tools. This allows you to map a TCP port on your vPro client back to a TCP port on your management console and tunnel TCP traffic between your management console and vPro clients over the SoL connection.

If you combine TCP redirection with remote control software, like Remote Desktop, VNC and similar tools, you can enable OOB access to a full GUI on a remote machine.

I've put together a video that demonstrates how you can use this ability to remotely manage a client with a full GUI, including the ability to transfer files, using vPro's OOB management capabilities.


2 Comments Permalink Tags: amt, sol, ider, commander, video, outpost, vpro, remote_repair
Click to view Flowy's profile
0

OS Repair using SOL and IDE-R

Posted by Flowy Sep 18, 2008

The SOL IDE-R for OS repair document was just updated and can be used to create a boot floppy or boot ISO that will allow for image redirection using SOL and IDE-R.

The SOL IDE-R for OS repair document has instructions on different methods of creating the boot floppy, where to get the setup files, and how you could use it for imaging. This document was meant for IT administrators who have knowledge on imaging, and batch file creation. The document is a framework on how to create it and should not be attempted by technicians who do not have some batch file programming or OS deployment background. There are provided samples in the document with instructions on how to create the bootable files, to add network drivers, and to image and when to use 1 for 1 imaging versus a sysprep image.

For more information, review the SOL IDE-R for OS Repair Resource Page.

0 Comments Permalink Tags: os_repair, florence_lo, bootable, flowy, flowy_lo, vpro, sol, ide-r, case_study
Click to view blund's profile
1

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.

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/38-11385-1654/Figure1.JPG
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.

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/38-11385-1659/Figure2.jpg
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.


Figure3.jpg
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).

Figure4.jpg
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?

http://communities.intel.com/openport/servlet/JiveServlet/downloadImage/38-11385-1662/Figure5.jpg
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...

1 Comments Permalink Tags: vpro, cira, brad_lund, eil, epi, winpe, bartpe, sol, ider, tools, utilities, system_maintenance
Click to view Ylian Saint-Hilaire's profile
0

I often get questions about the Intel AMT serial port. Ever since the DTK started to make heavy use of it, serial-over-LAN has gotten a lot of attention. First, how do you change the COM port number of the Intel AMT serial port? The COM number (COM3: for example) is assigned by the operating system, so you don’t see that is any AMT/BIOS/MEBx option. You have to go into Microsoft Windows Device Manager, go to the properties of the “Intel(R) Active Management Technology – SOL” port. Then go into the “Port Settings” tab and press the advanced button. There, you can change the COM port.

Also, it’s often useful for application to be able to automatically detect the AMT serial port. In Intel AMT Outpost, I scan the device drivers looking for the “Intel(R) Active Management Technology – SOL” device and read the COM port number that follows in that string. Sofar, it seems to work great, even in non-English countries, something I am always worried about.

The Intel AMT serial port is much like any other serial port, but it has a PCI device identifier that is not normally known to Microsoft Windows and so, Windows does not know what to do with this device. On Intel’s web site, there is an SOL driver available. The serial driver itself is just a small .INF that tells Microsoft Windows to load and use the standard serial driver. In fact, one can manually force the standard Windows serial driver to be used for this device. You need to go in the device manager and pick a driver from the list, select Microsoft as the manufacturer and you will see it. Even if it’s possible, I don’t recommend it because the DTK code will no longer recognize that COM port as being the AMT port, it’s going to work but will have the wrong name for auto-detection.

Lastly, if someone needed to know if a computer is AMT enabled without having to load any drivers, one way to do it would be to detect the presence of the Intel AMT serial port. It is always present even when AMT is un-provisioned, and it can’t be turned off, unless AMT is disabled entirely in MEBx. This can be a good way to figure out if you need to start considering a computer for AMT setup.

Ylian
(Intel AMT Blog)

0 Comments Permalink Tags: intel, amt, dtk, ylian, serial, sol
Click to view michelegartner's profile
0

Here are some new updates for the Known Issues, Best Practices, and Workarounds wiki:

*Updated results for the USB key provisioning matrix

*BIOS password screen unavailable on HP systems during SOL session

0 Comments Permalink Tags: troubleshoot, vpro, usb, sol
Click to view Ylian Saint-Hilaire's profile
0


Years before I started working on Intel AMT, designers where creating a list of usages that would be enabled by Intel AMT. The list included, I presume, usages around 3PDS, remote reboot to BIOS, disk redirection, etc. Many of the Intel AMT usages that are promoted on the Intel web site. When I started work on the DTK, a personal challenge had always been to find new ways of using existing features to do different and sometimes unexpected things. Create new usages for Intel AMT that it was never originally designed to do. I now present my top 5 abuses of existing features.

TCP-over-Serial-over-LAN. The Intel AMT serial port I am told, was originally designed as an easy way to remotely take control of the BIOS and recovery OS remotely. Designers needed a way for BIOS to be able to send test display data to a remote console. A virtual serial port was a great solution. It so happens that in the original design, this serial port was always enabled and usable, even when the normal OS was running. This allows a serial agent to talk to a console while bypassing the OS’s network stack. This is interesting on its own and I started work on a serial agent of my own. Things took a weird twist when I started sending binary data and sending files over this serial port, making it very valuable. It’s only a few weeks later that I realized I could also send TCP traffic over this serial link, making it possible to contact TCP services on the Intel AMT computer even if the network stack was disabled. A few days later, I showcased the first demonstration of VNC-over-SOL, and turning this abuse of the serial port into an instant hit. To this day, VNC-over-SOL is still, one of the most impressive demonstrations of Intel AMT.

Reverse Watchdog. When Intel sales people demonstrate Intel AMT to customers, they often get asked if you can shutdown gracefully an Intel AMT computer using Intel AMT. The simple answer was no, Intel AMT will perform a brutal shutdown or reset upon request. To perform operations like a clean shutdown or reset, sleep or hibernation requires the involvement of the OS. You could tell a serial agent like Intel AMT Outpost to perform the shutdown, but that required opening the serial connection and could be a problem if you had to shutdown many computers. I needed a way to pass a small amount of information to a running Intel AMT agent on the PC, do it using SOAP/WSMAN only and if possible get confirmation of reception. We could store the command into 3PDS and have the agent read it periodically, but 3PDS required setup and that little amount of data would have required allocation of a 4K flash page. The solution came when looking at the agent presence feature. When a console creates a new agent, the agent can now register this agent locally. The agent also get the timeout of the agent in seconds (from 1 to 65535), this would be the key. By constantly trying to register a known GUID, Intel AMT Outpost could see if the agent existed or not. If suddenly the registration works, the timeout value would indicate that type of shutdown operation to perform. Better yet, the simple fact that registration occurred changes the state of the agent to “Running”, confirming to the console that the message was indeed received. Today the Intel AMT Terminal has “Agent Commands” in the remote control that allows a user to perform soft operations when the agent is running, even if the OS network stack is not working.

Mouse over serial. A few months back I started work on a smaller version of Intel AMT Outpost called Intel AMT Guardpost. The idea was that if a serial agent was going to be useful, it was going to need to run on a recovery OS, run in the background with no dependencies and with as little footprint as possible (Is it not annoying to have all there background processes running?). The C/C++ version of Intel AMT Outpost was on its way. One feature I always wanted to work on was a remote Windows command prompt; it took over a week to finally pull this off. I could now remotely shell to DOS and perform basic command line operations. I could also enter the command like editor with the “Edit” command at which point, the temptation to support the mouse-over-serial-over-LAN was a must have. Using the binary serial protocol, I added the support to the terminal in a few hours. To this day, it’s still a fun and amazing demonstration of outstanding remote manageability.

IDE-R within the OS. A few days after first enabling IDE-R within Intel AMT Commander, I stumbled upon something I had not noticed before. If an administrator where to start IDE redirection and the OS was to re-scan its plug & play devices, the additional floppy and CDROM drive would show up in Microsoft Windows. This was immediately interesting since transferring files over the serial port was limited to 115kb/sec a very slow speed in today’s world. With IDE-R, you can copy files at around CDROM 4x speed on a local network. All I needed was a way for Intel AMT Outpost to cause the OS to rescan its plug & play devices. A few hours later the “HWRESCAN” command was built and for the first time, an administrator could mount a CDROM remotely and install a patch as high speed without ever using the OS’s network stack. This feature also turned out to be an excellent compliment to VNC-over-SOL.

Fast data path using IDE-R. This is not an idea I never built into the DTK, but I wanted to add it to this list since it would also be an interesting was to use existing features in new ways. The serial-over-LAN feature turned out to be extremely valuable, but it is also slow. Serial ports are very inefficient. One way someone could speed things up is to use IDE-R as a fast by-pass to the OS. An administrator would mount a virtual floppy disk drive containing a single file. This file, would not really exist, it would contain different data each time it was read, making it possible to send data to an OS agent thru Intel AMT at much higher speeds. Also, since the floppy is a read/write device, the agent could write into the virtual file data that it wants to send to the console. It would be quite a bit of work to pull this off, but it certainly seems possible. Someone would just have to know the internal format of an .img file.

That’s my top 5. I realize this is probably a rather advanced blog article, but this is proof that you can have a lot of fun to any technologies.


Ylian (Intel AMT Blog)

0 Comments 8 References Permalink Tags: intel, amt, dtk, commander, outpost, director, guardport, serial, ider, sol
Click to view miroyer's profile
0

Although Danbury is the ultimate solution for Disk Encryption and Remote Manageability, the following whitepaper provides a reference design for using Intel® vPro™ Technology and Serial Over LAN (SOL) as a means to perform remote disk drive unlock on client boot up.


Whitepaper: Intel® vProTM Technology Enables Remote Manageability of PCs Employing Encrypted Disk Technology

Matt Royer

0 Comments 0 References Permalink Tags: vpro, amt, sol, disk_encryption
Click to view Ylian Saint-Hilaire's profile
0

Serial-over-LAN is quite useful for taking control of a computer, making changes to the BIOS and when Intel AMT Outpost or Guardpost is running, getting a management command prompt even when the OS network driver is disabled. What if you have to repeat the BIOS change on 100’s of computers? Say you want to change a BIOS boot option on 100 computers? Or want to test the reliability of a new computer platform? The Intel AMT Serial-over-LAN scripting can help.

Connect using Intel AMT Commander to the Intel AMT computer and select “Take Control” to enter the VT100 terminal. Make sure everything works well and you can connect and perform Serial-over-LAN correctly. Go in the “Terminal” menu and select “Script editor…” and write a script like this one, using the user interface to guide you:

LABEL “start”
RESET bios
WAIT 40 seconds.
RESET powerdown
WAIT 15 seconds
JUMP “start”
You can save the script, and run it. You can also write more complicated scripts to change BIOS options and do more interesting things. There is a command:
WAITFOR “abcd”
This command will wait until the string “abcd” is anywhere on the VT100 screen. This is very useful to wait for the computer to finish booting and to do something after. You can also send string to SOL:
SEND “dir\r”
To send the “dir” command. Terminal scripting is very powerful. It’s also a great way to impress your friends and customers. In a few minutes, you can write a script that will power on a computer; navigate throughout the BIOS screens and shutdown the computer when done. Once you run it, it’s like a ghost is taking control of your computer and going into the BIOS, very cool.

Ylian (Intel AMT Blog)

0 Comments 0 References Permalink Tags: intel, amt, dtk, commander, sol, serial-over-lan, scripting
Click to view Ylian Saint-Hilaire's profile
4

One of the tasks every BIOS vendors has to do when building a BIOS that sits on top of a Intel AMT enabled computer is to convert the text-mode display into a series of VT100 codes that are sent into the Intel AMT serial-over-LAN port to a terminal console. As I noticed when building IAmtTerm.exe , BIOS vendors do this very differently and sometimes very inefficiently.

The BIOS is in a position to capture displayed text when it's on the screen, something that the management engine (ME) on which Intel AMT runs can't do. Simply put, display and keyboard information does not flow thru Intel AMT. In order to provide text display and keyboard input remotely, Intel AMT provides the pipe (the virtual serial port) but needs the BIOS to do the rest. BIOS vendors where left to build code that would convert incoming VT100 codes into user key strokes and display changes into VT100 codes. As a result, how this operation is performed varies greatly from vendors to vendors, even for different BIOS from the same manufacturer (mobile vs. desktop).

The first difference is the handling of keys such as F1 to F10, there are no less than 3 different ways BIOS perform this conversion and so, IAmtTerm.exe provides 3 different mappings. Users have to change the key mapping manually and try them out. Secondly, some BIOS vendors tested against different VT100 terminals, notably terminals with only 24 lines instead of 25 lines. A real display and IAmtTerm.exe both have 25 lines, but many terminals have 24 since it was the convention during the modem days of the 80's to use the bottom text line as terminal status line. Some BIOS will try various tricks to display only 24 lines, hiding the top line, etc. Users that use IAmtTerm's "Terminal Analyzer" will also notice that different BIOS vendors convert text to VT100 differently. Some BIOS will send a full line whenever anything on that line has changed. Sometimes the codes for moving the cursor will be sent when the terminal cursor is already at that exact position on the screen. In one case, I even saw all of the display attributes (foreground and background color) be sent before each character on the screen, slowing down the display significantly.

In the latest versions of the Intel AMT Developer Tool Kit (DTK), I added Intel AMT Guardport, a light-weight C/C++ based serial agent. This new agent allows the user to shell to a command prompt and for the first time, Guardport also includes most of the same VT100 conversion that BIOS perform. When building Guardport, we took care to support all 3 F1 to F10 key mappings, and optimize VT100 display conversion to provide the best possible display speed. As a bonus, we also added proprietary mouse support, so you can enter a mouse enabled text application such as "Edit" and move the mouse over the application.

Ylian (Intel AMT Blog)

4 Comments Permalink Tags: intel, amt, sol, serial, vt100