Why normalizing software inventory with GLPI dictionaries matters before license reporting
Agents report the same product under many names, so license counts are wrong until those names are normalized. When GLPI Agent sends software inventory from a mixed fleet, one application can arrive as a full product name with a version, a shortened name, a localized title or a publisher spelled three different ways. Each variant lands as its own software record. A report that counts installed copies of a product then undercounts or splits the total across several entries, and a compliance review built on that report starts from wrong numbers. The problem tends to surface when someone runs a license report for the first time, not when the data arrives.
Software dictionaries are GLPI's mechanism for mapping those raw variants to one clean software name and publisher. In practice, a dictionary rule matches an incoming name or publisher and rewrites it to a canonical value before the record is stored or updated. Teams usually need them once the inventory covers more than a small pilot group, when they start consolidating software records, or when they plan to report on licenses or maintenance contracts. Because later reports, license assignments and software-based searches all depend on the normalized names, dictionaries are a prerequisite for clean software records rather than an optional cosmetic step.
Before you design any rules, confirm how the GLPI version you run applies dictionary rules to new inventory and to records already in the database, since the replay behavior and the fields each rule can match are version-specific. Check the rule configuration screens and the matching documentation for your release, then test a representative sample of messy names in a non-production instance. Record which product and publisher names you expect to see after normalization, because that list becomes the acceptance criteria for the rule set and the baseline for any license figures you later report.
What the software dictionary covers in GLPI
The software dictionary sits between what GLPI Agent reports and the software records your team reads in reports and license reviews. Each part below is one step in that chain, and each one needs a check in the GLPI version you run, because menu names, rule fields and replay behavior change between releases.
Software name rules
Dictionary rules that match the raw software name reported by the agent and rewrite it to a standard name. Rules match on text patterns, so one rule can merge many variants such as edition suffixes, language packs and version numbers embedded in the title. Check that the matching is case-sensitive or not in your version, and test each rule against a sample of real agent output before you enable it. Keep the original reported name visible so a bad rule can be traced.
Publisher rules
Rules that normalize the publisher field, which agents often report in several spellings for the same vendor, such as legal entity names and abbreviations. A consistent publisher value is what makes vendor-level license grouping and reporting work. Confirm which field the rule reads in your GLPI version and whether publisher rules run before or after name rules, because order changes the result.
Category and assignment actions
Dictionary actions that set a software category or mark an entry as a known product, so reports can group applications by function rather than by name. These actions define which software is treated as operating system, security tooling or business application in later reporting. Ask who owns the category list and whether it matches the taxonomy used in your license and audit records.
Agent-reported software fields
The fields GLPI Agent sends for each installed application, including the display name, publisher, version and install path. Dictionary rules act on these values only after the inventory is imported, so a field missing from the agent payload cannot be corrected by a rule. Check which fields your agent version sends from a test machine before you write rules that depend on them.
Software and version records
The software objects and version objects that result from normalization, linked to computers as installations. A rule that changes a name can create a new software object or merge existing ones, which changes counts and license links. Before you run any change on live data, record the current software counts and confirm how your version handles merged records and the installations attached to them.
Dictionary exports and replays
Rule sets exported as XML so they can be reviewed, versioned and loaded into another GLPI instance, and the replay action that applies rules to software already in the database. Replays rewrite existing records, so they need a database backup and a dry run on a copy first. Confirm in your version whether the export includes every rule type and whether replay is limited to new imports or covers the full history.
Dictionary rule options and when each fits
This table compares the main choices a team makes when writing software dictionary rules in GLPI: rewriting names, assigning publishers, scoping by entity, ordering rules and keeping original names. Read each row as a decision, then check the review effort it adds before you replay rules on existing data.
| Choice | When it fits | Trade-off | Review effort |
|---|---|---|---|
| Rewrite the software name | Many variants of one product, such as version suffixes or language packs, need one clean name for reporting and license counts | Reports become cleaner, but a wrong rewrite hides the original product name from anyone searching for it | Sample rule matches against real inventory and confirm each rewritten name with the team that owns licenses |
| Assign a publisher only | Names are acceptable but the publisher field is blank, inconsistent or spelled several ways | Leaves the product name untouched, so it is safer for audit, though grouping by product still needs manual cleanup | Low per rule, but check publisher spelling variants such as legal suffixes and abbreviations |
| Rewrite name and publisher together | A product appears under many unrelated labels and you want one canonical record for license matching | Fastest path to a clean catalog, but a broad condition can merge unrelated products | Highest, because each rule changes two fields and needs a sample review before replay |
| Scope rules by entity | Business units or customers use different software catalogs or naming conventions | Keeps local conventions intact, but global behavior must be duplicated or inherited deliberately | Moderate, since each entity owner may need to approve rules that affect their assets |
| Global rules for all entities | The naming problem is the same everywhere, such as one vendor's installer names | One rule set is easier to maintain, but a rule that suits one entity can distort another | Moderate to high, because reviewers must check results across every entity the rule touches |
| Rule order and priority | Specific patterns must run before general ones so that a broad rule does not overwrite a precise correction | Ordering is easy to get wrong, and a later rule can undo an earlier one without warning | High when rule sets grow, so document the intended order and test edge cases after each change |
| Keep the original name for audit | Assessors or license teams need to trace each normalized value back to what the agent reported | Preserves evidence, but the original value must be stored and reported somewhere, which adds data handling work | Low to set up, but confirm with the platform team how original values are kept and reviewed |
| Replace names without retaining originals | A simple catalog is enough and historical traceability is not a stated requirement | Simpler data, but rolling back a bad replay becomes difficult and audit questions are harder to answer | Moderate, because each replay must be verified before the change is accepted |
How to build and test software dictionary rules
This sequence turns a messy list of software names into tested dictionary rules that are safe to promote from a test instance to production. Each step ends with a check, so the team knows which names still need attention before anything changes in the live inventory.
Export a representative sample of raw software names
Pull a sample of software records from the production inventory into a spreadsheet or CSV, covering the raw name, publisher, version and the number of computers that report each entry. Include workstations, servers and at least one department with unusual software so the sample reflects real variation rather than the most common titles. Done when the export contains every distinct raw name in the sample, and the team has agreed on how large the sample is and who signed off on it.
Group variants by product and publisher
Sort the export by normalized name and publisher, then cluster spellings that refer to the same product, such as abbreviations, edition suffixes, language packs and publisher name changes. A product owner or licensing contact should review the clusters where the grouping is unclear, because two similar names can be different products with different license terms. Done when each cluster has one proposed canonical name, one publisher and a short list of the raw variants it covers.
Write candidate rules in a test instance
Build the software dictionary entries and rules in a non-production GLPI instance, using the clusters from the previous step as the source. Keep each rule narrow enough to match only its own cluster, and record which rule should win when two patterns overlap. Export the rule set to XML so it can be reviewed and reloaded later. Done when every cluster has a rule, the rule set is saved as an XML file, and the team can reload that file into an empty test instance and get the same rules.
Replay rules on the sample and review unmatched names
Run the dictionary rules against the sample data in the test instance, then list every software record that did not match any rule. Review the unmatched list first, since it shows gaps in the clusters, and then check for any record that matched a rule it should not have matched. Done when the unmatched list is short, every remaining entry has a recorded decision (add a rule, leave as is or ignore), and no wrong matches are left unresolved.
Check results against known license records
Compare the normalized counts for the products that have a license record, such as an entitlement list or a procurement register, with the number of installations the test instance now reports. Where the counts differ, determine whether the difference comes from a missing rule, a rule that merged two products, or a license record that is out of date. Confirm the counts with the owner of the license data, not only with the person who wrote the rules. Done when each licensed product has a count that the license owner accepts, with any remaining differences documented.
Promote the reviewed rules to production
Export the approved rule set from the test instance, import it into the production instance and record the rule set version and the date of the change in your change log. Replay the rules on the production inventory only after the import, and take a database backup beforehand so the change can be reverted. Done when the production import is complete, the replay results match the test results for the sample, and the backup location is recorded.
Confirm counts and schedule ongoing review
After promotion, repeat the count comparison for the licensed products and check the unmatched list on the full production inventory, not only the sample. Assign an owner for new software names that appear after rollout, since new agents will keep reporting unmatched variants. Done when the post-promotion counts match the expected results, the unmatched list has an owner and a review cadence, and the team has agreed on who approves future rule changes.
Replaying dictionary rules on existing software data
Dictionary rules only run when software arrives in GLPI, so a rule you add today does not correct the software records already in the database. Those records keep the name and publisher they were stored with until someone replays the rules against them. Replay is a deliberate action you start, and it treats existing entries as if they had just been imported. Plan it as a separate change with its own owner, not as a side effect of rule editing.
A broad rule can rename or merge far more items than its author intended. A pattern that matches a short word, or a publisher string shared by unrelated products, can change records across several entities at once, and merged software loses its original detail. Before any replay, take a full backup of the database, the files and the config directory, including glpi.key and glpicrypt.key, as the GLPI update documentation describes for upgrades. Restoring that backup is the only reliable way to undo a bad replay.
Test on a sample before the full run. Restore the backup to a non-production copy, narrow the rule to one publisher or product family, replay it there, and compare the software list, license links and installation counts with the original. Confirm with the vendor documentation for your exact version where the replay action sits in the menus and whether it can be limited to a subset of records. Only after the sample results match your expectations should you repeat the change on production, in a maintenance window, and record which rules were replayed.
How the approach differs by fleet size and ownership model
A single organization with one GLPI instance and a fleet that one IT team can review end to end usually needs one dictionary set, owned by the team that runs GLPI. Most of the work happens during the first cleanup, followed by periodic reviews after large software purchases or agent rollouts. XML export is most useful as a backup of the rule set and as a change record, since there is rarely a second instance to feed.
- Ownership: The GLPI administrator owns the rules, and the asset or service desk lead approves changes that affect reports used for finance or licensing.
- Change rate: Expect a cleanup burst at the start, then a short review at a fixed interval. Keep a simple log of who changed which rule and why.
- Replay scope: One replay over the existing inventory is often enough, followed by a check of unmatched names after each collection cycle.
- XML use: Export the rule set before major upgrades and store it with other configuration backups so it can be restored or compared later.
- Risk: Overly broad rules are the main hazard, because one error reaches every record. Test new rules on a sample before replaying them.
Confirm that one named person can explain every active rule and that the rule set is included in your backup routine.
When GLPI entities map to business units, subsidiaries or sites, local administrators often know their software better than the central team, but the central team carries the risk of conflicting rules. Ownership usually splits into a global rule set controlled by the central team and entity-scoped rules maintained by local administrators within agreed boundaries. Changes come from both sides, so the central team needs a way to see what local teams add.
- Global ownership: The central team owns the publisher and product names used for licensing and reporting across all entities.
- Local ownership: Local administrators own rules for regional software, language variants and local vendors, with changes reviewed before they go live.
- Change rhythm: Global rules change on a planned schedule tied to reporting cycles. Local rules change as new applications appear, so review them at a fixed interval.
- Conflict control: Agree on the order in which rules apply and document which rule wins when a global and a local rule match the same software.
- XML use: Share the global set as an XML file that local teams import as a starting point, and keep their additions in separate files so updates merge cleanly.
Confirm which entities can edit rules, who approves changes and how a conflicting local rule gets reported back to the central team.
A managed service provider running several customer instances needs one tested baseline that is copied into each customer environment and then adjusted for that customer's software and reporting needs. The provider owns the baseline and its change process, while each customer owns the exceptions that reflect their own estate. XML export and import makes this repeatable, because the same rule set can move between instances without being rebuilt by hand.
- Baseline ownership: The provider owns the core dictionary set, versioned and tested in a non-production instance before any customer receives it.
- Customer ownership: Each customer approves its own rules, especially publisher names that appear in its contracts or license records.
- Change cadence: Release baseline updates on a fixed schedule, with a changelog customers can read before import.
- XML sharing: Keep one exported baseline per release, import it into each customer instance, then reapply customer exceptions from a separate file.
- Data separation: Keep customer inventory data out of shared files. The XML should carry rules only, not device records or customer-identifying names.
Confirm how each customer's exceptions survive a baseline update and who signs off on imports into that customer's instance.
Questions teams ask before normalizing GLPI software data
What makes software dictionary cleanup take longer or cost more?
The main drivers are the number of raw name variants, the number of publishers that appear under different spellings, and how many entities, sites and instances share the data. A catalog with a few hundred distinct raw names that cluster around known products is far quicker to map than one where every discovered version string is unique. Ask for the export counts before any quote: distinct raw names, distinct publisher strings, number of GLPI instances and whether rule sets must be shared across them. Each of these changes the review workload more than the rule syntax does.
Who must review the normalized software results?
Two groups should sign off. The asset or license owner confirms that the canonical product name and publisher match how the organization buys and tracks licenses, and a security or operations engineer checks that grouping does not hide software that needs its own risk decision. Review is not a one-time task. New agents and new application releases keep producing unmapped names, so the owner needs a defined process for approving new dictionary entries after go-live. Agree on who approves changes before the rule build starts.
Can an internal team normalize GLPI software data without outside help?
Yes, a team with GLPI administration skills and time for review can do it alone, and the work is largely analytical. The effort is in reading the existing data, deciding canonical names, writing rules in the correct order and replaying them carefully. Teams that lack recent GLPI experience often spend the most time learning how the dictionary rule engine evaluates conditions. Be honest about available review time, because the decision backlog, not the rule editing, usually sets the schedule.
What does a partner scope for software dictionary work usually include?
A typical written scope covers an analysis of the current software data, a proposed canonical naming model, the dictionary rules themselves, a replay against existing records with a before and after comparison, and documentation of how new names are handled. If several GLPI instances must match, the scope should also state how rule sets are exported as XML and imported, and who maintains the master copy. Confirm whether training for the internal reviewers and a short handover are included, and whether ongoing rule maintenance is outside the fixed scope.
What should we ask for in a fixed-scope quote for this work?
Ask for a quote that lists deliverables by name, the inputs the provider needs from you, and the acceptance criteria for each deliverable. Good questions include: which data exports are required, how many review sessions are included, what the replay test environment looks like, whether changes after go-live are covered, and how XML rule sets are validated before import. Also ask which items are one-time work and which recur, such as periodic dictionary reviews. Quotes built from the written scope are easier to compare than hourly estimates.
Is replaying dictionary rules on existing data safe for production?
It is safe when it is planned and reversible. Take a database backup and a copy of the configuration before replay, run the rules against a copy of the data first, and compare the results with the expected canonical names. Replaying rules changes asset software records, so reports, license counts and any automation that reads those fields can shift. Confirm with the GLPI version you run how the rule engine applies to existing data before scheduling the replay, and communicate the change window to the teams that rely on software reports.
How do we share the same software rules between several GLPI instances?
Export the rule collection from the instance where the rules were approved, then import the XML file into the other instances and check the result. The XML file is the transport, but it does not replace a change process. Keep one master copy under version control, record which instance last imported which version, and test the import on a non-production instance first. Confirm the import and export steps for your GLPI version in the documentation, since rule identifiers and ordering must still be checked after import.
Security and operational considerations for dictionary changes
Dictionary rules decide how software names and publishers are normalized, and every normalized record feeds reports that people act on. The cards below cover who can change rules, how changes are recorded, how to test and back up before replay, and how the exported files are handled.
Limit who can edit rules
Dictionary rules change how thousands of software records are rewritten, so editing rights should sit with a small group of administrators rather than every GLPI user with configuration access. Map which GLPI profiles can open the software dictionary and assign those profiles deliberately. Check that helpdesk staff and read-only auditors cannot alter rules, and confirm the list of people with edit rights against your change owners before the first rule set goes live.
Trace every rule change
A rule that changes a publisher name can alter license matching across many computers without anyone noticing. Record who changed each rule, when, and why, in a ticket or change log outside GLPI if GLPI's own history does not give you that detail. Confirm with your GLPI version and configuration whether rule modifications are logged and retained for the period your audit requires, and test that you can reconstruct a past state from those records.
Back up before replaying rules
Replaying dictionary rules on existing data rewrites stored software names, so a bad replay is hard to undo by hand. Take a database backup and export the current rule set before every replay, and keep the pre-change copy until the results are checked. Restore a backup into a test instance once to confirm the procedure works before you depend on it. Schedule replays outside inventory import windows so the two processes do not compete for the same records.
Protect license reporting from bad rules
A rule that merges two products or maps a publisher wrongly can make an installed product look unlicensed, or hide a product that needs a license. Review rule output on a sample of known installations, and compare software counts and license totals before and after each change. Agree with the license owner which reports must be reconciled after a replay, and ask who signs off when a rule changes a count that feeds a purchasing decision.
Store XML exports under control
Exported XML rule sets are portable copies of your normalization logic, so they should be stored with the same access controls as other configuration backups. Keep them in a restricted repository with versioning, not in shared drives or email attachments. Confirm who can import a file into another instance, and record which version of each file was imported where, so that a rule set in one environment can be traced back to its source.
Review internal names before sharing
Rule sets often contain internal product codes, business unit names, server naming hints, or comments that reveal how your organization is structured. Read every rule and comment in an exported file before sending it to a partner, another team, or a public repository. Remove or replace internal references, and check that the file does not expose hostnames, customer names, or contract identifiers that were typed into rule conditions.
How DeployOpen scopes and delivers software normalization for GLPI
DeployOpen plans, implements, customizes, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and software dictionary work follows the same method. We start from a sample of the software names your GLPI instance actually holds, agree the rules and replay plan in writing, and hand over rule sets, test evidence and runbooks your team can maintain.
How we scope
- Export and review a representative sample of software names, publishers and versions from your GLPI instance
- Agree in writing which normalization rules, dictionary entries and entity scopes are in and out
- Define how existing software records are replayed, and which records are protected from automatic change
- Confirm which GLPI version, plugins and agent sources feed the software data before work starts
How we build
- Draft dictionary rules for names, publishers and versions, with the order and conditions documented
- Test rules on a copy of the database before any replay touches production records
- Review rule hits and misses with your asset owners and record each exception as a decision
- Export the approved rule set as XML and verify that it imports cleanly into a second instance
How we hand over
- Deliver the final rule set, a rule register and the replay log from the test and production runs
- Document how to add rules, reorder them and review new unmatched software names after agent updates
- Walk through the procedure with the administrators who will maintain the dictionaries after the engagement
- Record what was changed, what was deliberately left alone and who approved each decision
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial handover
- Re-check dictionary rules when GLPI is upgraded, since rule behavior and plugin compatibility must be confirmed
- Review unmatched software periodically so new titles and publisher variants do not drift back into the inventory
- Scope any further rule work, such as new asset categories or integrations, as a separate written engagement
