Intel® Software Network

I've been following the 'tips and tricks' pages, and documents and as far as I can tell I've set up AMT/ME on the client BIOS correctly, but I can't get either a web browser or tools from the DTK to connect to the machine.

I've triple checked the new password I've set in the ME bios on the machine, and I've set it to DHCP and ensured it has the correct host and domain name. I get the logon page from the machine via a web-browser when it's powered down (so this is not dependant on Windows drivers/firewall, etc.) - but my password is always rejected.

The AMT tools show the client attempting to connect with HTTP, followed by the error message: 

System.Net.WebException: The remote server returned an error: (401) Unauthorized.
   at System.Net.HttpWebRequest.GetResponse()
   at IntelAmtStack.WsManDirectClient.LoadXmlEx(String postData, Boolean& shouldRetry)

Followed by another attempt to talk via https followed by the error:

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

I can't access the machine via https on a browser at all. The username I'm using is 'admin'. I'm assuming this is correct as it should be the default, but I can't find this specified in the machine anywhere.

There are a set of options in the BIOS regarding 'Virtual applicances'. I'm not sure what they are. They're not familiar to me from last time I fiddled with AMT six months ago, and aren't mentioned in any of the quick setup guides I've read. Any idea what I'm missing or am forgetting to do?

Thanks

Dave

Hi,

Can you see the log on window when you use the webUI from a remote machine?

"admin" is the default account with MEBx and that should be the user name that you use for logging in to the system. make sure that you have typed in your password correctly (check if your CAPS LOCK is ON). If you are seeing the log on window and are using "admin" username and your current MEBx password, you should be able to log in.

BTW, Please visit Gael's Blog on guidelines for creating a strong MEBx password at http://softwareblogs.intel.com/2007/11/08/strong-amt-me-passwords-and-other-shades-of-gray/

You don't have to set any Virtual Appliances option for setting up and connecting to your AMT system.

Thanks,

Sree

Yup, no problem getting a logon prompt via http when the machine is turned off.

Passwords I've tried include (anagrams of):    E1n#Ec3gle7   and  S200jlp!  (which another post on here describes as working for them).  Both of them ended with teh same behaviour as described.

I've double checked I'm typing the password correctly. If I completely reset the defaults, would 'admin' work as a  username/password combo work?  I suspect not, as it wouldn't be in SMB mode, or have DHCP or the hostnames set.

Stumped...

Dave

Hi,

What about when your AMT system is turned ON? Can you see the log on page using WebUI from a remote system?

admin is the default username and password for the system and you have to change it while provisioning it in SMB mode.

Thanks,

Sree

Yup - same behaviour when it's turned on or off. Same error codes and output, regardless of whether IAC is run as a local administrator or normal user. I've changed the admin password several times to no avail - can't get anything remote to recognise it - (or admin/admin either).

Stuck.

Hi,

Could you do a CMOS reset and try this again?

For this, disconnect the power cord and LAN cable. Remove the CMOS battery for 15 secs and insert it back in. This time when you power on, ME settings will revert to factory defaults. The default user name and password is admin/admin. Change it to a strong password before configuring the ME further.

Thanks,

Sree

It reset the ME settings, and re-created a different, strong password - but it hasn't made any difference to the problem.

Below is the debug log from AMT Commander if it helps. I've asterixed out the password and hostnames

---

--- 11:19:33:Event:***** changing state to Connecting
--- 11:19:33:Event:NetworkCredential HTTP Digest: admin, *****

--- 11:19:33:Event:Service Setup: http://*****:16992/SecurityAdministrationService
--- 11:19:33:CallAttempt:GetCoreVersion

--- 11:19:34:CallWarning:GetCoreVersion
--- 11:19:34:Event:NetworkCredential HTTP Digest: admin, *****
--- 11:19:34:Event:Service Setup: http://*****:16992/GeneralInfoService
--- 11:19:34:CallAttempt:GetCoreVersion

--- 11:19:35:CallWarning:GetCoreVersion
--- 11:19:35:Event:NetworkCredential HTTP Digest: admin, *****
--- 11:19:35:Information:Get: AMT_ThirdPartyDataStorageService
--- 11:19:35:CallFailed:http://*****:16992/wsman
<?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsman="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" ><s:Header><wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action><wsa:To>http://*****:16992/wsman</wsa:To><wsman:ResourceURI>http://intel.com/wbem/wscim/1/amt-schema/1/AMT_ThirdPartyDataStorageService</wsman:ResourceURI><wsa:MessageID>uuid:ebecda46-5cd8-4d17-a6f1-7b09c9066c38</wsa:MessageID><wsa:ReplyTo><wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address></wsa:ReplyTo></s:Header><s:Body></s:Body></s:Envelope>
--- 11:19:35:Error:System.Net.WebException
System.Net.WebException: The remote server returned an error: (401) Unauthorized.
   at System.Net.HttpWebRequest.GetResponse()
   at IntelAmtStack.WsManDirectClient.LoadXmlEx(String postData, Boolean& shouldRetry)
--- 11:19:35:Event:NetworkCredential HTTP Digest: admin, *****
--- 11:19:35:Event:Service Setup: https://*****:16993/SecurityAdministrationService
--- 11:19:35:CallAttempt:GetCoreVersion

--- 11:19:35:CallWarning:GetCoreVersion
--- 11:19:35:CallFailed:GetCoreVersion
--- 11:19:35:Error:System.Net.WebException
System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
   at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.CheckCompletionBeforeNextReceive(ProtocolToken message, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
   at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)
   at System.Net.TlsStream.CallProcessAuthentication(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
   at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at System.Net.ConnectStream.WriteHeaders(Boolean async)
   --- End of inner exception stack trace ---
   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at SecurityAdministrationService.Invoke(String methodName, Object[] parameters)
--- 11:19:35:Event:***** changing state to Disconnected

Ok, I am going to take another wild guess as this problem. Is your english keyboard QWERTY in Windows? If it is not, be aware that MEBx thinks that your are typing on a QWERTY keyboard and if you are in an OS that has a different keyboard mapping, the password will not match. I also have a small trick: Go in MEBx and try to change the computer's network name. In that box, type in your password and take a look at what shows up on the screen. You may not be typing what you think you are typing.

That's all I can think of right now. Let me know what you see.
Ylian (Intel AMT Blog)

---

Ylian Saint-Hilaire
Senior Lead Developer
Intel Corporation

Doh! Yes, it's qwerty...But it's a British english keyboard, so the # is in a different place to a usian keyboard, which is what the BIOS thinks is plugged in.. I dunno, bloody Americans..... 

Thanks!

Does this mean that Ylian was right?  Again?  How many does that make now?  Sheez.

---

--Gael
My Blogs

Actually, the "Royal" WE would like to understand this in more detail.  If this is indeed a keyboard issue, then why aren't more AMT developers having issues with this, as most of the developers on the forum seem to be outside the US and are most likely using non US keyboards?

---

--Gael
My Blogs

Possibly because most of the allowed punctuation isn't affected by the problem? Or because their languages are sufficiently non-english they have localised BIOSes that map their keyboards more correctly than the more subtle difference between the left and rightpondian varieties we use.

Thanks again,

Dave

I have to start more posts with "this is a wild guess but..." it seems to work for me. I did suspected your had a QWERTY keyboard, but I come from French Canada and our key mapping is slightly different than the US standard to allow for french accents. Same goes for Mexico, etc. French keyboards have a very different mapping.

Yes, this is a problem. MEBx like the BIOS are simply not aware of how the keys should be mapped. There is not BIOS option for entering the keyboard mapping to use. During Windows setup, it's one of the first thing that is setup, but americans often don't notice this.

To my knowledge, there is no plan to fix it. In enterprise deployments, it's not an issue since you don't use MEBx to setup anything (in most cases).

Ylian (Intel AMT Blog)

---

Ylian Saint-Hilaire
Senior Lead Developer
Intel Corporation