Intel vPro Expert Center Blog

Dell Optiplex 755 BIOS Update (includes AMT update)

pcgeek86@gmail.com — Fri, 13 Mar 2009 15:15:51 GMT

Dell just released a new BIOS update for the Dell Optiplex 755 system, version A13. This update includes an AMT firmware update to version 3.2.3 also that resolves a couple of security issues. I just performed the update on an Optiplex 755 that I had already provisioned, and it didn't break anything

If you're deploying the BIOS update via a ESM software package, such as Microsoft System Center Configuration Manager (SCCM) 2007, you can automate the staging of the BIOS update (without forcing a reboot) using the following command line:

O755-A13.exe -noreboot -nopause

Get it while it's hot!

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

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

Setting Power Policies in Windows Powershell

pcgeek86@gmail.com — Tue, 09 Dec 2008 02:03:20 GMT

Hello Intel vPro Community!

I'm going to talk to you today a little bit about how to use Windows Powershell to set Intel vPro power profiles. I'll provide a quick bit of background first on what power profiles are, and why you'd want to be able to set them with Powershell.

Intel vPro power profiles are nothing more than a setting in the Management Engine that tells the AMT chip when to be powered up, and when not to be powered up. In some cases, you may want vPro to be inactive during sleep states, or after the computer has lost power (eg. UPS failure).

In my case however, I want vPro to be always active. This is problematic, because Microsoft Configuration Manager's implementation of a provisioning server doesn't give you the option of setting the active power profile. Instead, during provisioning, ConfigMgr sets the active profile to whatever index "5" is. You'll actually see this in the amtopmgr.log file on your OOB (Out-Of-Band) service point during the provisioning process.

Because ConfigMgr decides the default power profile during provisioning, I've decided that I wanted to change it. Because Windows Powershell is an awesome automation tool, and because Intel's AMT Developer Toolkit (DTK) offers a .NET library that I can use in Powershell, I figured that I would figure out how to do it!

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

You might remember my last post on how to use Powershell to connect to an AMT device. The process basically involves loading the aforementioned .NET DLL from the DTK, and then establishing a connection to the device. I didn't really get the opportunity to show you how to do a whole lot with it after making the connection though, so that's the purpose of this post! Let's go ahead and take a look at a few lines of Powershell code, so you can understand the retrieval, and setting of power profiles.

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

# In my last Powershell script, I used the $amtdevice variable

# to reference the AmtSystem .NET object. We'll assume at this point

# that you have already connected to the AMT device based

# on my last article.

$amtdevice

# By using the .NET Reflector tool, we can see that the AmtSystem

# object has a property called SecurityAdmin, which returns an AmtSecurityAdmin

# object.

$AmtSecAdmin = $AmtDevice.SecurityAdmin

# The AmtSecurityAdmin object has a method called GetPowerPackages().

# After examining this data type in .NET Reflector, we can filter for only the two

# properties we want to see, the profile ID, and its Name. We'll use the Powershell

# Select-Object cmdlet to filter this data.

$AmtSecAdmin.GetPowerPackages() | Select-Object -Property ID,Name

# You should get some output looking something like this:

# 12834f94-10fb-dc4f-968e-1e232b0c9065 Desktop: ON in S0
# ab0086a1-7f9a-424c-a6e6-bb243a295d9e Desktop: ON in S0, S3
# acab8672-b496-e248-9b9e-9b7df91c7fd4 Desktop: ON in S0, S3, S4-5
# 4dcd327b-be6b-8943-a62a-4d7bd8dbd026 Desktop: ON in S0, ME Wake in S3
# 46732273-dc23-2f43-a98a-13d37982d855 Desktop: ON in S0, ME Wake in S3, S4-5
# baa419c5-6f6e-4d8d-b227-517f7e4595db Desktop: ON in S0, S3, S4-5, OFF After Power Loss
# ede30bd6-c504-462c-b772-d18018ee2fc4 Desktop: ON in S0, ME Wake in S3, S4-5, Off After Power Loss

# Once we have a listing of the power profiles available on the AMT device

# we can get the one that we want, and then set it. Since I always want my

# AMT device active, no matter the system's power state, I'm going to choose

# "Desktop: ON in S0, S3, S4-5" which is index 2 (in a zero-based collection).

$TargetPowerProfile = ($AmtSecAdmin.GetPowerPackages())[2]

# Now that I have a variable referencing the target power profile, I will set the

# profile on the AMT device. The AmtSecurityAdmin object has a method called

# SetActivePowerPackage() that takes one parameter: the power profile we have

# a reference to.

$AmtResult = $AmtSecAdmin.SetActivePowerPackage($TargetPowerProfile)

"Setting power profile to $($TargetPowerProfile.Name) resulted in $AmtResult!"

##### End Setting Power Profile #####

# Let's also take a quick look at how to get some basic information about

# the AMT device's provisioning data. We can figure out if IDE-R, SoL, and the

# WebUI are enabled. We'll use the AmtGeneralInfo object for this.

# Get a reference to the AmtGeneralInfo object

$AmtInfo = $amtdevice.Info

# Write out the current configuration settings

"SOL Enabled: $AmtInfo.SerialOverLanEnabled"

"IDE-R Enabled: $AmtInfo.IdeRedirectEnabled"

"WebUI Enabled: $AmtInfo.WebUiEnabled"

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

I hope this helps get you on your way to doing some cool Powershell / vPro automation! Let me know whether or not this helps you in your endeavors

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

Intel AMT, Windows Powershell, and You

pcgeek86@gmail.com — Wed, 03 Dec 2008 03:36:40 GMT

Hello everyone!

I have been working on understanding the Intel AMT Developer's Toolkit (DTK) so that I can begin developing some custom tools around Intel vPro. One of the tools that I am planning on working with is Microsoft's Windows Powershell. Windows Powershell is a very powerful, object-oriented command-line replacement for Windows XP, Vista, 2003, and 2008. It's an administrative scripting language that is significantly more powerful than VBscript, and has the entire power of the Microsoft .NET Platform behind it.

Just today, I've had my first success in using the Intel DTK with Windows Powershell, in my quest to automate Intel vPro related tasks using Powershell!

This is some really cool stuff, and I just had to get it out there to share with the community. I can't wait to see what else people build off of this!

Here is the first sample code that I've gotten to function correctly. I'm using it against a Dell Optiplex 755 running AMT firmware version 3.2.1, which was provisioned through ConfigMgr SP1.

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

$amtusername = "vprodemo\DomainUser"
$amtpassword = "P@SSW0Rd"
$amthostname = "vproclient.vprodemo.local"
$amtport = 16993
$amtrecallpassword = $false
$amtwebservicesonly = $false

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

[System.Reflection.Assembly]::LoadFile("$ManageabilityStack") | Out-Null
Write-Host "Connecting to $amthostname on port $amtport"
$amtdevice = New-Object ManageabilityStack.AmtSystem $amthostname,$amtport,$amtusername,$amtpassword,$amtrecallpassword,$amtwebservicesonly
$amtdevice.UseTls = $true
$amtdevice.WsManSupport = $true
Write-Host "TLS: $($amtdevice.UseTls), WsMan Support: $($amtdevice.WsManSupport)"
$amtdevice.Connect()

while ($amtdevice.State -eq "Connecting")
{
Start-Sleep 1
}
Write-Host "AMT device is in state $($amtdevice.State.ToString())"

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

Unfortunately that's all I can post for now, but I definitely plan on continuing work on this development!

Trevor Sullivan

Systems Engineer

OfficeMax Corporation