A few previous articles highlighted some ideas on the usage of IDE-Redirection within Intel AMT. In case you missed them, take a look at the following:
IDE-Redirection allows the administrator to override the local BIOS boot order, and to present a different boot image. Instead of touching every system with a bootable disk or flash drive, take those bootable disks and put them to an ISO or IMG file for use with IDE-Redirection. Sounds like a great idea - until the image file is too large, or communication to the target system is on the far side of a network with high latency. Then suddenly - the idea of IDE-Redirection, and related experiences, may not be so compelling.
As one example of a bad idea in using IDE-Redirection - see the video I created over a year ago. In it, I show an IDE-Redirect session using a Microsoft Windows XP installation image. If unsure why this is a bad idea, keep reading...
The IDE-Redirection Protocol Stack
In discussing a Remote System Repair scenario, an online article briefly references the IDE-Redirection protocol and experiences with high latency networks. The article was original written for Fast Call to Help scenarios - basically, a new and advanced feature of Intel AMT (available on version 4 of the firmware, and expected to be supported in the Altiris version 7 release). The article is available here.
Take a moment and brief through the article, with a specific focus on information around the IDE-Redirection protocol stack. An interesting excerpt from that article in regards to IDE-Redirection on high latency network with no optimization is "To provide real world context, without optimization, transferring a copy of a 100MB ISO file would take approximately 95 minutes with limited success".
Some additional interesting tidbits mentioned in the article in relation to high-latency networks:
- Embedded management processor operates in a constrained memory environment. Network and socket buffers are impacted, as compared to a full blown operating system network stack.
- The IDE-Redirection application layer protocol is multiplexed with other session protocols. In short - it's not just the file transfer, yet also the maintaining of the redirection session, etc. Again, this is happening within a constrained memory environment in the chipset.
- If using TLS to secure the session, this is yet another layer of encapsulation and multiplexing within the overall protocol stack.
- Although not specifically mentioned in the article, each session is unicast. Therefore, if you start up several IDE-Redirection sessions (i.e. for a client reimaging process), the server will need to handle each connection separately.
The article goes on to state some insights about normal network traffic, the interaction and protocol of the harddrive interface (remember, IDE-Redirection is effectively presenting a remote image as local to the target client), and so forth.
High Level Guidelines in Building a Bootable Image
As classically stated with any project - K.I.S.S. - keep it simple. (since there are various interpretations on the second "s", I'll leave that off).
Small and compact boot images are usually the best ones. Something to get the remote client "on the network", install a small bootstrap on the target device, and so forth. Generally speaking, a number of boot utilities can be quickly converted to IDE-Redirection boot images. A few examples:
- Ghost boot disk for reimaging
- DOS or Linux based utility disk
- GRuB based boot selection
- Compact BartPE or WinPE boot image
The first three examples are often accomplished in less than 20MB image files. The smaller the better. Plus, most of these ideas are VT100/ANSI compliant, meaning that a Serial-Over-LAN (SoL) session will allow you to view the remote console.
In the case of the Ghost reimaging, it would be best if the target Ghost image file were close to the client. In one production test, the image file was copied across a WAN with over 10 hops between the image file source and the target client. In essence, a high latency situation which led to a prolonged client reimaging session.
The forth example, using a WinPE boot image, can be accomplished in a low latency environment. Generally speaking, the WinPE boot image is between 90MB-150MB depending on how it is configured. Therefore, for a high-latency environment, this may not be the best idea.
In the end, even if the IDE-Redirection session is a little slow, it's likely faster than physically visiting the client system.
Conclusion
The IDE-Redirection capability with Intel® AMT is a handy utility for remotely accessing a system with a defined boot image. Since the session is maintained with a very limited set of the overall client system resources, and the session protocol is multiplexed in handling various items, the administrator may have a poor experience in high-latency or large boot image file situations. For these and others reasons, it may be best to keep the boot image files small. In some cases, customers use the IDE-Redirection session with what they call a "bootstrap" image to initiate the process of remotely remediating a client system.
Do you have a great idea or experience to share in using IDE-Redirection? Please chime in.
The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries.