While the sample space is small, it is clear any communications we have with our community must still consider all versions of Intel® AMT.

For those of you who voted, thanks for taking the time to give us a little insight.

The new SDK will have more details and some sample scripts to illustrate how to utilize the WMI provider.  But here's one example using the built-in WMI command line tool (wmic) that should be present by default on Windows 7, Windows Vista, or Windows XP.

wmic /namespace:\\root\Intel_ME path ME_System get FWVersion

On any system that has the appropriate driver and software package for vPro installed, that will return the firmware version of the system, even if the system hasn't been provisioned yet.  This can be useful for discovering unprovisioned systems in your environment, as well as the firmware details to check whether there is a new firmware version available from your OEM.

Along with the launch of the new vPro comes the long awaited 6.0 version of Active Management Technology (AMT). And unlike previous versions of AMT this version applies to both mobile and desktop platforms. 

We have many things planned for developers over the next few weeks to help you prepare for creating solutions based on this release. So be on the lookout for blog posts, announcements, events and new content in our Manageability Developer Community.

I'll try to keep this post updated with info as it comes out:

• WMI Provider
• Find a system

Let’s jump into code:

                if (bSupportWSMan)

                {

                    WsManDirectClient client = SetUpWsMan(ip, port, credential);

                    AMT_RedirectionServiceType rs = (AMT_RedirectionServiceType)client.Get(typeof(AMT_RedirectionServiceType));

                    if (rs == null) return;

                    rs.ListenerEnabled = true;

                    client.Put(rs);

                }

                else

                {

                    RedirectionService redSvc = SetUpEoi(ip, port, credential);

                    redSvc.SetRedirectionListenerState(true);

                }

The code shown above is simple, it supposes there is a way to know if WSMan is supported or not. If WSMan is supported, then the Listener Enabled property is set to true and the standard Put is called. If WSMan is not supported, then the web service object named RedirectionService is used by calling to the SetRedirectionListenerState with true. In both cases, the credential configuration is required, but, in the interest of simplicity, the function definition is not shown.

If you want to get more information about the standard WS-Tansfer Get, Put, Create and other operations, please read this good introduction: http://msdn.microsoft.com/en-us/library/aa384470(VS.85).aspx .

This is an important step to be performed after device provisioning, as I mentioned here (step 8), after a SCS enterprise provisioning this parameter is disabled by default, so it must be verified and/or enabled by your application.

There are two modes for the IP address setting of Intel AMT: static IP and dynamic IP. In the dynamic IP mode, i.e. automatic allocation of DHCP, Intel AMT shares the same IP address with the local OS when the latter is booted. Generally, you can find the Intel AMT’s IP by directly querying that of the OS. What about static IP then? For versions before Intel AMT 4.0, it is impossible to directly obtain and IP address configured for AMT on the local OS. You generally need to match the IP address of both the OS and AMT by the means of “network scanning + UUID match”.  Since the release of Intel AMT 4.0, Intel has added new interfaces for drivers to access the local ME (Management Engine). You can directly obtain network configuration information such as the static or dynamic IP of Intel AMT, the current IP address and MAC address, etc.

When Intel LMS driver is installed, a program named “Intel® Management and Security Status” will be installed and automatically open upon system start-up to report the status of Intel AMT. “Intel® Management and Security Status” will initiate “Fast Call for Help” connection and check the IP address configuration of local Intel AMT as shown in Figure 1.

Figure 1

Since the latest version of Intel AMT SDK does not provide an example on how to obtain the aforesaid IP address configuration information from local the machine, I spent some time studying the interface and found a way to obtain the Intel AMT IP address configuration information from the local machine. If you are interested, you can download the source code from here for reference: Sample Code Download. You should input a parameter representing the interface ID (0 for wired interface and 1 for wireless interface) during operation. The test results on Intel AMT 4.0 machine are shown in Figure 2.

Figure 2

The example mentioned above also works normally on an Intel AMT 5.0 machine.

Intel AMT 2.5 and 4.0 introduce the support to wireless management; that is to say, remote management is available via wireless interface. While the version 2.5 only supports wireless management in the S0 power state, IAMT 4.0 has extended the feature to the off and sleep state (i.e. Sx state). iAMT wireless management feature is disabled by default, which can be seen on the “Wireless Setting” menu item of WebUI as shown in the following figure. 

Some developers might encounter such a problem with Wireless configuration, including wireless capabilities (i.e. “Band mode capabilities” shown in the figure above), being added and deleted via the functions in the “Wireless Configuration Interface” of iAMT, however, such a function to enable wireless management cannot be found. Where is the function? How is the function invoked? In fact, this function is related to network interfaces, and iAMT provides a relevant function—SetNetworkInterface in the “Network Administration Interface”. The function has been called in the sample of SDK NetworkAdminstration, which can be used as a reference. “InterfaceHandle = 0” represents wired interface and “InterfaceHandle = 1” represents wireless interface; LinkPolicy in the parameter "InterfaceDescriptor" determines the circumstances where the iAMT wireless feature is enabled. The structure of LinkPolicy is: typedef enum<uint8> _LinkPolicyType { AVAILABLE_ON_AC_S0 = 0x01, AVAILABLE_ON_AC_SX = 0x0E, AVAILABLE_ON_DC_S0 = 0x10, AVAILABLE_ON_DC_SX = 0xE0 } LinkPolicyType. You can refer to SDK files for explanation of each parameter. Apparently, the parameter LinkPolicy should be the superposition of the values enumerated above. At first, I made a random superposition, 0x1E for example, and tried to call it with the program, but it turned out to be PT_STATUS_INVALID_PARAMETER error due to wrong parameter. I thought about it carefully and took the three options in the WebUI above (see the figure above) into consideration. It appears that only three parameters will be available: 1) 0x00 represents that Wireless Management is disabled; 2) 0x11 represents that Wireless Management is enabled in AC (using power supply) and DC (using battery) when the machine is turned on; 3) 0x1F represents that Wireless Management is enabled in AC in any cases and in DC when the machine is turned on. Currently, Intel AMT does not support iAMT wireless management to be enabled in DC when the machine is turned off because the notebook battery will be exhausted too soon. Besides, it should be noted that only when the "CommitChanges" function is invoked, the setting of the above function will become available. You have to change the URL when calling the "CommitChanges" function inside "SecurityAdministrationService".

Intel AMT began to support the Zero Touch Configuration (ZTC, which is now officially named as Remote Configuration) since version 3.0, which matches the certificate used by the configuration server via the built-in root certificate list of the AMT firmware and further certify the identity of the two sides via OTP (One Time Password) and specified domain name. After receiving the Hello message from AMT, the configuration server matches the Hash value of the AMT built-in root certificate list and then conducts TLS communication with AMT using the certificate issued by the root certificate configured with Hash value as a server certificate; then AMT will generate a self-signed certificate for the TLS interactive certification. When testing this feature with the ConfigurationServer example provided by Intel AMT SDK 5.0, the error “SSL_ERROR_SSL error: 14094438: SSL routines: SSL3_READ_BYTES:tlsv1 alert internal error” was found as the figure below:

It seems that the configuration server side failed to establish TLS connection with the AMT client. Based on previous experience, I carefully examined the certificates back and forth for many times. The root certificate is correct and Full Chain-required local certificate has no problems either. I was puzzled. Then, through consulting with others, I thought that the problem might lie in the certificate CN name which might fail to pass the AMT match. The root cause was finally found after several experiments. It turns out that in ZTC (i.e. PKI Provisioning) mode, AMT will actively match the domain name of the certificate CN name used by the configuration server with that assigned by the current DHCP server to see whether they are consistent. We can avoid this problem as long as the certificate CN name suffix is set in line with the domain name of the current network when generating a certificate. With regard to domain name match, Intel AMT can conduct mandatory FQDN Subfix check in ZTC mode, i.e. setting domain name suffix for mandatory match in MEBX. It seems that, if it’s not configured, Intel AMT will match the default domain name of default DHCP. 

Intel AMT began to support the Zero Touch Configuration (ZTC, which is now officially named as Remote Configuration) since version 3.0, which matches the certificate used by the configuration server via the built-in root certificate list of the AMT firmware and further certify the identity of the two sides via OTP (One Time Password) and specified domain name. After receiving the Hello message from AMT, the configuration server matches the Hash value of the AMT built-in root certificate list and then conducts TLS communication with AMT using the certificate issued by the root certificate configured with Hash value as a server certificate; then AMT will generate a self-signed certificate for the TLS interactive certification. When testing this feature with the ConfigurationServer example provided by Intel AMT SDK 5.0, the error “SSL_ERROR_SSL error: 14094438: SSL routines: SSL3_READ_BYTES:tlsv1 alert internal error” was found as the figure below:

It seems that the configuration server side failed to establish TLS connection with the AMT client. Based on previous experience, I carefully examined the certificates back and forth for many times. The root certificate is correct and Full Chain-required local certificate has no problems either. I was puzzled. Then, through consulting with others, I thought that the problem might lie in the certificate CN name which might fail to pass the AMT match. The root cause was finally found after several experiments. It turns out that in ZTC (i.e. PKI Provisioning) mode, AMT will actively match the domain name of the certificate CN name used by the configuration server with that assigned by the current DHCP server to see whether they are consistent. We can avoid this problem as long as the certificate CN name suffix is set in line with the domain name of the current network when generating a certificate. With regard to domain name match, Intel AMT can conduct mandatory FQDN Subfix check in ZTC mode, i.e. setting domain name suffix for mandatory match in MEBX. It seems that, if it’s not configured, Intel AMT will match the default domain name of default DHCP.

Recently, a user met a problem when developing with the Intel® AMT-based remote power control feature. AMT posed the Not_Permitted error when executing the remote power off as shown in the figure below:

Figure: Remote Power Off Not_Permitted

However, If Manageability Terminal Tool is used, users will not encounter the remote power off problem.

Later, the error occurred again when using RemoteControl.exe along with IMRGUI.exe of SDK. The error was discovered by analyzing MDK source code. When executing remote power off, the MDK Terminal Tool first stops SOL and then IDER, initiates them again after implementing the power off command. If you are not careful at the MDK Terminal Tool interface, you may think it directly powers off. The conclusion can be verified by the above two exe tools from SDK. To overcome the Not_Permitted error, use IMRGUI.exe to connect with the AMT client, and then initiate SOL or IDER, or both at the same time, and use RemoteControl.exe to execute the remote power off command or the PowerCycle Reset command.

Therefore, when developing with the Intel® AMT-based remote power control feature, we need to first check to see if SOL and IDER are connected before executing Power Down or the PowerCycle Reset command. If they are connected, turn them off and then turn them back on after execution of Power Down or PowerCycle Reset.

Serial Over LAN (SOL) is a serial port redirection function of Intel® AMT used to simulate serial port communication on standard network connection. People who have used and configured device without display interface all know that a serial cable is often needed.  One end is connected to the required operable device (such as a switch, a firewall, etc.) and the other end is connected to the serial port of your own notebook. We can open the Hyper Terminal in Windows and configure the serial connection parameters, then in the Hyper Terminal, we can see the configuration interface of the device at the other side, which is text command line mode or an operable menu in text mode for better. But the limited serial cable length makes the method above only practical when the operator is around the device, imposing greater physical limitations. With SOL features of Intel® AMT, the above method can avoid the physical length limitation of serial cable by transmitting serial port data via the Internet. SOL data transmission is based on TCP, using the TCP 16994/16995 port (IANA has defined the two ports as Intel® AMT redirection port which can be automatically recognized as amt-redire-tcp by the latest Wireshark packet-catching tool), which means serial port data transmission is possible whenever TCP is connected.

 The availability of Intel® AMT SOL features are dependent on several factors:

         1) Vendors can control the enabling and disabling of Intel® AMT SOL features in motherboard production by configuring BIOS firmware parameters;

         2) Intel® AMT SOL features can be activated or disabled via Intel AMT MEBx configuration menu;

         3) Intel® AMT SOL features can be remotely activated or disabled via Intel AMT SecurityAdministrationService interface;

         4) Whether or not to open TCP port required by SOL can be controlled via Intel® AMT RedirectionService;

 According to my experience, the priority should be 1) > 2) > 3) > 4). And SOL features are available only when all setup in the four steps above have been enabled.

 We shall set OemParametersType to 1 (UseSOL) in the remote boot parameter when remotely configuring client BIOS using Intel® AMT SOL. Only in this way can Intel® AMT BIOS boot in SOL mode and simultaneously export output data to the local display and SOL serial port, when both local and remote interfaces and operations are the same. Will SOL features be unavailable if we do not specify the parameter when we reboot the client? No. The only effect of booting without UseSOL parameter is that the BIOS output will not be exported to the SOL serial port. If we write data to the SOL serial port manually, the remote console can still receive it via the Hyper Terminal or other terminal tools. For example, we can open Intel® AMT SOL serial port via serial port program and write data into it when Windows is booted, so that the data can be seen by the terminal window of the console; and data entered via the terminal window keyboard can be received by the client serial port program.

 If DOS is booted instead of UseSOL, like Windows, it has to interact with the terminal window of the remote console by reading and writing SOL serial port via programs. If UseSOL is booted, DOS output can be automatically redirected to the terminal window of the remote console without reading and writing the serial port as DOS input and output is based on BIOS, and the remote console input will be automatically received by the DOS system. If we still use programs to read and write SOL serial port on DOS, my test shows that the data written to the port can still be transmitted to the terminal window of the remote console. But the DOS system also continues screen output, which will soon override the data written on the serial port. If you do not check the terminal window of the remote console carefully, you might think that data directly written to the SOL serial port has not reached the remote console.

 As for Linux systems, you can see its BIOS-based boot menu (e.g. LinuxGrub) by booting UseSOL. Core boot output is not exported to SOL by default. We generally add a parameter console=ttyS1 in the core boot parameter, then the core boot data will be automatically exported to ttyS1 serial port. It should be noted that the AMT SOL serial port is ttyS0 if the host has no physical serial port; ttyS1 for one physical serial port, and so on. When Linux is fully booted, default consoles will not be exported to the AMT SOL without configuration. Generally, if you want to export any console to the SOL, you have to modify /etc/inittab file and open a console on the SOL serial port (ttyS1 in most cases) with agetty, so that a login prompt can be seen in the terminal window of the remote console.

This blog's original link:  What should I do if iAMT cannot be connected?

In the past one or two weeks, I have been confronted with several cases from customers and the lab that iAMT has been set but cannot be connected. Now these problems have been solved and I’d like to share some of the solutions.

Currently, there are two ways to configure BIOS of iAMT. For Intel motherboard, the configuration shall be directly integrated into the Tiano BIOS in the “Intel ME” menu. Otherwise, you can enter the iAMT configuration menu by pressing “Ctrl+P”. New firmware (refreshed or newly manufactured) enters the iAMT BIOS with the default password “admin” at the first time, then the system will prompt you to change the default password in compliance with the password rules.

At this time, iAMT is in the Enterprise model, obtaining IP address using DHCP. iAMT has two Provisioning Models: Enterprise and Small Business (SMB). Changing the model in the iAMT BIOS menu is a shortcut. Generally the default model is Enterprise, so the provisioning model is generally changed into SMB in BIOS. I will not elaborate on the difference between the two models, which is mainly about security level. Their functions are basically the same, except for the configuration of the enterprise model is more complex, requiring the help of configuration server. But we generally choose the SMB model for iAMT function verification. We can change the Provisioning Model to SMB in the iAMT BIOS.

After saving changes and exiting you can test iAMT function. How? The simplest way is to test is through web page: Find the IP address assigned for iAMT machine via DHCP server or operating system (OS) of the iAMT machine, then open the browser via a machine connected to iAMT in the same network and enter http://iAMT-IP:16992 to see whether the login interface can be viewed. If not, set iAMT with a static IP address that shares the same network with the operation host. Remember not to set the address for iAMT to be the same address as the iAMT machine OS. Then, test it via WEB again. If it does not work, turn off the host for a short time and then turn it on for retest. If it still does not work, conduct further analysis provided that the setting of provisioning model and static IP is correct (we assume that at this time iAMT machine has entered OS):

1) Check whether the network is connected: Open a command line window (not on the iAMT machine, but on a machine connected with iAMT). Ping the IP address of iAMT machine to check whether it is through, if yes, the connection between network physical to link layer is normal; if not, conduct further analysis:

a) Ping the IP address of iAMT machine OS to check whether it is through. If yes, the network connection is ok, then go to step 2) to continue; if itsnot, conduct further analysis;

b) Use arp command “arp -a” to check whether or not the iAMT MAC address is parsed. If it is parsed, the reason might be the ping response of the iAMT machine has been disabled; or ICMP network data has been blocked by another network safety device in the network connection between the machines.

c) If the arp command shows iAMT MAC the address is not parsed, there might be a network connection problem. Connect iAMT machine with console machine directly with a common network cable. Then do the above test again. If it is still not through and the mac address is not parsed, exclude non-network-cable physical issue, and use the packet-catching tool to analyze the packets on the network port to see if there is anything abnormal or contact me to help you find the cause of the problem (^_^).

2) When no problem is found in the ping process, but iAMT is still not accessible via web page, use Telnet to test whether the iAMT port is open or not. Enter telnet iAMT-IP 16992 in the command line. If the system prompts connection failure in the end, you need to check in the iAMT BIOS whether or not SMB is chosen for Provisioning Model or disconnect the iAMT power supply for a moment and test again. If it still does not work, one of the possible reasons is iAMT Environment Detection has been opened, making iAMT automatically shield itself. In this case, you need to reset iAMT and test again. If the problem is still not solved, it might be a Firmware problem. Find the latest BIOS at the motherboard vendor’s website for an upgrade. If you fail to solve the problem again, there is a good chance that the motherboard is broken or you didn’t check the above steps carefully. You may contact me to help confirm whether the motherboard is broken.

3) If you can telnet to TCP 16992 port but cannot open the web page, check to see whether or not there are any browser setting problems, such as a proxy was set etc. Or you can change a browser, such as Firefox etc. There is also a chance that iAMT WebUI interface has been disabled (the WebUI is enabled by default). Then, you need to use SDK or other tools for verification, such as DTK, RDK etc. Generally, the easy-to-use DTK with GUI interface is recommended. You can download it from Intel Manageability Community. Upon installation, you can use the Commander tool inside to detect iAMT machine automatically after adding corresponding iAMT IP or set the scan range.

4) If you can telnet to the 16992 port, but cannot connect webui and DTK, there is a possibility that you have telneted to the OS 16992 port, which is prone to happen when both OS and iAMT use DHCP to obtain IP. You need to start the iAMT machine and stop it somewhere (it could be where multiple OSs choose to enter) before entering the OS or after entering the BIOS, then conduct the test according to the steps above and ensure the test is not affected by the OS.

Finally, for such iAMT problems such as various connection and feature abnormities, the final solution is to analyze data packets with packet-catching tools (my panacea which helps me solve almost all the iAMT-related problems :-) ). Eathereal(now it is called Wireshark) is my favorite as it is free and easy to use.

If there is one thing that you should definitely do on your laptop or desktop computer it is to have a backup and recovery plan as hard drives do sometimes fail and users do sometimes erase the files they would otherwise intend to keep. I spent some time last night helping some friends with a PC that appears to have a defective hard drive.

Norton Ghost 15 is the software that I use to backup the entire computer every few days, along with documents once a day, to an external hard drive. I have also had to restore the machine from a ghost image of the hard drive, booting from the Ghost CD and selecting the image to restore.

If you're using Windows 7 or Windows Server 2008 R2 then you might want to also consider using Norton Ghost 15. While Norton Ghost 15 will only install on client versions of the operating system it can run backup a PC from the bootable CD without even installing the software. I personally dual-boot Windows 7 and Windows Server 2008 R2 and so the scheduled backup backs up both hard drive partitions.

What would be great would be if Symantec allowed tools such as Norton AntiVirus 2010 and Norton Ghost 15 to be installed upon Windows Server if used for personal use. One option would be to allow the tool to install if the Windows Server instance operates within a workgroup and not a domain.

While Windows 7 provides simple backup and restore functionality Norton Ghost 15 provides some significant benefits over the Windows 7 backup and restore, these include:

1. Cold imaging allows backups to be created without even installing Norton Ghost 15, useful if you're using Windows Server 2008 R2 as a workstation operating system.
2. Blu-ray disc support allows backups to be created on writable blu-ray media.
3. Off-site backups written to an FTP location.
4. Encryption support protects valuable data within backup images.

Regardless of which backup and restore software you use, ensure you have a backup and restore system for your PC and test the restore process to ensure that it will work when needed.

Probably the most significant public facing accomplishments included the release of the book “Platform Management Demystified” which seems to be doing very well. When attending IDF in San Francisco this year, we gave away 800 of these books and it served both as boot promotion and as a promotion for Intel Active Management Technology. If you have not pickup you copy already, it’s available on Amazon.com. Speaking of being at IDF, this year I was co-speaker at a session and had my very own lab. Both the session and the labs did very well and I am expected to be speaker again for IDF Beijing in April.

Another accomplishment this year was the re-release of the Developer Tools for UPnP Technologies. Back in 2003 or so, I worked on a set of development tools to make building and testing UPnP solutions much easier. The tools had been on the Intel web site for a long time but without maintenance, we when offline and needed an update and a new open source license. These tools are now released at: opentools.homeip.net.

Also on the same web site is the open source release of the mesh network prototype software. It’s not ready for primetime yet, but I expect that this coming year it will get most interest as it actually starts doing useful things. Most of my coding time this year was spent on this mesh software, it’s really difficult stuff to build but it’s really powerful. Imagine being able to monitor and manage all your computers is one or more sites from a central web site and do it regardless of firewalls, proxies or which computer is on or off at any given time.

One of the big deals for Intel this coming year is the ATOM store. I bought myself a Netbook at CostCo this year since I wanted one and I would see if I could help out with the effort. I am mostly a C# developer (with the exception of the P2P mesh agent written in really tight C code) so when it came time to help with the ATOM store, my first contribution was to see if I could make C# apps work with the App Store SDK. I also built myself a test application that is well suited for the Netbook form factor just to try my hand at it.

I got myself a Microsoft Home Server and worked on an add-in for it. We will see how that effort goes in the next year, certainly some interesting possibilities. I also worked on a really small Linux boot image for remote booting computers over IDE-R in less than two minutes.

All in all, this year was filled with plenty of fun projects and a lot of potential building blocks. I fully expect that I will build on top of these existing software components many new innovations in the year to come.

Ylian

Does anyone have suggestions to reset the management engine or have an idea what is going on?

Update: The problem seems to be intermittent. This morning I played SIMS3 full speed on the train for a few hours before the computer started to slow down again.

Thanks,
Ylian

We were asked by Ph3ar in the Manageability Forums the following question:

"I have searched a bit but was quite difficult to find a list with the available AMT versions except this wikipedia entry that seems incomplete."

This is a good question, certainly useful info for all.

I directed Ph3ar to the Start Here Guide and this old post by Gael, but couldn't find any public article or page that better defined the differences. I'm sure it's somewhere in our site, but not much use if no one can find it, right? :)

I'll post in this blog what I know about the differences between Intel AMT versions and generations. It will be indexed, searchable and Googable (yay!); and if you know of a better or more-official information resource let know so I can update or fix accordingly.

First, an introduction: Intel AMT generations are identified by a version number. This number consists of 4 parts: m.x.hh.bbbb, as in 3.2.10.1080.
The numbers mean:
- m is the Major Version, which defines in which platform (type of hardware) the specific version runs.
- x is the Minor Version, used to differentiate between versions with different capabilities for a specific platform.
- hh is a secondary minor version. Different values will usually have the same features but with improvements between them.
- bbbb is the build number, which has little effect to real world users. :)
Intel AMT can be upgraded to higher Minor versions, but different Major versions require different hardware support.

Ok, so here's the non-official table of features:
(How to read it: Parallel features in projects appear in the same row, the dark cells show from which Minor version the feature is supported, and each higher minor version includes the features of the previous ones.)

Hopefully the table above will be valuable to clarify the picture for you.

Note 1: The table comprises only main features. There are features not mentioned in the table.
Note 2: This is not a division according to the realms existent/supported by each generation, it focuses around features only.
Note 3: The table does not include information about the variations of manageability mode added in 4.x or 5.x, like Standard Manageability, Level III manageability, Remote PC Assist...
Note 4: There may be errors in the table. Post your correction in the comments below! :)

Happy Holidays!

The most common way of communicating with a hardware device is via a device driver. This is software that opens to the Operating System the interface to the hardware devices of a system, translating Operating System commands to the specialized protocol and communication type required by the hardware.
Intel AMT technologies hardware devices have a driver, which carries all dialogues between the local operating system and this planar PCI device -- this driver is called the Intel Manageability Engine Interface (Intel MEI), formerly known as the HECI driver (for Host Embedded Controller Interface).

However, the hardware protocol is very specialized and limited, and writing agents or software to speak with AMT over this protocol would not only be cumbersome, but would require from our ISVs to learn yet another interface.
The best solution to this problem is to open, for local access, the same interface which is used for remote access: The HTTP (through SOAP or Ws-Manageability) protocol described in the Intel AMT SDK. Doing that gives us the following advantages:
- Unified protocols for local and remote commands
- Consistent settings for local and remote
- Unified authentication
- As the remote protocol is HTTP based, this gives us the same level of security we have on remote on the local communications (Kerberos/Digest authentication, TLS cryptography...).

Enter the LMS.
Most Operating Systems will not route local communications externally. That is, when network packets are destined to an addresses in the same host, the Operating System will create the connection within the OS, without trace of it in the external LAN interfaces.
When an application wants to send HTTP requests to Intel AMT from the OS, its counterpart to receive these requests within the OS is the Local Manageability Service. The LMS is a Windows Service that listens to communications to Intel AMT ports (16992 and 16993) and forward them (enveloped in Intel MEI messages) to the Intel AMT HW Device.

The great thing is that the messages reach Intel AMT as they are, and the control over traffic and all the other network or security mechanisms are performed centrally by Intel AMT.
Intel AMT on local will present a new level of protection: Only the relevant network interfaces are available, all the rest are blocked to prevent malicious or erroneous use.
The info in the table below was extracted from the Active Platform Management Demystified book, and it enumerates the interfaces open in local and the blocked ones (note: it also varies a little bit between projects):

In the next blog post, we'll wrap up the relationship between all Intel AMT software, and then prepare for the differences in the next Intel AMT version, version 6.0.
See you there!

Articles in the Intel® AMT software series:

1. The software bundled with Intel AMT
2. The notification area icon - understanding the pop-up
3. Configuring the notification area icon & app
4. More configurations (disabling) of the Intel AMT icon
5. Detailed information to the user with the User Notification Service
6. How the UNS works
7. UNS Error Messages and how to fix them
8. Newfangled Intel Management and Security Status
9. Intel Management and Security Status (IMSS), advanced configurations
10. Intel AMT software: LMS, HECI, MEI... why do I need those?