Online Help

Inventory troubleshooting

This guide groups common Inventory symptoms by observable behaviour and walks you through verification and resolution.

Symptom: Two near-duplicate device rows in Inventory (same name, different UUIDs)

Likely cause: The device-identification algorithm could not uniquely match a new audit snapshot to an existing record. Common root causes include hardware reporting a vendor-generated or repeated BIOS UUID, or a Windows reinstall that changes the MachineId.

Where to verify:

  • The Inventory grid for the device type — both rows visible with the same Name but different underlying identifiers.
  • Each row's Audit tab — both Audit ID values are needed for support reconciliation.

Resolution:

  1. Open both device rows from the Inventory grid.
  2. Note both Audit ID values from each row's Audit tab.
  3. Confirm the device's BIOS UUID is stable: if hardware reports a non-unique UUID, configure the Windows MachineId fallback site setting to treat that UUID as non-unique (your AlloyScan administrator manages this site setting).
  4. After the fallback is in place, subsequent audits identify the device by MachineId rather than BIOS UUID. New duplicates should not appear; existing duplicates can be reconciled with vendor support using the captured Audit IDs.
  5. If the duplication continues, contact support with both Audit IDs, the device hostname, and the timestamps of recent audits.

See How to configure Windows MachineId fallback for the setting that reduces duplicate identity matches.

Note: Details may vary by deployment.

Symptom: A device is missing from Inventory after a successful audit

Likely cause: The device is on the segment's Ignore List, has been pruned by Inventory pruning, or the audit failed silently for that device.

Where to verify:

  • Network > Segments > <segment> Open view > Ignore list — confirm the device is not listed.
  • Admin Center > Site Settings > Settings > Inventory settings — check the Pruning threshold (default 365 days). A device whose last audit is older than the threshold is removed.
  • Admin Center > Site Settings > Logs > Audit log — find the audit task for the device and inspect the Errors column.
  • Admin Center > Site Settings > Logs > Security log — look for Service authentication failed events that would explain a silent audit failure.

Resolution:

  1. If the device appears on the segment's Ignore list, remove the entry and re-run a scan + audit on the segment.
  2. If the audit failed, fix the underlying cause:
    • Stale or rotated credentials — update the matching credential in Admin Center > Site Settings > Tasks and services > Audit services > <service> > Credentials.
    • Network reachability — confirm the required ports are open between the Audit Service host and the target.
    • Outdated Audit Service — check whether the service shows - outdated in its modal title; update the service binary on the host. Outdated services still run, but updating eliminates one variable.
  3. If the device's last audit predates the pruning threshold, the device record has been removed by pruning. Re-discover and re-audit the device on the segment, or extend the pruning threshold.
  4. If the audit succeeded but the device still does not appear, check whether the symptom matches "Two near-duplicate device rows" above — the device may have been ingested under a second identity.

Symptom: Device Change history tab is empty after attributes obviously changed

Likely cause: Site-level Change tracking is OFF, or the relevant category sub-attribute is not ticked, or retention has elapsed.

Where to verify:

  • Admin Center > Site Settings > Settings > Change tracking — confirm the master Change tracking enabled toggle.
  • The same page's Tracking categories list — confirm the relevant category (General / System / Security / User accounts / AWS assets / Azure assets / Custom audit fields) is expanded and the specific sub-attribute is ticked.
  • The same page's Retention period combobox — confirm the retention window covers the time of interest (6 months minimum, 5 years maximum).

Resolution:

  1. Turn the master Change tracking enabled toggle ON if it is OFF. The toggle is OFF by default on a new site.
  2. Expand the category that owns the attribute and tick its sub-attribute checkboxes. Examples:
    • Hardware change to network adapters → General > Network adapters.
    • Domain or computer-name change → System > Domain or System > Computer name.
    • Antivirus level change → Security > Antivirus level.
    • User account change → User accounts > Last logon, etc.
    • Custom audit field value change → Custom audit fields > <field>.
  3. Wait for the next audit cycle to run on the device. Change Events are recorded against new snapshots, so the first post-enable audit establishes the baseline; differences appear from the second audit onwards.
  4. If older records have disappeared, the configured retention period has elapsed (or Purge change history has been invoked). The records cannot be recovered; adjust the Retention period going forward.
  5. For software-related Change history (Software change history report and Software page change history tab), tick General > Required software, General > Forbidden software, and General > Regular software as appropriate.

Tips

  • A symptom that crosses multiple areas (missing device + duplicate rows + empty Change history) is usually upstream — start with the audit pipeline. Check Audit log for the device's task and Security log for authentication failures before chasing inventory-side settings.
  • Pack support tickets with both Audit IDs (from the device's Audit tab), the timestamp of the symptom, the segment name, the Audit Service or Agent name, and any relevant screenshot — see About Inventory for context on these identifiers.