Recently, I’ve focused on connecting discovered data to the Common Service Data Model (CSDM). My first article discussed ServiceMapping and how to connect Application Services to Business. The second article looked at orphan Server CIs and how to make sure that every discovered server is connected to Service offerings and Application Services.
This time, I will focus on workstations or personal computers and how to connect End-User Computing to CSDM. Surprisingly, this topic is vague. Looking at the CSDM reference model alone, there is no clear guidance on this. However, additional details are available from other materials published by ServiceNow. For example, there is some discussion in the ServiceNow Community and the Community’s YouTube channel.
I’m basing this article on Mark Bodman’s CSDM Example Series, in which he explains how to model “Shared Tech and Client Compute Services.” The Client Compute example starts at 7:05.
But before diving into the data models, let’s start with the problem.
The Problem with Discovered Personal Computers
Let’s summarize our problem:
- Sometimes, Personal Computers created by Horizontal Discovery (like SCCM) are not connected to anything.
- The Common Service Data Model doesn’t provide clear guidance for Personal Computers and Workstations.
- While the CSDM Example Series provides additional guidance, how do you ensure that every PC has the required details and that all required groups exist?
- You need a systematic way to handle orphan PCs properly.
In my earlier articles, I talked about “Borderline CI Classes.” (Read here to see what I’m talking about). For this article, I will consider “Personal Computers” as another Borderline Class.
There seems to be some debate in the ServiceNow community on which CI Class is best for End-User Computing, but in this article, I will use the Personal Computer class in my examples. Another option could be the Computer class, which is a parent for the Personal Computer and is often used by discovery tools by default.
The borderline between discovered and manually maintained data
An Approach to Managing Personal Computer CIs
So to approach the problem of discovered, but incomplete Personal Computer data, I will describe the following:
- How Mark Bodman modeled “Client Compute Hardware” in the CSDM Example Series
- How this Client Compute Hardware example, with slight modifications, can be turned into a DCM Blueprint
- Another example data model that’s based on product models instead of locations.
- A way to ensure that orphan records are found and handled as soon as possible.
Breaking Down the Client Compute Hardware Example
In the CSDM Example Series video, Mark uses Location-based Dynamic CI Groups and points out that these computers also have, or should have, a reference to Product Models. In my opinion, Laptops can have locations, just like Desktops. Therefore, I modified the example picture a bit.
So, I will assume that:
- Every computer has a reference to a location.
- Dynamic CI Groups use location data to connect computers to location-based service offerings.
- Service Offerings have Catalog Items that are available for Subscribers in the Service Portal.
- The Technical Service Offerings are actually Business Service Offerings since those are consumed by business users (subscribers of the offering)
Data Model for Personal Computers / Client Compute
Based on CSDM and the Client Compute Hardware Example, we can create a data model that visualizes all the required relationships and references at a class level. The following image is a DCM blueprint with required relationships and references regarding the Client Compute example. (What’s a DCM Blueprint?)
When you run an audit (What’s an Audit with DCM?) against this Blueprint and get the audit results, there are a few things you should pay attention to:
- First, you’ll notice that Personal Computers without a Location cannot have a correct relationship to a Dynamic CI Group.
- Second, you should look for missing Dynamic CI Groups in cases where the PCs have a location but no matching Dynamic CI Group.
- Third, you should verify that all Dynamic CI Groups are Used by (opposite of Depends on) a Business Service Offering that refers to a Business Service and has some catalog items available for subscribers.
You can easily find these things in the detailed audit results that DCM produces.
Another Example with Product Models
The Client Compute Hardware example also discusses Product Models, but there’s no example of how to use that data to connect PCs to CSDM.
I consider this an option or an additional way to connect PCs to Technical Service Offerings based on their Product Model / Manufacturer information.
Here’s the same Client Compute Hardware example, but this time geared toward Product/Manufacturer-based Technical Service Offerings.
When we turn this example into a DCM Blueprint, it could look like this:
Now, instead of Location, the first thing to check with our new Blueprint is the Model ID of the PC, which should point to a Hardware Model. We can find the Manufacturer behind the model and use that as a basis for Dynamic CI Groups.
These model/manufacturer-based Dynamic CI Groups should have a Contained by (<> Contains) CI relationship to a Technical Service Offering. These offerings can have catalog items available for subscribers, and they must refer to a parent Technical Service.
Next, we’ll see how compliant our demo data is against these blueprints.
What the data looks like – Discovery Data for Personal Computers
I’ll use the ServiceNow “demo data” for Personal Computers / Workstations in this example.
In total, I’ve found 263 “Personal Computers” that should be part of the CSDM model. However, these records do not have any CI relationships created by Discovery. Nevertheless, some should be related to Service Offerings and Users based on order/delivery processes and workflows.
My goal is to ensure that all our Personal Computers are related to Business Service Offerings based on their locations and to Technical Service Offerings based on their manufacturers. And, of course, that every PC belongs to someone.
Audit your Blueprints with Data Content Manager
When the Blueprints are ready, you can run Audits on your data. You will get very detailed results that you can use to fix deviations and improve your data quality. Check out this video to see how auditing data works.
Even after the first audit run, we can see how compliant our Personal Computers are against these models.
If we look at the model-based results in more detail, we see that all PCs have a Hardware Model that might have been created automatically, but almost half of the PCs don’t belong to any Dynamic CI Group. This probably means that more Dynamic CI Groups should be created to match the rest of the Hardware Models.
Running regular audits against these Blueprints will ensure that data remains in good shape. DCM can quickly identify when new PCs are discovered and added to the CMDB without the necessary connections and ownership details. It can then automatically assign tasks to the relevant people or teams to fix these issues.
Updating this information while it is fresh is much more simple and cost-effective than running a project to find and correct these errors for thousands of records later.
Stuck with CSDM?
CSDM is a broad topic. We’ve written a lot about it and how Data Content Manager can make CSDM alignment easier.
Here are some excellent places to look for more information:
Please get in touch with us for a private demo where we show how Data Content Manager makes all this simpler.
