I've been asking GoDaddy for over a year to provide a specific Intel vPro site to help customers buy Remote Configuration Certificates.  Glad to see someone was able to get them to add a link on thier site.  http://help.godaddy.com/article/5260

Take a look at the posted document for step by step instructions on Windows 7 Migration with SCCM SP2.  This document includes how to create an image using SCCM, Installing drivers, Installing Applications, Creating Hardlinks with the User State Migration Tool, and Renaming and Joining the domain.  This document allows IT technicians to create an Win 7 image, deploy it to their environment using collections, and upgrade their existing Windows XP clients to Windows 7 clients without having to remove the data and put the data back.  Included in this guide is some tips and hints on getting the image deployment to work for your company.

http://communities.intel.com/docs/DOC-4079

If you're reading this blog posting, hopefully you've read my blog post on CIRA last week -

http://communities.intel.com/community/openportit/vproexpert/blog/2009/11/10/cira-and-fast-call-for-help--what-is-it-where-can-i-find-it

Firstly, I wanted to share with you that over the past week we have actually worked through an entire end to end setup with a real-world customer (i.e. not just inside Intel labs) and now we have CIRA and AMT functionality over CIRA working successfully!

If you're wondering which of the management consoles and MPS/vPro Gateways were used - it was LANDesk 8.8 SP3 in this case (remember that LANDesk bundle their own MPS/vPro Gateway offering). If you're looking to get this to work in your environment (CIRA with LANDesk specifically) please do get in touch and I can share some specific current LANDesk pointers with you (that are not mentioned in this blog posting).

Some of the things we came across last week which are good pointers to pay attention to:

1. There are 4 ports that get configured with the MPS which are fully configurable (i.e. they are not restricted to being a specific port number) - however, you cannot re-use the same port number, you need to have 4 distinct port numbers (sounds trivial, but it happens).
2. You can use port 16993 as one of the port numbers, even though that is the port that is used for https connections in AMT (there is no conflict)
3. In the httpd.conf file - instead of havinga deny all and allow specific IP addresses, you might want to change to allow all
4. CIRA relies on the DHCP option 15 that is allocated where the vPro client is to be different than what it was pre-configured with - that is how the system knows it is outside the corporate environment. If DHCP option 15 happens to be blank where your vPro clients connect from - that is good enough. Blank is considered different and CIRA works fine.
5. Currently, you should install the LANDesk agent after provisioning is completed
6. Check through selecting the 'vPro Status' operation on a provisioned vPro client to ensure all the LANDesk NED settings have been deposited properly on the vPro client prior to taking it out of the corporate environment.

Btw, the CIRA connection is established through a user click at the OS-level using the IMSS utility.

So the bottom line is we now have close to 100 systems that are confirmed to be have full AMT functionality working over a CIRA connection in a real live environment - it works! (

The 2nd part of the blog can be considered a more 'advanced topic' and is devoted to what happens if your management console of choice doesn't currently support CIRA...

One Management Console for example that is currently not supporting CIRA is Microsoft SCCM (even with SP2).

The options as I see them, are:

1. Contact your software vendor and ask them whether they support Intel - Intel works with multiple software vendors on incorporating support for various Intel vPro features (CIRA amongst others) - they can hear it from us, but it is much better if they hear it from you.
2. Your software vendor might have plans to introduce support for CIRA, however it is further down the line - so it is just a question of time.  
3. Try and engineer something yourself to have CIRA work in the environment you have setup

At least for testing your environment for what CIRA would look like, you could leverage the WebUI tool. You would need to have an MPS installed and configured first of all. Thereafter, all that you need to do is configure the proxy settings in the web-browser you are using to the IP address/FQDN of where you have your MPS installed and also enter the default http proxy port of 8080 - that will be sufficient for getting your WebUI to work over a CIRA connection.

If you use Microsoft Internet Explorer you are limited only to the http proxy portion which will allow several of the AMT operations to work over a CIRA connection, but not SOL/IDER for example.

If you are using Mozilla Fire Fox for example, you can configure a SOCKS proxy as well, which can handle routing SOL/IDER traffic as well.

If we take the example of Microsoft SCCM, what you can do is to use the scripting framework that has been used successfully for something like: providing out of band 802.1x in Microsoft SCCM SP1 (it is natively supported now in SP2) - http://communities.intel.com/message/10877

You can configure the correct settings for the vPro client to be able to contact the MPS Proxy Server and establish a CIRA connection between the MPS Server and the vPro client, however you will still need your management console to integrate and be aware of this CIRA connection to be able to do something useful.

What you could do at this point is to configure a 'transparent proxy' - what that would typically entail is to configure the MPS IP address/FQDN as a proxy routing that will be inserted in the headers of packets that go through the router to which the Server that is hosting the management software. You can use something like Cisco WCCP (Web Cache Control Protocol) to set this up. At this point, Microsoft SCCM will not be aware that the packets it is sending are actually being re-routed through the MPS to the vPro clients (which is aware of the remote vPro client) and that is why this is called a transparent proxy.

A caveat/disclaimer I would add though is that albeit technically feasible you would need to put together the full working solution yourselves and support it yourselves.

vPro provides many helpful tools for Help Desk support personnel such as the ability to reboot a vPro system to a CD-Rom image. Of course to use it, they must have permissions to access the firmware remotely. Check out this use case reference design: http://communities.intel.com/docs/DOC-4404. It provides a framework to use an Active Directory group to grant and revoke these firmware permissions on all vPro systems through out an environment. For non-SCCM users, this concept may be used with many other software packages such as SCS. Also included in the appendix is a method to reconfigure vPro systems without a full unprovision. Enjoy!

Sharing an experience and looking to validate some of the challenges vPro demonstration might present in markets outside of North America - especially if the original demonstration environment was created in North America.

A few weeks ago I had the opportunity to travel to Germany for a training event.   The equipment for the training event was sourced locally in Germany.   The result was 13 systems.  (For those that are superstitious – you might quickly identify that this will get interesting).  

Among those 13 systems, there were 4 different OEMs, 3 different keyboard layouts (US, UK, German), 3 different power connectors, 2 generations of Intel AMT (2.6 and 4.x), 3 different versions of Windows (XP, Vista, and Win7), 2 different versions of VMware workstation, and a single VMware workstation image created in North America.   Very little standardization.   A perfect recipe for disaster.

This was my first experience in working with differences that went beyond just QWERTY vs. QWERTZ keyboards.   The password used for the operating system and applications included the @ key.   This was problematic since on a US-based keyboard the location of '@' is Shift-2, yet a German keyboard is AltGr-Q  (press and hold key to right of spacebar, then press Q), and a UK-keyboard is Shift-‘ (press and hold shift, then press ‘ key which is located on third row third key from the right side).   Fortunately I didn’t have to deal with keyboards outside of Latin letters (i.e. A, B, C, etc) – although there are exceptions like the German letter β.

My first realization of internationalization troubles was that BIOS\MEBx screens and key sequences were US-keyboard QWERTY based regardless of the keyboard layout.   I had to ask myself - "Is this always true?".   Since the password included the @ symbol - mentally I had to follow the US-keyboard layout, althought the sequence wouldn't match the printed keys on the system.

When in the host operating system, the “Regional and Language settings” were commonly set to the origin of that system (expect one system which had UK keyboard with US-based Windows Regional and Language settings).   My frustration did not end there – as the VMware environment was set to US-based Regional and Language settings, and had to be adjusted on a per-system configuration basis.

Not all of the windows menus and options were in the same locations between English and German, yet there were similarities.   With the differences of languages between BIOS\MEBx, host windows operating system (with VMware workstation), and demonstration environment – some real-time translation or best guess had to be done.  I know some German, thus I was able to navigate through menus in the host operating system or VMware application, yet it slowed setup and troubleshooting situations.   Fortunately those attending the training knew English better than my German language skills... but frustrating nonetheless.

The good news – the underlying vPro functionality was the same, the training was delivered, and a new perspective was obtained by myself and those who received the training.

In talking with my international associates, a few more points were brought to my attention:

• difference of calendars (for example, those that use Buddhist calendaring system) which may affect Kerberos and certificates
• application installations may fail when using a foreign language
• Remote configuration certificate is issued to one domain (i.e. domain.company.com) yet will not support international domains (i.e. intldomain.company.com.uk)... this one is actually fixed in the latest firmware and will be explained in a separate article

There are likley other subtleties to the challenges of internationalization

Does this all sound familiar to those outside of the US?  

The experience was good for me.   I gained a brief look into much larger challenges on standardizing a technology solution across the globe.  

Here’s the situation, I recently purchased an ATOM set top box for my TV. I purchased this ATOM based box so that I could play my movies, audio and have an internet device for the TV for the family to leverage (facebook, shopping, checking out sites as a family). I was updating the OS, patching, configuring and ended up rebooting it a few times and then of course throw in a few HARD boots in the middle of it all.  I then went to boot it on and this popped up ..

Error:  "Corrupt file - NTOSKERNEL.exe"

My first comment was “ah bummer”, then I said okay I’ll just do an IDE-R/SOL and just copy the NTOSKRNL.exe file, no big deal.  Oh but wait, it wasn’t a vPro system and at that very moment I realized how key vPro is even to me.   I then spent 10+ hrs throughout the week at nights, lunch, etc.. building bootable USB’s, CD’s that would replicate vPro functionality, with little success and trust me I was asking everybody for input, thoughts and help.   At the end of the week I just pulled the drive, copied the file and then it was back to good again.

Would I have paid for vPro in this box prior, Probably not, would I now pay extra for it, that would be a YES!.   if it fails again I’m going to just pull the drive, but seriously what a distraction that was to unhook cables, take out the drive, hook up to another system, copy file, replace, rehook, power up.

So now as I explore more devices in the home, I’m thinking more about “What if?” it needs to be remotely managed – what would I do, what is my baseline requirement.  

If you are using Out Of Band (OOB) Management in Microsoft System Center Configuration Manager (SCCM) 2007 SP1 (or greater) to manage your Intel vPro clients, you may have noticed that computer objects are created in your Active Directory domain during provisioning of the Intel vPro firmware. These computer objects are created by the amtproxymgr component of an OOB Service Point, and allow Intel vPro to communicate directory with Active Directory, regardless of the operating system state.

Since these vPro computer objects appear very similar to standard computer objects that are created when joining a Windows OS to an AD domain, it may be hard to distinguish which ones are vPro accounts, and which ones aren't. This situation can be worsened if you somehow have Windows computer accounts mixed into the same OU that contains your AMT objects.

As you'll see below, it's very easy to locate these computers using some simple PowerShell code:

$vprosearcher = [adsisearcher]"(&(objectclass=computer)(serviceprincipalname=*:16993*)(samaccounttype=805306368))"
$vproaccounts = $vprosearcher.FindAll()

These two lines of code simply create a System.DirectoryServices.DirectorySearcher instance, with some LDAP search criteria to identify the accounts, and then assigns the results of this search to a PowerShell variable called $vproaccounts. The default search root is the top-level of your Active Directory domain, and the default search scope is already set to SubTree, so you don't have to specifically configure these settings on the DirectorySearcher. Once you're at this point, you can simply enumerate the accounts, or pipe the results into a PowerShell ForEach loop, and perform some operation against them (for example, givem them a Description attribute value).

Because this code sample uses the "adsisearcher" type accelerator (aka. type shortcut), it will only work with PowerShell v2.0 (included as part of the Windows Management Framework), unless you modify PowerShell v1.0 to include it. There's almost no reason not to be using PowerShell 2.0, now that it has been officially released, however.

I recommend using the free Quest PowerGUI tool to develop and debug PowerShell scripts.

Cheers,

Trevor Sullivan

What is it?

When vPro and more specifically AMT was initially designed and engineered it was architected to work on an internal corporate network which allowed for the Server to client communications model. The problem was that many organisations have client PCs that are actually situated outside the corporate environment and were excluded from the reach of the vPro benefits available to systems residing within the corporate network. The reason for this is that client PCs that are not on the corporate environment would be sitting behind a home router and would actually posses a private local IP address that is not publicly addressable - i.e. it is not unique and the Management Console has no way of reaching that remote client. The solution to this situation is what is called CIRA - Client Initiated Remote Access.

The term Fast Call for Helpis what we refer to the use case that is enabled by CIRA (which is a means to an end, but not a use case on its own). It specifically addresses a help desk type scenario where the PC is broken and it is being fixed from remote by an administrator or technician.

How does it work?

It works on the principle that as with any usage of a PC behind a NAT'd router, once the client initiates a request (say for a web page) and the information returned comes back to the router, the router knows locally which PC to forward the information back to. The important distinction from the analogy used is that this connection is created Out of Band and does not rely on the operating system or some local software client agent being available or in a healthy state.

The connection that is initiated by the client arrives at the vPro Enabled Gateway which needs to be 'publicly reachable' - so it would typically reside in a DMZ and by protected by an external firewall which might have some port forwarding.

The management console has a listner for incoming CIRA connections and once such a connection arrives it can perform AMT commands on the remote vPro client.

The high level flow is as follows (with a graphical representation below):

1. The user of the remote vPro client initiates the connection to a component that acts as a proxy Server and is called the vPro Enabled Gateway (aka MPS - manageability presence server).
2. The connection can either be initiated manually by a user in an OS level utility or pre-OS level with a key combination
3. Alternatively, the connection can be scheduled to automatically be initiated according to a pre-determined time frequency
4. Once the connection reaches the Gateway, a secure encrypted tunnel is established back to the vPro client
5. At this point the Management Console which is sitting inside the corporate environment is notified of the incoming connection from the vPro client
6. The administrator/technician which is using the Management Console can now initiate any AMT command to the remote vPro client

What components are required for getting CIRA and Fast Call for Help to work?

1. vPro systems
2. Management software that has built in support for Fast Call for Help
3. vPro Enabled Gateway

In addition, you should also be aware that there are configuration files that need to be edited for the vPro Enabled Gateway, some configurable ports need to be open and that AMT provisioning (with CIRA profiles) are a pre-requisite.

Which vPro Hardware do I need to take advantage of Fast Call for Help?

Any vPro system that has AMT Firmware 4.0 and above supports Fast Call for Help. That means any 4.x, 5.x and now the up and coming 6th generation of vPro which is being released in the 1st quarter of 2010. The new capability which is being introduced in 2010 is that this CIRA connection can be initiated over a wireless network interface as well, whereas today it is limited to being initiated over a wired network connection.

Which manageability software is available today for implementing a utilise CIRA capabilities?

1. Symantec Management Suite version 7 (formerly Altiris Management Console and aka CMS7) Beta II
2. LANDesk Management Suite 8.8 SP3
3. Setup and Configuration Service (SCS) 5.x and above (including the Intel DTK) also support CIRA

Which vPro Enabled Gateway products are available today for setting up a CIRA capable infrastructure?

1. Checkpoint Secure Gateway (interoperable with the Symantec Management Console, but not with the LANDesk console)
2. LANDesk Gateway which is embedded inside the LANDesk Management Console (however does require to run specific installer for MPS)

Why am I blogging about this now?

CIRA and Fast Call for Help were actually supported in Intel Firmware from version 4.0 which was released about 1.5 years ago. Unfortunately all the components required to make Fast Call for Help work were either unavailable or had stability issues. However, today the components exist and are validated to work successfully (with a few known issues that are being addressed). Therefore, if this is of interest to you then you are in a position to implement Fast Call for Help in your environment today. We would welcome anyone out there that is interested in trying to implementing this

Is this everything I need to know?

There are more technical details required for a successful implementation, however this should provide a good introduction and starting point. If you have any questions, please don't hesitate to contact me.