Yes, it's possible, but no, you can't do it without physically touching each machine.
1. Log into MEBx locally
2. Change password
3. Manually set domain suffix
4. Provision device
The FQDN configured in the MEBx overrides DHCP Option 15 for the AMT firmware.
I am not personally aware of any such documentation, but you might want to check out the utilities included with the Intel AMT DTK.
Option 15 is used in the provisioning process to validate the Provisioning certificate (e.g. VeriSign). AMT will look at the FQDN from Option 15 and compare it to the Provisioning Certificate during the provisioning process. These values must either match or leverage a few of the options available in different versions of AMT and Certificate types (e.g. wildcards, UCC, etc). Here is a good whitepaper post for more understanding to this point. http://communities.intel.com/docs/DOC-2432
Can these systems be given any type of Option 15 value? It does not have to match exactly to that of your SCCM environment as long as the top level roots are the same. This will make more sense once you review the whitepaper. If option 15 is completely missing from the equation for these remote systems, a physical touch will be necessary as Trevor describes. You are correct that you can use a utility (from the Manageability Tool Kit) to generate this value for you and import it into AMT. The utility is called USBFile (unless it was renamed in the tool kit). You can use this utility to generate a setup.bin file and copy to a formatted (FAT16) thumb drive (smaller drive the better). You can use the -dns switch to add your neccessary values to match your Provisioning certificate. Then simply insert it into the vPro system and it will pull the settings into the MEBx, as defined during the creation of the setup.bin file.
OUTPUT from Utility and associated switches
*** Intel(R) AMT USB file writer and viewer sample v2.0***
USBfile -create <usb output file name> <current MEBx password>
<new MEBx password> [-v 1|2] [-amt]
[-dns <DNS suffix>] [-fqdn <prov server fqdn>]
[-gen <num of records>]
[-xml <xml file name>]
[-pid <pid> -pps <pps>]
[-hash <cert file name> <friendly name>]
USBfile -view <usb file name>
-v 1|2: the setup file version, 2 by default
-amt: this will set the manageability selection value to AMT
-dns <DNS suffix>: sets the PKI dns suffux name (up to length 255)
-fqdn <prov server fqdn>: string up to length 255
-ztc 0|1: enable/disable PKI Configuration
-xml <xml file name>: if -gen is chosen the PSK records that
are created will be dumped to the given file
-gen <num of records>: create the requested number of consumable records.
By default, a single non-consumable record is created.
If this option is chosen, a PSK pair will be randomly
generated for each record.
-pid <pid> -pps <pps>: a psk pair - this is ignored if -gen was chosen
-hash <certificate file name> <friendly name>: to compute and add the
hash of the given root certificate file. The file provided
must contain the root certificate data only. Up to three
certficate hashes may be specified.
This is an integer that is calculated as follows:
bit 0 : 1 (Enable) or 0 (Disable) - SOL feature
bit 1 : 1 (Enable) or 0 (Disable) - IDER feature
bit 2 : 1 (Enable) or 0 (Disable) - Username/password
authentication type of the SOL/IDER in the ME FW
USBfile -create setup.bin admin Admin22@ -v 1 -gen 10 -xml setup.xml
USBfile -create setup.bin admin Admin22@ -pid AAAA-AAAN
USBfile -view setup.bin
1. The BIOS requires a binary file with the name "setup.bin"
2. If version 1 is chosen, the only valid options are -xml as well as
either -gen (to generate multiple PSK records) or -pid and -pps (to
create a single PSK record). All other optional flags will be ignored.
Thanks for your input about the usb-key tool.
Unfortunately the branch-offices use a router where I cannot set any DHCP options besides the DNS servers. All I can do about the DNS suffix is setting a group policy option in Active Directory that sets the DNS suffix for the computer, but this doesn't seem to fit for AMT as I already tried this.
I might have some other DNS issues there as well, because the PTR-Records are not correctly created for machines located in branch offices (the A records work and update fine though).