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

Hello,

This is my first contribution to the Intel vPro Expert center, and although I would not consider myself an expert on this product, I've still been graciously allowed to post here. Thanks Josh!

I'd like to start out by introducing myself. My name is Trevor Sullivan, and I am a desktop systems engineer at a large retail corporation. Over the past 8 months or so, I've been working quite a bit with several people from Intel and Microsoft to better understand the Intel vPro technology, and how it can benefit my company. Overall, I'm really impressed with the technology, and I am fortunate enough to be working with an environment that has a pretty decent install base of Intel vPro-enabled systems.

I'd like to take a few minutes to explain a few issues that we recently experienced with our production vPro implementation.

-

Provisioning Certificate Chain Invalid

We're using Intel vPro with Microsoft Configuration Manager 2007 SP1, and for a while, we had been running into issues that prevented us from provisioning a vPro device. It turns out that the reasoning behind this was related to our provisioning certificate. We requested a certificate from Verisign, and imported it into our central SCCM site server. We have several child primaries to our central SCCM primary site server, however, and we were using the same provisioning certificate on those systems (Intel confirmed that this was possible).

When I exported the certificate (using the Certificates MMC snap-in), with its private key, from my central SCCM site server, I did not choose the option to export the certificate chain with it. Importing the certificate, with its private key, went just fine on the other SCCM primaries, but provisioning just didn't work. After working with Bill York from Intel for several hours, it was finally determined that the Verisign Class 3 Intermediate Certificate Authority's public key certificate was expired in the Intermediate certificate store on the SCCM site server running the out-of-band (OOB) service point. I imported the updated Verisign Intermediate certificate into the server's Intermediate CA certificate store, which resolved the issue I was having.

If you are experiencing this specific problem, you should see something like the following in your amtopmgr.log on the SCCM site server running the OOB service point:

Try to use provisioning account to connect target machine vprosystem.subdomain.mydomain.com...

Server unexpectedly disconnected when TLS handshaking.

**** Error 0x382b948 returned by ApplyControlToken

Although this probably should have been obvious to me, I did not actually open the provisioning certificate on the server I had imported the certificate on, to verify that the certificate was valid. If I had done so, I would have seen a message stating that the certificate was invalid, and then I could have looked at the certificate chain tab to see that the Verisign Intermediate CA's certificate was not valid. After examining the certificate for the Intermediate CA, it was determined that it had expired, causing my provisoning certificate to become invalid.

-

Microsoft PKI -Auto-Approval of Pending Certificate Requests

After resolving the certificate issue, we started seeing another issue. This issue was related to our internal Microsoft PKI. The next symptom we saw was again in the amtopmgr.log file (+in case you haven't figured it out, this is probably the most useful AMT log in SCCM). Here are the messages we saw:

Send request to AMT proxy component to generate client certificate. (MachineId = 60752)

Successfully created instruction file for AMT proxy task: D:\SMS\inboxes\amtproxymgr.box

RETRY(1) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(2) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(3) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(4) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

AMT Provision Worker: Wakes up to process instruction files

AMT Provision Worker: Wait 20 seconds...

RETRY(5) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

Error: Missed device certificate. To provision device with TLS server or Mutual authentication mode, device certficate is required. (MachineId = 60752)

Error: Can't finish provision on AMT device vprosystem.subdomain.mydomain.com with configuration code (0)!

>>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<<

What this is telling you, is that the OOB service point was unsuccessful with its attempt to generate and retrieve a web server certificate, for the vPro client, from your internal Microsoft CA (either root or subordinate, but in our case, a subordinate). Although we had duplicated and configured the web server certificate template on our CA, the certificate was not getting created as we expected. The issue, in this case, was that our CA was not configured to automatically approve pending certificate requests.

In order to resolve this issue, follow these steps:

1. Open the Certification Authority MMC snap-in and connect to your CA

2. Right-click the CA node, and select Properties

3. Select the "Policy Module" tab

4. Click the Properties button

5. Choose the lower radio button (It reads: "Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate.")

6. Click OK on all dialog boxes

7. Restart the CA service, to allow the setting to take effect

-

I have a few more issues I'd like to talk about, mostly related to DNS. I will post again with details.

Thanks for reading,

Trevor Sullivan

Systems Engineer

We had the Intel vPro technology Challenge at MMS 2008 - a competition where teams of two competed to fix a troubled PC using Microsoft System Center Configuration Manager 2007 with PCs with Intel vPro technology. Check out how much fun this Challenge was at MMS 2008 this year:

]]>

To see more videos from MMS 2008, go to: http://www.intel.com/go/mms/

When Intel released Intel vPro technology into the marketplace in 2006, the press asked us what the "v" in Intel vPro technology meant. Now that the technology has been in the marketplace for almost two years, we thought that the best answer to the question, "What does the "v" in Intel vPro technology mean to you?" would come from Intel customers, as well as from some of the technical experts from Intel and our partners who deal with our customers on an almost daily basis. See their answers below.

]]>

To see more videos from MMS 2008, go here: http://www.intel.com/go/mms/

We are going to have Matt Royer join us again on the show. Josh, Russ, & Jeff Torello will be getting the latest information on WS-MAN translator integration and SMS/SCS to SCCM Migration. Hope you are able to join us!

When: April 21st @ 3:30 PM

Call-in Number: (347) 326-9831

Check out these blog posts from Matt Royer to get an insight on what our show will be about:

SCCM SP1 & WS-MAN Translator: How vPro firmware versions less than 3.2.1 are supported

Overview of SMS/Intel SCS migration to SCCM SP1

http://www.blogtalkradio.com/openport

Here's the scoop, yet again, for those who haven't heard...

Hosted by Josh Hilliker, Russ Pam, & Jeff Torello this bi-weekly informal show will be covering a variety of topics and is a perfect avenue to get your questions answered. Listen in live, give your two cents, or just download the show after it has aired. Make sure not to miss out on this awesome opportunity to learn and engage with the vPro experts. Can’t join us live? Have no fear, blogtalkradio let’s you listen to the show whenever you have the time. Visit the Open Port Radio site (link is above) to hear previous shows and even catch a glimpse of what’s to come!

Note: This information is based off Microsoft System Center Configuration Manager 2007 SP1 RC and is subject to changes between now and RTM

So as you read through the Microsoft documentation for SCCM SP1, you will most likely notice that Microsoft SCCM SP1 states they have native support for vPro clients with firmware versions 3.2.1 or higher. If Microsoft only natively supports vPro clients 3.2.1 or higher, you may be asking how vPro clients that are running firmware versions 2.x, 3.0, and 3.1 are supported.

Not to worry; through the use of the Intel WS-MAN translator, SCCM SP1 will be able to provide provisioning and manageability support for earlier versions of vPro firmware. As part of SCCM SP1 Release Candidate, Microsoft has introduced integration support for the WS-MAN Translator (It was not available as part of the initial SCCM SP1 Beta release).

In a future blog, we will provide a little more detail on the Install, Configuration, and SCCM Enablement of the WS-MAN translator; however, let us take this opportunity to talk little more about SCCM SP1 interaction with the WS-MAN Translator.

So why doesn't SCCM support earlier vPro firmware versions? The core reason is that SCCM only know how to communicate to vPro Clients in WS-MAN (Web Service Management). Prior to AMT firmware version 3.0, vPro Client only knew how to communicate in a protocol called EOI (External Operations Interface). So just like one person speaking English to another person that only understands French, when SCCM SP1 tries to communicate with a vPro client with a firmware version of 2.x, the vPro client does not understand what the management console wants it to do. So, simular to a person translating for our French and English speaking persons, the WS-Translator translates WS-MAN calls to EOI and from EOI to WS-MAN.

Ok, so vPro clients with AMT version 3.0 know how to speak WS-MAN. Why do you need the translator for firmware version 3.0 and 3.1? Well without getting into the excessively technical details, there were some changes required in the AMT 3.x firmware to make SCCM SP1 work properly with vPro client running firmware 3.x; these changes were introduced in vPro firmware version 3.2.1. To allow for vPro firmware 3.0 and 3.1 to be supported, we were able to mask those changes that SCCM SP1 required in the WS-MAN Translator.

The other thing that the WS-MAN translator enables is support for PSK vPro Client provisioning. Natively, Microsoft SCCM SP1 only supports PKI (also commonly referred to as Remote Configuration) for provisioning. vPro firmware version 3.0 supported PKI provisioning from the initial release; however, vPro firmware version 2.x did not received PKI provisioning support until versions 2.2 & 2.6. Although we recommend that you upgrade your vPro firmware to the latest version supported by the OEM, there may be some cases were upgrading 2.2 or 2.6 is not a viable option. So to support clients that are running 2.0, 2.1 and 2.5 firmware, the WS-MAN translator offers a means of supporting PSK provisioning. The key item to keep in mind about PSK support within the WS-MAN translator is that it only supports one PID/PPS pair; the same PID/PPS will be used for all your vPro Clients using PSK for provisioning.

If desired, you can use PSK provision through the WS-MAN translator for all vPro firmware versions; however, since SCCM SP1 only uses the WS-MAN Translator for firmware versions less then 3.2.1 you are required to use PKI provisioning for any vPro Client firmware version 3.2.1 or higher. It is for this reason (and the fact that you can take advantage of vPro Remote Configuration) that we recommend you upgrade your vPro Clients to 2.2, 2.6, and 3.2.1 were supported by the OEM.

If you have no vPro Clients in your environment that are less then firmware version 3.2.1, there is no need to use the WS-MAN translator; SCCM SP1 will natively provision and manage vPro clients without the need for the WS-MAN Translator.

As previously noted, stay tuned for more information on vPro Expert Center about the WS-MAN translator in the next couple weeks.

Matt Royer

The Intel® Active Management Technology's (Intel® AMT) Setup and Configuration Service (Intel ®SCS or SCS) provides developer or ISV with the tools to set up and configure Intel AMT devices. The Setup and Configuration Service (SCS) allows for most aspects of setup and configuration to be completed through a remote management console. The service package consists of a configuration engine and installer in binary form, plus a reference graphical user interface that the ISV may integrate into their Manageability Product.

So where is the Intel® SCS in Microsoft System Center Configuration Manager (SCCM) SP1? The short answer is MS SCCM SP1 does not use the Intel SCS. The longer answer is that Microsoft, as part of their architectural design of SCCM SP1, has chosen to develop their own mechanism for performing the initial provisioning and configuration of the Intel® vPro Clients. This is different from the requirement the Intel Client Manageability Add-on for SMS 2003 had on the Intel SCS for enterprise provisioning and configuration.

Each ISV, as part of their enablement of vPro Management Technology within their product, can choose to leverage the Intel® SCS or use it as a reference design to develop their own implementation. Microsoft, with SCCM SP1, is not the only ISV that chose to develop their own capability for provisioning and configuring vPro Client; did you know that LANDesk also does not use the Intel SCS for vPro Client provisioning and configuration?

Matt Royer