Troubleshooting WMI issues

If you encounter issues with Windows Management Instrumentation (WMI) in your BMC Discovery installation environment, use the steps described in this section to either resolve the issues or create a BMC Support case.

Issue symptoms

WMI issues involve script failures, access denial, or a block in port communication when the discovery access method used is WMI.

Scope

This issue affects all versions of BMC Discovery.

Resolution

When troubleshooting WMI issues, go to the DiscoveryAccess page for the Windows host and check for error messages, such as script failure or NoAccessMethod where the access method is WMI.

Click the script failure link to know more details about the cause. In this example the error message is, Failed to get service list:Failed to retrieve batch of results:0x80041003:Access denied.

To resolve this issue, examine the WMI query executed for this script. The query is located at Administration > Platforms > Windows > WMI tab. In this example. the script is getServices. Under the WMI tab of the platform script, it shows that getServices is executing the script, SELECT * FROM Win32_Service. The error message, Access Denied could indicate a permissions issue. You can use Wbemtest locally on the target host as the account used for discovery. Perform the following steps:

1. Log in to the target machine that uses the discovery credentials to discover this device.
2. From the Run command, execute wbemtest. 
   
   
   
   
3. Retain the default settings and click Connect.
   
   
   
   
4. Click Query and run the query listed on your WMI platforms page.
   In this example, the query is SELECT * FROM Win32_Service. Since the query returns the service names, it indicates an issue with reading the data remotely.
5. Launch wbemtest from the proxy or the Outpost. 
   
   
   
   
6. Specify the target machine by using \\<IP_ADDRESS>\root\cimv2 in the Namespace field, and entering the user information.
   After running the query, the message, Access Denied confirms that remote access is the issue.
   You can also test this by using WMIC from the proxy or Outpost server. WMIC does not allow for the format, SELECT * FROM, so use GET. 

7. Start a command prompt window and enter the following command:

   wmic /node:<IP_ADDRESS> /user:'<USERNAME>' /password:<PASSWORD> PATH Win32_Service

   1. If BMC Discovery skips the device or a credential test fails to connect, confirm if the WMI ports are open from the proxy or Outpost server.

   2. View the error message in a credential test to confirm if the WMI ports are open. However, the above WMI test too will do it. The common error message for blocked WMI communication (port 135) is, The RPC server is unavailable.

8. Test the port communication on the Outpost or proxy by using Nmap or PowerShell.
   
   

   • Nmap

     "C:\Program Files\BMC Software\Discovery Outpost\nmap\nmap" -p 135 <IP_ADDRESS>

   • PowerShell

     test-netconnection -port 135 <IP_ADDRESS>

   The WMI service, Windows Management Instrumentation, should also be running. Otherwise, you may get the error message, The service cannot be started. The service is likely disabled.
   
   
   If you get an access denied error but the user is a part of the Administrator’s group, then the likely cause is UAC (User Account Control). UAC treats members of the Administrator group as standard users. 

9. If access denied is still occurring after disabling UAC and rebooting, then remote management may not be configured. This can be done with the command winrm quickconfig, which will show the required changes for remote access to work. This command does the following as per Microsoft's documentation :
   • Starts the WinRM service and sets the service startup type to auto-start.
   • Configures a listener for the ports that send and receive WS-Management protocol messages by using either HTTP or HTTPS on any IP address.
   • Defines ICF exceptions for the WinRM service, and opens the ports for HTTP and HTTPS.
     
     
     
     This also disables UAC remote restrictions by setting the following registry key.
   • If the winrm quickconfig command does not work, you can do it manually. Perform the following steps:
   1. 1. Open the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
      2. Create a new DWORD value named, LocalAccountTokenFilterPolicy.
      3. Set its value to 1.
10. If the access denied errors are still occurring, review the WMI control and DCOM permissions on the target host. To do this, perform the following steps:
    1. Under Computer Management, expand Services and Applications and right-click WMI Control to open Properties.
    2. Click Root and then click Security.
       
       
       
       
    3. Add the user account and click Advanced. Ensure that you select the Enabled Account and Remote Enabled options for this namespace and sub-namespaces.
       
       
       
       
    4. To ensure that the account has remote access to DCOM, do the following:
       1. From the Run command, execute DCOMCNFG.
       2. Expand Component Services > Computers and right-click My Computer to open Properties.
       3. Under the COM Security tab, click Edit Limits under Launch and Activation Permissions.
       4. Add the user account, select the permissions Remote Launch and Remote Activation, and then click OK.
          
          

Besides the issues listed earlier, another common WMI issue is that unexpected values are set for the Windows host. Since the data is pulled directly from the host, you can view the script results under the DiscoveryAccess page for the host. Review and execute the Windows platform WMI scripts manually as shown at the beginning of this topic to confirm that the target machine is the source of the issue. Unexpected hostname and domain information are common issues.

The following are the WMI methods that BMC Discovery uses when populating the hostname and domain fields in the Windows host node. If any of these values are incorrect on the target, manually correct them so that the host gets updated on the next discovery run. 

• Hostname is set by the following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Hostname

• NIS/Windows Domain is retrieved from the WMI query, Select domain from WIN32_ComputerSystem.

• DNS Domain
  • If the AD policy Primary DNS Suffix is set for the Windows server, the following registry key is used:

HKLM\SOFTWARE\Policies\Microsoft\System\DNSClient\PrimaryDnsSuffix

• • If the AD policy is not set, it uses the following WMI query:

SELECT DNSDomain FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = 1"

• • If the AD policy is empty, it uses the following value from a network interface:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<instance ID>\domain

• • If the AD policy is empty, it falls back to the following DHCP domain value:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<instance ID>\DhcpDomain

• • If the interfaces do not have any of the keys listed above, they use the following key:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Domain

• Local FQDN is built on the hostname + DNS domain. 
• Name values under the network interface of the Host node is set by the appliance or the Outpost running nslookup for the IP address of the network interface.