ITOM — IT Operations Management (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 / ITOM Professional Implementer & Interview Guide
الأسلوب: عربية + إنجليزية تكمّلان بعضهما — بدون ترجمة حرفية لأسماء الشاشات.
Interview deep revision:
File: ../interview/MODULES_INTERVIEW_REVISION.md (§ ITOM)

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

ملخص في سطر: اكتشاف البنية التحتية ومراقبة الأحداث — الجسر بين الشبكة وCMDB.

وصف مختصر: يشرح تثبيت MID، بيانات الاعتماد، نطاق IP، جداول Discovery، اختياري Event→Incident وService Mapping. يكمّل CMDB.md.

1) Overview & Business Value

ITOM automates discovery, monitoring, and service visibility for infrastructure. — ITOM = اكتشاف + مراقبة + ربط الخدمات + CMDB. بدون ITOM تملأ CMDB يدويًا — بطيء وغير دقيق.

Core applications in ITOM suite:
- Discovery — finds servers, apps, network devices automatically.
- Service Mapping — maps application services top-down.
- Event Management — correlates alerts/events from monitoring tools.
- Cloud Discovery — AWS, Azure, GCP resources.
- Operational Intelligence — analytics on operational data.
- Agent Client Collector (ACC) — lightweight discovery agent.

Relationship to CMDB: — Discovery يغذّي CMDB. Service Mapping يبني Application Services. Event Management يربط alerts بـ CIs.

2) Architecture & Data Model

MID Server (on-prem bridge)
 ↓ probes/sensors/patterns
Discovery Schedule → discovers CIs
 ↓ IRE reconciles
CMDB (cmdb_ci_*)
 ↓
Service Mapping → cmdb_ci_service_auto
 ↓
Event Management → em_alert, em_event
 ↓
ITSM (incident on CI) / Change impact

Key tables:

3) Plugins & Activation

How to activate:

1. Navigate: All > System Definition > Plugins — Open direct
2. Search plugin name → Activate.
3. For licensed apps:
   Navigate: All > System Applications > All Available Applications > All — Open direct
4. Guided Setup:
   Navigate: All > Guided Setup > ITOM or Discovery — Open direct

4) Guided Setup & All Options

Sections:
- MID Server installation & validation.
- Credentials (Windows, SSH, SNMP, vCenter, cloud).
- Discovery Schedules & IP ranges.
- Classification & probes/sensors.
- Service Mapping entry points.
- Event connectors & rules.
- Cloud accounts.

Important navigation:

5) End-to-End Process Cycle

Install MID Server (Windows/Linux)
 → Validate MID (heartbeat in ecc_queue)
 → Create Credentials (domain/SSH/SNMP)
 → Define IP Ranges / Networks
 → Create Discovery Schedule (daily/weekly)
 → Run Discovery → CIs created/updated via IRE
 → (Optional) Service Mapping from entry points
 → (Optional) Event connectors ingest alerts
 → Event rules correlate → em_alert
 → Alerts create/link incidents (ITSM)
 → CMDB Health monitors data quality

6) Development

Scheduled script — alert to incident (concept)

// after em_alert created, optional BR creates incident
var inc = new GlideRecord('incident');
inc.initialize();
inc.short_description = 'Alert: ' + current.getDisplayValue('source');
inc.cmdb_ci = current.getValue('cmdb_ci');
inc.impact = 2;
inc.urgency = 2;
inc.insert();

Development topics:
- Discovery patterns (Pattern Designer).
- Identification/Reconciliation (shared with CMDB).
- Event rules & correlation filters.
- Transform maps for external CMDB feeds.
- MID Server script includes (rare — usually config).

7) Administration

Key roles:
- discovery_admin — Discovery configuration.
- evt_mgmt_admin — Event Management.
- service_mapping_admin — Service Mapping.
- cmdb_admin — CMDB (overlaps).

8) Hands-on Labs

Lab 1 — MID Server:
1. Download MID from instance.
2. Install on Windows server.
3. Validate in All > MID Server > Servers. — Open direct

Lab 2 — Discovery:
1. Create credential.
2. Create IP range.
3. Create schedule → Run now.
4. Check discovery_status and new CIs.

Lab 3 — Service Mapping:
1. Define entry point (URL or process).
2. Run mapping → view Application Service.

Lab 4 — Event Management:
1. Create connector (or use demo).
2. Ingest test event → verify em_event → em_alert.

9) Best Practices & Common Mistakes

Best practices:
- One MID per network zone (firewall rules).
- Use least-privilege credentials.
- Let IRE handle identity — don’t duplicate CIs manually.
- Map services after Discovery stabilizes.

Common mistakes:
- MID not validated (wrong URL/proxy).
- Discovery without credentials.
- Ignoring CMDB Health after Discovery.
- Service Mapping before Discovery completes.

10) CIS / Interview Focus

High-yield:
- MID Server purpose & ecc_queue.
- Discovery vs Service Mapping vs Event Management.
- Probes vs sensors vs patterns.
- IRE role in Discovery.
- em_event vs em_alert correlation.
- Cloud Discovery vs traditional Discovery.
- Integration with ITSM (CI on incident, alert→incident).

11) Portals, Workspaces, Role Hierarchy & Feature Catalog

Portals & Workspaces

Role Hierarchy

admin
└─ discovery_admin / evt_mgmt_admin
 └─ itil (consume CIs/alerts in ITSM)

Feature Catalog

• Discovery (schedules, credentials, MID, patterns).
• Service Mapping (top-down application services).
• Event Management (connectors, correlation, alerting).
• Cloud Discovery (AWS/Azure/GCP).
• Operational Intelligence.
• Agent Client Collector.
• Integration with CMDB Health & ITSM.

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

Application Menus map

All > Discovery
 ├─ Home / Schedules / Status / Credentials
 ├─ Networks / IP Ranges
 └─ Probes and Sensors / Classification
All > MID Server > Servers
All > Service Mapping
All > Event Management
 ├─ Connectors / Rules / Alerts
 └─ Administration
All > Pattern Designer

Build order

1. MID Server install + validate.
2. Credentials + IP ranges.
3. Discovery schedules → populate CMDB.
4. IRE rules verified (see CMDB.md).
5. Service Mapping (if licensed).
6. Event connectors + correlation rules.
7. ITSM integration (alert→incident, CI on forms).
8. Dashboards + CMDB Health remediation.

Study path:
File: ../interview/00_MASTER_DEV_ADMIN_INTERVIEW.md

13) Options & Instance Notes

14) Implementation Scenarios, Options, Best Practices & Customizations

Playbook: MODULE_IMPLEMENTATION_PLAYBOOK.md → ITOM

14.1 Scenarios

14.2 Options matrix

14.3 Plugins (order)

1. com.snc.discovery 2. com.snc.service-mapping 3. com.snc.sa.server (events) 4. Cloud plugins (AWS/Azure/GCP)

14.4 Roles

discovery_admin, evt_mgmt_admin, service_mapping_admin, cmdb_admin.

14.5 Common developments

Custom Discovery patterns, event rules/filters, alert-to-incident automation, MID hardening, firewall documentation, ECC queue monitoring.

14.6 Best practices

Discovery before Service Mapping; validate MID heartbeat before schedules; CMDB Health after first discovery run.

14.7 Go-live

• [ ] MID validated (ecc_queue)
• [ ] Pilot IP range success
• [ ] IRE not creating duplicates
• [ ] Event connector test alert

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

Framework: MODULE_ZERO_TO_HERO_CONSULTING.md · Feeds CMDB.md

من تثبيت MID حتى اكتشاف + (اختياري) أحداث وخدمات.

15.1 Business goals

15.2 Phase 0 — Discover

Network zones, firewall rules, credential policy, discovery scope (IP ranges).

15.3 Phase 1 — Activate

com.snc.discovery, Service Mapping, Event Management (as licensed).

15.4 Phase 2 — MID Server (Week 2–3)

Download, install, validate heartbeat (ecc_queue), one MID per zone.

15.5 Phase 3 — Discovery (Week 3–6)

Credentials → IP ranges → schedule → run → review discovery_status → fix IRE duplicates.

15.6 Phase 4 — Optional Event Mgmt (Week 6–8)

Connectors, correlation rules, alert→incident Flow.

15.7 Phase 5 — Optional Service Mapping (Week 8–10)

Entry points, map application services, link to CMDB.

15.8 Phase 6 — UAT & go-live

Pilot subnet 100% discovered, CI accuracy sample, event test alert.

15.9 Phase 7 — Operate

Expand schedules, MID patching, CMDB Health after each run.

15.10 Master checklist

• [ ] MID prod-ready · [ ] Pilot discovery · [ ] CMDB Health · [ ] Runbook for ops

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

Requires CMDB.md · MID Server is the bridge between network and CMDB.

16.1 Business goals

Why buy ITOM: English: Humans cannot keep CMDB current at scale — Discovery + events do. — ITOM يملأ CMDB ويربط التنبيهات بالحوادث — بدونه البيانات قديمة.

16.2 Requirements

16.3 Consultation cycle

16.4 Options (A / B / C)

16.5 All pages (Navigate)

16.6 Full PDI lab (16 steps)

16.7 Sign-off

• [ ] MID hardened (service account, patches) · [ ] Pilot subnet ≥95% discovered · [ ] CMDB team accepts IRE outcomes · [ ] Prod firewall change ticket ready

§17 — Power User Playbook (ITOM)

Daily operating manual for Discovery, Event Management, Service Mapping & Cloud Ops.
دليل التشغيل اليومي لاكتشاف البنية، إدارة الأحداث، خرائط الخدمة، والسحابة.

17.1 Personas & Daily Mission

17.2 Day-in-Life — A Typical Tuesday

08:00 Check MID Server health → All > MID Server > Servers
 Filter: Status != Up → investigate any Down/Warning MIDs.

08:15 Review Discovery Schedules nightly run
→ All > Discovery > Discovery Status (last 24h) — Open direct
Look for: Completed with Errors, Stuck, Cancelled.

08:30 Alert Intelligence triage
→ All > Event Management > All Alerts (Critical, Open) — Open direct
Group by: CI, source, alert_group_id.

09:00 Open NOC bridge if P1 alert open > 15 min and no incident.

10:00 Service Map reconciliation
→ Pick one business service → verify topology vs reality.

11:00 Cloud Discovery review
→ Cloud Resources page, check delta since yesterday.
Tag governance: untagged > 5% → notify owner.

13:00 Pattern Designer — fix one failing probe surfaced in §17.3.

14:00 Capacity review — Operational Intelligence anomalies.

16:00 Update runbook with anything new learned. — دورة يوم نموذجي للمشغّل: فحص MID، مراجعة الاكتشاف الليلي، فرز التنبيهات، تسوية خرائط الخدمة، مراجعة السحابة، إصلاح نمط واحد، مراجعة السعة.

17.3 Discovery Admin Recipes

Recipe A — Add new IP range + credential (5 minutes)

1. Navigate: All > Discovery > Credentials → New. — Open direct
2. Pick Type (Windows / SSH / SNMPv3 / vCenter / WMI).
3. Fill user, password (or key), Applies to specific MID(s) if zone-scoped.
4. Click Test Credential → pick a known target IP → must return Success.
5. Navigate: All > Discovery > IP Networks → New. — Open direct
6. Fill CIDR (e.g. 10.20.0.0/24), MID Server, Discovery Schedule (optional).
7. Save → open a Discovery Schedule → add this network → Discover Now (small scope). — أضف بيانات اعتماد، اختبرها، أنشئ نطاق IP، اربطه بجدول، شغّل اكتشاف فوري على نطاق صغير.

Recipe B — Define new Pattern in Pattern Designer

1. Navigate: All > Pattern Designer. — Open direct
2. Click New Pattern → choose type (Infrastructure or Application).
3. Set CI Type (e.g. cmdb_ci_apache_web_server).
4. Add Identification Section (commands / WMI / SNMP / file parse) producing identification attributes.
5. Add Connection Section to find related CIs (TCP/UDP listening ports → process).
6. Use Debug mode → run on a test host via MID.
7. Validate parsed values appear in Pattern Result preview.
8. Save & publish → assign to Classification so future Discovery picks it up.

Common operations inside a pattern step:
- Parse Command Output (with delimiters / regex)
- Match (regex extract groups)
- Merge Table (combine into output variable)
- Set Parameter Value (assign to CI attribute)

أنشئ نمطًا، عيّن CI Type، أضف خطوات الهوية والاتصال، شغّل Debug، انشره ثم اربطه بالتصنيف.

Recipe C — Debug a failing probe via discovery_log

// Background script — last 24h failures grouped by sensor
var gr = new GlideAggregate('discovery_log');
gr.addQuery('sys_created_on', '>=', gs.beginningOfYesterday());
gr.addQuery('state', 'IN', 'error,warning');
gr.addAggregate('COUNT');
gr.groupBy('sensor');
gr.orderByAggregate('COUNT', 'sensor');
gr.query();
while (gr.next()) {
 gs.info('[discovery] sensor=' + gr.getValue('sensor') +
 ' failures=' + gr.getAggregate('COUNT'));
}

Steps:

1. Run the script above in All > Scripts - Background. — Open direct
2. Top offender → open discovery_log.list filtered by that sensor.
3. Inspect Message field → most common errors:
   - Insufficient privileges → fix credential mapping.
   - Could not classify → missing/wrong pattern.
   - Connection refused → firewall or service down.
4. Apply fix → re-run schedule on a single device. — شغّل السكربت لتجميع الفشل، افتح أعلى محسّس فاشل، اقرأ الرسالة، أصلح بيانات الاعتماد أو النمط أو جدار الحماية.

Recipe D — Rolling discovery (daily prod, weekly dev)

// Idempotent: create or update two schedules covering same MID
function upsertSchedule(name, mid, cron, runDuration) {
 var gr = new GlideRecord('discovery_schedule');
 gr.addQuery('name', name);
 gr.query();
 if (!gr.next()) {
 gr.initialize();
 gr.name = name;
 }
 gr.mid_server = mid;
 gr.run_type = 'periodically';
 gr.run_dayofweek = cron.dayOfWeek;
 gr.run_time = cron.runTime;
 gr.max_run_time = runDuration;
 gr.active = true;
 gr.update();
}

upsertSchedule(‘Prod Daily Servers’, ‘MID-PROD-01’,
{ dayOfWeek: ‘’, runTime: ‘01:00:00’ }, ‘04:00:00’);
upsertSchedule(‘Dev Weekly Servers’, ‘MID-DEV-01’,
{ dayOfWeek: ‘6’, runTime: ‘02:00:00’ }, ‘06:00:00’);

Then attach the right IP Networks to each schedule via the related list. — شغّل البرنامج لإنشاء جدولين: يومي للإنتاج وأسبوعي للتطوير. اربط النطاقات بكل جدول.

Recipe E — MID Server health check + selector strategy

1. Navigate: All > MID Server > Servers → look at Status, Validation, Last refreshed. — Open direct
2. Open MID → related list MID Server Issues must be empty (acknowledge or resolve).
3. Navigate: All > MID Server > Capabilities → MIDs grouped by ability (AWS, Azure, JDBC, Discovery, etc.). — Open direct
4. Selector strategy:
   - MID Selector at Discovery Schedule level (per zone).
   - MID Cluster with Capability-based load balancing for high volume.
   - Set mid.use.ip.ranges on each MID so only its zone reaches it.

// Lightweight heartbeat — alert if any MID hasn't responded > 5 min
var cutoff = new GlideDateTime();
cutoff.addSeconds(-300);
var gr = new GlideRecord('ecc_agent');
gr.addQuery('status', '!=', 'Up');
gr.query();
while (gr.next()) {
 gs.warn('[MID Health] ' + gr.name + ' status=' + gr.status +
 ' last=' + gr.last_refreshed);
}

افحص حالة كل MID، اربط النطاقات بمسؤولها، وفعّل اختيارًا على مستوى الجدول أو الكلستر.

17.4 Event Management Recipes

Recipe A — Connect external monitoring via Event Connector

Steps for Datadog (example):

1. Navigate: All > Event Management > Connectors > Connector Instances → New. — Open direct
2. Type: Datadog. Provide API Key and Application Key (encrypted credential record).
3. MID Server: choose MID with internet egress.
4. Source instance = your DD URL.
5. Save → Test Connector → ingest sample events to em_event.
6. After ingest, set up a Mapping Rule to map Datadog tags → CI lookup field (host). — أنشئ موصلًا لـ Datadog، اختبره، وضع قاعدة لمطابقة العائل مع CI.

Recipe B — Alert correlation by time + topology

1. Navigate: All > Event Management > Rules > Alert Correlation Rules. — Open direct
2. New rule:
   - Name: App stack correlation.
   - Group by: CI relationship (parent/child) and tag.
   - Time window: 5 minutes (sliding).
   - Condition: events of severity ≥ Major.
   - Action: create parent alert with severity = MAX(child).

// Example "Group Key" advanced script for correlation
(function() {
 var ciSysId = current.cmdb_ci.toString();
 var serviceMap = new GlideRecord('svc_ci_assoc');
 serviceMap.addQuery('ci', ciSysId);
 serviceMap.query();
 var key = 'CI:' + ciSysId;
 if (serviceMap.next()) key = 'SVC:' + serviceMap.service_id.toString();
 return key;
})();

Validate: trigger two alerts on parent + child within window → should result in 1 parent alert. — عرّف قاعدة تجميع تنبيهات بناءً على CI والخدمة خلال 5 دقائق وأرجع تنبيهًا أبًا واحدًا.

Recipe C — Suppress noise via Alert Rules

Examples of high-value Alert Rules:
- Suppress alerts on CIs in maintenance (CHG window).
- Suppress recurring "flap" alerts (>3 in 10 min).
- Auto-close info severity after 30 min if no related higher severity.

Background snippet to identify flapping CIs:

var gr = new GlideAggregate('em_alert');
gr.addQuery('sys_created_on', '>=', gs.minutesAgoStart(60));
gr.addAggregate('COUNT');
gr.groupBy('cmdb_ci');
gr.having('COUNT', '>', 10);
gr.query();
while (gr.next()) {
 gs.info('[flap] CI ' + gr.getDisplayValue('cmdb_ci') +
 ' raised ' + gr.getAggregate('COUNT') + ' alerts in last hour');
}

Recipe D — Auto-create incident from P1 alert

Flow Designer flow EM: P1 Alert → Incident:

Trigger: Record created or updated on em_alert
 Conditions: severity = Critical AND state = Open
Action 1: Look Up Records cmdb_ci on current.cmdb_ci
Action 2: Create Record incident:
 short_description = current.description
 cmdb_ci = current.cmdb_ci
 impact = 1, urgency = 1
 assignment_group = mapped from CI support_group
Action 3: Update Record em_alert:
 incident = result.incident.sys_id
 state = Acknowledged

Flow ينشئ حادثة من أي تنبيه حرج ويربطها بالـ CI ويسند الفريق المالك.

Recipe E — Self-healing subflow

Subflow: Restart Web Service on Linux
Inputs: ci (cmdb_ci_linux_server), service_name
Steps:
1. Run SSH (MID): "systemctl restart {{service_name}}"
2. Wait 30s
3. Poll port via SSH "ss -ltn | grep :443" → true/false
4. If healthy → close alert, post note "Auto-resolved"
5. If unhealthy → escalate, set alert severity Critical

Trigger: Alert Action Rule on em_alert where description CONTAINS “Apache down”. — Subflow إصلاح ذاتي يعيد تشغيل الخدمة عبر SSH ثم يتحقق من المنفذ ويغلق التنبيه عند النجاح.

17.5 Service Mapping Recipes

Recipe A — Top-down vs Bottom-up vs Tag-based

Navigate: All > Service Mapping > Services > Application Services → New → choose method. — Open direct

Recipe B — Reconcile gaps when Service Map shows missing nodes

1. Open Service Map → click missing relationship icon (greyed node).
2. Use Discover action → triggers Pattern on candidate host.
3. If still missing → check Traffic-based connections (sa_tcp_connection).
4. Background:

var gr = new GlideRecord('svc_ci_assoc');
gr.addQuery('service_id', '<service_sys_id>');
gr.query();
gs.info('Service contains ' + gr.getRowCount() + ' CIs');
var missing = new GlideRecord('sa_tcp_connection');
missing.addQuery('service', '<service_sys_id>');
missing.addNullQuery('to_ci');
missing.query();
gs.info('Unresolved TCP endpoints: ' + missing.getRowCount());

افحص الخريطة، شغّل Discover على العقد الناقصة، ثم راجع TCP غير المربوطة.

Recipe C — Trace from “Incident in app” → impacted CIs → impacted users

// Given incident with cmdb_ci set, walk service map
function impactReport(incidentSysId) {
 var inc = new GlideRecord('incident');
 if (!inc.get(incidentSysId) || !inc.cmdb_ci) return;
 var ci = inc.cmdb_ci.toString();
 var svc = new GlideRecord('svc_ci_assoc');
 svc.addQuery('ci', ci);
 svc.query();
 while (svc.next()) {
 var users = new GlideRecord('cmdb_rel_ci');
 users.addQuery('parent', svc.service_id.toString());
 users.addQuery('type.name', 'Used by::Uses');
 users.query();
 gs.info('Service ' + svc.service_id.getDisplayValue() +
 ' impacts ' + users.getRowCount() + ' users');
 }
}
impactReport('<sys_id>');

انطلق من الحادثة → الخدمة → المستخدمون المتأثرون.

17.6 Cloud Discovery Recipes

A — AWS connector

1. Navigate: All > Cloud Resources > Configuration > Service Accounts → New AWS account. — Open direct
2. Choose auth: IAM Role (cross-account) or Access Key.
3. Datacenter Type: AWS, Regions: select target regions.
4. Bind to MID with AWS capability.
5. Run discovery → CIs populate cmdb_ci_ec2_instance, cmdb_ci_vpc, etc.
6. Verify tag ingestion → cmdb_key_value.list related to the CI.

B — Azure ARM connector

1. App registration in Azure AD → record Tenant ID, Client ID, Client Secret.
2. Assign Reader + Cost Reader on target subscriptions.
3. Navigate: All > Cloud Admin Portal > Accounts → New Azure account. — Open direct
4. Validate connection → run discovery → CIs in cmdb_ci_azure_*.

C — GCP connector

1. Create GCP Service Account with Viewer + Billing Account Viewer.
2. Download JSON key → store as encrypted credential.
3. Configure connector → run discovery.

D — Tag-based ingestion + cost reporting

Map AWS tag cost_center → CMDB attribute u_cost_center via Cloud Discovery transformation:

// Inbound transform map script — cmdb_ci_ec2_instance
(function map(source, target) {
 var tags = JSON.parse(source.u_tags_json || '{}');
 if (tags.cost_center) target.u_cost_center = tags.cost_center;
 if (tags.environment) target.environment = tags.environment;
 if (tags.owner) target.assigned_to = tags.owner;
})(source, target);

Then build a Report on cmdb_ci_cloud_resource grouping by u_cost_center summing monthly_cost. — اربط تاج AWS بحقل CMDB، ثم أنشئ تقرير تكلفة شهري حسب مركز التكلفة.

17.7 Top 20 ITOM Scripts (working snippets)

1. Discovery schedule auto-create from IP range CSV

var data = [
 { name: 'Riyadh DC', cidr: '10.10.0.0/16', mid: 'MID-RUH' },
 { name: 'Jeddah DC', cidr: '10.20.0.0/16', mid: 'MID-JED' }
];
data.forEach(function(row) {
 var net = new GlideRecord('discovery_range_item');
 net.initialize();
 net.name = row.name;
 net.range = row.cidr;
 net.mid_server.setDisplayValue(row.mid);
 net.insert();
});

2. MID Server failover logic (Business Rule on ecc_agent)

(function executeRule(current, previous) {
 if (current.status != 'Down') return;
 var alt = new GlideRecord('ecc_agent');
 alt.addQuery('status', 'Up');
 alt.addQuery('mid_cluster', current.mid_cluster);
 alt.addQuery('sys_id', '!=', current.sys_id);
 alt.setLimit(1);
 alt.query();
 if (alt.next()) {
 var sched = new GlideRecord('discovery_schedule');
 sched.addQuery('mid_server', current.sys_id);
 sched.query();
 while (sched.next()) { sched.mid_server = alt.sys_id; sched.update(); }
 gs.warn('[MID Failover] reassigned schedules from ' + current.name + ' to ' + alt.name);
 }
})(current, previous);

3. Pattern result validator

function validatePatternResult(discoveryId) {
 var dl = new GlideRecord('discovery_log');
 dl.addQuery('discovery_id', discoveryId);
 dl.addQuery('state', 'error');
 dl.query();
 var fails = [];
 while (dl.next()) fails.push(dl.message + '');
 return { ok: fails.length === 0, failures: fails };
}

4. Alert priority normalizer (Before BR on em_alert)

(function executeRule(current) {
 var map = { critical: 1, major: 2, minor: 3, warning: 4, info: 5 };
 var key = (current.severity + '').toLowerCase();
 if (map[key]) current.priority = map[key];
})(current);

5. Event flood suppressor (>100/min)

var gr = new GlideAggregate('em_event');
gr.addQuery('sys_created_on', '>=', gs.minutesAgoStart(1));
gr.addAggregate('COUNT');
gr.groupBy('source');
gr.having('COUNT', '>', 100);
gr.query();
while (gr.next()) {
 var src = gr.getValue('source');
 gs.warn('[flood] source=' + src + ' rate=' + gr.getAggregate('COUNT') + '/min');
 var sup = new GlideRecord('em_match_rule');
 sup.initialize();
 sup.name = 'TEMP suppress ' + src;
 sup.source = src;
 sup.suppression = true;
 sup.active = true;
 sup.expires_at = gs.minutesAgoStart(-30);
 sup.insert();
}

6. Topology-based correlation (advanced group key)

(function() {
 var ci = current.cmdb_ci.toString();
 if (!ci) return current.node;
 var parent = new GlideRecord('cmdb_rel_ci');
 parent.addQuery('child', ci);
 parent.addQuery('type.name', 'Depends on::Used by');
 parent.setLimit(1);
 parent.query();
 return parent.next() ? 'PARENT:' + parent.parent : 'CI:' + ci;
})();

7. Auto-create change request from Patch Mgmt alert

(function executeRule(current, previous) {
 if (current.source != 'Patch Management' || current.state != 'New') return;
 var ch = new GlideRecord('change_request');
 ch.initialize();
 ch.short_description = 'Patch required: ' + current.description;
 ch.cmdb_ci = current.cmdb_ci;
 ch.type = 'standard';
 ch.category = 'Patching';
 ch.risk = 'moderate';
 ch.requested_by = gs.getUserID();
 var id = ch.insert();
 current.work_notes = 'Change opened: ' + id;
})(current, previous);

8. Auto-acknowledge sustained alerts

var gr = new GlideRecord('em_alert');
gr.addQuery('state', 'Open');
gr.addQuery('sys_created_on', '<', gs.hoursAgoStart(2));
gr.addQuery('acknowledged', false);
gr.query();
while (gr.next()) {
 gr.acknowledged = true;
 gr.work_notes = 'Auto-ack after 2h (no user action)';
 gr.update();
}

9. Health Dashboard refresher

var refresh = new GlideRecord('pa_scores_history_recompute');
refresh.initialize();
refresh.indicator.setDisplayValue('ITOM Alert MTTR');
refresh.insert();
gs.info('Triggered PA recompute');

10. Cloud Discovery scope filter

// Restrict an AWS schedule to two regions only
var sched = new GlideRecord('cloud_discovery_schedule');
sched.get('<schedule_sys_id>');
sched.regions = 'ap-southeast-2,me-south-1';
sched.update();

11. AWS tag → CMDB attribute mapper (Transform Script)

(function map(source, target) {
 var tags = source.u_tags_kv || '';
 var pairs = tags.split('|');
 pairs.forEach(function(p) {
 var kv = p.split('=');
 if (kv[0] == 'cost_center') target.u_cost_center = kv[1];
 if (kv[0] == 'app') target.business_application = kv[1];
 });
})(source, target);

12. Cloud cost rollup by department

var agg = new GlideAggregate('cmdb_ci_cloud_resource');
agg.addAggregate('SUM', 'monthly_cost');
agg.groupBy('u_cost_center');
agg.query();
while (agg.next()) {
 gs.info('[cost] dept=' + agg.getValue('u_cost_center') +
 ' cost=' + agg.getAggregate('SUM', 'monthly_cost'));
}

13. Maintenance window alert suppression

(function executeRule(current) {
 var ci = current.cmdb_ci.toString();
 if (!ci) return;
 var cw = new GlideRecord('change_request');
 cw.addQuery('cmdb_ci', ci);
 cw.addQuery('state', 'IN', '-2,-1'); // scheduled, implement
 cw.addQuery('start_date', '<=', gs.nowDateTime());
 cw.addQuery('end_date', '>=', gs.nowDateTime());
 cw.query();
 if (cw.next()) {
 current.maintenance = true;
 current.state = 'Suppressed';
 current.work_notes = 'In maintenance window ' + cw.number;
 }
})(current);

14. Stale CI detector (Discovery didn’t see in 30d)

var gr = new GlideRecord('cmdb_ci_server');
gr.addQuery('discovery_source', '!=', '');
gr.addQuery('last_discovered', '<', gs.daysAgoStart(30));
gr.query();
while (gr.next()) {
 gs.info('[stale] ' + gr.name + ' last seen ' + gr.last_discovered);
}

15. Mass-acknowledge alerts by group

function ackByGroup(groupId) {
 var gr = new GlideRecord('em_alert');
 gr.addQuery('assignment_group', groupId);
 gr.addQuery('acknowledged', false);
 gr.updateMultiple({ acknowledged: true, work_notes: 'Bulk ack by ' + gs.getUserName() });
}

16. Service Map relationship rebuilder

function rebuildService(serviceId) {
 var clear = new GlideRecord('svc_ci_assoc');
 clear.addQuery('service_id', serviceId);
 clear.deleteMultiple();
 var refresh = new SncSAEngine();
 refresh.discoverService(serviceId);
}

17. Pattern timing analyzer

var gr = new GlideAggregate('discovery_pattern_log');
gr.addAggregate('AVG', 'duration_ms');
gr.addAggregate('MAX', 'duration_ms');
gr.groupBy('pattern');
gr.query();
while (gr.next()) {
 gs.info(gr.getValue('pattern') +
 ' avg=' + gr.getAggregate('AVG', 'duration_ms') +
 ' max=' + gr.getAggregate('MAX', 'duration_ms'));
}

18. MID Server queue depth monitor

var depth = new GlideAggregate('ecc_queue');
depth.addQuery('state', 'ready');
depth.addAggregate('COUNT');
depth.groupBy('agent');
depth.query();
while (depth.next()) {
 var c = parseInt(depth.getAggregate('COUNT'), 10);
 if (c > 5000) gs.warn('[queue] ' + depth.getValue('agent') + ' depth=' + c);
}

19. Discovery success rate dashboard (data source)

var total = new GlideAggregate('discovery_status');
total.addAggregate('COUNT');
total.addQuery('sys_created_on', '>=', gs.daysAgoStart(7));
total.query();
total.next();
var grandTotal = parseInt(total.getAggregate('COUNT'), 10);

var ok = new GlideAggregate(‘discovery_status’);
ok.addQuery(‘state’, ‘Completed’);
ok.addQuery(‘sys_created_on’, ‘>=’, gs.daysAgoStart(7));
ok.addAggregate(‘COUNT’);
ok.query();
ok.next();
var success = parseInt(ok.getAggregate(‘COUNT’), 10);

gs.info(‘Discovery success rate 7d = ’ + ((success / grandTotal) * 100).toFixed(1) + ‘%’);

20. Alert → Now Assist root cause suggestion

(function executeRule(current) {
 if (current.severity > 2) return;
 var na = new sn_nowassist.NowAssistAPI();
 var summary = na.callSkill('alert_root_cause', {
 alert: current.description + '',
 ci: current.cmdb_ci.getDisplayValue(),
 history_minutes: 60
 });
 current.work_notes = '[Now Assist] ' + (summary && summary.answer || 'no suggestion');
})(current);

عشرون سكربتًا جاهزًا للاستخدام تغطي الاكتشاف، MID، الأحداث، التنبيهات، السحابة، والتكامل مع Now Assist.

17.8 Power User Cheat Sheet

discovery_status.list → Runs (filter: state != Completed)
discovery_log.list → Per-device probe logs
ecc_queue.list → MID traffic (state, agent, queue)
em_alert.list → Active alerts
em_event.list → Raw events
em_connector_instance.list → Connectors
sa_tcp_connection.list → Service Mapping connections
cmdb_key_value.list → Cloud tags
cmdb_ci_cloud_resource.list → Cloud CIs

قائمة سريعة بأهم الجداول للوصول المباشر من شريط البحث.

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

Calendar to take ITOM from blank instance to Go-Live in 30 working days.
خطة 30 يوم عمل لإطلاق ITOM من الصفر.

Sequence assumes Australia release. Adjust durations for org maturity.
الترتيب لإصدار أستراليا — عدّل حسب نضج المؤسسة.

18.0 Overview Calendar

Week 1 → Day 0–5 Foundation (network, plugins, MID, credentials)
Week 2 → Day 6–11 Discovery rollout
Week 3 → Day 12–17 Service Mapping + Event Management
Week 4 → Day 18–23 Self-healing + Cloud
Week 5 → Day 24–30 Patch/Vuln, Dashboards, ATF, Training, Go-Live

خمسة أسابيع عمل — أساس، اكتشاف، خرائط/أحداث، علاج ذاتي/سحابة، إطلاق.

18.1 Day 0 — Pre-flight (network architecture & inventory)

Outputs (must exist before Day 1):

Firewall minimum (per MID Server):

MID Server → instance.service-now.com : TCP 443 (outbound, internet)
MID Server → discovered targets : TCP 22 (SSH), 135/445 (WMI), 161 (SNMP),
 5985/5986 (WinRM), 443 (vCenter/cloud)
MID Server ⇄ monitoring sources : varies (Splunk REST, Nagios SNMP trap 162)

⚠️ Warning: Do not allow inbound from MID — outbound only to instance. Document NAT. — يوم صفر يجمع المخططات وقواعد الحماية ومخزون الاعتمادات قبل أي تثبيت.

18.2 Day 1 — Activate plugins; CMDB ready

All > System Definition > Plugins → activate in order:
 1. com.snc.discovery
 2. com.snc.service-mapping (if licensed)
 3. com.snc.event_management (sa.server / Event Management)
 4. com.snc.cmdb_health (already on most instances)
 5. com.snc.itom_licensing (Operational Intelligence — if licensed)

Post-activation checks:

['com.snc.discovery', 'com.snc.service-mapping', 'com.snc.event_management']
.forEach(function(p) {
 var gr = new GlideRecord('sys_plugins');
 gr.addQuery('source', p);
 gr.query();
 gr.next();
 gs.info(p + ' -> active=' + gr.active);
});

CMDB readiness (block ITOM if missing):

• IRE active: navigate All > Configuration > CI Class Manager. — Open direct
• At least one CI Identification Rule per planned class (server, network gear, app).
• Domain separation decision finalized (do not retro-introduce). — فعّل البلجنز بالترتيب، تأكد من تشغيل IRE وقواعد الهوية، ثم اعتمد قرار العزل النطاقي.

18.3 Day 2–3 — Install MID Servers (HA cluster) + validate

Steps per MID:

1. Navigate: All > MID Server > Downloads → choose OS (Win/Linux), copy URL. — Open direct
2. On VM: install Java OpenJDK 17, create service account svc_midserver, install MID:

# Linux example
sudo useradd -m -s /bin/bash svc_midserver
sudo -u svc_midserver wget <mid_zip_url> -O /tmp/mid.zip
sudo -u svc_midserver unzip /tmp/mid.zip -d /opt/snc_mid
sudo -u svc_midserver /opt/snc_mid/agent/installer.sh -silent \
 -instanceurl https://<instance>.service-now.com \
 -instanceuser midserver_user \
 -instancepass '<encrypted>' \
 -midservername MID-RUH-01
sudo systemctl enable --now mid_server

3. Navigate: All > MID Server > Servers → record appears with Status=Up. — Open direct
4. Validate the MID → must turn Validated.
5. Repeat for second MID; cluster them: mid.cluster.name = ITOM-CL-01.
6. HA test: stop one MID’s service → schedules should re-route to peer (see §17 script #2).

⚠️ Run MID as least-priv service user. Never under Administrator/root. — ثبّت MIDs على VM منفصلين، صادق عليهم، ثم اربطهم في كلستر HA واختبر التحويل.

18.4 Day 4–5 — Credentials, IP ranges, exclusion lists

Day 4 — Credentials:

1. Navigate: All > Discovery > Credentials → New per OS family: — Open direct
   - Windows: domain account with Log on as service, Local admin via group policy.
   - Linux: SSH key (preferred) or sudo NOPASSWD on minimal commands.
   - SNMPv3: AuthPriv (SHA + AES128) — never SNMPv1.
   - vCenter: read-only role.
   - Cloud: SSO/role-based.
2. Test Credential against representative target → green.
3. Tag credentials with MID assignment to scope blast radius.

Day 5 — IP ranges:

// Bulk import via Background Script
var ranges = [
 { name: 'Prod-Servers-RUH', cidr: '10.10.10.0/24', mid: 'MID-RUH-01' },
 { name: 'Prod-Network-RUH', cidr: '10.10.20.0/24', mid: 'MID-RUH-01' },
 { name: 'Dev-All', cidr: '10.50.0.0/16', mid: 'MID-DEV-01' }
];
ranges.forEach(function(r) {
 var n = new GlideRecord('discovery_range_item');
 n.initialize();
 n.name = r.name;
 n.range = r.cidr;
 n.mid_server.setDisplayValue(r.mid);
 n.insert();
});

Exclusion list (must-have):

- Printers VLAN (if not in scope)
- IPMI/iLO networks (separate Discovery)
- Customer-owned segments
- DR network (only when DR drill)

Navigate: All > Discovery > Exclude Ranges → enter excluded CIDRs. — أنشئ بيانات اعتماد لكل نظام، اختبرها، ثم استورد النطاقات واستبعد المناطق الحساسة. — Open direct

18.5 Day 6–8 — First discovery (small subnet → fix → grow)

Day 6 — Pilot run:

1. Pick 10.10.10.0/24 (≤256 hosts).
2. Navigate: All > Discovery > Discovery Schedules → New Pilot-RUH. — Open direct
3. Add the pilot range, MID, run type On demand.
4. Click Discover Now.
5. Monitor: All > Discovery > Discovery Status until Completed. — Open direct

Day 7 — Review:

// Pilot success summary
var disc = new GlideRecord('discovery_status');
disc.addQuery('name', 'Pilot-RUH');
disc.orderByDesc('sys_created_on');
disc.setLimit(1);
disc.query();
disc.next();
gs.info('CIs touched: ' + disc.devices_discovered +
 ' / errors: ' + disc.devices_failed);

Day 8 — Fix patterns:

• Open discovery_log filtered by state=error → group by sensor.
• Most common: missing credential, classification gap, firewall.
• Re-run on individual IPs via Discover Now (Single IP).

Exit criteria: ≥95% of pilot hosts classified into specific CI class (not just cmdb_ci). — شغّل اكتشافًا تجريبيًا، راجع السجلات، أصلح الأنماط والاعتمادات حتى يصل التصنيف لـ 95%+.

18.6 Day 9–11 — Full rollout + scheduling strategy

Day 9 — Expand ranges in waves (5 waves max).

Day 10 — Scheduling:

Day 11 — Throttle settings:

All > Discovery > Properties:
 glide.discovery.max_devices_per_mid = 500
 glide.discovery.batch_size = 50
 glide.discovery.thread_count = 25

Verify ECC queue doesn’t pile up:

var q = new GlideAggregate('ecc_queue');
q.addQuery('state', 'ready');
q.addAggregate('COUNT');
q.groupBy('agent');
q.query();
while (q.next()) gs.info(q.getValue('agent') + ' queue=' + q.getAggregate('COUNT'));

وزّع النطاقات على موجات، اضبط الجدولة، وراقب طابور ECC من الامتلاء.

18.7 Day 12–13 — Service Mapping: first 5 business services

Day 12 — Pick 5 services with measurable business impact (eg. Internet Banking, Payroll, ERP, CRM, Email).

For each service:

1. Navigate: All > Service Mapping > Services > Application Services → New. — Open direct
2. Choose Top-down, set Entry Point (public URL or front-end host).
3. Provide Service Mapping credentials (separate from Discovery if needed).
4. Click Map → review topology.

Day 13 — Reconciliation:

• Use §17.5 Recipe B to identify missing nodes.
• For each missing relationship: add manual connection or fix pattern.
• Document owners for each service (used by Event correlation later).

Exit criteria: Each service maps host → app → DB → load balancer with ≤ 2 manual additions. — ابنِ خمس خدمات أعمال top-down، طابق الفجوات، ووثّق المالك لكل خدمة.

18.8 Day 14–15 — Event Management: connect external monitors

Day 14 — Nagios via SNMP trap:

1. Navigate: All > Event Management > Connectors > Event Sources → New. — Open direct
2. Type: SNMP, MID with EventManagementSNMPTrap capability.
3. Configure trap receiver: UDP 162 on MID (firewall rule from Nagios).
4. Test trap from Nagios → arrives in em_event.
5. Build Event Field Mapping: trap OID → severity, host, message.

Day 15 — Splunk:

1. In Splunk: alert action Send to ServiceNow EM (HEC token + URL).
2. URL: https:///api/now/v1/em/jsonv2.
3. Test by triggering Splunk alert → event lands in em_event with source=Splunk.
4. Create Datadog pull connector (§17.4 A).

Field normalization snippet:

// Inbound BR on em_event — normalize hosts to short name
(function(current) {
 var host = (current.node + '').toLowerCase();
 var dot = host.indexOf('.');
 current.node = dot > 0 ? host.substring(0, dot) : host;
})(current);

اربط Nagios عبر SNMP وSplunk عبر REST وDatadog عبر pull؛ وحّد أسماء العائل.

18.9 Day 16–17 — Alert correlation + suppression

Day 16 — Correlation rules:

Day 17 — Suppression rules:

• Maintenance: §17.7 script #13 enforced in flow.
• Flapping: auto-suppress >5 alerts in 10 min from same CI for 30 min.
• Info severity: auto-close after 30 min without higher severity.

Exit criteria: noise reduction ≥60% measured against pre-EM week. — عرّف قواعد التجميع والكتم — أقّل الضوضاء بنسبة 60% مقارنة بالأسبوع السابق.

18.10 Day 18 — Auto-create Incident from P1 alert + auto-resolve

Build the flow described in §17.4 D. Add the resolution back-link:

Trigger: em_alert updated, state changed to Closed
Condition: incident is set, incident.state IN (1,2,3)
Action: Update incident
 state = Resolved
 close_code = "Auto-resolved by event clearance"
 close_notes = "Source alert: " + alert.number

Test:

1. Inject Critical alert via REST → incident created within 2 min.
2. Clear alert (close in source) → incident auto-resolves. — أنشئ Flow لإنتاج حادثة من تنبيه حرج، واغلقها تلقائيًا عند انتهاء التنبيه.

18.11 Day 19–20 — Self-healing subflows

Two subflows minimum:

A — Restart Linux service over SSH:

Inputs: ci, service_name
Steps:
1. Get CI credentials via Discovery Credentials API
2. SSH probe (MID): "sudo systemctl restart {{service_name}}"
3. Wait 30s
4. SSH probe: "systemctl is-active {{service_name}}" → expect "active"
5. If active → close alert + post work note
6. Else → escalate severity, page on-call

B — Scale AWS Auto Scaling Group:

Inputs: asg_name, desired_capacity, region
Step 1: Call AWS Spoke action "Update Auto Scaling Group"
Step 2: Wait until DesiredCapacity == InService
Step 3: Update alert with scale event

Alert Action Rules in em_alert route by description regex (apache down, cpu_saturated).

Exit criteria: 2 self-heal scenarios working end-to-end in non-prod. — صمم Subflow لإعادة تشغيل الخدمات وآخر لتوسيع ASG ثم اختبرهما.

18.12 Day 21–22 — Cloud connectors (AWS + Azure)

Day 21 — AWS:

1. AWS side: create IAM Role ServiceNowDiscovery with policies:
   - ReadOnlyAccess
   - AWSConfigUserAccess
   - Cross-account trust to ServiceNow’s connector account.
2. SN side: All > Cloud Resources > Configuration > Service Accounts → New → Role ARN. — Open direct
3. Add scope (regions, services).
4. Run cloud discovery → verify cmdb_ci_ec2_instance populates.

Day 22 — Azure:

1. App Registration → Reader + Cost Management Reader.
2. SN side: All > Cloud Admin Portal > Accounts → Azure → tenant + client ID/secret. — Open direct
3. Validate and discover.

Common gotchas:

- Throttling on AWS → batch by region; lower thread count.
- Azure ARM rate limit → enable retries in connector config.
- Tag drift → schedule cloud discovery hourly.

ربط AWS عبر IAM Role وAzure عبر App Registration؛ تجنّب التحديد بتقسيم المناطق.

18.13 Day 23 — Cost rollup + tag governance

Required tags policy:

Validator script (scheduled daily):

var bad = new GlideRecord('cmdb_ci_cloud_resource');
bad.addQuery('u_cost_center', '');
bad.query();
gs.info('Untagged cloud CIs: ' + bad.getRowCount());
// Open ticket per missing-tag owner — Flow Designer

Cost report: §17.7 script #12 turned into PA indicator Cloud Spend by Cost Center. — ألزم التاجات الإلزامية، شغّل المدقق يوميًا، وأنشئ مؤشر تكلفة شهري.

18.14 Day 24–25 — Patch Management + Vulnerability Response integration

Day 24 — Patch Mgmt:

1. Navigate: All > Patch Management Application (Now Platform Plus). — Open direct
2. Connect to WSUS / Intune / SCCM via spoke.
3. Map discovered software (cmdb_sam_sw_install) → patch baselines.
4. Auto-create CHG using §17.7 script #7.

Day 25 — VR:

1. Activate com.snc.vulnerability (separate license).
2. Connect Tenable / Qualys / Rapid7 (Now Marketplace integrations).
3. Vulnerable Items (sn_vul_vulnerable_item) link to CIs from CMDB.
4. Build response rule: Critical CVE on Internet-facing CI → priority 1 CHG. — اربط Patch Mgmt مع WSUS وأنشئ تغييرًا تلقائيًا، ثم اربط Tenable في Vulnerability Response.

18.15 Day 26 — Dashboards & KPIs

Build these PA dashboards (Workspace → Performance Analytics):

Indicator example (MTTI — Mean Time To Identify):

Source: em_alert
Aggregate: AVG of (acknowledged_at - sys_created_on) WHERE acknowledged=true
Group by: severity
Breakdown by: source
Frequency: hourly

بنِ خمس لوحات PA لقياس عمليات ITOM، وحدد المؤشرات الرئيسية: MTTI، MTTA، MTTR.

18.16 Day 27 — ATF for end-to-end flow

ATF Suite ITOM E2E:

Test 1 — MID Heartbeat:
 Step: REST POST mock event → assert appears in ecc_queue
Test 2 — Discovery Pattern (mock):
 Step: Inject synthetic CI via Discovery Sensor → IRE returns existing CI
Test 3 — Event → Alert:
 Step: POST event → assert em_alert created with mapped CI
Test 4 — Alert → Incident:
 Step: Set severity=Critical → assert incident created in 60s
Test 5 — Self-heal:
 Step: Trigger Restart subflow → assert work_notes contain "Auto-resolved"
Test 6 — Service Map impact:
 Step: Set CI down → assert business service health reflects degraded

Run nightly via scheduled job; failure → notify ITOM Admin. — أنشئ مجموعة اختبارات تلقائية تغطي MID، الاكتشاف، الأحداث، الحوادث، العلاج الذاتي، وتأثير الخدمة.

18.17 Day 28 — Training

Hands-on labs reuse §17 recipes. Provide runbook printable PDF. — جلسات تدريب لكل فئة مع كتيب runbook عملي. اعتمد على وصفات §17.

18.18 Day 29 — Go-Live + Hypercare prep

Pre-Go-Live checklist:

• [ ] All MIDs Validated, no warnings 48h
• [ ] Discovery coverage ≥95% in pilot ranges
• [ ] CMDB Health score baseline recorded
• [ ] All 5 services mapped with owners
• [ ] Connectors validated (Nagios, Splunk, Datadog, SCOM)
• [ ] Correlation/suppression rules active
• [ ] P1 alert → incident flow tested
• [ ] Self-healing subflows tested 2× successfully
• [ ] Cloud accounts connected, hourly schedule running
• [ ] Patch/Vuln integration handshake green
• [ ] Dashboards published to NOC/Cloud Ops
• [ ] ATF suite green for 3 consecutive runs
• [ ] Runbook + escalation matrix shared
• [ ] Hypercare bridge schedule (24/5) for 2 weeks — قائمة التحقق قبل الإطلاق — كل بند يجب اعتماده قبل اليوم 30.

18.19 Day 30 — Go-Live

Sequence:

T-2h Freeze config in prod
T-1h Verify MID heartbeats
T-0 Switch monitoring tools to send to ServiceNow
 (parallel mode — keep old tickets for 7 days for reconciliation)
T+1h Smoke test from each source
T+2h Confirm first auto-created incident
T+1d Daily Go-Live standup, 2 weeks
T+7d Decommission parallel ticketing
T+14d Exit hypercare

Comms template (announcement):

Subject: ServiceNow ITOM is live
- New alert flow: monitors → ServiceNow → NOC
- Old tickets remain visible for 7 days
- Contact: itom-bridge@example.com / ext 5000

يوم الإطلاق: جمّد التغيير، حوّل أدوات المراقبة بالتوازي، تابع أول حادثة آلية، ثم اخرج من الـ Hypercare بعد أسبوعين.

18.20 Common Pitfalls & Fixes

⚠️ Top one to avoid: Activating Service Mapping before Discovery is stable — you’ll fix the same maps twice. — أخطاء شائعة — حلّها مرة واحدة عبر runbook قبل الإطلاق؛ أهمها: لا تربط الخرائط قبل استقرار الاكتشاف.

18.21 Master Sign-off

• [ ] Network/security signed firewall + MID design
• [ ] Plugins activated and version-locked
• [ ] HA MID cluster validated
• [ ] Pilot then full discovery ≥95% classification
• [ ] Service Mapping ≥5 services with owners
• [ ] Event Management connectors live + correlation + suppression
• [ ] P1 alert → incident → auto-resolve loop verified
• [ ] Self-healing subflows tested
• [ ] Cloud AWS + Azure ingestion + cost report
• [ ] Patch/Vuln integration handshake
• [ ] Dashboards + KPIs published
• [ ] ATF suite green
• [ ] Training delivered + acknowledged
• [ ] Go-Live + hypercare plan executed — قائمة التوقيع النهائي — اعتمدها قبل إغلاق المشروع.

§19 — CIS-Discovery / Event Mgmt / Service Mapping Exam & Z-to-Hero Feature Labs (30 inline Q)

19.1 Z-to-Hero Feature Labs (12 labs)

19.2 30 ITOM Practice Questions

1. MID Server architecture: A. On-prem agent connecting outbound to ServiceNow | B. Embedded | C. Cloud-only | D. None — Answer: A
2. MID min specs: A. 1GB RAM | B. 4GB RAM + 4 cores (production) | C. 64GB | D. Random — Answer: B
3. Discovery Phases: A. Shazzam → Classify → Identify → Explore | B. Just scan | C. Find | D. None — Answer: A
4. Shazzam = ? A. Port scan to find devices in IP range | B. SSH login | C. WMI | D. SNMP — Answer: A
5. Classify = ? A. Determine OS/device type via probes | B. Categorize tickets | C. Sort assets | D. None — Answer: A
6. Identify = ? A. Match against CMDB via IRE | B. Categorize | C. Tag | D. None — Answer: A
7. Explore = ? A. Gather detailed attributes via pattern | B. Initial scan | C. Final report | D. None — Answer: A
8. Pattern Designer language: A. ServiceNow Pattern Language (declarative) | B. JavaScript | C. Python | D. Bash — Answer: A
9. Probe vs Pattern: A. Probes = legacy/probe-sensor; Patterns = modern declarative | B. Same | C. Probes faster | D. Random — Answer: A
10. Credentials stored in: A. discovery_credentials table + encrypted | B. Plaintext | C. MID file | D. None — Answer: A
11. Discovery Status table: A. discovery_status (parent of devices found) | B. cmdb_ci | C. None | D. sysapproval_approver — Answer: A
12. Service Mapping is: A. Top-down pattern starting from entry point | B. Random | C. Bottom-up | D. Manual only — Answer: A
13. Application Service vs Business Service: A. Application = tech-focused; Business = customer-facing | B. Same | C. Random | D. None — Answer: A
14. Tag-based Service Mapping: A. Discover apps by tag (e.g., app=payroll) | B. None | C. Manual | D. Random — Answer: A
15. Operational Intelligence: A. ML-based anomaly + capacity forecasting | B. Just dashboard | C. None | D. Random — Answer: A
16. Event sources: A. SCOM, Splunk, Datadog, Nagios, SolarWinds, ELK, custom | B. Only Splunk | C. Email only | D. None — Answer: A
17. Event → Alert mapping: A. Field mapping in Event Rule | B. Manual | C. Random | D. None — Answer: A
18. Alert correlation types: A. Topology + Time + Sequence + Cluster | B. Random | C. Just time | D. None — Answer: A
19. Primary Alert = ? A. Root cause alert that secondary alerts roll up to | B. First alert | C. Loudest | D. Random — Answer: A
20. Self-heal action: A. Run remediation script on alert | B. Just log | C. Random | D. None — Answer: A
21. AIOps: A. AI for IT Ops — clustering, prediction, recommendation | B. Just dashboards | C. None | D. Random — Answer: A
22. Health Log Analytics: A. Log ingestion + anomaly detection | B. Just store logs | C. None | D. Random — Answer: A
23. Cloud Insights: A. Cost + usage visibility for AWS/Azure/GCP | B. None | C. Just billing | D. Random — Answer: A
24. Tag CIs from cloud: A. Auto from cloud resource tags | B. Manual only | C. Random | D. None — Answer: A
25. Service Graph Connector destination: A. CMDB via IRE | B. staging_table | C. Random | D. None — Answer: A
26. Predictive Capacity: A. Forecast resource exhaustion based on trend | B. Random | C. Just current | D. None — Answer: A
27. Maintenance window: A. Suppress events during scheduled maintenance | B. Just calendar | C. Random | D. None — Answer: A
28. CMDB Group: A. Manual group of CIs (vs class-based) | B. Same as CMDB Class | C. None | D. Random — Answer: A
29. ITOM workspace URL: A. /now/itom/workspace | B. /itom.do | C. Random | D. None — Answer: A
30. Service Watch (legacy) replaced by: A. Service Mapping + Operational Intelligence | B. Manual scripts | C. None | D. Random — Answer: A

19.3 What “Hero” looks like for ITOM

Manages discovery + event mgmt + service mapping + AIOps end-to-end. Connects SCOM/Splunk/Datadog. Discovers cloud resources via SGC. Maintains service maps automatically. Drives alert noise down 70%+ via correlation. Self-healing on top alerts.

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

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

1. Lab 1 — MID Server install / تثبيت MID — Deploy MID; verify UP at {BASE}/ecc_agent_list.do.

2. Lab 2 — Credentials / بيانات اعتماد — Add SSH/Windows creds at {BASE}/discovery_credentials_list.do.

3. Lab 3 — Discovery schedule / جدولة اكتشاف — Create schedule with IP range; run now.

4. Lab 4 — Review results / مراجعة النتائج — Check {BASE}/discovery_status_list.do; confirm CIs in CMDB.

5. Lab 5 — Service Mapping / خرائط خدمة — Define entry point; run top-down map.

6. Lab 6 — Event Management / إدارة أحداث — Ingest test alert; verify correlation.

7. Lab 7 — Cloud account / حساب سحابي — Add AWS/Azure account for cloud discovery.

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

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

Direct URLs Quick Reference