Video Screencast Help
Symantec Secure Login will be live on Connect starting February 25. Get the details here.

Part 4 - Using Out-of-Band Events and Alerts with Intel vPro Technology

Created: 28 Feb 2011
Language Translations
Terry Cutler's picture
+1 1 Vote
Login to vote


Since posting the previous 3 articles in this series, a few customer discussions and inquiries raised the following questions:

  • How could out-of-band alerts be used to help identify an unmanaged client or locate a system missing the Symantec Management Agent?  
  • If a system is built outside of the network, how could the administrator be notified the instant that system is placed on the production network?

Related questions and scenarios were raised in relation to Asset Management, System Deployment, and so forth.   A common point among the inquiries was that the Symantec Management Agent was not present on the target client.   This could be due to a new system being deployed, a system that was reimaged or repurposed, or other reasons.

In an effort to consolidate the ideas into one example, I put together following overview (click to enlarge).

The base scenario shown is a situation where a 3rd party images and prepares the client systems outside of the production network.   During the system preparation process, the 3rd party configures Intel AMT and sets the base out-of-band alert subscriptions.   The main subscription used in this example is "Link Up", with a target SNMP alert receiver IP address of the production Altiris Notification Server.

When the client is connected to the production network, everytime the network interface is able to communicate this will trigger a "Link Up" alert.   In general, the Link Up event occurs 4-7 times when a system is connected, powered on, and the operating system boot completes.   The SNMP alert will contain the sending IP address, alert message, type of alert, UUID of the system, and other data points.   These data points can be valuable references in helping to find the proverbial needle-in-the-haystack.

As a side note - when I did these tests, the systems had been configured by a beta instance of Altiris 7.1.  The Alert Subscriptions were set to point to a new server.   I recently installed an RTM version of 7.1 as a new server, and had added only two clients to that environment.   The tests completed were with clients NOT configured or known by the new server.

Finding an unknown yet previously configured Intel AMT device

Building upon the scenario above and from the previous articles, a rule filter needs to be defined to look for Link-up events from IP subnets within the environment.   If the systems are unknown (i.e. not discovered or listed in the target Symantec Management Console), they will appear with the IP address as the hostname.

Shown below is a simple Alert Filter that will look for the following:

  • Hostname contains 192.168.0   (this is the only IP subnet within my test environment)
  • Alert message is "Link Up"
  • Alert occurs more than 5 times within a 1 minute timeframe 

If the above condition are met, the response is an email notification to the administrator.   The email notification will inject the IP address, date\time of the occurrence, and other items as shown in the email template below.

I tried other tasks such as Discovery, Out-of-band Inventory, and so forth.   For some reason, these tasks failed to respond.   However, with the email notification, the IP address could be used to manually (or automated via workflow) initiate a discovery, out-of-band inventory, etc.

Here is an example of an email received.   Note that both the "System" and "IP" fields are the the IP address of the client.

Using the alert data to discover the client

With the IP address known, a discovery of the target client can commence.  Again - here is a perfect example were a light workflow process would help.

Using the "First Discovery" which is a clone of the pre-installed "Right Click Discovery Device" task, select a connection profile with Intel AMT credentials and other protocols for the environment.   In the example below, the Default Connection Profile is used.   (click to enlarge image)

When the discovery completes, an unmanaged computer object is created.   The object will be named based on the discovered value of the operating system hostname or the AMT network information.   In the example below, the once unknown system is listed as "Dell755".  This is the hostname.

To see the collected information, open the Resource Manager of the unmanaged computer.   Click View > Inventory.   Within the Data Classes of the computer object, expand Network Device Data, and click on Device AMT network info.

As shown in the example below, the Intel AMT settings were captured.   This may be helpful in determining the original name of the system.   A common scenario to consider: The client was imaged\prepared for deployment, before registering on the production network the system was reimaged and renamed.   If that were to happen - the original name as set in the Intel AMT firmware can be determined.

(click on image to enlarge)

If additional steps were taken to install the Symantec Management Agent and transition the computer to a managed object - the existing resource\GUID would updated accordingly.   Once again - a workflow automation opportunity.

Previously Managed Asset

Building upon the previous example, what if the target computer was managed at one time.   Due to various circumstances, the Symantec Management Agent was removed from the client.   In this situation, the NS Resource Object still exists within Symantec CMDB.   However, the client has not checked-in for an extended period of time via the agent.

If the Intel AMT configuration and alert subscriptions are still present on the client, it will send SNMP alerts to the target Altiris Notification Server.   The alert rule for this situation can be simplified to look specifically for the target hostname.   Look specifically for the last known name - as defined by the existing computer object.

Since the out-of-band alert message contains the UUID of the platform, this will be mapped to the existing objects.   Although the operating system hostname may have changed, the UUID will not unless the physical motherboard has been replaced. (If that happens, refer to the previous example).

A new alert filter is shown below is looking for 3 specific systems where an NS Resource object already exists.  

Using a similar email notification response, the moment a target client is connected to the production network the administrator will know.  The following email sample identifies the hostname and IP address of the sending client - valuable data points which could used in locating the asset and helping to bring it back to a managed state (once again - great opportunity for some workflow automation)

(click on enlarge)

Concluding Thoughts

Identifying new assets or trying to relocate existing ones within the production network can be augmented via out-of-band alerts.   The examples shared here provide a few insights on how this is possible.   The scenarios were based on real-world customer requests.   If the information was helpful or if you have additional ideas - please comment wink

Return to Part 3

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.