I have been paying attention to console operation logs after reapplying configuration and I'm interested in undestanding this one:
Date and time: 9/18/2007 10:43:35 AM
Error Code: 2202
Server name: TFSRTM
User name: AMTadmin
Platform UUID: 92CF7A0B-094A-DC11-9622-00E018889BFA
Operation ID: 471
Description: Error Configuring Intel AMT device: Failed to connect to configured Intel AMT device at FQDN LINTVPRO-PC.AMT.LOCAL: AMT Connection Error: SOAP Error : "getFullCoreVersion: Fault: 'No Data' : Details: 'get host by name failed in tcp_connect()'".
The AMT device is configured OK, but I can see error logs likeone above andI can notaccess it by itsWeb UI (and of course it's Web UI profileenabled),so I think these issues are related each other.
This looks like it's not able to resolve the FQDN (LINTVPRO-PC.MT.LOCAL) correctly. If you ping that FQDN, can you find it? You could also try connecting to the web interface with IP addressinstead of FQDN, if that works then SCS isn't resolving the FQDN correctly.
This could be related to configuring the DHCP server to handle DNS registration of the AMT device, there's documentation about this starting at the bottom of page 104 in the SCS Installation guide (Edit: I forgot to add the title of the section, it's "Registering Intel AMT Devices in the DNS")
Sorry I didn't reply sooner Javier, we just changed forums and I initially lost my e-mail updates that there were new posts.
It sounds like SCS wasn't able to fully provision the system, if "Delayed" is showing up in the status. If SCS got the hello packet, but wasn't able to get back to the system to finish the configuration (if there were DHCP problems this could happen), it wouldn't be fully configured. That would explain why the WebUI for the system isn't coming up, since until the AMT system hears back from SCS (or some other configuration server), it's not provisioned yet. One option is that you clear the system out of SCS and reprovision. You could either put Activator on the system to kick off hello packets again, or reset and reconfigure the AMT system.
The other possibility is that something isn't set right in the AMT system that is preventing SCS from connecting. How did you initially setup the AMT system for provisioning? Did you use a USB key, or did you manually enter data into the ME? For either option, could you tell me what options you set when you were configuring the AMT system?
Hmm, possibly. Is SCS attempting to use the default profile? The reason I ask is that WebUI is enabled in the default profile. I find it very suspicious that SCS is finding the system initially, but then not only does the WebUI not work, but you also can't reapply changes.
Do you always have this behavior with the AMT system you're configuring? Or have you configured and had the WebUI work?
Thanks for your reply. We have solved this issue by disable the DHCP in AMT machine Bios and setup a static one.
Now the machine looks configured in SCS Console but when I tried to access to WebUI with Admin Password shown in properties tab of platform settings window I got this error: "
I also tries with MBex password with same result (but when I tried locally in bios it works).
I misinterpreted what you said Javier, I thought you meant that the WebUI wasn't working at all, not that you were getting a login failed when you tried to connect. So it sounds like things are better off than I thought.
Back to my question about the profile that SCS used, were you using the default profile, or did you create your own? And if you were using the default profile, was the WebUI still installed? Given that you're getting a log on failed message, I believe the WebUI is enabled, but I wanted to confirm.
I think we've replicated the behavior you're seeing in our lab, I'll look at it in more detail this afternoon and see if I can figure out what's going on.