SHOW ALL CONTENT

Introduction

The Configurations module, also known as CMDB, constitutes the core of Octopus, in the sense that the CIs can be linked to all other modules.

We identify the CI impacted in an incident, the CI related to an event, we link CIs to a service request, a problem or a change, covered CIs are included in service contracts or lease contracts, we can identify the users use a CI, we organize the maintenance of the CIs in planned requests, in short.... they are everywhere.

That's the reason why they contribute actively to evaluate situations, impacts and to identify strengths and weakness in the infrastructure.

Implement and Maintain the CI Configuration

Once the creation of the CIs in the configuration module is completed, the main challenge is to maintain the configuration of these CIs.

That's why we recommend doing an analysis of the information that is really needed before adding it. Because often, the tendency is to add any information available without taking the time to ask if it has value. So it's good when you have the opportunity to step back and plan what you want to do with the CMDB.

Questions to ask can be:

What types of CI are we responsible for?
For each type of CI, what information and attributes are needed?
- The level of information is not the same from one element to another.
Are we in control of the information on these CIs?
- Because if we do not have access to information, it will be difficult to build and maintain the CMDB for these elements.
Who is responsible for collecting the information?
Who is responsible for updating?
How are we planning to check this information to make sure it is up to date?

You need to understand that setting up and then updating this information is time consuming and can be tedious, so you have to make sure that what you keep is worth it.

Recommandations

Start by defining a clear structure for the Configurations module. This includes CI types, available attributes, authorized relations, required statuses and any other information useful in CI management.
Revise the permissions given to the roles in order to apply security for adding, modifying or removing CIs.
- See the Role management article.
Train the resources and make them aware of the importance of maintaining the configuration of all implicated CI in the request where they are linked and explain the consequence of neglecting it.
Document the procedure based on the different roles.
- It could be different for the Service Desk, the technicians and the system administrators.
Identify a resource to act as a watchdog for the configurations - otherwise, time and in general the argument of "running out of time" will bring down the quality of the information.

Update

In certain cases, updates can be automated but sometimes data will need to be modified manually to ensure data integrity and accuracy.

Keeping these points in mind will be helpful:

Aim for simplicity - manage only configurations that are required for service delivery.
Be rigorous - each CI linked to a request must be updated as they are being used.
Verify - only authorized CIs are included in the CMDB and their configuration must be up to date.

The goal is to be able to find the required information and be confident that it is up to date.

Automated Update

Asset and configuration imports in the Octopus module can be done using Octopus tools and automated updates managed by Windows planned tasks.

The method to use depends on the available source and a combination of different sources is possible.

ADSIReader : Imports the computer names the Workstation CI type.
- After, you will need to readjust the right CI type (server, laptop, etc.).
- Consult the ADSIReader - Impacts on computer asset management article which presents the different scenarios which you will be faced with.
WMIUpdater : Updates the technical configuration of computers including: operating system, memory, processor type, installed software, etc.
DataImporter : Imports data from external systems using and ODBC link

In the configuration of CI Types, we specify in the Configuration tab if the type is a computer, meaning that it can be inspected using WMI in Octopus. In the Attributes tab, we can add some attributes generally considered for a given CI. Those attributes will be loaded automatically when the Windows task launches WMIUpdater.

Consult the ADSIReader - Impacts on computer asset management article for detailed usage.

Take some time to identify your sources and to select the ones with quality data. Whatever effort you put in your imports if the data source is wrong, it will import garbage into Octopus and if you modify it, it will be reimported again at the next import. It is therefore essential to update the systems from which you gather your information.

Manual Update

In an ideal world, we would like to automate all the updates of a CMDB and not manage it afterwards, but that is not the reality. Of course we will try to maximize automation, especially for those who do not require human intervention at the source and reduce as much as possible manual inputs to optimize the content of the CMDB. But there are some areas more at risk and these are the ones where humans intervene. Either in Octopus or in external systems linked to Octopus.

It is the reason why we recommend to not include all possible CI attributes in order to avoid micromanagement of the infrastructure.

At first, the temptation is high to centralize everything in the Configurations module, but it is important to understand the consequences of such an approach:

There is no added value for the organization - Follow and measure only what is necessary in the delivery of the service to the users.
The enthusiasm quickly faints: resources get discouraged in front of the task which takes time and causes the CMDB to lose integrity and accuracy
The cost of maintaining CIs increases because the manual update of CIs requires more time and quality control is more complex compared to the benefits.

It is by leveraging resources that we are able to maintain the CMDB at a level that meets the needs. They are the ones who intervene in the requests and they are the ones who can report errors in the data imported from external systems.

Establish clear procedures on the subject. A simple example could be an error in the last name of a user, if Octopus is linked to an HR system, the correction will need to be done in this system.

An proper and reliable CMDB benefits everyone, improves every day life, and extracts reliable data for analyzes that help inform decision-making.

Worth the Effort

The efforts in building and maintaining the CMDB are beneficial in many aspects :

Proper evaluation of impacts during an outage or to plan changes.
Establishing budgets for asset replacement.
An updated inventory - know where your assets are and who is using them.
Control of authorized software
Possibility to centralize policies, procedures, processes and any other documentation useful to users such as guides, in the CMDB
Audits made easier with the availability of the data
And much more!

Continuous Improvement

We recommend that you review the CMDB management on a regular basis.

As the evolution of information linked to CIs is constant, as well as the needs for this information we can consider the CMDB as a living organism that we must know well and take care of.

The review should cover the following elements:

Has an audit or a check been done since the last time?
- What did we find?
Do people find the information they need?
Is the information up to date?
Is some information missing?
On the contrary, are some information not used or no longer useful?
- If a CI type or CI attribute is no longer used or ultimately has no value, there is no point in continuing to update it.
Is the process always clear to all?
- If new employees were added to the team, do they know the roles and responsibilities of each one in relations to the CMDB?
Etc.

Maintaining the configuration of a CI

Table of contents

Related articles