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/
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.
Also, you will need the Intel AMT Software Development Kit. This contains AMT functionality that we will use in our webpage.
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.
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".
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..."
Then under the tab "Browse" we can point to a file we want to add.
The four files that we need to add as references are (assuming the SDK is at C:\VPRO_SDK):
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..."
The item we need is:
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.
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 ID="TableCell2" runat="server">
<asp:Button ID="Button1" runat="server" Text="POWER ON" onclick="Button1_Click" />
<asp:TableRow ID="TableRow2" runat="server">
<asp:TableCell ID="TableCell3" runat="server">
Click here to switch on DESKTOP2:
<asp:TableCell ID="TableCell4" runat="server">
<asp:Button ID="Button2" runat="server" Text="POWER ON" onclick="Button2_Click" />
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".
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:
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,
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:
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.
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.
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...>
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.
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..."
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.
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".
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..."
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".
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.
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:
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 inVPRO_SDK\Windows\Intel_AMT\Samples\WS-Management\RemoteControl
Thanks to Intel for providing the SDK.