SCS - Exception while provisioning AMT

[Maria_Camila_Gomez-S]

Hello
I am working with the Intel SCS, I have already been able to install the Windows Service and the Console.

SCS is set to work without TLS and it is not integrated with Active Directory yet.

I have generated the PID/PPS keys and already set this keys to my AMT machine which has been pre-provisioned (admins password changed, SCS server IP Address and port set, etc).

I entered the AMT machine under "New Intel AMT Systems" and the SCS has already detected the AMT machine but has not been able to finish the provision process. The machine is listed under "Intel AMT Systems" with status: "UnProvisioned".

The SCS log is showing the following:

2007-06-09 03:45:29,Incoming connection from 192.168.0.61:16994, version 2, count 13, uuid 0C3CC4969FB7DB11911900E018BFD7DC, Information, PRODUCCIONAdministrator,

2007-06-09 03:44:57,Exception while provisioning AMT: (119) Cannot contact back AMT with ip: 192.168.0.61, SeverityError, PRODUCCIONAdministrator,

2007-06-09 03:44:57,Provisioning AMT: 0C3CC4969FB7DB11911900E018BFD7DC,Information, PRODUCCIONAdministrator, 0C3CC496-9FB7-DB11-9119-00E018BFD7DC

(The last 2 lines keep repeating every 2 minutes)

I will appreciate any help on how to proceed to be able to finish the Provisioning for this machine.

Thanks
Maria

[virtual_walker]

Hello Maria,

I am also working on AMT setup and configuration but I am not using Intel SCS since the system requirements are too high. I am implementing my own using Intel AMT SDK. Based onthe description of the problem, it seems that your configuration server cannot establish a connection with your AMT device. The configuration server was able to receive the "Hello" message (The last 2 lines keep repeating every 2 minutes) but cannot start the configuration process. There arethree possible reasons why this happened. First, a firewall might be running on your server which prevents the SCS to send the configuration data on the specified port (make sure that the port on your server is open). Second, if you don't have a DHCP server the IP address of your AMT device (in this case: 192.168.0.61)might be the same with the IP address of the host PC, which should not be. Third, the preprovioning parameters set on the AMT device might be incorrect or incomplete which prevents the configuration server to establish the TCP/IP connection.

I suggest you install a packet sniffer on your configuration server and make sure that the TCP/IP handshaking is correct. You can download and install Ethereal (http://www.ethereal.com) for free.

[Gael_H_Intel]

Another thing that can happen is your DHCP server can change the IP address in the middle of the process - but based on your error messages, I don't think this is the case. Have you entered your FQDN (Fully Qualified Domain Name?) In the soon-to-be released SCS 3.0, the UUID comes over in the hello packet and then once you finish editing the system's info (by entering in the FQDN) the system can complete the process.(I am not sure about how the SCS 1.2 release does things.) Also, Virtual Walker suggests - check that firewall on your AMT client - if it's up, there will be no provisioning (I have a blog on this as it has bitten me quite a few times!)

[Maria_Camila_Gomez-S]

Thanks for your tips V.W. and Gael.

As a matter of fact I have ethereal installed and I have been using it to verify weather or not hello messages and communication between SCS and AMT machine is happening.

I can tell the two machines SCS and AMT are communicating, no firewall is enabled and of course DHCP service is running and mapping properly the AMT machine so SCS can reach 192.168.0.61 (AMT machine). SCS machine is NOT set to "provisionServer" in my DNS but the SCS IP address is set at the MEBx.

I know you are not working with SCS but anyway... here are the steps I have followed prior and during my provisioning process for this machine.

First I changed the default admin password for MEBx and provisioned the machine using Small Business, I was able to access the web admin console and also used Communicator from Intel's DTK.

Once we finished all our SMB testing I un-provisioned the machine, using Director (also from Intel's DTK), in order&; to start the Enterprise provisioning.

After installing SCS I created a profile and generated Security Keys which were printed and set into our AMT machine the provisioning mode was set to Enterprise and the provision server IP address and port were also entered.

After this I added the AMT Machine UUID to SCS in the "New Intel AMT Systems" list.

Once the machine was added the SCS received the Hello message and the Machine was automatically included in the "Intel AMT Systems" list with Status "UnProvisioned" (It keeps also appearing at the New Intel AMT Systems List)

The Log is registering every 2 minutes: "Exception while provisioning AMT: (119) Cannot contact back AMT with ip: 192.168.0.61, SeverityError" as shown at the original post.

When I created the profile and also within the MEBx settings for security keys generation I used the password that currently works for me when trying to access the MEBx panel, for the new password settings I choose the "Manual" Option and entered the same password.

I want to know if something is missing at my provisioning process using SCS and if there is a way to try to check my process without having to reset BIOS since I can not un-provision the system as is.

Any help will be appreciated

Thanks!
Maria

[Gael_H_Intel]

Hi Maria,

You mentioned above that:

SCS machine is NOT set to "provisionServer" in my DNS but the SCS IP address is set at the MEBx.

Page 52 of the "Intel AMT SCS Installation and User Manual" states the following:

The DNS must have information for two entities:The SCS Server must be registered in the DNS.A configured, operational Intel AMT device must be registered within DNS.

Intel SCS

Any platform running the SCS Service (the Main Service) must be registered in the DNS as ProvisionServer. This must be done in each DNS Domain. When it sends its Hello message, the Intel AMT device first uses the domain name received from the DHCP server. If there is more than one SCS in the domain, the DNS will alternate between the servers. If there multiple SCS instances or the server platform has a different name, then CNAME records need to be added to the DNS.

Intel AMT Devices

Ensure that the DNS is configured with the Fully Qualified Domain Names (FQDN) of the Intel AMT-enabled machines that are being configured.

Intel AMT devices must be configured to have the same FQDN as the host OS. This stems from the fact the Intel AMT device is not a secure DNS client and it relies on the host OS to maintain the DNS record. For this reason, the Intel AMT device snoops the DHCP requests and responses issued by the host OS. The Intel AMT device then uses the IP provided by the DHCP to the host OS as its own.

[adrianfreemantle]

Hi Maria,

This may be a simple test, but can you verify that you can ping the device? Try to reboot the client AMT system and let it enter windows. I have noticed that sometimes the Manageament engine is by default configured to be off when the client is off. This means that the AMT firmware is not "alive" when the system is off, usually this setting is updated when the system is provisioned.

Can you maybe specify what model your AMT client is and are you sure that the firmware is the latest available version, it is always worth looking into that as i have found that many "bugs" dissapear on my clients once i update the firmware.

[Maria_Camila_Gomez-S]

Thanks for all the help.

I included the provisionserver at my DNS and also check that my AMT machine FQDN is been included at DNS.

But nothing has changed.. the same 2 lines keep been registered...

I can ping to the AMT machine despite the power state. I can even telnet to port 16993 from the SCS Machine.

I am using a generic (Not branded) Box built with an Intel desktop Board DQ965GF and an Intel Pentium D CPU 3.0GHz processor.

My MEBx panel is integrated with the general BIOS access.
My current firmware version is: 2.0.5-build 1124

Maria

[virtual_walker]

The periodic reappearance of the error (the 2 lines that you mentioned) means that your configuration server has periodically received the "Hello" message from the AMT device but was unable to configure the device. An AMT in setup mode periodically sends a "Hello" message at an increasing interval until such time that the configuration server finishes configuration.

Based on my understanding of the problem, the configuration server has tried to configure your device but was not able to establish TCP/IP connection with your AMT device.
Are you using port 9971 on your server? If you are using port 9971, please verify using ethereal that there is a packet from (server)9971 > (client)16994. If you can see this packet, we can be sure that there is no hardware/software (windows firewall/officescan personal firewall) firewall running on your system. Look for these packets:

(client)16994 > (server)9971 SYN
(server)9971 > (client)16994 ACK

The second line is the acknowledgement packet.

If the SCS and AMT device were able to establish a TCP/IP connection, the next possibility is that the connection was established but the authentication of the PSK has failed. PSK stands for preshared keys which is composed of your AMT username, password, PID and PPS. Make sure that these parameters are stored in you SCS. I believe these are stored in the MS SQL express database.



I hope this helps:)

[Gael_H_Intel]

Hi Maria:

If this is the version of your firmware:

My MEBx panel is integrated with the general BIOS access.
My current firmware version is: 2.0.5-build 1124

Your BIOS Version would then be 5434, dated October 16, 2006. Since then there have been 12 updates.

The current version is: BIOS version 5882, ME firmware build: 2.1.3.1031 production signed, dated April 13, 2007

You might want to keep an eye on the following link:

http://downloadcenter.intel.com/Filter_Results.aspx?strTypes=all&ProductID=2372&OSFullname=OS+Independent&strOSs=38

I don't know if the trouble you are having with Provisioning has anything to do with the age of your firmware, but I think it is time you updated your system (there have been a lot of problems fixed in the last 12 releases)

[Maria_Camila_Gomez-S]

Thanks Gael and V.M.

The packets are being transmitted so I decided to reset the BIOS and restart the provisioining process just to make sure that the problem is not due to the security keys.

Of course I am going to update my firmware, I am a newbie with this BIOS stuff, thanks for all your tips.

I will let you know how it goes!

Maria

[Gael_H_Intel]

When you go out to that link to get the most current firmware, there will be directions on how to do it. It is actually very easy.Make sure you look through the Readme and Release files as well.

One thing that I have run into lately is that when I try to do the upgrade it gives me an error concerning privileges - there is actually a command documented where you run the upgrade program from a cmd window and you enter the ME username and password. Let us know if you run into this problem. I'm guessing that if the system is in an unprovisioned/factory state with the default password you may not have to do this.

Gael

[Maria_Camila_Gomez-S]

Hi Gael

As you mentioned I got the message: "This program is unable to continue. The user does not have permission to update the Intel Management Engine firmware"

so I followed the instructions to run the express BIOS update from the command line using:

CO96510J.86A.xxxx.EB.EXE -s -a force user admin pass password -s

• xxxx = BIOS revision number
• admin = Intel ME login name
• password = Intel ME password

as mentioned at:

http://support.intel.com/support/motherboards/desktop/sb/CS-025681.htm

But after pressing ENTER the application does not run. I tried other combinations (without the last -s, etc but despite the application runs I keep getting the same error)

Have you ever tried this?

Thanks!

Maria

[Gael_H_Intel]

Hi Maria,

I have used that command and it does work great. The only reasons why I would think that it might not work are as follows:

1. Are you logged on as "Administrator" or at least as a user with administrator privileges?

2. Your current board revision cannot be flashed with AMT 2.1 firmware. It looked to me like you were still running AMT 2.0. Does your system have at the minimum a C0 processor? If you are still on a B-stepping you will need an upgraded board in order to get to AMT 2.1 functionality.

If your problem is "2", then find the latestFirmware Buildin the archives link that is still 2.0.x - anyFirmware revision that has 2.1.x will apply to AMT 2.1.

[Gael_H_Intel]

Maria,

Here is some more reasons for the "cannot connect back to AMT" error:

• The current password of the security key entered to the MEBx doesnt match the MEBx password (most common reason).
• Duplicate DNS registration (two host names bind the same ip) .
• The SCS profile TLS PSK is configured to be plain text, the AMT machine doesnt support this.

I hope this helps!

[Maria_Camila_Gomez-S]

Hi Gael, thanks for all your tips.

Finally I found out the problem was due to the security program running at the AMT machine. Since running the Express Update from the command line does not shows the wizard, the update is run immediately and my program was locking the execution.

I was able to update, I did it first with an update prior to AMT 2.1 just in case to be able to go back since I was having some trouble with this process (I didn't know it was just the security program....)

Now I am going to update to the last version since I know that this is a very simple process.

Thanks again!

Maria

[Gael_H_Intel]

That's good to know Maria!

I have not experienced that since my systems are not on any external networks and therefore the first thing I do is disable the virus protection programs and the Firewall!

Thanks for sharing!

[virtual_walker]

A security program on the AMT machine?! I think this is surprising since no software (firewall or antivirus) can block AMT since it is snooping on the ethernet card.

[Maria_Camila_Gomez-S]

Hi V.W.

Maybe there is a misunderstanding.

I had a problem with provisioning using SCS, while looking to my case Gael suggested to update my firmware since I had a very old version and I had some trouble updating the firmware due to the security program that was locking the BIOS Express Update when it was run using the command line including AMT credentials.

Once the security program was uninstalled I was able to update my firmware using Express Update to version 5595. I was not able to update to a higher version through Express Update so I used the "ISO Image BIOS Update" method to update to version 5882.

After updating the firmware I have not tested the enterprise provisioning using SCS again.

So the security program was just locking the Expres Update command.

Maria

[virtual_walker]

Ooops...i see...I got it wrong. I stand corrected.