SCCM SP1 / WS-Trans & AMT 2.6.3

[idata]

I'm having a provisioning problem with the following setup:

• Dell Latitude D630C - BIOS A08 - AMT 2.6.3
• Microsoft System Center Configuration Manager (SCCM) Service Pack 1
• Intel WS-MAN Translator version 1.0 Build 552 (aka. version 1.1)

I am able to successfully provision an AMT 3.2.1 and AMT 4.0 system, so I believe that my issue is related to the AMT 2.6 platform, and the Microsoft hotfix from http://support.microsoft.com/kb/959040 KB article 959040, entitled "System Center Configuration Manager 2007 Service Pack 1 systems cannot provision AMT 2.2/2.6 clients in PKI mode and AMT 2.1/2.5 clients in PSK mode"

• I have verified that the IIS SSL Certificate on the Default Website matches the certificate configured in the Translator and in the ConfigMgr OOB (out-of-band) service point component configuration.
• From the OOB service point: A (forward) and PTR (reverse) DNS records are correct for the vPro client

Here is some of the amtopmgr.log provisioning log:

>>>>>>>>>>>>>>>Provision task begin<<<<<<<<<<<<<<<<p> 

Provision target is indicated with SMS resource id. (MachineId = 62134 vproclient.vprodemo.com)Found valid basic machine property for machine id = 62134.Warning: Currently we don't support mutual auth. Change to TLS server auth mode.The provision mode for device vproclient.vprodemo.com is 1.Attempting to establish connection with target device using SOAP.Found matched certificate hash in current memory of provisioning certificateCreate provisionHelper with (Hash: -------------------------------------------)Set credential on provisionHelper...Try to use provisioning account to connect target machine vproclient.vprodemo.com...Server unexpectedly disconnected when TLS handshaking.**** Error 0x710b924 returned by ApplyControlTokenFail to connect and get core version of machine vproclient.vprodemo.com using provisioning account # 0.Try to use default factory account to connect target machine vproclient.vprodemo.com...AMT Provision Worker: Wakes up to process instruction filesAMT Provision Worker: Wait 20 seconds...Server unexpectedly disconnected when TLS handshaking.**** Error 0x710b924 returned by ApplyControlTokenFail to connect and get core version of machine vproclient.vprodemo.com using default factory account.Try to use provisioned account (random generated password) to connect target machine vproclient.vprodemo.com...Auto-worker Thread Pool: Current size of the thread pool is 1Server unexpectedly disconnected when TLS handshaking.**** Error 0x710b924 returned by ApplyControlTokenFail to connect and get core version of machine vproclient.vprodemo.com using provisioned account (random generated password).Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 62134)Error: Can NOT establish connection with target device. (MachineId = 62134)Attempting to establish connection with target device using WSMAN.Try to use provisioning account to connect target machine vproclient.vprodemo.com...Using translator for version *.session params : https://sccmserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman https://sccmserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman , 41001ERROR: Invoke(get) failed: 80020009argNum = 0Description: A security error occurredError: Failed to get CIM_SoftwareIdentity instance.Fail to connect and get core version of machine vproclient.vprodemo.com using provisioning account # 0.Try to use default factory account to connect target machine vproclient.vprodemo.com...Using translator for version *.session params : https://sccmserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman https://sccmserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman , 41001ERROR: Invoke(get) failed: 80020009argNum = 0Description: A security error occurredError: Failed to get CIM_SoftwareIdentity instance.Fail to connect and get core version of machine vproclient.vprodemo.com using default factory account.Try to use provisioned account (random generated password) to connect target machine vproclient.vprodemo.com...Using translator for version *.session params : https://sccmserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman https://sccmserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman , 41001ERROR: Invoke(get) failed: 80020009argNum = 0Description: A security error occurredError: Failed to get CIM_SoftwareIdentity instance.Fail to connect and get core version of machine vproclient.vprodemo.com using provisioned account (random generated password).Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 62134)Error: Can NOT establish connection with target device. (MachineId = 62134)>>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<<<p> 

Thanks,

Trevor Sullivan

Systems Engineer 

OfficeMax Corporation

[Matthew_R_Intel]

Can you show the WSTrans.log output. Ensure that the Translator is configured for verbose logging (http://communities.intel.com/community/openportit/vproexpert/microsoft-vpro/blog/2008/06/05/how-to-enabling-logging-in-the-intel-wsman-translator)

--Matt Royer

[idata]

Matt,

Here is what I'm seeing in the wstrans.log file:

Submit to psk://vproclient.vprodemo.com:16993/GeneralInfoService 21

Discovery failed for https://vproclient.vprodemo.com:16993fault()Request from ":4775" for "https://provisioningserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman"Using Basic AuthenticationActiveThreads 1http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_SoftwareIdentity.Get()Using Discovery Routingproxy target is psk://vproclient.vprodemo.com:16993/IP:Non-factory accountUsing psk 4444-4444GetCoreVersion()Submit to psk://vproclient.vprodemo.com:16993/GeneralInfoService 21Discovery failed for https://vproclient.vprodemo.com:16993fault()

Thanks,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[Matthew_R_Intel]

Within your WSTrans.log you posted, i'm not seeing a "Submit to PKI"; i'm only seeing PSK attempts (where it is trying to use the PSK PID/PPS pair). I'm assuming you have configured (WSTransConfig.exe) the Intel WS-MAN Translator with your PKI provisioning certification (same one you configured in SCCM)?

Not seeing any specific reference to this in the log; but other common PKI provisioning problems through the Intel WS-MAN Translator are also caused by"

• Incorrect Setup Account configured
• Provisioning accounts not configured withing Provisioning Account Tab (SCCM Out of Band Component Configuration)

--Matt Royer

[idata]

Matt,

I'm assuming you're talking about the certificate configured in the screen titled "Import Common Setup Certificate"? If so, then yes, I have imported my Verisign provisioning certificate into this field. I have also selected my provisioning certificate in the "Select TLS/forwarding options" screen.

Here is a full list of settings I have in the wstranscfg tool:

Set initial setup password

Setup user: admin

Setup password:

Set Common Pre-Shared Key

Key name: Random numbers

Key value: Random numbers

Import Common Setup Certificate

Imported Verisign provisioning certificate

Set Common Service Credentials

User name:

Password:

Manage User Accounts

Only the default Administrators group is listed

Select TLS/forwarding options

Listening port: 443

Forwarding port: 16993

Server certificate: Verisign provisioning certificate selected

Set WinRM Options

WinRM Avaiable: Checked and greyed out

Allow Basic Authorization: Checked

Thanks,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Also, I meant to ask ... how does the WS-MAN Translator determine whether to use PSK or PKI provisioning? What factors would play into its decision to use PSK instead of PKI provisioning? Perhaps you could list out the high-level steps used during provisioning (whether PKI or not) through ConfigMgr, and then we could step inside each of those to determine more intricately where the problem lies. Is there a document that already contains the translator's logic paths?

[Matthew_R_Intel]

Trevor,

• Please configure your "Set initial setup password" password to be the same as what you configured within ConfigMgr as the MEBx password. The WS-MAN Translator will try admin / admin by default and then what is configured here along with what SCCM passes it.
• The second thing to try is to configure an alternate provisioning account within Configuration Manager. Site Database -> Site Management -> -> Site Settings -> Component Configuration -> Out of Band Management -> Provisioning Settings tab. Give it a user name of "admin" and password of what the remote admin password could be. If the AMT client is in a factory default state, the Remote Admin password should be "admin"; however, if you logged into the MEBx and change the MEBx password when the client was unprovisioned, the Remote Admin password may been set to MEBx password.

In terms of your other question. The WS-MAN translator tries to use PSK and PKI based on SetupProxy and Setup2Proxy values defined in the in the wstrans.exe.config file.

psk

pki

By default, the WS-MAN translator is configured to use PSK first and if the connection fails, it tries to use PKI. You can switch the SetupProxy value to pki and Setup2Proxy to psk to have the WS-MAN Translator use PKI first.

--Matt Royer

[Matthew_R_Intel]

As follow-up note... Any change to the wstrans.exe.config requires a WS-MAN Translator service restart for the change to take effect.

--Matt Royer

[idata]

Matt,

I will try [again] setting the "Set initial setup password" password to be the same as my ConfigMgr setting, however just so you know, I did have it set up this way prior to me having the issues. I blanked it out as a test, to see if that would resolve the issues.

I like the idea of setting PKI provisioning as the primary method. I will probably make that change and try again.

Also, FYI, the Latitude D630C I am testing with is brand new, out of the box, and the MEBx is set to factory defaults (no one has ever logged into it, changed the password, anything). It has never been provisioned. I am testing around a "best case scenario" at this point.

I will follow up in the next day or two with my testing results, and more information as it becomes available.

Thanks,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[Matthew_R_Intel]

Trevor,

I understand that you have already done a lot of general troubleshooting / trial of different configurations behind the scenes; just trying to get myself on the same page with what you have already done,,,

As noted previously, I did not see a PKI submit in your translator log. So if we are confident that your remote admin passwords / remote configuration certificate within the translator are configured properly, then getting the WS-MAN Translator to default to PKI first should most likely resolve the issue. Let us know how it goes.

--Matt Royer.

[idata]

Matt,

No worries. I was just letting you know that, that was how I initially had it configured

I tried provisioning the same system again this morning after trying both of your recommendations, and it's still having the same exact issue. I still don't see a hand-off to the PKI provisioning piece of the WS-MAN Translator.

1. Do you have a log of a successful PKI provisioning attempt of a 2.6 vPro client using ConfigMgr w/ the WS-MAN Translator?

2. Although I believe I have my TLS settings set up properly, I don't want to discount the possibility of this being a TLS problem. Are there any other items I should be checking regarding the provisioning certificate?

3. Anything else I should be checking?

-------

I don't want to confuse this information with the primary purpose of this thread, but I have another Dell Latitude D630C running BIOS A09, but it's only at AMT firmware 2.6.2 (not 2.6.3). This is my main work laptop that I use on a daily basis. I just noticed that, around noon yesterday, this system attempted to provision, and actually succeeded with first-stage provisioning. There are a bunch of errors during second-stage provisioning however, and I can't authenticate to it with my domain account (using the ConfigMgr OOB console). Because this is a different AMT firmware revision, I thought that this might be relevant information. Also, something else unique about this system, is that it had a custom MEBx password on it.

I have no idea why the 2.6.2 would partially work, having been customized slightly, and the newer 2.6.3 would completely fail even though it's at factory defaults. Again, I don't want to confuse the two issues, but they may have some similarities.

Due to confidential information contained within the log of the 2.6.2 system's provisioning attempt, I will send you this information via e-mail.

Thanks,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Matt,

I finally took apart my laptop this morning and reset the CMOS so I could re-attempt the provisioning process. Greg has forwarded me your message requesting me to do that. Now, instead of getting through first-stage provisioning, it's failing altogether. Here is the newest:

>>>>>>>>>>>>>>>Provision task begin<<<<<<<<<<<<<<<<p> 

Provision target is indicated with SMS resource id. (MachineId = 54246 vproclient.vprodemo.com)Found valid basic machine property for machine id = 54246.Warning: Currently we don't support mutual auth. Change to TLS server auth mode.The provision mode for device vproclient.vprodemo.com is 1.Attempting to establish connection with target device using SOAP.Found matched certificate hash in current memory of provisioning certificateCreate provisionHelper with (Hash: 0CE62E1E26D22E86F2C31BB6D95471C968C9903B)Set credential on provisionHelper...Try to use provisioning account to connect target machine vproclient.vprodemo.com...Server unexpectedly disconnected when TLS handshaking.**** Error 0x6d4b924 returned by ApplyControlTokenFail to connect and get core version of machine vproclient.vprodemo.com using provisioning account # 0.Try to use default factory account to connect target machine vproclient.vprodemo.com...AMT Provision Worker: Wakes up to process instruction filesAMT Provision Worker: Wait 20 seconds...Server unexpectedly disconnected when TLS handshaking.**** Error 0x6d4b924 returned by ApplyControlTokenFail to connect and get core version of machine vproclient.vprodemo.com using default factory account.Try to use provisioned account (random generated password) to connect target machine vproclient.vprodemo.com...Auto-worker Thread Pool: Work thread 12868 has been requested to shut down.Auto-worker Thread Pool: Work thread 12868 exiting.Auto-worker Thread Pool: Work thread 4284 has been requested to shut down.Auto-worker Thread Pool: Work thread 4284 exiting.Auto-worker Thread Pool: Current size of the thread pool is 1Server unexpectedly disconnected when TLS handshaking.**** Error 0x6d4b924 returned by ApplyControlTokenFail to connect and get core version of machine vproclient.vprodemo.com using provisioned account (random generated password).Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 54246)Error: Can NOT establish connection with target device. (MachineId = 54246)Attempting to establish connection with target device using WSMAN.Try to use provisioning account to connect target machine vproclient.vprodemo.com...Using translator for version *.session params : https://siteserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman , 41001ERROR: Invoke(get) failed: 80020009argNum = 0Description: A security error occurredError: Failed to get CIM_SoftwareIdentity instance.Fail to connect and get core version of machine vproclient.vprodemo.com using provisioning account # 0.Try to use default factory account to connect target machine vproclient.vprodemo.com...Using translator for version *.session params : https://siteserver.vprodemo.com/wstrans/dsc/eoi20/vproclient.vprodemo.com/wsman , 41001ERROR: Invoke(get) failed: 80020009argNum = 0Description: A security error occurred

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

Here is the output from MEinfowin on this system:

Intel(R) MEInfo Win Version: 2.5.0.1032

BIOS Version: A09

Intel(R) AMT code versions:

Flash: 2.6.2 Netstack: 2.6.2 Apps: 2.6.2 Intel(R) AMT: 2.6.2 Sku: 12 VendorID: 8086 Build Number: 1029 Recovery Version: 2.6.2 Recovery Build Num: 1029 Legacy Mode: False

Link status: Link up

Cryptography fuse: EnabledFlash protection: EnabledLast reset reason: Global system resetSetup and Configuration: In processBIOS Mode: Post BootDedicated Mac Address: 00-1c-23-1e-01-3eHost Mac Address: 00-1c-23-1e-01-3fFWU Override Counter: AlwaysFWU Override Qualifier: AlwaysFW on Flash Desc Override: DisableKedron Driver Version: 12.0.0.82Kedron HW Version: 2.0.40UNS Version: 2.6.8.1025LMS Version: 2.6.11.1025HECI Version: 2.6.30.1014

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

After fixing my other provisioning issues, I'm still having this issue with the AMT 2.x systems via the WS-MAN Translator. The same messages as the logs I included in my previous posts in this thread are occurring.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

[idata]

I was just watching http://www.vproexpert.com/sccm_vpro/module_06/module_06.html training module 6 (around 14:40) on ConfigMgr and vPro, and noticed that Matt Royer set the Name field to "WS-MAN Translator Server Certificate" (for the IIS / WS-Trans SSL certificate).

The certificate I created, from our internal CA, doesn't have this exact string in it. Can someone validate for me that this name is or isn't necessary? It would appear to simply be a friendly name to refer to the certificate as, but I just want to make sure.

Thanks,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation