Software and products
Normalization from executables and packages into products, the contains/exact/regex matching rules and their precedence, the review queue, and product merge — including why a merge without a rule does not stick.
Executables are not products
An estate does not run "Microsoft Teams". It runs Teams.exe, ms-teams.exe, Update.exe and a handful of helper processes, alongside a package registry entry with a different name again. Normalization is the layer that folds all of that into the single product a human — or a license agreement — actually reasons about.
Everything downstream depends on it. Utilization analytics, license consumption, redundancy analysis and product-level reports all count products, so the quality of your matching rules is the quality of your ITAM data.
Two kinds of software fact
| Fact | Where it comes from | How it resolves to a product |
|---|---|---|
| Running software | Process tracking — what actually executes and how heavily it is used | Matched against your rules. Anything unmatched still becomes a product, named after the executable, so the Products grid is always total and nothing is silently invisible. |
| Installed packages | The installed-software module — Windows registry, dpkg, rpm |
Matched against your rules only. An unmatched package gets no product link at all. |
Why packages behave differently: a fleet carries thousands of runtimes, drivers, language packs and update stubs. Giving each unmatched package its own product would bury the products that matter under noise. Running software gets a fallback product because there are far fewer distinct executables and each one is evidence of real use; packages must earn their product with a rule.
Matching rules
Rules live under Inventory → Policy and on each product's detail page. A rule maps a pattern to a product name, optionally setting the vendor and category, with a priority.
| Match type | Matches | Use it for |
|---|---|---|
| contains (default) | The pattern appears anywhere in the executable/package name or its path, case-insensitive. | The everyday case. teams catches Teams.exe and ms-teams.exe. A * in the pattern is decorative and stripped — this is substring matching, not globbing. |
| exact | The whole executable/package name, case-insensitive. The path is not considered. | Short or dangerous names. code as a contains rule would swallow half your estate; as exact it matches only code. |
| regex | A case-insensitive regular expression, tested against the name or the path. | Version-bearing or generational names — ^acrobat(reader)?\d*\.exe$ — and vendor directory conventions. |
Which rule wins
Rules are evaluated in a fixed order and the first match wins:
- Your organization's own rules, in ascending priority (a lower priority number is considered first);
- then the platform default rules shipped with VerOps, again in ascending priority.
Because your rules are always considered before the platform defaults, you can override any built-in grouping without needing it removed — write a rule with the grouping you want and it takes precedence.
An invalid regular expression is skipped with a warning rather than allowed to break anything: a bad pattern costs you that one rule, never the ingest of your fleet's data.
Authoring rules that hold up
- Start from the Products grid, not from theory. Sort by usage and fix the top of the list first; a long tail of one-off executables rarely repays the effort.
- Prefer exact for short names. Three- and four-letter patterns are the classic cause of a product that has quietly absorbed unrelated software.
- Check the path before widening a pattern. Both contains and regex see the path, so a vendor's install directory is often a safer discriminator than the executable name.
- Write the rule before merging. See the caveat below — this is the mistake people make most.
The review queue
The Review tab is where software that needs a human decision collects — newly seen products, and candidates that normalization could not confidently place. Working the queue is how the estate's quality improves over time; it is also where you will most often notice that a rule is needed.
Merging products
When you author a rule that folds one executable into another product, the source product usually already exists and already owns history — usage, licenses and violations keyed to it. Re-normalization moves the machines to the new product, but that history would be stranded on an empty husk. Merging is what moves it.
A merge is available from a product's detail page (Merge in the header) and moves everything the source owns into the target: usage across every time grain, licenses, policy violations and any remaining machines. The source product is then deleted. Vendor and category fill in from the source only where the target has none — a value you have already set is never overwritten.
How usage combines
Merging two products that ran on the same machine on the same day needs a rule for combining their numbers, and VerOps picks it per column based on what the column physically means:
| Measure | Combined by | Why |
|---|---|---|
| Active, focused, CPU-active and network-active time | Maximum | A product and its helper process run at the same time. Adding their wall-clock seconds would double-count the same minutes and could push a single day past 24 hours, corrupting every utilization percentage downstream. |
| Bytes sent/received and session counts | Sum | These are disjoint tallies of discrete events. Bytes the helper pushed are genuinely additional; one session each is two sessions. |
| Activity level | Maximum | It is a level, not a quantity. |
Automatic merging
When re-normalization empties a product into exactly one other product, VerOps merges it automatically. It deliberately refuses — logging and leaving the product alone — when the outcome would be a guess:
- the source's machines fanned out to two or more products, so no single product inherits the history;
- the source still has machines — it only shed a binary, it was not emptied;
- the source has licenses attached. A license is a contractual record with entitlements and position history hanging off it, and moving it to a heuristically chosen product could silently flip a compliance position. These are surfaced for a human instead.
Orphans
Products with no machines that still own history are flagged as orphaned — a warning pill on the row and an Orphaned filter chip that appears only when your organization has any. Each orphan shows what it still owns and an advisory suggested merge target. The suggestion is a hint for you to check, never something the merge acts on by itself.
The caveat that matters most: merging moves history, it does not create a grouping. If you merge two products without a matching rule tying them together, the next normalization pass will split the executables back into separate products again. The rule is what makes the grouping stick; the merge is what makes the history follow it. Write the rule first, then merge.
Every merge is recorded as a product merged event on the activity timeline, carrying a full summary of what moved.
Where products are used
Products are the unit of measurement for license consumption, for the utilization and adoption analytics described in the Scout overview, for redundancy and tool-sprawl analysis, and for the software_usage scheduled report.