Ask the Expert: Live Chat | Assets and Models and CIs, Oh My!

ServiceNow
Administrator
Administrator

Original Air Date: Thursday, July 9, 2015 | 10:00 AM (PDT) | 1:00PM (EDT)


Do you struggle with the difference between Assets and Configuration Items? And why do we need Model records? Isn't that just another thing to maintain? Get a better understanding of these items, how they are different, and how they work together in this session with Ben Sweetser.

Ben Sweetser is a ServiceNow "old timer" with experience on the full platform with focus on Asset and Configuration Management and Automation, such as Orchestration and Discovery.

43 REPLIES 43

Community Alums
Not applicable

Hi Chad,


Sorry for the delay in responding. What happens is that when the CI goes through the decom process, the Asset ends up back In stock. When the device is repurposed and put back into use again, the same CI is used, but would receive a new name and new details (such as Operating System). The history of the CI is available to see what it was previously. This gives you direct access to past tasks performed on the CI. Looking at the history, you'd see that the CI went through a previous retirement process. You're just updating the existing CI record with new details.


Ben


Ben,



Thanks for the response. This does make sense. I feel like this should work well for us.



The only other questions I have a bout this process are below:



1. Say we have a Windows CI. It is decommed and now has an "In Stock" status on the Windows server table. This hardware asset is now being repurposed as a Linux Server. Discovery runs, classifies the CI as a Linux server, looks in the Linux table, doesn't find a match on serial number/IP because our old CI is in the windows table and then creates a new CI in the Linux table. How would we keep this from happening and have Discovery update   the current available CI that may be in a different class table? (our current discovery set up scans the windows or linux table for a match in that table after the CI is classified as such)



2. If a CI is repurposed from windows to linux or vice versa, will the Model category on the asset automatically update or will that be a manual process?



Thanks again for getting back to me this is a huge help for us.


Community Alums
Not applicable

Chad,



I recommend taking a look at the options for reclassification of CIs (https://docs.servicenow.com/bundle/jakarta-servicenow-platform/page/product/configuration-management...   ). You can identify if you want the reclassification to be automatic or for it to instead generate a reclassification task.



As for matching up in the Discovery to prevent duplication, you can have a number of CI Identifiers that progress from more specific to less specific. It will stop as soon as it finds a match A more specific one may have class on there, but you should enable the identifier that matches just serial number as a backup. That will ensure it gets matched, even if the class is different.



If you are not using ServiceNow Discovery, be sure you are using the Identification and Reconciliation engine in your process to bring CIs in to leverage these CI Identifiers. (CMDB Identification and Reconciliation )



Finally, no, the Model Category on the Asset does not update. From a technical standpoint, this does not matter: The Model Category is used to create the corresponding CI when an Asset is created and vice versa. From a reporting standpoint, this may cause some concern. You don't want a Windows Server reporting as a Linux Server. With process in place though, the devices you buy should end up in the more generic "Computer" Model Category or possibly "Server" rather than the more specific class Discovery assigns. From an Asset perspective, this makes fine sense. The asset could be deployed in different configurations. If you want to report on Linux versus Windows, you would simply use the class on the CI at that point.



I hope this helps,


Ben


klf1123
Kilo Sage

Ben bsweetser -



I understand the importance of models and for hardware the link between CIs and Assets makes sense to me. What I want to understand more is software tracked as CIs from an company standpoint and software licenses on the asset side. I understand that the hardware CIs have the software installs marked but what about software CIs being tracked as applications why is there not a way to combine the CI and asset view. The company wants operational and asset view of software applications and some of those are licensed software titles. we were discussing adding the software model onto the Application CI so that we can link the data from the license table over to the CI table. I am not sure why assets and CIs are only linked for hardware but not software from a application management perspective. Thanks.



Karen


Community Alums
Not applicable

Hi Karen,


I want to describe your question back to make sure I properly understand. I'm going to use SQL Server as an example of an "Application" here. The reasoning is the same:


Let's say you have a Server with Microsoft SQL Server on it.


Discovery finds a couple things here:


  • It finds the Microsoft SQL Server Software Installation, which is used by Software Asset Management to determine compliance
  • It finds the MSSQL Database Server for which it creates a Configuration Item that is linked to the hardware it runs on and to any database instances running on that server

You're wondering why this Database Server CI is not associated is not associated with the Software Installation. Is this correct?



If so, a couple reason come to mind:


  • The Database Server CI is a logical representation of the software to serve the purpose of mapping items in the environment to show how and where things are connected.
  • Discovery of this CI requires the appropriate probes and credentials, which should not be required to perform Software Asset Management.
  • The Software Installation information can be discovered with the credentials for the hardware and provide the detail required for Software Asset Management.
  • They serve different purposes. You could use this information to determine "Hey, we found this software installation, but we didn't get a CI for this... we should investigate!" or the reverse "Service Mapping found this Application, but we don't have a corresponding installation for it for some reason. How did that happen?"
  • When it comes down to it, what value are you trying to get from having these items connected?


I hope this helps.



Ben