July 10, 2009 12:43 PM PDT
ZtcLocalAgent sample Setup and configuration status
A few questions on the ZtcLocalAgent sample.
1. I have two AMT 5 systems, one 5.0.2 and the other 5.0.3. On the 5.0.2 system, after unprovisioning Intel AMT, removing the power and CMOS battery, then turning it back on and running ZtcLocalAgent -discovery, the setup and configuration state is "In process" and the system does send hello packets to the provisioning server on the network. On the 5.0.3 system, following the same sequence, the state is "Not started". What could be causing this? These are on different domains with slightly different settings, but I don't see why they would behave so differently.
2. Now, when I run ZtcLocalAgent -activate on the 5.0.2 system ("in process" state) I get the expected result for the CFG_StartConfiguration API call of PT_STATUS_INVALID_PT_MODE. On the "not started" system, I get PT_STATUS_NOT_READY. According to the Developer's guide, this error should only be returned if DNS option 15 is not present on the network or if there is no DHCP server. The host OS does get an IP address lease from DHCP and it does have the correct domain suffix, so what else could be causing this?
3. Is it 24 hours after entering the "in process" state before CFG_StartConfiguration can request the AMT system to issue hello packets again?
When you first ran the config agent was the state in "Not Started" or "In Process"? If the process wasn't started, then the system was setup by your OEM to not support bare-metal provisioning. In 5.0.2, the default behavior was for a full unprovision to revert the system to the Intel factory default state, which is to support bare-metal provisioning for the first 24 hours, even though your OEM had defined the default behavior to be bare-metal provisioning not supported. In 5.0.3, a change was made in the default behavior to change it to revert to the OEM's factory defined state after a full unprovision instead of the Intel default configuration. This was changed in all of the AMT versions due to OEM requests to match customer demands. I hope that this answers your question.
Thanks, that explains the behavior I am seeing. To answer your question, the first time I ran ZtcLocalAgent -discovery shortly after removing CMOS/power and powering it back on it either said in process on 5.0.2 or not started on 5.0.3, these states haven't changed since (it hasn't been 24 hours yet for either).
Let me ask a few follow up questions; is agent initiated provisioning possible on 5.0.3 and above if bare metal provisioning is turned off by default? If so, what process/API changes do I need to make to ZtcLocalAgent to make it work? Right now, if provisioning is in the "not started" state, it doesn't work and hello packets do not get sent via CFG_StartConfiguration.
Is there a way to turn on bare-metal provisioning, or is it permanently off in 5.0.3 and above if the OEM decides to ship that way?
1. I have two AMT 5 systems, one 5.0.2 and the other 5.0.3. On the 5.0.2 system, after unprovisioning Intel AMT, removing the power and CMOS battery, then turning it back on and running ZtcLocalAgent -discovery, the setup and configuration state is "In process" and the system does send hello packets to the provisioning server on the network. On the 5.0.3 system, following the same sequence, the state is "Not started". What could be causing this? These are on different domains with slightly different settings, but I don't see why they would behave so differently.
2. Now, when I run ZtcLocalAgent -activate on the 5.0.2 system ("in process" state) I get the expected result for the CFG_StartConfiguration API call of PT_STATUS_INVALID_PT_MODE. On the "not started" system, I get PT_STATUS_NOT_READY. According to the Developer's guide, this error should only be returned if DNS option 15 is not present on the network or if there is no DHCP server. The host OS does get an IP address lease from DHCP and it does have the correct domain suffix, so what else could be causing this?
3. Is it 24 hours after entering the "in process" state before CFG_StartConfiguration can request the AMT system to issue hello packets again?
Thanks!
Hi Brian,
You don't have to do anything to ZTCLocalAgent to support Remote Configuration it already does that. All you have to do is run the command with the -activate switch. This will turn on Remote Config so that the system will start sending hello packets. Once a system goes to the "in process" state, the system will continue to send hello packets on a decaying schedule with the time between packets getting progressively longer until they stop altogether. Once the hello packets have stopped, you have to go back into the system and re-run the ZTC agent app to get the ME to start sending hello packets again.
The purpose of Bare-metal provisioning is to allow an enterprise that already has AMT setup and running in their infrastructure to get new systems setup with the least amount of effort. If BMP is supported, as soon as a new system gets connected to the network it will start sending hello packets and start communicating with the SCS server. If BMP isn't supported, then the user has to run ZTCLocalAgent to get the ME to start sending hello packets to the SCS, but ZTCLocalAgent can be run remotely, so an admin can see that a new machine has been added and then go out and force the system to get configured by running ZTCLocalAgent. Since most customers don't have AMT implemented yet, by not supporting BMP the OEMs stop the ME from issuing extraneous DHCP requests, and since turning on Remote Config only requires a remote command, the level of pain due to no support for BMP is fairly low.
Ok, then something is causing ZtcLocalAgent to not work on the 5.0.3 system. Setup and configuration state remains not started, and the error returned by CFG_StartConfiguration remains PT_STATUS_NOT_READY. What could be causing this?
1. I have two AMT 5 systems, one 5.0.2 and the other 5.0.3. On the 5.0.2 system, after unprovisioning Intel AMT, removing the power and CMOS battery, then turning it back on and running ZtcLocalAgent -discovery, the setup and configuration state is "In process" and the system does send hello packets to the provisioning server on the network. On the 5.0.3 system, following the same sequence, the state is "Not started". What could be causing this? These are on different domains with slightly different settings, but I don't see why they would behave so differently.
2. Now, when I run ZtcLocalAgent -activate on the 5.0.2 system ("in process" state) I get the expected result for the CFG_StartConfiguration API call of PT_STATUS_INVALID_PT_MODE. On the "not started" system, I get PT_STATUS_NOT_READY. According to the Developer's guide, this error should only be returned if DNS option 15 is not present on the network or if there is no DHCP server. The host OS does get an IP address lease from DHCP and it does have the correct domain suffix, so what else could be causing this?
3. Is it 24 hours after entering the "in process" state before CFG_StartConfiguration can request the AMT system to issue hello packets again?
Thanks!
Has remote configuration been enabled in MEBx? If you go into the PKI area of MEBx, are the default configuration certificates enabled?
Has remote configuration been enabled in MEBx? If you go into the PKI area of MEBx, are the default configuration certificates enabled?
Hi Roger,
I don't have direct access to the BIOS/MEBx, but based on the output from ZtcLocalAgent -activate, remote configuration is enabled and the default configuration certificates are enabled:
Friendly Name = Starfield Class 2 CA Default = true Active = true Hash Algorithm = SHA1
Certificate Hash: AD 7E 1C 28 B0 64 EF 8F 60 03 40 20 14 C3 D0 E3 37 0E B5 8A
Intel AMT Mode: Non Legacy
Zero Touch Configuration: enabled
Provisioning TLS Mode: PKI
RNG seed status: exists
Failed performing Start Configuration command: PT_STATUS_NOT_READY: Intel(R) AMT device has not progressed far enough in its initialization to process the command.
1. I have two AMT 5 systems, one 5.0.2 and the other 5.0.3. On the 5.0.2 system, after unprovisioning Intel AMT, removing the power and CMOS battery, then turning it back on and running ZtcLocalAgent -discovery, the setup and configuration state is "In process" and the system does send hello packets to the provisioning server on the network. On the 5.0.3 system, following the same sequence, the state is "Not started". What could be causing this? These are on different domains with slightly different settings, but I don't see why they would behave so differently.
2. Now, when I run ZtcLocalAgent -activate on the 5.0.2 system ("in process" state) I get the expected result for the CFG_StartConfiguration API call of PT_STATUS_INVALID_PT_MODE. On the "not started" system, I get PT_STATUS_NOT_READY. According to the Developer's guide, this error should only be returned if DNS option 15 is not present on the network or if there is no DHCP server. The host OS does get an IP address lease from DHCP and it does have the correct domain suffix, so what else could be causing this?
3. Is it 24 hours after entering the "in process" state before CFG_StartConfiguration can request the AMT system to issue hello packets again?
Thanks!
Have you been able to get a One-touch config (PSK) to work correctly?
Have you been able to get a One-touch config (PSK) to work correctly?
Interestingly, no, it doesn't talk to the provisioning server on the AMT 5.0.3 system we have. To verify the environment, we did try one-touch config on a Guardfish and a DQ35JO, both of those systems worked.
On the AMT 5 system, it accepted the key for auto-provisioning from the USB stick, then rebooted. After that, nothing happened.
It sounds like you have networking issues with the system in question, that could generate the error that you're seeing when you run the ZTCLocalAgent app. You should try and configure the system manually from MEBx to see if you can get AMT talking on your network at all.
