Management Platform (Formerly known as Notification Server)
·Complete replication only occurs when replicating Configuration and Management Items and security Objects, not for other replication types, such as resources and events. Resources and events always use differential replication, even if you set the resource or event replication rule to run on the Complete Replication schedule.
·Inside Hierarchy Management page – Replication tab there is an ‘Advanced’ section which allows the user to enable or disable replication of all configured Hierarchy rules. If enabled all hierarchy rules created by both solutions and the Core Notification Server will be replicated down the hierarchy when either the Differential, or Complete replication schedule runs. Once the rules arrive at the destination NS they are read only and cannot be edited by the user.
·The ‘ItemReplication’ table stores the hash generated for each item during differential replication. If the hash is the same within the same table at the parent and child, then the item will not send during the replication run.
The hash is cleared when the modified date for the item, within the vItem table is greater than the modified date within the ‘ItemReplication’ table
·A way of checking that items are sent and then received at the destination would be to query the database table ‘Evt_NS_Object_Replication_Status’.
If replicating down the hierarchy, you would query the Evt_NS_Object_Replication_Status on the parent to see what was sent, and the same table on the child to see what was received. Do a comparison of the contents at the parent and child.
How to check the time that an item/object replicated
·Obtain the item GUID and do a query on the vItem table at the destination server using the item GUID. The Column ‘CreatedDate’ will be the time at which the item was first replicated. If a differential replication is run and the item has changed since it was last replicated, then the modified date column will change to the differential replication time.
Replication Blacklist (Added in SMP 7.1)
When upgrading your notification servers in a hierarchy, the servers will temporarily be mixed versions. This has been known to cause issues when specific items are replicated. A new database table has been introduced called ReplicationBlacklist. If a SMP 7.1 detects that an item it is attempting to import via replication is contained within this blacklist table, it will abort the import.
·Inside the Hierarchy Management page there is a ‘Custom’ option available for Configuration and Management items. Once you enable the option and Apply the page, the user can then right click on individual items or folders in the console tree views and choose ‘Hierarchy – Enable/disable Replication’ from the context menu. This will cause only the selected items to be replicated when the replication schedule is triggered. If a folder containing items is enabled for replication, then a popup will appear with the option to also enable all sub folders and sub items or to only enable the selected folder.
·When an item or folder is enabled for replication it stores the record of this in the table ‘HierarchyItemInstruction’.
When replication occurs it then knows to only send the items in that particular table. The contents of the HierarchyItemInstruction tableare replicated with the items. This means that the items sent are automatically enabled for replication at the destination server if this server has item replication set to ‘Custom’ inside the Hierarchy Management page.
At the moment there is no way to disable the item for replication at the destination server, as the item is set to read only. This is a known issue.
·If ‘Custom’ replication of Configuration and Management items is enabled by the user, and multiple items are enabled for replication, and the user later changes their Hierarchy Item replication selection to either ‘All’ or ‘None’ it will not clear out the contents of the HierarchyItemInstruction table.
If they wish to then return to the setting of ‘Custom’, the NS will revert back to the existing list of enabled items, saving the user from having to go back and manually re-enable the specific items.
·If a folder contains child folders or items, setting this parent folder as ‘Disabled’ for replication causes all child folders/items to also be disabled for replication. The user cannot set individual child folders or items to be enabled for replication, as the parent folder setting to disable replication overrides this.
·If the user has set Configuration and Management Item replication to ‘Custom’, when a Replicate Now…Operation is carried out on a particular item, it automatically enables this item for future replication. Such that when the differential or complete replication schedule next runs it will send any modifications to this item.