Removed software still appears to require reconciliation.

Jen Wenrick1 · ‎06-27-2022

We are using ServiceNow Discovery and SAM Pro. I have some software that was de-installed from LINUX OS systems about 1 month ago. Since then discovery has run multiple times, reconciliation has run multiple times and this software package continues to show up on these systems in the license workbench. How does this work with Discovery and ServiceNow with regard to software that is de-installed, what should I expect to see? Looking for more details on how this is supposed to work so that I can further troubleshoot please. I also have the same questions about SCCM & JAMF integrations, but the immediate need/concern the LINUX server situation mentioned above. THANKS!!

Jeanna1 · ‎07-14-2022

Is there a KB on this? How can other customers get this fix?

Gary Ables · ‎06-29-2022

Thanks for trying to help me, but this method not working to me GoMedicare Benefits

Joe Ryder · ‎06-29-2022

Hi Jen! It looks like Srinivas with ServiceNow has a direct fix for part of your issue with ServiceNow Discovery (looks like a retirement rule that was not being triggered). Know that SN Discovery works with the retirement rules and other automation better than the connected discovery methods, including SCCM.

What I've found in practice and what I've seen in the community is that your configuration of the third-party discovery tools and how they are being consumed by ServiceNow will determine the effectiveness of install status. I have seen issues where SCCM data comes into ServiceNow (where the Service Graph connector is not active and we are just using the classic SCCM spoke) has a "Last Scanned" timestamp that reflects not when the installation was last scanned but when the script last saw the installation in SCCM's table. As well, I have seen where software no longer scanned is not retired but just left with the Last Scanned date static indefinitely.

I currently have a script custom-written by a service partner that removes installs every 90 days that have a last scanned date more than 90 days old just to keep the installs clean. However, because SCCM also keeps install records for 90 days, that means an uninstalled software product can be in ServiceNow as an active install for 6 months before it falls out.

While I do not now how the JAMF connector works specifically, I would assume it will have similar issues if it does not see the expected criteria it needs to mark an installation as "Retired" or delete the record. For instance, if SCCM never deletes its records, ServiceNow will continue to see the install in history and will never mark it as Retired.

Finding a root cause in third-party tools will start with looking at that criteria in the discovery pattern that determines if the software installation should be updated to Retired or deleted. Then, you'll want to look at the incoming data to see if that criteria matches the results of the query. That's the most common issue with discovery patterns, one system miscommunicating to another based on configuration.

Jen Wenrick1 · ‎07-01-2022

@Srinivas Ramanujaiah - thanks so much! I have sent you an email outside the forum regarding the testing suggested!

@Joe Ryder - thanks! Very helpful! If you don't mind sharing - the script you have looks at cmdb_sam_sw_install last_scanned for each install to check? and then presumably also a check to ensure that last scan date for other things (say hardware scan) is current to make sure it is not an overall issue with the server/pc reporting data? thanks for any and all words of wisdom on the SCCM topic! We have not yet done JAMF but will be very soon. I'll add to this that we are currently using SCCM plugin but will be transitioning to Service Graph connector so Service Graph would be my focus for additional improvements/enhancements. (as I don't expect to be using the plugin much longer)

Joe Ryder · ‎07-01-2022

That's exactly right. I'd post the code here (I understand it's not super complicated) but I don't have direct access myself and I'd need to see if I can post it publicly. But basically, it just looks at the date, makes an age calculation, and deletes the record if the age is more than 90 days.

Those scenario-handling logic bits are something we're exploring as we continue to refine discovery overall. Generally, if the server is having any other issues with discovery, we'll see that as credential errors or other errors in system logs, so we can actually monitor that separately. We didn't need it in the logic in this script because we just wanted to focus on an extended "oldest date" this operational data would live. We do flat-filed reporting on individual targets that need installs over time, but the base functionality is set up to just monitor near-current license consumption.

I'll admit we might reassess our data age strategy as we get more mature. We might want those old installs to stick around for a year to get falloff trends, especially for enterprise and "ULA" agreements where we need to see the real performance of contracts against shelfware trends.