Traditionally, I've known Intel AMT to be part of the toolkit of administrators. It has helped me out by either simplifying or enabling parts of my work as a system administrator. Usually, this meant being able to do things without users entering the picture. Whether it's power management, changing BIOS settings, booting into a CD, and so on.

 

This changed when I deployed a Microsoft Small Business Server 2011 Standard at a customer's site. This was a very small office, with about five client pc's. Suddenly, I had a use case where users themselves would benefit from being able to use AMT features.

 

Although their previous SBS (2003) also had a Remote Web Access website which including a remote desktop (RDP) proxy, it was never used much. However, since the new server was installed, users found it easier to connect to internal clients pc's using this new RDP proxy, and they enjoyed the option of being able to work from home using this feature.

 

This "connect to computer" feature of SBS is shown on the right side in  the screenshot below. This Remote Web Access is a standard feature of  SBS and is normally accessed using https://remote.companyname.com/

01-rwa-mainscreen.png

This is fine during office hours, when a user working from home can ask someone currently still at the office to switch on the computer for them, but outside office hours, this presents a problem. As an administrator I am able to turn on computers remotely, but the tools I use for this (either the web interface, the AMT Commander or (usually, these days) the Powershell module) are more technical than what the users prefer to use, and -- most importantly -- require either the AMT password to work, or more advanced provisioning (e.g. Active Directory integration) than makes sense for such a small site.

 

One solution for this is to use the SBS itself, specifically the included web server, to do both the underlying work (performing AMT commands on the backoffice computers) as well as the authentication, using IIS's builtin user authentication.

 

To do this, we need to compile our AMT code into a DLL that IIS can use. So we need a compiler that can do this. You can download Visual Web Developer 2010 Express (a flavour of Visual Studio 2010) for free from Microsoft, which will do this for us. Alternatively, if you have Visual Studio 2010 Professional already installed somewhere, you can use that instead.

 

http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-web-developer-express

 

Also, you will need the Intel AMT Software Development Kit. This contains AMT functionality that we will use in our webpage.

 

http://software.intel.com/en-us/articles/download-the-latest-intel-amt-software-development-kit-sdk/

 

Once Visual Studio (or Visual Web Developer, which I shall also call Visual Studio in this article) is installed, and the SDK is unzipped, we can begin. In this example, the SDK is unzipped to C:\VPRO_SDK.

 

First, we open Visual Studio, create a new Empty Web Application and give it a name, in this case "PowerOn". Then click "OK". I've used C# because I'm more familiar with it than Visual Basic.

02-VC-newproject2.png

 

With this new project, it's not technically necessary, but it's wise to set the Target .NET Framework to a slightly older version, for a little more compatibility. If we set it to 3.0 then this page should even run on SBS2008 (or plain Windows Server 2008 running IIS, of course). If you set this too high, you might find you have to install new .NET Frameworks on your server before you can use the page. Right click on "PowerOn" (or your own project name) in the top right corner en click "Properties".

02a-VC-project-properties.png

 

Now, we need to reference the AMT SDK libraries that will enable us to do things like power on computers. Right click on "Reference" and choose "Add reference..."

03-VC-addreference3.png

 

Then under the tab "Browse" we can point to a file we want to add.

04-VC-addreference-filename.png

 

The four files that we need to add as references are (assuming the SDK is at C:\VPRO_SDK):

  • C:\VPRO_SDK\Windows\Intel_AMT\Bin\CIMFramework.dll
  • C:\VPRO_SDK\Windows\Intel_AMT\Bin\CIMFrameworkUntyped.dll
  • C:\VPRO_SDK\Windows\Intel_AMT\Bin\DotNetWSManClient.dll
  • C:\VPRO_SDK\Windows\Intel_AMT\Bin\IWSManClient.dll

 

Next, to make our code simpler and shorter, we're going to use a class from the SDK that already predefined some common tasks. Rightclick the project name, in this example "PowerOn", then click "Add" and "Existing Item..."

05-VC-add-existingitem3.png

 

The item we need is:

  • C:\VPRO_SDK\Windows\Common\WS-Management\C#\common\AssociationTraversalTypedUtils.cs

 

Now we're ready to create code. The only actual webpage that we need is a Default.aspx, this will be the page that is displayed. Rightclick the project name again, click "Add" again, but this time "New Item...". Next choose Web Form (the top option) and name it Default.aspx.

06-VC-add-new-item-Default.png

 

Now you have the option of whether you want to write the code for the table/text/buttons/etc or whether you want to drag-and-drop them in the designer view. Myself, I am clumsy with graphical editors, so I prefer to write code. The tags for writing a table are incredibly simple. This is some sample code for a table with two rows, and a power-on button on each. Of course, after the first row, it's a simple matter of copy-and-pasting until you have enough rows. However, you have to change the following each row:

  • the computer name (in this example DESKTOP1, DESKTOP2, etc.)
  • the ID of the button (changed automatically, when copy-and-pasting)
  • the method that is called upon a click (in this example: Button1_Click, etc.)

 

Here is some sample code. It goes between the <div> and </div> in the middle of the page.

On this page, you can switch on computers using Intel vPro.
        <asp:Table ID="Table1" runat="server" Height="200px" Width="500px">
            <asp:TableRow ID="TableRow1" runat="server">
                <asp:TableCell ID="TableCell1" runat="server">
                    Click here to switch on DESKTOP1:
                </asp:TableCell>
                <asp:TableCell ID="TableCell2" runat="server">
                    <asp:Button ID="Button1" runat="server" Text="POWER ON" onclick="Button1_Click" />
                </asp:TableCell>
            </asp:TableRow>
            <asp:TableRow ID="TableRow2" runat="server">
                <asp:TableCell ID="TableCell3" runat="server">
                    Click here to switch on DESKTOP2:
                </asp:TableCell>
                <asp:TableCell ID="TableCell4" runat="server">
                    <asp:Button ID="Button2" runat="server" Text="POWER ON" onclick="Button2_Click" />
                </asp:TableCell>
            </asp:TableRow>
        </asp:Table>

 

Next, we need to create the "Button1_click" that we mention in this code. The easiest way to go to the source code is to right-click on the method we want to define and choose "View code" in the popup menu. Here, I've right-clicked on "Button1_Click".

07-VC-goto-code2.png

 

This automatically brings us to the file that should contain the source code for button1_Click, button2_Click and whatever other methods you wish to define. First, however, on this page, you need to add a few "using" references at the very top. The start of this page should read:

 

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Intel.Manageability.Cim;
using Intel.Manageability.Cim.Untyped;
using Intel.Manageability.Cim.Typed;
using Intel.Manageability.WSManagement;
using Intel.Manageability.Exceptions;
using Intel.Manageability.Utils;

 

The first of these are probably already there, but it's wise to check. You're going to have to add the bottom lines that start with "Intel".

 

Next, we define the actual method that does the AMT work. The code for this needs to go below the "Partial Class" line and its opening bracket. The code is:

    protected void Button1_Click(object sender, EventArgs e)
        {
            String computerName = "desktop1.company.local";
            String username = "admin";
            String password = "P@ssw0rd";
            CimReference outJob = null;
            IWSManClient wsmanClient = new DotNetWSManClient( computerName, username, password, false, false, null, null);
            CimReference managedSystemEPR = AssociationTraversalTypedUtils.DiscoverManagedHost(wsmanClient);
            CIM_PowerManagementService powerStateService = (CIM_PowerManagementService)AssociationTraversalTypedUtils.GetAssociated(wsmanClient,
                                                                                               managedSystemEPR,
                                                                                               typeof(CIM_PowerManagementService),
                                                                                               typeof(CIM_HostedService));
            ushort powerState = 2; // "On" is powerstate 2
            uint response = powerStateService.RequestPowerStateChange(powerState, managedSystemEPR, null, null, out outJob);
            if (response != 0)
            {
                throw new WSManException("Wrong response from AMT");
            }
        }

 

Explaining this code is beyond the scope of this document, but if this makes sense for you, then you're likely to expand on it as well, perhaps with the webpage showing the current powerstate of AMT machines, but you don't need to. If you use this code, the button will turn on a computer. Of this code, you need to change the first three lines to reflect the name of the computer you wish to power on, and the username and password needed to do it.

 

These credentials will be compiled and saved into the DLL, so it's important to keep the DLL safe, on the SBS server, and not in shared document folders that regular users can access. During normal use, the DLL and the password contained within will not be accessible for users on your network or to users accessing the website.

 

This page should now look something like this in Visual Studio:

08-VC-code-overview3.png

 

That's all the coding we need to do, now we can deploy our website to the SBS. However, it might be a good idea to test our web page. To do this, change "Debug" at the top, to "Release," then click the green triangle to the left of it.

09-VC-setrelease-and-test.png

 

We should see a layout shaped like a table with (in this example) two buttons and a distinct lack of visual style. For people who are creatively inclined, it might be a good idea to put slightly more effort into the HTML or ASP code that we started with (where the table is). If you are using an underpowered VM (like me) to do this, it might take quite a while before the page appears. This is normal. Also, if you want to test the functioning of the buttons, you need to be able to access the computers. This usually means you have to be directly connected to the intranet, or have a VPN connection running. Also, be wary of any firewalls that might be in the way, blocking TCP port 16992 between the SBS Server and the AMT-enabled workstations.

10-MSIE-testpage.png

 

Now that we're confident that all the visual elements are there and that the buttons work, it's time to publish our work to the SBS server. Just close the Internet Explorer window, so we're back in Visual Studio. At the top, it says "Create Publish Settings", which sounds like a good idea. Click on this and then on "<New...>

11-VC-Publish-new.png

Then, choose "File System" for the simplest method, and type in a temporary folder name where Visual Studio can copy the necessary files to. In this example, I used "C:\DEPLOY" which is easy to find afterwards.

12-VC-Publish-file-system.png

 

Now, it's time to prepare the server. Log into the the server with administrative credentials and open the "Internet Information Services (IIS) Manager" snap-in. This is found under "Administrative Tools". Next, under "Sites" find the "Default Web Site" and right-click on it. Then choose "Add Application..."

13-IIS-new-application.png

 

Next, enter an alias. This will be the last part of the URL for the page. If the alias is "poweron" then the final address will be "https://remote.company.com/poweron". For the physical path, it's good practice to use a location within C:\inetpub\wwwroot\ but you don't have to.

14-IIS-application-settings.png

 

Now comes a very important step. Securing the webpage (preferably before we copy the actual files to it). Back in IIS Manager, select the new entry "poweron" and double-click "Authentication".

15-IIS-Authentication-icon.png

 

Two things are important here: to disable anonymous authentication (you don't want anonymous users turning on your computers), and to enable another form of authentication. The easiest to set up is Basic Authentication. Just right click on "Anonymous Authentication" and click "Disable". Then right click "Basic Authentication" and click "Enable". Next, right click "Basic Authentication" again and choose "Edit..."

16-IIS-Authentication-settings.png

 

In this window, type the domain that your SBS users are located in. Otherwise, your users will have to authenticate with "DOMAIN\user" every time, which is a hassle. The bottom option "Realm" just makes the login window a little bit prettier, but isn't technically needed.

 

Now we've made sure that anonymous users cannot access the /poweron application. But when users do login, we want it to be safe. So, on the left side, select "poweron" again, and this time double click on the large "SSL Settings" icon and select the option "Require SSL" followed by "Apply".

17-IIS-SSL-settings.png

 

Optionally, if you only want to allow specific users or groups access to the page (instead of all authenticated SBS users), choose "poweron" again on the left, and this time double click the "Authorization Rules" in the middle. Here, you can specify which users to allow or deny access.

18-IIS-Auth-rules.png

 

Now that IIS is aware of our application, and it's properly secured, it's time to make it work. For this, simply copy the contents of the "C:\DEPLOY" folder (or where you decided to deploy to, earlier) to the location we specified in IIS as the location for our application. In this example, this is "C:\inetpub\wwwroot\poweron". The result should look similar to this:

19-Explorer-poweron-deployed.png

And, voilá, we're done. Now we can sit back and enjoy the fruits of our labour by going to the website https://remote.company.com/poweron and click on buttons, marvelling at the computers spontaneously turning on.

 

In the scenario of a small company, where the goal is to enable users to switch on computers remotely, so they can connect to them and use all the applications that they're used to at the office, these few easy steps suffice. Of course it's also possible to customize this in various ways, it's possible to automatically generate the number of buttons, to use certificates for authentication, to use TLS connections, to also display the current power status and so on. But for an administrator with merely basic understanding of programming concepts and Visual Studio, it's entirely possible to create such a custom website for a small business customer.

 

The code you see in the example isn't created by me from scratch. The code relating to vPro is from combining code from a few sources within the AMT examples in the SDK. Mostly from a few of the classes in

VPRO_SDK\Windows\Intel_AMT\Samples\WS-Management\RemoteControl

 

Thanks to Intel for providing the SDK.

Every once in a while an invention or product comes along that really makes your life easier. The electric toothbrush. The Crock-Pot*. Automatic transmission. The Intel® vPro™ technology module for Microsoft* Windows PowerShell*. Things that, once you get your hands on them, you wonder how you ever lived without them.

 

Windows PowerShell allows you to create simple, viewable scripts that can be modified as needed, allowing for quick adoption of Intel vPro technology Out of Band (OOB) Management use cases. And, it’s right there in your Microsoft Windows* environment, available to everyone. As Bill York, Intel Enterprise Solution Architect, says, “Every company I support has somebody using [Windows ] PowerShell to support their Enterprise.” It’s ubiquitous. And the Intel vPro technology module for Microsoft Windows PowerShell lets you harness that ubiquitous power to help manage your remote Intel vPro based clients. IT shops can quickly and easily extend Intel vPro technology OOB Management into IT Business process automation to increase efficiency and effectiveness.

 

Along those lines, the Intel vPro technology module for Microsoft Windows PowerShell can help bridge gaps between some management consoles and Intel® Active Management Technology (Intel® AMT). For example, Microsoft System Center* Configuration Manager doesn’t enable KVM Remote Control when it provisions your managed clients. And many help desk staffers don’t have the credentials and permissions to access Intel AMT and turn KVM Remote Control on. But with the Intel vPro technology module for Microsoft Windows PowerShell, IT Engineering can use Windows PowerShell to enable KVM Remote Control on the clients, which in turn allows the help desk (with their more restrictive permissions) to take advantage of this powerful Intel vPro feature to better assist their callers. Says York, “The module allows organizations to configure the lower layers of Intel AMT,” which can also allow them to take advantage of Solution Reference Designs and Use Case Reference Designs that otherwise would have remained out of reach.

 

The upcoming version 3.2 release adds even more value to what you’ve already come to love. With the new GUI editor in version 3.2, your engineering team will be able to generate a customized Windows PowerShell based Intel AMT point-and-click GUI that allows you to take advantage of Windows PowerShell’s Intel AMT capabilities even if you aren’t a Windows PowerShell command line guru. This light-weight, customizable GUI lets you streamline the invoking of core Intel vPro technology OOB use cases. And version 3.2 of the module exposes Intel AMT (local or remote) and the local Intel® Manageability Engine (Intel® ME) driver as a Windows PowerShell Drive, allowing you to map to a client’s Intel AMT firmware from within Windows PowerShell so you can view and manipulate Intel AMT data on the managed client. For example, you can validate which Access Control Lists (ACLs) are currently in Intel AMT, or set timeout values that your management console doesn’t natively configure. “The sky’s the limit for customers to create their own usages,” says York, “without necessarily having to rely on Intel resources to produce these things for them.”

 

All sizes of organizations can benefit greatly from the Intel vPro technology module for Microsoft Windows PowerShell. Charlie Milo, Intel Enterprise Technology Specialist, tells of one large FSI account that that has been purchasing Intel vPro based clients for five years, whose environment consists of around 85% Intel vPro based clients, and yet, though they were impressed with Intel vPro capabilities, they have been unable to make use of them because their management console does not support Intel vPro technology. Enter the Intel vPro technology module for Microsoft Windows PowerShell. “It was a game changer,” says Milo. Using the module, they were able to execute Intel AMT commands on their Intel vPro based managed clients, thus taking advantage of the powerful remote and OOB management capabilities of Intel vPro technology that was already resident in some 85% of their existing PC fleet. That sure beats an electric toothbrush!

 

At another, mid-sized account, Milo was able to deploy the module to help the customer bridge yet another gap between their management console and Intel AMT. The customer wanted to use Intel AMT’s Alarm Clock feature on their 1,200 Intel vPro based PCs, but unfortunately that feature isn’t supported by Configuration Manager. But with the Intel vPro technology module for Microsoft Windows PowerShell, the customer could use Windows PowerShell scripts to remotely configure the Alarm Clock settings on all 1,200 systems.

 

And Intel Solution Support Team’s Steve Davies is having success with the module at his accounts, too. One, a high-quality television entertainment provider, will hopefully be using it in production soon to remotely boot their BitLocker-enabled clients. And another, a well-known European airline, may soon be deploying a PowerShell enabled use case that Davies successfully demonstrated to them recently. Davies also plans to show this use case at local Microsoft MMS events.

 

Even ISVs can benefit from the Intel vPro technology module for Microsoft Windows PowerShell, according to Milo. One ISV that focuses on Client-Side Virtualization to help centrally manage PCs was able to leverage the module to incorporate features like remote power on and IDE Redirection (IDE-R) into their product, even though it does not yet natively support Intel vPro management capabilities.

 

And these are just some of the module success stories out there. Got one of your own? Feel free to relate it in the comments section of this blog.

 

But, like one of those late-night infomercials on cable TV, that’s not all. In addition to revolutionizing our customers’ relationships with their Intel vPro technology based clients, the module is helping to revolutionize the way Intel sells Intel vPro technology itself. The module is part of a growing suite of Intel-developed tools that allow us to provide everything our customers need to get up and running with Intel vPro technology. Intel® Setup and Configuration Service (Intel® SCS), the Intel vPro technology module for Microsoft Windows PowerShell, and a growing number of Solution Reference Designs and Use Case Reference Designs from BCPD Engineering, are making it possible for customers to purchase, provision, configure, and use Intel vPro technology—and start seeing real value right from the start—regardless of whether their entrenched management console supports Intel vPro features or not. What’s more, these tools allow us to deploy new Intel vPro features directly to our customers, on our own cadence, without waiting (and pleading) for ISVs to support those great new features.

 

In short, these tools like the Intel vPro technology module for Microsoft Windows PowerShell are putting Intel in the driver’s seat, in command of our own destiny with regard to the success of Intel vPro technology.

 

Kind of a nice feeling, isn’t it?

Filter Blog

By author:
By date:
By tag: