Windows Discovery Overview - Support and Troubleshooting

Windows Discovery Overview Description This Knowledge Base article covers some of the main topics regarding windows discovery.

For supported windows versions, PowerShell requirements, data collected, and what probes/patterns are triggered for windows, see the following "Windows Discovery" documentation for your ServiceNow instance release:

Windows Discovery Table of Contents Description WMI vs WinRM Shazzam Windows Classification Credentials Credential Test Remote Capabilities Test Properties and Parameters Troubleshooting Common Errors Additional Information WMI vs WinRM ServiceNow discovery leverages multiple protocols to communicate with the target devices. Either WMI or WinRM can be utilized for windows discovery. The protocol used for windows discovery is controlled at the MID server level via MID server parameter "mid.windows.management_protocol". The default value for this property is "WMI".

Network Requirements WMI and WinRM have different network/firewall requirements.

WMI WMI is based on DCOM/RPC. This means a connection is first initiated on port 135 to determine what dynamic port to use. The connection then proceeds to use the dynamic port negotiated.

The following Microsoft documentation provides more information on this topic:

Setting up a Remote WMI Connection How to configure RPC dynamic port allocation to work with firewalls Enhanced windows discovery also uses the target server admin$ and as such also requires file sharing port traffic to be allowed (port 445). For more information on enhanced windows discovery please see:

Differences between Windows PowerShell Discovery and legacy Windows Discovery WinRM WinRM uses port 5985 (HTTP) or 5986 (HTTPS), this depends on the configuration on the target host. The following Microsoft documentation provides further information on setting up WinRM:

Installation and configuration for Windows Remote Management How to configure WINRM for HTTPS Network Issues Support can provide best effort in trying to resolve such issues. However, for both WMI and WinRM it is best to reach out to the network admin, and system admin, managing the environment where the target device is located in order to resolve connection issues.

Shazzam Shazzam is the first phase of discovery. At this phase, and with default settings, the MID server will send SYN requests to the target server on ports 135, 5985, and 5986. If the target device replies on these ports then the windows classification will be triggered. In the following image we can see the ecc_queue input for a Shazzam probe showing the result for the ports scanned:

404 Microsoft-HTTPAPI/2.0 HTTP/ 1. l Not Pound " width="907" height="155" />

Shazzam successfully detecting ports are open does not guarantee all network requirements are met. There could still be connectivity issues in later phases of discovery where discovery will actually establish a connection to a target server, specially for WMI which requires dynamic ports to complete the connection.

Windows Classification This Windows - Classify WMIRunner probe is the first probe triggered in windows discovery, right after Shazzam. This probe runs scripts WMIRunner.js and WMIScanner.js located in the MID server scripts\WMI folder. This probe communicates to target devices using the MID server service credential and similar to how WBEMTEST connects. Therefore, WBEMTEST could be used from the MID server for troubleshooting.

ed O S … N" width="480" height="470" />

Introduction to WBEMTEST However, starting in Fuji (2015) mid.use_powershell parameter defaults to true and changes how this probe works. With mid.use_powershell = true the logic is effectively replaced with the PowershellProbe logic instead. This adds many benefits of using Powershell, including the use of discovery_credentials table instead of being limited to the MID service account. This probe in turn checks if there are WMI_FETCHDATA parameters, and if so, executes WMIRunner.psm1 script in the MID server. For the Windows classification probe it performs a remote capabilities test.

The remote capabilities test checks:

Remote Admin Share access Powershell access Powershell access is only tested if remote Admin share access test is successful The results of these tests are populated in following parameters:

admin_share_access target_powershell_access These parameters are used in both the classify and on post classify probes. The parameter determines how the probe will collect information from the target, as well as automatically skip probes which require both tests to pass. One of the following messages would be logged to the discovery status history if a PowerShell or WindowsCommand probe is skipped due to the remote capabilities check:

Probe cannot be launched because remote Powershell probes require admin share access and PowerShell on the target Probe cannot be launched because the target's admin share is not accessible from the MID server Probes which collect WMI attributes (The windows classification probe would be one example) have performance benefits when taking the code path executed where both admin share and Powershell access are available on the target. The following documentation further explains these improvements:

Differences between Windows PowerShell Discovery and legacy Windows Discovery Credentials To discover Windows computers using credentials from the credentials table, set the mid.powershell.use_credentials parameter to true. Using credentials from the credentials table is the default behavior (mid.powershell.use_credentials defaults to true).

To force Discovery and Service Mapping to use the credentials of the MID Server service user, set the mid.powershell.use_credentials parameter to false on the MID Server.

For information on permissions, review the following documentation:

Windows Credentials Windows probes and permissions Credential Test Tests can be executed via PowerShell.

WMI # Setup User & Variables: $userName = " " $userPassword = " " $targetIP = $securePasswd = ConvertTo-SecureString $userPassword -AsPlainText –Force $cred = New-Object System.Management.Automation.PSCredential ($userName, $securePasswd) $so = New-CimSessionOption -Protocol Dcom

# Test Credential $session = New-CimSession -ComputerName $targetIP -SessionOption $so -Credential $cred WinRM # Setup User & Variables: $userName = " " $userPassword = " " $securePasswd = ConvertTo-SecureString $userPassword -AsPlainText –Force $cred = New-Object System.Management.Automation.PSCredential ($userName, $securePasswd)

# Test Credential New-PSSession -ConnectionUri http:// :5985/wsman -Credential $cred Remote Capabilities Test Admin Share Log into the MID Server Open PowerShell with the account used for discovering the target device Run Test-Path -Path "\\ \admin$" Target Powershell Access $target = " " $userName = " " $userPassword = " " $securePasswd = ConvertTo-SecureString $userPassword -AsPlainText –Force $cred = New-Object System.Management.Automation.PSCredential ($userName, $securePasswd) $session = New-PSSession -ComputerName $target -Credential $cred -ConfigurationName Microsoft.PowerShell32

Enter-PSSession $session Invoke-Command -Session $session -FilePath c:\file_path\file_Name.ps1 Exit-PSSession Properties and Parameters MID Server parameters for Powershell MID Server parameters Troubleshooting Overall Troubleshooting Shazzam Confirm following ports are open on the target server: If WMI: 135 If WinRM (HTTP): 5985 If WinRM (HTTPs): 5986 On the target server run following command to check the status of the port "netstat -ano | findstr " Confirm firewall is not blocking connections from MID to target On the MID server run "telnet " Classification Check credential can authenticate against the target Log into the MID server Open "Windows PowerShell ISE" Run one of the credential test scripts: WMI WinRM Was the credential test successful? Yes: Continue No: Work with your network and windows team to resolve the error Is the windows management protocol WMI (mid.windows.management_protocol)? Yes: Run the Remote Capabilities Tests No: Continue Set MID server and Powershell to debug Set MID server parameter mid.log.level = debug Set MID server property mid.property.powershell.log_info = true Reproduce issue Review MID server logs Common Errors RPC Server Unavailable Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)) Get-CimClass : Access is denied Additional Information Signing Powershell scripts Microsoft Just Enough Administration (JEA) for Discovery