Service Asset and Configuration Management

Configuration Management is the process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships.

Much of the advanced ITIL Configuration Management activities in Ivanti Service Desk rely on linking your CIs into Structure diagrams, on versioning, and on Managed Versioning (managing CI data and versions from Change processes). To enable this behavior, you must have the Ivanti Configuration Manager component of Service Desk.

For more information about using the Configuration Manager component, see Configuration Items.

Naming CIs

When you design your CI windows and attributes, remember that the CI Name attribute must be unique. With IT equipment this is rarely an issue, but if you already provide asset-tagging of all IT equipment then this Tag or Asset ID could be a logical choice of attribute to use to define your CIs. However, remember that if you import this data, the unique identifier must also exist in the source of the data being imported.

Do not use IP addresses as your unique name for a CI. Although IP addresses are unique, they are often dynamically allocated.

When creating CIs, either manually or from imports, the naming and format conventions set on the CI are enforced. By default this includes the unique CI Title. Duplicate CIs cannot be created in the CMDB. CIs are, by default set to have soft-deletion, therefore even if a CI is deleted a record of it (and its unique name) still persist in the database, this means that a new CI with the same name can still not be imported.

Typically, existing CIs are discovered using third party discovery tools and imported into Service Desk using the Data Import component. These act as your baseline for future management of the CIs through Change and Release Management. If you place any attributes under Managed Change Control, do not update them through importing after the baseline has been taken.

Availability Status for CIs and Services

Service Desk provides a range of ways to track and present the current status of CIs and Services for both IT staff and customers. The simplest approach is to add a reference list to your CI window, providing a dropdown list of Service Status values (Available, Impacted, Unavailable, Withdrawn, and so on). You can then change these statuses manually when required.

Alternatively, you can change this value automatically from within other processes. You could use a Change process, for example, to set the status of a Service or CI automatically when it is created or resolved.

In both cases, you can design Report Templates in Object Designer to enable you to present attractive and informative Service Status displays in Web Access. For example, you could create a query that used a Report Template so that end-users can see a list of services with icons representing their current status, driven by the status value on the CI.

See also Service Portfolio Management for information about how you can link the Service Lifecycle status to a Service CI.

Vital Business Services

You may choose to indicate that your Services or CIs have a vital business function. Add a boolean checkbox to the Service or CI window to indicate this. Consider also using the different relationship types in the CI structure component to highlight with a different color those CIs or Services that have a vital business function.


If you choose to follow ITIL guidelines and specify baseline versions of CIs, you can either add a dropdown list of Version Type to your CI, or enable version control and use the standard Description field to describe whether a version is a baseline.


Previously described in ITIL v2 as the Definitive Software Library, if you are following the ITIL v3 guidelines you can keep a track of your source master media within the Service Desk CMDB by defining a Definitive Media Library (DML). This is a grouping of CIs, with one for each definitive source. Typically these are grouped in a CI structure, although using a checkbox (in DML) and a simple query (DML) can also provide this view.

Complex/Component CIs

You may want to build complex CIs that comprise a number of linked CIs. As with many areas in Service Desk, there are different ways to approach this, one of which is described below.

To set up complex/component CIs:
  1. Use the CI Structure component to link your CIs together with relationships.
    The links in the diagrams are real data relationships, and joining CIs in a diagram also joins them together at a data level.
  2. Use the CI Relationship Types tree in the CI Structure component to create new relationship types for different types of linking.
    You can set CI versioning to be manual or automatic on any CI type. If you require both the components and the parent CI to be versioned, use Managed Versioning. This automatically sets a version number on a CI when the Commit action is used in a Change process.
  1. To increment component version numbers, include two Add Configuration Item actions to your Change process, so that both the parent CI and the child are selected and managed. To do this when prompted by the Change process, click Add Configuration Item and select the parent CI. When then prompted to select the child by the process, click Add Configuration Item and select the child.

Viewing affected Services from a CI window

You can view the related CIs and Services from a Configuration Item window by right-clicking the CI window then clicking Impact Analysis. This is possible only if the Impact Analysis option is made available on that window.

Development Environments

If you are managing Development and Live environments in your CMDB, then there are two recommended options to track whether a CI is in LIVE or DEV usage:

Reporting on Configuration Items

You can report on various aspects of your CMDB using the reporting capabilities in Service Desk. Some useful reports to run are:

RFCs by CI – build a query on the Change Configuration Item object and group it by CI. This will list all of the changes associated with the various CIs.

Failing CIs – build a query over the CI object and filter it by those at the unavailable status.

All CIs – build a query over the CI object and filter by those that are not soft-deleted.