Reconciliation rules configuration

[SAIRSM]

HI all,
Currently I need to configure a reconciliation rule to update the serial number of a windows user as manual entry as while discovery it is taking baseboard serial number instead of system serial number, so here i have to update the system serial number manually and have to make it is not overridden when discovery runs.
For this, I created a manual entry rule with low priority and also high priority but nothing works.
Anyone, could you please what is the best way to overcome this situation.
Thanks,
Rama Satya Sai M

[pr8172510]

Hi @SAIRSM,

Discovery is still changing the value, check Data Source History (cmdb_datasource_last_update) for the affected CI and serial_number to confirm which source actually updated the attribute. ServiceNow uses Data Source History together with Data Refresh Rules during reconciliation.

Also verify the Windows Server CI Identification Rule. If the issue is that Discovery is identifying/updating the wrong CI because of the serial number, then the problem is with identification, not reconciliation.

 check Data Source History and the Windows Server Identification Rule before making any further reconciliation changes.

You may also find this similar Community case useful
 Discovery overwriting Linux Servers with same Serial Number, where the resolution involved the CI Identification Rule and the glide.identification_engine.enable_identifier_optional_condition property.
https://www.servicenow.com/community/developer-forum/discovery-overwriting-linux-servers-with-same-s...

[SAIRSM]

Hi @pr8172510 ,

I did one thing to get my required condition, I created one record in the table cmdb_datasource_last_update mention the data source is manual entry, attribute is serial number and as I mentioned previously, I created reconciliation rules and after I ran the discovery and serial number is not overridden.
Is this the appropriate way, please let me know.

Thank you,
Rama Satya Sai M

[pr8172510]

Hi @SAIRSM,

I would not rely on manually creating a record in cmdb_datasource_last_update as the solution.

cmdb_datasource_last_update is used to store the last data source that updated each CI attribute, and this information is used during reconciliation together with Data Refresh Rules. The table is populated after reconciliation is enabled and the relevant data source updates the CI.

I would therefore verify the Reconciliation Rule + Data Refresh Rule configuration and allow ServiceNow to maintain the Data Source History as part of the normal reconciliation process.

Since your Preview Rule already shows Manual Entry → ServiceNow → SG-Intune for serial_number, check the Data Source History after a normal manual update and Discovery run to confirm which source is updating the attribute.

So, although your manual cmdb_datasource_last_update record appears to make the scenario work, I would not recommend using that as the configuration. The supported approach is to control the attribute through Reconciliation Rules and Data Refresh Rules.

[SAIRSM]

Hi @pr8172510 ,

As you said, it's absolutely right but the issue in my instance is I am not able to find any records in the data source table based on the CI I want to modify, So I choose this option.

Could you please let me know that is there any reason why the last update history of that particular CI is not present in the table.

Thank you

[Vishnu-K]

Hi @pr8172510 ,

So quick heads up on how priority works in ServiceNow reconciliation rules - it's kind of backwards from what you'd think. Lower number = higher priority. Your Discovery rule is at 50, so you need your Manual Entry rule to be below that, like 10. Once you do that, you can go fix the serial number by hand and Discovery won't undo it on the next run, since Manual Entry now outranks it.

Also - when you set this up, just pick the Serial number attribute by itself, don't select a bunch of attributes together. Keeps things clean so you're only touching serial number and not accidentally messing with other fields.

So basically you'd end up with: Serial number - Manual Entry - Priority 10 - Applies to Windows Server.

And yeah, worth repeating since it's easy to mix up - lower number wins. That's the whole reason 10 beats Discovery's 50, and why your rule at 9999 never had a chance, it was always going to lose out.

One last thing - I'd treat this as more of a patch than an actual fix. If you can, it's better to go fix the Discovery pattern itself so it grabs the real system serial number instead of the baseboard one to begin with. Only go the reconciliation rule route if fixing the pattern isn't really doable on your end.

Hope this helps, if it helped you please do mark it as helpful and accept the solution.

Thanks,

Vishnu