How Resource Merging works within an Hierarchy?

Products

• IT Management Suite

Issue/Introduction

 

Resolution

 

Resource Keys

Below is a list of some resource types and what key the NS uses to identify that a duplicate exists.

 

Computer – Name.domain, UniqueID, FQDN, Distinguished Nme

User – Name.domain, Distinguished name

Site – Name

Subnet – Name (Subnet name will always be in the format of CIDR - classless interdomain routing notation, e.g. 172.16.65.0/18)

 

Resource Merge Enforcement Keys -

Having a Resource key defined inside the ResourceKey db table does not cause automatic merging of resources when a duplicate is found. A resource will only merge is there is a record for the resource type inside the ResourceTypeMergeKey table. All resource types and associated keys within this table are treated as enforcement keys, which the NS will automatically merge on.

The stored procedure used for merging resources is SP_ResourceMerge

 

 

Resource merging

The ways in which Hierarchy replication deals with consolidating duplicate computer resource data are listed below, along with how it decides which resource data should take precedence.

An important factor when replicating computer resources is that they maintain the correct information about which NS they report to. This information is stored in the ‘OwnerNSGuid’ column of the ‘vItem’ table for each computer resource. The Owner NS GUID corresponds with a matching NS name within the ‘ForwardServer’ table

 

Duplicate resources are merged when the values for their enforcement keys match (see above for explanation on Resource Merge Enforcement Keys).

The simple rule for merging data in regards to hierarchy and replication is, that the source server always wins, it will always override the resource data at the destination server, if data already exists for that resource.

 

Example 1 – Merging of Resource GUIDs

 

If the source server has a resource in the DB marked as GUIDB and the destination server has the same resource in its DB as GUIDA,when the source server replicates the resource, the GUID on the destination server is switched from GUIDA to GUIDB.

 

Example 2 – merging of data classes

 

NS A is the parent and models data class DC1, DC2 and DC3 for a given resource type.

NS B is the child and models data class DC1 and DC4 for the same resource type

If the replication direction is up, then the source of truth at the top of the Hierarchy (NS A) is:

DC1 - NS B (Overridden)
DC2 - NS A (Preserved)
DC3 - NS A (Preserved)
DC4 - NS B (Dataclass itself is sent and created at destination, replicated data inserted)

 

If the replication direction is down, then the source of truth at the bottom of the Hierarchy (NS B) is:

DC1 - NS A (Overridden)
DC 2 - NS A (Dataclass itself is sent and created at destination, replicated data inserted)
DC 3 - NS A (Dataclass itself is sent and created at destination, replicated data inserted)
DC 4 - NS B (Preserved)

 

Global Merging and resynchronisation events

Resources are brought into the database from many different sources, e.g. AD import, Network Discovery, Asset Solution, Software Management Solution etc. 

This can cause the same resources to exist at multiple nodes in a hierarchy structure with different GUIDs.

Global merging is the process of synchronizing the GUIDs of like resources across the entire hierarchy structure, preventing the existence of duplicates at each hierarchy node. This global synchronisation goes a step further, and also includes switching the local GUID of the Altiris Agent, so that a complete resynchronization can occur.

 

Below is an example scenario of a global merge being carried out on a subnet resource:

 

Parent NS with two child NS nodes -

Parent has subnet1 with GUIDC

Child node1 has subnet1 with GUIDA

Child node2 has subnet1 with GUIDB

 

- Child node1 replicates subnet1 up the hierarchy first

- At the parent, subnet1 GUID is flipped to GUIDA

- At this time an event in the form of a hierarchy alert is sent from the parent to each child node, that gives the following command, ‘If you have Subnet1 (based on ResourceTypeMergekey matching) then flip your GUID for Subnet1 to be GUIDA now’

- The event is called a ‘Hierarchy Global Resynchronisation Event’. The events are only sent in the direction the resource came from.

- In this scenario, if Child node2 replicated subnet1 up the hierarchy before it received the resynchronisation event from the parent node, then this would cause the GUID on the parent for subnet1 to be flipped to GUIDB, and a sync event would then be sent down to all child nodes instructing them to flip subnet1 GUID to GUIDB.

 

-      It will attempt to match a computer resource on any of the below resource keys, It will merge on the first resource key that matches, it does not merge on multiple keys.

• Name.Domain
• FQDN
• MAC Address (entered as a merge key by Inventory solution)
• UUID (Unique Computer ID) sent up by Altiris Agent basic inventory

The UUID is formulated by taking each physical network card of the machine and generating a MD5Base64 hash, which is a combination of (Computer UUID + Motherboard Serial Number + MAC Address)

 

Switching the local Altiris Agent GUID - Otherwise known as ‘Altiris Agent Blacklisting’

 

-      When a computer GUID is merged, the old computer GUID is blacklisted. The next time the Altiris Agent requests configuration, the NS responds by returning an error code. This error code instructs the Altiris Agent to visit CreateResource.aspx to obtain the new GUID.

 

-      When merging of a computer resource is carried out at a parent node, a resync event is created and sent down to immediate child nodes. This event lists the ResourceKey which the resource was merged on. When the event is processed at the child node it searches for matching resources based only on the merging ResourceKey specified inside the event.

For example: A computer resource is replicated up the hierarchy, and a matching MAC address is found, but not a matching name.domain.

The resource is merged and a resync event is generated which includes the ResourceKey ‘MAC Address’ and when the event arrives at the child node it will only attempt to merge based on resources that have a matching MAC address. It does not search for matching name.domain.

 

-      Contained in the resync event is the name of the NS machine where the resource originated from, so if the NS processing the event is this NS, then it is instructed to do nothing.

 

-      Blacklisted Agents will be added to the filter ‘Blacklisted host computers’. This filter has an Item GUID of ‘40ae9358-6b46-42e4-9928-693f8f76f1cf’. To check whether a computer GUID has been added to the collection you need to query the CollectionMembership table for the above collection GUID and the blacklisted resource GUID.

 

  select resourceguid     
    from collectionmembership     
   where collectionguid = '40ae9358-6b46-42e4-9928-693f8f76f1cf'

-      The Blacklisted Agent GUID is also added to the new database table called ‘AgentBlacklist’