Intel vPro Expert Center Blog

PC Refresh Cycles and Windows 7 … what’s the financial connection?

julie.a.whitcraft@intel.com — Tue, 24 Nov 2009 04:29:06 GMT

It’s understandable that in today’s economy that you might consider pushing out your PC refresh cycle to save cash today. This is an area of cost cutting that many companies consider so you’re not alone. But if you have considered, or are considering, pushing out your PC refresh cycle, have you factored in all of the costs that impact that decision? These costs include the unexpected costs of supporting older machines once the warranty has expired, higher energy costs compared to new machines, and more. The total cost of ownership starts to increase out in time and will eventually reach a point where it makes more sense to replace your PCs versus continuing to maintain them. But how do you know what the optimal replacement time is? And is delaying your refresh really the best financial decision?

There are strong financial reasons to refresh PCs now and, with the Windows 7 operating system, there are even stronger reasons to do so with PCs powered by Intel® Core™ 2 processors with vPro™ technology. Join me for a webcast on Tuesday, December 1^st, where I’ll walk through our analysis on the PC refresh cycle and the framework we use, discuss the true cost of older PCs and how to assess your own PC refresh cycle, and share our experience with Windows 7 as part of the Technical Adopter Program (TAP). I’ll also be joined by Amy Stephan from Microsoft who will provide more insight into why it makes sense to refresh now and why Windows* 7 and New PCs with Intel® vPro™ Technology are better together.

Finding AMT Objects in Active Directory

pcgeek86@gmail.com — Wed, 11 Nov 2009 21:03:38 GMT

If you are using Out Of Band (OOB) Management in Microsoft System Center Configuration Manager (SCCM) 2007 SP1 (or greater) to manage your Intel vPro clients, you may have noticed that computer objects are created in your Active Directory domain during provisioning of the Intel vPro firmware. These computer objects are created by the amtproxymgr component of an OOB Service Point, and allow Intel vPro to communicate directory with Active Directory, regardless of the operating system state.

Since these vPro computer objects appear very similar to standard computer objects that are created when joining a Windows OS to an AD domain, it may be hard to distinguish which ones are vPro accounts, and which ones aren't. This situation can be worsened if you somehow have Windows computer accounts mixed into the same OU that contains your AMT objects.

As you'll see below, it's very easy to locate these computers using some simple PowerShell code:

$vprosearcher = [adsisearcher]"(&(objectclass=computer)(serviceprincipalname=*:16993*)(samaccounttype=805306368))"
$vproaccounts = $vprosearcher.FindAll()

These two lines of code simply create a System.DirectoryServices.DirectorySearcher instance, with some LDAP search criteria to identify the accounts, and then assigns the results of this search to a PowerShell variable called $vproaccounts. The default search root is the top-level of your Active Directory domain, and the default search scope is already set to SubTree, so you don't have to specifically configure these settings on the DirectorySearcher. Once you're at this point, you can simply enumerate the accounts, or pipe the results into a PowerShell ForEach loop, and perform some operation against them (for example, givem them a Description attribute value).

Because this code sample uses the "adsisearcher" type accelerator (aka. type shortcut), it will only work with PowerShell v2.0 (included as part of the Windows Management Framework), unless you modify PowerShell v1.0 to include it. There's almost no reason not to be using PowerShell 2.0, now that it has been officially released, however.

I recommend using the free Quest PowerGUI tool to develop and debug PowerShell scripts.

Cheers,

Trevor Sullivan

A Closer Look at ConfigMgr SP2

pcgeek86@gmail.com — Wed, 22 Jul 2009 14:51:09 GMT

Matt Royer wrote in June about some of the new AMT-related features being included in Service Pack 2 for Microsoft System Center Configuration Manager 2007. I recently installed ConfigMgr SP2 in my lab environment, and wanted to follow up on Matt's post by sharing some screenshots of the new AMT features, for those of you that may not be beta testing SP2

** The updated AMT Settings screen, which now features the option to set the power package for the management controller.

** The new Provisioning Schedule screen (no more editing your sitectrl.ct0 file!)

** The new main 802.1x & Wireless Profile Configuration screen (there are a couple of detail screens below)

** The new Wireless Profile Detail screen

** The new 802.1x Profile Detail screen

I don't have a provisioned client in my lab yet, but once I do, I will see if I can investigate the updated Microsoft OOB Console, and capture some screenshots. As Matt's post stated, there should be added functionality for inputting information into the 3PDS (Third-party data store), so I assume there will at least be that change.

Cheers,

Trevor Sullivan

Systems Engineer

AMT / ConfigMgr SQL Query: Mismatched Hostnames

pcgeek86@gmail.com — Tue, 21 Jul 2009 18:50:10 GMT

In IT environments where device naming standards may be coarse, or where users can freely rename their systems at will, you may experience problems managing these clients' AMT firmwares. Since, in order to maintain proper AMT functionality, the OS and AMT hostnames must match, an IT administrator or engineer would likely be interested in finding out which machines do not meet this criteria.

With that in mind, I've written a simple SQL query, that can be run against your Configuration Manager database, to determine what devices have mismatching OS and AMT hostnames. I've pasted the text below, but if you want a more nicely formatted version, please see this link at PasteBin.

/*
Author: Trevor Sullivan

Date: Tuesday, July 21st, 2009

Purpose: Identify devices whose AMT hostname and OS hostname mismatch
in the Configuration Manager database

select
-- Active Directory site name
[AD_Site_Name0] as 'AD SiteName'
-- AMT hostname (in provisioning record)
, [amt].[HostName] as 'AMT HostName'
-- OS hostname (should match AMT firmware)
, [sys].[Name0] as 'OS Hostname'
-- Retrieve UserID to identify device owner
, [UserName0] as 'UserID'
-- Hardware vendor
, [cs].[Manufacturer0] as 'Vendor'
-- Device model
, [cs].[Model0] as 'Model0'

from v_AMTMachineInfo [amt]

-- Join v_R_System to retrieve AD Site Name field
join v_R_System [sys] on [sys].[ResourceID] = [amt].[MachineID]
-- Joinv_GS_Computer_System to allow us to retrieve make/model information
join v_GS_Computer_System [cs] on [sys].[ResourceID] = [cs].[ResourceID]

where
-- We only want current resource records from ConfigMgr
[sys].[Obsolete0] = 0
-- This condition determines the mismatching hostname in the v_R_System and v_AMTMachineInfo SQL views
and [sys].[Name0] <> [amt].[HostName]

Cheers,

Trevor Sullivan

Systems Engineer

OOB Console Error

pcgeek86@gmail.com — Mon, 22 Jun 2009 20:50:08 GMT

Hello vPro Experts!

Are you having trouble getting the Microsoft Out-of-Band (OOB) Console to connect to your Intel vPro clients? If so, one of the first things you should do, is enable verbose logging in your OOBConsole.exe.config file. This file is located in the following folder: %PROGRAMFILES%\Microsoft Configuration Manager Console\AdminUI\bin. If you open this file in Notepad, you should see a line that looks like <source name="OOBConsole" switchValue="Error">. If you change the text Error to Verbose, you will enable verbose logging for the OOB Console. The next time you try to connect to an AMT device, you should start seeing more detailed logging in the OOBconsole.log file, located in: %PROGRAMFILES%\Microsoft Configuration Manager Console\AdminUI\AdminUILog.

If you're seeing this message specifically: GetAMTPowerState fail with result:0x800401F3, then you might have forgotten to install WinRM 1.1 on your Windows XP client running the OOB console. Also make sure that you're running Windows XP Service Pack 3! Once you install WinRM 1.1, this error should magically disappear, and have you well on your way to managing vPro devices!

Cheers,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Microsoft OOB Console Requirement

pcgeek86@gmail.com — Mon, 08 Jun 2009 17:24:06 GMT

Hello vPro Experts!

I would like to pass on some information that I discovered a while ago, based on a Microsoft Premiere Support ticket. I was having trouble getting the Microsoft Out-of-Band (OOB) Management Console functioning from a Windows XP system. I tried everything on a fresh, standard build of Windows XP, but nothing would work.

After working with Premiere Support, we finally discovered that Windows XP Service Pack 3 (SP3) was required for proper functioning of the Microsoft OOB console.

This behavior is actually related to some functionality that was added in SP3, specifically in the winhttp.dll library. There is a function called WinHttpSetOption in the WinHttp library, which is called with a parameter enabling the WinHttp Option Flag named WINHTTP_ENABLE_SPN_SERVER_PORT. This flag enables the WinHttp library to include the server port in the Kerberos Service Principle Name (SPN), since the AMT web service is running on a non-standard HTTP port (16993).

The Windows XP Service Pack 2 (SP2) version of the WinHttp library does not include this capability, and consequently fails to authenticate. In order to properly connect to ConfigMgr-provisioned AMT devices with the Microsoft OOB Console, please make sure your helpdesk / support systems are running Windows XP SP3.

If you have any questions, feel free to post them in the comments section, and I will do my best to answer them.

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Intel AMT DTK: Synchronous Connections

pcgeek86@gmail.com — Tue, 02 Jun 2009 20:17:27 GMT

Hello vPro Experts,

In case you've worked with any of the Powershell code samples I've previously posted, you've probably noticed that the AmtSystem.Connect() method executes asynchronously, and returns immediately. In this case, you'd have to develop some sort of loop in order to determine whether or not the connection was successful. Typically, I would just use this code to prevent a script from continuing before the connection was established:

while ($amtdevice.State -eq "Connecting") { Start-Sleep 1 }

But that's ugly, because, what happens if it never connects? Although it's nice to have the ability to asychronously connect to AMT devices, writing code and understanding the logic, to handle async processes is significantly more difficult than writing code that is synchronous. For this reason, we will look at how to modify and recompile the ManageabilityStack .NET assembly in the Intel AMT Developer Toolkit (DTK) to allow synchronous connections to AMT from PowerShell code.

In order to perform the next steps, you'll need the following:

The Intel AMT DTK source code
Microsoft Visual Studio 2008 (the Express edition is fully functional and free!)
Microsoft Windows PowerShell 1.0 or 2.0 CTP3

Once you've installed these components, continue on:

Download the Intel AMT DTK source code and extract to a folder
Navigate to <Source>\Manageability Stack and open the Manageability Stack.csproj file in Visual Studio 2008
Open the AmtSystem.cs file in the Visual Studio Solution Explorer
Rename the Connect() method to ConnectAsync()
Copy the following code above the ConnectAsync() method:
public void Connect()
{
   if (State != AmtSystemObjState.Disconnected) return;
   ChangeState(AmtSystemObjState.Connecting);
   ConnectEx(this);
}
In the Visual Studio Solution Explorer, right-click the Manageability Stack project, and click Build
Go to your <Source>\Manageability Stack\obj\Debug folder, and grab your new ManageabilityStack.dll .NET assembly

Now that you have a recompiled ManageabilityStack assembly, you can load this into PowerShell, and connect synchronously using the Connect() method!

Update: I attached the AmtSystem.cs file to this blog post, if you're not comfortable modifying source code yourself! You'll still need to replace the file, open the project, and recompile the library though

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Microsoft Windows 7 Survey

kelsey.e.witherow@intel.com — Thu, 30 Apr 2009 21:15:55 GMT

On behalf of Josh Hilliker with the vPro Expert Center, please take a moment to participate in this survey we have created on the Microsoft Windows 7 upgrade. Thank you in advance! Your responses are appreciated.

Click the link below to take part in this survey!

http://www.surveymonkey.com/s.aspx?sm=Dsbce68_2b0qjcTPTQ0ereRg_3d_3d

Powershell: Controlling AMT Power States

pcgeek86@gmail.com — Sun, 19 Apr 2009 16:25:53 GMT

I wanted to quickly share an example of how to set the current power state of a provisioned Intel vPro system using Windows Powershell!

Take a moment, and ask yourself these quick questions:

Have you ever wanted to be able to automate the powering up, or powering off, of multiple computers?
Is your company interested in saving money by not needlessly leaving computers powered on at night?
Do you have a time-critical environment, such as a call center, where you need to reliably power up your computers so they are ready to go in the morning for agents?
Do you want to be able to create your own helpdesk tools to enable remote reset of hung systems?

If you answered "yes" to any of the previous questions, then hopefully this Powershell code will help you, as an administrator, achieve your goals! Let's take a look at how to perform the actions of:

Powering up a vPro (AMT) system
Powering down a vPro (AMT) system (not gracefully, just FYI)
Power cycling a vPro (AMT) system (also not graceful)

For the sake of simplicity, we'll continue to work with the ManageabilityStack.AmtSystem object that I have referenced in my previous article(s). If you aren't sure how to get the $Global:Amtdevice Powershell variable, please look back at my other articles. This will also require the download of the Intel AMT Developer Toolkit. You'll need the Manageability Stack.dll library contained within.

-------------------

In order to control the remote power state of an AMT system, all you really need to know are these 3 hex values:

0x10 = System reset

0x11 = Power on

0x12 = Power off

0x13 = Reset w/ power cycle

These hex values will be used with the $AmtSystem.Remote.SendRemoteControl() method to alter the power state of the remote system. The SendRemoteControl() method included with the DTK includes a number of parameters that go beyond the scope of this article, so we will pass hex value 0x0 to these parameters for the time being. In order to use the above hex values, simply pass the hex value as the first parameter of the SendRemoteControl() method. In order to fulfill the parameter requirements of this method, pass 5 additional parameters with the value 0x0. Here are some examples:

Powering up an AMT System

$Result = $AmtDevice.Remote.SendRemoteControl(0x11, 0x0, 0x0, 0x0, 0x0, 0x0)

Write-Host "Power command resulted with: ${Result}"

Powering off an AMT System

$Result = $AmtDevice.Remote.SendRemoteControl(0x12, 0x0, 0x0, 0x0, 0x0, 0x0)

Write-Host "Power command resulted with: ${Result}"

Power cycling an AMT System

$Result = $AmtDevice.Remote.SendRemoteControl(0x10, 0x0, 0x0, 0x0, 0x0, 0x0)

Write-Host "Power command resulted with: ${Result}"

The above samples show how to use the SendRemoteControl() method of the AmtRemoteControl .NET type in the Intel AMT Developer Toolkit (DTK) to control the power state of a remote AMT device.

If you have any questions about this, please leave a comment or send me a private message.

Sincerely,

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Upgrading the Intel® AMT™ Add-On for SMS from V3.3 to V5.0 Update!

liesa.harkness@hp.com — Fri, 20 Mar 2009 15:01:18 GMT

Murphy's Law states that just when you think you have shared all you have to give in a document you find a juicy tidbit that should have been included. Therefore, I have updated the Intel® AMT™ Add-On for SMS from V3.3 to V5.0 Upgrade OverviewPDF.

I discovered a batch file that is included in the default installation directory, C:\SMSAMTInstallation\iAMT addon for SMS\IAMTSMSSettingsExport.bat. Within it contains the command line to export the registry settings for your currently installed version of the Add-on.

Upgrading the Intel® AMT™ Add-On for SMS from V3.3 to V5.0?

liesa.harkness@hp.com — Wed, 18 Mar 2009 21:23:35 GMT

Before you upgrade the IIntel® AMT™ Add-On for SMS to the Intel® Client Manageability Add-On for Microsoft* SMS 2003 version 5.0 check out my document about the process and some things to keep in mind befor you begin.. Thanks! Intel® AMT™ Add-On for SMS from V3.3 to V5.0 Upgrade Overview

Integrating VNC and WinPE 2.x

pcgeek86@gmail.com — Tue, 10 Mar 2009 16:58:59 GMT

Integrating VNC on Windows PE 2.0

Author: Trevor Sullivan

Company: OfficeMax Corporation

Versions: 1.0 – April 24, 2008 – original document

Synopsis

Integrating VNC on Windows PE allows a remote user, such as a support person, to remotely control a Windows pre-execution environment, and perform administrative tasks such as deploying an operating system image, or diagnosing hardware and software problems using 3^rd party tools. This image can be remotely booted in a LAN environment using the IDE-R feature of Intel AMT.

Requirements

Microsoft Windows AIK v1.1 (downloadable from Microsoft)
A working Windows PE 2.x CD (can be built from WAIK)
UltraVNC 1.02 (downloadable from Internet)
ImageX (to mount WIM files) - included with WAIK

Setting up UltraVNC

Install UltraVNC 1.02 on a development system

You can optionally install UltraVNC 1.02 to an Altiris SVS virtual layer to avoid making permanent changes to your development system

After UltraVNC is installed:

1. Execute VNC in user-mode

2. Run the following command: winvnc –defaultsettings

3. You should be presented with a configuration dialog

4. Set a password for VNC and choose to disable the tray icon

5. Confirm the settings dialog, and stop Winvnc by running: winvnc –kill

6. Extract the following registry tree: HKLM\Software\ORL (vnc.reg)

7. Add the password to the default key

a. Open the registry file (vnc.reg)

b. Create a new section (key) for HKLM\Software\ORL\Default

c. Copy the password value from ORL to the Default key

Gathering Source Files

Copy the following list of files from the UltraVNC installation directory on the source computer into a separate working folder:

Authadmin.dll
Authssp.dll
Ldapauth.dll
Logging.dll
Logmessages.dll
Mslogon.acl
Unzip32.dll
Vnchooks.dll
Vnchooks_settings.reg
Vncviewer.exe
Winvnc.exe
Workgrpdomnt4.dll
Zip32.dll
Vnc.reg (from previous section)
Vnc.vbs (see below)

Trevor developed a short script to get around a problem with winvnc hanging when I’d execute it. This executes winvnc.exe asynchronously so that it continues to run in the background, but startnet.cmd will be allowed to continue. The script source is included below:

ScriptPath = Left(Wscript.ScriptFullname, len(Wscript.ScriptFullName) - len(Wscript.ScriptName))

set sh = CreateObject("Wscript.Shell")

sh.Run "regedit /s " & ScriptPath & "vnc.reg", 1, true

sh.Run "wpeutil disablefirewall", 0, true

sh.Run ScriptPath & "winvnc.exe", 1, false

Modifying the PE Disc

Mount WIM file on filesystem using ImageX
Copy all source files to folder on root of WIM mount path
Modify startnet.cmd to execute VNC vbscript using cscript.exe
- Use the fully qualified path to the script file (eg. “cscript X:\vnc\vnc.vbs”)

Notes

Winvnc does not work under service mode on Windows PE; Winvnc must be run under user context
The registry value “password” must exist under HKLM\Software\ORL\Default, otherwise winvnc will prompt for a password upon startup

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Powershell: Exploring the Management Engine

pcgeek86@gmail.com — Wed, 25 Feb 2009 04:26:00 GMT

Hello vPro Experts!

I would like to take some time to touch on exploration of the management engine via the local interface (specifically the HECI driver). In order to follow the exercise here, you'll need to have Windows Powershell installed, have the Intel AMT Developer Toolkit downloaded and installed, and have an AMT client (does not need to be provisioned) with the HECI driver installed. The HECI driver should be downloadable from your OEM.

To give you a high-level idea of the program flow we'll use to access the AMT device, consider the following:

Load the "Manageability Stack.dll" .NET library
Create an instance of the ManageabilityStack.HeciWrapper object
Reference the properties and methods of the HeciWrapper object, and the HeciMeInfo object (provided by the HeciWrapper.MeInfo property)

Here is the Powershell code that correlates to the above process:

Loading the .NET Library

# Load the Manageability Stack .NET library

$AmtLib = "C:\Program Files\Intel\Manageability Developer Tool Kit\Manageability Stack.dll"
[System.Reflection.Assembly]::LoadFile($AmtLib)
# Create a HeciWrapper object

$Heci = New-Object ManageabilityStack.HeciWrapper

# Pipe the $Heci variable into the Get-Member cmdlet to determine what properties

# and methods are available to us.

$Heci | Get-Member

Obtaining a list of embedded certificate hashes

# List embedded certificate hashes
$Heci.MeInfo.EnumerateHashHandles()

Getting the BIOS and AMT Versions

# Retrieve the AMT version
Write-Host "AMT version: $($Heci.Versions.Versions["AMT"])"
# Retrieve the BIOS version
Write-Host "BIOS version: $($Heci.Versions.BiosVersion)"

Retrieving Provisioning Information

# Retrieve the provisioning server name
Write-Host "Provisioning server: $($Heci.MeInfo.GetAuditRecord().ProvServerFQDN)"
# Determine provisioning date
# This will return "01/01/0001 00:00:00" if not provisioned
Write-Host "Provision date: $($Heci.MeInfo.GetAuditRecord().TlsStartTime)"
# Get provisioning mode (Enterprise, SMB, etc.)
Write-Host "Provision mode: $($Heci.MeInfo.GetProvisioningMode().ProvisioningMode)"
# Get provisioning state
Write-Host "Provision state: $($Heci.MeInfo.GetProvisioningState())"

-----------------------------------

I hope these code samples are able to help you out in your administration / engineering endeavors! Please let me know if you have any questions, and don't forget that in Powershell .... when in doubt .... use Get-Member to discover what information is available to you!

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Powershell: Enabling auto-provisioning on SCCM client

pcgeek86@gmail.com — Tue, 17 Feb 2009 05:01:39 GMT

Hello!

Have you ever run into the situation where you want to enable the auto-provisioning policy for a ConfigMgr client, but dont' want to wait for the policy to filter down to the client? If you're like me, then you would answer with a hearty "yes." Thankfully, I've got a method for you to force an SCCM client to enable auto-provisioning, without relying on the collection setting!

Keep in mind that, for some odd reason, pasting this code into a Powershell window will probably fail. Instead, paste the first 4 lines, and manually type out the last (red) line.

$OobSettings = [wmiclass]”root\ccm\policy\machine\actualconfig:CCM_OutOfBandManagementSettings”
$OobSettingsInstance = $OobSettings.CreateInstance()
$OobSettingsInstance.AutoProvision = $True
$OobSettingsInstance.SiteSettingsKey = 1
$OobSettingsInstance.Put()

Basically what this does is spawn an instance of the CCM_OutOfBandManagementSettings WMI class, sets two properties on it, and then writes it back to the system. This should enable auto-provisioning immediately so you don't have to wait!

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Fully Automated Enterprise Client Builds :: Toying with ideas ...

pcgeek86@gmail.com — Tue, 16 Dec 2008 15:25:09 GMT

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:

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)

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:

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"?)

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