InTune Service Graph Connector overwriting computer fields in the CMDB

[Scott Baker4]

We recently activated the InTune Service Graph Connector as part of a SAM Pro project.   The connector had been tested in our Test environment prior to being activated in Prod.  Shortly after activating the Connector, we found that that thousands of our PCs had their data overwritten by SG-InTune.  Assigned to, Short Description, model and other fields were changed.   We were not advised by our implementation vendor that this would occur and thus did not look for it in Test.  We have had to turn off the InTune Service Graph Connector and recover the data until we can determine the necessary mapping rules to change so it doesn't happen again.

Why is this happening and what documentation is there which would have told us to expect this result?

[CMDB Whisperer]

I always recommend disabling the auto-assignment of assets based on login information.  While you should capture the information about last logged in or top logged in user, this should be used to complement the Assigned to field, never to overwrite it.  Assigning the responsibility of an asset to a user is a business transaction.  It is not "discoverable".  The reality is that many people don't actually track this consistently, so ServiceNow has added this to all of their endpoint discovery tools and Discovery itself to give a sense of who the asset might belong to, but at best this information should be populated only if the field is null, and ideally, it should be populated in a separate field, so that asset managers and owners can consult this information to ensure that the Assigned to values are correct.  Assigned to means "who is currently responsible for/custodian of this asset".  While that may be the last or most frequent user, that may not be the case.   In any case, you will need to customize the SGC/ETL application to stop this behavior.  And unfortunately, capturing changes to ETL applications is unreliable so you will need to be very careful when promoting the changes up to Test and Prod, and may very likely need to apply the changes independently in each environment, as your update sets may not be valid.

As for Short description, I agree that this is also a bit heavy handed.  They needed a place to put other data that didn't have a place to go or couldn't be consistently formatted, so they used Short Description.  Same is true for Discovery.  Many people will use Description to store contextual information about how a device is configured and/or used in operation, only to find that Discovery will overwrite this information.  I advise users to use the Comments field instead of the Short Description field for this purpose.  That said, it's important to keep in mind that both of these fields are likely to contain configuration information that is best stored in some other attribute, relationship, or related CI.

So I feel that frustration and while this won't fix your problem, I hope it helps explain it and to know that you are not alone here.  And of course, I should mention that it is up to you to meticulously review the results of any development, implementation, enhancement, or fix before you promote it to Production.  And that means review all of the data that is changed.  Relying on the thoroughness of documentation and the accurate reporting and logging of errors is never a good or complete strategy.