Discovery and License use of Non-Persistent Application Servers

[Scott Braden]

All, 

Looking for some insight / suggestions on dealing with Discovery of Non-Persistent Application Servers. Hosted in our VMWare Environment. 

Throughout the course of a day / week / month we spin up -> tear down and spin up non-persistent Application Servers. What we are finding is that each time we do this process the Object ID (vm-xxxx) changes. We do re-use the server name. It appears to us that ServiceNow's OOB Identification rules look for a match on Object ID when Discovery runs. What we are finding is that there appears to be this steady creep of ITOM Licenses being used despite our environment not actually growing day to day. 

We are considering changing the Identification rule from Object ID to Name. But are curious how others have handled this or similar situations. 

Thanks, 

[HDLawrence]

Hi Scott, have you found any information on this? We're working on the same thing.

[Scott Braden]

HDLawrence,

To date we do not have a clear answer to this issue.  

Firstly, if you are encountering the license creep issue I would recommend you contact your account rep(s) and specifically request to speak with someone who “lives” in this ITOM Licensing space.

ServiceNow Support officially came back and told us they do not recommend that we change this OOB Identifier.

From our perspective and in talking with our ServiceNow account reps and working with the product team we have the following sort of takeaways for this issue which admittedly may or may not be helpful to you.

• Initially we were running an older version of the ITOM SU Licensing Plugin. An update resulted in roughly a 25k License usage drop overnight. This didn’t correct the issue but I would say it improved it. I’d highly recommend testing the ITOM SU Licensing Plugin in Sub Prod Prior to installing or updating it in Prod as we’ve observed some Errors in our Logs with the most recent version and Xanadu. So presently we are still one version behind.

• We are using Life Cycle Stage and Life Cycle Stage Status. There is a system property csdm.lifecycle.migration.activated which needs to be set to “True” for ITOM Licensing to use the Life Cycle Stage and Life Cycle Stage Status for its calculations. One suggestion that was thrown out there was to set this to false in subprod and just see if this corrects the issue. Obviously this would be predicated upon having the proper status for install_status and operational status fields.  

• At some point in the distant past my organization customized some of the many different “Status” fields. (install_status, operational_status in particular) Customization of these fields can cause issues with the ITOM SU Licensing Calculations.

• The ITOM SU Licensing Reports do not clearly show which fields are being looked at if you are using the Life Cycle Stage and Life Cycle Stage Status fields. We’ve asked ServiceNow to correct this or provide some way of showing us which fields they are keying off of and we’ve been told they are working on this.

• A suggestion was made recently for us to turn on “vCenter Event Collector” as there was some thought this would help improve the licensing counts. What we were told is that ServiceNow ITOM SU Licensing “polls” multiple times throughout the day and that using “vCenter Event Collector” should at least in theory lead to a much more accurate representation of what is currently out there with our environment. As opposed to only relying on once daily Discovery. Additionally, our organization does quite a bit of vMotioning and this is supposed to help provide better visibility into this. This was a very recent suggestion and we are still working through this process so I can’t speak to how effective or ineffective this might be.

All the above is really looking at the Licensing aspect but not the other issue that we are seeing where we are getting hundreds of vms with the same name. To this end a suggestion was made to explore using CMDB Data Manager to create policies and actions to delete these duplicate VM’s. This also was a very recent suggestion and not something we’ve been able to dig into as of yet.