How Purging works in a Hierarchy?

Products

• IT Management Suite

Issue/Introduction

The following information is provided as reference on this purging process depending on the version used.

Environment

ITMS 7.x, 8.x

Resolution

For ITMS 7.5 SP1 and later:

The following functionality to purge not local computer resources was added.
Hierarchy purging process is as follows:
1) During purging Child will send hierarchy event to the Parent
2) Parent will save purged computers into RemotePurgedComputer table
3) During purging(if it was enabled) Parent will purge computers which are in RemotePurgedComputer table, even if they are not local.
4) After purging Parent removes records(which are purged) from RemotePurgedComputer. Added core setting KeepRemotePurgedComputerData (See 178374 "Replicated computer resources are also purged on Parent server in case they are purged from Child server"). In case if it true then RemotePurgedComputer table will not be cleared.

Note: RemotePurgedComputer contains GUID, PurgedType (0 indicates that the computer was deleted), ServerGuid (Server which purged computer, it should be computer OwnerNS).

 

For ITMS 7.1 SP2 MP1:

Question: If a computer has been retired in a Child SMP, what process the Parent SMP will take to purge it?
Answer:
The Parent purging process is unchanged in a hierarchy. Purging depends on the ModifiedDate in ResourceUpdateSummary for the Inv_AeX_AC_Client_Agent data class.
Once this date is outside the purging maintenance window, it will be Retired or Deleted, as configured.

Question: Full Replication affects Purging? like updating "last inventory received" field causing to delay the purging process?
Answer:
Full replication will cause the Inv_AeX_AC_Client_Agent data class to be replicated to the Parent, each time the full schedule runs.
This then updates the ModifiedDate to be the date/time of the import of a given resource's data at the parent.
Apply the logic from answer 1 above to understand the implications.

Question: Setting up the Purging settings on the Parent, will those also replicated? If so, what can be done to stop Replication on it?
Answer:
Purging maintenance policies from the Parent are replicated to the child. You could prevent this with the following update SQL:
update Item
set Attributes = Attributes | 4
where Guid = 'DE4A3A7C-2147-463E-8A06-A23B6C6E719B'

Note: Starting with SMP 7.5 SP1 now you can change if these settings are replicated or not. On your Parent SMP go to SMP Console>Settings>Notification Server Settings>Purging Maintenance. Right-click on it and select 'Hierarchy>Properties'. You will see under 'Hierarchy Properties' window 'Purge Data' and 'Purge Computers' checkboxes. Selecting 'Purge Data' will allow you to edit and keep the changes on the Child SMP for the 'Purge Legacy Saved Reports' and  'Purge Outdated Agent Registration Entries' sections under the 'Purging Maintenance' tab. Selecting 'Purge Computers' checkbox allows you to edit and keep the changes on the Child SMP under 'Purge computers managed by this NS, which have not reported data for: ' section.
See also 155630 "Purging Maintenance on child NS - Parent Setting overwriting Child settings"

Question: If the customer is experiencing extreme differences in the machine counts on the parent vs child SMP because purging seems to be not retiring/deleting on the Parent, what could be checked?
Answer:
Check the ForwardDate in the ForwardingHistorySummary table on the child, and the ModifiedDate for the Inv_AeX_AC_Client_Agent data class in ResourceUpdateSummary for a machine in question at the parent.
Machines that are expected to be purged should not be forwarding.

Question: Does AD imports affect how Purging is done on the Parent SMP?
Answer:
Active Directory imports should not affect purging.

Additional Information

KB 228171  "How does purging maintenance work in Symantec Management Platform?"