If you're reading this blog posting, hopefully you've read my blog post on CIRA last week -
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:
- 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).
- 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)
- In the httpd.conf file - instead of havinga deny all and allow specific IP addresses, you might want to change to allow all
- 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.
- Currently, you should install the LANDesk agent after provisioning is completed
- 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:
- 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.
- 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.
- 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) -
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.
Miss the Win7 and Intel vPro technical webinar? Recording now available.
Posted by Michele Gartner Nov 18, 2009
Managing Help Desk permissions in vPro with Microsoft Configuration Manager
Posted by Jake Gauthier Nov 18, 2009
If you are one of the many organisations that is planning on adopting Windows 7 and are wondering whether there are any implications for your vPro systems, then this blog is for you...
The implications of Windows 7 on vPro can be summarised as relating to at least one or more of the following areas:
Let's start with the Management Console...
If you are using Microsoft SMS, for example, as your management console then you should be aware that Microsoft officially doesn't support Windows 7 clients with SMS and therefore if you wish to manage your Windows 7 clients you will need to transition to Microsoft SCCM. Therefore, when planning your vPro migration to Windows 7 you need to actually to migrate to SCCM before hand.
For those that do migrate to SCCM there are some additional implications which are indirect for the Windows 7 migration, but are part of the SCCM with vPro package. As this is not a posting on SCCM, I'll only mention briefly that you need to be prepared to have an Enterprise Certificate Authority, potentially have to make use of the WS-MAN translator (if you have any AMT Firmware that is prior to 3.2.1), you will need to upgrade to latest AMT Firmware versions and you will be integrated with Active Directory.
Regarding AMT Drivers (namely HECI/MEI and LMS/SOL)...
As the drivers are installed at the OS level, it doesn't come as a surprise that there might be a requirement for drivers to be able to install on a new operating system.
- AMT 2.x based systems - currently no planned official AMT Windows 7 drivers (use compatability mode)
- AMT 3.x based systems - official AMT Windows 7 drivers will be available by OEMs in Q1 of 2010 (for now use compatability mode)
- AMT 4.x based systems - you will require drivers version number 4.2 (otherwise you could use compatability mode)
- AMT 5.x based systems - you will require drivers version number 5.2 (otherwise you could use compatability mode)
If you are not familiar with compatability mode, here is how you do it:
1. Right click on the driver installation file à Properties à Compatibility tab (per sample screen shot below):
2. Select the mode (I guess either Windows Vista or Windows XP SP2 or SP3)
3. Click Apply/OK
4. Right click installation file and run as Administrator and install the drivers (or alternatively prior to step 3 tick the box of run as administrator)
Btw, the exact same process can be used for AMT 4.x and AMT 5.x drivers – i.e. take existing not 4.2/5.2 level drivers and install them in compatibility mode.
It is useful to know that the 4.2 and 5.2 level drivers are actually available for download fromt the OEM sites; take Dell for example: http://support.dell.com/support/downloads/driverslist.aspx?c=us&l=en&s=gen&ServiceTag=&SystemID=LAT_E6400&os=WLH&osl=en&catid=&impid=
and
Lastly, we have the AMT Firmware...
Strictly technically speaking, Windows 7 doesn't require a different kind of AMT Firmware, since the firmware sits underneath the operating system anyway. What is required though is the latest AMT Firmware (4.2 and 5.2) so that it can interoperate with Microsoft SCCM in the best and most stable manner. Therefore what might initially seemed as no need to upgrade AMT firmware to work with Windows 7 actually becomes a recommendation to do so.
Hopefully this has provided some clarity on the technical requirements around vPro and Windows 7. There are some particular compelling points for having vPro systems and leveraging them for a Windows 7 migration deployment, however this is covered by other blogs and materials out there, such as: http://communities.intel.com/docs/DOC-3096
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
Known Issues wiki: LANDesk, MS ConfigMgr, Remote BIOS update, and more.
Posted by Michele Gartner Nov 5, 2009
Matt Royer wrote in June about some of the new AMT-related features being included in Service Pack 2 for Microsoft System Center Configuration Manager 2007. I recently installed ConfigMgr SP2 in my lab environment, and wanted to follow up on Matt's post by sharing some screenshots of the new AMT features, for those of you that may not be beta testing SP2
** The updated AMT Settings screen, which now features the option to set the power package for the management controller.
** The new Provisioning Schedule screen (no more editing your sitectrl.ct0 file!)
** The new main 802.1x & Wireless Profile Configuration screen (there are a couple of detail screens below)
** The new Wireless Profile Detail screen
** The new 802.1x Profile Detail screen
I don't have a provisioned client in my lab yet, but once I do, I will see if I can investigate the updated Microsoft OOB Console, and capture some screenshots. As Matt's post stated, there should be added functionality for inputting information into the 3PDS (Third-party data store), so I assume there will at least be that change.
Cheers,
Trevor Sullivan
Systems Engineer
Hello vPro Experts!
I would like to pass on some information that I discovered a while ago, based on a Microsoft Premiere Support ticket. I was having trouble getting the Microsoft Out-of-Band (OOB) Management Console functioning from a Windows XP system. I tried everything on a fresh, standard build of Windows XP, but nothing would work.
After working with Premiere Support, we finally discovered that Windows XP Service Pack 3 (SP3) was required for proper functioning of the Microsoft OOB console.
This behavior is actually related to some functionality that was added in SP3, specifically in the winhttp.dll library. There is a function called WinHttpSetOption in the WinHttp library, which is called with a parameter enabling the WinHttp Option Flag named WINHTTP_ENABLE_SPN_SERVER_PORT. This flag enables the WinHttp library to include the server port in the Kerberos Service Principle Name (SPN), since the AMT web service is running on a non-standard HTTP port (16993).
The Windows XP Service Pack 2 (SP2) version of the WinHttp library does not include this capability, and consequently fails to authenticate. In order to properly connect to ConfigMgr-provisioned AMT devices with the Microsoft OOB Console, please make sure your helpdesk / support systems are running Windows XP SP3.
If you have any questions, feel free to post them in the comments section, and I will do my best to answer them.
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
Dell just released a new BIOS update for the Dell Optiplex 755 system, version A13. This update includes an AMT firmware update to version 3.2.3 also that resolves a couple of security issues. I just performed the update on an Optiplex 755 that I had already provisioned, and it didn't break anything
If you're deploying the BIOS update via a ESM software package, such as Microsoft System Center Configuration Manager (SCCM) 2007, you can automate the staging of the BIOS update (without forcing a reboot) using the following command line:
O755-A13.exe -noreboot -nopause
Trevor Sullivan
Systems Engineer
OfficeMax Corporation
Hello!
Have you ever run into the situation where you want to enable the auto-provisioning policy for a ConfigMgr client, but dont' want to wait for the policy to filter down to the client? If you're like me, then you would answer with a hearty "yes." Thankfully, I've got a method for you to force an SCCM client to enable auto-provisioning, without relying on the collection setting!
Keep in mind that, for some odd reason, pasting this code into a Powershell window will probably fail. Instead, paste the first 4 lines, and manually type out the last (red) line.
$OobSettings = [wmiclass]”root\ccm\policy\machine\actualconfig:CCM_OutOfBandManagementSettings”
$OobSettingsInstance = $OobSettings.CreateInstance()
$OobSettingsInstance.AutoProvision = $True
$OobSettingsInstance.SiteSettingsKey = 1
$OobSettingsInstance.Put()
Basically what this does is spawn an instance of the CCM_OutOfBandManagementSettings WMI class, sets two properties on it, and then writes it back to the system. This should enable auto-provisioning immediately so you don't have to wait!
Trevor Sullivan
Systems Engineer
OfficeMax Corporation