I wonder if this is related to the token size issue. Perhaps as a troubleshooting step, you could create a new domain user account, and add this only to your vPro management group? Then, try to connect with this account and see if you are successful on a consistent basis.
Are you able to connect with the Microsoft OOB Console? If not, to enable additional logging, go to: <ConfigMgrInstallPath>\AdminUI\bin\oobconsole.exe.config, and change this line:
<source name="OOBConsole" switchValue="Error">
<source name="OOBConsole" switchValue="Verbose">Then, open up <ConfigMgrInstallPath>\AdminUI\Logs\oobconsole.log and seek out the appropriate date/time & error message.-------
Since we are in post-provisioning here, the infrastructure bit is lower on the priority list of issues. Rather, we should be troubleshooting this from a client (browser) --> server (vPro client) issue. Just wanted to note that in the discussion
Consultant | 1E Inc.
Thanks for your tips, unfortunately they didn't help yet:
- The token size is definitely no problem (tokensz reported 1757, 2343 in base64)
- The same account works on some computers (of the same type and firmware version)
The OOBConsole log shows some error about access denied (0x19 in Intel terminology and 0x80070005 in MS terms). However this isn't conclusive as there is no reason to deny access. I found a MS KB article with these error codes, but it doesn't apply (only for SP1 and the userAccountControl as well as servicePrincipalName on all accounts are the same).
Anyway, I attached the OOBConsole logs of three computers:
- WS86: IE just displays "cannot display this page" after pressing logon
- WS94: Works flawlessly
- WS100: IE presents a logon prompt after pressing logon (my credentials don't work of course)
Based on a post in the MS forums I tried to reprovision the machine that just disconnected in IE (WS86) - this worked. But I'd rather avoid reprovisioning the whole company - especially as I know that I tried this before an a currently failing machine, so the problem would reappear. And not to mention that powering on/off using SCCM always works...
That whole thing just doesn't make any sense.
It sounds like you may be seeing a knwon issue with earlier versions of AMT firmware and Kerberos authentication that can occur every 25 days. This issue has been resolved in the latest firmware which you can obtain from the OEM's that you purchased your systems from. I recomend you try updating your firmware to see if that resolves the issue.
Thanks for the tip, I'll try updating the machines that aren't on the newest release.
I think some of the machines already have the newest firmware and are still experiencing the issue while others which have an old firmware for sure are working reliable.
Is there a document or the sort with more information about this bug?