CMDB configuration
from scratch - complete guide

If someone asked you today "How many SQL Server licenses do you have? Does server APP-01 talk to database PROD-DB? Where is the network switch for the data center?", and you would answer by searching through emails, Excel files and notes scattered across desks - then a CMDB (Configuration Management Database) is for you. The CMDB is a database of every IT asset in the organization - servers, laptops, software, licenses and the relationships between them. In this article I will show you how to build a CMDB from scratch: planning the structure, importing data, configuring relationships and integrating with the help desk.

What is a CMDB and why do many companies not have one?

The CMDB is the single source of truth for the entire IT infrastructure. It contains everything you have:

• Hardware: servers, laptops, switches, routers, printers, storage
• Software: operating systems, applications, middleware, databases
• Licenses: who has permissions, how many licenses are available, expiry date
• Contracts: service, warranty, hardware SLA
• Relationships: server A serves application B, which uses database C, which runs on hardware D

Question: why do many companies still not have a CMDB?

• Belief that it is too hard: "Building a CMDB is a 6-month project". The truth: a 2-4 week project with the right approach.
• No data to import: "We have no data to start from". Spreadsheets are scattered across desks - the data is there, you just have to collect it.
• Fear of change: "A CMDB change = a help desk change = chaos". No change = chaos already, today.
• Inertia: IT works ad-hoc, without a process. A CMDB enforces a process - and that means changing habits.

CI types (Configuration Items) - what to inventory?

Every element in the CMDB is a CI (Configuration Item). You have to decide which CIs are important to you.

Mandatory CIs (Tier 1) - start here

• Servers (Physical & Virtual)

  Every Windows or Linux server, physical or VM. Attributes: hostname, IP, OS, RAM, CPU, order date, business owner, hardware SLA.

• Business applications

  ERP, CRM, HR, email, accounting systems. Attributes: name, version, vendor, license number, support date, process owner, application SLA.

• Databases

  SQL Server, PostgreSQL, Oracle, MongoDB. Attributes: DBMS type, version, database (which databases?), backup SLA, recovery time, data owner.

• Network devices

  Switches, routers, firewalls, load balancers. Attributes: model, IP, location, availability SLA, owner.

Second priority CIs (Tier 2) - add after Tier 1

• Laptops and workstations
• Licenses (software)
• Service contracts
• Storage (SAN, NAS)
• Backup systems

Third priority CIs (Tier 3) - if time permits

• Printers
• Monitors
• Keyboards, mice
• Teams/departments (for business relationships)

Relationships between CIs - how to map dependencies?

A CI without relationships is just a number in the database. A CI with relationships = a map of the infrastructure. A relationship is a link between two entities: A supports B, A depends on B, A talks to B.

Example relationships (for a typical IT stack)

ERP Application (CI)
  ↓ runs on
Server APP-01 (CI)
  ↓ connects to
SQL Server 2019 (DBMS) on SRV-DB-01 (CI)
  ↓ backup to
NAS Storage (CI)

User (CI)
  ↓ uses
Dell XPS Laptop (CI)
  ↓ needs
WiFi 5GHz (Infrastructure CI)
  ↓ on
Switch SW-01 (CI)
  ↓ powered by
UPS Unit-A (CI)
    

The map shows: if SRV-DB-01 goes down → ERP goes down → tens of users go down. That is why you need monitoring and a fast repair SLA on the database.

Automatic import - network discovery

Instead of entering every server manually, the system automatically scans the network and finds the devices. That is discovery.

Discovery methods

• Network Scan (SNMP, WMI): the system pings the 192.168.0.0/24 network, collects active devices (servers, switches, printers) - about 60-70% of CIs.
• Agent-based Discovery: install an agent on every Windows/Linux server - gives detailed OS, application and license data - about 80-90% of CIs.
• API Integration: connect ManageEngine to vSphere (VMware), Hyper-V, AWS - automatically pull VM and instance data - about 95% of CIs for VMs.

Step by step: Discovery in Endpoint Central (or ManageEngine SDP Enterprise)

1. Admin → Discovery → New Discovery Task
2. Pick the method: Network Scan vs Agent-based
3. Set the scope: 192.168.0.0/24 network or all servers from Active Directory
4. Run discovery - the system scans, collects data, imports into the CMDB
5. Validate: review the proposed CIs, remove duplicates, fill in missing attributes manually

CMDB in ManageEngine SDP - step-by-step configuration

ServiceDesk Plus Professional and higher include a CMDB. Here is the database configuration.

Step 1: Defining CI types (CI Class)

1. Admin → CMDB → CI Class → New CI Class
2. Give it a name (e.g. "Server", "Database", "Application")
3. Add attributes for each type:
   • Server: hostname, IP, OS, RAM, CPU, location, owner, SLA
   • Database: DBMS type, version, databases (list), backup time, RTO/RPO
   • Application: name, version, vendor, license key, support date, owner
4. Save - the CI type is ready to use

Step 2: Adding CIs (configuring elements)

1. CMDB → Create → New CI
2. Pick a CI Class (e.g. Server)
3. Fill in the data:
   • Name: PROD-SQL-01
   • IP: 192.168.1.50
   • OS: Windows Server 2019
   • RAM: 32 GB
   • CPU: 16 cores
   • Location: Datacenter-1, Rack-5
   • Owner: Database Team
4. Save - the CI is in the database

Step 3: Defining relationships between CIs

1. CMDB → Relationships → New Relationship
2. Relationship 1: App ERP → runs on → Server PROD-APP-01
3. Relationship 2: Server PROD-APP-01 → connects to → Database PROD-SQL-01
4. Relationship 3: Database PROD-SQL-01 → backed up to → NAS Storage

CMDB integration with the help desk - practical use

A CMDB without the help desk = an archive. A CMDB linked to the help desk = a tool that saves time.

Scenario 1: Technician opens a ticket

Technician: "Server PROD-SQL-01 is not responding". In the ticket form:

1. Automated lookup: the system finds CI "PROD-SQL-01" in the CMDB
2. Sees the data: Owner = Database Team, SLA = 4h, Database = PROD-ERP.db (important database!), 500 users depend on it
3. Priority automatically set to CRITICAL - because 500 people depend on it
4. The technician immediately knows who to call (Database Team) and what the expectations are (4 hours to repair)

Scenario 2: Outage impact reporting

A manager asks: "How long was yesterday's ERP outage?" The system automatically shows:

• Outage duration (e.g. 12:00-12:45)
• Root cause (e.g. no disk space on PROD-APP-01)
• Number of users that depend on ERP - based on CMDB relationships

Example: assume an ERP outage of 45 minutes, with 500 users depending on it. Multiplying downtime by the number of affected people and an approximate cost of working time, you can estimate the scale of business loss - the exact figure depends on the rates in a given company. Such a report helps justify investment in better infrastructure, because IT shows the business impact of outages.