Intel vPro Expert Center Blog

4 Posts authored by: ninbar

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.

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.

If you want to upgrade your Centrino Pro laptop from AMT 2.5 to 2.6 to take advantage of Remote Configuration (RCFG, AKA "Zero Touch"), it can be done, but few gotach's you need to be aware of:

 

First, the basics: There are two independent Firmware components at play: The ME Firmware, which is the actual AMT embedded software, and MEBx which is a BIOS extention that provides the interface to configure AMT.

 

Once you have upgrad the AMT ME Firmware to 2.6 (that you downloaded from Intel web site), your MEBx reamins at a previous ver (i.e 2.5). So, when you go to MEBx screen (using cntrl-P), what you see at the top right of the screen is the version of MEBx not AMT. Many people are confused by that and think that this is the AMT version, which it is not. To see the actual AMT version, you can either run MEInfo (tool which is available with the FW download), or, simply login to AMT through the webUI.

 

Here is the complication: MEBx, being the older version, does not expose 2.6 features (such as managing certificate hashes) so how can you provision the system in RCFG? As it turns out, when you "un-provision" the client, AMT goes to a default state which is ‘ready for RCFG'. Since it has the built-in certificates hashes, it can be provisioned with one of them. But again, since MEBx 2.5 does not provide access to certificate management, you can not add your own certificate hashes.

 

 

This complication stems from the fact that OEMs have not posted yet release 2.6. Usually, OEMs FW release will include both MEBx and AMT as one package. When you download AMT from Intel web site, you get only AMT FW (MEBx is vendor specific). Once OEMs post 2.6 on their website, both MEBx & AMT FW will match and there will be no confusion.

 

 

Happy upgrade!

--Noah Inbar

 

 

Filter Blog

By author:
By date:
By tag: