Wanted to share the following with my healthcare peers for awareness and to see if anyone else has run into this situation.
Short Version: I would highly recommend updating your ITOM Plugins if you are behind, specifically ones around SU counts for ITOM licensing to ensure SU's are being counted/consumed accurately:
Long Version:
We ran into an issue where suddenly our ITOM SU's spiked. Initially, we thought this might have been a result of an integration we had done. ServiceNow rightfully reached out to us from a compliance perspective as we were showing significantly over.
Digging into the reports available to us, specifically the Report ITOM Licensable CI's report, we noticed that our VMware instances were showing far more than it should have.
Reviewing the ITOM Licensing knowledge docs we noticed the following bracketed in red:
We quickly went and looked at the VMware instances captured in the ITOM Licensable SKU's report and noticed over 16000+ of them were virtual desktops that met the criteria to be excluded.
I then noticed that our ITOM/OT SU Plugin was one update behind. To be clear, not a major release. I went ahead and updated that plugin, and suddenly all my counts were back in line, with proper exclusions.
While I wouldn't have thought a customer not updating a plugin resulted in discrepancies on the ServiceNow side, it does appear to be the case. Had we not dug into it further and accepted the number as is, it could have resulted in a significant expenditure to true up ITOM licensing.
Anyone else run into this?
Brian,
Just wanted to chime in that at my organization (also a health care organization) we too have observed a similar issue, with VM's and when we installed the latest version of the ITOM/OT SU Licensing Plugin we observed a drastic decrease as well. Close to a 19k decrease.
Unfortunately, in our instance this alone hasn't proven to be the only issue. In our environment we have many non-persistent VM's both for End Users but also for App Servers, and we've found that ServiceNow's OOB VM match occurs on and only on Object ID. Our organizations process with VM's is we spin them up and tear them down all day long every day. This process re-uses "Name" but the Object ID continually changes. Which is resulting in "new" VM's being created with the same "name" multiple times (hundreds of times). It seem to us that this is a contributing factor to the issues we are seeing. Additionally, we've observed some strange behavior around a business rule called "Sync Ops Status for CMDB CI" where it doesn't appear to be properly running for us on our Windows Server CI Records. At least as compared to the functionality within a PDI.
In one of our engagements with ServiceNow we were told that SU Licensing is based off of the "Life Cycles" and no longer based off of the install_status field, despite all of the ITOM Licensing reports that we can see showing Install Status. In that same engagements we were told the issues we were seeing in part were because the "install_status" field in our instance had lost the value of "Retired" and was instead just defaulting to "7". We were further informed that due to the Life Cycle Mappings that when the "Install_Status" of "Retired" was selected the proper "Life Cycle" changes should occur automatically. We therefore fixed the issue where "Install_status" was missing the "Retired" value and subsequently updated close to 300k VM Records so that the "Install_Status" field properly reflected the value of "Retired". - This seemed to make a big difference for us and our licensing dropped again.
However, we then observed something a bit unexpected where in our instance we are running into issues where we have a one to many relationship between Window Server CI's and VM's and where retiring one VM that is associated with the Windows Server subsequently retires the Windows Server CI. Initially we thought this would be okay and that subsequent Discovery scans would detect that the Windows Server was in fact still present and flip it back to active. Unfortunately we were only partially correct. Discovery did find that the Server was still there, and did flip the "Install_Status" field but for some reason in our instance the Business Rule "Sync Ops Status for CMDB CI" doesn't appear to want to run for Windows Server CI's. Nor do the OOB Life Cycle Mappings appear to run.
We have an active case opened with ServiceNow, and we've engaged our ServiceNow reps. We've been told that we are not the only organization in this space facing issues.
Not sure if any of what I've provided helps but just wanted you to know you aren't alone with the issues you are seeing.
