Home > Intel Communities > Open Port IT Community > Intel® vPro™ Expert Center > Blog > 2008 > December > 16
Up to Blog Posts in Intel® vPro™ Expert Center
Previous Next

Intel vPro Expert Center Blog

Currently Being Moderated
Trevor Sullivan
2


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.


----

The Problem

 

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:



Requirements


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

Step-by-Step Workflow


This is the theoretical process that would be followed:


  1. Physically plug in vPro system – power and network (device remains powered off)
  2. vPro System obtains IP address and DHCP Option 15 (mydomain.com)
  3. vPro System sends “hello packet” to site server (CNAME provisionserver.mydomain.com)
  4. Script reads vPro system’s UUID from amtopmgr.log file on site server
  5. Script creates Resource Record for system in “Collection 1” with auto-provisioning enabled
    1. Use a random name for the hostname (based off of the SMBIOS UUID perhaps)
    2. Make sure to refresh the collection membership, or verify that it gets added somehow
  6. vPro System sends another hello packet to site server at built-in interval
  7. vPro System is recognized as a SCCM resource and provisions
  8. Provisioned vPro resource is automatically populated into SCCM “Collection 2”
  9. Task sequence begins executing
  10. 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)
  11. 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"?)


Known Issues and Risks


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.

----

Conclusion

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.


Thanks,


Trevor Sullivan

Systems Engineer

OfficeMax Corporation

 


Attachments:
Tags: sccm, configuration, manager, engineering, roi, 5.0, sccm_sp1, automation, tools, configmgr, deploy, vista, vpro, amt, trevor, provision, 3.2.1, install, windows, 4.0, dtk, xp, sullivan, automated, microsoft


Add a comment Leave a comment on this blog post.
Dec 17, 2008 7:48 PM Matt Royer Matt Royer    says:

The core of the challenge with unprovisioning when the OS no longer matches AMT hostname comes down to these factors: TLS AMT certificate, AD Object created AD Container, and the only digest user available after a SCCM provision is the remote admin (which SCCM scrambles the password forcing Kerberos authentication).



  • If the OS Host Name changes, when it boots the OS will register it’s FQDN (which no longer matches AMT’s) to the IP address
  • For TLS connection to work properly, you have to connect with FQDN the certificate was issued to, but the only FQDN that resolves is the new one which no longer matches the AMT certificate that was issued.  SCCM does not ignore invalid certificates when it comes to amt / vPro client management.
  • Since the AD object in the AD container was created with the attribute information stating the FQDN, trying to do Kerberos authentication over the new FQDN is not going to work.
  • Now you can ignore the invalidity of the certificate and connect with digest user; however, the only digest user that SCCM uses or allows to exist natively is the Remote Admin Digest user (which as noted above, the password is encrypted within the SCCM database).

 


There are 2 approach (most likely couple additional if we continue to brainstorm) that could be taken allowing the box to be unprovisioned once an OS rename has occurred.  Which since you are trying to do this via script, I would recommend using the unprovisionex utility or vbs scripts that performs a partial unprovision.



  • Temporarily create a resolve record (in DNS or host file) that matches the old FQDN.  After which, you should be able to connect with a Kerberos user and perform a partial unprovision (via the unprovisionex utility or vbs scripts).
  • After the box has been provisioned by SCCM, add a digest user with PT Admin rights via script (script would need to connect to the amt client with kerberos so you want to do this before the OS rename).  Since you will know what the user name and password is (unlike the remote admin that SCCM has stored), you should be able to connect (ignoring the invalid certificate) with the unprovisionex utility or vbs scripts that performs a partial unprovision after the OS has been renamed.

 

After either of these, I would just have the agent initiate provisioning via policy to re-provision the client when the OS build was finish with it's new name

Now in all technicality, you could change the hostname in AMT, request a new AMT Certificate request from CA & pushed to AMT client, and have an AD Object created with the correct hostname all via script without having to reprovision the AMT client.  However, this is all the same stuff that happens during first stage provisioning within SCCM.  So I would recommend allowing SCCM to reprovision the box natively so that it’s in a known Microsoft supported configuration.
Reply
Dec 17, 2008 9:03 PM Trevor Sullivan Trevor Sullivan    says in response to Matt Royer:

Matt,

Thanks for your excellent feedback. You nailed most of the issues on the head, and I think that especially your 2nd option for resolution (adding a temporary digest user) is a great idea! That is exactly why I solicited other people's feedback, because I knew there were pieces missing that someone else could fill in.

Regarding your first solution, which involves adding a DNS resource record to allow you to connect to the AMT device: Wouldn't you have to also have a corresponding PTR record for Kerberos authentication to work properly? With the way that, at least our DNS is configured, the PTR record would already have been updated by the operating system, at this point in the process. If we can get away with just having an A record (or maybe even a CNAME record), then this shouldn't be too much of an issue, as long as I can figure out a way to update DNS programmatically. I think we're set up to have the DHCP service register DNS resource records on behalf of the client, though.

With respect to the idea of adding a 2nd digest user: This definitely sounds more feasible, unless we want to deal with the potential for Kerberos authentication issues due to incorrect DNS (which I’ve had more than my share of already). The only challenge I can see with this approach, is the requirement to continually watch the amtopmgr.log for the initial OOB provision success, at which point, the script would have to add the digest user before the operating system gets loaded. There should be a sufficient window of time, but this would still need to be accounted for.

Your train of thought is the same as mine though: once the operating system and the ConfigMgr client are installed, you would simply reprovision the device using agent-initiated provisioning. Once ConfigMgr sees that the system has the ConfigMgr agent installed, it will reject packets anyway, so we wouldn't have to worry about it getting provisioned OOB a second time at that point.

Let me make some revisions to the document, based on your recommendations, and I'll see if we can't work this concept a little closer to reality. I may need to develop some sort of flowchart to make visualizing the process a little bit easier.

Josh offered to test this out in his lab, since I don't have certain resources available to me, such as a trusted provisioning certificate for my lab.

Thanks,

Trevor Sullivan
Reply

Actions

Popular Blog Posts