From 19da72b7dcd19d01032611a842135970d46c1ead Mon Sep 17 00:00:00 2001 From: weishen Date: Sat, 19 Sep 2026 15:38:47 +0800 Subject: [PATCH] Add course notes: ServiceNow CMDB Fundamentals 2026 (22 videos, 3 chapters) --- .../ServiceNow-CMDB-Fundamentals-Notes.md | 805 ++++++++++++++++++ 1 file changed, 805 insertions(+) create mode 100755 knowledgebase/course-notes/ServiceNow-CMDB-Fundamentals-Notes.md diff --git a/knowledgebase/course-notes/ServiceNow-CMDB-Fundamentals-Notes.md b/knowledgebase/course-notes/ServiceNow-CMDB-Fundamentals-Notes.md new file mode 100755 index 00000000..53affa33 --- /dev/null +++ b/knowledgebase/course-notes/ServiceNow-CMDB-Fundamentals-Notes.md @@ -0,0 +1,805 @@ +# Configuration Management Database (CMDB) Fundamentals +# Course Notes (structured from transcripts) + +Source: /Users/weishen/mnt/volume2/knowledgebase/course/Pluralsight.Configuration.Management.Database.CMDB.Fundamentals.2026.BOOKWARE-GETH +Generated: 2026-09-19 +Note: 22 video transcripts across 3 chapters. Instructor: Ramiz. Pluralsight 2026. + +--- + +## Chapter 1 — 01. Course introduction + +**Core Insights** +- CMDB solves the problem of configuration data scattered across spreadsheets, ticketing systems, and outdated documentation. +- The CMDB is positioned as the backbone of modern IT operations: faster incident management, safer change management, and real IT visibility. +- A neglected CMDB turns change management into guesswork and makes impact analysis impossible. +- The course is structured in three modules: foundation (Module 1), hands-on building (Module 2), and ongoing quality/governance (Module 3). +- Target outcome: ability to understand, build, and maintain a CMDB that genuinely supports IT operations. + +**Detailed Notes** +*Course Motivation* +- IT teams lack a clear picture of what is running and how everything connects when incidents occur or changes go wrong. +- ServiceNow CMDB is presented not as a nice-to-have but as a foundation for incident, change, and visibility. + +*Course Roadmap* +- Module 1 — What the CMDB is, why it matters to ITSM, and the real benefits of maintaining it well. +- Module 2 — Hands-on: creating CIs, defining relationships, populating the CMDB with different methods, building a working configuration database. +- Module 3 — Ongoing work: monitoring CMDB quality, fixing common data issues, implementing governance for long-term reliability. + +**Action Items** +- List where configuration data currently lives in your organization (spreadsheets, ticketing, docs) to scope the CMDB problem. +- Map the three-module structure onto your learning plan before starting hands-on lab work. + +**Key Terms/Concepts** +- **CMDB (Configuration Management Database)**: central repository of IT configuration data; the single source of truth for what is running and how components connect. + +## Chapter 1 — 02. What is the CMDB in ServiceNow + +**Core Insights** +- The CMDB is a centralized repository — a master inventory of configuration items (CIs) such as servers, databases, applications, network switches, and printers. +- In ServiceNow everything lives in the base table `cmdb_ci`; specialized tables (server, database, application) inherit from it. +- The CMDB's power is in relationships: it maps how components connect, turning raw data into intelligence (e.g., server ABC hosts app XYZ, connects to DB 123). +- The CMDB is dynamic — it should reflect real-time infra changes, showing what is actually running, not what should be running. +- CIs carry essential attributes (name, manufacturer, vendor, location, operational status) that tell the story of each asset. + +**Detailed Notes** +*What Counts as a CI* +- Any part of IT infrastructure with relationships to other components qualifies — servers, databases, switches, applications, software, even printers. + +*Table Architecture* +- `cmdb_ci` is the core base table where all CIs live; child tables like `cmdb_ci_server`, `cmdb_ci_database`, `cmdb_ci_application` branch from it. + +*Three Pillars of Value* +- Centralized: one place instead of per-team spreadsheets — answering questions doesn't require pinging five people. +- Relationship-aware: spreadsheet says a server exists; CMDB says what it hosts, connects to, which licenses it needs, its team, and which services break if it goes down. +- Dynamic: reflects constant provisioning, retirement, and configuration shifts. + +*Cost of Neglect* +- Outdated CIs and missing relationships make change management a guessing game, lengthen incident resolution, and break root-cause analysis — inefficient and dangerous. + +**Action Items** +- Inventory your key CI types and verify they could be modeled under the `cmdb_ci` hierarchy in ServiceNow. +- For one critical server, write out its full relationship map as a warm-up exercise for CMDB modeling. + +**Key Terms/Concepts** +- **Configuration Item (CI)**: any component of IT infrastructure worth tracking in the CMDB. +- **Base table (cmdb_ci)**: root table from which all CI classes inherit. +- **Relationship**: documented connection between CIs that enables impact analysis. +- **Single source of truth**: one authoritative, accurate record of infrastructure configuration. + +## Chapter 1 — 03. Demo Understanding the CMDB interface + +**Core Insights** +- The CMDB application in ServiceNow is organized into modules for management, health, and data exploration. +- Management modules: CMDB 360 query schedules, Class Manager (class hierarchy, identification and reconciliation rules), Groups, Query Builder, Health Preferences, Remediation, Reports, and Exclusion List. +- Health visibility: the CMDB Health Dashboard measures completeness, correctness, and compliance. +- Category modules (application server, servers, clusters, database, network) list specific CI types; clicking a record opens the full CI with attributes. +- The Exclusion List prevents specific items from being created/updated as CIs — commonly paired with Discovery. + +**Detailed Notes** +*Management Modules* +- CMDB 360 query schedules: scheduled queries for a 360-degree view of a CI across the CMDB. +- Class Manager: centralized management of class hierarchy, identification rules, and reconciliation rules. +- CMDB Groups: logical grouping of CIs for management, reporting, and access control. +- Query Builder: build complex queries spanning multiple CI classes and relationships without code. +- Health Preferences: settings driving how CMDB health is measured. +- CMDB Remediation: track/manage actions fixing data quality issues. +- Reports: pre-built reports for visibility into CMDB data. + +*Health and Data Modules* +- Health Dashboard shows visual metrics of completeness, correctness, and compliance. +- Category modules such as application server, servers, clusters, database servers, database instances, and network group related CI types; e.g., network groups different network device types. +- Opening a category (e.g., database) shows the CI list; clicking through opens the CI record with all attributes. + +**Action Items** +- In a personal developer instance, navigate to Configuration and click through each module once to build spatial memory of the interface. +- Open the Class Manager and review the identification/reconciliation rule options available by default. + +**Key Terms/Concepts** +- **Identification rule**: logic that decides whether a discovered item matches an existing CI or creates a new one. +- **Reconciliation rule**: logic resolving attribute conflicts between data sources. +- **Exclusion List**: items blocked from being created/updated as CIs. +- **CMDB Health**: measurement of data completeness, correctness, and compliance. + +## Chapter 1 — 04. CMDB and ITSM process integration + +**Core Insights** +- The CMDB is the thread tying incident, problem, change, and asset management together. +- Incident management: linking an incident to a CI instantly reveals dependencies, downstream systems, and impacted users — cutting investigation time from ~30 minutes to seconds. +- Problem management: relationship data turns five seemingly unrelated incidents into an obvious pattern pointing to a common root cause. +- Change management: impact analysis shows the blast radius (dependent apps, downstream risk) before approval — without it, change management is guesswork. +- Configuration data flows both directions: executed changes update the CMDB (patches recorded, retired apps marked inactive, new databases added). + +**Detailed Notes** +*Incident Management* +- First step on an incident (e.g., slow accounting app) is linking it to the relevant CI — the app itself or its hosting server. +- From the CI, teams see what depends on it, what databases feed it, and what systems are downstream. + +*Problem Management* +- Five incidents sharing a cause (e.g., a failed network switch) become visible as one pattern via relationship data, enabling root-cause analysis and preventing cascading failures. + +*Change Management* +- Before approving a change (e.g., patching a DB server), the dependency map shows affected applications and the full impact chain. +- Data-driven scheduling, testing, and stakeholder notification replace guesswork. + +*Bidirectional Flow* +- Changes feed back into the CMDB: patches, retirements, and provisioning keep records current. + +**Action Items** +- For each incident template in your org, define which CI linkage should be mandatory. +- Draft an impact-analysis checklist for change requests that queries the dependency map before approval. + +**Key Terms/Concepts** +- **Affected CI**: configuration items directly impacted by an incident. +- **Blast radius**: the set of downstream components at risk when a change is applied. +- **Impact analysis**: evaluating consequences of a change using CMDB relationships. + +## Chapter 1 — 05. Demo Incident linked to CMDB + +**Core Insights** +- Incidents carry two distinct tabs: Affected CIs (directly impacted, being worked on) and Impacted Services/CIs (downstream business services affected via relationships). +- Affected CI lists speed resolution — technicians know exactly which systems are involved with no guessing or email chasing. +- Repeated appearance of the same CI across incidents is a strong signal for problem management root-cause analysis. +- Impacted services give a service-centric view that drives prioritization, SLA tracking, customer communication, and major incident decisions. +- Clicking a CI (e.g., SAP App SRV01) opens the full CI record with attributes and a related-items dependency list — the link between incidents and the rest of ITSM. + +**Detailed Notes** +*Demo Walkthrough* +- Navigate to Incident → Open, select an incident, and review standard fields: short description, caller, priority, assignment group, state. +- The Affected CI tab lists CIs directly involved in the incident; the Impacted Services/CIs tab shows downstream business services derived from CMDB relationships. + +*Value to Roles* +- Incident resolution: immediate identification of the affected server, application, or database. +- Problem management: pattern detection when the same CI recurs across incidents. +- Management: a service-centric view — seeing degraded business services, not just a broken server. + +*CI Record Drill-Down* +- Clicking SAP App SRV01 opens a server CI showing name, class, operational status, owner, location, and related items with all dependencies. + +**Action Items** +- Standardize the practice of always linking incidents to affected CIs in your instance. +- Build a recurring report of top CIs by incident count to surface potential problems early. + +**Key Terms/Concepts** +- **Affected CIs tab**: CIs directly impacted and under investigation for the incident. +- **Impacted Services/CIs tab**: downstream services and CIs affected as a consequence, derived from CMDB relationships. + +## Chapter 1 — 06. Benefits of a well-maintained CMDB + +**Core Insights** +- Operational benefits: faster incident resolution, outage prevention via single-point-of-failure discovery, and higher change success rates. +- Strategic benefits: infrastructure-wide visibility enables cost savings (retiring redundant apps, capacity optimization), true service dependency mapping, and data-driven strategic decisions (cloud migration, consolidation). +- Governance benefits: compliance audits, risk identification (unsupported OS, end-of-life apps), and organizational accountability through CI ownership. +- Prevention is cheaper than firefighting — reinforcing critical paths before they break. +- The real value isn't what you spend on the CMDB; it's what you save: time, money, effort, and risk. + +**Detailed Notes** +*Operational Benefits* +- Incident resolution: teams instantly see context, dependencies, and impact from the affected CI. +- Outrage prevention: accurate relationships reveal hidden vulnerabilities and single points of failure. +- Change success: better planning, testing, and communication raise change success rates and cut production incidents. + +*Strategic Benefits* +- Visibility/optimization: answer which servers are underutilized, which apps are redundant, where investment is over-concentrated. +- Service dependency mapping: surface hidden chains (e-commerce → server C → SAN → network segment; financial system outage blocks payments). +- Strategic decision making: answer cloud migration, app migration, and data-center consolidation questions with data. + +*Governance Benefits* +- Compliance: audit trail proving what runs in the environment for regulated industries (healthcare, finance, government). +- Risk management: flag unsupported OS, end-of-life applications, compliance gaps, lifecycle risks. +- Accountability: CI owners, tracked changes, documented relationships make people take better care of owned infrastructure. + +**Action Items** +- Run a report to identify single points of failure in your critical service paths. +- Create a compliance query flagging CIs on unsupported OS versions or past end of life. + +**Key Terms/Concepts** +- **Single point of failure**: a CI whose outage breaks critical services and has no redundancy. +- **Service dependency mapping**: documented chain of how business services are constructed from underlying CIs. +- **Configuration baseline**: snapshot of configuration at a point in time used for change impact and compliance. + +## Chapter 1 — 07. CMDB terminology and ITIL evolution + +**Core Insights** +- Configuration management is a discipline, not just a database: identifying, tracking, and maintaining CI information involving people, tools, and governance. +- Attributes (name, vendor, serial, location, status) make a CI valuable; relationships (runs-on, connects-to) are typed and drive impact analysis. +- CI classes form an inheritance hierarchy rooted at the base CMDB CI table; server CIs inherit base attributes plus server-specific ones (CPU, RAM, OS). +- The CMDB originates from ITIL, which defined configuration management in the 1980s; ServiceNow's CMDB is built on ITIL principles. +- ITIL process parts: planning, identification, control, verification/audit — with supporting concepts like configuration baseline and release management. + +**Detailed Notes** +*Core Terminology* +- Configuration items: the entities themselves. +- Configuration management: the whole process discipline of identifying, tracking, and maintaining CI info. +- Attributes: fields in a CI record; value comes from completeness and accuracy. +- Relationships: typed connections (e.g., app runs-on server, server connects-to switch) that matter for impact analysis. +- CI class structure: hierarchy with base `cmdb_ci` table and subclasses (server, database, application) inheriting attributes. + +*ITIL Evolution* +- ITIL (Information Technology Infrastructure Library) is the world's widely adopted ITSM framework; it defined the CMDB concept in the 1980s. +- Process steps: planning (what to track and why), identification (register CIs with attributes/relationships), control (keep CMDB updated as infra changes), verification and audit (regularly confirm CMDB matches reality). +- Configuration baseline: a point-in-time snapshot (e.g., production as of March 1st) for change impact and compliance. +- Release management: deploying a new app version is a release; the CMDB records it and captures dependency shifts. + +**Action Items** +- Define your tracking strategy first: decide which CI classes matter before populating anything. +- Set up a recurring verification/audit cadence so the CMDB is checked against reality. + +**Key Terms/Concepts** +- **ITIL**: Information Technology Infrastructure Library, the widely adopted ITSM framework. +- **Configuration baseline**: snapshot of configuration at a specific point in time. +- **Identification**: registering CIs with attributes and relationships. +- **Control**: ensuring the CMDB is updated when infrastructure changes. +- **Verification and audit**: periodically confirming CMDB accuracy against reality. + +## Chapter 1 — 08. Demo CMDB in action + +**Core Insights** +- `cmdb_ci.list` is a quick navigator shortcut to the CMDB table; the demo instance holds 2,786 CIs (real orgs often have tens to hundreds of thousands). +- Grouping CIs by class reveals how ServiceNow organizes infrastructure logically (AIX servers, applications, clusters, databases, email servers, IP routers, etc.). +- A CI record has identification fields (name, asset tag, manufacturer, serial, model), configuration details (device type, IP, location, port), and a related-items section listing typed relationships (depends on/used by, member of). +- The Dependency View renders the whole topology as an interactive map with layouts (vertical, horizontal, radial, force, groups) and filters (dependency depth, CI type, manufacturer). +- The ITSM bridge: an incident's impacted service (SAP Enterprise Service) opens a dependency map showing five related incidents and a linked problem record — a strong root-cause signal connecting CMDB to incident and problem management. + +**Detailed Notes** +*CMDB Table Walkthrough* +- Navigate via `cmdb_ci.list`; columns include name, manufacturer, location, description, class, updated, maintenance schedule. +- Grouping by class shows the logical organization of infrastructure in the instance. +- Drilling into an IP router CI: identification fields at top; configuration details (device type, IP address, location, port, channel, firmware manufacturer) below; related items at bottom with depends-on/used-by and member-of relationships. + +*Dependency View* +- Visualizes topology as a map instead of relationship lines; layout options adapt the view to the analysis goal. + +*ITSM Integration* +- Opening an incident shows affected CIs and impacted services; the impacted service is SAP Enterprise Service. +- From the incident's dependency map, details reveal five incidents reported against the CI — the incident manager sees isolated vs. systemic issues; the problem manager sees a root-cause signal. +- A linked problem record shows the team already investigating the recurring issue; filters narrow the view by dependency level, CI type, or manufacturer. +- Real-world pattern: see the CI, see dependencies, link to incidents and problems, drive faster resolutions — used in banking, telecom, healthcare, manufacturing. + +**Action Items** +- Practice navigating with `.list` shortcuts to reach CMDB records quickly. +- Use the dependency view's filters to build reusable views per service for impact analysis. +- Configure a monitoring pattern: repeated incidents on one CI should auto-flag for problem management. + +**Key Terms/Concepts** +- **Dependency View**: interactive topology map of a CI's relationships with multiple layouts and filters. +- **`.list` shortcut**: navigator syntax (`table_name.list`) jumping straight to a table's list view. +- **Impacted service**: business service degraded as a downstream consequence of an incident. + +--- + +## Chapter 2 — 01. CMDB data model and CI class structure + +**Core Insights** +- The CI class hierarchy is the blueprint of the CMDB: every configuration item inherits from a single base table, `cmdb_ci`. +- Inheritance makes the data model scalable — base attributes (name, short description, operational status, discovery source) apply to all CIs, while specialized child classes add type-specific attributes (CPU/RAM for servers, database-specific fields for databases). +- There is no single "correct" CI scope; organizations must decide which CI types to track based on needs and governance strategy. +- ServiceNow allows extending the hierarchy with custom CI classes, but flexibility demands governance or the CMDB becomes messy and inconsistent. +- Design CI classes with consistency, completeness, and scalability in mind; getting the structure right first prevents months of data cleanup later. + +**Detailed Notes** +*The Inheritance Model* +- `cmdb_ci` is the parent/base table; every CI record traces back to it. First-level specializations include database, server, application, and computer categories. +- Child tables inherit all parent fields and add their own specialized attributes — same structure, different detail per class. +- Example path in ServiceNow: Server → Computer → cmdb_ci. + +*CI Planning (part of ITIL configuration management)* +- Before creating CIs, define: which infrastructure types to track, which attributes matter per type, and who owns maintenance of each type. +- Scope decisions vary: some orgs track every device (printers, switches, UPS), others stay business-centric (servers, databases, applications). + +*Governance Principles* +- Consistency: a server CI should look like every other server — same attributes, naming, relationships. +- Completeness: capture what you need to know (e.g., tracking servers without OS is a critical gap). +- Scalability: the structure must accommodate new infrastructure types without breaking. + +**Action Items** +- Document a CI class plan before building: list tracked types, mandatory attributes, and data owners. +- Enforce naming conventions and standard attributes per CI class across all creating teams. +- Review the out-of-box class hierarchy and only create custom classes where a genuine gap exists. + +**Key Terms/Concepts** +- **CI class structure**: The inheritance hierarchy of tables defining what attributes and behavior each configuration item type has. +- **cmdb_ci (Configuration Item base table)**: The root table all CI records inherit from, holding universal attributes. +- **Inheritance**: Child tables automatically receive all parent fields and add type-specific fields. +- **CI planning**: The ITIL-aligned activity of deciding what infrastructure to track and how. + +## Chapter 2 — 02. Demo Exploring CI class structure in ServiceNow + +**Core Insights** +- The CMDB is not one table — it is an ecosystem of thousands of tables, each storing a specific type of configuration data. +- All CI tables inherit from the single root base table `cmdb_ci`; this was demonstrated live on a ServiceNow personal developer instance. +- Grouping tables by their "extends table" column reveals the parent–child hierarchy behind the scenes. +- Structural changes made at the base table level propagate automatically to every CI class in the CMDB. + +**Detailed Notes** +*Navigating the Table Landscape* +- Filter Navigator → Tables; the demo instance contained 6,207 total tables, each like a spreadsheet with defined columns and rules (incidents, users, changes, CMDB each live in separate tables). +- Filtering labels by "CMDB" surfaced 5,000+ CMDB-related tables — evidence the CMDB is a family of tables. +- Filtering names by `cmdb_ci` narrowed to 596 tables, all specialized children of the same base CI table: servers, databases, applications, and more. + +*Viewing the Hierarchy* +- Grouping by the extends table column produced 73 parent–child groups. +- Expanding "Configuration Item" showed only one table extends directly from it: `cmdb_ci` itself — the root of the entire hierarchy. +- Every server, database, and application table ultimately traces back to this one base table. + +**Action Items** +- In your own instance, use the Tables list filtered by `cmdb_ci` to inventory existing CI classes before creating new ones. +- Use the "group by extends table" view to map your CMDB hierarchy and spot duplicate or orphaned classes. +- Audit base-table field changes carefully since they cascade to every child class. + +**Key Terms/Concepts** +- **Staging/extends relation**: A table's parent in the inheritance hierarchy, shown as the extends table column. +- **PDI (Personal Developer Instance)**: A free personal ServiceNow instance used for learning/demos. +- **Table**: The storage structure in ServiceNow; all data lives in tables. + +## Chapter 2 — 03. Creating and managing CIs + +**Core Insights** +- Two creation paths exist: manual form entry and automated discovery; imports via import sets/transform maps handle bulk population. +- Manual creation is precise but does not scale — for hundreds of CIs it is unrealistic, error-prone, and stale the moment it is done. +- Discovery tools scan infrastructure and populate the CMDB automatically, but still require governance around approvals, validation, and ownership. +- Import sets stage raw data into a temporary table; transform maps define column-by-column mappings into the target CMDB table. +- Quality over perfection: an 80%-complete, actively used CMDB beats a perfect one that was never started. + +**Detailed Notes** +*Manual Creation* +- Fill a form: basics (name, description, type), then type-specific details (OS, CPU, RAM, manufacturer, owner, location, support group). +- Which attributes are mandatory vs. optional must be defined in governance policy (e.g., name + OS + owner minimum). + +*Automated Discovery* +- Agents/scanners find components: Windows discovery agents for servers, SNMP for network devices, dedicated processes for databases and applications. +- Discovery can auto-create CIs and relationships — but who approves and validates new CIs are governance questions. + +*Import Sets & Transform Maps* +- Import set = staging table where raw data lands; transform map = rule mapping source columns to target fields (e.g., spreadsheet server name column → CI name field). +- Powerful for initial population from a source of truth (inventory system, spreadsheet); quality is still garbage-in, garbage-out. + +*CI Attributes & Best Practices* +- Core attributes: name (unique, follow naming conventions), type (class), owner (accountability), status (lifecycle: in use/in development/retired), location (physical/cloud region). +- Operational attributes: CPU, RAM, OS, version, component-specific configuration. +- Populate attributes that drive incident/change decision-making rather than collecting everything. + +**Action Items** +- Define mandatory vs. recommended attributes per CI type in a written governance policy. +- Start small: load critical servers and key applications, define relationships, and use the CMDB in incident/change workflows. +- Establish an iteration loop to identify and close data gaps as the CMDB is used. + +**Key Terms/Concepts** +- **Import set**: A staging table holding raw imported data before transformation into the CMDB. +- **Transform map**: Defines how source columns map to target CMDB fields during import. +- **Discovery**: Automated agents that scan infrastructure and populate CI data. +- **Lifecycle status**: A CI's state (in use, in development, retired) tracked for governance. + +## Chapter 2 — 04. Demo Creating a CI + +**Core Insights** +- A CI is created from a blank, class-specific form — the demo created a server CI manually on a PDI. +- Key identification fields: name (unique identifier), company, asset tag, and serial number. +- The assignee/owner field is among the most important — no owner means no accountability for keeping the CI accurate. +- Server-specific fields (OS, RAM) only exist on the server table, demonstrating inheritance in action. +- The manual workflow is identical across all CI types: fill identification, set owner, add type-specific attributes, save, verify. + +**Detailed Notes** +*Demo Walkthrough* +- Filter Navigator → "configuration" → Servers → All (41 existing server CIs) → New to open a blank server form. +- Filled: name `serve prod 01`, company Acme (business unit owner), asset tag SV41, serial number 123456789. +- Assigned to a user (Antony) — the owner accountable for record accuracy. +- Server-only attributes: OS (Hyper-V) and RAM; real implementations would add CPU count, disk space, IP address. +- Submitted, then verified the CI appeared in the server list. + +*Verification* +- Added the "Updated" column via the gear icon to spot the newest record; sorting by that column put `serve prod 01` at the top. +- The record is stored in the cmdb_ci_server table. + +**Action Items** +- Standardize which identification fields are mandatory for each CI class before enabling creation. +- Always assign an owner/assignee on every CI record. +- Use the Updated column sort to routinely spot stale CMDB records. + +**Key Terms/Concepts** +- **Asset tag**: An organization's internal asset tracking number for the CI. +- **Serial number**: The manufacturer's unique hardware identifier. +- **Assignee**: The person accountable for the CI's data accuracy. + +## Chapter 2 — 05. Defining and visualizing CI relationships + +**Core Insights** +- A CI in isolation is just a record; relationships give the CMDB its power, connecting CIs so the data becomes intelligent. +- Relationship types carry meaning: Runs on, Connects to, Part of, Depends on, Backed up by, Managed by — each affects impact analysis differently. +- Relationships can come from discovery (auto-created), manual definition, bulk import via transform maps, or be added organically during incident/change work. +- Visualizing relationships (dependency maps) enables instant impact analysis: if a database goes down, which applications break? +- Start with high-value, critical relationships for your most important services and expand iteratively — don't map everything on day one. + +**Detailed Notes** +*Common Relationship Types* +- Runs on: application/service runs on one or more servers. +- Connects to: server connects to a database; application talks to an API. +- Part of / Grouped in: server part of a cluster; database part of an instance group. +- Depends on: a service depends on a supporting application/shared library. +- Backed up by: a system protected by a backup solution. +- Managed by: an infrastructure component managed by a systems team. + +*Defining Relationships at Scale* +- Small environments: click-through manual definition is feasible. +- Large environments: discovery finds installed applications and auto-defines run-on relationships; spreadsheets/CMDB tools can be imported in bulk; users add relationships as they discover them. + +*Visualization & Impact Analysis* +- Dependency maps show the full chain: applications → servers → databases → backup systems. +- Answering "what breaks if X fails?" becomes a glance at the map — operational intelligence for change decisions and incident response. + +**Action Items** +- Identify and model the critical dependency chains for your top business services first. +- Test impact analysis on the mapped relationships before expanding coverage. +- Prefer discovery-generated relationships for installed-software dependencies; reserve manual effort for what discovery cannot model. + +**Key Terms/Concepts** +- **Impact analysis**: Determining downstream effects when a CI fails or changes. +- **Dependency map**: A visual graph of CIs and their directional relationships. +- **Relationship type**: A labeled, directional connection (runs on, depends on, etc.) between CIs. + +## Chapter 2 — 06. Demo Creating and visualizing relationships + +**Core Insights** +- The related-items section on any CI record lists all relationships, each with direction and meaning (depends on, used by, exchanges data with). +- L1/L2/L3 labels indicate dependency depth: L1 is directly connected, L2 one hop away, L3 two hops away — the foundation of impact analysis. +- A freshly created CI sits in isolation; relationships are what bring the CMDB to life. +- The relationship editor lets you pick relationship types and connect a CI to other CIs; results appear immediately in the dependency map. + +**Detailed Notes** +*Demo Walkthrough* +- Opened the master view (`cmdb_ci.list`), grouped by class, and opened an AIX server record (SAP App SRO 2). +- Related items showed: web servers "Depend on / used by" the server; storage/database as parents the server depends on; "Exchanges data with" both child Windows servers and parent mass-storage devices. +- Explained L1 (direct neighbors, hit immediately on failure), L2 (one hop), L3 (two hops) — at risk depending on the chain. +- Opened the dependency map showing the server centered with arrows to its dependencies and dependents. + +*Creating Relationships* +- Plus icon opens the relationship editor: suggested types across the top (connects to, depends on, used by, child/parent), filters, and a CI picker below. +- Selected "depends on / used by" and added three CIs (Thinkpad T20, MacBook Pro 15, DP00315), then "receive data from" and "connects to / child" with more CIs; saved. +- The dependency map and related-items list both updated to show all new relationships. + +**Action Items** +- Review the related-items section and dependency map on your most critical CIs as a first impact-analysis exercise. +- Use L1/L2/L3 depth to prioritize which connections to keep accurate first. +- Use the relationship editor's type suggestions rather than free-typing to keep relationship vocabulary consistent. + +**Key Terms/Concepts** +- **Related items**: The section of a CI record listing all its relationships. +- **L1/L2/L3 dependency depth**: Distance of a connected CI from the CI of interest (direct, one hop, two hops). +- **Relationship editor**: UI for adding and typing relationships between CIs. + +## Chapter 2 — 07. Methods of populating the CMDB + +**Core Insights** +- Four approaches exist: manual creation, automated discovery, import sets/transform maps, and the hybrid approach — which most mature organizations actually use. +- Manual gives complete control but is time-intensive, error-prone, non-scalable. Discovery automates at scale and builds relationships, but only covers discoverable infrastructure and needs configuration. +- Import sets bulk-load fast from external sources but depend on source-data quality and require transform-rule definition. +- Data quality is decisive: garbage in, garbage out. Validate sources, map to standards, assign ownership, and enforce mandatory attributes. +- A realistic phased rollout: discovery first, manual for gaps, import the application portfolio, define relationships, then iterate with real usage. + +**Detailed Notes** +*Method Comparison* +- Manual: use for specialized items that don't fit discovery patterns, small initial setups, or CI types needing specific manual entry. +- Discovery: Windows agents, SNMP scanners for network devices, database discovery — finds what is actually running and auto-creates relationships; data quality depends on the process. +- Import sets/transform maps: export from spreadsheet, competing CMDB, or inventory tool → stage → transform → bulk load; ideal for initial population and legacy migration. +- Hybrid: discovery for servers/network, manual for specialized components, import sets for application data from an APM/portfolio tool. + +*Data Quality Best Practices* +- Validate source data before import or discovery. +- Enforce naming conventions, standard attributes, and consistent status values (no "server 123" vs "production server UK01"). +- Assign ownership so someone is accountable for stale records. +- Define mandatory attributes per CI type; don't leave every field optional. + +*Realistic Scenario (mid-sized org)* +- Phase 1: discovery finds ~150 Windows servers and network devices. +- Phase 2: manually add ~50 servers without agents (Unix, legacy, out-of-band devices). +- Phase 3: bulk import 300+ applications from the APM/portfolio tool. +- Phase 4: define server–application relationships (part automated, part manual). +- Phase 5: iterate — use the CMDB, find gaps, fix them. + +**Action Items** +- Choose a population method per CI category rather than one method for everything. +- Write naming and status-value standards before the first import or discovery run. +- Build a phased rollout plan with explicit governance checkpoints (approval, validation, ownership). + +**Key Terms/Concepts** +- **SNMP scanner**: Discovery mechanism for network devices. +- **APM (Application Portfolio Management)**: A tool holding application inventory, often a source for imports. +- **Hybrid approach**: Combining manual, discovery, and import methods based on situation. + +## Chapter 2 — 08. Demo Import sets and discovery + +**Core Insights** +- The import flow is: create a staging table → load raw data → build a transform map → run the transform → verify CIs landed in the target table. +- Import sets can be new per import or reused for recurring imports of the same structure; sources can be files (CSV/Excel) or configured data sources (FTP, JDBC, REST). +- A transform map is the bridge that tells ServiceNow which source column goes to which target field — without it, the staged data has no destination. +- Auto-mapping works only for exactly matching column names; mapping assist gives a controlled visual editor for manual mapping. +- Completion code "success", a complete import-set run state, and target-record links verify the transform cleanly. + +**Detailed Notes** +*Demo Walkthrough* +- Prepared a sample CSV of 10 laptop records (name, asset tag, manufacturer, serial, OS, location, department, owner, CPU count, RAM, hard disk, IP, MAC, operational status). +- System Import Sets → Load Data → created a new staging table (label: computer import CMDB test), uploaded the CSV. +- The import-set state showed "loaded" — data staged but not yet in the CMDB; all 10 rows visible under the import set rows tab. +- Created a transform map: source = staging table, target = cmdb_ci_computer; used mapping assist to map nine fields (asset tag, CPU count, department, IP, MAC, manufacturer, etc.). +- Ran the transform: completion code success; all 10 records got target-record links; the import-set run state was "complete". + +*Verification* +- Opened `cmdb_ci_computer.list` and confirmed all 10 CIs present. +- Added asset tag, CPU count, MAC, IP, model, and RAM columns to verify imported values match the spreadsheet exactly. + +**Action Items** +- Reuse an existing staging table for recurring imports of identical structure to keep the process streamlined. +- Prefer mapping assist when source column names deviate from target field names. +- Always verify imported CIs by checking target-record links and spot-checking a few attribute values. + +**Key Terms/Concepts** +- **Staging table**: Temporary holding area for raw import data before transformation. +- **Transform map**: Defines source-to-target field mappings between staging and CMDB tables. +- **Mapping assist**: Visual editor for manually mapping source fields to target fields. +- **Import set run**: A record of a completed transformation run with its state. + +--- + +## Chapter 3 — 1. CMDB data quality and integrity + +**Core Insights** +- Building a CMDB is easy; keeping it reliable over time is the hard part — a CMDB decays like an untended garden unless continuously maintained. +- Data quality and integrity are the foundation of trust: impact analysis, incident response, and change approvals are only as good as the CMDB data behind them. +- Data quality has four dimensions: completeness, accuracy, consistency, and currency. +- Maintaining quality is an organizational problem, not a technical one — ownership, governance, audits, process integration, and education. +- Without attention the CMDB drifts into entropy: records go stale, relationships age, and nobody notices until a bad decision is made. + +**Detailed Notes** +*What Defines a Healthy CMDB* +- A healthy CMDB is one where you can trust the data for decisions — approving changes via impact analysis, incident responders tracing relationships. + +*The Four Dimensions of Data Quality* +- **Completeness**: essential attributes populated (e.g., every server has an owner); not every field, just what decisions require. +- **Accuracy**: data matches reality (e.g., actual OS version vs. recorded version) — small errors compound in compliance and support-lifecycle decisions. +- **Consistency**: standardized naming and formatting ("Prod App Server 1" vs. "Production App Server 2" breaks search and reporting). +- **Currency**: records reflect the current state, not a historical record — decommissioned servers and upgraded apps must be updated. + +*Operational Consequences of Bad Data* +- Incident management may miss affected systems and resolve without addressing root cause. +- Change management may approve risky changes when the CMDB understates what a CI supports. +- Configuration management cannot enforce standards against an untrusted source of truth. + +*How to Maintain Data Quality* +- Every CI needs a named owner or it will decay; define and enforce standards (attributes, naming, statuses); schedule audits comparing the CMDB to reality; integrate CMDB updates into provisioning/decommissioning/deployment processes; educate users with real examples of bad decisions caused by bad data. + +**Action Items** +- Assign an owner to every CI and make the list of ownerless records a tracked metric. +- Define mandatory attributes per CI type, a naming convention, and valid status values; write them down and publish them. +- Schedule recurring audits (compare CMDB entries against live infrastructure) and hold teams accountable for discrepancies. +- Wire CMDB updates into standard operating processes so they happen automatically, not as an afterthought. +- Run a training session showing real cases where stale or missing CMDB data caused a costly or risky decision. + +**Key Terms/Concepts** +- **Completeness**: degree to which essential, decision-driving attributes are populated on CI records. +- **Accuracy**: how closely recorded CI data matches the real-world component. +- **Consistency**: uniformity of naming, formatting, and status values across records. +- **Currency**: how current records are relative to the actual infrastructure state. +- **Entropy (CMDB decay)**: the natural drift of CMDB data toward staleness and error when no one actively maintains it. + +## Chapter 3 — 2. Using CMDB health dashboards + +**Core Insights** +- Health dashboards turn vague "is our CMDB good?" into quantifiable scores that show where problems live. +- Trending over time is the real power: visibility into improvement or decay tells you whether governance efforts are working. +- The ServiceNow dashboard computes KPIs from your governance rules — completeness, accuracy, and compliance are only meaningful relative to standards you define. +- Measure what matters to your organization: align metrics with incident management, change, or other priorities instead of tracking everything. +- Metrics drive behavior — tracking something makes people improve it, and declining scores force accountability. + +**Detailed Notes** +*Dashboard KPIs* +- **Completeness score**: percentage of CIs with mandatory attributes populated, calculated from governance rules; 95% is good, 60% signals work to do. +- **Accuracy metrics**: automatically detectable issues like CIs with no relationships or orphaned records. +- **Compliance**: CIs meeting governance standards, e.g., production servers must link a backup solution. + +*The Power of Trending* +- Scores tracked over months show improvement or degradation; a dropping score means governance is not preventing decay; an initiative that lifts the curve proves measurement drives results. + +*Customizing What You Measure* +- Tailor metrics to priorities: % of CIs with SLA info, missing relationships, % of applications with documented dependencies, data freshness vs. reality. +- If incident management is the priority, measure data incident managers rely on; if change is critical, measure the data change managers need. + +*Key Metrics Worth Tracking* +- **Discovery coverage**: % discovered automatically vs. manually created — more discovery catches new infrastructure automatically. +- **Relationship density**: average relationships per CI — near-zero suggests missing definitions, dozens suggests over-granularity. +- **Freshness/verification age**: when each CI was last verified; unverified for 6+ months is stale. +- **Ownership coverage**: % of CIs with assigned owners — ownerless CIs decay. +- Showing completeness climbing from 65% to 78% demonstrates progress and creates accountability. + +*Practical Approach* +- Don't fix everything at once: pick the high-value CI type first (e.g., servers, databases), drive it past 90% completeness, then iterate. + +**Action Items** +- Configure the health dashboard and note the baseline overall score and per-KPI values before any cleanup. +- Define mandatory and recommended attributes per CI type so completeness scores are meaningful. +- Set up a monthly trend review of the three KPIs; investigate any month-over-month decline immediately. +- Choose 3-5 custom metrics aligned to your biggest operational pain (incident, change, or compliance) and track only those first. +- Prioritize one high-value CI class (e.g., servers) and target 90%+ completeness before expanding scope. + +**Key Terms/Concepts** +- **CMDB Health Dashboard**: ServiceNow tool showing overall CMDB health scores and surfacing where problems are. +- **Completeness Score**: % of CIs meeting mandatory-attribute governance rules. +- **Compliance KPI**: % of CIs satisfying governance audit rules (e.g., backup linked, owner assigned). +- **Discovery coverage**: share of infrastructure captured automatically by discovery vs. entered manually. +- **Relationship density**: average number of relationships per CI, used to spot missing or over-granular relationship definitions. +- **Freshness**: how recently each CI was verified accurate, tracked via timestamps. + +## Chapter 3 — 3. Common CMDB data issues and remediation + +**Core Insights** +- The five classic CMDB problems are duplicates, orphans, wrong relationships, missing attributes, and stale data — each with a distinct remediation path. +- Prevention beats remediation: enforce naming standards, run duplicate detection regularly, and validate data at entry. +- Prioritize fixes by impact × effort: high-impact/low-effort quick wins first; skip low-impact/high-effort items. +- Many fixes (relationships, attributes, freshness) require subject-matter-expert validation — remediation is a people process, not just a technical one. +- Remediation is never a one-time project; a five-phase loop of identify → triage → fix → measure → govern keeps issues from undermining trust. + +**Detailed Notes** +*Issue 1: Duplicate CIs* +- Same physical component recorded multiple times (e.g., "ProdDB01" vs. "proddb01"); duplicates confuse relationships, skew metrics, and link incidents to the wrong CI. +- Remediation: merge using ServiceNow's merge tool — pick the master record, merge the rest, relationships update automatically. +- Prevention: strict naming conventions plus regular duplicate detection. + +*Issue 2: Orphan CIs* +- CIs with no relationships — unused apps, disconnected servers, isolated databases; either the CI is obsolete and not retired, or relationships are missing. +- Remediation: investigate; then delete it, mark it retired, or add the missing relationships. + +*Issue 3: Wrong/Outdated Relationships* +- E.g., Server A no longer uses database B; an app was migrated away a month ago. +- Remediation: harder — requires system owners to validate whether the relationship still exists before deleting/updating. + +*Issue 4: Missing Attributes* +- No OS specified, no version, no owner. +- Remediation depends on the attribute: query external systems where possible, otherwise survey system owners with a pre-filled list, specific asks, and a deadline. + +*Issue 5: Stale Data* +- Records unverified for months or years (app at v1.5 but actually v3.0). +- Remediation: periodic (e.g., quarterly) verification campaigns — send owners lists to confirm or update, creating accountability and freshness. + +*Issue 6: Inconsistent Data* +- Naming conventions broken, status values inconsistent, relationships modeled differently. +- Remediation: enforce standards with dropdowns instead of free text and ServiceNow rules that validate data as entered — make deviation hard. + +*Prioritization Framework and Phased Approach* +- High impact + high effort: schedule dedicated effort. High impact + low effort (quick wins, e.g., merging 50 duplicates): do first. +- Low impact + low effort: nice-to-have. Low impact + high effort: skip. +- Phases: 1) identify via dashboard/reports, 2) triage by impact/effort, 3) fix high-impact first, 4) measure progress, 5) govern to prevent regression. + +**Action Items** +- Run duplicate detection (naming and owner-based) and merge the top duplicates as an afternoon quick win. +- Produce an orphaned-CI report and triage each record into delete / mark retired / add missing relationships. +- Launch a quarterly verification campaign: email system owners a list of their CIs with a deadline to confirm or correct. +- Replace free-text fields with dropdowns and add validation rules so bad data cannot be entered. +- Build the five-phase remediation loop into a recurring review (e.g., monthly triage, quarterly verification). + +**Key Terms/Concepts** +- **Orphan CI**: CI record with no relationships, indicating isolation or obsolescence. +- **Master record**: the canonical CI record kept when merging duplicates. +- **System owner**: the person/team responsible for a component, used to validate relationships and attributes. +- **Verification campaign**: periodic exercise where owners confirm or update CI data to keep it fresh. +- **Impact × effort matrix**: prioritization grid — high-impact/low-effort quick wins first, low-impact/high-effort skipped. + +## Chapter 3 — 4. CMDB governance and best practices + +**Core Insights** +- Governance is what prevents decay in the first place — policies, processes, and responsibilities that keep the CMDB healthy over time. +- Ownership must exist at two levels: a configuration management team owns the CMDB overall, and each CI has a system/application team owning its accuracy. +- Don't rely on voluntary compliance — enforce standards inside ServiceNow with mandatory fields, dropdowns, business rules, and compliance dashboards. +- Governance evolves along a maturity curve from ad-hoc to optimized; most organizations should target Level 3 (Managed), which delivers reliability without constant firefighting. +- Start simple, iterate: define CI types, mandatory attributes, and naming conventions, enforce them, track metrics, then refine annually. + +**Detailed Notes** +*Key Elements of Governance* +- **Clear ownership structure**: a configuration management role/team sets standards and drives improvement; individual CIs have named owners. +- **Standards**: document CI types tracked, mandatory attributes per type, naming conventions, and valid status values; distribute to everyone creating or updating CIs. +- **Enforcement mechanisms**: mandatory fields so critical attributes can't be blank, dropdowns for status, business rules validating relationships, dashboards tracking compliance — make the wrong thing hard and the right thing easy. +- **Process integration**: provisioning auto-creates CIs (via discovery or workflow), decommissioning marks retired, deployments update versions — CMDB updates are part of operational processes, not an afterthought. +- **Ownership and accountability**: use a RACI matrix for CMDB decisions; make clear that keeping CIs updated is part of each owner's job, with consequences when health metrics decline. +- **Regular audits**: periodically (e.g., quarterly) sample CIs and verify existence, location, and ownership against reality; use findings to fix systematic problems. +- **Training and communication**: people can't follow standards they don't know — train teams, share real examples of failures caused by bad data. +- **Continuous improvement**: governance is not static — add CI types for new technologies, refine attribute definitions, review the whole framework annually. + +*Governance Maturity Model* +- **Level 1 (Ad-hoc)**: CMDB exists, no clear governance, poor data quality, sporadic updates. +- **Level 2 (Defined)**: basic standards defined, some enforcement, quality improving but gaps remain. +- **Level 3 (Managed)**: governance documented and enforced, ownership clear, health metrics tracked, data quality good — the realistic target for most organizations. +- **Level 4 (Optimized)**: governance fully integrated with processes, continuous improvement, consistently high quality. + +**Action Items** +- Publish a CMDB standard document covering CI types, mandatory attributes, naming convention, and valid statuses. +- Turn on mandatory fields, dropdowns, and business rules in ServiceNow so standards are enforced at entry. +- Draft a RACI matrix for the CMDB (responsible/accountable/consulted/informed) and communicate consequences for declining health metrics. +- Run a quarterly sample audit of CIs against reality and use findings to drive systematic fixes. +- Schedule an annual governance review asking: is it working, what are the pain points, what should change; then iterate. + +**Key Terms/Concepts** +- **CMDB governance**: the policies, processes, and responsibilities that keep the CMDB healthy over time. +- **Enforcement mechanism**: technical controls (mandatory fields, dropdowns, business rules) that make deviations from standards hard. +- **RACI matrix**: responsibility assignment grid — Responsible, Accountable, Consulted, Informed — applied to CMDB decisions. +- **Governance maturity model**: 4-level progression (Ad-hoc → Defined → Managed → Optimized) describing how mature CMDB governance is. + +## Chapter 3 — 5. Demo: CMDB health dashboards and metrics + +**Core Insights** +- The ServiceNow CMDB Health dashboard is found via the Application Navigator under "CMDB" — either through the CMDB workspace or directly to the Health dashboard. +- Three views exist: Class (by CI type), Services (by business service), and Health group (by custom groupings like environment or owning team). +- The overall score is a weighted average of the three KPIs — Completeness, Correctness, and Compliance — a headline metric for status reports. +- Each KPI drills down to concrete problem lists: missing mandatory/recommended attributes, duplicate/orphan/stale CIs, and governance audit failures. +- KPIs may show "this KPI has not run" until the scheduled calculation jobs execute — an empty dashboard usually means disabled jobs, not a healthy CMDB. + +**Detailed Notes** +*Navigation* +- From the Application Navigator, filter by "CMDB"; either open the CMDB workspace or jump straight to the CMDB Health dashboard. + +*Dashboard Views* +- **Class**: health grouped by CI type (server, database, applications...). +- **Services**: health from the perspective of delivered business services. +- **Health group**: health by custom groupings, e.g., all production CIs or CIs owned by a particular team. +- The Configuration Item filter on the Class view shows visibility across all CI types. + +*Scores and KPIs* +- **Overall score**: single number, a weighted average of the three KPIs below it; higher is better, moves with data quality. +- **Completeness**: required and recommended attributes populated — drills down to Missing required attributes (most serious) and Missing recommended attributes. +- **Correctness**: accuracy, free of duplicates, orphans, and stale records — three classic integrity problems. +- **Compliance**: CIs failing governance audit rules, e.g., "every production server must have an owner assigned". +- Completeness drops when new CIs arrive incomplete; scores improve when teams populate missing data. + +*Reading the State* +- All KPIs showing "this KPI has not run" means the scheduled score-calculation jobs have not executed yet in the instance — the next demo shows how to activate and run them. + +**Action Items** +- In a ServiceNow instance, navigate to the CMDB Health dashboard and note which view (Class/Services/Health group) suits your reporting audience. +- Record the overall score and each KPI value as a baseline; identify which CI class drags the score down. +- Check whether any KPI shows "has not run" — if so, verify the calculation schedule jobs are active before trusting the dashboard. +- Set up the Class view with the Configuration Item filter to get cross-CI-type visibility in status reports. + +**Key Terms/Concepts** +- **Overall score**: weighted average of Completeness, Correctness, and Compliance KPIs summarizing CMDB health. +- **Correctness**: KPI measuring data accuracy — surfaced through duplicate, orphan, and stale CI lists. +- **Audit section**: compliance list of CIs failing governance rules (e.g., missing required ownership). +- **KPI has not run**: dashboard state indicating the scheduled jobs that compute scores have not executed. + +## Chapter 3 — 6. Demo: CMDB health review and correction + +**Core Insights** +- Health dashboard KPIs are not computed in real time — scheduled jobs, typically every few hours, calculate and store scores, and the dashboard displays stored results. +- Out-of-the-box, 5 of the 6 CMDB Health schedule jobs are inactive; an empty dashboard is usually "the engine isn't switched on," not a healthy CMDB. +- After activating all jobs and triggering them manually, the instance showed an overall score of 63% — with 295 duplicate computers flagged by Discovery and by Owner. +- Duplicate detection works through two signals: Discovery can't uniquely identify the CI (missing serial/asset tag) and shared owner-defined identifiers. +- Filtering the dashboard to a specific CI class (application servers) recalculates every KPI for that scope (67% overall) — the dashboard localizes where problems live. + +**Detailed Notes** +*Score Calculation Architecture* +- Recalculating across thousands of CIs per dashboard open would be too expensive; ServiceNow runs scheduled jobs (typically every 3 hours) that store results the dashboard renders. + +*Activating the Jobs* +- Filter Navigator → System Definition → Scheduled Jobs; filter the long list by "name contains health" to find the 6 CMDB Health jobs. +- 5 of the 6 showed active=false — disabled jobs never run despite configured schedules; select all 5 and set active=true. +- To populate the dashboard without waiting up to 3 hours, open each job (e.g., Completeness Score Calculation) and click Execute now. +- A 3-hour schedule is a sensible production default: current enough without straining the platform. + +*Interpreting the Results* +- Overall score 63%; Completeness at 100% — every CI in scope has mandatory and recommended fields filled per current rules. +- Correctness: 295 duplicate computers flagged — non-compliant by Discovery (couldn't uniquely identify, often missing serial numbers/asset tags) and non-compliant by Owner (shared owner-defined identifier); printers flagged similarly. +- Orphaned CIs: empty (no isolated records). Stale CIs: service CIs plus 14 Windows cluster nodes not updated recently. +- Compliance audit: 34 service CIs and 13 databases fail governance rules (e.g., missing required ownership or invalid status). + +*Scope Filtering* +- Searching "server" and selecting Application Servers recalculates the overall score to 67% with every KPI re-scoped to that class — the dashboard reveals not just overall health but where the problems live. + +**Action Items** +- In any ServiceNow instance, verify all six CMDB Health schedule jobs are active before trusting the dashboard. +- After enabling jobs, trigger each one manually with "Execute now" to populate KPIs without waiting for the schedule. +- Review Correctness lists for the two duplicate signals (Discovery-identified and owner-identified) and plan merges. +- Use the Compliance audit section to drive fixes for failing CIs (e.g., missing ownership, invalid status). +- Compare per-class scores against the overall score to locate the CI types with the worst health. + +**Key Terms/Concepts** +- **Scheduled job**: platform job that periodically computes and stores dashboard KPI scores (default ~3 hours). +- **Non-compliant by Discovery**: duplicate flag when Discovery cannot uniquely identify CIs, typically missing serial numbers or asset tags. +- **Non-compliant by Owner**: duplicate flag when records share the same owner-defined identifier. +- **Execute now**: manual trigger that runs a scheduled job immediately (used to populate dashboards without waiting). +- **Stale CI**: record not updated or verified recently (e.g., Windows cluster nodes flagged in the demo). \ No newline at end of file