If you have Dell or Lenovo client systems with Intel AMT version 6, firmware updates are available to make these systems host based configuration capable. 

 

If you are new to the Host Based Configuration concept, please see http://communities.intel.com/community/openportit/vproexpert/blog/2011/03/07/intel-amt-7-introduces-host-based-configuration

 

On the Dell systems - the latest BIOS will automatically update\enable the functionality.   You are ready to configure the system in Client Control Mode (Need more information on this topic? Use SCS 7.1)

 

For Lenovo systems, the process is a little more involved:

  1. Update to the latest BIOS
  2. Update to the latest Intel AMT firmware release (in my experience, the MEUPDATE.CMD file worked best)
  3. Enable host based based configuration via WMI-based BIOS settings script

 

More details on the 3rd step for Lenovo systems:

  • Review documentation at http://support.lenovo.com/en_US/research/hints-or-tips/detail.page?&LegacyDocID=MIGR-68488
  • Per the documentation, create ListAll.vbs
  • Run cscript ListAll.vbs on client system.   Output will include two datapoints of interest.   The second item may not be accessible in the actual Lenovo BIOS screens.
    • AMTcontrol = Enable
    • HostBasedConfiguration = Disable
  • Per the documentation, create setconfig.vbs
  • Run cscript setconfig HostBasedConfiguration Enable and ensure a success

 

The Lenovo system with Intel AMT 6.2 is now ready for Host Based Configuration

In a previous article, I discussed Link Preference and how it enables better KVM user experience over wireless.  In this article, I will discuss Profile Synchronization, another important capability that makes AMT over wireless a seamless experience.

 

What challenge are we trying to solve?  Although we can configure in advance wireless networks in AMT, but what if the client roams in a new network; one that was never configured before?  You can’t have access to AMT unless AMT is aware of that network.   Profile synchronization solves that problem by pushing the OS’s currently used network's parameters to AMT.

 

OK, so how does it work?

 

First:  Not all AMT wireless profiles are born equal!

 

AMT defines two types of profiles:

Admin profiles: Profiles known in advance and entered by IT administrator (during provisioning or manually using Web-UI for example)

User profiles:  Networks discovered by the OS after the client has been deployed.  AMT get User Profiles only though synchronization.

 

Up to 15 Admin Profiles and 8 User Profiles can be defined in AMT.

 

Other key differences

  1. While Admin Profiles require TKIP or CCMP with WPA minimum encryption, User Profiles have more relaxed requirements and can be configured with WEP or no encryption.
  2. User Profiles are not viewable from Web-UI, only Admin Profiles are viewable *

 

Wireless Profile Synchronization modes

Profile Synchronization supports three modes:

  1. Normal (default)
    Whenever the OS connects to a new wireless network the profile is pushed to AMT but requires user acknowledgment before synchronization.
  2. Always reject
    Synchronization of any new profiles are rejected and no user notification displayed.
  3. Always accept
    Synchronization accepted with no user notification (“Silent Synchronization”)

 

PROSet is currently the only Wireless Connection Manager that supports Profile Synchronization.

  1. The Full PROSet package (except GUI)  must be installed.  The ‘drivers only’ installation does not have the necessary API to support that feature.
  2. Install PROSet with the following option to enable/disable synchronization:
    1. MEPROFILESYNC=ACCEPT (silently accepts all profile sync)
    2. MEPROFILESYNC=BLOCK (silently blocks all profile sync)
  3. If desired, instead of setting the MEPROFILE though PROSet, the registry value can be edited directly:

define     ENABLE_USER_ACCEPT 0x10  // accept all USER profiles, no popup

#define   ENABLE_USER_BLOCKED 0x20  // reject all USER profiles, no popup

 

Other important points about Profile Synchronization:

  1. Only currently connected network is pushed to AMT (discovered networks  are ignored).
  2. Both sides of synchronization (OS & AMT) must be enabled:
    1. OS side (“push” ): PROSet synchronization is enabled as described above
    2. AMT side (“accept”): Configured in the Provisioning Profile: “Enable Synchronization” box
  3. LMS is required for Profile Synchronization.

PROSet communicates with AMT through LMS.

 

 

Profile Synchronization user acknowledgment:

 

ScreenHunter_001.bmp

 

What happens when User Profile password changed?

PROSet will NOT synchronize changes in the profile’s password.   The proper procedure to change profile password is:

  1. First disconnect and delete the network from PROSet
    1. PROSet synchronization will remove the wireless profile from AMT.
  2. Create a new profile with the new password.
  3. Upon connecting to that network, PROSet synchronization will add the profile to AMT.

 

What happens when max of 8 User profiles reached?

When AMT has already maxed out at 8 User Profiles, a newly synchronized network will override the profile that has not been used for the longest time.

 

What happens during provisioning and re-provisioned?

Un-Provisioning deletes, as expected, all Admin Profiles as well as User Profiles.

 

Re-Provisioning however is less intuitive:
During re-provisioning, only Admin Profiles are deleted (and new ones installed based on what is configured in the provisioning profiles), User Profiles however, are NOT removed ** and although the provisioning process competes successfully it gives warning: “ClearWirelessSettings failed” and “Access Denied”.   The warnings look scary but don’t be alarmed, it only means that user profiles could not be deleted but  that’s not an issue.

 

Here is a screen sample of such warning message after re-provisioning completes:

 

 

ScreenHunter_090.bmp

 

 

* This can be confusing, particularly during debugging: you connect with Web-UI and don’t see any User Profiles; you may think they are simply not there, which may or may not be the case.  Knowing this would save you some grief during debugging.

 

** User Profiles are saved in User Space that certain applications (Ex. Web-UI) and Re-Provisioning cannot access  or remove.

Citrix’s announcement of XenDesktop 5.5 is a welcome step in the evolution of desktop virtualization towards a more intelligent infrastructure, one that strives for an improved balance between user experience and IT control.  Three aspects of XenDesktop 5.5 stand out in particular – XenClient2, improvements to HDX and enhanced support for Microsoft infrastructure management technologies.

 

Intel and Citrix have long collaborated on the development of client hypervisor technologies for the enterprise.  Users with Intelligent Clients based on the 2nd Generation Intel® Core™ vPro™ processor family will benefit from the compelling visual experience delivered by XenClient2 based on optimizations for Intel® HD graphics.  IT departments that deploy XenClient2 will be able to offer users flexibility while retaining control based on the ability to define different control policies for personal and corporate environments with full access to the management and security capabilities of Core vPro processors.  In addition, improvements to the synchronization capabilities between XenDesktop and XenClient2 provide an important model for how to maintain images both at the endpoint and in the data center.

 

The many HDX improvements in XenDesktop 5.5 signify an important start in returning balance to VDI deployments.  Specifically, Adobe Flash re-direction and many other more detailed protocol improvements acknowledge that user experience can be enhanced by offloading computing to Intelligent Clients while centralizing image management.  We find this trend encouraging and look forward to broader media redirection and broader offloading to help improve the economics and user experience in VDI scenarios.

 

Last, but not least, enhanced support for Microsoft’s App-V and System Center that permits unified management of virtual and physical desktops is a crucial trend that IT decision makers will greatly appreciate.  Traditional desktop management of Intelligent Clients is well understood and has been continuously improved by Intel, based on the Active Management Technology capabilities of Intel® vPro™ platforms and management consoles, such as System Center Configuration Manager.  It has always been a challenge for IT departments interested in virtual desktops to deal with a different set of management consoles to get similar insight and control over those platforms.  The prospect that Intelligent Clients that are used with or without virtualization can now be managed from the same console should be a very welcome step.

 

While XenDesktop 5.5 and Intelligent Clients clearly offer important improvements for user experience and IT control, we look forward to working with Citrix to drive continued improvements to make desktop virtualization solutions increasingly intelligent by offloading compute to optimize the user experience and drive better infrastructure economics for IT.

So I wanted to use PowerShell to manage a vPro client which was provisioned through host based configuration. Looks like I need to get user consent. Lucky for me there are user consent cmdlets in the Intel vPro Module for PowerShell.

 

First, check if user consent is needed: Type

Get-AMTUserConsent <computer name/ip> -credential <your credentials>

 

check user consent.png

 

In this case, user consent is not necessary – to help determine why I checked the Intel AMT version with:

Get-AMTFirmwareVersion

no need for user consent.png

 

This client is AMT version 4.2 – and since user consent was added in AMT 6.0, I need to go find a newer client!

 

Let us try again with a newer client:

Get-AMTFirmwareVersion

Get-AMTUserConsent

Start-AMTUserConsent

 

  get user consent.png

 

 

Great! The system now can be managed with Intel AMT.

Download Now

 

DigiPoS.jpgDigiPoS brings retailers electronic point of sale solutions that are crucial to their success. And for the last 12 years, it's based these systems exclusively on embedded Intel® architecture processors.


DigiPoS delivers retail solutions that help customers maximize their investments and DigiPoS maintain its competitive advantage.To achieve this, it needs a close working relationship with a company that offers a predictable roadmap of high-performance embedded processor technology. DigiPoS has run its in-store systems exclusively on embedded Intel architecture processors for the last 12 years. Its products run on a variety of technologies from Intel, including the Intel® Atom™ processor, Intel® Core™ i7 vPro™ processor, Intel® Q67 Express Chipset, and Intel® Solid-State Drive (Intel® SSD). DigiPoS is now the third largest EPoS provider across Europe, the Middle East, and Africa (EMEA) and one of the top five across the rest of the globe.


“DigiPoS invests a huge amount of money in research and development based on the Intel embedded processor and chipset roadmap,” explained Phil Parry, group technical director for DigiPoS. “Any last-minute deviations are extremely costly for us, but we can rely on Intel. Unfortunately, we haven't always had this experience with other vendors.”


For the whole story, download our new DigiPoS business success story.

When using a KVM remote control session over LAN, the transition from in-Band to Out-Of-Band is seamless.  However, KVM over wireless is a different story:  when the OS shuts down the KVM session drops during transition from OS control of the interface to Intel ME control of the interface!   The operator needs to close and re-start a new session or use some workaround (ex. SOL).  Same issue when the system goes from OOB back to OS, session drops and important screen messages are lost.

 

Undoubtedly, not a smooth user experience!  Fortunately, there is a solution.

 

Changing Link Preference:

In Intel AMT 6.0 a new feature was introduced:  ability to manually switch who is in control of the wireless network interface: the OS or the Intel ME.   The selection of who is in control of the interface is called Link Preference.

 

With this feature, the solution to the KVM issue is simple: manually switch to ME control of the interface BEFORE shutting down the OS.  By switching to ME in advance, when the OS shuts down, the ME is already in control of the interface and KVM will not experience the transition that causes the session to drop.

 

The only impact when switching Link Preference (either from OS to ME or ME to OS) there is a temporary disconnection (a brief screen refresh) and in some implementations a popup message:

 

             ScreenHunter_002.gif             

 

The two Link Preference options are:

  1. Host Link Preference.  In this mode the OS is in control of the interface. The ME will only take control when the OS is down.   However, transition will cause KVM session to drop.
  2. ME Link Preference.   In this mode, AMT is always in control of the network and it never relinquishes control to the OS.  KVM session will be un-disrupted regardless of reboot or any other state of the system.

 

Which begs the Question:  Why not use the ME Link Preference all the time?   After all, you get continuous un-disrupted connectivity between in-band and Out-of-Band!

 

Here is the catch: LAN & WLAN are two different animals.  Unlike LAN, in WLAN when the ME is in control of the network, the OS does not have access to the network, any OS connectivity to the network is lost.  So if you are in KVM session with ME Link Preference, even if the OS is up, the only network activity possible is AMT related!

 

Typical session flow to a client in In-Band state:

  1. Start your KVM session, Link preference by default is Host OS, do all your In-Band work with Host Link.
  2. When you are ready to bring down the OS, before executing the shutdown command, switch to ME Link.
  3. When you are done with Out-Of-Band work, restart the OS.
  4. When the OS is fully up, switch back to Host Link Preference.

 

With this flow you are in the same un-disrupted KVM session throughout your support activity.

.

Typical session flow to a client in Out-Of-Band state:

  1. First, change Link Preference on the viewer to ME Link Preference and start VNC session.
  2. Perform OOB maintenance functions
  3. When you are done with OOB work, restart the OS
  4. When the OS is fully up, switch to Host Link Preference.

 

Why Connecting to OOB client with ME Link preference?

As mentioned earlier, both transition from OS-to-ME and from ME-to-OS control will cause the KVM session to drop.   When initiating a session to OOB client, the ME is in control.  If your KVM viewer is configured to use OS Link, upon reboot the viewer expects to transition to Host Link that would cause the session to drop.

 

How to change Link Preference

The location of the Link Preference option will vary between the viewer applications.

 

Example #1:

SDK sample application “KVM Console”: the option appears at the top menu under “Wireless”

ScreenHunter_085.bmp

 

When you click on “Wireless”, the following menu appears:

 

ScreenHunter_086.bmp

 

 

Example #2:

In VNC-Plus, feature is located under Options -> Advanced -> AMT Server tab

 

ScreenHunter_087.bmp

 

Note:  Link Preference selection is available only in VNC Viewer PLUS.

As we enter the embedded market, clients residing outside the firewall (“out in the cloud”) are becoming more prevalent with devices such as Digital Signs, ATMs and others.   This is a perfect environment for AMT with FCFH  capability to shine.

 

We know AMT can be complex and adding FCFH  on top does not help.  At the same time, BKMs are scarce.  This high level summary hits on some key points and Gotcha’s when developing a FCFH  based solution.  It also addresses some questions I’ve been getting on FCFH deployment.

 

The basic & simplified architecture of FCFH solution:

  1. Client calls vPro Enabled Gateway (aka MPS) to trigger a connection
  2. vPro Enabled Gateway authenticates with the client and creates a secure tunnel
  3. vPro Enabled Gateway  notifies Management Console that it holds active connection with the client
  4. Management Console connects to the client through the Gateway.

 

ScreenHunter_062.bmp

 

A key component in this solution is the vPro Enabled Gateway (aka MPS).

The vPro Enabled Gateway  has the following functions:

  1. Respond to client’s request and create secure tunnel
  2. Notify Management Console that connection has been opened (or closed)
  3. Act as a proxy to all ClientßàManagement Console traffic (forward traffic).

The vPro Enabled Gateway has no awareness of the content of the traffic it forwards, but it is aware of type of traffic (HTTP or SOAP) as it needs to route it to the correct service (see next item).

 

The vPro Enabled Gateway is comprised of three services:

  1. sTunnel – responsible for creating secure connection with the client
  2. MPS – responsible for all SOAP traffic
  3. Apache – Responsible for all HTTP traffic

ScreenHunter_060.bmp

 

For simplification, I will refer to the vPro Enabled Gateway as a Black Box and not worry about its internal communication.  I will only discuss its external interfaces:

 

     1.     Interface to the internet:

    Few conditions must be met for the client to find the vPro Enabled Gateway:

  1. sTunnel listening port:  FQDN:Port#  must be visible on the internet
  2. AMT is configured with Gateway’s FQDN:port# during provisioning
  3. FQDN of the vPro Enabled Gateway must be resolvable

-   Static IP of vPro Enabled Gateway can also be entered but requires additional info in the provisioning profile

     2.     Interface to the enterprise

               vPro Enabled Gateway has two separate connections for communicating with the Management Console

  1. SOAP traffic for  Re-direction & KVM
  2. HTTP for all web services traffic (all other AMT commands)
  3. Management Console listens on a single port for both types of traffic

FCFH  connection with TLS vs, Non-TLS

There is confusion about Non-TLS optoin is in the context of FCFH connection: namely: "How can a client on the internet connect over non-TLS connection? isn't that a serious breach of security"?

 

Here is clarification:

  1. The connection between the client and vPro Enabled Gateway is always TLS regardless of your TLS choice in the provisioning profile!  even you you choose "No-TLS" in the provisioning prfile.
  2. The Client/Gateway authetnication & encryption is done when the client established conneciton with sTunnel.  This is why we install a web server cert on sTunnel during environment setup and a trusted root cert on every client during provisioning.
  3. The entire connection link between Management Console and AMT client can be either TLS or non-TLS (as defined in the provisioning profile).  If TLS is selected, the Client/Gateway connection which is already TLS (as described above) will be encrypted twice! (TLS on top of TLS).

Certificate Authority Requirement

A FCFH  deployment must have CA in the env.  Reason being: As described above, client and vPro Enabled Gateway must authenticate before connection can be established.  This implies that a web server cert must be installed on the vPro Enabled Gateway, and a Trusted Root Certificate installed on every client.
If the env does not have a CA:  a potential workaround could be to temporarily create a CA, generate the required web server cert & trusted root cert and then shutdown the CA.  The trusted root cert must be available during provisioning.

 

Commercial Gateway vs SDK gateway

The configuration of SDK gateway is more complex and involved tinkering with three separate configuration files.  Although a configuration GUI based tool is provided, there is still significant learning curve and debugging is a non-trivial task.  Using Commercial product should make the process easier (although I never tried it myself).

 

Connection Time-Out
I’ve been getting questions about connection timeout.  Concern is “will connection timeoout and close while I am working on a client?”.  The answer is No.
Here is quick background and how connection timeout works:

MPS ability to handle large number of connections is limited (recommended not more than 250 concurrent active connections) which could be an issue in large scale deployments. To control the number of active connections, we define in the Provisioning Profile an ‘idle-timeout’ parameter.  When FCFH  connection is established, AMT timer starts counting down as long as no activity detected on that connection.  Once there is activity, the timer resets.  For example, if idle timeout is 30 minutes, and 25 minutes went by with no activity, then you run some command (ex. check AMT power state), the timer will re-set back to 0 and will start counting down from the moment there is no activity again.  So as long as there is SOME activity on that connection in this 30 minutes window, the connection will remain open.

 

Connection Notification

I’ve been asked if vPro Enabled Gateway can notify more then on Management Console about connection Opened or Closed.   The answer is yes.   A simple entry in a configuration file will direct connection notification up-to 8 different Management Consoles,  This is useful for development as well as support multiple operators.

 

Management Console.

Currently, only few management consoles support FCFH connection natively.  Most customers will need to develop some level of scripting to manage their clients over FCFH  connection.   With the introduction of FCFH  support in PowerShell 3.1, this has become a whole lot easier.


However, PowerShell support solves only the Use case implementation aspect.  There is still the issue of tracking connections status: in a large deployment, the operator needs to know which clients have active connections and when clients will re-connect.   A query to the gateway can be performed, but this is not practical and gives only a list of Active connections with no other information.

 

To address these shortcomings, a FCFH console solution is needed to complete the solution.  We are developing a sample application for demo purposes only (still in early beta, and not for customer use) that features the following capabilities:

  1. List all clients which has currently active connections
  2. When the connection will be timed out (idle-timeout for each connection)
  3. What triggered the connection (User/Event/Scheduler)
  4. Quick access to few use cases
  5. Which clients are currently disconnected
  6. Time left for scheduler to initiate a connection.

Filter Blog

By author:
By date:
By tag: