NOTE: An update to this article with improved tool and method will be posted soon (April 2011).
Of all the Intel® AMT systems found in your environment, how do you know which ones are configured? What about the exact Intel® AMT version, especially if the Altiris environment does not own the configuration? What if you simply want to know system make, model, driver version, and other data associated to Intel® AMT systems in your environment?
This data is not discoverable via traditional inventory methods. Sounds like a job for a custom inventory solution.
Several months ago I posted an article on how to accomplish this with Altiris Inventory version 6. See Scanning an Environment for Intel AMT Capable Systems
With the advent of Altiris Inventory version 7 – which is included in the Symantec Client Management Suite version 7 – it is time to update that information.
A few background reference points. For an overview how custom inventory with Inventory Solution version 7 works, see Introduction to Custom Inventory in Notification Server 7.0. For this custom inventory, Intel® AMT specific data will need to be captured. Take a look at the AMTSCAN tool available at http://communities.intel.com/docs/DOC-2061.
There are other tools which obtain Intel AMT information. The AMTSCAN tool does a good job, including placing the information to a known Windows registry location. However - should you want to sample other tools and ideas, take a look at What Remote Configuration root certificate hashes are on my system?. Plus - there's a tool due out late 2010 or early 2011 which will do a much better local discovery of Intel AMT.
For now - we'll work with AMTSCAN.
Overview - Getting Individual Client Registry to Symantec CMDB
The sequence is relatively simple:
- Use AMTSCAN to capture Intel AMT information into the Windows Registry
- Use Inventory Solution 7 to capture the custom registry entries into the Symantec CMDB
If you run AMTSCAN on a client, data similar to below will be stored in the registry
Once the custom inventory runs, this data be accessible via Symantec CMDB as associated to that client. The following screenshot shows the Real-Time System Manager Inventory with the AMTSCAN custom data.
Other uses of this information could include custom filters. For example - Wouldn't it be nice to know exactly what Intel AMT 6.x systems are provisioned thus targeting who can respond to a KVM remote control request?
Defining the AMTSCAN custom inventory
Following the Inventory Solution 7 article mentioned above, here are the steps I took.
First - define the AMTSCAN Custom Data Class. This is found under Settings > Discovery and Inventory > Manage Custom Data Classes
Second - define the individual "attributes" or data fields to be captured. In my example below, only a subset of the AMTSCAN data was desired. I used the default size and key settings. In production environments, you can reduce the number as needed. As I understand it - this designates the size of the data field in database. Thus if you know a certain data field will not require 50 characters - such as the AMTversion - reduce to 10 characters or a value you feel will suffice.
BTW: As a side comment - I noticed that it work best to save after each change to the custom data class.
With the custom data class defined, a vbscript can be run on the clients to capture and submit the data. Attached is a text file with the vbscript I modified from the Inventory Solution 7 article mentioned above. Make sure you define the correct GUID or custom data class in the vbscript.
At the end of the vbscript, I included two wscript.echo statements that are commented out. These were used during manual tests within the environment.
Validate the Custom Inventory Script
Make sure you have the Inventory agent installed and updated on the clients. The screenshot below shows enabling the agent plug-in
On my client system, the following Inventory sub-agents were installed:
- Inventory Agent: 7.0.1255
- Inventory Rule Agent: 7.0.7416
In my own tests, I noticed a flaw with Windows 7 64-bit systems during manual tests. To run the vbscript for collecting the data, it would generate an error indicating "Could not create object named "Altiris.AexNSevent". However, if I ran from the 32-bit cmd prompt (found at c:\windows\SysWOW64) it worked perfectly.
The steps can sequenced via TaskServer as shown below
Concluding Thoughts
Once the AMTSCAN custom data resides in Symantec CMDB and associated to the respective client, a series of possibilities unfolds: custom filters, custom reports, targeting events based on custom data, and so forth.
I'm interested to hear how others make use of this information, and look forward to share more insights when more discovery tools become available late 2010 or early 2011
The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries