Hello vPro Experts!
I've got something sitting in the back of my mind, that I would like to share with you all. Unfortunately, it's simply a theory, and I have not yet had the opportunity to test it, but I am in the early stages of developing and documenting it, and would really appreciate any feedback, to help make it become a reality.
Are you asking yourself either of these questions?
"How can I reduce the amount of overhead involved with imaging every new client system that comes through the doors, but at the same time, not shift that cost to the vendor?"
or, slightly paraphrased:
"How can I streamline the provisioning of new systems, but at the same time, not sacrifice the flexibility of having in-house imaging?"
If your support teams are imaging each desktop and laptop that is shipped from your hardware vendor, you may have investigated the option of having the vendor pre-image systems prior to shipping them out. There are a couple of caveats to this methodology though. First of all, there is usually an additional cost associated with any sort of customization that the vendor must make to a system. Secondly, if you are using a task sequence-based "imaging" process in-house, then you may not have a way of transferring that process (which is inherently network-reliant), to the vendor. Typically, in this scenario, your operating systems, applications, and Active Directory domain, are all residing on network servers that can't be contacted by the vendor during the process (unless you have some uber-fast, secure VPN link between you and them, in which case you can stop reading).
The Theoretical Solution (utilizing Intel vPro)
The proposed solution to the problem presented above, is actually a combination of technologies, and custom development work. In this case, I'm going to be working with the following tools:
- Microsoft Configuration Manager SP1 / R2 (R2 for unknown computer OSD support)
- Intel vPro / AMT Clients 3.2.1 and greater (4.0, 5.0)
- Microsoft VBscript and/or Windows Powershell
- Microsoft Windows Management Instrumentation (WMI)
- Intel AMT Developer Toolkit (DTK)
Here are the requirements for the process:
- Microsoft Configuration Manager SP1
- An Out-of-Band (OOB) service point for ConfigMgr SP1
- “ProvisionServer” DNS record pointing to out-of-band service point
- Collection 1: SCCM collection to temporarily store resource records created by script
- Collection 2: SCCM collection that contains provisioned vPro clients without the ConfigMgr client agent
- ConfigMgr Task Sequence to build vPro system
- ConfigMgr advertisement to link task sequence to Collection 2
This is the theoretical process that would be followed:
- Physically plug in vPro system – power and network (device remains powered off)
- vPro System obtains IP address and DHCP Option 15 (mydomain.com)
- vPro System sends “hello packet” to site server (CNAME provisionserver.mydomain.com)
- Script reads vPro system’s UUID from amtopmgr.log file on site server
- Script creates Resource Record for system in “Collection 1” with auto-provisioning enabled
- Use a random name for the hostname (based off of the SMBIOS UUID perhaps)
- Make sure to refresh the collection membership, or verify that it gets added somehow
- vPro System sends another hello packet to site server at built-in interval
- vPro System is recognized as a SCCM resource and provisions
- Provisioned vPro resource is automatically populated into SCCM “Collection 2”
- Task sequence begins executing
- Once the operating system is installed, the device should detect a mismatching hostname between the OS and the ME firmware (this could be configured as part of the task sequence)
- The device will send a request to the ConfigMgr site server to re-provision the AMT firmware with the new hostname (equivalent of "Update Provisioning Data"?)
There is at least one known outstanding issue that I'm aware of, and there may be a way to solve it.
Possibility of over-writing an existing system
If an existing, un-provisioned system is not reporting into Configuration Manager properly, it may be incorrectly assumed to be a new, blank system. Therefore, during the build (or imaging) process, an automated check may need to be put into place to verify whether or not the system is truly a new client or not. This could theoretically be done by analyzing the filesystem, or mounting the offline registry hives, and looking for any indicators. Additionally, if a vPro device was already provisioned, it would need to be excluded from being targeted with this process.
I hope that this overview gives you some ideas about how to automate the provisioning of new enterprise clients using Intel vPro out-of-band provisioning. If you have any suggestions for improvement, I'd be interested in hearing them. If you'd like, you can download a copy of this document below.