Intel vPro Expert Center Blog

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

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

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

The Manageability DTK, formally known as the AMT DTK, is now available for download

daniel.w.brunton@intel.com — Thu, 28 Aug 2008 17:58:22 GMT

The DTK is now available for download. Please note the new name: Manageability Developer Tool Kit. The Manageability DTK underwent internal review and improvements and is now available in conjunction with Intel's Open Source efforts. The compiled applications included with the Manageability DTK introduce a client limit of 20. This setting, along with other settings, options and features can be modified using the provided source code included with the Manageability DTK package. Please review the Manageability DTK release notes for a comprehensive list of updates and changes.

You can download the DTK at the following URL: http://softwarecommunity.intel.com/articles/eng/1034.htm

For on-going DTK questions and comments, please visit the Intel Software Network and the Intel vPro Expert Center online communities.

Intel AMT demonstration

ylian.saint-hilaire@intel.com — Tue, 29 Jul 2008 19:46:54 GMT

Hi everyone. A few days ago, I did a demonstration of Intel AMT at an Intel event. This is a standard demonstration of Intel AMT with reboot, remote BIOS edit and the unique TCP-over-SOL to perform a VNC session on a computer that has the operating system network stack disabled.

This video is also available in high quality within the YouTube site. You have to go into YouTube and click ont the high quality link. I am pretty impressed how must better the quality is when viewing it in high quality.

The VNC-over-SOL demonstration is probably my number one demonstration for WOW'ing an audience with Intel AMT. I sometimes also do demonstration on agent presence that is also unique to the DTK.

Ylian

Fun facts about the Intel AMT serial port

ylian.saint-hilaire@intel.com — Fri, 25 Jul 2008 07:30:15 GMT

I often get questions about the Intel AMT serial port. Ever since the DTK started to make heavy use of it, serial-over-LAN has gotten a lot of attention. First, how do you change the COM port number of the Intel AMT serial port? The COM number (COM3: for example) is assigned by the operating system, so you don’t see that is any AMT/BIOS/MEBx option. You have to go into Microsoft Windows Device Manager, go to the properties of the “Intel(R) Active Management Technology – SOL” port. Then go into the “Port Settings” tab and press the advanced button. There, you can change the COM port.

Also, it’s often useful for application to be able to automatically detect the AMT serial port. In Intel AMT Outpost, I scan the device drivers looking for the “Intel(R) Active Management Technology – SOL” device and read the COM port number that follows in that string. Sofar, it seems to work great, even in non-English countries, something I am always worried about.

The Intel AMT serial port is much like any other serial port, but it has a PCI device identifier that is not normally known to Microsoft Windows and so, Windows does not know what to do with this device. On Intel’s web site, there is an SOL driver available. The serial driver itself is just a small .INF that tells Microsoft Windows to load and use the standard serial driver. In fact, one can manually force the standard Windows serial driver to be used for this device. You need to go in the device manager and pick a driver from the list, select Microsoft as the manufacturer and you will see it. Even if it’s possible, I don’t recommend it because the DTK code will no longer recognize that COM port as being the AMT port, it’s going to work but will have the wrong name for auto-detection.

Lastly, if someone needed to know if a computer is AMT enabled without having to load any drivers, one way to do it would be to detect the presence of the Intel AMT serial port. It is always present even when AMT is un-provisioned, and it can’t be turned off, unless AMT is disabled entirely in MEBx. This can be a good way to figure out if you need to start considering a computer for AMT setup.

Ylian

(Intel AMT Blog)

Intel DTK Network Reflector and local manageability

ylian.saint-hilaire@intel.com — Wed, 14 May 2008 10:18:36 GMT

As many of you may know, there are two ways of contacting Intel AMT: The remote network interface and the local LMS/HECI interface. These interfaces are very different; the remote interface that is available thru the wired and sometimes wireless Ethernet and is rich with features while the local Intel AMT interface is very limited. Intel AMT was designed this way from the start for security. Intel AMT acting as an IT agent on desktops and laptops could not be allowed to be meddled with by the local user or local applications that could try to use or deactivate Intel AMT. That at least was the original design intent.

Times have changed it seems and many users of Intel AMT don’t see local users and applications as being always hostile. There are many reasons why it would be very interesting to access all of the features of Intel AMT locally. For example

If the user changes the name of the computer is the OS, it would be nice to have a local agent sync up the Intel AMT network with the OS name automatically. This way, when the computer goes to sleep next, Intel AMT will report the correct new name.
Circuit breaker policies could be used as a local firewall implemented in hardware. Set it once and the gigabit network chip does all the filtering and counters at gigabit speeds.
On a mobile platform, wireless profiles could also be synched up automatically. The user adds a new wireless profile with a WPA key and this profile is automatically added to Intel AMT.
Enterprise provisioning of Intel AMT could be done entirely locally using local software removing the need for complicated centralized servers.

Instead of seeing the local user as hostile, the local application now cooperate to setup Intel AMT so that if something goes wrong, it’s ready to be used to recover the computer. All this and more would be possible if Intel AMT allows the local applications full access to all the remote interface features.

A local application can’t simply connect to TCP port 16992 or 16993 and access all of the Intel AMT features since the traffic has to flow thru the gigabit network interface. Connecting to 127.0.0.1 will not work, that will access the more limited local interface.

A solution is to use a reflection application like Intel DTK Network Reflector found in the Intel AMT DTK. This tool runs on a central always on server and simply reflects back all TCP connections back to the source on ports 16992 to 16995. Using this tool an Intel AMT console or even a web browser can connect to "http://reflector:16992" and log into its own Intel AMT remote services. However, there are issues with this solution: You need this reflector tool running and know where on the network it is running. Also, a rogue application could log into the remote interface and put an annoying circuit breaker policy to drop all packets, etc.

In the future, Intel AMT itself could be modified to allow all services on the local interface removing the need for the reflector. There are security considerations of course, but feedback from users of Intel AMT on this idea would be appreciated.

Ylian (Intel AMT Blog)

My trip to see the Intel AMT development team - Israel & Jordon

ylian.saint-hilaire@intel.com — Wed, 07 May 2008 06:05:31 GMT

Last week Intel sent me to Israel for an Intel only gathering of engineers, architects and specialists that work on Intel AMT. I was honored to attend and also to be a speaker taking about the progress made with the DTK. First of all, I want to thank all of the people in Intel Israel for making this trip a great success. I also got to hear about many DTK success stories and it all of the hard work worth it. I was especially surprised with the DTK’s success in Asia, but also all over the world. I am still not sure if it’s the tutorial videos, the translations or what.

In addition to the meetings, we had a great time visiting the old city of Jerusalem, the Dead Sea and later on my own the city of Elat and Petra in Jordan. I got some of the most wonderful pictures and uploaded some on Google servers here:

http://picasaweb.google.com/ysainthilaire/Israel200802

These pictures cover the 10 days of my trip, starting with the old city then me playing in the mud and floating in the Dead Sea and finishing with my visit to Jordan. Jordan was probably this highlight of this trip, there is something just odd about traveling in this vast desert and realizing that I was in the country that had a common border with Iraq. For most of us in the US, it seems so distant. The city of Petra in Jordon has unique sand stone carvings in the walls. Some people will also notice that the Indiana Jones movie was filmed at this location. Petra was named one of the new 7 wonders of the world and as a result got a surge in tourism. It’s a wonderful place, hot and laid back.

Most people travel by air from Jerusalem to Elat and Jordan, but I opted to take the bus. It’s a 4 and a half hour trip thru amazing scenery. It’s also inexpensive, about 12 to 15$ and much more convenient than by airplane. I will say that except for the bus, everything was very expensive in US dollars. It’s a shame the dollar is so weak, I don’t except to make many of these trips.

Last week was the holocaust memorial day in Israel and I happened to visit the Wailing Wall with some of my Intel co-workers just as 1000’s of people where attending a ceremony that was being broadcast live on TV. One of my pictures shows all the people at the wall.

The Dead Sea was really amazing, it’s so saturated with salt that you simply float. This sea is the lowest point on Earth I am told, it’s 1,378 feet below sea level. Your ears pop on the way there as the air pressure increases. As pressure increases so does the temperature which will often be 10 degrees hotter than Jerusalem. The Dead Sea is well known for the Dead Sea salts used as skin treatment. It also gave me a great excuse to play in the mud! You let it dry and wash it off to wonderful skin… but it’s also just loads of fun.

To sum it up, this 10 day trip was simply amazing. In addition to meeting many people who use the DTK, I also got to see and experience some unique places I will never forget.

Ylian (Intel AMT Blog)

Intel AMT 3.0 on my home computer

ylian.saint-hilaire@intel.com — Tue, 22 Apr 2008 19:33:24 GMT

I just posted a new YouTube video on my own Intel AMT 3.0 computer that runs under my television. It runs Microsoft Media Center, has 4 cores, 4 tuners, 4 hard drives, 3 Gigs of RAM, 2 DVD's... Certainly the most powerful computer I have ever owned. Most importantly, it has Intel AMT 3.0 using an Intel DQ35JO motherboard. This is very useful for me to work on Intel AMT Commander on my spare time and also to remotely manage my computer from anywhere in the world.

If you guys have your own computer project that runs Intel AMT, please let me know. Better yet, if you have pictures it would be great to share with the community.

Ylian (Intel AMT Blog)

Intel AMT DTK back online, v0.52x released

ylian.saint-hilaire@intel.com — Sun, 20 Apr 2008 23:46:12 GMT

I am glad you inform everyone that the Intel AMT DTK is back online and once again, my apologies for the interruption. Version v0.52x was released, with just a few fixes over the previously posted v0.51x. It's mostly the same as before, not many new features, but if you have experiences problems in the past, try this version.

Probably the area where the DTK is improving most is with general stability and WSMAN. When using Intel AMT 3.0, Intel AMT Commander and Intel AMT Outpost will use WSMAN instead of SOAP. Since all the calls are different, many new bugs showed up. As we get the benefit of more testing and feedback, the code keeps improving. Users can force Commander to use SOAP by going to the "View" - "Advanced properties". The second tab has a check box to remove using WSMAN first. WSMAN will of course still be used if Commander determines that WSMAN is the only available option.

Next week I am once again heading to Israel to meet with this Intel AMT firmware development team. Last year I had a pretty shaky flight over, something I had blogged about. Hopefully this year will be better. At Intel, this is going to be the ultimate meeting of everyone related to AMT, so I will get to meet some of the other people that post on the forums, and many of the people that I get the most complicated answers from.

Ylian (Intel AMT Blog)

Intel AMT DTK v0.51 released & Audio blog

ylian.saint-hilaire@intel.com — Mon, 24 Mar 2008 17:25:40 GMT

Hi all. I wanted to announce the release of the Intel AMT DTK v0.51 on the public web site. As usual, lots of improvements have been made since the last version thanks for much testing and feedback from users. There are a few things that are particularly interesting about this new release of the Intel AMT DTK and lets get right to it:

Build-in C# WSMAN stack. As Intel AMT is transitioning to WSMAN calls for remote managibility, adding WSMAN support into the DTK has been increasly important. In the past, the DTK made use of WinRM, a Microsoft component that needed to be installed and configured. With version 0.51 of the DTK, I build my own WSMAN stack in C# right into the DTK stack. As a result, no more dependency on WinRM at all and no more compile problems. Additionaly, the DTK is now much faster at making WSMAN calls since all HTTP requests are now pipelined, and the DTK can connect to AMT computers that have invalid TLS certificates (a warning will be displayed of course). This is big news for anyone interested in WSMAN work. If you build your own managibility solution, I suggest you look at grabbing at least that part of the DTK source code.
Intel AMT Flash Tool. This version of the DTK adds a new Intel AMT Flash Tool. It will help users correctly setup a USB flash key so that it can be use to provision Intel AMT computers. As many of you many know, Intel AMT will in the right conditions, read a setup.bin file in a USB flash key when booted and use the information to help setup Intel AMT. The setup.bin file must be at the very start of the USB key and this new tool with help with that. The new tool is based on a similar tool that has already been released on the Intel Pro Center.
Intel AMT Reflector tool. Another new tool is a TCP connection reflector. It's a small generic tool that accepts connections and forwards the data back to the source IP address on a target port. It's useful for accessing Intel AMT from your own computer using a reflector on a different computer. I use it for recording some of my demonstration videos, but it can also be used by agents running localy that want to re-configure Intel AMT on itself. For example, detecting an OS name change and updating Intel AMT.

Many more changes and fixes have also been done, for example the terminal now correctly detects Serial-over-LAN disconnection, etc. For a full list, the DTK includes a change log.

Intel AMT DTK v0.51x Audio Blog (.mp3)

Ylian (Intel AMT Blog)

Top 5 things Intel AMT does and was never designed to do

ylian.saint-hilaire@intel.com — Tue, 26 Feb 2008 06:34:24 GMT

Years before I started working on Intel AMT, designers where creating a list of usages that would be enabled by Intel AMT. The list included, I presume, usages around 3PDS, remote reboot to BIOS, disk redirection, etc. Many of the Intel AMT usages that are promoted on the Intel web site. When I started work on the DTK, a personal challenge had always been to find new ways of using existing features to do different and sometimes unexpected things. Create new usages for Intel AMT that it was never originally designed to do. I now present my top 5 abuses of existing features.

TCP-over-Serial-over-LAN. The Intel AMT serial port I am told, was originally designed as an easy way to remotely take control of the BIOS and recovery OS remotely. Designers needed a way for BIOS to be able to send test display data to a remote console. A virtual serial port was a great solution. It so happens that in the original design, this serial port was always enabled and usable, even when the normal OS was running. This allows a serial agent to talk to a console while bypassing the OS’s network stack. This is interesting on its own and I started work on a serial agent of my own. Things took a weird twist when I started sending binary data and sending files over this serial port, making it very valuable. It’s only a few weeks later that I realized I could also send TCP traffic over this serial link, making it possible to contact TCP services on the Intel AMT computer even if the network stack was disabled. A few days later, I showcased the first demonstration of VNC-over-SOL, and turning this abuse of the serial port into an instant hit. To this day, VNC-over-SOL is still, one of the most impressive demonstrations of Intel AMT.

Reverse Watchdog. When Intel sales people demonstrate Intel AMT to customers, they often get asked if you can shutdown gracefully an Intel AMT computer using Intel AMT. The simple answer was no, Intel AMT will perform a brutal shutdown or reset upon request. To perform operations like a clean shutdown or reset, sleep or hibernation requires the involvement of the OS. You could tell a serial agent like Intel AMT Outpost to perform the shutdown, but that required opening the serial connection and could be a problem if you had to shutdown many computers. I needed a way to pass a small amount of information to a running Intel AMT agent on the PC, do it using SOAP/WSMAN only and if possible get confirmation of reception. We could store the command into 3PDS and have the agent read it periodically, but 3PDS required setup and that little amount of data would have required allocation of a 4K flash page. The solution came when looking at the agent presence feature. When a console creates a new agent, the agent can now register this agent locally. The agent also get the timeout of the agent in seconds (from 1 to 65535), this would be the key. By constantly trying to register a known GUID, Intel AMT Outpost could see if the agent existed or not. If suddenly the registration works, the timeout value would indicate that type of shutdown operation to perform. Better yet, the simple fact that registration occurred changes the state of the agent to “Running”, confirming to the console that the message was indeed received. Today the Intel AMT Terminal has “Agent Commands” in the remote control that allows a user to perform soft operations when the agent is running, even if the OS network stack is not working.

Mouse over serial. A few months back I started work on a smaller version of Intel AMT Outpost called Intel AMT Guardpost. The idea was that if a serial agent was going to be useful, it was going to need to run on a recovery OS, run in the background with no dependencies and with as little footprint as possible (Is it not annoying to have all there background processes running?). The C/C++ version of Intel AMT Outpost was on its way. One feature I always wanted to work on was a remote Windows command prompt; it took over a week to finally pull this off. I could now remotely shell to DOS and perform basic command line operations. I could also enter the command like editor with the “Edit” command at which point, the temptation to support the mouse-over-serial-over-LAN was a must have. Using the binary serial protocol, I added the support to the terminal in a few hours. To this day, it’s still a fun and amazing demonstration of outstanding remote manageability.

IDE-R within the OS. A few days after first enabling IDE-R within Intel AMT Commander, I stumbled upon something I had not noticed before. If an administrator where to start IDE redirection and the OS was to re-scan its plug & play devices, the additional floppy and CDROM drive would show up in Microsoft Windows. This was immediately interesting since transferring files over the serial port was limited to 115kb/sec a very slow speed in today’s world. With IDE-R, you can copy files at around CDROM 4x speed on a local network. All I needed was a way for Intel AMT Outpost to cause the OS to rescan its plug & play devices. A few hours later the “HWRESCAN” command was built and for the first time, an administrator could mount a CDROM remotely and install a patch as high speed without ever using the OS’s network stack. This feature also turned out to be an excellent compliment to VNC-over-SOL.

Fast data path using IDE-R. This is not an idea I never built into the DTK, but I wanted to add it to this list since it would also be an interesting was to use existing features in new ways. The serial-over-LAN feature turned out to be extremely valuable, but it is also slow. Serial ports are very inefficient. One way someone could speed things up is to use IDE-R as a fast by-pass to the OS. An administrator would mount a virtual floppy disk drive containing a single file. This file, would not really exist, it would contain different data each time it was read, making it possible to send data to an OS agent thru Intel AMT at much higher speeds. Also, since the floppy is a read/write device, the agent could write into the virtual file data that it wants to send to the console. It would be quite a bit of work to pull this off, but it certainly seems possible. Someone would just have to know the internal format of an .img file.

That’s my top 5. I realize this is probably a rather advanced blog article, but this is proof that you can have a lot of fun to any technologies.

Ylian (Intel AMT Blog)

Top 5 things I would change about Intel AMT

ylian.saint-hilaire@intel.com — Mon, 25 Feb 2008 07:06:45 GMT

The Intel AMT Developer Tool Kit (DTK) is now over a year old and by many accounts, the most popular software package for using Intel AMT that exists today. As I work on improvements and new features I also get to interact with my users, developers, IT departments, testers, etc. I also come across many common ideas for how Intel AMT should be improved. Today I decided to compile my own list of changes I would make to improve Intel AMT. Even if I work at Intel, I have no special access or power over what gets changed, so it’s important that users of Intel AMT make your voices heard if you think you have changes you need made.

1. No TLS, Serial-over-LAN/IDE-R password in the clear. As many of you have discovered, when using Intel AMT in small business or enterprise mode without TLS, the login username and password is sent on the network in the clear when the administrator performs a serial-over-LAN or IDE redirect operation. With so many coffee shops, schools, Internet cafes playing around with Intel AMT features, this could be a big problem. Imagine a classroom with a few vPro computers with AMT setup in SMB mode by an unsuspecting teacher. A student running a packet sniffer, obtaining the password and rebooting AMT computers remotely. This can be avoided by setting up TLS using Intel AMT Director, but this should not be problem in the first place. The HTTP digest used for web pages could easily be adapted and used.

2. Allow TLS in SMB mode. This is a long time feature request that is somewhat related to the first issue. In my work with Intel AMT, I can do everything I need to setup TLS in SMB mode except enabling it. Allowing administrators to setup server-side authenticated TLS would be very easy to add to Intel AMT and would provide improved security with almost no work. In fact, Intel AMT Commander could just prompt the administrator on first connect if he or she want to enable TLS when a non-TLS SMB computer is found. A new root certificate would be generated if none already exist. Strictly speaking, it would not provide “bank level” security, but would go a long way for shops, schools, small business owners that have more to think about than understanding secure manageability.

3. Release the SOL/IDE-R redirection source code. The library called “IMRSDK.dll” is compiled by Intel and not available in source code form. It’s available in Windows and Linux but it has been a problem for people trying to port this feature on to other platforms. It’s also a problem because this library is far from perfect and I would be the first to make changes to it. One of the most critical changes I would make involves knowing if the Serial-over-LAN is connected or not. Imagine how annoying it is to have the SOL connection drop and that application not know about it. Intel AMT Terminal will show “Connected” at the top even when it’s really not. I also want a debugging feature to know exactly what is going on, people report in forums and privately to me that SOL has problems and I have no way to help. My list does not end there; I have more changes I really need made.

4. Make Intel AMT discovery and connection easier. Some Intel AMT software have a discovery feature that attempts to sweep a network to find Intel AMT computers and add them to a management console. To make it easier on the user, Intel AMT Commander also attempts to automatically detect that type of AMT computer it’s talking to. Once you discover a computer, the work is not done. Is the computer setup with TLS? Is it in WSMAN only mode? Is it using TLS mutual-auth? Are you talking to LMS? What version is this? The Intel AMT DTK has an elaborate system to attempt gather this data when a user connects. With new version of Intel AMT, transition to WSMAN and more, it’s getting more and more difficult to correctly detect and connect to all versions of Intel AMT. Developers looking at the DTK’s connection algorithm will be stunned, we need to simplify this process.

5. Get permitted access realms upon connection. So you setup Intel AMT with various user accounts, one for asset monitoring only, one for packet control, another for remote repair. When software like Intel AMT Commander connects to Intel AMT using one of these accounts, it has no idea what types of permissions this account has. As a result, the software is left to assume it has all rights, or fail with an error when things start to go wrong. I don’t think it would be unreasonable to be able to query the allowed realms upon connection for the account currently being used. This would make it easy for Intel AMT Commander to remove from the UI features that are not allowed.

Of course, being an avid fan of Intel AMT, I could write many things I like about it, just look at my many blogs. It’s my hope that this list will spur discussion and action. If you read this, take the time to write a small comment saying which one of these would want fixed first, or tell me if you have your own issue.

Ylian (Intel AMT Blog)

Intel AMT Commander’s Serial-over-LAN scripting

ylian.saint-hilaire@intel.com — Tue, 05 Feb 2008 06:31:34 GMT

Serial-over-LAN is quite useful for taking control of a computer, making changes to the BIOS and when Intel AMT Outpost or Guardpost is running, getting a management command prompt even when the OS network driver is disabled. What if you have to repeat the BIOS change on 100’s of computers? Say you want to change a BIOS boot option on 100 computers? Or want to test the reliability of a new computer platform? The Intel AMT Serial-over-LAN scripting can help.

Connect using Intel AMT Commander to the Intel AMT computer and select “Take Control” to enter the VT100 terminal. Make sure everything works well and you can connect and perform Serial-over-LAN correctly. Go in the “Terminal” menu and select “Script editor…” and write a script like this one, using the user interface to guide you:

LABEL “start”
RESET bios
WAIT 40 seconds.
RESET powerdown
WAIT 15 seconds
JUMP “start”

You can save the script, and run it. You can also write more complicated scripts to change BIOS options and do more interesting things. There is a command:

WAITFOR “abcd”

This command will wait until the string “abcd” is anywhere on the VT100 screen. This is very useful to wait for the computer to finish booting and to do something after. You can also send string to SOL:

SEND “dir\r”

To send the “dir” command. Terminal scripting is very powerful. It’s also a great way to impress your friends and customers. In a few minutes, you can write a script that will power on a computer; navigate throughout the BIOS screens and shutdown the computer when done. Once you run it, it’s like a ghost is taking control of your computer and going into the BIOS, very cool.

Ylian (Intel AMT Blog)