SCCM updates "assigned" and "assigned to" fields.

[Flybook]

Hello experts,

It is our understanding that OOB interface from SCCM is changing the assigned and assigned to fields to most likely user. These two fields are used for end user compute devices and are set by the our staff. We do not want SCCM changing these fields for any device. If there is a possible solution to stay OOB, we would like to adopt that and stop SCCM updating these two fields. If not, Is this a mapping/interface that we can customize so that these fields do not get updated by SCCM?

We would like to know if Reconciliation Definitions can be used to limit a Discovery Source from updating these particular fields. Please let me know if this is a viable solution. It might be an easier fix to implement than the ACLs.

Thank you!

[Flybook]

Hi Iholl, 

Based on what I see and have read about this system property, it is ONLY for Discovery because Discovery does not use the CMDB IRE.  SG SCCM DOES use CMDB IRE. 

Please correct me if I am wrong here. 

Thank you!

[lholl]

Depending on which version of the SCCM plugin you're using (since you haven't mentioned it yet), both use IRE but I do not see the Service Graph connector respecting this property in the IRE script on second glance.

A way to "break" assigned_to being populated in an out-of-box sort of way is to set this property "glide.discovery.assigned_user_match_field" to a field that does exist so that when SCCM/Discovery looks for the assigned_to user, the query returns nothing and your data will never change. Obviously this will leave blank assigned_to fields null if you guys do not populate it yourselves.

A more natural/OOB route: Basically how Reconciliation works is that the "cmdb_datasource_last_update" table keeps track of all the modifications that Discovery Sources make in order to figure out your prioritization rules and if one Discovery Source can overwrite another. You didn't mention how your team is entering in data, but if it's through an IRE-enabled transform map you would just create a new Discovery source, set that in your Transform script when you call the IRE API, and then create a Reconcilation rule to prioritize that over SCCM for the assigned_to field. If your team is just going through every CI and updating it manually, you'd have to write a before business rule to package their changes into a payload then call it through the IRE API like I did for my printers: 

  var payload = {

        "items": [{

            "className": "cmdb_ci_printer",

            "lookup": [{

                "className": "cmdb_ci_network_adapter",

                "values": {

                    "mac_address": mac

                }

            }],

            "values": {

                "model_id": model.getUniqueValue(),

                "serial_number": serial

            }

        }],

        "relations": []

    }

    var jsonUtil = new JSON();

    var input = jsonUtil.encode(payload);

    var output = SNC.IdentificationEngineScriptableApi.createOrUpdateCI('ImportSet', input);

If everyone has already entered their data, this option wouldn't work obviously because you wouldn't be able to retroactively call this script to create the cmdb_datasource_last_update record in which case I'd probably recommend the above examples.

Also, with how awkward and round-about all these options are it's honestly probably just easiest to modify the single assinged_to field on the SCCM plugin and accept you'll have an update conflict. Since you're disabling the feature it doesn't matter if servicenow updates the code on the script anyways.

[Nitin Panchal]

If anyone is still looking for the same on how to disable graph connector field update , here is KB article published by ServiceNow
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0958725