- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Thanks!
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!
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Brian,
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.
Regards,
Roger
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.
Regards,
Roger
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Brian,
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 notsupport 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.
Later,
Roger
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 notsupport 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.
Later,
Roger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Roger,
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?
Thanks,
Brian
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?
Thanks,
Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Brian Earp
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?
Thanks!
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 ZTCLocalAgentto 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 hasbeen 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.
Regards,
Roger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Roger,
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?
Thanks,
Brian
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?
Thanks,
Brian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Brian Earp
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?
Thanks!
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - rogerb
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:
Intel ZTCLocalAgent Version: 3.0.0.1
BIOS Version: APQ4310H.86A.0024.2009.0410.1430
Intel AMT code versions:
Flash: 5.0.3
Netstack: 5.0.3
AMTApps: 5.0.3
AMT: 5.0.3
Sku: 18494
VendorID: 8086
Build Number: 1126
Recovery Version: 5.0.3
Recovery Build Num: 1126
Legacy Mode: False
Setup and Configuration:
Not started
Found 5 certificate hashes in following Handles:
0,1,2,3,4,
Certificate hash entry:
Friendly Name = VeriSign Class 3 Primary CA-G1
Default = true
Active = true
Hash Algorithm = SHA1
Certificate Hash:
74 2C 31 92 E6
07 E4 24 EB 45
49 54 2B E1 BB
C5 3E 61 74 E2
Certificate hash entry:
Friendly Name = VeriSign Class 3 Primary CA-G3
Default = true
Active = true
Hash Algorithm = SHA1
Certificate Hash:
13 2D 0D 45 53
4B 69 97 CD B2
D5 C3 39 E2 55
76 60 9B 5C C6
Certificate hash entry:
Friendly Name = Go Daddy Class 2 CA
Default = true
Active = true
Hash Algorithm = SHA1
Certificate Hash:
27 96 BA E6 3F
18 01 E2 77 26
1B A0 D7 77 70
02 8F 20 EE E4
Certificate hash entry:
Friendly Name = Comodo AAA CA
Default = true
Active = true
Hash Algorithm = SHA1
Certificate Hash:
D1 EB 23 A4 6D
17 D6 8F D9 25
64 C2 F1 F1 60
17 64 D8 E3 49
Certificate hash entry:
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 AMT device has not progressed far enough in its initialization to process the command.
Activate Intel AMT configuration:
Failure
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Brian Earp
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?
Thanks!
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - rogerb
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Brian,
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.
Regards,
Roger
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.
Regards,
Roger
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for all the help. I've learned the hardware needs to be updated. I'm using newer hardware now and things are working much better.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page