Got errors when using scs console to discover vPro clients

[idata]

We are using SCS to work with HP's Client Automation 7.9 for vPro management.

After going through the steps to update the Intel vPro client wiht new Intel MEBx passwors and valid PID-PPS security keys, the client computer automatically authenticate itself with the provisoning server.

The client platform is provisoned and showing in the scs console as "Not Configured" with a UUID. We edited the platform and added FQDN, AD OU and profile. The device would remotely provision fine with a green icon after that. We right-click the platform and click "Authorize AMT". After a while, the following errors started to appear in the log:

Error Setting Configuration Window of Opportunity: Missing mandatory parameter: pid.

Error Configuring Intel AMT device: Failed Setting ACLs.: AMT Connection Error: SOAP Error [14]: "setACLs::RemoveUserAclEntry: SOAP Unknown error".

The provisoning status was also changed to error icon with a slash. We could not discover tjhe client device in HP Client Automation.

Is there anything wrong or missing about above steps? It is really frustrate!

[Bruno_Domignues]

Hi Peng,

Can you set your SCS for verbose mode and send to us the log of machine, since provisioning until you get the error?

Best Regards!

--Bruno Domingues

[idata]

Attached the full log as well as a screen capture for the vPro device platform in SCS console.

[Bruno_Domignues]

Peng,

Based on your logs, as you described the problem happens during provision phase and abort on updating ACLs:

ERROR!Error Configuring Intel AMT device: Failed Setting ACLs.: AMT Connection Error: SOAP Error [14]: "setACLs::RemoveUserAclEntry: SOAP Unknown error".DebugSetting ACLs.DebugSetting 802.1x in S0.DebugSetting environment detection.DebugClear 802.1x wired profile settings.DebugSetting enabled interfaces.DebugSetting TLS options.DebugSetting Ping responseDebugSetting Domain name to devlocal.local.InformationSetting the Host name to hp-radia.DebugSetting Network parametersDebugSynchronizing Intel AMT device clockDebugUpdating Intel AMT device RNG key

As I can see in your printscreen, you are using AMT 3.0.1 and one possible cause can be mismatch of SCS ACLs for newer vPro features, in this case I would suggest you define in your profile only "admin" account with PT administration rights in order to make sure that is the case.

I would suggest also, update your AMT firmware for the newest version available.

Best Regards!

--Bruno Domingues

[idata]

Hi Bruno,

Thanks for the help!

Based on your suggestion, I removed other user except for the built-in "admin" account with PT administration. After that, the old "setacls" error disappears. However, we are getting the following error message now:

4171

ERROR!

Error Configuring Intel AMT device: AMT Connection Error: SOAP Error [24]: "commitChanges: Fault: 'Timeout' : Details: 'connect failed in tcp_connect()'".

4/1/2011 9:12

17410FFB-A956-11DC-BBDA-FE9DD0E9000F

2202

DEVLOCAL\Localadmin

SATLITE78

4171

Information

Committing changes.

4/1/2011 9:12

17410FFB-A956-11DC-BBDA-FE9DD0E9000F

780

DEVLOCAL\Localadmin

SATLITE78

hp-radia.devlocal.local

4171

Warning

Failed Setting TLS PSK: AMT Connection Error: SOAP Error [24]: "setTlsPsk: Fault: 'Timeout' : Details: 'connect failed in tcp_connect()'".

4/1/2011 9:12

17410FFB-A956-11DC-BBDA-FE9DD0E9000F

2205

DEVLOCAL\Localadmin

SATLITE78

hp-radia.devlocal.local

4171

Information

Generating a new PID/PPS pair.

4/1/2011 9:11

17410FFB-A956-11DC-BBDA-FE9DD0E9000F

862

DEVLOCAL\Localadmin

SATLITE78

hp-radia.devlocal.local

4171

Warning

Failed Setting MEBx password: AMT Connection Error: SOAP Error [24]: "setMEBxPassword::GetAdminAclEntryStatus: Fault: 'Timeout' : Details: 'connect failed in tcp_connect()'".

4/1/2011 9:11

17410FFB-A956-11DC-BBDA-FE9DD0E9000F

2205

DEVLOCAL\Localadmin

SATLITE78

hp-radia.devlocal.local

4171

Warning

Failed Setting power policies.: AMT Connection Error: SOAP Error [-1]: "setPowerOptions: SOAP Unknown error".

4/1/2011 9:11

17410FFB-A956-11DC-BBDA-FE9DD0E9000F

2205

DEVLOCAL\Localadmin

<td nowrap="...

[Bruno_Domignues]

Person Peng,

Have you tried upgrade the firmware? Just for debugging purpose I would like to recommend you upgrade to latest firmware version:

http://support.dell.com/support/downloads/download.aspx?c=us&cs=555&l=en&s=biz&releaseid=R255852&SystemID=PLX_PNT_P4_755&servicetag=&os=WLH&osl=en&deviceid=15256&devlib=0&typecnt=0&vercnt=12&catid=-1&impid=-1&formatcnt=0&libid=1&typeid=-1&dateid=-1&formatid=-1&fileid=375394 DELL BIOS A16 with firmware version 3.2.20

http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=12454&prodSeriesId=3459241&prodNameId=3459245&swEnvOID=2105&swLang=13&mode=2&taskId=135&swItem=vc-83192-1 HP firmware version 3.2.20

http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-74750 Lenovo firmware version 3.2.20

Do a full unprovision and try it again, from this point there is no reason to not work.

Best Regards!

-- Bruno Domingues

[idata]

Hi Bruno,

Unfortunately, we are still getting errors after upgrading the firmware. See attached for the logs and screen shot. Is there anything else I am missing?

Regards,

Pearson Peng

[Bruno_Domignues]

Peng,

As far I can see you moved to n-1 problem:

7884ERROR!Proper certificate that matches the pre loaded certificate was not found in the user certificate store. PKI configuration failed.7884ERROR!Error Configuring Intel AMT device: Failed to connect to un-configured Intel AMT device at IP 16.178.123.22: Proper certificate that matches the pre loaded certificate was not found in the user certificate store. PKI configuration failed.

SCS is claiming that didn't find the proper certificate in ME. Are you using PKI mode with internal certificate? probably you should inject the hash again into the ME.

Best Regards!

--Bruno Domingues

[idata]

Hi Bruno,

I am Pearson's colleague.At first thanks for your help.

You said the error was we used the PKI mode, in fact the error log was happened when we deleted the PID and PPS. When We set new PID and PPS ,the same error log was reappeared.This is the new log information.

Best Regards!

Giggs Song

[idata]

Latest update is after using static IP addresses on both sides, we finally provision the vPro client in SCS successfully. However, we encountered a problem in HP Client Automation. The client is shown in "vPro Provisioning", but it cannot be found using Device Discovery Wizard in HPCA.

Attached serval screen captures for the issue. Is there any idea about the issue?

[Bruno_Domignues]

Giggs,

It's looks like a network issue, looking into log I can find this entry multiple times:

ERROR!Error Configuring Intel AMT device: Failed to connect to un-configured Intel AMT device at IP 16.178.123.22: AMT Connection Error: SOAP Error [25]: "getFullCoreVersion: SOAP Unknown error".

and also:

DebugThe SOAP connection with connection parameter set # 16 failed: AMT Connection Error: SOAP Error [24]: "getFullCoreVersion: Fault: 'Timeout' : Details: 'connect failed in tcp_connect()'".

Some ideas to fix it:

- Disable Windows Firewall;

- Check if you are able to ping vPro machine from console, using IP address and FQDN, and that FQDN reply match with IP address;

- Check if you are able to open connection to vPro machine in 16992 or 16993 port: from console open a telnet (e.g. telnet IP_address 16992);

At the end, vPro machine should be accessible from console using FQDN onto 16992 or 16993 port, if not you may face this kind of problem.

Best Regards!

--Bruno Domingues

[Bruno_Domignues]

Peng,

It looks like you have name resolution problem in your network. Do you have these machine's FQDN with alias in DNS? are you able to query this machines using FQDN?

Best Regards!

--Bruno Domingues

[idata]

Hi Bruno,

I have confirmed that the machine's FQDN with alias provisionserver exists in DNS. I can nslookup the machines using both host names and FQDN.

The latest update is that after adding a digest user in the profile in SCS console, the client vPro device is discovered in Device Management in HP Client Automation. However, when we click on the vPro device to manage it, the following error pops up:

"Error: Unable to retrieve information for the selected device.

The possible cause could be the device is not available in network."

Attached the zipped screen captures and the stdout log file.

[Bruno_Domignues]

Hi Peng,

It's looks like that the root cause is your network, I would suggest you run the /docs/DOC-5582 DiagTool on your server and also on your vPro machine in order to check the connectivity and dependecy.

The DiagTool generate a report, you can post here in order that we can identify the problem.

Best Regards!

--Bruno Domingues

[idata]

Hi Bruno,

We decide to use PKI mode to provision the vPro client device and set up another testing environment with only two computers in a private network. We will not pursue the original issue. Thanks for the help!

[Terry_C_Intel]

The nature of the errors with tcp_connect() indicates the network interface of the management engine is closed or disrupted during the configuration process. A number of items could cause this to happen. Outdated firmware, incorrect domain setting in the configuration profile, etc.

After reading through the replies and some of the attachements shared - I am curious to know what the AMTdiag tool results were for your environment among other items.

Please ensure the BIOS\firmware is updated on the client. The Intel AMT firmware specifically should be above 3.2.x for this particular system.

What is the "domain" in your configuration profile? This setting should align to the DHCP option 15 on the network segment.

You appear to be using Intel SCS 5.x. What exact version? (check "AMTconfig" in windows servers, or click on Service Status within the Intel SCS console)

[Terry_C_Intel]

Take a look at /community/openportit/vproexpert/blog/2011/04/29/troubleshooting-tcpconnect-wsman-soap-and-related-intel-amt-connectivity-errors http://communities.intel.com/community/openportit/vproexpert/blog/2011/04/29/troubleshooting-tcpconnect-wsman-soap-and-related-intel-amt-connectivity-errors

Based on the sequence of events using PID\PPS - where the setting of the ACL failed yet other setting succeeded - I suspect there is an incorrect setting in the configuration profile. It's a guess. If you follow the steps shared in the above article - this will provide some definitive answers.

Hope that helps.