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

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

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:

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

Hello vPro community!

I rather quickly posted the Powershell code I got functioning yesterday just to make sure that I didn't forget to post it at some point, but if you're new to Powershell, you might not understand everything that's going on here. If I left your head spinning, then I apologize, but tonight, I'm wrapping back around to help describe to you the thought process behind the script I posted!

On top of that, once I put together some notes from earlier today, I will post later on about some of my newest findings! To give you a teaser, I found a method of setting AMT power profiles using Powershell code! I'll be sure to get this posted as soon as I can, but for now, I think it would be most beneficial to understand the basics of connecting to a vPro system.

I'm going to step through the script line-by-line and leave some comments about each of them. Comments will be denoted by lines beginning with a pound sign (#). This is because Powershell uses this character as a "comment" character.

If you're experienced with .NET, then you'll probably either already know about, or want to get familiar with, the tool known as the .NET Reflector. This utility allows you to "reflect" over a .NET library, and discover the objects, methods, and properties that are available to you to use in your Powershell scripts. It's not always a simple task to figure out how to use .NET objects, especially if there is either poor documentation, or none at all, but this tool definitely makes it easier.

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

# The following 6 lines are simply variables that we are setting

# to make troubleshooting and customizing our script easier.

# We will be instantiating (creating) an object of the data type

# "AmtSystem" that requires these values as params to its

# constructor method.

# This is the domain\userID we want to authenticate as

$amtusername = "vprodemo\DomainUser"

# This is the password for the user account to authenticate
$amtpassword = "P@SSW0Rd"

# This is the FQDN of the vPro client system we want to connect to
$amthostname = "vproclient.vprodemo.com"

# This is the TCP port that we want to connect to the vPro client on

# TCP 16993 is used for TLS communications to AMT clients

$amtport = 16993

# This parameter determines whether or not your password is

# saved in the AmtSystem object (I think)
$amtrecallpassword = $false

# I haven't verified this, but I believe that this parameter determines

# whether or not WS-MAN is used exclusively on vPro clients

# that support it. Otherwise, it will attempt to use EOI (SOAP).
$amtwebservicesonly = $false

# Next, this variable stores the path to the "Manageability Stack.dll"

# which is included with the Intel AMT Developer Toolkit (DTK).

# Be sure to download the latest version from the Intel website.

# This DLL is a .NET library, written in C#, that provides an API

# to interact with Intel vPro clients.

$manageabilitystack = "C:\Program Files\Intel\Manageability Developer Tool Kit\0.6.08325.2\Manageability Stack.dll"

# This line uses the built-in Assembly class (part of .NET reflection)

# to load the .NET DLL containing the AMT API. The Out-Null Powershell

# cmdlet is used to suppress any console output of the LoadFile() method.

[System.Reflection.Assembly]::LoadFile("$ManageabilityStack") | Out-Null

# The Write-Host cmdlet is built into Powershell and simply writes

# some text to the console. We are using inline variables to dynamically

# display the information about the client we're connecting to.

Write-Host "Connecting to $amthostname on port $amtport"

# This is the line that's actually getting the object that we will use to

# reference our target Intel AMT client. We are creating a global variable

# name "amtdevice" and setting its value to a "New-Object" of datatype

# ManageabilityStack.AmtSystem (you can use .NET Reflector to find this)

# and then passing the parameters that we defined before to its constructor.

# If the below line wraps in your browser, please be sure to put it all on one line in your script.

$global:amtdevice = New-Object ManageabilityStack.AmtSystem -ArgumentList $amthostname,$amtport,$amtusername,$amtpassword,$amtrecallpassword,$amtwebservicesonly

# Footnote: With respect to variable scope in Powershell, the reason I am

# defining this as a global variable explicitly, is because if you copy and paste

# this code into a script, and then run that script from within an interactive

# Powershell session, the $amtdevice will now be defined as global to the session

# and will not be deleted when the script exits. This allows you to run the script to

# retrieve the device object, but then continue to work with it interactively once

# the connection is established!

# Tell the AmtSystem object that we want to use TLS

$amtdevice.UseTls = $true

# Enable WS-MAN support (if available) on the connection
$amtdevice.WsManSupport = $true

# Once we've set up all of our configuration options about the connection,

# this next line actually establishes the connection.

$amtdevice.Connect()

# The "State" property of the AmtSystem object is "Connecting" until the

# connection either succeeds or fails. We want to monitor the status until

# this occurs.

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

# Finally, once the connection either succeeds or fails, we write out the

# State property to the console so that we know what the outcome was.

Write-Host "AMT device is in state $($amtdevice.State.ToString())"

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

So, there you have it. That is the code, with my comments inline. If you have any questions or feedback on my articles, please feel free to comment on this blog article. I will try my best to answer them, although please understand that I am still working on comprehending this great API! If this is useful to any of you, I would like to know that, and if not, then please recommend something that you would like to hear about!

As promised, I will eventually write another follow-up article on how you can set Management Engine (ME) power profiles on a provisioned AMT client remotely, using Powershell! Until next time ...

Happy Powershell Scripting!!

Trevor Sullivan

Systems Engineer

OfficeMax Corporation