CMDB — Configuration Management Database (Zero → Pro)

اقرأ أولاً: ../MASTER_ALL_IN_ONE_SUMMARY.md · ../html/MASTER_ALL_IN_ONE_SUMMARY.html
الدليل الشامل: ../MASTER_ALL_IN_ONE.md · ../html/MASTER_ALL_IN_ONE.html
ممارسة الشاشات: ../html/MASTER_PRACTICE_GUIDE_ALL_TOPICS.html
Australia · Scope x_786686_hr_leave

Australia Instance — نسخة أستراليا

Direct Navigation URLs — روابط التنقل المباشرة

Platform target: ServiceNow Australia (Sep 2026) · next EA: Brazil
URLs: ../../SERVICENOW_DIRECT_URLS_CATALOG.md · 1-week: ../../SERVICENOW_ONE_WEEK_STUDY_DEPLOY_AUSTRALIA.md
HR Leave: Scope x_786686_hr_leave

CIS-Discovery / CMDB / CSDM Professional Implementer Guide
الأسلوب: عربية + إنجليزية تكمّلان بعضهما — بدون ترجمة حرفية لأسماء الشاشات.

ملخص ووصف بالعربية (Arabic Summary)

ملخص في سطر: مصدر واحد للحقيقة عن البنية التقنية — من إدخال CI يدويًا حتى الاكتشاف والجودة.

وصف مختصر: يغطي CSDM، CI Class Manager، منع التكرار (IRE)، استيراد CSV، خريطة الاعتماد، وربط الحوادث بـ CI. يُدرس مع ITOM للاكتشاف.

1) Overview & Business Value

CMDB stores Configuration Items (CIs) and their relationships. — هو الأساس الذي تعتمد عليه كل الموديولات (ITSM, ITOM, SecOps…). بيانات سيئة في CMDB = قرارات سيئة في كل مكان.

Core value:
- Single source of truth for infrastructure & services.
- Impact analysis (ما الذي يتأثر إذا تعطّل هذا الخادم؟).
- Service mapping & dependency views.
- Foundation for Discovery, Event Management, Change.

2) Architecture & Data Model

CI class hierarchy:

cmdb (base)
└─ cmdb_ci (Configuration Item)
 ├─ cmdb_ci_hardware
 │ ├─ cmdb_ci_computer
 │ │ ├─ cmdb_ci_server
 │ │ └─ cmdb_ci_win_server / linux_server
 │ └─ cmdb_ci_netgear
 ├─ cmdb_ci_appl (applications)
 ├─ cmdb_ci_service (services)
 │ └─ cmdb_ci_service_auto (Application Service / CSDM)
 └─ cmdb_ci_business_app

Key tables:

CSDM (Common Service Data Model): — CSDM هو الإطار/المعيار المعتمد لتنظيم CMDB في أربع طبقات.

Foundation → Design → Manage Technical Services → Sell/Consume
(Business App → Application Service → Technical Service Offering...)

3) Plugins & Activation

How to activate:

1. Navigate: All > System Definition > Plugins (for core). — Open direct
2. For Discovery/Service Mapping (licensed):
   Navigate: All > System Applications > All Available Applications > All. — Open direct
3. Guided Setup:
   Navigate: All > Guided Setup > CMDB and > ITOM (for Discovery). — Open direct

4) Guided Setup & All Options

Sections:
- CMDB foundations — classes, CSDM alignment.
- Identification & Reconciliation (IRE) rules.
- Data sources & Discovery (if licensed).
- CMDB Health — completeness, compliance, correctness.
- Relationships & dependency views.
- Service mapping.

Important options:

5) End-to-End Process Cycle

Populate & maintain CMDB:

Choose CSDM scope
 → Define CI classes (CI Class Manager)
 → Set Identification & Reconciliation rules (IRE)
 → Populate:
 - Discovery (MID Server) for infra
 - Integrations / Import Sets for external sources
 - Service Mapping for application services
 → Reconcile (IRE prevents duplicates, manages authoritative source)
 → Maintain via CMDB Health (completeness/compliance/correctness)
 → Consume: ITSM (incident CI), Change impact, Event Management

IRE هو الحكَم: يقرّر إنشاء CI جديد أم تحديث الموجود، ومن المصدر الموثوق.

6) Development

Build a relationship via script

// relate an application to the server it runs on
var rel = new GlideRecord('cmdb_rel_ci');
rel.initialize();
rel.parent = appCiSysId; // cmdb_ci_appl
rel.child = serverCiSysId; // cmdb_ci_server
rel.type = relTypeRunsOnSysId; // 'Runs on::Runs'
rel.insert();

Query CIs safely

var ci = new GlideRecord('cmdb_ci_server');
ci.addActiveQuery();
ci.query();
while (ci.next()) {
 gs.info(ci.name + ' — ' + ci.sys_class_name);
}

Development topics:
- IRE: identification rules, reconciliation, data source precedence.
- CI Class Manager (extend classes, dependent attributes).
- Transform maps + coalesce for imports (avoid duplicates).
- Dependency views & relationship types.
- CMDB Health remediation.

7) Administration

Key roles:
- cmdb_admin — إدارة CMDB.
- discovery_admin — إدارة الاكتشاف.
- itil — قراءة/استخدام في العمليات.

8) Hands-on Labs

Lab 1 — Explore classes:
1. Navigate: All > Configuration > CI Class Manager. — Open direct
2. Inspect the hierarchy (Server → Windows/Linux).

Lab 2 — Create CIs + relationship:
1. Create a Server CI and an Application CI.
2. Relate them (“Runs on::Runs”).
3. Open the Dependency View.

Lab 3 — Import with coalesce:
1. Import a CSV of servers via Import Set.
2. Set coalesce on a unique key (serial/name) to avoid duplicates.

Lab 4 — IRE:
1. Inspect identification rules for cmdb_ci_server.
2. Re-import the same data; confirm no duplicates created.

Lab 5 — CMDB Health:
1. Open CMDB Health Dashboard.
2. Identify completeness/correctness gaps and remediate one.

9) Best Practices & Common Mistakes

Best practices:
- Follow CSDM — don’t invent your own structure.
- Let IRE manage identity; never bypass it on imports.
- Always coalesce on a stable unique attribute.
- Monitor CMDB Health continuously; assign data owners.
- Use the most specific CI class (not generic cmdb_ci).

Common mistakes:
- استيراد بلا coalesce → تكرار CIs.
- وضع كل شيء في cmdb_ci العام بدل الفئة الصحيحة.
- تجاهل CSDM فيصبح CMDB فوضويًا.
- تعطيل/تجاوز IRE.

10) CIS Exam Focus (Discovery / CMDB / CSDM)

High-yield:
- CI class hierarchy & table-per-class.
- IRE: identification rules, reconciliation, authoritative data source.
- CSDM 4 domains (Foundation/Design/Manage/Consume).
- Relationships (cmdb_rel_ci, relationship types, parent/child).
- CMDB Health: completeness, compliance, correctness.
- Discovery: MID Server, schedules, probes/sensors, patterns.
- Service Mapping vs Discovery.
- Coalesce in Transform Maps (deduplication).

Exam tip: — ركّز على IRE و CSDM والعلاقات — أكثر ما يُختبر في CMDB/Discovery.

11) Portals, Workspaces, Role Hierarchy & Feature Catalog

ملاحظة عن الروابط:
CMDB يُدار غالبًا عبر Workspaces والأدوات الإدارية، لا Portal للمستخدم النهائي.

11.1 Portals & Self-service

11.2 Workspaces & Admin Tools

11.3 Role Hierarchy

admin
└─ cmdb_admin
 ├─ itil (read/use CIs in processes)
 ├─ discovery_admin (Discovery config)
 ├─ service_mapping_admin
 ├─ cmdb_read / asset roles
 └─ data owners (per CI class / domain)

11.4 Full Business Cycle

Define scope via CSDM (Foundation → Design → Manage → Consume)
 → Model CI classes (CI Class Manager)
 → Set Identification & Reconciliation rules (IRE)
 → Populate:
 Discovery (MID Server, schedules, probes/sensors, patterns)
 Service Mapping (top-down application services)
 Integrations / Import Sets (coalesce to dedupe)
 → IRE reconciles (authoritative source, no duplicates)
 → Build relationships (cmdb_rel_ci)
 → Maintain via CMDB Health (completeness/compliance/correctness)
 → Data Manager retires stale CIs
 → Consume: ITSM (incident CI), Change impact, Event Mgmt, SecOps

11.5 Feature Catalog

Process/data features:
- CI Class modeling (CI Class Manager, dependent attributes).
- Identification & Reconciliation Engine (IRE).
- Multisource CMDB (multiple authoritative sources).
- CMDB Health (completeness/compliance/correctness + remediation).
- CMDB Data Manager (lifecycle, staleness, deletion).
- Relationships & relationship types + Dependency Views.
- CSDM alignment.

ITOM features that populate CMDB:
- Discovery (MID Server, schedules, probes/sensors, patterns, credentials).
- Service Mapping (top-down service modeling).
- Cloud Discovery (AWS/Azure/GCP).
- Certificate/Inventory discovery.

Platform features used:
- Transform Maps + coalesce (import dedup).
- Flow Designer / IntegrationHub (external CMDB feeds).
- Performance Analytics (CMDB Health trends).
- Now Assist / Predictive for data quality.

12) End-to-End Implementation (Post-Activation)

اقرأ هذا بعد تفعيل CMDB/Discovery/Service Mapping.

12.1 Application Menus map

All > Configuration
 ├─ CI Class Manager
 ├─ Servers / Computers / Network Gear / Applications / Services
 ├─ CI Identifiers (Identification Rules)
 ├─ Reconciliation Definitions
 ├─ CMDB Health (Dashboard / Completeness / Compliance / Correctness)
 └─ Relationships / Relationship Types
All > CMDB Data Manager (stale CIs / lifecycle)
All > Discovery
 ├─ Discovery Schedules / Discovery Status
 ├─ Credentials / IP Ranges
 ├─ Probes & Sensors / Patterns (Pattern Designer)
 └─ MID Servers
All > Service Mapping (Business/Application Services)

12.2 Core tables to know

12.3 End-to-end build order

1. Strategy:
   - Choose CSDM scope (Foundation → Design → Manage → Consume).
2. Model:
   - CI Class Manager: classes, attributes, dependent attributes.
3. Identity:
   - Identification Rules (IRE) + Reconciliation Definitions + data source precedence.
4. MID Server:
   - Install + validate MID Server.
   All > MID Server > Servers. — Open direct
5. Discovery (if licensed):
   - Credentials → IP ranges → Discovery Schedules → run.
   - Patterns / Probes & Sensors as needed.
6. Service Mapping (if licensed):
   - Entry points → map application services top-down.
7. Imports:
   - Import Sets + Transform Maps with coalesce (dedupe) for external sources.
8. Multisource:
   - Configure multiple authoritative sources.
9. Health:
   - CMDB Health Dashboard: assign data owners, remediate gaps.
10. Data Manager:
    - Lifecycle/staleness rules to retire dead CIs.
11. Consume:
    - Link CIs to ITSM/Change/Event Mgmt; build Dependency Views.
12. Test + Deploy.

12.4 All configuration pages

Study path note: — للدراسة من الصفر اتبع: STUDY_ROADMAP.md

13) Options & Instance Notes

14) Implementation Scenarios, Options, Best Practices & Customizations

Playbook: MODULE_IMPLEMENTATION_PLAYBOOK.md → CMDB

14.1 Scenarios

14.2 Options matrix

14.3 Plugins

Guided Setup: CMDB + ITOM

14.4 Roles

cmdb_admin, discovery_admin, service_mapping_admin, data owners per CI class/domain.

14.5 Common developments

IRE rules, custom CI classes/attributes, relationship types, Transform Maps, Health remediation projects, external CMDB sync (IntegrationHub), dependency views for change impact.

14.6 Best practices

CSDM alignment workshop first; one authoritative source per class; retire stale CIs (Data Manager).

14.7 Go-live

• [ ] IRE tested with duplicate imports
• [ ] Health dashboard owners assigned
• [ ] Discovery schedule pilot (one subnet)
• [ ] Relationships validated for top services

15) Zero-to-Hero End-to-End Implementation (Scratch → Go-Live)

Framework: MODULE_ZERO_TO_HERO_CONSULTING.md · Often with ITOM.md

من استراتيجية CSDM حتى CMDB موثوق يغذّي ITSM/Change/Events.

15.1 Business goals

15.2 Phase 0 — Discover (Week 1–2)

CSDM scope workshop, CI classes in scope, authoritative sources, data owners.

15.3 Phase 1 — Activate (Week 2)

CMDB core, Discovery/Service Mapping if licensed, Guided Setup CMDB+ITOM.

15.4 Phase 2 — Model (Week 3–4)

CI Class Manager, attributes, relationship types, IRE identification + reconciliation rules.

15.5 Phase 3 — Populate (Week 4–8)

15.6 Phase 4 — Quality (Week 8–10)

CMDB Health dashboard, assign owners, remediate completeness gaps, Data Manager staleness.

15.7 Phase 5 — Consume (Week 10–11)

Link to ITSM incidents/changes, dependency views, optional Service Mapping.

15.8 Phase 6 — UAT & go-live

Duplicate CI test, impact analysis demo, sign-off from operations.

15.9 Phase 7 — Operate

Monthly health review, discovery schedule expansion, reconciliation audits.

15.10 Master checklist

• [ ] CSDM scope doc · [ ] IRE tested · [ ] Health KPIs green pilot · [ ] ITSM using CIs

16) Full E2E Practice · Pages · Requirements · Options (AR + EN)

Extended: MODULE_FULL_E2E_PRACTICE.md · Pairs with ITOM.md for Discovery

16.1 Business goals

Why buy CMDB: English: Incidents and changes need to know what broke and who depends on it. — بدون CMDB دقيق، ITSM يعمل “أعمى” — لا تأثير ولا root cause على البنية.

16.2 Requirements

16.3 Consultation cycle

Questions: Which CIs are authoritative source? Who owns application service records?
من المصدر الموثوق للـ CI؟ من يملك سجل خدمة التطبيق؟

16.4 Options (A / B / C)

16.5 All pages (Navigate)

16.6 Full PDI lab (18 steps)

16.7 Sign-off

• [ ] No duplicate serials in pilot scope · [ ] Health owner named · [ ] ITSM agents trained to pick CI · [ ] CSDM scope doc approved

§17 — Power User Playbook (CMDB)

Day-in-life recipes for each CMDB persona + 20 production-ready scripts.
ملف عملي لكل دور — مدير CMDB، مالك CI، حارس البيانات، مدير الاكتشاف، معماري CSDM، مدقق.

17.1 Personas — what each role does

لكل دور صفحات بدء يومه. مدير CMDB يبدأ من Workspace، حارس البيانات من Data Manager، ومالك CI من قائمة مفلترة على ملكيته.

⚠️ مالك CI ليس بالضرورة مالك العملية — افصل بينهما.

17.2 ITSM Agent — using CMDB context

On an incident form:

1) Pick CI in cmdb_ci field — autocomplete shows operational CIs only
2) Side panel → "Affected CIs" → adds downstream services automatically
3) Side panel → "Dependency View" → topology graph
4) Related list "Affected CIs" → tracks impact
5) On resolve → CI stays linked → fuels Problem RCA + CSI analytics

Topology read:

Open CI → Related Items → Dependency View
- Outgoing (children): what depends on this CI
- Incoming (parents): what this CI depends on
- Click any node → drill into incidents/changes/problems on that CI

وكلاء ITSM لا يبنون CI — هم فقط يربطون ويرون التأثير. أمّا الإدخال فمن Discovery أو Import.

17.3 CMDB Manager recipes

Recipe A — Read the Data Quality dashboard

Navigate: All > Configuration > CMDB Dashboard
Tiles to watch:
- Completeness → % required attrs filled (target ≥ 90%)
- Correctness → IRE rule pass rate (target ≥ 95%)
- Compliance → CIs with owner + class (target ≥ 90%)
- Health Score → weighted overall (target ≥ 80, §18.20)
- Staleness → not updated > 90 days (target ≤ 10%)
- Duplicates → IRE rejects + suspects (target = 0 confirmed)

Recipe B — Stale CI cleanup

// Background script — find stale, optionally archive
var stale = new GlideRecord('cmdb_ci');
stale.addQuery('sys_updated_on', '<', gs.daysAgo(90));
stale.addQuery('operational_status', '1'); // currently operational
stale.addQuery('discovery_source', '!=', '');
stale.setLimit(200);
stale.query();
var ids = [];
while (stale.next()) ids.push(stale.number + ' ' + stale.name);
gs.info('Stale CIs: ' + ids.length + '\n' + ids.join('\n'));
// To act: switch to write mode, set install_status = 7 (Retired)

Recipe C — Duplicate detection via IRE

Navigate: All > Configuration > CI Identifiers
For each class verify:
- Independent attributes (e.g. serial_number)
- Dependent attributes (e.g. fqdn + ip_address)
- Run IRE simulation → see duplicates flagged before insert

Recipe D — Class mapping & reclassification

Navigate: All > Configuration > CI Class Manager
1) Browse hierarchy — note "cmdb_ci_server" parent of Linux/Windows/Unix
2) Pick CI from list → "Suggest reclassification"
3) Confirm → IRE re-validates → no duplicates created

Recipe E — Attribute completeness audit

// Script Include: report completeness per class
var classes = ['cmdb_ci_server', 'cmdb_ci_appl', 'cmdb_ci_database', 'cmdb_ci_service_auto'];
var required = {
 cmdb_ci_server: ['name', 'serial_number', 'os', 'ip_address', 'owned_by'],
 cmdb_ci_appl: ['name', 'version', 'install_status', 'owned_by'],
 cmdb_ci_database: ['name', 'version', 'instance', 'owned_by'],
 cmdb_ci_service_auto: ['name', 'service_classification', 'business_criticality', 'owned_by']
};
classes.forEach(function(cls) {
 var ga = new GlideAggregate(cls);
 ga.addAggregate('COUNT');
 ga.query(); ga.next();
 var total = ga.getAggregate('COUNT');
 var missing = 0;
 required[cls].forEach(function(attr) {
 var miss = new GlideRecord(cls);
 miss.addQuery(attr, '');
 miss.query();
 missing += miss.getRowCount();
 });
 gs.info(cls + ' completeness: ' + total + ' CIs, missing-attr instances: ' + missing);
});

17.4 CSDM — model a real service (HR Leave Portal)

CSDM 4 domains (Foundation / Design / Build / Manage):

Model the “HR Leave Portal” — top to bottom:

Business Application (cmdb_ci_business_app)
 HR Leave Portal
 └── Service Offering (cmdb_ci_service_offering)
 HR Leave — Premium 24x7
 └── Application Service (cmdb_ci_service_auto)
 x_786686_hr_leave (Scoped App)
 ├── Web tier → cmdb_ci_web_server (Nginx)
 ├── App tier → cmdb_ci_appl (ServiceNow scope)
 ├── DB tier → cmdb_ci_database (Postgres / Mongo / mysql)
 └── Identity → cmdb_ci_appl (Okta / Azure AD)

Relationships used:

CSDM يعطي نموذجًا واحدًا متفقًا عليه — لا تختصر طبقات Design لأنها التي يربط بها العمل والخدمات بـ ITOM.

17.5 CI Class Manager — custom class for HR Leave

Navigate: All > Configuration > CI Class Manager
1) Pick parent: cmdb_ci_application_software
2) "Create child class": cmdb_ci_hr_leave_component
3) Add attributes:
 - tier (choice: web / app / db)
 - environment (choice: dev / uat / prod)
 - app_scope (string default x_786686_hr_leave)
 - cost_center (reference cmn_cost_center)
4) Save → triggers schema change (review with admin)
5) Add IRE: independent attr "name + environment"
6) Add suggested reclassification rule from cmdb_ci_appl

MID Server integration check:

Navigate: All > MID Server > Servers
Verify status: Up
Capabilities: ALL (or specific: Discovery, Service Mapping)
Configure Parameters: mid.proxy.host / port if behind proxy

17.6 Service Mapping — top-down vs bottom-up

Reconcile gaps:

Open App Service "HR Leave"
Side panel → "Map status"
Expected: 4 CIs, mapped: 3
Missing: DB tier
Cause: credential expired
Fix: refresh credential, re-run Service Mapping

Troubleshoot Service Mapping failures:

1) Run "Test Mapping" from the App Service form
2) Open mapping log → look for "Connection refused" or "Auth failed"
3) Validate MID can reach all hops (mid_server > Run Diagnostics)
4) Inspect Pattern Designer if pattern not catching components

17.7 Discovery probe/sensor design (overview)

Sample flow for a Linux server:
schedule fires → MID gets IP → SSH probe lands → sensor parses → classifier picks cmdb_ci_linux_server → IRE upserts CI → relationships added (Runs on hardware, hosts apps)

الاكتشاف يبدأ من جدول الخدول → MID → probe → sensor → IRE → CI نهائي. أي عطل ينعكس على Health.

17.8 Quick navigation cheatsheet

cmdb_ci.list → all CIs
cmdb_rel_ci.list → all relationships
/now/cmdb → CMDB Workspace
/now/cmdb/ci-class-manager → class manager
sys_db_object.list (filter table starts with cmdb_ci) → all CI tables
cmdb_health_metric.list → metric records
cmdb_ci_business_app.list → CSDM Business Apps
cmdb_ci_service_auto.list → Application Services (CSDM)
cmdb_ci_service_offering.list → Service Offerings
mid_server.list → MID Servers
discovery_status.list → Discovery runs
discovery_schedule.list → schedules
sa_pattern.list → Service Mapping patterns
cmdb_data_certification.list → owner attestation

17.9 Top 20 CMDB scripts — copy/paste ready

All scripts in scope global. Verify in dev before scheduling.
Add try/catch when scheduling daily.

1) Detect duplicates via IRE rule (manual scan)

// Background script — find CIs sharing the same serial_number
var ga = new GlideAggregate('cmdb_ci');
ga.addNotNullQuery('serial_number');
ga.addAggregate('COUNT', 'serial_number');
ga.groupBy('serial_number');
ga.addHaving('COUNT', '>', 1);
ga.query();
while (ga.next()) {
 var s = ga.serial_number.toString();
 gs.info('Duplicate serial ' + s + ' has ' + ga.getAggregate('COUNT', 'serial_number') + ' CIs');
 var dup = new GlideRecord('cmdb_ci');
 dup.addQuery('serial_number', s);
 dup.query();
 while (dup.next()) gs.info(' - ' + dup.number + ' ' + dup.name + ' class=' + dup.sys_class_name);
}

2) Find blast radius (downstream impact of a CI)

function findBlastRadius(ciId, maxDepth) {
 var visited = {};
 var queue = [{id: ciId, depth: 0}];
 var result = [];
 while (queue.length) {
 var n = queue.shift();
 if (visited[n.id] || n.depth > (maxDepth || 4)) continue;
 visited[n.id] = true;
 if (n.depth > 0) result.push(n.id);
 var rel = new GlideRecord('cmdb_rel_ci');
 rel.addQuery('parent', n.id);
 rel.query();
 while (rel.next()) {
 queue.push({id: rel.child.toString(), depth: n.depth + 1});
 }
 }
 return result;
}
var blast = findBlastRadius('<ci_sys_id>', 4);
gs.info('Blast radius: ' + blast.length + ' downstream CIs');

3) Bulk import CIs from CSV via Import Set + Transform Map

// Background script — programmatic insert into staging then transform
var STAGING = 'u_imp_server'; // your staging table
var rows = [
 {u_name:'web01.prod', u_serial:'AB123', u_ip:'10.0.0.1', u_os:'Linux'},
 {u_name:'web02.prod', u_serial:'AB124', u_ip:'10.0.0.2', u_os:'Linux'}
];
rows.forEach(function(r) {
 var gr = new GlideRecord(STAGING);
 gr.initialize();
 for (var k in r) gr.setValue(k, r[k]);
 gr.insert();
});
// Now run Transform Map manually:
// All > System Import Sets > Run Transform → pick your map → coalesce on serial_number
gs.info('Staged ' + rows.length + ' rows in ' + STAGING);

4) Reclassify CIs (Server → Linux Server)

// Switch a CI's class
var gr = new GlideRecord('cmdb_ci_server');
gr.addQuery('os', 'STARTSWITH', 'Linux');
gr.addQuery('sys_class_name', 'cmdb_ci_server'); // generic only
gr.setLimit(50);
gr.query();
while (gr.next()) {
 gr.sys_class_name = 'cmdb_ci_linux_server';
 gr.update();
}
gs.info('Reclassified ' + gr.getRowCount());

5) Data quality score per class

// Compute basic quality score: % CIs with name, owned_by, serial_number, location
var classes = ['cmdb_ci_server', 'cmdb_ci_appl', 'cmdb_ci_database'];
classes.forEach(function(cls) {
 var t = new GlideAggregate(cls); t.addAggregate('COUNT'); t.query(); t.next();
 var total = parseInt(t.getAggregate('COUNT')) || 0;
 if (!total) return;
 function pctMissing(attr) {
 var m = new GlideRecord(cls);
 m.addQuery(attr, '');
 m.query();
 return Math.round((m.getRowCount() / total) * 100);
 }
 var sumMissing = pctMissing('name') + pctMissing('owned_by') + pctMissing('serial_number') + pctMissing('location');
 var score = Math.max(0, 100 - Math.round(sumMissing / 4));
 gs.info(cls + ' quality score: ' + score + ' (' + total + ' CIs)');
});

6) Stale CI detector (no update > 90d)

// Scheduled Job — weekly
var stale = new GlideRecord('cmdb_ci');
stale.addQuery('sys_updated_on', '<', gs.daysAgo(90));
stale.addQuery('install_status', '1'); // installed
stale.query();
while (stale.next()) {
 stale.work_notes = 'Stale: no update >90 days — verify with owner.';
 stale.update();
 gs.eventQueue('cmdb.stale.ci', stale, stale.owned_by.toString(), '');
}

7) Orphan CI detector (no relationships)

// Find CIs with zero relationships
var ci = new GlideRecord('cmdb_ci');
ci.addQuery('install_status', '1');
ci.setLimit(500);
ci.query();
var orphans = [];
while (ci.next()) {
 var rel = new GlideRecord('cmdb_rel_ci');
 rel.addQuery('parent', ci.sys_id).addOrCondition('child', ci.sys_id);
 rel.query();
 if (!rel.hasNext()) orphans.push(ci.number + ' ' + ci.name);
}
gs.info('Orphans: ' + orphans.length);
orphans.slice(0, 50).forEach(function(o){ gs.info(' ' + o); });

8) CMDB Health Dashboard refresher

// Scheduled Job — nightly 01:00
var indicator = new GlideRecord('pa_indicators');
indicator.addQuery('name', 'STARTSWITH', 'CMDB');
indicator.query();
while (indicator.next()) {
 new sn_pa.PADataCollector().collectIndicator(indicator.sys_id.toString());
}
gs.info('Refreshed ' + indicator.getRowCount() + ' CMDB indicators');

9) Mass-update CI owner from AD group

// Map all CIs of class X to the group manager
var grp = new GlideRecord('sys_user_group');
if (grp.get('name', 'HR Leave App Owners')) {
 var ci = new GlideRecord('cmdb_ci_hr_leave_component');
 ci.query();
 while (ci.next()) {
 ci.owned_by = grp.manager.toString();
 ci.support_group = grp.sys_id.toString();
 ci.update();
 }
 gs.info('Updated ' + ci.getRowCount() + ' CIs');
}

10) CI lifecycle state transitions

// Move retired CIs to operational_status=Retired and unlink from active services
var retire = new GlideRecord('cmdb_ci');
retire.addQuery('install_status', '7'); // Retired
retire.addQuery('operational_status', '1'); // still operational — wrong
retire.query();
while (retire.next()) {
 retire.operational_status = 6; // Non-Operational
 retire.update();
}
gs.info('State-corrected: ' + retire.getRowCount());

11) Auto-create relationship from Service Map data

// Script Action — on insert into a custom mapping table
(function createRel(parentCi, childCi, relTypeName) {
 var t = new GlideRecord('cmdb_rel_type');
 if (!t.get('name', relTypeName)) return;
 var rel = new GlideRecord('cmdb_rel_ci');
 rel.addQuery('parent', parentCi);
 rel.addQuery('child', childCi);
 rel.addQuery('type', t.sys_id);
 rel.query();
 if (!rel.hasNext()) {
 var r = new GlideRecord('cmdb_rel_ci');
 r.initialize();
 r.parent = parentCi;
 r.child = childCi;
 r.type = t.sys_id;
 r.insert();
 }
})(current.u_parent, current.u_child, 'Depends on::Used by');

12) CI categorization via Predictive Intelligence

// On insert of a generic cmdb_ci, ask PI for class suggestion
(function classify() {
 if (current.sys_class_name != 'cmdb_ci') return;
 try {
 var pi = new sn_ml.SolutionStore();
 var solution = pi.get('cmdb_class_solution');
 if (!solution) return;
 var pred = solution.predict({short_description: current.name + ' ' + current.short_description});
 if (pred && pred.predicted && pred.confidence > 0.7) {
 current.sys_class_name = pred.predicted;
 current.work_notes = 'PI classified as ' + pred.predicted + ' (conf ' + pred.confidence + ')';
 }
 } catch (e) {
 gs.warn('PI classify failed: ' + e.message);
 }
})();

13) Audit log CI changes

// Business Rule — after update on cmdb_ci
// Capture critical attribute changes to a custom audit table
var WATCH = ['name', 'serial_number', 'ip_address', 'owned_by', 'operational_status', 'sys_class_name'];
WATCH.forEach(function(attr) {
 if (current[attr] != previous[attr]) {
 var a = new GlideRecord('u_cmdb_audit');
 a.initialize();
 a.u_ci = current.sys_id;
 a.u_attribute = attr;
 a.u_old_value = previous[attr];
 a.u_new_value = current[attr];
 a.u_changed_by = gs.getUserID();
 a.insert();
 }
});

14) Application Service auto-create from tag

// Scheduled Job — daily
// Group all CIs with the same tag:service=<x> into an Application Service
var tags = {};
var tagRec = new GlideRecord('label_entry');
tagRec.addQuery('label.name', 'service');
tagRec.query();
while (tagRec.next()) {
 var svc = tagRec.title.toString();
 if (!tags[svc]) tags[svc] = [];
 tags[svc].push(tagRec.table_key.toString());
}
Object.keys(tags).forEach(function(svc) {
 var svcCi = new GlideRecord('cmdb_ci_service_auto');
 if (!svcCi.get('name', svc)) {
 svcCi.initialize();
 svcCi.name = svc;
 svcCi.short_description = 'Auto-created from tag service=' + svc;
 svcCi.operational_status = 1;
 svcCi.insert();
 }
 tags[svc].forEach(function(memberCi) {
 var rel = new GlideRecord('cmdb_rel_ci');
 rel.addQuery('parent', svcCi.sys_id);
 rel.addQuery('child', memberCi);
 rel.query();
 if (!rel.hasNext()) {
 var r = new GlideRecord('cmdb_rel_ci');
 r.initialize();
 r.parent = svcCi.sys_id;
 r.child = memberCi;
 r.type = '0c5c1199c0a8010101e93f8d44b1cdb1'; // "Contains::Contained by"
 r.insert();
 }
 });
});

15) CMDB-to-spreadsheet diff for vendor reconciliation

// Compare CMDB to staged vendor sheet
var vendorTable = 'u_imp_vendor_assets'; // staged sheet
var vendor = new GlideRecord(vendorTable);
vendor.query();
while (vendor.next()) {
 var ci = new GlideRecord('cmdb_ci_hardware');
 ci.addQuery('serial_number', vendor.u_serial);
 ci.query();
 if (!ci.next()) {
 gs.info('Vendor has ' + vendor.u_serial + ' — missing in CMDB');
 } else if (ci.owned_by.toString() != vendor.u_owner.toString()) {
 gs.info('Owner mismatch on ' + vendor.u_serial + ' CMDB=' + ci.owned_by.getDisplayValue() + ' Vendor=' + vendor.u_owner.getDisplayValue());
 }
}

16) Detect CI without business_service / Application Service

var ci = new GlideRecord('cmdb_ci_appl');
ci.addQuery('install_status', '1');
ci.query();
var orphanApps = [];
while (ci.next()) {
 var rel = new GlideRecord('cmdb_rel_ci');
 rel.addQuery('child', ci.sys_id);
 rel.addQuery('parent.sys_class_name', 'IN', 'cmdb_ci_service_auto,cmdb_ci_service,cmdb_ci_business_app');
 rel.query();
 if (!rel.hasNext()) orphanApps.push(ci.name.toString());
}
gs.info('Apps without service: ' + orphanApps.length);
orphanApps.slice(0, 30).forEach(function(a){ gs.info(' ' + a); });

17) Bulk-archive retired CIs

// Run quarterly
var ret = new GlideRecord('cmdb_ci');
ret.addQuery('install_status', '7'); // Retired
ret.addQuery('sys_updated_on', '<', gs.daysAgo(180));
ret.query();
while (ret.next()) {
 // archive: remove relationships first
 var rel = new GlideRecord('cmdb_rel_ci');
 rel.addQuery('parent', ret.sys_id).addOrCondition('child', ret.sys_id);
 rel.query();
 rel.deleteMultiple();
 ret.deleteRecord();
}
gs.info('Archived ' + ret.getRowCount() + ' retired CIs');

18) Find all CIs owned by a leaving employee

// Used during offboarding
var leavingUserId = '<sys_id_of_user>';
var owned = new GlideRecord('cmdb_ci');
owned.addQuery('owned_by', leavingUserId).addOrCondition('managed_by', leavingUserId).addOrCondition('assigned_to', leavingUserId);
owned.query();
var list = [];
while (owned.next()) list.push(owned.number + ' ' + owned.name + ' (' + owned.sys_class_name + ')');
gs.info('CIs owned by user: ' + list.length);
list.forEach(function(x){ gs.info(' ' + x); });
// Next step: reassign to manager

19) Map CIs to KB articles

// Suggest KB articles for a given CI based on incident history
function ciToKbArticles(ciId, limit) {
 var inc = new GlideRecord('incident');
 inc.addQuery('cmdb_ci', ciId);
 inc.addNotNullQuery('kb_knowledge');
 inc.orderByDesc('opened_at');
 inc.setLimit(limit || 10);
 inc.query();
 var seen = {};
 var kbs = [];
 while (inc.next()) {
 var k = inc.kb_knowledge.toString();
 if (k && !seen[k]) {
 seen[k] = true;
 kbs.push({sys_id: k, title: inc.kb_knowledge.getDisplayValue()});
 }
 }
 return kbs;
}
gs.info(JSON.stringify(ciToKbArticles('<ci_sys_id>'), null, 2));

20) CI suggestion via short description match

// Reusable Script Include — called from incident or change form
var CIShortDescMatcher = Class.create();
CIShortDescMatcher.prototype = {
 initialize: function() {},
 suggest: function(text) {
 var words = (text || '').toString().toLowerCase().split(/\W+/).filter(function(w){ return w.length > 3; });
 if (!words.length) return [];
 var enc = words.map(function(w){ return 'nameLIKE' + w; }).join('^OR');
 var ci = new GlideRecord('cmdb_ci');
 ci.addQuery('operational_status', '1');
 ci.addEncodedQuery(enc);
 ci.setLimit(5);
 ci.query();
 var out = [];
 while (ci.next()) out.push({sys_id: ci.sys_id.toString(), name: ci.name.toString(), cls: ci.sys_class_name.toString()});
 return out;
 },
 type: 'CIShortDescMatcher'
};

17.10 Power-user keyboard & URL tips

URLs المباشرة أسرع من التنقل بالقوائم بعد أن تحفظ الجدول.

§18 — From-Scratch Implementation (Day 0 → Day 30)

30-day CMDB build plan with CSDM as the backbone.
خطة 30 يومًا لبناء CMDB من الصفر بالاعتماد على CSDM.

18.1 Day 0 — Prep (the week before)

CSDM strategy (pick a starting tier):

Crawl → Foundation only (users, locations, departments)
Walk → + Design (Business Apps, Service Offerings, App Services)
Run → + Build (technical CIs, relationships)
Fly → + Manage (linked incidents/changes), Discovery + Service Mapping
Default for HR Leave App: start Walk; reach Run by Day 20

Data sources inventory:

Ownership model:

Tier Owner Cadence
Business App Business product Annual attest
Service Offer Service owner Quarterly attest
App Service Engineering lead Quarterly attest
Server Server ops Monthly via Discovery
Database DBA team Monthly
Workstation IT Asset Quarterly

⚠️ Without owners assigned, Day 14 attestation step fails.

18.2 Day 1 — Activate CMDB plugins, IRE, CI Class Manager, MID Server install (Windows)

Plugins:

Navigate: All > System Definition > Plugins
- com.snc.cmdb (Configuration Management Database)
- com.snc.cmdb_workspace (CMDB Workspace)
- com.snc.cmdb_ci_class_manager (CI Class Manager)
- com.snc.identification_reconciliation (IRE)
- com.sn_cmdb_data_certification (Data Manager / certification)
- com.snc.cmdb.health (CMDB Health metrics)
- (if licensed) com.snc.discovery (Discovery)
- (if licensed) com.snc.service-mapping (Service Mapping)

MID Server install on Windows:

:: 1) On a Windows VM (server-grade, 4 vCPU, 8 GB RAM min)
:: 2) Navigate in ServiceNow: All > MID Server > Downloads → Windows 64-bit
:: 3) Extract: C:\ServiceNow\MID_Server\
:: 4) Edit config.xml
:: <parameter name="url" value="https://<your-instance>.service-now.com/" />
:: <parameter name="mid.instance.username" value="mid.user" />
:: <parameter name="mid.instance.password" value="<obfuscated>" />
:: <parameter name="name" value="MID-HR-Leave-01" />
:: 5) Run as service:
cd "C:\ServiceNow\MID_Server\agent"
installconf.cmd :: install Windows service
start.cmd :: start service
:: 6) Validate in ServiceNow: All > MID Server > Servers
:: Status should turn "Up" within 2 minutes.

⚠️ Never embed plain credentials in config.xml; use keystore and external secret store.

18.3 Day 2–3 — Foundation tables

Tables to populate first:

Navigate: System LDAP → Configure LDAP server → Schedule (nightly)
Mappings: AD user attrs → sys_user (sAMAccountName → user_name; mail → email; manager DN → manager)
Test transform: 50 users dry-run, then full

18.4 Day 4–5 — Core CI tables in scope, class hierarchy

Navigate: All > Configuration > CI Class Manager
Review hierarchy:
cmdb_ci
├── cmdb_ci_hardware
│ ├── cmdb_ci_server (Linux, Windows, Solaris, AIX)
│ ├── cmdb_ci_storage
│ └── cmdb_ci_network_gear
├── cmdb_ci_appl
│ ├── cmdb_ci_appl_dot_net
│ └── cmdb_ci_database
├── cmdb_ci_service_auto (Application Service)
├── cmdb_ci_service_offering
└── cmdb_ci_business_app

In-scope CI tables for HR Leave Portal:

18.5 Day 6–7 — Discovery setup

Navigate: All > Discovery > Schedules
Create:
 Name: "HR Leave Prod Subnet"
 IP range: 10.10.20.0/24
 MID server: MID-HR-Leave-01
 Schedule: Daily 03:00
 Credentials: SSH (linux.svc) + WMI (win.svc) + SNMPv3

Credentials (Vault recommended):

Navigate: All > Credentials
Type: SSH Username/Password
Name: "linux.svc PROD"
User: linux.svc
Tag: applies_to = MID-HR-Leave-01 only

MID Server clustering (HA):

Install MID #2 on a second VM, same config.xml but unique mid.instance.name
Group both MIDs into a Cluster:
 Navigate: All > MID Server > Clusters
 Add: MID-HR-Leave-01, MID-HR-Leave-02
 Mode: Load balancing

18.6 Day 8 — First Discovery run + results review

Trigger schedule manually → All > Discovery > Quick Discovery (use single IP first)
Watch: All > Discovery > Discovery Statuses
Expect: 100% Probes Complete; 0 unclassified; 0 errors after 2 runs

Common Discovery exceptions:

18.7 Day 9–10 — Service Mapping setup (top-down map of “HR Leave Portal”)

Navigate: All > Service Mapping > Services
New: "HR Leave Portal"
Entry point: https://hr.example.com (URL)
Discovery: pick MID
Run "Discover service" → traverses → builds map
Review: side panel topology
Save map → CIs created or matched (web/app/db tiers)

18.8 Day 11 — IRE rules & matching attributes

Navigate: All > Configuration > CI Identifiers
For cmdb_ci_server:
 Independent attrs (first priority): serial_number
 Dependent attrs (fallback): name + fqdn
For cmdb_ci_appl:
 Independent: name + install_directory
 Dependent: name + version + host
For custom cmdb_ci_hr_leave_component:
 Independent: name + environment
Test IRE: All > Configuration > CI Identifier Simulation → paste sample payload → confirm "match" vs "create"

18.9 Day 12–13 — Import from CMDB sources

Excel → Import Set → Transform:

1) System Import Sets → Load Data → Upload CSV
2) Create Transform Map: source u_imp_server → target cmdb_ci_server
3) Map fields: u_name → name, u_serial → serial_number, etc.
4) Coalesce on serial_number
5) Run Transform → review staging/target rows

AD groups → CI owners script — see §17.9 script #9.

AWS via spoke:

Plugin: AWS Service Management Connector
1) Configure AWS account credentials (IAM access key + secret)
2) Schedule: AWS Cloud Discovery
3) Result: cmdb_ci_compute (EC2), cmdb_ci_aws_lambda, cmdb_ci_rds_cluster, etc.
4) Tag strategy in AWS: service=HR-Leave env=prod app=hr_leave
 → use script §17.9 #14 to auto-group

18.10 Day 14 — CSDM Foundation populated

Acceptance:

- 100% sys_user from AD up to date
- All departments have manager assigned
- All locations have country + city
- All cost centers reference an owner
- core_company has primary contact for each vendor

Attest with Data Manager:

Navigate: All > Configuration > Data Certification → certification per group
Owners receive email; click link → confirm 10 sample records → digital sign-off

18.11 Day 15 — CSDM Design (Service Offerings, App Services)

Create Business App: "HR Leave Portal"
Owner: HR product mgr
Criticality: Tier 2 (employee-facing, non-revenue)
Compliance: GDPR + PDPL applicable
Lifecycle phase: In Production

Service Offerings (children):
- “HR Leave — Premium 24x7” SLA P1 4h
- “HR Leave — Standard 8x5” SLA P2 8h

Application Services (children of Service Offerings):
- x_786686_hr_leave (Scoped App)

18.12 Day 16–17 — CSDM Build (software + deployment)

Add to App Service "x_786686_hr_leave":
- cmdb_ci_appl : "HR Leave Web" runs on Nginx CI
- cmdb_ci_appl : "HR Leave Engine" runs on ServiceNow Tomcat container
- cmdb_ci_database : "hr_leave_db" Postgres 15
- cmdb_ci_appl : "Okta Federation" external identity
Relationships:
- Application Service "Contains" each component
- Component "Depends on" hardware/cloud CI
- Web "Sends data to" Engine
- Engine "Reads/Writes" Database

18.13 Day 18–19 — CSDM Manage (linkage to ITSM)

On incident form:
 Configuration item field → mandatory for category in (hardware, software, network)
 Affected CIs → side panel
On change_request:
 Configuration item → mandatory always
 Conflict detection enabled (ITSM §17.10.10)
On problem:
 Cmdb_ci required when known_error=true

Validate:

Pick a real incident → confirm CI populated → open Dependency View → see App Service ancestor → CSDM is paying off

18.14 Day 20 — CMDB Health Dashboard + Data Quality

Navigate: All > Configuration > CMDB Dashboard
Activate metrics:
- Completeness (per class)
- Correctness (IRE pass)
- Compliance (owner + class assigned)
- Staleness (no update 90d)
- Duplicate suspects
Set owners per metric (CI Owner role) → email reports weekly
Target Health Score: ≥ 80 by Day 30 (see §18.21)

18.15 Day 21–22 — Compliance, completeness, correctness audits

18.16 Day 23 — IRE rules for cloud (AWS/Azure/GCP)

Cloud CIs identifying attrs:
AWS → arn (independent)
Azure → resource_id (independent)
GCP → self_link (independent)
Test:
 - Insert EC2 with arn=arn:aws:ec2:us-east-1:111:instance/i-xxx → 1 CI
 - Re-run AWS Discovery → no duplicate
 - Change tag → CI updated, not duplicated

18.17 Day 24 — Tagging strategy & governance

Required tags:

env = dev | uat | prod
app = hr_leave | itsm | itam | ...
cost-center = CC1234
owner = user.email
classification = public | internal | confidential

Governance:

- Reject creation of cloud resources missing tags (cloud governance layer e.g. AWS SCP / Azure Policy)
- ServiceNow nightly check: untagged cloud CIs → notify owner
- Application Service auto-creation via §17.9 #14

18.18 Day 25 — Custom CI class for HR Leave components

Already created Day 5; verify:
- Inherits from cmdb_ci_application_software
- Attributes: tier, environment, app_scope, cost_center
- IRE rule: name + environment
- Suggested reclassification: from cmdb_ci_appl when scope=x_786686_hr_leave

Seed records (manual or import):

18.19 Day 26 — Relationships catalog

Navigate: All > Configuration > Relationship Types
Confirm above types exist (OOTB) and have correct labels (EN + AR if multilingual instance).

18.20 Day 27 — ACLs for sensitive CIs

⚠️ Avoid blanket cmdb_admin for staff; use data_steward for read-write narrowed to a class.

18.21 Day 28 — ATF: IRE rules + relationship integrity

Navigate: All > Automated Test Framework > Tests
Create:
T1 — Insert duplicate serial server → IRE rejects, no duplicate
T2 — Insert with all attrs → CI created, sys_class_name correct
T3 — Reclassify generic Server → Linux Server → child class updates
T4 — Add Depends-on relationship → cmdb_rel_ci row created
T5 — Delete CI with relationships → rel removed
T6 — Custom HR Leave class IRE: name+env coalesces correctly
T7 — Tag-based Application Service script (§17.9 #14) creates rel
T8 — Stale CI detector (§17.9 #6) flags >90d
T9 — Health dashboard renders all 5 metrics
T10 — Discovery patterns produce 0 unclassified for sample IP
Schedule: nightly 22:30

18.22 Day 29 — Training + ownership handover

Audiences (≤ 90 min each):
1) cmdb_admin / data_steward → Workspace, Health, Data Manager, IRE
2) CI Owners → quarterly attestation flow, edit rights
3) ITSM agents → how to pick a CI, dependency view, escalation
4) CSDM Architects → ongoing maintenance of Business App → App Service mapping
Deliverables:
- Slides EN + AR
- Recorded video (≤ 10 min)
- 1-page quick reference per audience

18.23 Day 30 — Go-Live + Hypercare

Sign-off pre-check:
[ ] CSDM modeled for top 5 services (incl. HR Leave Portal)
[ ] CMDB Health Score ≥ 80 (see formula §18.24)
[ ] 0 confirmed duplicate serials in prod scope
[ ] Discovery green for 3 consecutive nights
[ ] Service Mapping green for HR Leave Portal
[ ] All Application Services have owner + criticality
[ ] ATF nightly pass rate 100% for prior 3 nights
[ ] ACLs tested with itil and data_steward impersonations
[ ] Update Set "CMDB_Baseline_v1" exported
Hypercare:
- Daily 15-min standup week 1
- Twice-daily Health check
- Owner outreach for any metric < target
- Fix-forward via short Change requests

18.24 CMDB Health Score — target ≥ 80

Formula (weighted average of 5 metrics, each 0–100):

Health = 0.30*Completeness + 0.25*Correctness + 0.20*Compliance + 0.15*Staleness_inv + 0.10*Duplicate_inv

Where:
- Completeness = % required attrs filled per class, averaged
- Correctness = IRE pass rate over last 30 days
- Compliance = % CIs with owner_by AND non-generic sys_class_name
- Staleness_inv = 100 - % stale (sys_updated_on < -90d)
- Duplicate_inv = 100 - (confirmed_duplicates / total_cis * 100)

Example numbers for HR Leave scope at Day 30:
- Completeness = 92
- Correctness = 96
- Compliance = 88
- Staleness_inv = 90
- Duplicate_inv = 99
- Health = 0.3092 + 0.2596 + 0.2088 + 0.1590 + 0.10*99 = 92.0 ✅ (≥ 80) — لو حاصلك أقل من 80، تابع: أولًا اكتمال البيانات، ثم تعيين المالكين، ثم تنظيف الـ stale.

18.25 Common pitfalls + fixes

18.26 Final CMDB implementation checklist

• [ ] §18.1 Strategy + sources + owners agreed
• [ ] §18.2 Plugins active; MID Server up
• [ ] §18.3 Foundation tables populated via LDAP
• [ ] §18.4 Class hierarchy reviewed, in-scope classes locked
• [ ] §18.5 Discovery schedule + credentials
• [ ] §18.6 First Discovery run green
• [ ] §18.7 Service Mapping HR Leave Portal built top-down
• [ ] §18.8 IRE rules per class, simulation tested
• [ ] §18.9 Excel/AD/AWS imports validated
• [ ] §18.10 CSDM Foundation certified
• [ ] §18.11 CSDM Design (Business App + Service Offer + App Service)
• [ ] §18.12 CSDM Build (technical CIs and relationships)
• [ ] §18.13 CSDM Manage (ITSM linkage live)
• [ ] §18.14 CMDB Health dashboard activated
• [ ] §18.15 Compliance audits passing
• [ ] §18.16 Cloud IRE rules
• [ ] §18.17 Tagging governance enforced
• [ ] §18.18 Custom HR Leave class seeded
• [ ] §18.19 Relationships catalog confirmed
• [ ] §18.20 ACLs hardened
• [ ] §18.21 ATF GREEN for 3 nights
• [ ] §18.22 Training delivered + recordings
• [ ] §18.23 Go-Live + hypercare runbook
• [ ] §18.24 Health Score ≥ 80
• [ ] §18.25 Pitfalls scan complete — لا تذهب لـ ITSM Go-Live قبل اكتمال هذه القائمة — CMDB هو الأساس الذي يقف عليه كل شيء.

§19 — CIS-DF (CMDB) Exam & Z-to-Hero Feature Labs

§19 — امتحان CIS-DF (CMDB) ومختبرات من الصفر إلى الاحتراف

19.1 Exam bank linkage — Your 180-question study guide

Bank file: C:\SVCProject\SERVICENOW_CIS_DF_CMDB_STUDY_GUIDE.md (146 KB, 180 questions)

This file covers your 157 questions + 23 additional Zurich-aligned questions. Use it as the primary practice resource. — ملف بنك الأسئلة في الجذر — C:\SVCProject\SERVICENOW_CIS_DF_CMDB_STUDY_GUIDE.md يحوي 180 سؤالاً (مما يشمل الـ 157 التي تذكرتها).

19.2 Question-to-Lab matrix (Z-to-Hero)

Each lab maps to a question range — do the lab, then answer the corresponding questions:

Total: 25 labs covering all 180 questions across 6 exam domains.

19.3 Top 30 quick-recall facts (must memorize for CIS-DF)

1. CMDB table prefix: cmdb_ci_* (CIs), cmdb_rel_ci (relationships)
2. CSDM domains: Foundation, Design, Build, Manage (memorize this order!)
3. Lifecycle Stage ≠ Lifecycle Status (Stage = strategic; Status = operational)
4. IRE Identifier: independent (1 attribute) or dependent (parent + attributes)
5. Reconciliation: source priority per attribute, not per record
6. Multisource: “Last wins” is NOT the default — explicit priority is the default
7. Discovery output: discovery_messages → IRE → CMDB
8. MID Server: needed for on-prem; not for SaaS
9. Service Graph Connector: Workday, ServiceNow, AWS connectors — standardized ingestion
10. CMDB Health = C³: Completeness + Compliance + Correctness
11. Completeness: required attributes filled
12. Compliance: CI classes used correctly
13. Correctness: no duplicates, valid relationships
14. Audit (cmdb_audit): only for CIs with audit enabled
15. Tags: applied via CMDB Tagging app
16. Authoritative Source: defines who can update which fields
17. Sys Class Name: drives polymorphism in CMDB
18. Relationship types: stored in cmdb_rel_type (Runs On, Depends On, etc.)
19. Service Mapping: top-down pattern-based discovery
20. Service Graph Map: Application Service ↔ CIs ↔ Infrastructure
21. CMDB Query Builder: visual query for navigating relationships
22. Unified Map: visual representation of Application Service
23. Dependency Views (legacy): replaced by Unified Map in newer releases
24. CMDB Workspace: /now/cmdb (URL may vary)
25. Identification Rule API: IRESearchEngine, IRECommand
26. Reconciliation Rule API: handled by IRE backbone
27. CI Class Manager: define new CI classes + extend
28. Data Manager: archive + delete stale CIs (compliance lifecycle)
29. CSDM Best Practice: don’t put apps in Infrastructure domain
30. Common error: putting Application Service in Build domain (it’s Design)

19.4 Sample CIS-DF questions with explanations (10 examples)

Q1. In CMDB IRE, which option best describes an Independent Identifier?
A. An identifier that uses parent CI attributes
B. An identifier that uses one or more attributes of the CI itself
C. An identifier that requires Service Mapping
D. An identifier inherited from cmdb_ci_class_manager

Answer: B
Explanation: Independent identifiers use the CI’s own attributes (e.g., serial number for hardware). Dependent identifiers require a parent CI (e.g., disk depends on computer).

Q2. What is the correct CSDM domain order?
A. Build → Design → Foundation → Manage
B. Foundation → Design → Build → Manage
C. Design → Foundation → Manage → Build
D. Manage → Build → Design → Foundation

Answer: B
Explanation: Foundation (organizations, locations, contacts) → Design (services, applications, technical services) → Build (infrastructure CIs) → Manage (incidents, changes, etc. — operational data).

Q3. When two sources update the same CI’s os_version attribute with different values, which wins by default?
A. The most recently updated source
B. The source with the highest configured priority for os_version
C. The source that discovered the CI first
D. Both are kept; an issue is created

Answer: B
Explanation: Multisource CMDB uses per-attribute source priority. Last-wins is NOT the default.

Q4. Which Service Graph Connector pattern correctly enriches HR Profile CIs from Workday?
A. Custom REST script in cmdb_ci_person
B. Workday SGC + IRE rule on employee_number
C. Import Set with daily transform
D. SOAP integration with manual mapping

Answer: B
Explanation: SGC is the modern, governed path. IRE on employee_number ensures idempotency.

Q5. What does CMDB Health Completeness measure?
A. Number of CIs in production
B. % of required attributes populated for in-scope CIs
C. % of CIs without duplicates
D. % of CIs with correct class

Answer: B
Explanation: Completeness = required attributes filled. Correctness = no duplicates. Compliance = correct class.

Q6. A CI has been duplicated 5 times due to a discovery misconfiguration. Best remediation?
A. Manually delete all but the oldest
B. Run de-dup utility based on IRE identifier rules
C. Mark all 5 as retired
D. Update the discovery pattern, leave duplicates

Answer: B
Explanation: Use the de-dup utility based on IRE rules to merge duplicates. Manual deletion loses history.

Q7. Which is NOT a recommended approach for adding a custom CI class?
A. Use CI Class Manager
B. Extend from the closest base class
C. Add to Global scope to ensure visibility
D. Define IRE identifier for the new class

Answer: C
Explanation: Custom CI classes should be in a scoped app, not Global, to follow ServiceNow best practices.

Q8. What field on cmdb_ci_application_service distinguishes it from cmdb_ci_service?
A. service_classification
B. business_criticality
C. lifecycle_status
D. business_service_type

Answer: A
Explanation: service_classification = ‘application_service’ differentiates from business_service.

Q9. Why use Unified Map instead of legacy Dependency Views?
A. Faster rendering
B. Better mobile support
C. Supports multi-level relationships with filters
D. All of the above

Answer: D

Q10. Which APIs are recommended for programmatic CI creation respecting IRE?
A. Direct GlideRecord insert on cmdb_ci
B. IRE Command API (new IRECommand()…)
C. CMDB Service Graph API (/api/now/cmdb)
D. Both B and C

Answer: D
Explanation: Direct GlideRecord bypasses IRE; both IRE Command API and CMDB Service Graph API enforce identifier rules.

19.5 Lab → Question quick-jump table

19.6 Z-to-Hero day plan (1 full day on CMDB)

End-of-day deliverable:
- Update Set CMDB_Day8
- CMDB Health screenshot
- 180/180 questions reviewed (at least flagged)
- Confidence score per domain

19.7 What “Hero” looks like for CMDB

A CMDB hero can:
- Design IRE identifier rules for new classes
- Resolve multisource conflicts via priority matrix
- Explain CSDM 4 domains to a junior dev in 5 minutes
- Diagnose Health failures and fix them
- Build a custom Service Mapping pattern
- Write IRE Command API calls programmatically
- Govern data quality via Data Manager
- Migrate from legacy to CSDM model
- Pass CIS-DF with ≥85% on first attempt

Hands-on Labs — مختبرات عملية

Step-by-step labs for PDI / Australia instance. Replace {BASE} with your instance URL.
مختبرات خطوة بخطوة — استبدل {BASE} برابط نسختك.

1. Lab 1 — Manual CI / CI يدوي — Create server CI at {BASE}/cmdb_ci_server.do?sys_id=-1.

2. Lab 2 — Relationships / علاقات — Link application CI Runs on server CI.

3. Lab 3 — IRE rule / قاعدة IRE — Configure identifier at {BASE}/cmdb_identifier_entry_list.do.

4. Lab 4 — Import set / استيراد — Load CSV via {BASE}/sys_import_set_list.do; transform to cmdb_ci.

5. Lab 5 — CMDB Health / صحة CMDB — Review dashboard at {BASE}/now/cmdb-health/home.

6. Lab 6 — Dependency map / خريطة اعتماد — Open Dependency View from CI record.

7. Lab 7 — Reconciliation / مطابقة — Set source priority for Discovery vs manual.

8. Lab 8 — Service model / نموذج خدمة — Create Application Service at {BASE}/cmdb_ci_service_list.do.

Best Practices — أفضل الممارسات

Deployment Checklist — قائمة النشر

Direct URLs Quick Reference