When designing a vPro deployment strategy it is important to understand the implications of your decisions on your ability to scale your vPro deployment beyond one management application. Here are a few of the basic principles that are important in these decisions:

· Reduce the number of client dependencies by updating your vPro firmware and vPro drivers

· Choose one application and method for initial setup and configuration

· Determine which application is going to manage which aspect of vPro feature configuration

· Use Kerberos authentication

· Understand how to share TLS across applications

The details behind these principles are described below.


Intel vPro is a suite of individual technologies. The term vPro means manageability, security and power efficiency among other things. Depending on your companies needs you may desire to take advantage of some or all of the individual features of a given vPro system. Similar to the rest of your infrastructure the ways that you interact with vPro may be different depending on the use case. For example, you may find yourself with a software deployment console that needs to use vPro for waking up machines that are powered off and security software that uses vPro to manage a System Defense firewall. Both pieces of software would need access to vPro functionality and need to cooperate together to provide a full set of vPro functionality. As an analogy, it would be uncommon for a given IT department to only have one tool that manages Windows clients. They would more likely use a combination of tools such as MMC snap-ins, Remote Desktop, Group Policy Objects, 3rd party consoles, etc.

This article attempts to speak to vPro ISV interoperability and outline the path to success in sharing access to vPro across ISVs. Understanding the interoperability decisions relating to vPro will ensure that your vPro deployment is scalable beyond your initial usage of vPro. Also, as vPro progresses as a product the list of features that the vPro suite contains will expand. It will become increasingly difficult to use one tool to get all of the functionality out of vPro.

The basic concepts that make for an interoperable vPro deployment are the following:

· vPro Lifecycle – How the vPro lifecycle impacts interoperability

o Separation of Duties – Determining which features of vPro are managed by which ISV

· Authentication – Understanding how authentication decisions impact interoperability

· Encryption – Figuring out how to share encryption keys used to protect communication transport

vPro Lifecycle

There are several aspects to the vPro lifecycle that impact interoperability ranging vPro firmware/software versions to turning on vPro to managing the feature. Putting together a plan to manage each aspect of the lifecycle can help make for an easier path to interoperability.

vPro Firmware/Driver Versions

When you obtain a new machine it is important to check with the OEM to ensure that your machine has the latest firmware and vPro drivers. The reason this is so important is because it will help to make your interoperability matrix as small as possible. As a general rule, there has historically been a new major version of firmware and drivers for each new platform year. Beyond each year’s release, there are also updates that fix issues or back-port features for consistency and forward compatibility. Maintaining each of your machines firmware and driver versions will decrease the number of different vPro configurations you have in your environment and make management through consoles easier and more consistent.

vPro firmware and drivers are typically available on the OEMs support/download section of their site. The firmware is usually coupled with the BIOS firmware and available through a BIOS update. The drivers include the HECI (low level driver) and LMS (higher level service) as well as other components that help complete the vPro use cases.

Initial Setup and Configuration

The enablement of vPro on a given machine is often referred to as ‘vPro provisioning’. The term provisioning can be broken into two parts – initial setup and initial configuration. Since it is important to differentiate these two parts of provisioning for this conversation, the term Initial setup and configuration will be used to describe these two sub-processes of provisioning.

Initial setup at a high level is the initial trust establishment that allows the machine to know that you are authorized to turn on the vPro features. This can be done through a number of methods including through MEBx, USB Key One-Touch, and Remote Configuration. This initial configuration step is typically completed using ISV software assistance. For example the ISV software might create the USB key utilized through the One-Touch configuration or act as the coordination point for remote configuration. The initial setup phase is broken down into a smaller subset of steps all utilized to establish trust for the subsequent configuration phases. These steps include (but are not necessarily limited to) the following:

· Setting the remote administrator password

· Synchronizing the clock (important for the Kerberos authentication protocol)

· Configuring TLS mode

Once initial setup is completed, the initial configuration can be applied to the machine. This initial profile should include the minimal necessary information in order to manage the system from there on out. Some primary examples of what is included in initial configuration are the network/wireless settings as well as authentication configuration (discussed in a later section). The basic idea is to then allow multiple ISVs to utilize this information (network access and credentials) in order to configure the different features of vPro that they care about. Here are a few examples of configuration that is set during initial configuration:

· Wireless profiles

· Additional digest users or Kerberos ACLs

· Enablement of the web administrative interface

This initial setup and configuration should be managed by one source. Having a consistent way of enabling vPro and setting the initial configuration network and authentication credentials is critical to achieving ISV interoperability. That way there is one consistent way to access the machines after the initial configuration is done.

To be clear, this initial setup and configuration should not be confused with subsequent usage of vPro. Policies and settings such as System Defense Filters, Agent Presence, Third Party Data Storage (3PDS), etc are all examples of things that are outside of the scope of initial setup and configuration and therefore can be managed easily outside this single setup and configuration source. The only requirement being that the software configuring these usages should be configured to use the authentication credentials / encryption mechanisms that were established via initial setup and configuration. This concept and examples on how this is achieved is discussed throughout this post.

If for some reason the method of initial configuration needs to change midway through deployment, you may need to either migrate the data that was set through initial configuration using a tool such as the SCS to SCCM migration tool or as a last resort go back through the initial setup and configuration process again using the new console. Instructions on how to do this can be found here.

Using the features

When multiple vPro enabled software applications are used to manage the same client it is important to clearly delineate between the roles of the two applications. This delineation might be decided for you based on the functionality of the software and the indented usage of vPro, however there may be overlap between two software offerings. In that case, IT policy should take over.

The basic idea behind determining a clean separation of duties for vPro enabled applications is to figure out which applications will manage which parts of vPro. An easy way to think about this is based on the origination of the data. Here are some examples:

· Security software the manages the System Defense filters

· Auditing software that maintains the audit logs and event logs

· Management software that manages Client Initiated Remote Access (CIRA) settings

There also might be examples where multiple software applications might utilize the same features of vPro at different times. For example most or all of them might utilize the following:

· Remote power control capabilities


· Asset inventory

The ability for these software applications to manage the features of vPro that they are responsible for and share the usage of the other features is made possible by setting up the proper authentication/authorization and encryption policies.


Authentication is the act of proving you are who you say you are. It is important to understand the different ways that you can authenticate to vPro and the role that the IT infrastructure can play in this proof of identity. This not only applies to individuals but service accounts as well. vPro supports both HTTP Digest Authentication as well as Active Directory Kerberos Authentication. Here is a brief description of both:

Digest Authentication

Digest authentication is a simple passing of a username and password through the digest protocol. It is considered to be reasonably secure when coupled with SSL and easy to setup since all you have to do is create a username and password in order to establish a trust between two endpoints. The drawback to digest authentication lies in scalability and interoperability.

When using vPro with digest authentication, it is recommended for security reasons that the console creates a unique password for each vPro system so that if one password is compromised, then all machines are not compromised. This creates a difficult interoperability problem. This means that the console that is responsible for initial configuration (and therefore creates the initial digest password) will need to store all of the unique passwords in their data store. If another ISV wants to then subsequently gain access to that vPro system they need to either gain access to that data store to get the passwords or have the initial configuration console create a new account with new passwords on each machine for that application. Since there is no standard interface for this console to console communication and sharing of usernames and passwords and because this large number of accounts can quickly become difficult to manage, it is strongly recommended to use Kerberos if interoperability is a goal of your deployment.

If digest must be used and interoperability between vPro enabled software is desired, it might be a worthwhile exercise to investigate your needs for interoperability vs. the risk of security exposure by making the digest password the same across all managed vPro clients. Making the digest password the same across machines would allow all software access to all machines without having to share machine specific credentials. Again, Kerberos gives you these same benefits without the same exposures. The primary reason is that the Kerberos account is centrally controlled. If compromised, the password can be changed once centrally to mitigate the exposure without having to connect to each remote machine to change it. Also since the account is managed centrally with Kerberos, it is easier to create vPro software specific service accounts that only have access to a smaller number of vPro features. Doing this with Digest could result in an unreasonably large number of usernames and passwords that would be difficult to manage per machine.

Active Directory Kerberos Authentication

Kerberos is an authentication protocol that allows someone to gain access to network based resources based on that initial authentication by trusting the central source that originally authorized that user. The Kerberos protocol is a bit more complicated than digest; however it has the advantage of providing a secure answer for scalability and interoperability. If you have Active Directory deployed in your company, you have the infrastructure you need to support Kerberos authentication.

Kerberos works by sending the username and password securely to a central authentication server. The authentication server then authorizes them to gain access to other network resources that trust that same authentication server. This means that the username and password only needs to be stored once on that authentication server and because the authentication server is trusted by the environment it provides one place for central management of those credentials.

Microsoft centered their Active Directory solution around Kerberos in order to simplify account management and allow for interoperability between different resources based on a single authentication. For these same reasons and based on the fact that vPro seamlessly integrates with Active Directory, Kerberos is a far better choice for vPro authentication in the context of interoperability, scalability and manageability.

Again, here are some of the reasons that centrally managed Active Directory Kerberos accounts are superior to Digest for interoperability:

· Reduces the number of individual usernames and passwords to manage/share

· Better security since control is centralized

· Account management such as changing passwords can be done once rather than once per machine


Once a user or service is authenticated using either digest or Kerberos authentication the user then needs to be mapped to a set of allowed actions. In vPro this association between a user and the actions they are authorized to perform is controlled through Realms. vPro Realms are predefined groupings of control that can give one user or service access to a given feature of vPro and another user access to another feature isolating the ability for each to control the other. Here are some examples:

· Users that need administrative access to the entire set of vPro features should be assigned to the PTAdministrationRealm

· Software that needs access to manage System Defense should be assigned to the CircuitBreakerRealm

· Software that needs to wake up or shut down a machine should be part of the RemoteControlRealm

It is common that the software managing these realm assignments abstracts the names or even blurs lines between the realms. There are even software applications that completely abstract the realm assignment by inserting the authorization logic into their application. Regardless of how the software chooses to utilize these realm assignments it is important to understand the realm assignments and how they impact your plans to allow for interoperability. As you are doing this ensure that you are assigning the least privilege necessary to get the job done, which will not only help to isolate your applications, but ensure a more secure deployment.


vPro supports SSL and TLS in order to protect the information passing between the vPro enabled software application and the vPro client. This is an optional component of the vPro configuration but is strongly suggested for security reasons. Some of the vPro enabled software consoles extract the complexity of configuring encrypted communication and enable it by default. If there is an expectation that multiple vPro enabled software applications should be able to communicate securely to vPro clients, then there needs to be a strategy for trusting the CA used to secure that connection.

The encryption technology vPro uses is the same that is used to protect you when you are going to your banks website to check your account balance. The way it works is through a public/private key pair where the vPro client is similar to the banks web server containing the private key and the vPro enabled software application or web browser used to manage vPro needs the public certificate. vPro only supports storing one private key used to establish secure communication so similar to other features of vPro you will need to choose which console will manage the lifecycle of that certificate. It would typically make sense that this is the same console that owns the initial setup and configuration. Once you have made this decision, the other consoles need to utilize that same key pair to communicate securely with the vPro clients.

The high level process used to share this key pair includes exporting the public key from the console that originally configured encryption and importing it into the other vPro enabled software applications certificate store. This isn’t as hard as it sounds. For example, here are the steps to export the Root CA certificate that is used with SCS. This process only needs to be done once per server that needs to manage vPro.

To export the certificate and save it as a file:

Note: There are several methods of exporting a certificate. This section describes one method.

1. Click the Windows Start button > Programs > Administrative Tools > Certification Authority.

2. Right-click on the first sub-branch. A popup menu is displayed.

3. Click Properties and click the General tab.

4. Select the certificate and click View Certificate.

5. Click the Details tab and click Copy to file.

6. Follow the steps in the Wizard: Select an export format (any of the options is acceptable), name the certificate file, and save it in a known location. A message indicates that the export was successful. Click OK. The Details tab returns to focus.

7. Click OK > OK. The Certification Authority Management Console returns to focus.

To install the CA certificate in the certificate store as a trusted root certificate:

Note: This step is not required if the CA is installed on the local platform.

1. Find the certificate. If it was exported directly to another computer, find it on the other computer. If it was exported to a USB key, move it from the USB key to the computer.

2. Right-click on the certificate and from the popup menu and select Install Certificate. The welcome screen of the Certificate Import Wizard is displayed. Click Next.

3. Select Place all certificates in the following store and click Browse. The Select Certificate Store window opens.

4. Select Trusted Root Certification Authorities and click OK.

5. Click Next > Finish. A message indicates that the import was successful. Click OK.


With proper planning vPro configuration can easily be managed by several vPro enabled applications. Having an understanding of the separation of duties for those applications and the authentication/encryption technology vPro uses can make for a vPro deployment that scales beyond one ISV.


Here is a simple video that demostrates how SCCM and Altiris can interoperate together to manage vPro Out of Band functionality.


Craig Owen & Matt Royer