Hardware status and Substatus OR Install status on CI-classes with Hardware devices

[Ed Laar]

Hi,

I am facing a possible issue in the use of Hardware status and Substatus versus Install status. Following the documentation Hardware status and Substatus should be used on CI-classes that contain hardware CI's while Install status should be used in classes containing non-hardware CI's. So far perfectly fine.

But: On several CI-classes this is OOB not the case.

Example: On cmdb_ci_display_hardware, Hardware status and Substatus are not available, even so on cmdb_ci_ip_phone.

What is the best way to do in these cases? Add Hardware status and Substatus (but they will be added as customized fields) or leave it as-is (but this is causing confusions)

Any suggestions? What do you do in such cases?

Grtz,

Ed

[CMDB Whisperer]

Per the CSDM 5 document, unfortunately I would have to say that it is very much NOT ready for prime time.  Every indication seems to be that ServiceNow is still figuring out a path for customers to migrate to CSDM Life Cycle -- or they are leaving it to customers to figure out their own path.  The Washington release passed my synchronization tests, so although I was a bit cautious still because ultimately I wasn't convinced that the chained business rule  logic approach to synchronization would ever be a workable approach (and still am not), I reluctantly started giving the tentative thumbs-up for adoption.  But lo and behold, the very next release ServiceNow decides it wasn't going to be a workable approach (ahem!) and decided to discontinue the syncronization in favor of a new Product Instance 2.0 which expands the use of CSDM Life Cycle to include CSM, while discontinuing all support for Life Cycle Mapping synchronization!  There are not enough details available about this solution for me to confidently say when CSDM Life Cycle will get a thumbs up from me.  I still have more research and testing to do.  Unfortunately, PI2.0 is a one way street so I'll need to do this testing on a temporary instance I can throw away afterwards, maybe a PDI if installation is available there.  I haven't yet had the time for this but hope to be going down this path soon and will share my findings if possible.

[s4scott]

Currently, to successfully use the CMDB with other modules (SPM for example), both the legacy state/status fields and CSDM Life Cycles must be respected. Ignore one or the other at your own peril. This is slowly improving, but Life Cycles have not been universally adopted as of Yokohama. Going to start testing with Zurich this month.

[CMDB Whisperer]

Hardware Status and Substatus in reality should be deprecated, but they are not.  They are an artifact from a pre-Aspen time when asset management functionality was overloaded onto the CMDB tables.  Unfortunately, today there is still a default rule that causes the Hardware Status and Substatus fields to be considered the de facto standard fields for CI status, if the CI is a Hardware CI.  As a result your install status will not be in sync.  Bottom line is that there has long been a disconnect between the different fields, and as a result the fields don't stay in sync, and bad decisions can be made based on conflicting reports around whether an asset is actively in use or whether it has been retired!  Along came CSDM Life Cycle which seems to have been designed to fix the problem but in reality (thus far) it has only made the problem more complex.  The best I can tell you, in short, is the following:

1) Don't use Hardware Status at all, ever, anywhere.  Kill it.  Bury it.  Deactivate the fields in the dictionary so no one can even add them to the forms.  This won't cause data loss, and you can still query those fields as needed.

2) Make sure you do some data audits and configuration audits to figure out the true status of your CIs and assets in question.  They are probably broken.  Create a pivot report showing your CI statuses and their respective asset states and you will see what I mean.  There are bound to be some stark contradictions.

2) Modify (yes modify) the script that synchronizes status between Assets and CIs so that it only uses Install Status, regardless of whether or not it is a Hardware CI.  For the skeptical out there, ServiceNow has published a knowledge article prescribing this to resolve synchronization issues, even though they don't acknowledge it as a bug.

3) Adopt CSDM Life Cycle Management in a limited fashion, only supporting one-directional synchronization from the legacy fields to the CSDM fields.  Do not allow users to directly set the CSDM Life Cycle stage/status on Assets or CIs.  It will break stuff and make your synchronization problems worse.  But do consider allowing your CSDM Life Cycle stages to be synchronized from your legacy fields, and consider creating status-based reports or business rules based upon the CSDM Lifecycle once you confirm that the synchronization is working properly.  (UPDATE: life cycle synchronization is not supported after Xanadu, so this recommendation is no longer valid.)

[Ed Laar]

Thanks Kilo Sage for your comprehensive reaction; really appreciate it. We will start re-considering the Hardware Status and Substatus and propose to move to Install status only.

Do you have by the way the mentioned ServiceNow KA on-hand regarding this??

Grtz,

Ed

[Christine13]

Here is a link to the KB that talks about updating the AssetAndCISynchronizer Script due to the issue. 

Install Status for Hardware CIs (e.g. Pending Install) is mapped from Asset to CI but not mapped fro...