Initial AMT Setup

[robi_y]

Hello,
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

[tnjman]

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!

[Gael_H_Intel]

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 Tool

Here 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.

[tnjman]

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

As for the version of AMT, it is 5.2.40.1037

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) = MyComputer.abc.com (static ip 10.1.2.19, for example)
2) AMT Name = MyComputer.abc.com (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 MyComputer.abc.com - 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.

[Gael_H_Intel]

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.

[tnjman]

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.

[tnjman]

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!

[Gael_H_Intel]

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?

[tnjman]

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!

[Gael_H_Intel]

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 Systems

And another one:

http://software.intel.com/en-us/blogs/2009/08/18/intel-amt-certificate-based-provisioning-aka-ztc-in-4-easy-steps/

[tnjman]

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.')
http://technet.microsoft.com/en-us/library/cc161804.aspx#BKMK_AMTprovisioning2
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."
Also: http://technet.microsoft.com/en-us/library/cc700804.aspx
It mentions the "must-have" Enterprise version of o/s. Ugh!

[Gael_H_Intel]

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:

http://communities.intel.com/community/openportit/vproexpert/blog/2011/03/09/vpro-provisioning-certificate-from-godaddy--new-standard-ssl-certificate-support?wapkw=provisioning+cert+premium

[tnjman]

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.1.7.23.2

http://scug.be/blogs/sccm/archive/2010/05/06/step-by-step-guide-for-provisioning-intel-vpro-clients-in-sccm-2007-sp2-part-1.aspx

http://scug.be/blogs/sccm/archive/2010/05/06/step-by-step-guide-for-provisioning-intel-vpro-clients-in-sccm-2007-sp2-part-2.aspx

http://scug.be/blogs/sccm/archive/2010/05/06/step-by-step-guide-for-provisioning-intel-vpro-clients-in-sccm-2007-sp2-part-3.aspx

http://scug.be/blogs/sccm/archive/2010/05/06/step-by-step-guide-for-provisioning-intel-vpro-clients-in-sccm-2007-sp2-part-4.aspx

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!

[tnjman]

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.

[Gael_H_Intel]

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.

[juhe86eri]

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.