Which CMDB CI Class is correct for Laptops and Desktop Computers?

[Daniel Slocum]

There has long been discussion around the topic of which CI Class is appropriate for laptops and PC’s. These are the CI records that represent the computers individual workers utilize for productivity each day. The arguments on this topic center around two classes; the Computer (cmdb_ci_computer) class, and the Personal Computer (cmdb_ci_pc_hardware) class. At the center of the discussion is a desire by some to define configuration items more accurately in the CMDB by the class in which they are stored. The Server class, which is the parent class for a number of classes of servers is extended from the Computer class and thus provides granularity for infrastructure computing so why not remain consistent and leverage the Personal Computer (PC) class for end-user computing devices in the same manner? After all, the PC class is also extended from the Computer class so it just makes sense this way. Others say, “not so fast.”

Having worked with a significant number of ServiceNow Asset plugin and Hardware Asset Management customers, I’d like to proffer my thoughts for consideration should you be involved in this “discussion” within your organization, or if a consultant is guiding you one way or the other. First, let me cut to the chase; for most customers, I don’t think it is beneficial to use the PC class.

Within the ServiceNow CMDB hierarchy, the Computer class, which is extended from the broader Hardware class, is the parent class for computing devices: servers, desktops, laptops, and handheld units. Extending from the Computer class is the Personal Computer class. Why might it be necessary or maybe beneficial to store records there instead of the base Computer class?

Maybe there are additional attributes available on the cmdb_ci_pc_hardware table that are needed to properly manage CI’s throughout their operational lifecycle?  Looking at the CMDB structure alone, there is no benefit to using the PC class over the Computer class as the PC class adds no additional data attributes in which to store operational, characteristic, or identifying data. You can visualize the previous statement in the image below. Note that the Computer table has a “plus” sign followed by the word “columns”. This indicates columns unique to the cmdb_ci_computer table are present and can be viewed by clicking the plus sign.  Now, look at the Personal Computer table. It is the fifth table down in the column of tables extending from the Computer table on the left of the image. There is no “plus sign” followed by the word “columns” there, which indicates there are no unique attributes to display. Scratch one reason to prefer the PC class over the Computer class. 

Note that the image is also added as an attachment. Downloading it can give you the flexibility to make it larger and easier to read. Clicking the image will also make it larger.

Granular classification is another reason why one might prefer the PC Class over the Computer class. PC Hardware is more granular in that it segments End User Computing devices from the more inclusive Computer table. This reasoning also holds with the Server table extended from the Computer table. Server, in turn, has a number of tables representing different server types extending from it. However, the Handheld Computing Device table is also extended from Computer and is not extended from Personal Computer, which one might expect. There is also the Form Factor attribute on the Computer table to take into account. This baseline choice list, shown below, contains the granularity most CMDB Managers are looking for without a need to utilize the PC class. Present among the available choices are both Desktop and Laptop, which accounts for both computer types generally tracked in the PC Class.

Let’s also talk about Discovery Sources. The Service Graph Connector for Microsoft SCCM, ServiceNow Discovery, and the Agent Client Connector all integrate with the CMDB to store data in the Computer Class.  Recently, one of my fellow Rangers, Doug Schulze, did a write-up and video on how to modify ServiceNow Discovery to write to the PC Class instead of the Computer Class.  A key takeaway was that once you make that change, you own that change because you have modified baseline ServiceNow features.

In this writer's opinion, it is best to not adopt use of the PC Class over the baseline Computer class. But, I’ll give you this one concession. There are a myriad of business reasons for doing something and your organization may have a very legitimate reason for needing to use the PC Class. That is the beauty of the ServiceNow Platform. Customers can leverage its features to meet all manner of use cases that haven’t been discreetly provided for by baseline product features or configurations. If this is you, go for it! Utilize the Personal Computer class to meet your needs. If this is not you, I recommend, you stick with the Computer class.

[Pascal Verdieu]

@markbodman Rolling back the OG post, do you if there was some thought about the separation of duties between Computers and Servers, and if yes, what was the thinking behind this.  Or were servers added afterwards and the the differences between the 2 classes were missed (see my post for some examples)?

Tkx

[markbodman]

Hello Pascal,

Here is my advice given the main thread topic of Client Compute challenges.

This is a grey area in that client compute places these these CI's initially side-by-side with servers. So this starts with knowing if this is managed as Technical or Business Service, which I discussed this at length in this CSDM video here .  As noted above, we use Client compute is generally not discovered using our discovery as we are focused more on decanter use-cases.  But that doesn't mean it won't work either, with most client compute "working from home" these days, it's generally less discoverable on networks.

As a rule of thumb, I suggest that relying on Service Graph connectors and IH-ETL to bring this data in from element managers for client compute.  Knowing how external source data maps to CI classes can be leveraged from product documentation here for example.  The the SCCM Service Graph Connector is in our store and free, so a good place to start. As noted above, cmdb_ci_computer is the destination CI, so in general, rely on the source system and automation we provide OOTB to guide your on these decision..  Other connectors will likewise map to CI's as appropriate.  I'm sure there are improvements that can be made but it gives you a cleared CI mapping so you don't have to guess.

One thing that hasn't been used as widely is that we created the Dynamic CI group to leverage a query approach to grouping CI's and the intended offering & service (Technical or Business) per above discussion.  With these queries, we don't have to create a separate class for every imaginable situation such as client vs. datacenter compute for example. How could you handle a situation whereby you issue a server class computer to an employee to work at home? Leveraging specific attributes on the CI itself such as discovery_source in the query condition can help determine this is a client compute situation, no matter what the class or in addition to the class to guide you. Or other related records can be used such as the model_id, or related asset details if that's a better source to segregate true client support vs. something running in a data center. Assets will typically be assigned to individuals for example.  Ideally, there is a policy that client compute is tracked when issues, I suggest finding that source, setup a Dynamic CI Group segregate client vs. datacenter compute, and align them to your service type, (business vs. technical).

I hope this helps. Sometimes external context will lead you to the right answer vs. getting wrapped around the axel on trying to come up with a perfect CI class structure.

[Daniel Needles1]

@markg  -- Absolutely! No one's perfect.  8-)  

That said, I think there is some "low hanging fruit" that could shore up things in the "Difficulties around Joins." Take Query Builder.  The biggest barrier is the lack of visibility regarding the scheme and proprietary verbiage describing connections.  For example,  imagine I want to join "Computers to VMware."  After I drag the two tables onto the canvass and try the direct and indirect connections, it is hard to know "magically" what to do next.  The workaround for me has been this older reference map https://www.snow-mirror.com/wp-content/uploads/2016/07/ServiceNow-Data-Model-v3.4.pdf   If ServiceNow could provide a visual high level navigation along these lines, that would mitigate much of the guess work when trying to "grok" how the heck ServiceNow would navigate from here to here.  The Table & Columns Schema Map gets there part way, but isn't quite enough.  Also, in all the documentation for Query Builder I've ran across it never references anything to mitigate this "map visualization" problem.  It really should be in the how tos.  Of course having ServiceNow automatically create the link between two tables  dragged onto the canvass is really where things should end up eventually, but in the meantime at least describe the tables and relationships needed to get there somehow.

Regarding "Product Management"  Thanks for the videos!  I am unsure if I have ran across those.  Hopefully, it is user error and these will answer a good chunk of my questions.  I'll take a gander.  That said, I suspect these are "isolated" in nature.  The issue I've run into is the "teaming" of the various artifacts into a coherent and organized approach.   Let me describe what we are doing as a case study of what I mean (as well as possibly exposing some assumptions and misconceptions I have.)

We ended up building our solution around the CMDB View (Health) Dashboard.  First we scoped the devices:

•Servers (Linux, Windows)

•Database Servers (Oracle, MS-SQL, Postgres, MySQL, Mongo DB)

•Hypervisor (vCenters, ESX Hosts, VM Instances)

•AWS (EC2 instances)

•Computers (Laptops/Printers/Hand-held)

Next we used the context of the Dashboard to scope the metrics covered:

Correctness – data integrity:

•Orphan, Duplicate, Staleness

Completeness – are fields populated correctly:

•Required Fields: Due to discovery already populated, so not much here.

•Recommended Fields: Env, Location, Group/User, Discovered Fields

•Data Certification: (same fields covered as Required and Recommended Fields)

Compliance – Do devices meet CDK Policies:

•Not at this time; future Implementation

Next we used input from the Device Owning Groups to set up the CI Class Manager's Health attributes at a device type level followed by adding a UI script to highlight the CMDB Recommended fields select per device type in Yellow (as they are otherwise invisible.  )

Next we created additional tabs on a device type basis with the above metrics so the device owning group could click into the metrics and pull up the offending devices to handle missing Recommended fields and Stale Devices.  We created scripts to automatically generate de-duplication tasks on a device type by device type basis.  We created another script to automatically cull orphaned records (in certain cases.)   Finally, we are in the process of automating the creation of Data Certification tasks (which check the recommended and required fields for correct population.)

This automated the CMDB health and allows us to delegate to device owners the CMDB health and welfare maintenance for their devices where possible.   However, this approach required tweaking the CMDB View Dashboard and doesn't use either of the Data Foundation dashboards, CMDB Workspace, or any of the other widgets.  So one point of potential conflict and lots of technical debt. 

What I would expect from ServiceNow is a couple case studies of businesses using these various artifacts to the level above describing how they work in concert to provide Situational Awareness and CMDB remediation.  Does that make more sense?

[Kunal Paul]

Do we have any dashboard that shows a breakdown per device type etc?  need reports from the CMDB around the amount of Networks, servers, Thin clients, Notebooks, Desktops etc

[DonnaOlsen]

I would imagine Model Category could help categorize these and populate to appropriate classes.