Configuration management is a application which stores the tangible & intangible entities of the network. All the configuration items which are involve in logical network are stored in configuration management module. CIs are categorized on the basis of class.Data is stored in cmdb_ci table which is one of the core table of servicenow.
The configurations are stored in a configuration management database (CMDB) which consists of entities, called Configuration Items (CI), that are part of your environment. A CI may be:
- A physical entity, such as a computer or router
- A logical entity, such as an instance of a database
- Conceptual, such as a Requisition Service
In each case, there are attributes about the CI that you want to maintain, and there is control you want to have over the CI. There are changes that may need to be made and tracked against the CI. Also, to be sure, a CI does not exist on its own. CI’s have dependencies and relationship with other CI’s. For example, the loss of a bank of disk drives may take a database instance down, which affects the requisition service that the HR department uses to order equipment for new employees.
It is this relationship data that makes the CMDB a powerful decision support tool. Understanding the dependencies and other relationships among your CIs can tell you, for example, exactly who and what is affected by the loss of that bank of disk drives. When you find out that a router has failed, you will be able to assess the effect of that outage. When you decide to upgrade the processor in a server, you can tell who or what will be affected during the outage.
Configuration Items are a personal issue, because each customer has a unique environment. Details about the exact physical attributes of a computer may be needed by one customer, but may just represent meaningless data to another. ServiceNow therefore provides a mechanism to easily define new classes of Configuration Items and new relationships that may exist between CI’s. New classes can be defined that extend other classes. For example, a laptop class exists that extends the computer class. The computer class itself extends the base CI class. Customer class extensions are automatically part of the ServiceNow environment and blend seamlessly into the integration points for other ITIL processes.
MENU & MODULE
All the CIs are bifurcated on the basis of class. CIs related to computer are stored in ‘Computer’ module, servers are stored in ‘Server’ module. Similarly for all CIs , some class is defined.
CREATING NEW CONFIGURATION ITEM
Goto ‘configuration’ module and as per the class of your CI , select the module & click on create new . Here in below screenshot, CI of Linux class is being created:
The CMDB, in contrast to a static asset list, helps you track not only the configuration items (CIs) within your system, but also the relationships between those items.
A relationship in the CMDB consists of two CIs and a relationship type:
- Parent CI
- Child CI
- Type of the relationship that links both CIs
For example, in the [Server1] [Managed by] [Server2] relationship:
- Server1 is the child CI
- Server2 is the parent CI
- [Managed by] is the relationship type
For example, a web application might read data from a particular instance of Oracle, which in turn might depend on a piece of underlying hardware. Most CIs in a CMDB have multiple relationships to other CIs, users, and groups.
The relationships between CIs can be automatically discovered. If you use Discovery, many relationships can be automatically loaded into the system through the discovery process. If you import your data from another system, you may get some form of relationships.
You can add to automatically discovered relationships, create new relationships, or edit relationships for a CI by launching the CI relationship editor from the CI form.
BSM : BUSINESS SERVICE MAP
BSM is a graphical representation of CI and its relationship with other CIs. User can view different layout of BSM using view option available in CI form.
A business service management (BSM) map has one starting point, called the root CI or root node of the map. The root CI is highlighted with a circle around it. The maps can show both upstream and downstream dependencies for the root CI. By default the BSM map displays 3 levels, both upstream and downstream relationships, and collapses all clusters. Administrators can configure the number of levels displayed.
Use the layout controls to display map elements in different configurations for easier management. Use the filter panel to display fewer levels or to filter out elements you don’t want to see, then save the filter for use later. Draw new relationships between elements or edit existing relationships.
In a BSM map, icons and glyphs indicate if a CI has an active, pending issue. You can investigate the tasks that are connected to a CI to get more details. The map collapses and expands clusters to make them easier to view.
This is graphical representation of CI representing the upward & downward connections. At the top there are multiple options to change the layout:
Options for details & setting are also available which can be used to gather or view the details of corresponding CI.
User can add a new relationship to the CI from this view also. Click on the arrow shown beside the CI & user will see option to add relationship , click on it & add the CIs.
CHANGING CI CLASS
Reclassify a CI by modifying its ‘Class’ attribute. You can upgrade, downgrade or switch a CI’s class. When downgrading or switching a CI’s class, attributes that are unique to the current class, and are not defined in the newly reclassified class – are lost.
Each class in the class hierarchy is defined with a unique set of attributes. This set consists of attributes that were inherited from the parent class, and additional attributes specifically defined for the class. When you reclassify a class:
- The set of attributes is adjusted to match the set of attributes of the newly assigned class. Attributes are added or removed as needed.
- A new record, with the CI’s sys_id, is inserted to the table of the new class, with the appropriate set of attributes for the class.
More specifically, depending on the reclassification that you chose:
- Downgrade : The newly assigned class is a parent of the current class, and has less attributes than the current class. For example, reclassifying a CI from the cmdb_ci_server class to the cmdb_ci_computer class.
- Upgrade: The newly assigned class is a derived child of the current class and has additional attributes. For example, reclassifying a CI from the cmdb_ci_computer class to the cmdb_ci_server.
- Switch: The newly assigned class is in a different branch in the class hierarchy and has a different set of attributes than the current class. For example, reclassifying a CI from the cmdb_ci_linux_server class to the cmdb_ci_win_server class.
In the example above for a reclassification downgrade, the cmdb_ci_server class has attributes that the cmdb_ci_computer class does not have. During the downgrade, these attributes and their respective values are not included in the new CI record that is inserted into the cmdb_ci_computer class.
A switch is a combination of a downgrade and an upgrade. In the example above for a switch, the CI is downgraded to the cmdb_ci_server, and then upgraded to the cmdb_ci_win_server class. Therefore, attributes are lost in the same manner that they do in a downgrade operation.
- Locate the CI that you want to reclassify. For example, if the CI is a server, then in the navigation search box, type cmdb_ci_server.list to display the CI in the Servers view.
- Ensure that the Class attribute is displayed in the view. Use Personalize List to personalize the view if you need to.
- Locate the CI that you want to reclassify, and click on the Class value of the CI.
- Select the class that you want to reclassify the CI to, and click the green check box to confirm the change request.
In a downgrade or a switch reclassification, some CI data might be lost.
The final step in setting up for configuration management is populating the CMDB with information. This involves creating records for each configuration item on the cmdb_ci tables or on one of the tables which extend it. There are many ways to populate the CMDB:
- Using an automated Discovery product
- Importing the information from another source
- Integrating with existing external CMDBs
The Discovery product is an extension to the ServiceNow platform that automatically populates the CMDB. Discovery uses a MID Server installed on the network to send out probes and sensors and collect information on hardware on the network, software running on that hardware, and the relationships between all of the items found. This information is sent back to the instance, and is used to populate the CMDB.