Exclude IP Address from Discovery in Reconciliation Rules

Henrik Jutterst · ‎02-08-2024

Background

We're setting up Discovery for a customer and looking through the Reconciliation Rules for Servers and the extending classes. For the moment before we can start running Discovery on a broad range of IPs we need to keep some fields before we move over 100% to Discovery.

I've set up Reconciliation Rules for IP Address field to only be updated by my custom source at the moment. Or at least that it should have the highest priority.

Issue

When are running Discovery now on an example host, we see that IP Address is overwritten by ServiceNow Discovery even though it should not do so.

At least to my mind, the Reconciliation Rules looks correct. but since it's not doing what I'm looking for, I think I need some guidance is this issue. If there's a new server found and the IP Address is blank, it's Ok for ServiceNow Discovery to write to the record, but if there's already a value by my desired source, Discovery should not modify it.

Please see screen shots:

For the Second (middle) rule:

But even though this I can see that record is being updated by Discovery.

Record History:

I don't want Discovery to update this field

Edit:

I've done some modifications to the first rule now so Order is 90,91,92 instead of 90,90,90.

In the Middle/second rule, I've added to update all fields except IP Address now. But still ServiceNow Discovery keeps updating IP Address on Discovery of CI.

Henrik Jutterst · ‎02-09-2024

Ok so it turns out that IP Address is a bit different then standard fields on CMDB Server and the extending classes. There was no real issue with the Reconciliation Rules for that matter, but that IP Address have some OOB differences.

So a colleague of mine fond that there is a Discovery Property called "glide.discovery.exclude_ip_sync_classes" for this matter. So by adding cmdb_ci_server to the comma separated list in the property, IP Address field is not overwritten by Discovery.

ServiceNow Docs - Discovery properties

Defines CI classes whose IP addresses should not be substituted if the address returned by Discovery does not match one of the devices' NICs. Use a comma separated list to define multiple classes. By default, the system uses the management IP of a load balancer returned by Discovery in the CI record, rather than substituting it for the IP address of one of the load balancer's NICs.

Type: string
Default value: cmdb_ci_lb

So adding the value like this, solved the issue for the field to not being overwritten.

View solution in original post

Sandeep _ · ‎02-08-2024

I hope this article helps you: it's related to how exclude IP address
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0748222

Henrik Jutterst · ‎02-08-2024

Hi @Sandeep _
No. I don't want to exclude IP Addresses from being scanned.

I'm writing and asking about the field on a server record.

James Chun · ‎02-08-2024

Hi @Henrik Jutterst ,

So the requirement is there are multiple data sources are updating the CMDB, but you don't want Discovery to update the IP address field of a Window Server CI if it's already populated by a different source.

Can you please share the 3rd Reconciliation rule as well?

Also, can you try deactivating all rules except the first one and see if Discovery still updates the IP address?

Thanks!

Henrik Jutterst · ‎02-08-2024

Hi @James Chun and thank you for trying to help here!

Yes, you understood correct what I was looking for. I have multiple data sources but for now, I want the Vm-sources to have priority to the IP Address field. (will change this later so that ServiceNow also own this data, but that is for the future and not relevant now)

Here is the updated and third rule on the right. Right now it contains all fields except IP Address (just like the second/middle one. Only differance is the filter for the "CI Company" to be "is"/"is not" <company name>.

I will try removing/deactivating ServiceNow as a contributor to the CI. But if you see anything strange, please let me know and I can try to correct that.

Kind regards

/Henrik