I have heard the request several times for an OEM or service provider capability to fully provision an Intel vPro/AMT system BEFORE it arrives onsite at the customer. The following idea may also be of use\interest for large lab environments.
In doing lab tests – I find this possible in many situations\cases. The key is knowing the provision profile ACL settings (at least the Intel AMT admin password), with an assumption only BASIC or STANDARD mode provisioning (e.g. no TLS, no Kerberos, no 802.1x).
Once in the environment – if the mgmt ISV supports a network discovery or agent based update process, then the mgmt console has “full control” of the client. In my lab tests – provisioned a group of systems with a primary Altiris server. Then I loaded up a second Altiris environment, redirected the in-band Altiris agent to it, and thus populated “in-band”. After running the Altiris OOB Discovery – then had an awareness of what systems were AMT capable. Could have also done an Altiris Network Discovery. In the end – the second Altiris environment NEVER provisioned the systems. In fact – I totally disabled the provisioning aspects of the environment. However, both Altiris servers can send mgmt commands. Interested to know if anyone has tried this in a mixed environment – SMS and Altiris, LANDesk and SMS, etc. Thus far – don’t see any issues.
Since the configured client will be imaged with an OS, and the FQDN will likely change once or twice – the Intel AMT reflector Utility can be used to resync the FQDN between OS and AMT FW. This utility has a command line\script capability.
If the target environment decides they want to reprovision the systems – changing of the provision profile or other – then again, use Intel AMT Reflector or the unprovision.exe utility to fully unprovision the client. After this – initiate a provisioning process via Remote Configuration, or have pre-shared keys installed on the client. (At one point I considered partial unprovision – yet that would require the OEM or service provider to dump their generated PID|PPS pairs to a setup.bin and give to the customer… not likely).
The Intel vPro Activator utility could be used to initiate the hello packets remotely.
The key item to keep in consideration – this idea could be applied to mixed environments, whether or not all client mgmt solutions utilize Intel SCS… in fact, the systems could be small-medium business (SMB) or enteprise mode (without TLS, Kerberos, etc)
Thoughts on this? Have others tried it? if so - like to hear about your experiences in doing so.
In doing lab tests – I find this possible in many situations\cases. The key is knowing the provision profile ACL settings (at least the Intel AMT admin password), with an assumption only BASIC or STANDARD mode provisioning (e.g. no TLS, no Kerberos, no 802.1x).
Once in the environment – if the mgmt ISV supports a network discovery or agent based update process, then the mgmt console has “full control” of the client. In my lab tests – provisioned a group of systems with a primary Altiris server. Then I loaded up a second Altiris environment, redirected the in-band Altiris agent to it, and thus populated “in-band”. After running the Altiris OOB Discovery – then had an awareness of what systems were AMT capable. Could have also done an Altiris Network Discovery. In the end – the second Altiris environment NEVER provisioned the systems. In fact – I totally disabled the provisioning aspects of the environment. However, both Altiris servers can send mgmt commands. Interested to know if anyone has tried this in a mixed environment – SMS and Altiris, LANDesk and SMS, etc. Thus far – don’t see any issues.
Since the configured client will be imaged with an OS, and the FQDN will likely change once or twice – the Intel AMT reflector Utility can be used to resync the FQDN between OS and AMT FW. This utility has a command line\script capability.
If the target environment decides they want to reprovision the systems – changing of the provision profile or other – then again, use Intel AMT Reflector or the unprovision.exe utility to fully unprovision the client. After this – initiate a provisioning process via Remote Configuration, or have pre-shared keys installed on the client. (At one point I considered partial unprovision – yet that would require the OEM or service provider to dump their generated PID|PPS pairs to a setup.bin and give to the customer… not likely).
The Intel vPro Activator utility could be used to initiate the hello packets remotely.
The key item to keep in consideration – this idea could be applied to mixed environments, whether or not all client mgmt solutions utilize Intel SCS… in fact, the systems could be small-medium business (SMB) or enteprise mode (without TLS, Kerberos, etc)
Thoughts on this? Have others tried it? if so - like to hear about your experiences in doing so.
Tags:
vpro,
migration,
co-host,
provisioning
