Intel vPro Expert Center Blog

Real world experiences with provisioning using a hybrid Activator Utility and Scripts approach

Tal_Elgar — Wed, 03 Sep 2008 12:45:47 GMT

As many of you might know or have experienced, relying fully on the default provisioning window where the Management Engine sends 'Hello Packets' to the SCS server is problematic. Problems start arising in the following instances:

The network has multiple domain suffices being allocated as connection specific DNS suffices depending on location and this could potentially lead to a mismatch between the SCS domain suffix and the client domain suffix.
DHCP option 15 upon which the default process relies on might need be in use for one reason or another
The provisioning window (24 hours for RCFG and 6 hours for PID/PPS by default) has closed before the infrastructure has been put in place to do something useful with these hello messages.

In the past there was a solution based on sample vbscripts provided by Intel- either Server side only or a combination of client and server side scripts that would be used in conjunction with SCS. This has now evolved to the Activator Utility which is considered the best known method, however there are some subtleties where using the Activator isn't as straight forward, such as:

The Activator utility will typically run under the context of the Local System Account - to allow each Local System Account to write information to the SCS DB requires delegating control all the Computer Objects. This is seen as a significant security risk by some organisations.
The syntax for running the Activator utility necessitates the specification of a profile ID. The number of the profile ID can't be pre-determined with absolute certainty and the SCS API only accept the profile ID and not the profile name. A situation can ensue that the wrong profile ID has been hardcoded on the clients.
Some operations like /a cannot work under the Local System Account context to begin with

Together with the hetrogeneous states of vPro machines (some provisioned, some not, some needing to be re-provisioned) some further logic needs to be put in place to provide a robust end to end solution. This has lead to the implementation (in a nutshell) of the following solution at a large scale enterprise customer (it assumes knowledge of the activator utility and it's switches):

A scriptable interface needs to be able to determine whether a system is provisioned or not - this is achieved by running MEInfo and parsing the contents of the output and writing some information into registry keys.
A script always checks the registry keys to know whether to run the Activator utility
The script is run at every boot-up of the system to make sure any previous failed attempts or if the system has been unprovisioned since the last boot is covered
Once a script (which runs under the context of the Local System Account) determines it needs to execute - i.e. the machine is unprovisioned but has PID/PPS loaded it runs the Activator Utility with the //s h /d PID but not /o and /p
At this point you might ask yourself, if I am using the client side vbscript, why should I use the Activator tool as well? The answer is that the Activator tool provides you the ability to send an in-band 'hello message' to kick-off the provisioning process. That is why we make use of the /h and /d PID parameters. If you wouldn't use the Activator tool, the out of band 'hello messages' would have easily timed-out a long time ago and you wouldn't be able to commence their resending unless you pulled the power cable out and back in - i.e. restart the Management Engine.
The PID is predetermined per machine type and can be inserted into XML file that sits in client - if the PID was unique per each machine this would have broken the whole solution - hence a clear recommendation to have the same PID/PPS across all machines or at least across all machines of the same model
At this point the information is written into an Interim DB using SQL account permissions
Note that no permissions need to have been delegated for all Local System Accounts
On the server side the script uses the same or different SQL account permissions to access to the interim DB
On the server side the script contains the /p and /o parameters - this is crucial as this is a single point where the /p and /o parameters can be changed thus providing flexibility
In addition since the customer has opted to not use certificates and because there is a difference between the connection specific and Active Directory domain suffices, provisioning is take place with hostname only - typically this would have involved using the /a switch, however there is a known issue that won't work under the context of the Local System Account. Therefore the FQDN is stripped of it's domain the server script and the hostname is derived.
The server script creates an XML file with the appropriate content to plug into the Configuration Parameters table in the main SCS DB, as the SCS service can parse the contents of this XML file and check that it is valid content.

The overall benefit of this solution is you avoid the security risk of delegating access rights for all Local System accounts, cover the different scenarios when the Activator Utility should be run, avoid the problems of mismatching domain suffices and maintain the flexibility of a single point of changing parameters for the variable Activator Utility syntax.

The same logic will apply if you are using RCFG - simply ignore point #6 above regarding PID.

Hope some of you find this useful.

Thanks, Tal

SCS 5.0 - Setup and Configuration version 5.0 - the latest and greatest

Tal_Elgar — Mon, 01 Sep 2008 22:14:35 GMT

SCS 5.0 is the latest version of the Intel Setup and Configuration Service. This new version boasts a number of fundamental and exciting additions to the world of vPro:

You can enjoy the benefits of Active Directory Integration without the need to extend the Active Directory Schema!
You can use Windows Authentication to communicate with the SCS Database
The SCS Console version 5.0 has a much nicer and professional looking user interface
The performance, stability and logging capabilities of the application have notably improved
You have the ability to dynamically create collectoins of AMT Systems based on different filter conditions
This is still early days for AMT Firmware versions 4 and 5 and the use of CIRA (Client Initiated Remote Access) and MPS (Management Presence Server) but it supports them

Note: If you are using SMS as your Management Software you will need to use the Intel (R) Client Manageability Addon version 5.0 which is available for download from the following url: http://downloadcenter.intel.com/Filter_Results.aspx?strOSs=All&strTypes=All&ProductID=2609&lang=eng&OSFullName=All%20Operating%20Systems

To emphasize the point - you will not be able to use SMS Addon version 3.3 with SCS 5.0. SCS version 5.0 will be bundled already for you with the Addon version 5.0.

Some potentially useful technical insights that I have gathered through my experience of being an early adopter of SCS 5.0 through trying to deploy it at a large-scale enterprise customer:

If you opt for having windows authentication (as opposed to the dummy SQL account which was part of the design up until SCS 3.3) you will need to opt for the custom installation path. In there you will be prompted to specify twice the user for running the AMTSCS and AMTSCS_RCFG virtual directories in IIS. You will need to specify the same username and password of the accounts that are running your IIS services where your SCS is being installed. Pay attention to this step - if you specify any user other than the user that is running the IIS services: this could a local account for example and not a domain account, then you will not be able to log into SCS via the SCS console.
When you opt for the windows authentication to DB you wil not be able to use the default website on IIS. If you are creating a new website and you are going to opt for https connection, make sure your new website is setup with the server ssl certificate. You will also need to remember to stop the default website and have your new website running.
You will need to remember to delegate permissions to the account that is running the SCS service on the AD OU for AMT objects, but this time it will be for objects of type 'Computer Objects'. There will not be a conflict with the Host OS level computer objects as these AMT Computer Objects are seen as user objects.
You have the option to create the DB separately using an SQL Standalone DB script (i.e. not as part of the install wizard) however even if you are opting for windows authentication to your SCS DB, you can achieve this by only running the wizard (the custom install path). If you have created the DB prior to SCS install, you can point the SCS service to this DB instance during the install wizard.
A general point to note that would apply to any provisioning with SCS (not just SCS 5.0) - when you are creating a profile
Another point to mention is that the profile ID number is not fully deterministic if you don't run through the config of a new profile without pressing cancel at any point. For example, if you have the default profile as profile ID #1 then when you try and create an additional profile and at some point click cancel and then try and create a new profile it can eventually have a profile ID of #5 for example. This can start becoming a problem if you rely on the profile ID number as part of your provisioning process using the Activator Utility for example, as you can only pass the profile ID as far as the SCS API is concerned, yet if you've hardcoded the profile ID in some file on the vPro client where your Activator Utility will run then you cannot know for sure until your profile has been created in SCS what its profile ID will be. If you are editing an existing profile, its ID number won't change. You also cannot go into the DB and change that value manually as it is a primary key and is auto generated as part of an indexing mechanism in the SCS code. - this one might be a bit tricky, so contact me if you need me to clarify.
I don't know whether you've noticed any sluggishness in the past when trying to install 3.x versions of SCS - for example with one of my large customers it would take 1.5 hours to install SCS because of looking up users in a rather large Active Directory; whereas with SCS 5.0 it takes 5 minutes at most.
Whilst I haven't taken advantage of the capability to create collectoins of AMT systems I wanted to point out one of the main benefits of this feature. I have been faced in the past with situations where I need to perform an operation through SCS on many machines, but not all machines. Therefore the global operations in SCS 3.x versions only gave me the possibility of running the command on a single or all machines. Now I can tailor which machines I want to perform operations on.

My overall recommendation to you is to give SCS 5.0 a go. It is easily the best SCS version that has been released. I have blogged about it as part of my first hand experiences - I have had nothing to do with its development and I am speaking out of the objective view of a user. Hope you find this useful.

Tal

Got 10 min? Provision Intel AMT in Basic Mode!

Kelsey_Witherow — Tue, 10 Jun 2008 22:21:57 GMT

Here's a video I created to show step by step how to provisioning Intel Active Management Technology in basic mode. Check it out!

**Please Note: Basic was previously called SMB mode. Standard and Advanced were referred to as Enterprise mode. See Michele's Understanding Provisioning Models - Basic, Standard, & Advanced for explanation.

Useful links for everything vPro - Compiled into one page!

Kelsey_Witherow — Tue, 13 May 2008 22:15:36 GMT

Be sure to view this brand new resource created in the activation subzone. It details out nearly 40 links to documents, tools, and websites that aide in activation of Intel vPro Technology.
CHECK IT OUT:
vPro Useful Links

Provisioning: Hopefully more answers than questions

mprimros — Tue, 06 May 2008 07:16:30 GMT

I've been getting quite a few questions recenly regarding provisioning. Many folks are confused when it comes to what type of provisioning works with which versions of AMT and I'm hoping that this post will help to clear up some of that confusion.

Currently, there are two types of provisioning, PKI (Protected Key Infrastructure) and PSK (Pre Shared Key). For those who are not familiar with what is involved with these two types of provisioning, PKI involves using a formatted provisioning certificate in order to establish a trust relationship between the AMT client and provisioning server where PSK uses a PID/PPS key pair to establish the trust for provisioning. There is quite a bit of documentation regarding how to setup PKI and PSK provisioning in the deployment documents for AMT, so I won't go into that detail here. What I'd like to cover here is what are the differences between these types of provisioning and which versions of AMT use which types of provisioning.

First, lets cover the different types of provisioning and a brief overview how each of them work.

PSK provisioning uses a Pre Shared Key to encrypt the provisioning process. In order for an AMT client to use a Pre Shared Key, however, the MEBx must first be programed with the correct key. This can be done in either one of two ways, manual entry or via a setup.bin file located on a USB thumb drive.

Manual entry is just that, a user must access the MEBx and manually type in the characters for the PID and PPS and any other settings that are required in order to get provisioning to work (system name, password change, etc). Once the user saves the changes to the MEBx, AMT starts sending out 'hello' packets to the provisioning server to start the provisioning process. This method is the most straight forward but is also the most time consuming, especially when attempting to deploy many systems at the same time.

USB thumb drive provisioning shortens the PSK entry process by using a formatted setup.bin file located on a USB thumb drive that can hold many PID/PPS pairs as well as password change information for MEBx. This key is then used on each system as it boots up to load the PSK information into MEBx. When the system boots, ME detects that a setup.bin file is located on the USB key and, if AMT isn't provisioned already, will prompt the user if they would like to load the provisioning information from the USB key. If the user confirms the request, then ME loads the first available PID/PPS entry into the PSK settings as well as changes the password for MEBx to the password set in the file. ME then marks that entry in the setup.bin file as used and reboots the system. Once rebooted, AMT starts sending out 'hello' packets using the PID/PPS pair. This method is better than manual entry, but only barely. This still requires a user to be at the system and to interact with the process.

PKI provisioning is split into two different types of provisioning as well, Bare Metal and Agent Based/Delayed provisioning.

Bare metal provisioning is where the factory settings in AMT are set at the OEM/System Integrator so that as soon as power and a network connection are applied to the system, then AMT will send out 'hello' packets and provisioning starts. If provisioning doesn't happen right away the provisioning period will continue for 24 hours, sending out 'hello' packets at a decreasing rate, after which AMT goes into delayed provisioning mode. This method of provisioning greatly improves the time savings from a deployment aspect by enabling many systems to be provisioned with minimal interaction from deployment personnel. This method works well when using a 3rd party trusted certificate that is natively supported in AMT (Verisign, GoDaddy, etc).

Agent based/delayed provisoining is where either the 24 hour provisioning period has expired without a successful provisioning transaction or, due to the AMT version, AMT requires an in-band agent or tool to start the PKI provisioning process. In order to start agent based/delayed provisioning the agent or tool sends a command down through the HECI driver in the host OS and tells AMT to start sending out 'hello' packets to the provisioning server. In addition, some basic configuration settings can also be sent to AMT in order to get it ready for provisioning (enable AMT, set PKI provisoining, etc). This method of provisioning tends to be the most reliable. Again this works best when using a 3rd party trusted certificate that is natively supported in AMT but in addition you gain the benefits of having an in-band agent that is able to assist the provisioning process by providing the provision server in-band information that helps keep the out of band aspects of AMT synced with the in-band host OS. Configured correctly, provisioning AMT with the assistance of an in-band agent can make the entire provisioning process hands free for deployment personnel.

Lastly, I want to touch on how each of these provisioning processes relates to the different AMT versions. Different versions of AMT support different types of provisioning. AMT 2.0, 2.1, 2.5 only support PSK provisioning. AMT 2.2 and 2.6 support PKI provisioning (as well as PSK) but only agent based PKI provisioning. AMT 3.0 and higher versions of AMT support bare metal PKI provisioning (as well as agent based/delayed PKI and PSK provisioning). A common utility used to accomplish agent based provisioning is the RCT (Remote Configuration Tool).

Provisioning is a very complex topic and what I've touched on here is really just the tip of the iceburg when it comes to understanding the intricacies involved. I hope I've provided more answers than questions, but if there is something you still don't understand, feel free to comment and I'll try to clear it up!

Thanks,
Matt Primrose

Two ISV's managing the same client? Sure!

mprimros — Mon, 10 Mar 2008 21:18:41 GMT

The Brand Promise Validation team here at Intel came across an issue in the lab which many customers may also run into when they are trying to deploy AMT. The question was, how do I use two different ISVs to manage different aspects of my Enterprise configured AMT client fleet? Theoretically this isn't neccessarily a tough question. Based on how AMT was designed, so long as you have the same authentication and credentials setup between the different managment software, you should be able to access the AMT features. In practice, however, many management applications attempt to configure AMT in such a way that they have sole access by customizing the provisioning settings and then hide those settings away.

However, as I'm about to describe, with a little tweaking, you can force these applications to play nice together.

The main thing to remember anytime you are setting up AMT in enterprise mode is that the key to accessing AMT is having the correct certificates in place. For access that means having a Web Server based certificate template that will be used for TLS communication between the console and AMT. If you are also using PKI provisioning, you'll have to have a properly configured or purchased provisioning certificate in place (I won't be covering the details of PKI provisioning in this blog, but maybe in a future update). Lastly, for SMS and Altiris you'll also need a .pem certificate. Details on how to create a .pem certificate is included in both the Altiris help and Intel AMT Add-on for SMS documentation. A quick summary of a .PEM file certificate is taking each certificate in the chain starting at the top and concatinating those certificates into a single file. This file is used for secure TLS communication during SOL sessions.

The two management applicaitons we targetted for implementation was Altiris and SMS using the Intel AMT Add-on for SMS. The reason we targetted these apps is that we have inimate knowledge using these applications since they are used in our validation efforts and they both utilize the Intel SCS for provisioning.

Both Altiris and SMS systems should be in the same domain using the same certificate authority and have the same root certificate installed. While it is definately feasible that you could have the the two management applications in different child domains using wildcard certificates for authentication, this article doesn't cover that specific configuration.

I'm not going to go into the details of setting up Altiris and SMS or how to configure SCS for provisioning since it is assumed that if you are attempting to merge these ISVs so that they can manage AMT clients, then you should already know how to get the individual applications to work with AMT.

I started off by getting Altiris setup and configured using the built in SCS included in the OOB Management solution for Altiris. At this point I didn't have to do anything special in order to make sure that the SMS Add-on would work, I just setup Altiris as normal to manage AMT clients. Once setup, I verified that I could provision and manage my AMT clients.

Next step, on a different machine, I setup and configured SMS with the Intel AMT Add-on for SMS. I configured SMS to use it's own SQL server, however, there is no reason that you couldn't have it use the Altiris SQL server (setting up a separate instance) or a stand alone SQL server (again with a separate instance). For ease of configuration, however, I just used a separate SQL install on the same machine as SMS.

Once you have the SMSAMTUser_<sitecode> account created in active directory and have that account as well as whatever user accounts you want to use AMT via SMS added to the Intel(R) AMT groups (there are 3-5 of them depending on the version of the AMT Add-on you are using), you need to add the SMSAMTUser_<sidecode> to the Altiris SCS users list. On the Altiris system go to: View -> Configuration -> Solution Settings -> Platform Administration -> Out of Band Managment -> Provisioning -> Configuration Service Setings -> Users. Click the blue + to add a new user. Click the ... button. Select domain and type in the name query field SMSAMTUser and click Find. Select the SMSAMTUser_<sitecode> that is found in the results field and click OK. Under Role make sure Enterprise Administrator is selected. Click OK. This gives the service account for the Intel(r) AMT Add-on for SMS rights to view and modify the Altiris SCS.

On the SMS system, open up the Intel Add-on Settings dialogue box and configure it to use the Altiris Setup and Configuration Server. In order to find the URL that Altiris uses to connect to the SCS, On the Altiris machine, go to:

View -> Configuration -> Solution Settings -> Platform Administration -> Out of Band Managment -> Provisioning -> Configuration Service Setings -> Service Location.

If you have the Default URL set, you should have something like [/]<fqdn/AMTSCS. If you are using an alternative URL, copy that down. On the SMS machine, open up the Intel Add-on Settings and go to the Setup and Configuration tab. Select the Integrated Setup and Configuration radio button and type in the URL you copied down into the SCS Service URL box. Click the Set Profiles box and the AMT profiles that are setup in Altiris should pop up in a new window. Select the profiles you want to use in SMS (select all of them if you want all profiles to be able to be managed in SMS) and click OK. The list of supported profiles should now be populated with the profiles that are setup in Altiris.

Next step is to setup the .PEM certificate file that was used in Altiris for the Intel AMT Add-on for SMS. Copy the .PEM file used in Altiris to the SMS system. If you don't know where you .PEM file is located in Altiris, go to:

View -> Configuration -> Solution Settings -> Real-Time Console Infrastructure -> Configuration.

Click on the Intel(r) AMT Connection Settings tab. Under Redirection Security you should see a box next to the Trusted CA certifcate location. That box should have the path to the .PEM file. Once you have copied that file to your SMS system (doesn't matter where you put the .PEM file on your SMS box, so long as you remember where you put it) open up the Intel Add-on Settings dialogue and click on the Security tab. Check the Enable Intel(r) AMT secure Connection (TLS) box. In the CA Certificate Path put in the path to the location of the .PEM file that was copied onto the SMS system. Click Apply.

That is the basicis of what needs to be done. Once you have discovered the AMT clients in SMS and they are populated in the collection, right click on All Systems and go to All Tasks -> Intel(r) AMT Tasks -> Discover Systems. Now when you right click on an AMT system and go to All Tasks -> Intel(r) AMT Tasks you should see the list of AMT functions you can perform such as Asset Identification Information, Power Control Operations, etc.

In order to get SOL/IDE-R to work and System Defense to work, you'll need to go into the Intel(r) Add-on Settings in SMS again and setup the location of the ISO images that will be used for IDE-R and the System Defense file that will be used to filter packets using Circuit Breaker. Creating the System Defense file is covered in the Intel(r) AMT Add-on for SMS documentation and will not be explained in detail here. The repository for the ISO images needs to be a network share and can either reside locally on the SMS system (still mapped to the network share location) or can reside in a central repository. If you want both Altiris and SMS to use the same set of images just use the same network path to the ISO images for both applications.

That's it. In my environment I'm able to manage AMT machines with either management application. The only slight gotcha (and this is more a security feature of AMT) is that if one management application is currently managing a client (ex. using SoL) then the other is unable to break in and use the client. The gotcha part of this is that neither management application gives a clear indication that the system is currently in use by another management application, the attempt to manage just fails with an authentication error.

Simplified Provisioning whitepaper posted

Terry Cutler — Wed, 16 Jan 2008 19:48:55 GMT

A number of requests through 2007 on the Intel vPro provisioning process.

The document posted (http://communities.intel.com/docs/DOC-1323) provides a summary of the process. Take a look.