- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-22-2024 01:02 PM
Dwayne! Did you ever hear back?!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2024 12:56 PM
Hey Chris, I still have a support ticket open with ServiceNow. It seems something with the software portion of the Intune integration is causing the disparity we're seeing. Support is going to reach out to the developers to see what they think. I'll let you know what I find out!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-11-2024 11:52 AM
Ahmet, the new version of the Service Graph Connector for Intune seems to have fixed the issue. See second bullet point on release notes below for v2.3.1
Once I upgraded and ran the import, the Most Recent Discovery matched the last synch time we see coming over in the Intune data.
Release Notes
Fixed
- SG - Intune Computer data source was not updating the discovery source in the Network Adapter [cmdb_ci_network_adapter] table
- SG-Intune Software data source was updating the most recent discovery of computers to the scheduled import time"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-07-2024 04:15 AM
Hi, We are facing the same issue. Can you please elaborate this in detail with example on what kind of custom field you are describing here? That will help us in resolving it by following the same workaround you have implemented.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-10-2024 08:14 AM - edited 05-10-2024 08:16 AM
I'm going to make a blog post on this, but it comes down to "Source Recenecy Timestamp" on the transform. Source recency timestamp will override whatever you have in "most recent discovery" and has two behaviors:
If source recency timestamp is empty, the record will get updated every sync and set the last_discovered ("most recent discovery") to the time the record was transformed.
If source recency timestamp is populated with a date time object, last_discovered ("most recent discovery") will be set to that time. But there's a caveat! (I'll explain with an example)
Let's say the device last checked in to Intune (u_lastsyncdatetime) 30 days ago. If you populate source recency timestamp with u_lastsyncdatetime, last_discovered will be the date that the device last checked in to Intune. BUT, the record won't ever get updated until the device checks in again with Intune and the date is more recent than the value in last_discovered. If you update your transform to pull in additional information, the record won't update with that new info if the source recency timestamp matches last_discovered on the record. So, if you need to change your transform and you want all that data to get pulled in, you'll need to either temporarily clear source recency timestamp on the transform or clear last_discovered on all the CIs.
The method we're currently going with is leaving source recency timestamp empty and mapping the last check-in to a new field. This gives us the benefit of knowing the most recent time ServiceNow saw the device during a sync as well as having the info on the most recent check-in to the config management system (Intune in this case).