Audit Troubleshooting

This page lists some common issues that can lead to audit failures and offers recommendations on how to troubleshoot them.

• Computers and devices are offline

  All the network nodes you are trying to discover or audit must be available on the network (online, turned on, etc.). You can ping a computer or device to make sure it is responding correctly. If it is not responding, there must be an issue with its configuration.

• Audit credentials lack administrative access

  The audit credentials used for the Direct Network Scan must correspond to a user account that is a member of the local Administrators group on each Windows client machine, whether through membership in a Windows domain group or assigned directly.

  For more details, refer to Managing Audit Credentials.

• Local audit account does not exist

  When using a local account for the Direct Network Scan of Windows computers,Network Inventory requires that this account belongs to the local Administrators group and exists on every client computer you intend to audit. More information can be found in Managing Audit Credentials.

  Even when the requirements are met, the Direct Network Scan under a local audit account may occasionally fail with the following error message:

  Failed: Error connecting to host (Error: 1312. A specified logon session does not exist. It may already have been terminated).

  To work around this issue, on the Automation Server computer, create the local account that you intend to use for the Direct Network Scan, and add this account to the local Administrators group.

• Administrative shares are disabled

  The Direct Network Scan Audit of a Windows computers relies on the hidden administrative share (ADMIN$) that Windows uses to manage the computer environment on the network. Some administrators consider administrative shares to be a security risk and disable them completely. Make sure the administrative shares of a Windows computers are enabled. Moreover, the absence of administrative shares on your computer can lead to various issues unrelated to Alloy Navigator Express.

  For details and resolution, see Microsoft Knowledge Base article Overview of problems that may occur when administrative shares are missing.

• Client for Microsoft Component is disabled on the Automation Server

  On Automation Server running Windows XP / Windows Server 2003 or later, you are unable to remotely audit computers when the Client for Microsoft Networks component and Workstation service are not installed and configured.

  1. Make sure that the Client for Microsoft Networks component is installed and enabled.

  2. The Client for Microsoft Networks component corresponds to Windows network service Workstation. Configure and start the Workstation service.

• Windows firewall and third-party firewall products are enabled

  An enabled firewall may block access to remote connections. By default, Windows Firewall closes the ports used for file and printer sharing to prevent Internet computers from accessing your shared files and printers. Third-party firewall products may employ a similar approach.

  If you are using a firewall, open the ports used by File and Printer Sharing for your local network to enable the audit.

  For more details and resolution, see Microsoft Knowledge Base article Internet firewalls can prevent browsing and file sharing.

• User Account Control (UAC) is enabled

  UAC enables users to perform common tasks as non-administrators, and as administrators without having to switch users, log off, or use Run As. UAC also affects remote connections to computers. When a local user account is used to connect to a machine, the user is identified as a standard user even if the account is in the Administrators group. Since regular users do not have administrative rights, the audit fails.

  The method for resolving this issue depends on whether you are connecting to a remote computer in a domain or in a workgroup, as this determines whether UAC filtering is enabled. For detailed information about disabling UAC, see Administration Guide: Troubleshooting the Direct Network Scan.

• NetBios is disabled (Network connection properties)

  Disabling NetBIOS in the network connection properties can result in various connection errors, such as "No such host is known". To check this setting, navigate to Network connection properties > Internet protocol (TCP/IP) > Properties > Advanced > Wins tab on the nodes that produce the same or similar errors during the audit.

• SSH daemon is disabled for Mac

  The Apple Mac OS X includes SSH by default, but the SSH daemon is not enabled. In this case, remote connections are not possible. To enable it, follow these steps:

  1. Go to System Preferences.

  2. Under Internet & Networking, run the Sharing icon.

  3. In the list that appears, select the Remote Login option. The SSH daemon will start immediately, allowing you to remotely log in with your username and password.

• Incorrect SSH protocol configuration for Linux and Mac

  The Direct Network Scan of Linux and Mac computers establishes connection to the audited computers using the Secure Shell protocol (SSH). By default,Network Inventory accesses client Linux, Mac computers and Linux-based hypervisors (VMware ESX, Xen, and Citrix XenServer) over the standard TCP port 22. However, when the SSH server on your client computers listens on a non-standard TCP port, you can specify another port number when providing audit credentials for the Audit Source or for particular computers.

  For details, see Managing Audit Credentials.

  Make sure that each client Linux and Mac computer has the SSH server running and listening on the TCP port. Otherwise, the Direct Network Scan will fail.

  If you connect to Linux and Mac computers using your SSH private key instead of a password, make sure the SSH public/private key pair is properly set up and the public key is uploaded to all Linux and Mac computers you want to audit. Additional information on SSH public key authentication can be found at the following web address: http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter8.html.

• Extended hardware information is not collected on Linux

  To access low-level hardware information (hardware serial numbers and asset tags) from a Linux system during the Direct Network Scan, the user account used for auditing the system must have root privileges. For details, see Linux and Mac Audit Credentials.

  Some administrators consider providing credentials for the root account a security risk. You can configure the Direct Network Scan to collect extended hardware information using audit credentials for a non-root account. For instructions, see Administration Guide: Linux and Mac Direct Network Scan.

• Windows Remote Management 2.0 is missing

  The Direct Network Scan of VMware ESXi hypervisors requires that the computer hosting the Automation Server instance has Windows Remote Management (WinRM) 2.0 or later installed. This component is also required for VMware ESX hypervisors when they do not have the SSH server running and listening on the dedicated TCP port.
  
  WinRM 2.0 component is included in Windows 7 and Windows Server 2008 R2. Windows 8, Windows 8.1, Windows 10, Windows Server 2012, and Windows Server 2012 R2 include WinRM 3.0. If your Automation Server instance is installed on a computer running Windows XP Professional, Windows Vista, Windows Server 2003, Windows Server 2003 R2, or Windows Server 2008, install the Windows Management Framework Core package, which includes WinRM 2.0 and Windows PowerShell 2.0. To download the appropriate update from the Microsoft Download Center, see Microsoft Knowledge Base article Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0).

• The WS-Management service is not running on VMware ESXi 6.5

  The Direct Network Scan of VMware ESXi 6.5 requires the WS-Management service to be running on an ESXi host. On a newly installed ESXi 6.5, this service is turned off by default. To turn on the WS-Management service, enter esxcli system wbem set -e 1 on the command line and press Enter.

• Task List performance degradation

  If you are experiencing a noticeable degradation Task List performance, it may result from the accumulation of old tasks in the system.

  To resolve this issue, regularly review and delete tasks that are no longer needed or relevant. By removing obsolete tasks, you can help maintain optimal system performance.

• Other issues

  • You are not allowed to use blank passwords for the audit credentials. Windows XP SP2 and higher will deny access under an account with a blank password. For details, see Managing Audit Credentials.

  • Ensure there are DNS issues related to the name of the Network Inventory application host machine or the IP address of the client machine. For example, the name of the DNS entry for the Network Inventory application host machine must match its computer name, and the IP address of the client machine must be unique within the DNS.