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.