How Purging works in a Hierarchy
search cancel

How Purging works in a Hierarchy

book

Article ID: 178563

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

The following information is provided as reference on the purging process used in a Hierarchy, depending on the version being used.

Environment

ITMS 8.x

Resolution

The following functionality to purge computer resources that are not local was added in ITMS 7.5 SP1:

  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) the Parent will purge computers which are in RemotePurgedComputer table, even if they are not local.
  4. After purging the Parent removes records (which are purged) from RemotePurgedComputer. The core setting KeepRemotePurgedComputerData was added. For more information see KB article Replicated computer resources are also purged on Parent server in case they are purged from Child server. In case this is true then the 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).


Question: If a computer has been retired in a Child Symantec Management Platform (SMP), what process the Parent SMP 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: Does Full Replication affect Purging like updating the "last inventory received" field causing it 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 of this.


Question: When setting up the Purging settings on the Parent, will those also be replicated? If so, what can be done to stop Replication on these?

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: You can change if these settings are replicated or not. On your Parent SMP Console go to 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 the '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. 


Question: If you are experiencing extreme differences in the machine counts on the Parent vs Child SMP because purging seems to not be retiring/deleting the resources on the Parent, wha should 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 forwarded.


Question: Does Acitve Directory (AD) Import affect how Purging is done on the Parent SMP?

Answer: AD Import rules should not affect purging.

Additional Information

Powered by Wolken Software