- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Attached the full log as well as a screen capture for the vPro device platform in SCS console.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 keyAs 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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="...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page