Initial AMT Setup

Initial AMT Setup

I've setup my new dell optiplex 755 with WinXP according to the setup manuals with static IP.
The AMT status service shows AMT is enabled. All drivers appear as required, but when starting Outpost from the DTK I get a failure message (like a previous post complained).
Also when browsing over to http://:16992, I do not get the console.
How do I go forward? How can I validate my AMT settings - is there some lower level options?
Thanks in advance, Robi

36 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.


I was wondering if you enabled AMT on your Dell system? When you refer to your static IP address, is that for your host OS? You will need to go into the BIOs, configure the ME (tell it to use Intel AMT) and then you will have to configure AMT and give it a static IP address as well. This is the IP address that you would connect to via the Web UI. (If you are using Static IP, your AMT Client will have a different IP address than your Host OS.)

You will have to change the ME password (to a strong password)if this is the first time you have gone into it.

Once AMT is enabled, make sure you can ping the system (using the AMT IP address.) If you have a firewall enabled you also won't be able to connect.

Check out the Start Here guide for some help.

Also check out this blog on setting up an AMT Client.

I hope this helps.

Follow me on Twitter: @GaelHof

Thanks for replying.
Actually pinging the AMT static IP does not work on the AMT host machine, so I tried pinging form another machine and over there AMT replis. Additionally, with AMT commander on the other machine I can access the AMT machine.

So the question remains why can't I ping AMT from the local machine? Hopefully this can help resolve the problem of Outpost which can't access AMT.
Is there some way to check the installed drivers?


You are not supposed to connect to the AMT system locally through WebUI or ping locally even if you have static IP. Another question is do you have LMS and HECI drivers installed on your system?



I do have the drivers installed, on startup the LMS service informs that AMT is enabled.
I just suggested that maybe the fact that the AMT does not answer to local pings, may point to the problem of outpost not succeeding to connect either.

Thanks anyway
p.s. I've also installed WinRM - Microsoft's WS-MAN but it does not help with web local access, nor with outpost


I wonder if your trouble is not a network topology issue ... did you configure your AMT host and AMT device with static IP on the same subnet? in that case the switch or hub will not forward any packet back to the same port and a transmitted packet from the host will never get back to the AMT device (there is no loopback).

However if you are using different subnet with correct default gateway than can route packet from one subnet to the other you will be able to ping your AMT device from the AMT host...

did you try this?

Your'e right, they are configured to the same subnet.
Here are (one of) the settings I've tried.

AMT: (mask
Remote machine (which also acts as a gateway, on one of it's NICs):

From the remote machine I can ping AMT.
From the local machine I can ping the remote (gatway) and also the local ip (101) but not the AMT.

I've tried moving AMT to a different subnet, but did not succeed pinging it at all - tried to add static routing info on both machines, but possibly mistaken, so:

1) Would appreciate help on configuring the gateway routing to the other subnet.
2) Do you think that Outpost will not work till we can locally ping?

Thanks, Robi

Well, some more info (thanks for keeping along with me...)

I ran Outpost under a debugger and I see that it fails connecting while invoking a web service (probably the first one) with a method name "GetCoreVersion".The exception message is:

The underlying connection was closed: An unexpected error occurred on a receive.

So still it seemslike a networking issue.


In the static IP mode with two IP addresses for the AMT device and host system, you won't be able to ping each other even ifthey are on different subnet. I have forwarded your Outpost question to Ylian.



Hi there. I just released Intel AMT DTK v0.51x a few minutes ago. You coudl try that first.First aword on AMT/LMS/Outpost:

The way AMT is hooked up to the Gigabit network adapter makes it impossible to access using the OS loopback adapter ( any traffic you send to will never reach the network hardware and so, never reach AMT.

So, there is a way to talk to AMT using a HECI driver, it's a local driver that talks directly to AMT using a customer driver. A service called LMS ("Local Management Service" I think) will listen to TCP ports 16992 and 16993 and forward the traffic thru the HECI driver to AMT.

As you can see, when you contact port 16992 on the local computer, the traffic is just captured byLMS and forwarded to AMT using a driver. It's not going thru the network at all. Also, network configuration on AMT will not affect the HECI driver or LMS.

Here is my checklist of things that be cause Outpost to not be able to connect:

  • Check that theHECI driver is installed, and it's the correct one for your computer.
  • Check that LMS is running, it's a Windows service "Intel Local Management..."
  • Check that LMS is listening on 16992or 16993. Use "Netstat -all".
  • Check that you are not using TLS with Mutual-Authentication turned on. If you do, you will need the correct certificates to connect. If in SMB mode, this is not a problem.
  • Check that you are not using a Kerberos account. If in SMB mode, this is not a problem.
  • Check that you don't have firewall software that may be blocking loopback access to LMS. Try turning off firewalls just to see if that is the problem.

Hope this helps,
Ylian (Intel AMT Blog)

Thanks for the detailed answer, however, in spite of:
- LMS is installed and listening to those 2 ports (checked with netstat)
- All firewalls are turned off
- Heci drivers from Dell site are installed (R148566 + R162295)
- AMT configured in SMB mode

When browsing to the local address, there is no connection.
I tried the new Reflector tool and forwarded some arbitrary port to 16992, in this case when pointing the browser to the new port, it replies with an empty screen (White Screen Of Death?), but for different ports there was again a connection error - so might be that LMS is trying to do something and fails silently. Maybe the drivers are not functioning but I don't know how to validate this, except for the status service in the Windows notification area which shows that AMT is enabled.

I am stumpted. First, when LMS is working and you use a web browser to access 16992 on LMS, youmay not see the Intel AMT web page, it depending on the AMT version.

If you use Intel AMT Reflector, you need to run reflector on a different computer that does not have Intel AMT. In that case, you can reflect back 16992 to 16995 connections back to your own computer and it will be just like you are accessing AMT from a different computer.

Other than that, I am stumped, it should work... try updating your firmware.

Ylian (Intel AMT Blog)

I would try using DHCP and make sure the host name of the AMT client and the host OS is the same. Aside from that, this feels like a network issue. Make sure all of your systems can ping all of your systems (at least the systems you are using to do this experiment) and make sure you are entering the correct passwords.

Follow me on Twitter: @GaelHof

Hi - one more thing... Could you verify if you have enabled SOL and IDER in your AMT Configuration? The AMT configuration does not enable Serial over Lan by default and this is what AMT Commander uses.

To enable this:

Hit CTRL-P during boot up to enter the AMT configuration Tool

Select Intel AMT Configuration
Select SOL/IDE-R
Press Y acknowledging changes

User Name and Password should be enabled
Serial over LAN should be enabled
IDE Redirection should be enabled

Follow me on Twitter: @GaelHof

One more thanks...

As detailed above I can ping all directions except from the local AMT machine to the AMT given address, however I understand this is OK, since locally the LMS catches messages and forwards to AMT through the HECI driver.

I've rechecked and all SOL/IDE-R options are enbled.
I'm also OK with the passsword since extenally (from a browser or using Commander) I can access AMT.

I think I'll try a different machine when I find one.
I'll report if something is found, thank you all.

One more question - could you check your AMT configuration and make sure you entered the Host Name for the AMT client and that it is the same as the Host Name for the OS - if you haven't done that, you will be able to ping, but it will be the host OS that is answering, not the AMT Client.

You will not be able to ping the AMT Client from the Local AMT System. Ever. (I'm still not clear on if this is what you are trying to do...) The LMS and HECI software are used for APIs that are designed to work on the Local AMT Client. There are many operations that won't work locally and pinging is one of them.

Follow me on Twitter: @GaelHof

I tried the HostName both ways. In any case, I used the ip addresses when trying to ping. I now understand that locally pinging is not a method to validate connection with the AMT client. It could be nice if you could add some other ways for diagnosing such problems.
The bottom line is that I don't have local connectivity (Browser/Outpost) to AMT.


This page has a link at the bottom to a video tutorial on Outpost (Intel AMT Outpost agent (v0.11)) Please go through it and see if this is what you are trying to do here.



Hi - are you still trying to get the Web UI from the local AMT System? You will not be able to do this. You must connect to the Web UI from a remote console.

Follow me on Twitter: @GaelHof

Well, I could do without a local Web UI, but I see that (at least some of the)
developer tools work above a web layer anyhow (through the LMS).
My main concern now is
succeeding with operating Outpost - locally. It's local functionality like watchdog acknowledge and storage access can not be replaced by remote access. Right now it seems to fail due to
local networking issues!
BTW, I followed the mentioned above videos, if not mistaken some even show local web access, e.g., by Commander (at least in the demonstrated version).

Hi there. In the DTK video about Outpost, I wanted to show both Outpost and Commander on the same computer screen. I start the video by saying that I setup a special router that will send the network traffic back to me.

So, in the video, I connect Commander and the web browser to a router, and the router echos the packets back to Intel AMT. I hope you understand that in this video, the network traffic is going outside of my computer to the router and back.

In the video, Intel AMT Outpost is connected localy and talks to LMS. It can does basic SOAP commands, but the web page would not work.

Idealy, I should have done the video with two comptuers. One with the web browser and Commander. The other running Intel AMT Outpost. My YouTube demonstraion show the demo on two different comptuers:

I hope this helps. Really, Intel AMT can not server web pages localy.

Ylian (Intel AMT Blog)

Okay, old thread, but still valid.

Various thoughts:

1) It is "netstat -a" NOT "nestat - all"

2) You mention how to check LMS service, but NOT how to check HECI driver version???

3) How do we check if we have TLS with mutual authentication turned on? On my Dell 780, it shows listening on 16993, but not 16992. Shouldn't it be listening on 16992?

4) I cannot get to it via browser from a remote machine http://testbox:16992 or 16993 - both fail.

5) I can ping it just fine from a remote machine, so the AMT ip address is pingable.

6) I am *VERY* confused why you tell us to configure AMT with the SAME HOST NAME AS THE HOST COMPUTER, but different IP address - that means I have a static IP and dynamic IP - both with SAME name!

7) My AMT status via the Intel app shows "Unconfigured, Awaiting Configuration"

Thank you for any insights and answers/tips!

The first thing I'd have you do is run the SCS Discovery tool - this will show you what you have (and send the xml file if you need more assistance.)How to run the SCS Discovery ToolHere is a blog I wrote on checking the HECI driver version:Communication error between application and Intel ME module (FW Update Client)On the IP Address question- these days we are suggesting DHCP. Currently Static IP addresses are only applicable to the wired interface (not sure what configuration you are working with..) The SDK Documentation has a lot of information on this.TLS Authentication - if your system is awaiting configuration, you will not be able to access the ME/AMT until it is configured - so there are no authentication methods that have been applied at this point. I don't know what version of AMT you are working with but in recent releases there is a section in the SDK Docs:Set TLS to Server/MutualAuthentication - you can see that there is an API that you could call and check the authentication mode.

Follow me on Twitter: @GaelHof

Thanks very much for the reply. That does help a bit.

As for the version of AMT, it is

I prefer DHCP as well (for the AMT portion), but my point was, with the recommendations of various experts, they all seem to be saying:

1) Host Name (i.e., name of computer) = (static ip, for example)
2) AMT Name = (dchp - random ip)
In that scenario, we will have TWO instances of an identicalDNS name pointing to two separate IPs - how does that work?

So, if I ping - WHICH one would it ping? Wouldn't that be some sort of conflict?

Upon reading some more docs, I think on Intel's site, it mentions to give the same name to the AMT host as to the machine itself; and something about "the software or firmware may change the name(?)"

So, does that make sense? It's just very confusing to have a recommendation that TWO ip addresses should point to the same DNS name, without any further explanation as to WHY that is not a bad idea.

Can you send me the links that you are referring to regarding recommendation about having two ip address pointing to the same DNS name? That sounds wrong. With DHCP you the ME should take the same IP address as the host OS (see the Link Preference portion of the SDK.) At one point it was OK to have a static host but a dhcp ME but I don't think that is supported anymore, at least not on the later revs. Meanwhile I will see what I can dig up on the 5.2 AMT release requirements.

Follow me on Twitter: @GaelHof

No, as far as I know, there is no restriction on using static.
It would be impossible to offer this type of thing 'without' static as an option, due to military, security-centric places; etc. Some folks (us included) just do NOT use DHCP - not for our hosts anyway.

Still supported are:
1) Host=Static, while AMT=DHCP.
2) Host=Static, while AMT [also] = static.

Another question - I am on 2008 Server R2, but in all examples for requesting a cert, I see they say, "Choose Windows 2003 Enterprise." First off, I don't have "Enterprise" version of o/s - not for these servers.
Secondly, does it have to be choosen and Windows 2003, or can I go ahead and choose Windows 2008 as the "type of cert?"

Thanks again!

This paper about creating certificates might be of some use to you. Bascially, if you have a system where you have already enabled AMT, you can apply TLS authentication after the fact. This paper shows you how you can create a certificate using OpenSSL and the AMT SDK and then how to install it using PowerShell. If you are trying to use a Windows cert, then you would need an OS that can operate as a Certificate Authority.Are you allowed to use DHCP on AMT? Or are you restricted to being static in both AMT and the OS?

Follow me on Twitter: @GaelHof

Thanks again for the continued invaluable information.

We defininitely want to use DHCP for the AMT side. We use static for our Hosts - so, we don't really have a choice on that.

I definitely am using Windows certs (currently) - have used some OpenSSL in the past. I have my CA setup, already submitted one request and generated the cert, installed it, etc.

BUT, in the typical examples, it shows the Intel-AMT cert as having 2 'purposes' listed - one for 'Ensures the identity of a remote computer' and one for 'Proves your identity to aremote computer'; but when I generate one from my Internal CA, it has only 'one purpose' listed - 'Ensures the identity of a remote computer'

Thoughts? Has anyone used their own certs successfully for the provisioning part? I don't mind entering the thumbprint into BIOS as needed but I just want to make sure I generate/create the cert requests and certs properly. Thanks!

It sounds to me that ensuring and proving is the same thing. Here is a blog that talks about provisioning certs - this might helpe you a little bit, but I'm pretty sure I had a blog that addressed creating your own - I have done this as well and got it to work. It still requires the OU field to be set correctly, Option 15, the FQDN - so this blog might be helpful. (I'm going to look for more info on creating your own provisioning cert.)Intel AMT and Remote Provisioning (aka Zero Touch)Here is another one that might help:Remote Configuration Certificate Application Best Practices for Intel vPro SystemsAnd another one:

Follow me on Twitter: @GaelHof

Thanks greatly! I am reading those now, and have read the MickySoft article on "how to" and it mentions using "your own" - but it says, in order to do the "Duplicate" and create the "AMT Custom provisioning template," you have to have 2003 Server 'Enterprise' version - so that puts a kink in things.
But I swear I saw someone who said they were able to do it with 2003 Standard.
We really have 2008 R2 Standard, but it still applies. Here's the article about needing 'Enterprise' version:
(steps 19 & 20 , and the related 'yellow note.')
Also,I don't recall any specs mentioning if the Cert has to be V1, V2 or V3, which also makes a difference, apparently.
And a note on another article that says now Godaddy supports the AMT provisioning certs via its 'Standard' certs, so you don't have to shell out the extra bucks for the "Premium SSL Cert."
It mentions the "must-have" Enterprise version of o/s. Ugh!

That is an excellent article - I have only used the Enterprise Windows versions and it has always worked for me. So it sounds like either you upgrade or you look into GoDaddy. It's too bad you can't use the Host Based Provisioning method that was available starting with AMT 6.2 (push down a script, run it and you're provisioned.)
Here is a blog regerding the GoDaddy Premium vs Standard Certs:

Follow me on Twitter: @GaelHof

FYI, also, here are the 1-4 steps I found that also show, specifically from Godaddy, the cert having the 2 purposes and the OID # 2.16.840.1.114413.

If someone can screen-shot or verify it does NOT need to have the 2 purposes, and so forth, and that they got it working with 2003/2008 NON-Enterprise (i.e., Standard - LOL) version, that would be good.

I don't think we have any more 2003 Enterpriseservers left around - even if we did, I would need to move my CA to that server, and I'm not doing that. We do have some 2008 versions, but I'm not moving my CA just to get 'one or two' minor features that, imo, already should be allowed in 2008 R2 Standard!
Again: UGH!

Yeah, but 'host-based' is the "light/broken" version - it doesn't allow the remote KVM functionality, where I can re-direct the person's screen and remotely boot, while being like I'm right there at the"console."

I think that's the difference that I was remembering.

Few people realize that you can "move" a system in Client Control mode over to Admin Control Mode after AMT is enabled. I think the DTK offers this as soon as you connect to the system. Once an AMT system is enabled, and it can be in the most primative, basic configuration, you can modify it's configuration via the APIs or the powershell scripts that are included in the SDK. You can even apply TLS authentication once AMT is enabled. It doesn't all have to happen while running the Intel SCS tool.Have you checked out the Director portion of the DTK? You can create provisioning certs using that tool. Bring up Director, go into Certificate Manager - create a root certificate, once that is done create another certificate - in the drop down select remote configuration certificate and that should do it.When creating the root certificate, be sure enter your Common Name and Organization Name.

Follow me on Twitter: @GaelHof

As you can see, when you contact port 16992 on the local computer, the traffic is just captured byLMS and forwarded to AMT using a driver. It's not going thru the network at all. Also, network configuration on AMT will not affect the HECI driver or LMS.

Leave a Comment

Please sign in to add a comment. Not a member? Join today