Skip to main content

Asset Management Troubleshooting Guide

Diagnose and resolve common Asset Management issues in Motadata ServiceOps, covering agent installation, asset discovery, data accuracy, duplicate assets, and SNMP connectivity.

Asset Management in Motadata ServiceOps supports multiple methods of asset creation, including agent-based discovery, agentless discovery, CSV import, and manual entry. Most issues fall into one of four categories: agent communication failures, discovery processing errors, incorrect unique identifier configuration, and permission gaps. This guide provides targeted diagnostics and step-by-step fixes for the most frequent failures encountered in the field.

Prerequisites​

  • Asset Management license is active on the ServiceOps instance.
  • You have the Asset Management role permission.
  • You have backend (SSH/Terminal) access to the ServiceOps server for log review.
  • The agent machine is accessible for log collection.

Asset Creation Methods​

Assets can be created in the following ways. Each method has its own failure points, covered in the troubleshooting sections below.

  • Manual Creation: Created directly through the ServiceOps UI. Learn more
  • CSV Import: Bulk creation using a formatted CSV file. Learn more
  • Agentless Discovery: Network-based discovery without an installed agent. Learn more
  • Agent-Based Discovery: Discovery via the Motadata agent installed on the endpoint. Learn more
  • Via Purchase Order: Assets created automatically from a raised Purchase Order. Learn more
  • Via API: Programmatic creation using the ServiceOps API. Learn more

Common Issues​

Agent installer exits showing an Administrator Rights error

Possible Causes

  • The installer is running without elevated system permissions.
  • Windows User Account Control (UAC) is blocking silent execution.
  • Group Policy restricts the user from running the installer with elevated privileges.
  • The agent build is corrupted or incompatible with the target OS.

Solution

  1. Open Command Prompt as Administrator (right-click > Run as administrator).
  2. Run the installer using the following command:
    msiexec /i "C:\Path\to\AgentFile.msi"
  3. If the issue persists with the latest build, try an older agent version to determine whether the failure is build-specific.
Agent is installed but not visible in ServiceOps

Possible Causes

  • No communication between the machine and ServiceOps (or the Poller, if configured).
  • Incorrect IP, Server URL/FQDN, Poller IP, Activation Code, or Secure Auth credentials used during installation.
  • Antivirus software is blocking agent files.
  • The agent service has stopped or failed to start.
  • The Asset unique identifier values for the machine are blank or resolve to None.

Solution

  1. Verify the installation mode. For agent version 8.5.1 and above, confirm the correct mode was used:

    • Activation Code: Navigate to Admin > Organization > Account > License Details to retrieve the code.

    License Details

    • Secure Auth: Navigate to Admin > Discovery and Agents > Agent > Agent Credential Profile to retrieve credentials.

    Secure Auth

    Compatibility Check

    The agent version must not be higher than the server version. Agent creation via Secure Auth can take up to 5 minutes after installation. Check the API.log file on the agent side:

    C:\Program Files (x86)\Motadata\winagent_service\Logs  (64-bit)
    C:\Program Files\Motadata\winagent_service\Logs  (32-bit)

    API Logs

  2. Check agent-to-server connectivity. Run the following from the agent machine:

    curl -v <serverURL>

    A response without errors confirms connectivity.

  3. Check Poller connectivity (if applicable). Use Telnet to test the connection:

    Syntax: telnet {Poller_IP_Address} <Port>
    Example: telnet 172.16.11.157 8080

    Use port 8080 for a Windows Poller and 8090 for a Linux Poller. A blank screen after connection confirms success.

    Blank Screen

  1. Validate the config.ini file. Located at C:\Program Files (x86)\Motadata\winagent_service. Confirm the Activation Code, Server URL, and (for v8.5.1+) the secure_auth key match valid values.

Config File

  1. Review agent logs. Check Logs > main.log at the agent install path for installation or communication errors.

  2. Check agent service status.

    • Windows: Open Services and confirm the Motadata ServiceOps service is running.
    • Linux: Run systemctl status motadata_serviceops. Restart if needed.

  3. Whitelist agent files in antivirus and firewall settings.

  4. Verify OS and architecture compatibility. Refer to the Supported OS Version List. For unsupported OS versions, raise a support ticket for a custom discovery pattern.

  5. Asset Identifier check. If the unique identifier value is blank or None, asset creation will not proceed. See section 4.8 for identifier troubleshooting.

Agent registered in Agent List but asset not created (Agent version 8.4.5 and below)

Possible Causes

  • WMI or PowerShell is disabled on the endpoint.
  • Antivirus or firewall is blocking PowerShell or WMI queries.
  • Discovery process failed on the agent side.
  • The asset creation API call to the server is failing.
  • Insufficient permissions for the user installing the agent.
  • The asset already exists in the Stage or Archived state.
  • Required custom fields are missing from the Asset Form.
  • Agent architecture mismatch (32-bit vs. 64-bit).
  • Agent prerequisites (.NET Framework, PowerShell 3.0+) are not installed.
  • The NSQ queue for Asset Operations is stuck.

Solution

  1. Verify WMI access.

    wmic os get version

    Verify WMI

  2. Verify PowerShell execution.

    powershell.exe Get-CimInstance -ClassName Win32_OperatingSystem

    If blocked by Group Policy, adjust settings or contact your IT administrator.

    Verify PowerShell

  3. Check antivirus restrictions. Whitelist powershell.exe and wmiprvse.exe. Temporarily disable antivirus to test if asset creation succeeds.

  4. Review discovery logs on the agent. Check Discovery.log at C:\Program Files (x86)\Motadata\winagent_service\Logs for discovery errors.

  5. Verify the asset creation API call. Check API.log at:

    • 64-bit: C:\Program Files (x86)\Motadata\winagent_service\Logs
    • 32-bit: C:\Program Files\Motadata\winagent_service\Logs

    Verify asset creation

    Search for /discovery/data calls. The response must show success.

  6. Ensure Proper Installation Rights

    • The agent must be installed by an admin user with sufficient privileges for discovery.
    • Check if the user has full administrator rights.

  7. Check Server-Side Discovery Logs

    • On the ServiceOps server, review the Discovery.log file when the agent sends the asset creation request.
    • Check error.log on the server for any failures at the same timestamp.

    API Log

8 Check Stage and Archived assets.

  • The asset may already exist in a non-active state:

  • Navigate to the Hardware Assets list and select More Options > Asset in Stage.

  • Apply the All Archived Hardware Assets filter.

    Asset in stage

  1. Validate the Asset Form. If custom fields are marked required, ensure the agent sends values for them. Make fields optional or update the agent configuration if needed.

  2. Verify agent architecture. Confirm the installed agent (32-bit or 64-bit) matches the OS architecture. Reinstall with the correct version if there is a mismatch.

  3. Check prerequisites.

    $PSVersionTable

    PowerShell 3.0 or higher and .NET Framework must be installed.

    PowerShell Version

  4. Restart services if the NSQ queue is stuck.

    systemctl restart ft-main-server

    If the queue depth continues to grow after restart, also restart the Analytics Server:

    systemctl restart ft-analytics-server

    Contact support is the issue persists.

Agent created but asset not created (Agent version 8.5.0 and above)

Possible Causes

  • WMI or PowerShell execution is disabled.
  • Antivirus or firewall is blocking PowerShell or pattern-executor.exe.
  • Discovery classification failed (OS type not detected).
  • pattern-executor.exe is not running or is stuck.
  • The asset creation API call (/discovery/data) is failing.
  • Unique identifier values are missing or mismatched (e.g., motherboard serial number not found).
  • The discovery pattern for the machine's OS is disabled in ServiceOps.
  • The endpoint runs Windows 7.
  • Corrupted agent installation with residual files in C:\ProgramData\Motadata\WinAgent.
  • The .exe downloads are restricted.

Solution

  1. Check PowerShell Execution Policy.

    Get-ExecutionPolicy

    Get Execution Policy

    If restricted, set to RemoteSigned for testing:

    Set-ExecutionPolicy RemoteSigned

    Verify WMI is functional:

    Get-WmiObject Win32_ComputerSystem

    If blocked, check Group Policy or Antivirus restrictions

  2. Whitelist the following in Antivirus:

    • powershell.exe
    • pattern-executor.exe
    • MotadataServiceOps.exe

  3. Temporarily disable AV for testing (if allowed).

  4. Validate discovery classification. Check cmdb.log for cf_1 Result. This should show OS details (for example, Windows 10). A null result indicates PowerShell or WMI is blocked.

    System Preference

    Set Execution Policy

  5. Check if pattern-executor.exe is running. Open Task Manager > Details. If the process is absent, restart the agent service (MotadataServiceOps.exe).

    Validate Discovery Classification

  6. Verify the API call. Search API.log for /discovery/data. The HTTP response must be 200 OK. If failing, check error.log on the server at the same timestamp.

  7. Confirm unique identifiers. Navigate to Admin > Organization > System Preference > Asset/CMDB Preference and verify the identifier configuration matches what the agent sends (for example, motherboard serial number).

    Task Manager

  8. Check the discovery pattern status. Navigate to Admin > Discovery and Agents > Discovery Pattern > Discovery and confirm the OS-specific pattern is enabled.

    Discovery Pattern

  9. Windows 7 limitation. Agent v8.5.0 and above do not support Windows 7. Use one of these alternatives:

    • Install agent v8.4.5 or below.
    • Use Agentless Discovery.
    • .Net Framework 4 must be installed

  10. Reinstall the agent (if all steps above fail).

    • Uninstall the agent.
    • Delete C:\ProgramData\Motadata.
    • Reinstall the agent.
Asset created but data is incorrect or missing

Possible Causes

  • Discovery data was not collected correctly by the agent.
  • PowerShell or WMI command failed during the discovery cycle.
  • A data transformation or processing error occurred on the server.
  • Asset data was manually modified after creation.
  • The discovery pattern does not match the actual system configuration.
  • Insufficient permissions prevented proper data collection.

Solution

  1. Verify data at the agent level.

    • Check API.log on the agent machine.
    • Search for the expected component data (hardware specs, installed software) in the API payload.
    • If data is missing, check cmdb.log at C:\Program Files (x86)\Motadata\winagent_service\Logs.

    cmdb.log

  2. Test PowerShell collection manually.

    powershell.exe Get-CimInstance -ClassName Win32_OperatingSystem

    If blocked by Group Policy, adjust the settings or consult the IT admin..

  1. Validate server-side processing.

    • Check discovery.log at /opt/flotomate/main-server/logs/apolo for processing errors.
    • Compare the data with the agent's API.log payload.

    Verify PowerShell

    Also review error.log for data transformation or pattern-matching failures.

  1. Test the discovery command directly.

    Locate the PowerShell or WMI command in the Discovery Pattern configuration, run it on the endpoint, and compare the output against what is shown in ServiceOps. A discrepancy indicates the discovery pattern needs adjustment.

  2. Check for manual changes.

    Navigate to Asset Details > History > Change Logs to confirm whether data was modified after creation. If unauthorized changes are occurring, consider locking critical fields.

    Discovery Logs

  3. Verify the discovery pattern is enabled for the asset's OS type under Admin > Discovery and Agents > Discovery Pattern.

Device is active but the agent shows as inactive

Possible Causes

  • The endpoint machine can no longer reach the ServiceOps server.
  • The Server IP or URL has changed since the agent was installed.
  • The agent service has stopped.

Solution

  1. Verify agent services are running on the endpoint machine.

  2. Validate config.ini. Open the file at C:\Program Files (x86)\Motadata\winagent_service and confirm the server URL, IP address, and protocol are correct.

    Config File

  1. Review agent-side logs. Check Main.log at C:\Program Files (x86)\Motadata\winagent_service\Logs for connectivity errors.

    Config File

  2. Review server-side logs. Check agent.log at /opt/flotomate/main-server/logs/apolo for incoming connectivity issues.

    Server-side Logs

  3. Check Agent Preferences. Navigate to Admin > Organization > System Preference > Agent Preference and validate the configured values.

    Agent Preference

  4. Verify agent cycle configuration. Open config.ini and confirm the values under the cycles section are correct.

    Agent Cycle Data

  5. Windows: set agent services to start automatically. Ensure agent services are configured for Automatic startup in the Windows Services application.

    Services Application

  6. Restart agent services. If the agent becomes active after restart, collect the agent logs for further analysis.

Discovery scan not running despite active device and agent

Possible Causes

  • The NSQ topic for scan or asset creation events has a growing backlog (depth value increasing).
  • NSQ consumer services are stuck or unresponsive.
  • High CPU or memory load is preventing message processing.
  • Intermittent network issues between NSQ and its consumers.
  • A service crash has left components in an inconsistent state.

Solution

  1. Log in to the ServiceOps server via Terminal as the root user.

  2. Check NSQ topic stats.

    Run the following command to review the NSQ status:

    curl http://127.0.0.1:4151/stats

    NSQ Stats

  1. Locate the relevant topic for the failing process (scans, asset creation).

  2. Evaluate queue depth. If the depth value is not decreasing and continues to grow, the queue is stuck.

    NSQ Stats

  3. Restart services to clear the backlog.

    systemctl restart ft-main-server
    systemctl restart ft-analytics-server

  4. Verify recovery. Run the NSQ stats command again after restart and confirm the depth value is decreasing.

  5. Check the agent API log. On the agent machine, open API.log and search for /discovery/data calls. Confirm they return HTTP 200 OK. If failing, review error.log on the server at the same timestamp.

    Identify Topic

Duplicate assets are being created

Possible Causes

  • Non-static fields (such as IP addresses) are included in the unique identifier configuration.
  • Unique identifier values change across discovery cycles (for example, DHCP-assigned IPs).
  • Blank or null values are returned for configured identifiers.
  • The agent retries asset creation when the server does not respond with success.
  • API calls between the agent and server have failed.
  • CSV imports have modified unique identifier values.
  • Virtual machine clones report identical hardware IDs.

Solution

  1. Review the unique identifier configuration. Navigate to Admin > Organization > System Preference > Asset/CMDB Preference. Use only static identifiers such as motherboard serial number or BIOS UUID. Remove dynamic fields such as IP addresses.

    Unique Identifiers

  2. Validate identifier values on endpoints. Identify machines where identifiers return different or blank values across discovery cycles. Update discovery patterns if identifiers resolve to blank.

  3. Check server communication. Review API.log on the agent for failed creation calls. The server response must contain success. Upgrade to ServiceOps 8.5.x or above if running an older version.

  4. Prevent import-related duplicates. Always verify CSV files before import. Do not modify unique identifier columns during import. Use the Update Existing option when re-importing.

  5. Resolve existing duplicates. Compare unique identifier values to identify duplicates. Merge or archive incorrect records. Review discovery.log for identifier conflicts and monitor for multiple assets sharing the same identifier.

Logs to collect for persistent issues
  • Server-side: discovery.log, error.log
  • Agent-side: API.log, cmdb.log
  • CSV import files (if applicable)

Logs

SNMP discovery is not detecting devices

Possible Causes

  • The target device is unreachable or the network firewall is blocking SNMP traffic on UDP port 161.
  • Incorrect IP address or hostname is configured.
  • SNMP credentials are incorrect (community string for v1/v2c, or username/auth/privacy settings for v3).
  • A mismatch exists between the configured and the device's SNMP version or authentication/privacy protocol.
  • The SNMP service is not enabled on the target device.
  • Device ACLs are restricting SNMP access.
  • MIBs are not properly installed on the ServiceOps server.

Solution

  1. Verify basic connectivity.

    ping <device_ip>
    nc -zv <device_ip> 161

  2. Test SNMP credentials directly.

    For SNMPv2c:

    snmpwalk -v2c -c <community_string> <device_ip> system

    For SNMPv3:

    snmpwalk -v3 -l authPriv -u <username> -a MD5 -A <auth_password> -x DES -X <priv_password> <device_ip> system

    snmpwalk Command

  3. Validate the ServiceOps credential configuration. Navigate to Admin > Discovery and Agents > Credentials > SNMP. Confirm the correct SNMP version, authentication protocol, and privacy protocol are selected and match the device configuration.

SNMP Credentials

  1. Confirm the device responds to SNMP. Verify you receive a valid snmpwalk response from the target device before running discovery in ServiceOps.

    snmpwalk Command

Dedicated SNMP Guide

For detailed SNMP credential configuration and advanced device troubleshooting, see the SNMP Device Connectivity and Discovery Troubleshooting Guide.

Quick Reference Matrix​

IssueProbable CauseQuick Fix
Asset not createdWMI/PowerShell services disabledEnable services and run test commands manually
Asset not created via agentAgent misconfigured or installation incompleteReinstall the agent and verify config.ini parameters
Asset created but not updated after changesDiscovery not triggered or pattern misconfiguredRun manual discovery and check cmdb.log
Duplicate assets createdUnique identifier based on dynamic values (IP, hostname)Use static identifiers such as BIOS UUID or MAC address
Agent not showing as ActiveServer URL mismatch or Secure Gateway unreachableUpdate config.ini, verify connectivity, restart agent
Scan not executing via agentNSQ queue backlog or discovery thread crashedRestart the Main Server and Analytics Server
Asset deleted after reinstallationIncorrect deallocation setting or unique ID mismatchChange the deallocation policy or adjust the unique field mapping
Agent not auto-upgradingAuto-upgrade disabled or upgrade package missingEnable auto-upgrade, check upgrade.log, or upgrade manually
Agent appears more than onceAgent installed multiple times with different credentialsUse the same install method and credentials; merge or remove duplicates
Software inventory missingRegistry or PowerShell access blockedEnable permissions, check antivirus, validate discovery pattern
CSV import results in blank or incomplete assetsField mismatch or invalid data in CSVUse the system-generated template and validate mandatory fields
Agent not communicating with serverProxy, firewall, or TLS issuesCheck logs, validate port access, verify certificates if HTTPS is used
Slow agent registrationHigh server load or NSQ message delaysScale server resources or increase worker threads for API and NSQ