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.

Register now at:  http://webcasts.techrepublic.com.com/abstract.aspx?docid=1177231&tag=content;rightCol

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

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

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:

1. Download the Intel AMT DTK source code and extract to a folder
2. Navigate to <Source>\Manageability Stack and open the Manageability Stack.csproj file in Visual Studio 2008
3. Open the AmtSystem.cs file in the Visual Studio Solution Explorer
4. Rename the Connect() method to ConnectAsync()
5. Copy the following code above the ConnectAsync() method:
   public void Connect()
   {
      if (State != AmtSystemObjState.Disconnected) return;
      ChangeState(AmtSystemObjState.Connecting);
      ConnectEx(this);
   }
6. In the Visual Studio Solution Explorer, right-click the Manageability Stack project, and click Build
7. 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

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

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

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:

1. Load the "Manageability Stack.dll" .NET library
2. Create an instance of the ManageabilityStack.HeciWrapper object
3. 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

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