How to prevent asset records being created from virtual machine CIs?

[Valqe]

Hi all.

It appears that baseline ServiceNow configuration will create asset records [alm_asset] when new CI is created even if this CI applies to virtual machine. I'd like to better understand what are best practices to avid asset record insertion for CIs whose "Is Virtual" field value is 'true'

My two comments are:

-- I would hate to make changes in baseline business rule "Create Asset on insert"

-- In 'Hardware Category' records there is a way to set 'Asset Tracking Strategy' to 'Don't create assets' but you never know what new model category will be created in the future to prevent new hardware categories from creating new assets for virtual machines.

I would appreciate your thoughts on best practices you followed for way around to this configuration.

Thank you.

Val

[Rahul Priyadars]

May be Some Data Driven Mechanism but seem we can achieve without much changes.

Have a look at the Model assigned to the VMs that are discovered. It should be a Virtual Machine Model some kind of. In the Model record, you can set the Asset tracking strategy to Don't create assets. That will override the Model Category creation of the assets for the virtual CIs you discover.

This is driven from Model data even though you may have some Physical Windows CI which needs an asset - So changes are only limited to Model Data.

Hope This helps.

Regards

RP

[Valon1]

Thank you for your reply Rahul,

Modifying 'Model' to prevent asset record from being created for virtual machines seemed the safest way to do it without modifying the baseline config.

However, the concern I had was: what will happen when new model(s) gets introduced?

From screenshot below I wonder: How do we know when infrastructure team introduces new (i.e.VMware model 7.2) which is not configured to "Don't create assets"? It will end up creating new assets for future models that are not set to not create assets.

So far solution I'm thinking to implement is to modify Create Asset on insert" business rule and introduce IF condition that would check class and Is Virtual field before creating an asset

IF (current.sys_class_name == 'cmdb_ci_server' && current.virtual==true)

But this change will require me to change baseline BR and I hate to do that.

[Rahul Priyadars]

As per OLD ITIL School Software which are Part of DSL (Definitive Software Library) are only rolled out in environment. Its the JOB of Asset Management /Config Management process to Control this.

I gave you above configuration as it do not require to play with a single code. 🙂

But seems Code is the 1 Touch solution

Regards

RP

[bjmcdonald]

So, it's better to use the model "don't create assets" on a generic Virtual model than using "enforce CI verification" on the model category?  Just want to make sure that is the best practice.

How / When should you use "enforce CI verification"?  

[Valqe]

You usually want to utilize "enforce CI verification" in cases when your company is allowing employees to bring their own devices. If that's the case then when ServiceNow 'Discovery' creates CIs for given devices you want to prevent assets to be created for same - therefore "enforce CI verification"

I did a lot of research on this topic (prevent asset creation for virtual CIs) and at the end I decided the following:

-- I will NOT modify baseline "Create Asset on insert" business rule, since it has long term implications on future instance upgrades.

-- Even if I were to modify  Create Asset on insert" BR, it will not work, because there is "Asset - Create asset delayed sync" scheduled job that will still create an asset from CI. And if I were to modify that too it would be to much to modify in the baseline.

So my solution was:

-- Run discovery in your DEV (or subdev) environment. Check what kind of virtual assets are being created and note their "Hardware Model" records. In my case there were two records:

1.  "VMware Virtual Platform" and

2. "VMware7,1"

-- Modify those Hardware Model records "Asset tracking strategy" to "Don't create assets"

-- Export those Hardware Records in .XML format and import them on higher instances

-- Run Discovery on higher instances and assets for hardware models that you've imported (and previously modified not to create assets) will not be created.

Unfortunately this approach will not work if you already ran discovery in higher instances because asset records have already been created.

I hope this helps