CMDB setup

[Money]

Hello everyone.
I am looking for some opinions in setting up a CMDB. Is there anyone that is sticking to more of the out of box Service-Now configuration? Is there anyone that has experienced a custom CMDB where you have created from scratch?

We are leaning towards a custom CMDB for various reason. We are looking to map out our items by different class levels and we are not looking to house those levels on different tables. For example, a CI's Hardware classification would be a level 1. From there that same CI's classification of the type of hardware would be level 2. For example, computer. We are looking to possibly go down 4 levels and not have to worry about there being separate tables (for instance hardware and computer). Just some thoughts or experiences regarding the CMDB...

[Jacob_Andersen]

Just some quick thoughts.....

I have done several CMDB implementations and most customers tend to use the setup that SN provides. Many customers add additional classes and fields. When looking at what you're proposing, it does look like you'd be recreating a new CMDB from scratch.

You say that you'd like a flatter structure with additional 'levels' so that you won't have to deal with the additional tables. I would argue that the additional tables (that extend the parent tables) will actually be quite a bit simpler for you in the long run. This allows your child tables to get all of the relevant fields from the parent, but will also allow you to define additional fields that are relevant for only that class type. You can NOT do this cleanly if you use a single table with a 'level' field.

Another reason for basing your structure off of what is already there is you won't have to rewrite all of the OOB SN business rules , etc, that anticipate a particular CMDB structure existing.

Of course, you may design your CMDB however you see fit. This is ServiceNow, you can do anything! I just want to point out why you may wish to keep the parent/child table paradigm and why this will be easier to maintain and use well into the future.

[Eloybayona]

Hello Jacob,

I am also involved in a project were we are going with the idea that we should import our assets to a flatter CMDB model so that we do not have to categorize for example servers into linux vs windows. This way we just dump all servers into the cmdb_ci_server table and not into the separate cmdb_ci_win_server, cmdb_ci_unix_server, etc.. We also wanted to utlize Discovery and just ran a quick discovery scan for a single windows web server. The discovery tool went ahead and created a new CI record in the cmdb_ci_win_server table with the same name and a superset of the info that we had imported for that same CI in the cmdb_ci_server table. So what I am gathering from this is that we will not be able to map what discovery finds to the correct CIs since we have placed them in the more generic cmdb_ci_server table. How easy is it to get Discovery to correctly map the CIs to the more generic parent tables instead of the particular tables? Is it just better to start from scratch again and delete what we had already loaded in the CMDB using excel sheets and transform maps and partition the data into all of the separate tables that service now has setup OOB?

[prdelong]

Discovery can map things pretty easily. It has a set of identifying fields it works through to determine if an existing CI matches the one it is currently scanning. It looks like the server is missing some identifying information (serial #, IP address, MAC). Try turning on the 'generic name' identifier and re-scan. Assuming you delete the other Discovered record first, it should update the server record sitting on the cmdb_ci_server table and reclassify it as a Windows server.

[anilkumarsharma]

HI Sir

as per conversation , you worked on Multiple Project of CMDB. if you have any document. Pls send me