With Intel® AMT offering remote power on, serial-over-LAN, and IDE-Redirection -- do we still need Pre-Execution (PXE) boot built into Altiris Deployment suite with Altiris PXE server? What about Wake-on-LAN? Those are loaded question with loaded answers. I'll state my view -- and am open to thoughts from the community.
In addition to talking a little about PXE boot and Wake-on-LAN in respect to Intel® AMT environments, this article will also provide a brief demonstration of the power management and redirection capabilities.
PXE boot or Intel® AMT redirection?
The following provides a few viewpoints and considerations:
- If you are using Altiris Deployment server with PXE boot today, and it is working fine -- keep using it.
- PXE boot allows for scripted install. In essence this could be accomplished via Intel® AMT inside an ISO image.
- PXE and the features of Intel® AMT are tools to be integrated and utilized within an Altiris (or other) environment.
- PXE will still be needed for systems not supporting Intel® AMT -- including workstations, servers, and so forth.
- Intel® AMT is TCP\IP based and can use Transport Layer Security (TLS) for data and session encryption.
- More information on Altiris PXE server available here: http://apl-ibase.altiris.com/resources/dell/wp/Intro_to_PXE_and_PXE_Server.pdf
By basic nature -- PXE boot is not reliable, routable, nor secure. UDP, snooping DHCP traffic, IP helpers at the routers, and other items are few reasons why. To compensate, in an Altiris environment, the PXE server must have an assigned job for the target system. UDP acknowledgements are sent, thus emulating TCP based traffic. In essence, the weaknesses of the PXE boot process appears to be minimized and the functionality enhanced by the management and deployment platform of Altiris
PXE boot requires DHCP options 43, 54, and 60 to define key variables and options snooped via the DHCP lease sequence and to configure the client. In addition, communications on network ports 67, 68, 1758, 1759, and 4011. A PXE boot menu can be sent to the client, allowing for the administrator to select a list of options. Once a menu item is selected, the .0 file is located and subsequently the list of files and images is downloaded into the local client's memory. This is followed by execution from memory of the pre-boot OS -- such as WinPE and so forth. By some recommendations, the local physical memory should be double the size of the image being downloaded to allow the data to be loaded and the pre-boot OS to be initiated.
Intel® AMT is built upon a reliable, routable, and secure foundation. TCP is the transportation protocol, allowing for resends and validation of packet receipt. Communications will be on ports 16992 through 16995, depending on non-TLS or TLS mode, use of Serial-over-LAN, and so forth. (Sending unencrypted packets for serial-over-LAN or IDE-Redirection does pose security potential risks, therefore support and implementation of TLS may be preferred.) In essence, less network ports need to be open and IP helpers are not needed for network infrastructures which route TCP\IP traffic. By using TLS, the session can be secured and encrypted, provided for session and data integrity.
For the image being downloaded, the WinPE pre-boot could be packaged inside an ISO image. The ISO image is streamed across the network via IDE-Redirection, thus a consideration of network bandwidth, number of hops from the source location, and so forth. The ISO image file could also be a small packaged menu system which then requests the WinPE or other files from a drive local to the client system (e.g. local optical drive).
Although a stronger tool individually, the Intel® AMT functionalities and capabilities are still being integrated into the Altiris management and deployment environment. The functionality exists today to view the session via Serial-over-LAN and may be best used for relatively simple ISO images of utility disks. Future enhancements might include distribution point management -- as in, defining an IDE-R session and setup once and using variables or switches as to where the file is being pulled from, based on available bandwidth and so forth. The key for now is to use what is available and to provide feedback to the product teams on how the tool could be better integrated into the management platform. (hint, hint)
Wake-on-LAN or Intel® AMT remote boot?
Wake-on-LAN (WoL) is commonly used to boot a system that appears to be off, yet has a power source and network connection. Most modern systems have PCI 2.2 compliant network adapters which use a small amount of power to receive broadcast messages from the network and to activate the power switch of the system. The "magic packet" for WoL is a UDP broadcast message to a particular subnet and containing the MAC address of the target computer.
Supporting broadcasts on specific subnets often requires configuration of the infrastructure routing port for that subnet. In addition, UDP traffic is not reliable thus the only way to know if the "magic packet" was successful is for the host OS to load and start it's TCP\IP stack. What if a power off or restart sequence is needed, and WMI is not available to initiate? Imagine a system that is technically on, yet the host operating system has failed. (Some might say this "never" happens... seriously).
By default, the Intel® AMT management BIOS extensions (MEBx) is on if power is applied to the system, regardless of the host system power state. With a network connection (same physical port as the host system), the MEBx has it's own TCP\IP networking stack and is thus able to communicate reliably on the network. Thus when a power operation from the management console is issued, it is sent via TCP\IP directly to the target system. Once received, the MEBx communicates to the host system and powers it. In addition to being able to "wake" the system, the MEBx can also report on what power state the system is in. (Not familiar with the different system power states? Take a look at http://softwareblogs.intel.com/2007/01/10/all-about-system-power-states-s0-s5/) Even more interesting, the MEBx can power off the host system (move to S5).
Let's take this one step further. What if we could check and record the power state, move the system to power-on (S0, also referred to as H0 -- for host on), this loads the OS, Altiris Deployment server sends down an update package, then via WMI the Microsoft Windows operating systems is gracefully shutdown, and so forth. Did a big light turn on? Yep -- that's what the power of Intel® AMT combined with Altiris Client Management Suite can do.
What if the power consumption of the MEBx is too much (Intel® AMT systems may consume 5-9W of power when the host if off), and a particular environment wants the MEBx to "go to sleep". Remember the power policy settings within the Intel® AMT profile? The MEBx could enter a sleep state when the host system is asleep or off. Per the image below, the Standby (S3) or Hibernate (S4) sleep states could trigger the MEBx to enter a sleep state after a defined interval (covered up in the screen shot below). In this case, Hibernate refers to host system off, whether or not the Windows Hibernate function was used.
If the MEBx is in a sleep state, how might we wake it up for management and security operations -- like to remotely power up the system? I will have the exact answer shortly. (Update - see posting at http://www.symantec.com/connect/tech-tip/2202/waking-up-intel-management-engine)
Possibilities of Intel® AMT Redirection
Before concluding this article, a little more exploration into how the Intel® AMT redirection and power management features are integrated into the Altiris environment. The following screen shots and explanations should turn on a few more lights (conceptually and in reality), yet also allow us to turn off some physical systems if needed.
For those new to the interface and capabilities of Intel® AMT redirection, below is a screen shot of the Hardware Management interface. This is accessed via the Real-Time Systems Management for a particular system. The main two sections of focus are the Remote Power Management and Redirection Options.
The Reboot, Power off, and Power-on options are similar to a physical switch on the system. If you were to select "Power off" followed by "Run Task Now", the target system would shut-off immediately. When a healthy Microsoft Windows environment is running on the host system and WMI is possible, a fourth option appears under "Power on" labeled -- "Graceful power action". For reboot and power-off, this option uses WMI to initiate a Microsoft Windows shutdown sequence before Intel® AMT executes a power management operation.
In the above image, the Redirection option of displaying the task and performing a boot from a CD image is selected. Other source locations are available in the pull down box. CD image refers to ISO image, with the path defined above. Below is the result of this action. Although a relatively simple DOS boot disk, the possibilities should be enlightening. Not only has the target system booted from a defined ISO image, yet the administrator is able to via the remote console. In fact, the administrator can view the entire POST boot process up until the GUI loads. Plus, the administrator can send keyboard commands as demonstrated below -- a relatively simple DIR command yet sometimes the simple items open the minds of possibilities out there.
If you have not already fallen off your seat, may I give you a little nudge? With Intel® AMT redirection, the administrator is able to remotely access (view, change, etc) the target system BIOS setup utility. The screen shot below is a Lenovo T61 (Intel® Centrino® Pro) BIOS setup utility accessed via the Altiris console remotely. Now I have to admit -- in my own experiences of IT operations and support, I rarely needed to access the BIOS setup utility. However, there a few occasional moments when it was needed. This is a key example of ensuring appropriate access control within the Intel® AMT profile. Imagine if any support technician could remotely boot, redirection, access BIOS setup screens, and so forth. Technologically with Intel® AMT, this is possible -- as well as restricting the level of access to perform certain functions.
Conclusion
Intel® AMT extends the manageability reach of the Altiris console, allowing for access below the operating system while using reliable and routable protocols. Does this necessarily mean that Pre-eXecution boot and Wake-on-LAN are history now? Not necessarily. Servers and workstations which do not currently support Intel® AMT may still require these technologies. Does this mean the Altiris PXE server is history? No. Does this mean Intel® AMT is the best solution? That all depends on how well Altiris integrates the functionalities and capabilities of the "tools" provided by Intel® AMT.
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