Manageability tools problem

[idata]

Hello,

today I successfully activated Intel AMT on a DQ57 based PC.

My network has MS AD, we don't use 802.1x yet.

ME firmware version 6.1.1.1045, but somehow it supports Host Based Setup (Client Mode Operation). (?????) Newest firmware is 6.1.20.1059, so still no 6.2...

The configuration was done by Configuration CLI and an XML file. I have much more issues with TLS now, so I just use AD integration and no TLS (AD object is created successfully though).

The worst issues are with provided Manageability tools.

I can't connect to "amt-pc", nor "amt-pc.domain.com", though I can connect to the IP address. WebUI works with all 3 types - computer name, FQDN and IP address.

a) "ping amt-pc" is ok, when using this name, connecting is slow, debug says after 10 seconds "The remote name could not be resolved".

b) "ping amt-pc.domain.com" is ok, when using this FQDN, the manageability tools fail to resolve the name too, but it takes only like 0.5sec.

c) when I'm using the IP address, connecting is slow (like with amt-pc), but it's successful

Any ideas?

[idata]

When you say "Manageability Tools" which tool are you referring to? Are you referring to the "Manageability Commander Tool"? If so, what version of the tool are you using? (It should say at the bottom of the window).

[idata]

Manageability Director Tool 7.0.11161.2 and Manageability Commander Tool 7.0.11161.2

[idata]

You might try the "Flush DNS Cache" option. Right click on the Network node and select "Add Intel(R) AMT Computer", then click the flush DNS cache button.

In Commander could you take a look at the debug information? Select "Help" from the menu and then "Show Debug Information". This should show Commander trying to connect via the 16992 port (non-TLS) and then if that fails trying the 16993 port. Before it attempts the TLS connection it should give you an error reason for the non-TLS connection. What does that error say?

[idata]

I flushed the DNS cache and I also restarted my system a couple of times. Still the same debug message when not using IP: "The remote name could not be resolved: 'amt-pc'". The same message from the debug window is for non-TLS and then repeated for TLS connection.

[idata]

Now I tested 3 different AMT systems. Same results.

System 1: Lenovo X201 33238UG, BIOS 6QET66WW (1.36), Core i5-540M, Intel AMT 6.2.0.1022

System 2: Intel DQ35JO based system, BIOS JOQ3510J.86A.1143.2010.1209.0048, Pentium E2160, Intel AMT 3.2.30.1055

System 3: Intel DQ57TML based system, BIOS TMIBX10H.86A.0037.2010.0528.1504, Core i5-650, Intel AMT 6.1.1.1045

I tried connecting physically and through VPN. Browser connections always work.

[idata]

Now I tested 3 different AMT systems. Same results.

System 1: Lenovo X201 33238UG, BIOS 6QET66WW (1.36), Core i5-540M, Intel AMT 6.2.0.1022

System 2: Intel DQ35JO based system, BIOS JOQ3510J.86A.1143.2010.1209.0048, Pentium E2160, Intel AMT 3.2.30.1055

System 3: Intel DQ57TML based system, BIOS TMIBX10H.86A.0037.2010.0528.1504, Core i5-650, Intel AMT 6.1.1.1045

I tried connecting physically and through VPN. Browser connections always work.

One more thing: It all works like a charm with Manageabiltiy Commander Tool 6.0.10314.2

[idata]

Hello,

Let's target this in two pieces. First it appears we have an environment issue with DNS/DHCP. Have you verified your client is in both the Forward and the Reverse lookup table? Also, if you do an nslookup, does the FQDN display or is it unresolved? Another thing we can look at is to make sure we are NOT using Static IP. I've seen a couple of users with this issue.

The second piece looks like a DTK bug. But in order to verify this, we need to make sure you can manage your clients using the FQDN via the WebUI.

As a side note, we encourage users to submit DTK related issues to our support team via mailto:support_dopd_swe@intel.com support_dopd_swe@intel.com This is our support email account where you can submit your Debug log file (See attached file) and details about the issue you are having. This support method helps us manage the defects and ensure we address each issue with the appropriate level of detail.

I hope this help's a little and provides you with some steps to move forward with the end goal of getting you to manage your clients via vPro.

Thanks!

LM

[idata]

Hello!

Thank you for your reply.

First, I also thought it was a DNS issue, but

1. The computers have dynamic address, they appear in Address Leases of DHCP. Address Leases hostname&IP match DNS Forward and Reverse zones.

2. nslookup returns correct authorative answers for FQDN and for hostname only.

3. IP:16992, FQDN:16992, Hostname:16992 in browser gets me to AMT login page.

4. Manageability Commander Tool 6.0.10314.2 works with FQDN, Hostname and IP.

What really bugs me - I don't think I'm the only guy in the world trying to use Manageability Commander Tool 7.0.11161.2 with FQDN...

I think I'm going with the report bug anyway. Thank you for posting it.