SG-SCCM and Computer Hard Drives/Disks Updates

[kchapman87]

My organization is working on ensuring we are tracking Computer Disks (hard drives) within ServiceNow when we have ran into a question that I cannot seem to find a clear answer on in regards to the SCCM Service Graph Connector.

If a USB/Removable/Portable drive (disk) is removed from a computer, will the CI record make this update upon the next SCCM scan (e.g. the disk will drive will no longer be related to the computer CI record)? Or will it remain and also appear on another Computer CI it may be moved to?

[Fabian Kunzke]

Hello,

What a great question! Certainly, you can always make sure by tracking the sys_ids of the records. However, there is also a clear theoretical answer:

Identification rules.

Within the IRE (used by the SGC for SCCM) you will have a identification rule for the cmdb_ci_disk class. This identifier dictates the behavior of the import(s) [Note: the same rules also apply to Discovery and other SGCs]. At the end of the day, you can dictate how this works, but i will explain the ootb setup a bit in detail.

Firstly, the issue with disks is how they are identified and how they are discovered. Most disk details are discovered through the host. This brings some limitations, as we don't always get a unique identifier (like the serial number). If we would, then we could identify disks based on their unique value. But here comes the catch: We can virtualize disks. So even if we get the serial number, across multiple devices or servers we could not make sure that these always differ by definition. 
And therefore, disks won't be unique just based on their individual parameters. Not based on their name, serial number or other details.

This is where another setting in identification rules becomes key: Dependent identifiers. The way these work is that they include the dependency to another CI in the identifier. It applies to application CIs as well:

As you can see here, this is a dependent identification rule for the cmdb_ci_disk class. In this case, the uniqueness of your disk is always determined based on the device it is related to.

Long story short - if the same disk appears for a different device, the disk is created as new CI because the identification rule is a "dependent" one: Your disks are unique in the scope of the dependent CI. Same disk, new dependent CI -> new uniqueness.

Now that said, if you'd like to change that behavior, you can. However, USB disks should - IMO - be managed differently than "normal" disks. I highly recommend creating a child class for these cases to make sure you can separate the identification rule from all other disks. If you wanted, this would allow you to identify USB disks independent from their related CI (known as an independent identification rule).

Now should you do that? Well, if you want to track USB drives in more detail because of a strict use case (security related, asset management related or others) - sure. You will need to make sure that all imports (including the discovery) treat USB drives/disks as your new custom class, but it would be possible.

Hope this helps

Regards

Fabian

[kchapman87]

@Fabian Kunzke 

First, thank you for this detailed information! 

To confirm what you are saying, since the identification rules are seeing disks as unique CIs due to the dependency, it is NOT removing any relationships if/when a removable disk is removed from a device...correct? It will remain related to the Computer CI and if moved to a different Computer CI , a new disk CI will be created and related to the different computer CI.

Also, we are currently working on a solution to be able to pull in hard drive (disk) serial numbers for computers into ServiceNow via SCCM thus this came up if we want the serial numbers for these removable disks/drives as well as my initial question.

[Fabian Kunzke]

Hey,

So yo get the full answer, you need to combine what i wrote with what @Vishnu-K wrote. If storage devices are not discovered again in a full load for a device they will always get removed due to the cleanup process he described. To my knowledge you can change the behavior here, but it only makes limited sense outside the scope you are referring to. So generally I would not advice for it.

Your second assumption of a new disk being created when the drive moves to a new CI is correct. This is due to the dependent identification rule.

So if you want to change this completely, you will need to adjust both the cleanup as well as the identification rules. From my perspective this should not be the case for all drives (e.g. for virtual ones there is no value in this and it would make it absurdly hard to deal with virtual drives), but i do see value in doing it for drives you expect could be moved (USB, maybe even physical drives). At the moment all of this is handled through one class.

Implementing this would mean you need to adjust all imports for disks (otherwise you will have inconsitencies) to use your new identification rules (again, i'd recommend a new class to separate USB (and maybe physical drives if you want to manage that as well) from virtual drives). Further the cleanup needs to be adjusted to ignore that new scope.

Overall this only works well if your data is consistent. Any time you do not get a serial number or one that is not unique you will run into issues. And these issues are massive. One core functionality of the drives inventory - especially on a server level - is to measure the full drive capacity against the used capacity from the directories. If you are missing a drive or a drive is flopping (switching from one CI to another because of a duplicate serial number), then these measurements go out of the window. Now for USB drives they usually won't impact the overall storage capacity as they are not intended as long-time storage. For physical disks i would not take that risk.

It's a potential trade off: Yes, you can now manage physical disks better. However, you run into the risk that your storage capacity measurements in the CMDB will get inconsistent. This is why I would re-assess how important this really is. For USB drives I can see the value IF (AND ONLY IF) you have a process to actually manage USB drives. For all other long-term storage devices I personally don't see the value compared to the risk of not being able to tell if your server has enough storage capacity or not.

In short: What you intend to do is possible. It has more technical depth compared to just flipping a switch as it is not in-line with the default (so ootb connectors, the discovery etc. won't be aligned with this and it will impact future integrations). If you have a process that manages these USB drives and it is indeed of high value to your company to flag moving USB drives and raise an actionable item based on that - good. If you "only" have the requirement that it would be "nice" to see and identify these drives - don't do it. The overall platform impact is likely not worth it.

To be a bit overdramatic: The CMDB is not there for nice-to-have features. It is the foundation most of your processes rely on. If there is no process relying on what your need to implement - don't implement it. Or at least question it.

Hope this helps

Regards

Fabian

[kchapman87]

@Fabian Kunzke 

Thank you very much for all of this additional detail and context. It is extremely helpful!