WebUI takes two times to connect and authenticate

[idata]

We have WebUI up and working. However, we're seeing a weird quirk happening. Sometimes, when we connect to the WebUI on a desktop (AMT v6.0) we can see the WebUI log in page and click the log in button and authenitcate quickly. Othertimes, we do the same thing and it doesn't connect, then we have to try again and wait about 30 seconds (estimated) and then it connects.

I know there should be a simple answer to this, but I don't know how to diagnose or review logs to find it.

Ideas?

[Bruno_Domignues]

James,

Probably, you configured your ATM to sleep when idle, choosing one of these options (see attached print screen from webui) it can reduce the power consumption even more.

Desktop: ON in S0, ME Wake in S3 

Desktop: ON in S0, ME Wake in S3, S4-5

If you switch to Desktop: ON in S0, S3, S4-5

You problably won't face this behavior

Best Regards!

--bruno

[idata]

All I see are the following 2 options on the Dell Optiplex 980 machines we have.

Desktop: ON in S0

Desktop: ON in S0, ME Wake in S3, S4-5

The On in S0, ME Wake in S3, S4-5 is checked.

[idata]

Update, so far James W. has written an application to resolve most of the problems with Reboot, Turn On and Turn Off commands without having the user to log in by hard coding a local user account in AMT. When trying to utilize the Kerberos method, we've notices it's a hit and miss with being able to connect to the machine. After further research, we're coming to a conlusion about the kerberos issue and we feel it's not something to do with the network or how certificate services are configured. Instead it's something with the code in the AMT chipset and how it's trying to interact with Kerberos. With this application, James W. added the option to utilize Kerberos or not. With Kerberos being an option, we're able to conclude without Kerberos interaction there is 100% functionality.

In conclusion, as of right now, if we create a local account through the WEBUI and utilize his program, it works perfect. However, once an update is pushed from SCCM, it overwrites the local memory and erases the local account which was created manually.

The Million Dollar questions are, How do we create a local account on the AMT chip either through SCCM or another product? And if we have to do it through a seperate product or script, then is there a way to have that automatically update when an update is pushed from SCCM?