Intel SCS and RCT.EXE Problems

[idata]

Hi,

We have 2 Dell Optiplex 755 and have removed the battery on them to restore them back to factory settings (I hope this also resets the AMT back as well).. These machines are AMT 3.0 devices.

We have setup a windows server 2003 using VMWare, along with SQL Express, IIS, DotNet Framework 2. Then installed the Intel SCS and configured it to use another external CA on the network. This all appears to be working ok, from what we can see.

We installed the Verisign public root certificates on the machine as well, as the dell has 4 certificates on it by default, 2 of which are from verisign.

We were expecting the machines to start sending messages out to the provision server automatically. But can't seem to see anything coming through requesting..

So then tried running RCT.EXE on the DELLs to try and connect to the SCS..

This showed a little more progress, except it didn't seem to work. After checking the log file, we got the following:

-- Start --

Step Into: CheckAMT

Connected to HECI driver, version: 3.0.30.1086

BIOS Version: A03

Intel AMT code versions:

Flash: 3.0.4

Netstack: 3.0.4

AMTApps: 3.0.4

AMT: 3.0.4

Sku: 12

VendorID: 8086

Build Number: 1120

Recovery Version: 3.0.4

Recovery Build Num: 1120

Legacy Mode: False

Setup and Configuration:

In process

Provisioning TLS Mode:

PKI

Step Into: GetHostFQDN

host Name is gibbo1.amtestdomain.local

Step Into: CSCSER::PerformSCSRemoteConfiguration

Step Into: CSCSER::SCSSetAMTIdentity

Step Into: CSCSER::SCSCreateOTP

AMT version: 3.0 Step Into: StartConfiguration

BIOS Version: A03

Intel AMT code versions:

Flash: 3.0.4

Netstack: 3.0.4

AMTApps: 3.0.4

AMT: 3.0.4

Sku: 12

VendorID: 8086

Build Number: 1120

Recovery Version: 3.0.4

Recovery Build Num: 1120

Legacy Mode: False

Setup and Configuration:

In process

Intel AMT Mode:

Non Legacy

Zero Touch Configuration:

enabled

Provisioning TLS Mode:

PKI

RNG seed status:

exists

PT_STATUS_INVALID_PT_MODE: Command is not permitted in current operating mode.

Activate Intel AMT configuration:

failure

PT_STATUS_INVALID_PT_MODE: Command is not permitted in current operating mode.Exit with code 2

-- End --

From what we can tell the error code 2, which means that it 'Platform is already in setup and configuration mode.'After looking at the code, it looked like it was failing when the RCT.EXE was calling SetProvisioningServerOTP. Anybody got any ideas..Many thanks

[Alireza_M_Intel]

If more than one Dell 755 presents on same network and Dell's firmware update (released internally last week) is missing, the provisioning task will fail due to duplicate UUID. I don't know if this issue is related to duplicate UUID but recommend connecting only one Dell 755 to network and if problem persists, try to provision the system in PKI-PSK (PPS-PID) to see no issue with SCS in general. If it works in TLS-PSK, then the focus should be on RCFG certificate. It is important to know that this certificate has to be installed in SCS service account personal certificate store with its PRIVATE KEY (very important)

[Steven_D_Intel1]

Your DELL Optiplex 755's are based on AMT 3.0. The default for AMT 3.0 is to automatically send out network packets (sometimes called 'hello' packets) as soon as a valid network link is available. If I were debugging your situation, I'd look in the following places

1. Make sure your DELL client can obtain the necessary network parameters to send packets on the network. This either means checking that DHCP is providing the client with dynamic IP address and parameters (subnet, gateway, DNS IP and domain name) or configuring DELL client with an unused static IP address and parameters. If the client cannot obtain an IP address then no packets will be sent. The preferred configuration option is dynamic IP and you can see in your DHCP server if an IP lease was granted

2. If the client has an IP address then it can communicate on the network which is good. Next, it needs to be able to locate the SCS server so it can get provisioned. Clients locate the SCS server in one of two different ways; either they lookup the name 'ProvisionServer' using DNS and expect the IP address they receive from DNS to be your SCS server, or you type the IP address of your SCS server into the DELL client in the MEBx BIOS screen. If the client cannot find the IP address of your SCS server you will not see any packets. The preferred configuration option is to place an entry into your DNS for 'ProvisionServer' rather than typing values into the MEBx BIOS screen. However for debugging purposes, if you think your DNS is broken, you could type an entry into the MEBX screens and if this results in packets reaching your SCS server from your client then you should focus on DNS

3. Make sure packets are reaching the SCS server from your clients. This can be done by installing Microsoft Network Monitor (included in Server 2003) onto your SCS server and setting it to capture packets. Remove power from your DELL clients and then re-apply power to force them to begin sending packets. After approximately 5-8 minutes, stop the packets capture on your SCS server and inspect the trace. You are looking for packets from your client which are targetted at port 9971. If you see these packets, then you know your clients are sending packets and they are reaching your SCS server. If you see no packets from your clients then you need to work backwards and look at your DHCP server and your DNS system to ensure that they are providing an IP address and providing correct IP address for SCS. Again you can install Microsoft Network Monitor on your DHCP and DNS server to check for packets from your DELL clients and confirm DHCP and DNS are working

4. If packets are reaching your SCS server, but you do not see anything in the SCS console to indicate provisioning has succeeded or failed, then check the AMT Configuration service is running on your SCS server and has not stopped. If it stopped, then restart it. If it will not restart, then check the event log for possible reasons (probably a database access issue)

5. Once you see that your DELL clients show up in the SCS console, then you need to ensure that the SCS server has the required information to provision the clients. This basically means an entry which links the client UUID to the SCS profiles, FQDN and OU. You need to ensure this exists. Finally you need to ensure you have an RCFG digital certificate installed on your SCS server if you plan to use certiicates for provisioning purposes (rather than using TLS-PSK which requires loading PID/PPS data onto your client). RCFG certiifcates are explained in the SCS User Guide and you need to obtain one of these certificates

To summarise, the best way to debug your issue is to check for network packets at each stage in your network (DHCP, DNS and SCS server) using a tool like Microsoft Network Monitor to ensure packets are being received and the client is receiving the data it needs. If packets are not being received then you have narrowed down the area to troubleshoot in more detail.

Good Luck

[Todd_Christ]

whgibbo - I'd suggest that you download and install the latest Intel AMT Add-on for SMS 2003 v3.0 package which includes hotfix 3 (just released). The download may be found here: http://downloadcenter.intel.com/detail_desc.aspx?strstate=live&productid=2609&dwnldid=11609&agr=n&lang=eng&prdmap=2609 http://downloadcenter.intel.com/detail_desc.aspx?strstate=live&productid=2609&dwnldid=11609&agr=n&lang=eng&prdmap=2609

[Terry_C_Intel]

Still having issues or did you get this figured out?

If not - some questions and thoughts to consider

• What is the SCSconsole showing for OTP (One Time Password) and RemoteConfiguration support? Both should be checked

• Is the SCS console logging in verbose mode? Other prompts or indicators for the target system and provisioning sequence? (look under Logs->Log in the SCS console)

• Does the ProvisionServer (server running AMTconfig with DNS record identifying as "ProvisionServer") have a web directory "AMTSCS_RCFG"? You'll find this under the IIS default webpages - right under "AMTSCS" virtual directory

• Has a Intel Client Setup Certificate been associated (using loadcert.exe) on the SCS server?

• Are you using an external or custom in-house certificate? If custom or 3rd party beyond the standard offering (e.g. VeriSign G1, VeriSign G3, Starfield, or Godaddy) - is the certificate hash (e.g. 40 character certificate thumbprint) entered into the MEBx non-persistent certificate store? (BTW: This can be accomplished using USBfile.exe version 2 - for a newer version of the setup.bin)

[William_Y_Intel]

Dell has released Bios A04 that corrected the duplicate UUID issue that could cause this exact error. When you provision a Dell 755 with Bios A03, the SCS server records the processed UUID. The when you attempt to provision another Dell 755 (using the RCT tool in your case), the SCS already has the UUID from the first system. Since the A03 Bios release has the same uuid for all systems, SCS will flag a warning that any system after the first provision system has been provisioned...due to the same uuid issue. You should get this resolved when upgrading to A04.

Also, make sure you have added the Domain Users group inside of your SCS Users Groups. And specify this group as Client Configuration role.