Relocation of Software Components – Bi-directional Hierarchy rules

Products

• IT Management Suite

Issue/Introduction

 This article contains information on Relocation of Software Components – Bi-directional Hierarchy rules

Environment

ITMS 8.x

Resolution

One of the central tenants of Hierarchy is that items and resources only replicate in one direction, either up or down. However, Software Components enter the Hierarchy in two places and need to be replicated throughout the Hierarchy. First, Software Components are created by scanning computers using the Inventory Solution Plugin Agent, which are sent up the hierarchy. Second, Software Components are imported at the root parent NS via the Definitive Software Library, e.g. Patch Management import, Asset Management, Software Management, then sent down the Hierarchy.

 There are three key issues with sending software components in multiple directions:

 

1. The owner, originator and source NS for the software component is constantly switched and is not accurate.

 

2. Once a child NS replicates a software component up the hierarchy it will become read-only at the destination. The root parent NS is responsible for defining software components and replicating them down to child NSs for distribution, so all software components must be editable.

 

3. When a child NSs replicates up software components these currently override the existing parent NS records for a particular component if resource key matching occurs. The parent NS does not want its existing software components overridden by incoming software components, as it is seen as the source of truth for the existing components it is hosting.

 

How are these three problems solved by resource relocation?

 

1.    When a Software Component is replicated up the hierarchy, the Owner, Source and Origin NS of the resource will be set to the Parent NS id on import.

 

2.    When a Software Component is replicated up the hierarchy it is entered into the parent db table ‘ItemImportMethod’ with a value of ‘0’ (local) for the ‘ImportMethod’ column. Normally a value of ‘3’ (Hierarchy Managed) would be entered for the resource. This ensures that the Software Components is recognised by the parent NS as being ‘local’ and will therefore be editable and not read-only.

 

3.    The Software Component will not be replicated/relocated under the following conditions:

 

a. GUID match - When a Software Component relocation rule is run at the child NS it first carries out a GUID comparison with the Software Components that already exist at the parent. If any GUIDs match, the child NS excludes these from being sent during replication.

b. Resource Key match - In addition to a GUID comparison the child NS also carries out resource key matching for the Software Component resources at the source and destination, and excludes any Software Components which have matching keys

c. Software Component is not local - Not local, meaning the item has a source NS GUID which does not match the local NS ID GUID inside the ‘ServerSettingsGuid’ table. In this case the associated data class data for ‘Version Known As’ and ‘Software Component’ should not be replicate either.

 

New Hierarchy Rule - Resource Summary Relocation

 

-        On Install of the NS a new pre-defined Hierarchy rule is laid down called ‘Software Resource Summary Relocation’ that has an added ‘Relocate up’ flag. This new rule specifically targets the Software Component resource type and two related data classes ‘Version Known As’ and ‘Software Component’. 

 

-       Only this rule will exercise the new relocation functionality. Other hierarchy rules which may be configured to replicate Software Components in an upward direction do not act in this way.

 

-       The data verification section of the rule definition has been removed specifically for this rule as it is not applicable to this type of replication.

 

Additional notes on Software Component relocation:

 

-       Software Component relocation rules are run as Complete replications, no hashing is carried out

 

-       In an upgrade scenario where the Notification Servers within a Hierarchy are mixed version, i.e. NS 7.0 Sp5 (Parent) and NS 7.1 (Child). If the Software Resource Summary relocation rule is kicked off at the child it will not replicate any Software Components and related data classes as it first checks that the destination NS is a supported version for the relocation feature

 

-       ‘Hierarchy Job Summary’ contains new columns inside its drilldown reports for indentifying that a hierarchy rule or job is of the relocation type. The two drilldown reports that contain this information are: ‘Replication Job Rules’ and ‘Hierarchy Job Rules’