Windows Server Discovery – Troubleshooting guide - Support and Troubleshooting

Windows Server Discovery – Troubleshooting guide Summary .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Windows powers the bulk of enterprise server estates—on-prem data centers, cloud VMs, and clustered/virtualized hosts. Accurate discovery of identity, hardware, OS, network, storage, and virtualization relationships drives uptime, audit readiness, and cost control.

ServiceNow Discovery automates that collection across Windows using WMI or WinRM/PowerShell and writes clean CI attributes and relationships into the CMDB—reducing manual effort and drift.

ServiceNow Discovery follows four phases— Shazzam , Classification , Identification , and Exploration .

This KB focuses on the Windows pattern and gives phase-by-phase troubleshooting checks (ports, creds, Admin$, WMI/WinRM tests), plus “status fail of the commands” quick fixes you can run from the MID.

Who should use it (target audience):

Support Engineers (Discovery/MID/Platform) Infrastructure / Windows Platform teams SAM / Asset Management teams Discovery Admins Facts .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Release .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } ALL

Instructions .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } TL;DR – 10 ‑ Minute First Response

Ask up front

Credential validated from the MID (WMI/WinRM flavor you expect)? Correct management protocol & ports are reachable (135 + RPC range for WMI, or 5985/5986 for WinRM; 445 if needed)? Followed the triage flow below end ‑ to ‑ end? Any open PRBs/Store updates matching the symptom? Quick checks (do in order, on the MID server):

Reachability : tracert → last hop; Test-NetConnection -InformationLevel Detailed . Port test : WMI/DCOM path: Test-NetConnection -Port 135 WinRM HTTP/HTTPS: Test-NetConnection -Port 5985 / -Port 5986 Admin share : Test-Path " \\\ \admin$ " (expect True if accessible) WinRM session (HTTP): $target=" ";$u=" ";$p=" " $sec=ConvertTo-SecureString $p -AsPlainText -Force $cred=New-Object pscredential($u,$sec) New-PSSession -ComputerName $target -Credential $cred WMI query from MID : CMD: wmic /node:" " /user:" " /password:" " path win32_operatingsystem PowerShell: gwmi win32_operatingsystem -computer -credential ' ' On target (optional) : netstat -ano | findstr 5985|5986|135 to see listening ports. If anything above fails, stop and remediate (credentials, firewall/ACL, WinRM/WMI service) before chasing Discovery internals.

Troubleshooting Windows Credential issues:

1. How to recognize a credential problem

Check three places for evidence: Discovery Status , ECC Queue , and MID logs .

Discovery Status : During Windows – Classify or early Exploration , look for messages such as No credential found for type [Windows] , couldn’t classify , Access is denied , RPC server unavailable , or Get-CimClass : Access is denied . ECC Queue : Open the WMIRunner (or PowerShell ) message for the target. In the response payload, check the debug_info and parameters: If no credentials were attempted , you’ll see an empty list (e.g., credentials_attempted: []) and an error like No credential found for type [Windows] → the MID did not have a visible Windows credential to try. If credentials were attempted but failed , you’ll see authentication errors (e.g., access denied, logon failure). Fix the credential itself or its rights. MID logs : Temporarily enable debug (e.g., increase MID log level and enable PowerShell logging), rerun, and verify which credentials were loaded/used and the resulting error.

Root causes & what to do

A) No credential available to the MID (visibility)

Symptoms : ECC shows No credential found… or credentials_attempted: [] and the credential_id is empty. Fix :

Open the Windows credential record and verify: Active = true . Applies to is set to All MID servers or the correct Specific MID servers so those MIDs can see the credential. Order is appropriate if many credentials exist (helps avoid lockouts and unexpected selections). After changes, restart the MID (or save/modify the credential) to refresh the MID’s credential cache .

B) Credential selected but authentication failed (bad password/insufficient rights/UAC)

Symptoms : Access denied/logon failures in ECC or MID logs; PowerShell Get-CimClass : Access is denied. Fix :

Ensure the account meets Windows requirements (commonly a domain account with local administrator on targets, or a local admin/JEA profile with sufficient rights for probes). Validate username format per your environment: Down-Level DOMAIN\User, UPN user@domain, Workgroup WORKGROUP\User, or local .\User. Re-test from the MID host using the same credential: WMI : gwmi win32_operatingsystem -computer -credential ' ' WinRM : create a New-PSSession -ComputerName -Credential Address any failures (password, policy/UAC, WinRM/WMI configuration) and retry discovery.

C) Protocol/config mismatch (WMIRunner vs PowerShell use of credentials)

What happens :

With PowerShell-based discovery enabled, Windows classification/exploration can use Credentials table entries. With pure WMIRunner and PowerShell credential usage disabled, discovery may fall back to the MID service account only. Fix : Verify MID properties controlling PowerShell usage and whether credentials from the table are used and/or whether fallback to the MID service account is allowed.

D) Network/firewall prevents authentication even with correct credentials

Symptoms : Timeouts, RPC server unavailable , or connection failures. Shazzam shows 135/5985/5986 open, but authentication still fails. Fix : From the MID host, confirm TCP 135 (WMI/DCOM) plus dynamic RPC high ports are permitted for WMI, and TCP 5985/5986 for WinRM. Coordinate with network/firewall teams or lock WMI to fixed ports if required by policy.

Please execute the command and check the result over the port number: Test-NetConnection -ComputerName 10.10.xx.xx -Port 135

Related KB links:

MID Server - Troubleshooting WMI/Powershell issues and credentials : KB0549834

Windows credentials DOC : Official DOC link

PART I — The ECC chain you should see (end‑to‑end)

Use Discovery Status → Related Links → ECC Queue (or breadcrumbs/correlator):

Shazzam → MultiProbe (scan) – shows open ports (135/5985/5986 etc.). Classification probe – Windows classify over WMI or WinRM authenticates and returns OS caption. HorizontalDiscoveryProbe – Pattern Launcher (Windows Server) – triggers Windows pattern(s). Pattern probes (WMI/PowerShell) – collect OS/CPU/RAM, storage, services, processes, MSSQL, etc. HorizontalDiscoverySensor – parses pattern JSON → IRE. Identification / Exploration (IRE) – insert/update CI + related lists. Read ECC like a pro:

Topic = which probe/sensor; Agent = which MID; Response to links the previous hop. Capture payloads for case evidence.

PART II — Phase‑by‑Phase Runbook

1) Shazzam (Scan) – what “good” looks like & fast fixes

Good: Target IP appears with result:"open" for 135 (likely Windows), 5985/5986 (WinRM), or other classifiable ports. Refusals listed as result:"refused"; timeouts indicate network blocks.

Validate quickly (MID host):

Test-NetConnection -Port 135 Test-NetConnection -Port 5985 (or 5986) If needed, telnet or third ‑ party TCP tester

Common break/fix:

No returns/timeouts: Routing/ACL/firewall; engage network team; confirm MID selection; reduce scan chunk size for stressed networks. Windows WMI path blocked: Host firewall allows 135 but blocks dynamic RPC → coordinate to open negotiated RPC range or lock WMI to fixed ports. Not scanning a port you expect: Confirm port_probe_spec and port ‑ probe priority; check selective scanning rules.

How Discovery tells it failed in the scanning phase:

Discovery Status : You’ll see a Warning from Shazzam about the target not being reachable or no response on target ports. If Shazzam doesn’t find any classifiable ports (e.g., 135/WMI or 5985–5986/WinRM), classification will not trigger. ECC Queue → Shazzam : open the Shazzam message for that IP and check the result/warn and the port_probe_spec that lists which ports were scanned (e.g., 135, 5985, 5986). If the result says no response to target ports , it’s a scan reachability problem (network/firewall/route), not a credential issue yet. Reminder: Shazzam sending SYNs that show a port “open” only proves the handshake, not that all requirements are met—WMI still needs dynamic RPC ports after 135, which may fail later if blocked.

Customer tests to run:

NOTE: Tests should done from the MID Server host:

Trace the path tracert (Windows) – see last responsive hop. Optional: Test-NetConnection -InformationLevel Detailed . These are the basic connectivity checks recommended for scan troubleshooting. Check scan ports explicitly WMI/DCOM : telnet 135 or Test-NetConnection -Port 135 . WinRM (HTTP/HTTPS) : telnet 5985 / 5986 or Test-NetConnection -Port 5985/5986 . Telnet/port tests from the MID server are the documented quick checks. If 135 is open, remember WMI needs more than 135 WMI uses DCOM/RPC : it contacts 135 , then negotiates a high dynamic port for the real session. If those dynamic ports are blocked, discovery fails later with RPC errors. On the target Windows server (if you have access)

Verify listeners: netstat -ano | findstr 135 , findstr 5985 , findstr 5986 . Check Windows Firewall rules for RPC (135) , Dynamic RPC , and WinRM . The official guidance explains why opening 135 alone isn’t enough and how to add rules.

Troubleshooting & fixes (by symptom)

A) Shazzam says “not a reachable host” or no response to scanned ports

Likely routing/firewall/ACL .

Validate reachability from the MID , not your laptop (path may differ). Use PING/TRACEROUTE/TELNET as documented. Common causes: routing gaps, physical firewalls, local software firewalls, ACLs. Work with network teams as needed. B) Port 135 open, but WMI fails later (often RPC errors)

This is the classic “135 is fine, but DCOM dynamic ports are blocked.”

Fixes (pick what fits your policy):

Allow Dynamic RPC for the OS version (2008+ uses 49152–65535 ). If you cannot open the full range, configure DCOM to a limited high-port range (e.g., 65000–65100) and allow only that set—note the performance caveat. Implement the documented Windows Firewall rules for RPC Endpoint Mapper (135) and Dynamic RPC . C) WinRM path expected (5985/5986) but scan shows closed

On target: ensure WinRM is enabled and listening; on MID: telnet 5985/5986 or Test-NetConnection -Port 5985/5986 . The Windows Discovery overview covers WinRM port requirements. D) Scan shows ports “open” but classification still doesn’t run

Re-check the Shazzam payload to confirm the port scanners and results; Shazzam only triggers classification once it sees open/expected ports for that protocol. If none are open, the device won’t proceed. Then proceed to the Classification troubleshooting (credentials, protocol) once the scan evidence is healthy.

Quick “Do/Verify” checklist you can paste in tickets

From MID : tracert ; Test-NetConnection -Port 135|5985|5986 (or telnet ). From target : netstat -ano | findstr 135|5985|5986 to verify listeners. If using WMI : confirm Dynamic RPC is allowed (2008+ = 49152–65535) or configure/allow a constrained range. If using WinRM : verify 5985/5986 open and listener configured. Re-run scan; check ECC → Shazzam for updated results before moving to Classification. RELATED KNOWLEDGE ARTICLES:

MID Server - Troubleshooting WMI/Powershell issues and credentials : KB0549830

Opening ports in Windows Firewall for remote server access : KB0549828

Windows Discovery - Troubleshooting WMI/Powershell issues on the remote machine : KB0549830

2) Classification (Windows) – prove it’s Windows & prep pattern launch

What happens: Windows classifies and authenticates via WMI or WinRM and returns the OS details. This stage selects the proper Windows patterns and binds the credential to the device context.

Where to look: ECC MultiProbe/Windows – Classify payload; check the credential chosen, runner type (WMI vs PowerShell), and any auth/ACL errors.

Validate quickly (from MID):

Credential test scripts (PowerShell ISE or console): WinRM: create New-PSSession to the target. WMI: run wmic ... win32_operatingsystem from MID; PowerShell equivalent gwmi . Firewall check : On target, confirm listening ports; on MID, telnet . Enable debug when needed: set MID mid.log.level=debug and mid.property.powershell.log_info=true ; reproduce and review agent0.log / wrapper.log . Frequent symptoms & actions:

RPC Server Unavailable / WMI connection failed → validate DCOM path (135 + high ports), service status, account rights. Access is denied (HRESULT 0x80070005) / Get ‑ CimClass: Access is denied → credential or policy issue; try the WMI/WinRM commands above; fix permissions/UAC. Firewall blocks → temporarily disable to isolate; then author rules allowing MID’s IP and required ports. WinRM hardening tips:

Ensure WinRM service is configured ( winrm quickconfig ), PowerShell remoting enabled ( Enable ‑ PSRemoting -Force ), and an execution policy that allows scripts.

How Discovery tell classification failed (and where to look):

Discovery Status Symptom: “Active, couldn’t Classify” appears in the log. Turn on classification debug to make these messages explicit ( glide.discovery.debug.classification=true ). ECC Queue (input) for the Windows – Classify probe Open the WMIRunner (or PowerShell) input record for the device. This is the first Windows probe that runs immediately after Shazzam and is where classification gathers OS facts (WMI/WinRM). What “good” looks like (your example): the payload contains WMI and/or registry objects such as Win32_ComputerSystem and Win32_OperatingSystem ; those facts then satisfy a classifier’s match criteria and trigger identity probes. Classification record Navigate: All → Discovery Definition → CI Classification ( /discovery_classy_windows_list.do ). Open the relevant Windows classifier (e.g., Windows 2012 Server ) and review: Active / Order / Match criteria (All vs Any) Classification Criteria related list (what values the sensor must return to match). Triggers probes related list (what will run after a match). Tip: Windows classification takes precedence over other protocols by default ( WMI > SSH > SNMP > CIM ). If multiple ports are open, the platform follows that order.

Quick triage: decide where the failure is

A. Network reachability OK, but no data returned → credentials / remote capability / Windows service

B. Can’t connect at all → ports / firewall / ACL / routing

C. Data returned but NOT matching any classifier → classifier criteria/order/config

D. “No sensors defined” on ECC input → probe/sensor mapping or customizations

Customer network checks (before or in parallel)

Ports open from MID to target For Windows discovery the Shazzam phase checks 135, 5985, 5986 , but open ports in Shazzam do not guarantee later connection success (e.g., WMI dynamic ports). WMI path : 135 (DCOM broker) then a negotiated high RPC port ; enhanced discovery may also use 445 (admin$) . Firewalls that allow 135 but block high ports or 445 will break classification or later probes. WinRM path : 5985 (HTTP) or 5986 (HTTPS) depending on host config. Remote capabilities (PowerShell path) If the MID is using the PowerShell logic (default), the classify probe first tests: access to admin$ and PowerShell remoting ; results appear as admin_share_access and target_powershell_access , and probes that require them will be skipped with clear log messages. Hands-on tests from the MID Quick checks: telnet 135|5985|5986 (or equivalent TCP check). WMI credential test (DCOM/CIM) or WinRM PSSession test per KB to validate the exact account you plan to use.

Instance-side checks & fixes

1) Credentials & protocol

Classification is the first time credentials are actually used . Confirm the Windows credential exists, is active, and has the required rights, and that your MID’s management protocol (WMI vs WinRM) and PowerShell settings match your design. If using PowerShell discovery, remember it relies on the credentials table (by default) and the remote-capability tests above. 2) Classifier configuration

Open the classifier and verify:

Active = true, Order appropriate, Match criteria reflect what the sensor returns (e.g., Win32_OperatingSystem.Caption contains “Server 2019” or “2012”). If you’ve disabled an earlier Windows classifier, the platform will stop at that level and never reach later versions (e.g., 2012). Re-enable or adjust order. Triggers probes contains only what you really need; patterns must be launched via Horizontal Pattern probe (don’t put a pattern name directly into “Probe”). 3) “No sensors defined” on ECC input

This usually means a probe was triggered that has no corresponding sensor mapping , often due to adding non-OOB probes to a Windows classifier. Fix by removing/disabling the added probes in the classifier so only supported ones are launched. 4) Turn on diagnostics and re-run

Set mid.log.level=debug and mid.property.powershell.log_info=true , reproduce, then review MID logs for RPC/WinRM/permission errors.

What to confirm in the ECC payload when classification succeeds

Presence of OS facts : Win32_ComputerSystem.Domain/Name and Win32_OperatingSystem.Caption/Version . Registry facts (optional but common): HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters (Domain/Hostname). These are exactly the types of values your Windows classifiers match against to decide “Windows Server 2012/2016/2019…”, and then they trigger identity/exploration probes .

Common root causes & fixes (one-liners)

Ports show open in Shazzam but classify still fails: classic WMI case— high RPC ports or 445 blocked ; open them or use WinRM. “Active, couldn’t Classify”: enable classification debug and check credentials/network first; classification is right after Shazzam. “No sensors defined” on ECC input: remove custom probes from the Windows classifier or add the corresponding sensor—OOB Windows classifiers don’t trigger those extra probes. Wrong classifier never matches: the record is inactive , ordered too high/low, or its criteria don’t align with the returned payload. Check Active/Order/Match criteria and Classification Criteria . PowerShell path skipping probes: admin$ or PS remoting not available; fix share/WinRM and re-test.

Tiny checklist you can drop into the KB

Shazzam shows 135/5985/5986 reachable (but remember WMI needs high RPC + 445). ECC WMIRunner input exists and returns OS facts (or shows the error). Windows credential validated from MID (WMI/WinRM test). Remote capability tests: admin$ and PowerShell reachable (PowerShell path). Classifier is Active , Order correct, Criteria match payload; Triggers probes sane. No “No sensors defined” error (remove unsupported probes from classifier).

RELATED KB articles:

Discovery Windows Classification: "No sensors defined" error for ecc queue input : KB0780724

Windows classification probe error "The result file can't be fetched because it doesn't exist" : KB0749612

Discovery of Windows Servers are failing with the "Missing Classification Information" exception. : KB1575372

Create a Discovery CI classification

3) Pattern troubleshooting using the Discovery Horizontal logs:

What happens: Once the classification of the Device is completed, the Discovery starts triggering the pattern. And we have an in-built horizontal log UI available for the users to quickly troubleshoot the issues:

Where to look for the logs: Once the classification is done, the Discovery sensor triggers the HorizontalDiscoveryProbe to trigger the pattern. Once the probe receives the input, the outcome of the Discovery pattern will be seen in the Horizontal pattern logs, as shown in the attached screenshot.

Most common Errors:

2025-11-08 10:50:30: Executing WMI query on host: 10.190.xxx.xx with namespace: Root\MSCluster and query: SELECT Name,Status,Description,Caption FROM MSCluster_Cluster

2025-11-08 10:50:37: Error during execution of Windows command: executeQuery -Namespace Root\MSCluster -Query "SELECT Name,Status,Description,Caption FROM MSCluster_Cluster". executeQuery : Could not get query SELECT Name,Status,Description,Caption FROM MSCluster_Cluster on namespace=Root\MSCluster. Original Exception: Invalid namespace At line:1 char:5 + & { executeQuery -Namespace Root\MSCluster -Query "SELECT Name,Status ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,executeQuery

Usually, this is a very common Error we see at this step " 1.2 Get cluster info from MSCluster_Cluster" incase the customer has not created the applicable credentials willingly because there is no requirement or existence of MSSQL Server discovery.

However, the solution is to provide the following permissions. Verify remote read-only access to the following WMI namespaces:

Root\ CIMv2 Root\Microsoft\SqlServer\ComputerManagement* NOTE: Recently, there is a property is introduced called "mid.sa.windows.allowable_failures" due to this. If the above command fails, the discovery is canceled after that. In the same step logs, we can see the below:

2025-10-29 11:09:08: Windows command failure count is 1 and allowable failures is 2. Continuing pattern execution. 2025-10-29 11:09:08: Execution time: 2009 ms

We have verified and found that this is a known issue identified as PRB1927941 . As per the KB article, the resolution is to add the following property under MID Server -> Properties:

mid.sa.windows.allowable_failures

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2434137

Solution: We can set the value to 5 or 10 (recommended), or to -1 if you want to allow unlimited errors.

Step # Step name (exact) What it runs/expects Typical cause Quick check / Fix 1 Get Data Set By Windows – Classify Launches Windows classify (WMIRunner / PowerShell path); needs admin share + PowerShell/WMI remote capability to succeed. Uses MID setting mid.windows.management_protocol (WMI/WinRM). Populates admin_share_access , target_powershell_access . Admin$ share blocked; WinRM/WMI not reachable; credential lacks rights. From MID: Test-Path \\ \admin$ and New-PSSession -ComputerName -Credential (WinRM) or wmic /node:" " ... path win32_operatingsystem . Open ports 135/5985/5986 and allow dynamic RPC if WMI. 2 Windows – Hardware Information Collects chassis & enclosure (WMI Win32_SystemEnclosure.ChassisTypes ) and memory modules. WMI class blocked/corrupt repo; insufficient rights to WMI namespace. From MID: Get-CimInstance Win32_SystemEnclosure -ComputerName -Credential . If fails, repair WMI repo and permissions. 3 Insert chassis_type to cmdb_ci_win_server Evaluates numeric ChassisTypes → friendly text (Desktop/Tower/…); sets field if value not empty/“null”/“None”. Missing/empty ChassisTypes ; WMI blocked; bad mapping input. Verify Win32_SystemEnclosure.ChassisTypes returns a number; fix WMI/rights. 4 Trim cmdb_serial_number Trims whitespace from cmdb_serial_number.serial_number before use. Source serial empty/whitespace; no serial in upstream table. Confirm pattern collected serial (see Step 5) and that SN exists in table. 5 Insert serial number to cmdb_ci_win_server Sets main CI serial_number from cmdb_serial_number[1].serial_number . Serial not found/permission denied; duplicate/blank value. Validate serial pull with Get-CimInstance Win32_BIOS / Win32_BaseBoard . 6 Reference between serial and win server Creates reference (non-CI) link between serial record and server. No serial rows; relation filter removes unmatched lines. Ensure Step 5 produced a serial; re-run after serial exists. 7 Windows – OS Information Collects OS caption, version, SP, description. WMI/WinRM blocked; access denied. From MID: gwmi win32_operatingsystem -computer -credential ' ' . 8 Windows – CPU and Memory Collects CPU name/speed/manufacturer, core counts, logical procs; memory modules. WMI class denied; 32/64-bit remoting mismatch; throttling/timeouts. From MID: Get-CimInstance Win32_Processor -ComputerName -Credential . 9 Insert System, OS and CPU data Sets fields: os_version , os_service_pack , manufacturer , model_id , short_description , os_address_width , assigned_to , cpu_* , ip_address , host_name , fqdn , os_domain , name , cpu_count , os . Any upstream attribute missing due to remote capability failure or partial WMI; name/FQDN build fails if domain empty. Quick sanity: ipconfig /all (domain), Get-CimInstance Win32_ComputerSystem , Get-CimInstance Win32_Processor . 10 Insert ram Sums Win32_PhysicalMemory[*].Capacity (bytes) → MB. No module data returned; partial timeouts. `Get-CimInstance Win32_PhysicalMemory 11 Relate memory modules Links cmdb_ci_memory_module to server (Contains↔Contained by). No modules discovered; relation prunes unmatched. Confirm Step 10 returns modules; re-scan. 12 Windows – ARP & NDP Tables Collects ARP/NDP to discovery_net_arp_table . Admin share/PowerShell blocked; network stack restricted. Ensure remote PS works; validate arp -a locally as proxy test. 13 Reference ARP table → server Non-CI reference from ARP table to server. No ARP rows; pruning. Verify Step 12 returned rows. 14 Windows – Printers Enumerates printers. Spooler service off; permission denied. Get-Printer (newer OS) or wmic printer get Name . 15 Windows – Cluster Collects cluster and node data; sets node relations by matching node name to host_name / name . Node name mismatch; cluster service off; remote PS blocked. Compare node names; fix DNS/NetBIOS; ensure ClusSvc running. 16 Relate win_cluster ↔ server Links cluster CI to server when cluster components exist. No PartComponent in cluster payload; access blocked. Re-run cluster step after validating permissions. 17 Windows – Network Collects NICs, routes, gateways. Net classes blocked; admin share check failed. Get-CimInstance Win32_NetworkAdapter, Win32_NetworkAdapterConfiguration . 18 Relate router/route interfaces & next hops Creates Uses/Used by relations for router/route interfaces and next hop gateway. Empty routing table returned; permission issues. route print remotely via Invoke-Command to confirm data. 19 Relate network adapters Owns↔Owned by between server and NICs. No adapters captured; pruning. Confirm Step 17 outputs adapters. 20 Relate IP addresses Owns↔Owned by between server and IPs (contains condition). IPs not parsed; formatting mismatch. Verify IP list on target; re-run network step. 21 DNS Collects DNS config/records for the node. DNS client blocked; command timeout. ipconfig /all & Resolve-DnsName . 22 Windows – Storage Collects disks/partitions/HBAs/FC/iSCSI/NAS/filesystems. Storage classes blocked; MPIO/driver hides devices; rights. Get-PhysicalDisk , Get-Disk , Get-Partition , Get-InitiatorPort , vendor tools. 23 Insert total disk space Sums PhysicalDisks[*].Size → GB and writes disk_space . One or more disk sizes null; overflow/timeouts. `Get-PhysicalDisk 24–31 Storage relations (disk / partition / storage device / FC disk / iSCSI disk / NAS FS / FS) Creates Contains/Owns relations from server to each storage CI. No storage item discovered = pruned; mapping key mismatch. Validate Step 22 returned objects; re-discover with proper rights. 32 Windows – Hyper-V Detects Hyper-V role. If host is Hyper-V, pattern creates/updates cmdb_ci_hyper_v_server and marks guest as virtual. Hyper-V services off; permissions limited; remote PS blocked. Get-WindowsFeature Hyper-V and Get-VMHost (on host). 33–34 Insert / Relate Hyper-V server Copies host fields to Hyper-V CI; sets virtual=true , builds NameForCluster ; relates cmdb_ci_hyper_v_server “Runs on::Runs” to Windows host. Missing isHyperV flag; source fields empty. Validate Hyper-V detection; ensure classification captured host metadata. 35 Windows – Cloud Cloud hints (AWS/Azure). Cloud APIs blocked; instance metadata unreachable. If in AWS/Azure, verify IMDS/UUID access; network path to metadata. 36 If AWS, set object_id Sets cmdb_ci_win_server.object_id to awsData.instance_id when isEc2 && shouldDiscoverAmazon . Cloud classify missed; IMDS blocked; MID lacks cloud perms. Ensure AWS discovery/IMDS reachable from target. 37 If Azure, set object_id Sets server object_id to uuidSerial when isAzure && shouldDiscoverAzure . Azure UUID not read; classification skipped. Ensure Azure discovery enabled; check UUID on VM. 38 If cloud, mark virtual Sets virtual=true for EC2/Azure. Cloud flags not set due to earlier failures. Re-run cloud classify once creds/IMDS fixed.

Creds, ports & “quick checks”:

Ports: WMI → 135 (+ dynamic RPC); WinRM HTTP/HTTPS → 5985/5986. Confirm telnet from MID; netstat -ano | findstr on target. Admin$ & PowerShell remote capability tests (from MID): Test-Path \\ \admin$ New-PSSession -ComputerName -Credential $cred / Enter-PSSession / Invoke-Command … WMI basic test: wmic /node:" " /user:" " /password:"..." path win32_operatingsystem (failures like 0x800706BA / 0x80070005 = RPC unavailable / Access denied). WinRM basic test: New-PSSession -ConnectionUri http:// :5985/wsman -Credential $cred (enable with winrm quickconfig , Enable-PSRemoting -Force ).

See the Data collected by the Pattern: Data collected in Windows Discovery.

4) Identification – make CMDB match decisions predictable

What happens: IRE compares discovered identifiers to CMDB and chooses one of: create new , update single match , or stop on duplicates .

Operator moves:

If no identity probes launched, verify Windows classify succeeded and that identity probes are in Triggers for Windows. When duplicates stop progress, turn on CI identification debugging (property) to log per ‑ IP identification detail; clean up dupes/imports or adjust identifier order. Prefer serial/UUID where reliable; tune Name & Class Name identifier based on naming uniqueness in your environment. Edge case: Multi ‑ NIC servers scanned on multiple IPs in the same run may show Identified, ignored extra IP — expected; not an error.

Windows Discovery – Identification Phase (IRE) Troubleshooting

What “Identification” does

After Classification succeeds, Discovery hands an identification payload (hardware facts such as serial, name, MACs, adapters, IPs…) to the Identification & Reconciliation Engine (IRE) . IRE decides whether to update an existing CI or insert a new one using the Identification Rule (e.g., Hardware Rule in CI Class Manager).

How to spot an Identification issue (and where to look)

Discovery Status Typical signals: Identifying… , Created new CI , Multiple matches found , Stopped during Identification , Abandoned due to too many errors . ECC Queue Open messages around “Identification” (and any pattern logs). Errors like Identification CI errors , Found duplicate lookup items , payload validation failed , or multiple matches point to IRE. CI Class Manager → Identification Rule (e.g., Hardware) Check the Identifier entries, order, and active flags . Typical entries (priority varies by customer): Serial-number–based (e.g., Serial number , Product instance identifier ). Name . Lookup entries (e.g., Network Adapter : MAC + Name, or Serial-number lookup). Ensure the order reflects your environment (most reliable identifiers first). System Logs (syslog_list.do) with IRE debug enabled (see “Enable IRE debug” below) You’ll get identification_engine entries with “Input = {…}” and “Output = {…}” that show exactly what IRE received and decided.

Enable IRE debug (do this once, test one IP, then turn off)

Discovery property glide.discovery.debug.ci_identification = true (writes extra CI-ID details to the Discovery log). IRE log properties (sys_properties) glide.cmdb.logger.source.identification_engine = * If logs do not appear in [syslog], also set: glide.cmdb.logger.use_syslog.identification_engine = * Re-run a Quick Discovery for a single target Open System Logs and filter Source = identification_engine Copy the “ Input = {…} ” payload (what IRE evaluated). Copy the “ Output = {…} ” payload (what IRE decided). (Optional) Use Identification Simulation to replay that payload and see exactly which identifier matched or failed. Don’t leave these properties on—debugging is verbose.

Read the IRE decision:

Normal outcomes

Exactly one match → CI updated , exploration proceeds. No matches → new CI inserted , exploration proceeds. More than one match → IRE stops (human action needed to resolve duplicates). Important: Payload validation happens before rule matching

If IRE finds duplicate/invalid items in the payload (e.g., the same MAC/IP repeated), it fails before running the identifier steps. Symptom: ECC/System Logs show validation errors, and you won’t see “Rule Step 1/2/…” in the message. Fix: remove/normalize duplicates in the payload source (sensor/pattern), then re-run.

Fast triage flow:

Did Identification even start? If not: Classification may have finished but nothing triggered Identification. Check the Windows classifier → Triggers probes : the Identification probe/pattern must be present and Active . If Classification output JSON was malformed (legacy WMI path), resolve that first (Classification fix), then come back. If Identification started and failed immediately: Look for payload validation errors (duplicate MAC/IP, malformed data). Fix: deduplicate/clean the payload (pattern or sensor), or correct the device data causing the duplicates. If there are multiple matches Turn on CI ID debug; find which identifier caused ambiguity (often Name or a non-unique Serial ). Fix: Clean up duplicate CIs in CMDB (or use de-dup tasks). Re-order or disable weak identifiers (e.g., demote/disable Name in environments with non-unique hostnames; prefer Serial or UUID if reliable). If there are no matches (unexpected insert) Payload is missing reliable keys (e.g., serial); or rule order doesn’t fit your reality. Fix: Ensure Windows discovery is returning serial/UUID (see “Windows data health” below). Adjust Identifier order in CI Class Manager to align with what you actually get (e.g., promote Name if unique across estate, or add a Lookup that matches your standard). “Abandoned due to too many errors” in pattern logs A common cause is duplicate relationship types in cmdb_rel_type . Fix: identify and deduplicate the offending relationship type; make sure removing it doesn’t break existing cmdb_rel_ci links. Classified but never identified due to model/containment issues Orphaned/bad containment metadata (e.g., entries with no parent) can block pattern steps that collect identity. Fix: remove orphaned records in cmdb_metadata_containment (filter parent_id = NULL ) and retry.

Windows-specific data health (so Identification has strong keys)

Ensure serial/UUID is discoverable Remote query (test from MID): PowerShell/CIM: Get-CimInstance Win32_BIOS | Select-Object SerialNumber Get-CimInstance Win32_ComputerSystemProduct | Select-Object UUID If these return nothing or “To Be Filled By O.E.M.”, consider promoting Name (if unique) or a MAC-based lookup temporarily—then address firmware/BIOS inventory quality. Account rights Use a Windows credential with local admin rights. For the PowerShell path, the MID must reach admin$ and PS Remoting; for WMI, DCOM must reach 135 + dynamic RPC ports (and often 445 ) through firewalls. Duplicate network data Teaming/bonding/virtual NICs can yield the same MAC on multiple adapters. Tidy the payload (or adjust pattern) to avoid duplicated MACs/IPs.

CI Class Manager – rule hygiene and best practices

Put the most reliable identifiers first (typically Serial or UUID for hardware, then Name , then MAC lookups ). If hostnames are unique in your estate, it’s acceptable to promote Name above Serial to get faster, deterministic updates. If names aren’t unique (lab prefixes, recycled names), disable/demote Name and rely on Serial/UUID or MAC lookups. Keep Lookup entries (e.g., Network Adapter MAC + Name, Serial lookup) active only when your data for those fields is consistently clean. After every change, Quick Discovery one CI , examine IRE Input/Output and confirm the new order yields the expected match.

Ready-to-use checklists

Minimal repro (one IP)

Turn on IRE debug props (source/use_syslog) and Discovery’s CI identification debug. Quick Discovery a single IP. Grab IRE Input/Output from System Logs. If validation failed → clean duplicates/bad items in payload. If multiple matches → tune rule order or clean duplicates in CMDB. If no match (unexpected insert) → ensure serial/UUID present, or re-order identifiers to match your data reality. Data/Rule fixes

Remove duplicate relationship types if “abandoned due to too many errors”. Remove orphaned containment metadata if patterns stall before identity. Tune Identifier order (Serial/UUID vs Name vs MAC lookup) and Active flags. Re-run a single-IP test and re-check IRE Input/Output.

RELATED LINKS: How to capture IRE [identification and reconciliation engine] debug logs: KB0750382

[CMDB - IRE] How the CMDB Identification and Reconciliation Engine works when passing a CI (as payload) to the createOrUpdateCi( ) : KB0750386

Troubleshooting the Identification Phase in Discovery: KB0535238

5) Exploration – collect the good stuff (probes & patterns)

What happens: Horizontal pattern(s) execute using the same credential; additional probes may trigger (e.g., MSSQL , vCenter discovery on Windows).

Troubleshooting style: Re ‑ run the same probe commands from the MID host first.

WMI: wmic ... to the same class/namespace; verify no timeouts. If success outside but Discovery times out, raise wmi_timeout for that probe. PowerShell: gwmi ... , Invoke-Command , Enter ‑ PSSession to replicate. JavaScript via cscript: test remote registry/WMI queries as the MID service account if applicable. Watch ‑ outs: A credential that works for classification might lack rights for deeper exploration (e.g., registry/services/files). Credential order can affect which account is used.

Windows Server extras commonly triggered from Windows:

MSSQL probe (when SQL service detected) – ensure SMO libraries if required on the MID. VMware vCenter/ESXi probes (when vCenter detected) – require credential type=VMware, etc.