A manually maintained application spreadsheet is obsolete as soon as the next installer runs.
Spreadsheets are useful for analysis and sign-off. They are weak as the primary collection system because they depend on manual discovery, naming consistency, and repeated reconciliation.
01
Understand why spreadsheet inventories fail
Unknown installs remain unknown
The register changes only when someone notices and records an application.
Names are inconsistent
Publisher, product, architecture, channel, and version may appear under multiple names.
User and device installs are mixed
A per-user application can exist on one profile while a device-level package affects every user.
Current state replaces change evidence
Manual edits often erase when an application appeared, changed, or was removed.
02
Define the inventory schema before collecting data
| Field | Purpose |
|---|---|
| Device and user identifiers | Shows where and for whom the software is installed |
| Product name and version | Supports supportability, vulnerability, and troubleshooting decisions |
| Publisher and product identifier | Helps normalise naming and identify ownership |
| Architecture and install scope | Separates 32-bit, 64-bit, device, and per-user records |
| Install path and package source | Supports investigation and removal planning |
| First detected and last confirmed | Provides evidence age and change history |
| Approval and business owner | Connects technical presence to an authorised purpose |
| Lifecycle status | Approved, under review, prohibited, exception, or removal pending |
Microsoft's current Intune application inventory can collect richer properties such as install location, date, size, architecture, uninstall command, product identifiers, languages, and install scope. It also uses full and delta synchronisation. Those fields illustrate the level of detail needed for useful inventory, regardless of the collection product.
03
Collect from the endpoint, not from memory
Use more than one source because Windows software can be installed through different mechanisms:
- System and per-user uninstall registry records.
- Microsoft Store and package-manager records.
- Managed application deployment records.
- Portable applications and executable discovery where justified.
- Browser extensions, drivers, services, and firmware as separate inventory classes.
Preserve the collection method. An application absent from one registry key is not proof that it is absent from the device.
04
Normalise without destroying source evidence
Create a canonical product record, but retain the raw detected value. For example, several records may map to one application family while representing different channels, architectures, or components.
The raw endpoint record supports investigation. The canonical record supports reporting and governance. Replacing the raw name with a cleaned label loses evidence.
Normalisation keys can include publisher, product code, package family, executable signature, install path, and version pattern. Human review remains necessary for ambiguous software.
05
Track additions, removals, and version changes
A useful inventory is a timeline, not a periodic dump. Generate events when:
- A new application appears.
- An application version changes.
- A publisher or signature changes unexpectedly.
- An application is removed.
- An install scope changes.
- An approved application becomes unsupported.
- A previously removed application returns.
Prioritise material changes. A component update from an approved vendor may be routine. A new remote-access tool, browser extension, unsigned package, or end-of-life application may require immediate review.
06
Assign ownership and review exceptions
Discover
Collect the installed record and source metadata.
Classify
Map it to an application family and risk or business category.
Identify an owner
Record the responsible business or technical function.
Decide
Approve, restrict, remove, or create a time-bound exception.
Verify
Confirm the expected application state on the endpoint.
Review
Reassess versions, support status, and continued business need.
07
Where Snipe RMM fits
Snipe RMM currently emphasises endpoint inventory and evidence in the device record. The product direction is to make application evidence useful for support, audit review, and change detection rather than presenting an isolated list. Approval workflows and richer software governance should be treated as product requirements until implemented and verified.
Sources
Authoritative references
- Microsoft Learn, App inventory for Windows devices in IntuneDocuments collection sources, richer metadata, install scope, and delta synchronisation.
- NIST Cybersecurity Framework 2.0Includes inventory outcomes for managed software, services, and systems.
- Australian Signals Directorate, Guidelines for system managementCalls for regularly verified software registers with versions and patch histories.