IMPORTANT: Keep checking the MAP Blog and MAP Toolkit Content Index (en-US) for updates and changes , especially after new versions of MAP are released.

Each computer that is inventoried gets a status code indicating whether the inventory of the target succeeded or not. This is a guide to the possible error messages and provides some background on why they occur.

Network-level failures

These error messages roughly correspond to the error raised by WinSock: http://msdn.microsoft.com/en-us/library/ms740668(VS.85).aspx

• Failed – Machine not found:

The hostname failed to resolve via DNS. This could have been a timeout (overloaded DNS server didn’t respond in a timely manner), failed connection (no route exists to DNS server), or the host name simply wasn’t in DNS at the time it was queried. At the winsock layer, this would be WSAHOST_NOT_FOUND. A WSATRY_AGAIN during name resolution can also cause this if WSATRY_AGAIN is received on the final inventory retry attempt.

• Failed – Connection Timeout:

The hostname resolved in DNS successfully to an IP address. Then MAP tried to open a connection to port 135 to see if the machine was firewalled or otherwise not listening on port 135 (possibly it’s a Linux machine or other non-windows or device). When trying to open TCP/135, the connection timed out (this is a normal TCP/IP connection timeout)

Note: MAP doesn’t try to do a traditional ping (ICMP) and instead relies on being able to open TCP/135 in the WMI inventory scenario to determine if the machine is alive/reachable or not.

• Failed – Connection Refused:

The host is up and running, but when MAPS tried to connect via DCOM/WMI, the connection was refused. Could have been for multiple reasons:

• Firewall blocking the port by accepting the sending a 'nak' (negative acknowledgement) when receiving a 'sync' rather than not responding at all
• Target computer too busy
• WMI service isn’t running
• Possibly others
• Failed - Host Unreachable:

This is WinSock error WSAENETUNREACH, usually caused by a network topology issue (no known route to the host exists)

DCOM (RPC) failures

These error messages are usually raised by the DCOM layer:

• Failed – Access Denied:

MAP couldn’t find any credentials in the list of credentials entered in the UI that would work for the target machine.

• Failed - RPC Server Unavailable:

This is a generic RPC error and the root cause can be related to several possible issues. This Wiki article discusses how to troubleshoot this error: Troubleshooting "The RPC server is unavailable"

• Failed - RPC call failed:
  1. WMI service isn’t running on the target machine
  2. WMI configuration is corrupt on the target machine
  3. MAP is misconfigured and asks for a WMI namespace that doesn’t exist on the target machine (retry class error)
• Failed - RPC call cancelled:

  Unclear why this happens, but appears to be one of two reasons: the target machine is overloaded and can’t answer the query, or (less likely), the machine running MAPS is overloaded and the WMI client starts killing outstanding sessions (retry class error)

  WMI Failures

  These errors are from the WMI layer:

  • Failed - Invalid CIMv2 WMI Namespace:
  • Failed - CIMv2 WMI Namespace not found:
  • Failed - CIMv2 WMI Namespace invalid parameter:
  • Failed - Invalid StdRegProv WMI Namespace:
  • Failed - StdRegProv WMI Namespace not found:
  • Failed - StdRegProv WMI Namespace invalid parameter:

  This means that the target machine returned a “Invalid Namespace” error, Namespace not found error, or invalid parameter error when MAPS tried to connect to either the root\CIMv2 WMI namespace or the root\DEFAULT:StdRegProv namespace (for registry lookups) on the target machine. This should never happen, and suggests something is seriously wrong with WMI on the target machine (every Windows machine should support the CIMv2 and the StdRegProv namespace)

  • Failed - Computer shutting down:

  MAPS happened to connect to a computer as it was in the process of shutting down. (retry class error)

  This error message is generated from MAP itself when it thinks that a thread is blocked waiting for a WMI call to complete:

  • Failed - WMI query time out:

  MAP successfully connected to TCP/135, then during authentication for DCOM/WMI or just in the course of issuing a WMI query, the query timed out (this is a fairly long timeout and is issued by MAPS itself against an inventory thread if the thread appears hung and doesn’t show progress for more than 5 minutes). If at least one WMI query succeeds against a particular target computer, you won’t get this error. (Retry class error)

  • Failed - No credentials provided:

  This shouldn’t happen, this basically means that inventory was started without any username / passwords provided from the UI to the inventory engine. If the MAPS UI is working correctly, this won’t happen.

  There are a handful of other errors that can occur during WMI inventory that MAP will catch, and then schedule that computer for retry:

  ManagementStatus.ServerTooBusy

  ManagementStatus.ShuttingDown

  ManagementStatus.Timedout

  ManagementStatus.TransportFailure

  ManagementStatus.ServerTooBusy

  If these errors happen for every single WMI class for every retry attempt, then these errors may result in “Failed – Other Reasons” status code for that computer.

  In the previous list, items marked as "retry class error" will cause the inventory for the target computer to be immediately abandoned and then scheduled for retry later during the same inventory run. The inventory engine will allow 3 such retry attempts (for a total of 4 attempts) before the computer is abandoned completely and marked as failed.

  If the target computer is scheduled for retry in MAPS 5, there is some reordering of the order in which the WMI classes are attempted to be inventoried; the class that was being attempted at the time of failure will be moved to the end of the list (this is new behavior for MAPS 5). This will allow for a more complete inventory in cases where a particular WMI provider on the target machine is responding slowly or not at all; the other classes that have not yet been attempted and may be responding correctly will then be tried first on the next retry and the offending class will be tried last. This may allow for a more complete inventory than was possible in previous versions of MAPS.