Creating Policies under the CMDB Data Mananger

[Anthony78]

We have AWS, Azure, VCenter and On-Prem  CIs in ServiceNow. I would like to set up a policy to retire, Archive and delete. Which tables would be best practice to setup these polices . I would like to understand the pros and cons for better understanding.

[Marshall Parker]

You will need to identify which CI Class (or multiple classes) you are storing your CIs in from each discovery source.

CDMB Data Manager Policies can be setup on a common parent class, but rules should be within the same concept area for management. When you have a different criteria to consider [Class, Source, etc..] you can add a new Policy entry specific to that criteria.

Example: If you have On-Prem CIs in both Windows Server & Linux Server, and the criteria for Retire & Archive is the same - you could setup a policy on the parent Server class with the right criteria. But if you have different criteria to consider between those 2 classes, you may want to setup 2 policies directly on each class.

[Anthony78]

Hi @Marshall Parker ,

So Im thinking to create a policy in  "cmdb_ci_hardware" & cmdb_ci_appl tables so that these tables will be parent for all hardware and software levels .  - Is it okay to create on this table level

But the virtual instances are not coming under this class , how do i retire those ?

1.Do i need to create a policy in hardware level and as well in virtual instance level ?

2.do i need to retire servers first or virtual instances first ?

3.Is there a option to retire the ci if either one ci retired 

[Marshall Parker · Accepted solution]

Policies set on a larger scale like Hardware [cmdb_ci_hardware] or Application [cmdb_ci_appl] can be ok, especially to introduce the process of CMDB Data Manager; however you want to keep an eye on these as the CMDB scope grows as you may want more nuanced policies over time.

Each policy can have a certain complexity to the filter but over time you may decide you need policies at a smaller scope closer to each CI level. It will become a trade-off between # of Policies and # of Classes.

For the Virtual Instance, depending on how you are bringing those in, your discovery or integration method may be providing status updates to show that a specific VM is Off or Retired and you may be able to leverage that update to build a relevant Archive policy.

To auto-update multiple layers of a CI, you could research Dependent CI management which can cascade-retire or cascade-delete based on the CMDB Data Manager policies. These auto-updates can be processed automatically or be set to generate tasks for a human approval/intervention. (SN Docs: Dependent CIs management (servicenow.com))