Intel,Altiris Group

What does Resource Synchronization do in Out of Band Management Systems? 

Jun 08, 2007 01:12 PM

Resource Synchronization is a critical part of the full provisioning process for Intel vPro AMT, and Altiris/Symantec. This process not only runs a number of tasks, but primarily brings the vPro system into the Notification Server database or synchronizes the vPro system with an existing Notification Server Computer Resource record. This document was created to assist in understanding what is occurring within a synchronization, and also to point out the various data points required for a device to be properly synchronized, or to allow Provisioned Intel AMT systems into the Altiris CMDB.

Overview

On a high-level overview, the Resource Synchronization policy conducts these four items:

  1. Clean up Duplicates: Cleans up duplicate resources if the appropriate checkbox is checked in the Resource Synchronization policy User Interface
  2. Synchronizes Data: Synchronizes Resource data from the Intel SCS component (Database name IntelAMT) into the appropriate Notification Server inventory tables
  3. Create Assignments: Creates Profile assignments for AMT Devices that have not had assignments (and are thus unprovisioned)
  4. Clean Up: Cleans up exported 'USB keys' files older than 7 days

The synchronization policy is shown here:

Each step is detailed in the following sections.

Step 1. Clean up duplicates

One key table populated by the Synchronization is Inv_OOBSC_AMT_Devices. This table is used as part of cleaning up any duplicates in the Notification Server database. In conjunction with this table, the Basic Inventory table Inv_AeX_AC_Location (populated by several methods including synchronization, Basic Inventory sent from an Altiris managed computer, a system discovered via Network Discovery, etc) is used. The Altiris database may under certain circumstances have duplicate records for the same computer. This process is used to discover and remove those duplications so that the Altiris CMDB can be congruent.

If the table Inv_OOBSC_AMT_Device has the same value in the FQDN (Fully Qualified Domain Name) column as in the Inv_AeX_AC_Location table, and the _ResourceGuid in the Inv_OOBSC_AMT_Device table is not the same as in the Inv_AeX_AC_Location table, then the computer with the _ResourceGuid in Inv_OOBSC_AMT_Device will be deleted as it duplicated. The following diagram illustrates this:

The following is the Step by step process. Note that each step represents criteria, and if the criteria do not match, nothing further is done (meaning no duplication was detected):

  1. FQDN is captured from the Inv_OOBSC_AMT_Device table
  2. If a match is found for the same FQDN in the Inv_AeX_AC_Location table, continue…
  3. The _ResourceGuids are compared between the two tables. If they are different, continue…
  4. The computer from Inv_OOBSC_AMT_Device will be deleted.

A duplicate circumstance can occur if there was no computer resource in the Notification Server Altiris database at the time the Synchronization policy was originally run (for example the provisioned computer had no Altiris agent installed). In this case the synchronization policy sees that the computer is already known to the Intel SCS (IntelAMT database) but no such computer can be found in the Notification Server CMDB. In this case a new computer resource is created by the synchronization policy (this covered in step 2). If an admin installs the Altiris agent later on a system it is possible that the duplicated resource will be created due to nuances of how it is detected by the Notification Server when to create new resource versus using an existing one.

The following Query is used to detect duplicates within the Notification Server:

SELECT ad._ResourceGuid FROM Inv_OOBSC_AMT_Device ad " +
				"INNER JOIN Inv_AeX_AC_Location al ON " +
				"UPPER(al.[Fully Qualified Domain Name])=UPPER(ad.FQDN) " +
				"AND ad._ResourceGuid!=al._ResourceGuid

All duplicated resources found by the above criteria are subsequently deleted.

Step 2. Synchronize data

The Synchronization policy goes through each of the AMT devices known to Intel SCS (IntelAMT database) and updates the Notification Server Altiris database tables accordingly. The list of AMT devices known to Intel SCS are analyzed by the synch policy in batches – up to 1000 devices in each batch. This means the synch policy causes the Intel SCS interfaces call to fetch the first 1000 AMT devices, Analyzes each of the 1000 devices one by one, and then calls Intel SCS to receive next 1000 devices to continue the process.

For each AMT device in each batch, synchronization is performed. The synchronization conducts the following:

  1. It tries to find an appropriate Notification Server managed computer resource based on the information we capture for the given AMT device from Intel SCS > the IntelAMT database.
  2. From the Intel SCS we capture the FQDN for the AMT device. Based on the FQDN we resolve the IP from DNS, and then the MAC address from the IP using the SendARP windows API.
  3. Overall we then use the UUID, FQDN, HostName, IP, and MAC to find the correct managed computer resource in the Notification Server. The Synchronization calls sp_OOBSC_FindResource stored procedure in SQL to find the ResourceGuid of the matching existing device it discovered. The stored procedure exists in the Notification Server database.
    Note: Troubleshooting tip: if the Synchronization doesn't create a Notification Server managed computer resource (and thus does not populate the collections) – First try to find a system based on the UUID as the most efficient and valid method (this requires Out of Band discovery, Network Discovery, or a Get Intel AMT Inventory Task successfully performed). If this fails, then try to find the system based on the FQDN in the Altiris agent basic inventory table (Inv_AeX_AC_Location). If it is still not found then try to find it based on the MAC Address, and if still it isn't found then search based on host name, finishing if it still fails based on IP Address.
  4. If no resource is found, then a new Notification Server managed resource is created and the basic inventory tables are populated as much as we are able to (NSEs for Inv_AeX_AC_Identification, Inv_AeX_AC_Location and Inv_AeX_AC_TCPIP inventories are created and passed to the Notification Server data processing Queues).
  5. Finally an NSE for Inv_OOBSC_AMT_Device is created with the information from the Intel SCS IntelAMT database for the given Intel AMT box and the NSE is placed to the Notification Server queue folders for the Notification Server to process.

Step 3. Create Assignments

An essential part of the full Provisioning process is the profile assignment to a device that is in transition. It's that profile that secures and sets up the device for manageability. Without a profile no AMT box can be managed.

See the following screenshot:

The check box next to 'Intel® AMT 2.0+ to profile:' must be checked, and an appropriate profile assigned. This assures that a Profile will be automatically assigned either at the time of provisioning or during a Synchronization. Without this no manageability will be available for the machines still stuck in the Provisioning process.

The following process is used to create Profile assignments:

  1. The Synchronization first checks to see if the Policy has a default profile selected (Either for amt 1 or amt 2 or both) – if no selection is made, then no assignments can be created and this part of the synchronization is complete.
  2. If assignments are made, then Synchronization fetches a list of unprovisioned Intel AMT boxes from the Intel scs IntelAMT database. Once again this is accomplished in batches – 1000 unprovisioned amt boxes in each batch. For each unprovisioned device the subsequent steps are completed.
  3. Synchronization checks to see if the Intel SCS already has a mapping for this unprovisioned device in the IntelAMT database. If it does then there is nothing to do and this process finishes.
  4. If no mapping exists, we next fetch the FQDN from the IntelAMT database. The stored procedure sp_OOBSC_FindResource is next used to find a ResourceGuid. If no FQDN is found no assignment can be accomplished, and this process finishes.
  5. Next the Intel SCS interface call is made to assign the default profile selected in the synch policy UI to the FQDN found. The assignment is completed and synchronization moves to the next device.

Step 4. Cleanup exported USB key files

USB Key files are used for USB one-touch provisioning and are created via the User Interface for use on USB devices. When security keys are exported, the created file to be put to the USB device is stored in the NSCap\Bin\Win32\X86\OOB\Exported Keys folder. Every time a set of security keys are exported to a USB key file, a copy of the file is stored in a unique subfolder in the Exported Keys folder.

The synch policy analyzes subfolders in this folder location and deletes subfolders which have a creation date older than 7 days past.

Conclusion

Resource Synchronization is an essential part of enabling the ability to manage Intel vPro systems when they have been entered into the Intel SCS component. If this is failing, the systems we've provisioned will not appear in the managed collections required to use the Real-Time tab or any of the Out of Band Management Tasks.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.