Cannot use AMT WebInterface or SCCM OOB Console

[idata]

Hi

I am unable to use the Web-Interface or the Out Of Band Management Console of SCCM.

WebUI

I can connect the UI using the URL https://ws94.mydomain.ch:16993 and get to the page with the blue banner and the "Log On..." -Button. When I click Logon, the prompt appears, but no matter which combination I try, it fails.

• SCCM has a group (mydomain\domain admins) and a single user (mydomain\amt) configured under "AMT Settings"; all features are selected
• • Neither the domain-admin nor the single user gets access (I'm 100% sure that I typed the passwords correctly)
  • The MEBx account also fails (admin:admin or admin:the password specified in SCCM)

Connecting from a browser outside the domain shows an (expected) certificate warning, and then the login dialog (see attachment). None of the logins are accepted.

I saw similar questions in other threads, so I already ruled out a few things:

• SCCM has the correct permissions in the Active Directory OU (the AMT computer object exists, and it gets updated/a new timestamp when I select "Update provisioning data in Management Controller Memory")
• There is no certificate failure. I can open the SSL/TLS secured website without a warning on any computer that is joined to the AD domain. In the certification authority I see the issued certificate for the client.
• There is no time difference between the client and the server (at least the Windows-Clock says so)

OOB Console

When I open the console on my provisioned client, in the bottom left corner it says "connecting" then "disconnected". As long as the console is open, it repeats the line [6][25.03.2009 15:29:05] :GetAMTPowerState fail with result:0x80070035 in the logfile OOBConsole.log.

I already saw this thread (http://communities.intel.com/openport/thread/1592), but it didnt't help or apply to my situation.

Any ideas?

Best regards,

Ingo

[idata]

Hello,

Sorry I didn't see this thread earlier, even though I asked you to create it I had a really busy day at the office today, and didn't have a chance to look at stuff much past the morning.

Anyway, the thread you linked to didn't work, so I'm not sure what it is you tried in order to resolve your issue.

Please try out this document: http://support.microsoft.com/kb/908209 http://support.microsoft.com/kb/908209. Although the hotfix itself is for Internet Explorer 6, the registry key fix applies even if you are running Internet Explorer 7 or 8.

For 32-bit computers

loadTOCNode(3, 'moreinformation');

1. Click Start, click Run, type regedit, and then click OK.
2. In the left pane, locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl
3. On the Edit menu, point to New, and then click Key.
4. Type FEATURE_INCLUDE_PORT_IN_SPN_KB908209, and then press ENTER.
5. On the Edit menu, point to New, and then click DWORD Value.
6. Type iexplore.exe, and then press ENTER.
7. On the Edit menu, click Modify.
8. Type 1 in the Value data box, and then click OK.
9. Exit Registry Editor.

For 64-bit computers

loadTOCNode(3, 'moreinformation');

1. Click Start, click Run, type regedit, and then click OK.
2. In the left pane, locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Internet Explorer\Main\FeatureControl
3. On the Edit menu, point to New, and then click Key.
4. Type FEATURE_INCLUDE_PORT_IN_SPN_KB908209, and then press ENTER.
5. On the Edit menu, point to New, and then click DWORD Value.
6. Type iexplore.exe, and then press ENTER.
7. On the Edit menu, click Modify.
8. Type 1 in the Value data box, and then click OK.
9. Exit Registry Editor.

I hope this helps you out

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Hi

I appreciate your help any time you write it. In my time zone it's now 7:40 AM, so I wouldn't have seen your earlier anyway.

The Registry-Key fixed the problem with the Web-Interface. Many thanks for this hint

I still cannot access the Computer through SCCM's OOB Console though. Any ideas on this one?

Ingo

Edit:

P.S: The link to ther other thread still works, maybe you got the closing paranthesis into the URL.

/thread/1592 http://communities.intel.com/openport/thread/1592

[idata]

Hello,

I'm glad to hear you got the WebUI working

Are you connecting with the OOB console from the site server, or a different system? If it's a different system, I would recommend installing KB 960804 (the same one you installed on your site server) on the client with the ConfigMgr console.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Hi

I tried connecting from the site-server.

Meanwhile I found the problem. The Resource-Records of SCCM contains two Discovery Data Records for "Resource Names". The first one is "WS94" and the second one is "WS94.mydomain.ch" (without quotes). So now the OOBConsole.exe tries sends a query to the site server with Resource ID and accesses the first index of the "Resource Names" data hardcoded. Obviously a connection to this name will fail because of a certificate mismatch. I patched the OOBConsole.exe binary using the .NET Reflector and the Reflexil-Plugin to use the array index 1 instead of 0 and it connected successfully after this hack.

The buggy code is in OOBConsole.exe, Type Microsoft.ConfigurationManagement.AdminConsole.OobConsole.Utilities.QueryManager, method GetAmtByResourceID(string resourceID).

And this is the line that causes the mismatched access:

properties.FQDN = ((obj3["ResourceNames"].ObjectValue != null) && (obj3["ResourceNames"].StringArrayValue.Length > 0)) ? obj3["ResourceNames"].StringArrayValue[0] : string.Empty;

In my lab, I only have one Resource Names-Entry. But the lab machines were set up manually, whilst the production machines were set up using SCCM's OSD feature. The Resource Records were created using the WDS PXE Filter script from the WDS.

So. This leaves me to the question: Is it a failure to have two resource names, or is it a failure of the OOBConsole not to use the entry that contains the FQDN? Obviously it knows that there can be multiple entries, hence the array access.

Ingo

[idata]

Good job, and nice find! So, you're a .NET coder like myself?

In order to get an answer to your question, I think you'll have to ask Microsoft's developers

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Hi

Yes, actually I'm a software developer. System management is kind of a part time job that has to be done.

Could you just do me a last favor and take a look into your SCCM and tell me how many "Resource Names" entries you have on your client entries?

Getting in contact with Microsoft without signing a bunch of expensive contracts seems to be next challenge I'm facing now...

My finding might be worth an entry in the SCCM/vPro FAQ as I'm not the only one experiencing this error (see a few threads below created by Sandy Wood). I'll post back if I get any news/information from Microsoft.

Thanks anyway,

Ingo

[idata]

Hello,

Yes, I'll try to remember to check the resource names field for you in the morning, when I get to the office. If you don't hear from me, feel free to shoot me an e-mail reminder, but I usually check out the VPEC for new content a few times a day.

I can edit the SCCM/vPro FAQ also, so I can add an entry for you, for this issue. Could you get me the details from your OOBconsole.log when you were having the issue, so that I can include this in the root cause section?

Thanks for all of your quick responses in this thread, by the way. I'm glad that there is another community member who is regularly checking out and participating in this discussion forum. I hope I've been helpful to you, even though you solved your issue yourself!

Edit: Also, I just noticed that you said you were using the PXEfilter.vbs script to create the resource records using ConfigMgr OSD. Have you looked through this script to see exactly how it's creating the ConfigMgr resource records, and what looks different about how it's creating them vs. manually installing the ConfigMgr client? I am wondering if it (the script) enters the hostname only, because it can't necessarily assume that the machine is going to be a domain member.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Hi

Yeah well, it wouldn't make much sense to post here and then forgetting to look for your answers...

Usually my problems are already solved by someone else, so I'm just a reader. But with this vPro stuff I came to a dead end. And of course you have helped, you solved/directed me to the solution of the WebBrowser issue

The OOBConsole.log keeps repeating this line in the log:

[6][26.03.2009 11:53:13] :GetAMTPowerState fail with result:0x80070035

If the logging level in OOBConsole.exe.config is switched from "Error" to "Verbose" you can see the line

Resouceid(100).get AMT machine: name:WS94;ip:WS94;user:mydomain\myuser

The ip in this line should be the FQDN, so this led me to the failing code fragment.

The PXEFilter.vbs creates the SCCM resource as follows (the full script is attached):

Set oSite = oSMS.Get("SMS_Site")

Set oParams = oSite.Methods_.Item("ImportMachineEntry").inParameters.SpawnInstance_() oParams.NetbiosName = sNetBiosName oParams.SMBIOSGUID = sUUID oParams.MACAddress = sMacAddress oParams.OverwriteExistingRecord = false

I really don't know how to compare this to a manually created record, in fact you could call me a SCCM newbie/dummy. My first impression is that it doesn't create a Resource Names entry at all, so maybe SCCM automatically adds it during the creation of the record based on the NETBIOS name.

Ingo

[idata]

Thanks for the information. I'll post this to the FAQ.

FYI, I only have a single item in the Resource Names array. This contains the FQDN of the machine, not just the hostname. I would suggest that this is a bug in the OOBconsole.exe since AMT requires the FQDN for certificate validation, as you've already noted.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation