Troubleshooting Windows scan failures

Issue symptoms

• A scan of Windows devices fails with any of the following messages: 
  • NoAccess
  • skipped - Device is an unsupported device

Issue scope

• One or more devices fail with this error.
• Windows credentials are configured for the device.
• Windows Proxy has been configured for the device.
• The required firewall ports are configured for the device.

Resolution

Perform the following steps to troubleshoot the scan failures:

Step 1: Verify the prerequisites

1. Perform the credentials test, and check if it fails or succeeds.
   If the credentials test is successful, move on to the next steps. If the credentials test fails, check with your network team if the credentials for the device are working and valid.
2. Verify that the account used for the scan has sufficient permissions to do a complete discovery.
   If the scan is using a credential proxy, the credential should have local Administrator rights on the target server.
   If the scan is using an Active Directory proxy, the proxy service should be running as a domain authenticated account with local Administrator rights and the log on as user right on the target server.
3. Check the connectivity to know if the proxy or Outpost can access the target device successfully.  

   1. To check the connectivity, perform the following step:
      From the Windows proxy or the Outpost, run the following commands and check the results:

      ping [device_ip_address]
      traceroute [device_ip_address]

      The expected result is that the devices should be reachable and responding.

   2. Check port 135:

      The appliance scans port 135 to determine whether the port is open and therefore the target is likely to be a Windows host. If the port is open, then further discovery is undertaken using the Windows proxy. If the port is blocked, no Windows discovery is attempted.

      To test this, open a command line on the Discovery appliance and enter the following command:

      telnet target 135

      where, target is the IP address of the Windows host to be discovered.

   3. Check if other required ports are open:
      Check for firewalls between the proxy and the target. Verify that required ports are open. Note that Windows discovery requires more than just port 135 to be opened. For more information on the ports used for Windows discovery, see Network-ports-used-for-discovery-communications.

   4. Confirm that WMI is active and working correctly on the target server:
      Open a command prompt on the proxy server or the Outpost and execute the wmic command. Examples:

      wmic /node:<ipaddress> /user:<domain\username> /password:<password> PATH Win32_PhysicalMemory
      wmic /node:<ipaddress> /user:<domain\username> /password:<password> PATH Win32_ComputerSystem get Name
      wmic /user:mydomain\someuser /password:somepassword /node:remotehost /output:"c:\win32_computersystem.csv" path win32_computersystem Get /All /format:csv

      To check if WMI can see the HBA information, use the above commands.
      The same command can also be executed on the target host, for example:

      wmic PATH Win32_PhysicalMemory

      You can also refer to the following video that explains how you can troubleshoot Windows WMI discovery failures: 
      

       https://youtu.be/vOoghM2GzSU
      
      If the command works on the scanned host, but fails from the proxy, the root cause is in the network (typically a firewall, local or otherwise). In some cases, starting or restarting the WMI service on the target may be helpful. Please consult the device administrator.
      If the problem persists, please contact Customer Support and provide the results to all the questions and checks you performed above.
      However, if all the prerequisites are working fine, proceed to the following Step.
      
      

Step 2: Increase the WMI timeout from the proxy or Outpost configuration

If WMI connectivity works using the WBEMTEST utility or WMIC command, but still WMI fails during discovery, then increase the WMI timeout from the proxy or the Outpost configuration and check the scan. behavior.

To increase the timeout for the Windows proxy:

• In the Discovery UI, go to Manage > Credentials > Manage Windows Credential Proxy >[Windows_proxy] > WMI. Set the timeout to 180 or above.

To increase the timeout for the Outpost:

• In the Outpost UI, go to Manage > Configuration > Use WMI. Set the timeout to 180 or above.

If increasing WMI timeout resolves the discovery issue, contact your Windows team to check why WMI is responding slowly.

After performing both the steps described earlier, if the problem is still unresolved, do the following:

1. Rescan the endpoint with the discovery and proxy logs in debug mode.
2. Gather the Windows event logs (system, application, security) from the target system and the proxy machine at the time of failure.
3. Open a Support case and provide the above logs and the results to all the questions or checks above.