INTRODUCTION
ServiceNow releases most ITOM content outside of major releases, via the Store. This distribution approach has been a great benefit to the ITOM world because it delivers so many functionalities and fixes at a much faster pace. Do these updates really make a difference? As an ITOM practitioner I can absolutely confirm the benefit
I regularly see Discovery errors disappear when key ITOM plugins are updated. I have also seen many cases in which ServiceNow support pushed back on troubleshooting a ticket until the customer's instance was brought up to current revision. While that situation sometimes causes frustration, it's also frequently the right approach given how often it makes a real difference. The writing on the wall is clear: update your plugins
PICK YOUR PLUGINS
The first step is to identify the plugins that are in-scope. The starting place for this question is defining which components are in use. Typically we would see things like:
- Workspaces (CMDB, Discovery, Cloud Discovery, Service Graph Central)
- Service Graph Connectors
- Supporting plugins (Discovery and Service Mapping Patterns, CMDB CI Class Models)
- Other ITOM
Let's assume a common deployment with ServiceNow Discovery and the Service Graph Connector for Microsoft Intune. Using the Application Manager (System Applications > All) you can build a list of plugin labels and IDs.
- CMDB Workspace (sn_cmdb_ws)
- Discovery Admin Workspace (sn_disco_workspace)
- SG Central (sn_sgc_central)
- Service Graph Connector for Intune (sn_intune_integrat)
- Discovery and Service Mapping Patterns (sn_itom_pattern)
- CMDB Ci Class Models (sn_cmdb_ci_class)
It can be cumbersome flipping through records in the application manager if you need to check all of your key plugins, so I recommend setting up a filtered list view favorite to allow for a faster check. Navigate to the Store Applications table by entering "sys_store_app.list" in the left navigator.
You will likely need to configure the column layout to make this useful. I suggest the following as a starting place:
NAME | ID | SHORT DESCRIPTION | VERSION | LATEST VERSION | UPDATE AVAILABLE
Next, open the filter, and add criteria for the ITOM products you identified above using "ID is one of…"
Finally, click on "Run" and you should see a table similar to the following:
Last step: Use the Star to apply this as a Favorite, and label it "ITOM Plugin Versions."
Now you can conveniently check your suite of ITOM plugins with a simple click. This will come in handy when planning updates.
I also recommend you add a section to your Configuration Management Plan (CMP) documenting these key plugins. This provides a source of record for your expectations of updates, allows the Platform Team to understand the CMDB Team's requirements, and ensures that the important updates aren't stored on post it notes around the office.
UPDATE PROCESS
We have defined the list of plugins that we need to keep current, but how often should they be refreshed? One of the most important plugins is Discovery and Service Mapping Patterns (sn_itom_pattern). This plugin is updated roughly every 30 days. I recommend updating all of the key plugins at the same time, which is monthly.
I will leave it to ServiceNow docs to explain the process of updating a plugin using application manager; It's pretty simple, but there are a few nuances to consider.
Before updating any plugin, review the release notes in the ServiceNow Store. These notes highlight new features, bug fixes, and any specific considerations for the update. This takes just a few minutes and helps you understand what's changing in your environment. This information is available in the install interface for each plugin. I do not recommend curating updates to only those fixes which specifically impact your environment. I view the CMDB landscape as a system which should be kept current as a whole.
After each update you need to check for high priority skipped updates . Make sure you check the installation results to confirm things went as smoothly as you'd hoped. It is not unusual for a few patterns to have small customizations which cause a skip that prevents you from receiving updated code. These customizations can be anything from someone making no changes, but saving the pattern all the way to changing the code. Any time the update process encounters a component with content or timestamp it's not expecting, the update will skip, and require administrative intervention.
I recommend maintaining a configuration registry as a component of your configuration management plan. Its purpose is to document critical configurations which are subject to governance controls. In this case, a known and CCB-approved pattern customization can be documented to explain why it is in place, when it was approved, and handling of updates. This can be managed directly in the registry, or via links to design documents which contain these details. If you plan for managing future updates at the time of CCB approval of customization, then you pave the way for more efficient updates.
What if you have no registry, and you have pre-existing customizations which are not approved by the CCB? Get them documented on the registry in a pending state, and get stories in your backlog for decomposing the changes, filling out your design documentation, and completing a CCB design review.
As with any significant change, these updates should first be installed in a development environment and validated. This should provide timing an specific process for installation on UAT. After two installations you should be confident in the risk mitigation and duration for your production updates. I've been doing this for many years at many customers, and have found the process to be very smooth. I don't consider this a high-risk change.
TESTING
Testing is a vast topic that would need its own series of articles to dive deeply into.
For Service Graph Connectors, you should have a documented baseline of time, number of records, and any benign errors or warnings that should not be attributed to the update itself. With this information, you should be able to review the results of an import following the update and have confidence that things are as intended.
For Discovery, try to document a small set of test targets representing your principal classes which you can Discover following the update. Of course you will need to manage those target lists as devices come and go, but this test case is important to catch problems early. You can start with a simple process stored in a KB article, or try your hand in using Test Management 2.0. You could even get fancy using Automated Test Framework (ATF) on your non-production instances.
Regardless of your approach, start simple, do something, and document it so that you have a foundation to iteratively improve.
CONCLUSION
In this article we discussed the importance of updating your ITOM related plugins with a more frequent cadence than environment upgrades. We configured a simple list view to identify out of date plugins, and provided some key considerations for building your own update process. One of the first things I do when I'm engaged for CMDB remediation is to check and update plugins; I hope that this article helps you to keep your CMDB a bit more reliable with the fresh features and fixes.
