Why GLPI inventory fills up with ignored and unmanaged devices
Discovered devices end up ignored or unmanaged when GLPI Inventory cannot match them to an asset record it should update, or when an administrator decides they are out of scope. A network discovery run or an agent check-in can surface home routers, personal phones, guest virtual machines and printers that belong to no one in your organization. GLPI Inventory holds these devices apart from your managed asset records so that unknown hardware does not silently change your inventory. The consequence is a growing pile of entries that nobody has classified, and that pile is where most inventory trust erodes. Someone must decide, for each device, whether it is a real asset, a device to quarantine, or noise to refuse.
A deliberate handling process becomes necessary as soon as the first broad discovery run completes across more than a few subnets. Without one, the ignored list turns into a dumping ground, real servers get buried among consumer devices, and security teams see unknown hosts that the asset records cannot explain. Plan the process before the backlog exists. Decide who triages unmanaged devices, what evidence justifies promoting a device into the asset inventory, and what happens to devices that should never be recorded. Confirm the exact list views, status names and actions in your installed GLPI Inventory plugin, because the behavior of unmanaged and ignored devices depends on the plugin and GLPI versions you run.
This page covers one capability: how unmatched devices are classified, quarantined and promoted into the asset inventory. It does not cover SNMP setup or import rule design, which have their own pages in this group. Version checks matter here. After a new GLPI version is detected, plugins are suspended in GLPI 11 and must be reactivated after major updates, so confirm the plugin is active and running the version you tested before you rely on its unmanaged device handling. Use the GLPI project site and the plugin release notes for your exact versions, and treat any procedure you copy from another instance as a starting point to verify in your own environment.
Options for handling each class of unmanaged device
This table compares the main ways to treat a discovered device that GLPI has not promoted to a managed asset, from leaving it ignored to converting it into a typed asset. Read each row against the device class it fits, then check the trade-off before writing the rule that applies it. The main takeaway is that most devices need a deliberate decision per class, not one global setting.
| Option | When it fits | Main trade-off | What to confirm first |
|---|---|---|---|
| Leave ignored | Devices you have not yet classified, such as a short-term discovery sweep of an unfamiliar subnet | Ignored items stay out of reports and ownership tracking, so they can persist unnoticed | How your team reviews the ignored list and how often |
| Keep as unmanaged | Personal or guest equipment that appears on the corporate network but must not be treated as company assets | Records remain visible, which helps detection, but they can clutter asset counts if not filtered | Which reports and dashboards exclude unmanaged records |
| Quarantine by network or entity | Home routers, consumer IoT and other devices that should be isolated from managed asset data while still being investigated | Requires a separate entity or group and ongoing review, and does not stop the device touching your network | Whether your network team can act on the same device list |
| Refuse through inventory rules | Devices matching a known pattern that should never create records, such as a specific printer model or a test range | Silently dropping data can hide a misclassified real device, so rules need periodic review | The matching criteria and who approves each refusal |
| Assign to a dedicated entity | Virtual machines, lab systems or a subsidiary whose records should stay separate from the main inventory | Keeps reporting clean, but access rules and entity-based permissions must be designed and maintained | How entity access and visibility are set for each team |
| Promote to a typed asset | Real company hardware such as switches, printers or servers that need ownership, contracts or lifecycle tracking | Requires classification effort and a named owner, and the asset must then follow standard lifecycle controls | The asset type definitions and the process that assigns owners |
Quarantining home routers, guest devices and short-lived VMs
Not every discovered device deserves a place in the asset inventory. Consumer routers, personal phones, lab VMs and cloud instances that are recreated often can inflate license counts and patch reports if they land in production records. The cards below cover which classes to isolate and how to use entities, rules and reporting to keep them out of the numbers that matter.
Consumer routers and home equipment
Home routers, access points and smart-home hubs often answer SNMP or show up in network discovery because they sit on a branch or remote-worker network. They rarely belong in the managed asset base, and their firmware is outside your patch process. Route discovered devices matching known consumer vendors or unknown MAC prefixes to a quarantine entity, then review the list before anything is promoted. Check that discovery ranges do not reach home networks at all. Keep these records out of the patch report entirely.
Personal phones and guest devices
Personal phones, tablets and visitor laptops can reach GLPI through guest Wi-Fi, a shared subnet or a user who installs the agent by mistake. Without a rule, each device creates an asset tied to whoever last logged in, which skews ownership reports and software counts. Set a rule that matches personal device types or agent tags that were never assigned by your deployment process, and send them to a quarantine entity. Confirm that agent installers are only distributed through managed channels.
Lab and test VMs
Developer sandboxes, proof-of-concept hosts and test clusters are often created by hand and deleted within days. If the hypervisor or agent registers them as production computers, license counts and vulnerability reports rise without any real change in your estate. Use a naming or tag convention on the hypervisor side, then match it in an import rule that places those VMs in a lab entity. Agree with the platform team who owns the lab entity and how long records stay there before cleanup.
Short-lived cloud and hypervisor VMs
Autoscaling groups, CI runners and VMs synced from a hypervisor or cloud account are destroyed and recreated constantly, so each rebuild can create a new asset. Matching on hostname or serial alone then leaves stale records behind. Map these sources to a dedicated entity and use a stable identifier, such as the cloud instance ID or the hypervisor UUID, in the matching criteria. Ask the team to confirm how long terminated instances should remain before automated purge, and whether that setting is available in your GLPI version.
Reporting that excludes quarantined records
Quarantine only works if licensing, patch and asset reports filter it out consistently. Build saved searches or dashboards that scope to production entities and show quarantined counts separately, so reviewers can see backlog without mixing it into totals. Review the report definitions after each rule change, since a new entity can silently fall outside an existing filter. Ask whether your auditors expect a documented exclusion rationale for ignored records.
Promotion review and rule maintenance
A quarantined device becomes an asset only after a named owner approves it, the entity and location are set, and the match is recorded so it is not re-quarantined on the next scan. Keep a short written procedure for this step and review the rule set on a fixed schedule, because stale matches cause real devices to be ignored. Confirm with your GLPI administrators who holds the right to change inventory rules and how changes are logged.
How to promote a real device into the asset inventory
This sequence takes a device that GLPI has discovered but parked as ignored or unmanaged and turns it into a correctly typed, correctly owned asset record. Each step ends with a check so the inventory reflects what is actually on your network.
Review ignored and unmanaged items
Open the list of discovered devices that GLPI has not linked to an asset, and sort it by discovery source, first seen date, IP range and detected type. Your inventory administrator does this work, and it is best done with the rule history open so you can see why each item was held back. Group items that look alike, such as a set of printers from one vendor or a block of addresses from one subnet, so they can be handled together. The step is complete when every item has been assigned to one of three buckets: likely managed, likely personal or temporary, or unknown and needing an owner.
Confirm ownership with the network owner
For each unknown item, ask the team that owns the network segment or hypervisor whether the device is theirs, and ask who is accountable for it. Network teams can usually match a MAC address or switch port to a patch record, and virtualization teams can confirm whether a virtual machine belongs to a known project. Record the answer and the name of the person who gave it in the device's comments or a linked ticket, so the decision can be audited later. The step is complete when each item is either confirmed as company-owned with a named owner, or marked as not company-owned and left for quarantine.
Apply matching rules or create the asset manually
For confirmed devices, first check whether an existing inventory rule would match them if the device were re-imported, and adjust the rule conditions only if the device is consistently missed. If no rule fits, create the asset manually with the correct asset type, manufacturer, model, serial number and location, and set the entity that owns it. Keep manual creation for the exceptions, because a rule that matches on stable identifiers is more durable than a one-off entry. The step is complete when a matching rule demonstrably assigns the device to the right type and entity on a test import, or when the manual asset record saves with all required fields.
Link the discovered record to the asset
Open the ignored or unmanaged discovered device and link it to the asset record, either from the device view or by reconciling it with the asset it represents. Confirm that the link carries the serial number or identifiers that will match the next inventory run, so the next agent or discovery report updates the asset rather than creating a duplicate. Check that the discovered record is no longer listed in the ignored or unmanaged queue. The step is complete when a fresh inventory update for that device attaches to the existing asset and no second record appears.
Verify the record appears in the expected entity with the right type
Open the asset from the entity you expected and check its type, manufacturer, model, status and location against the source you confirmed in the ownership step. Use a search filtered to the entity to confirm the asset is visible to the teams that should see it and hidden from the teams that should not. If the device is a virtual machine or a network device, confirm that its parent host or switch relationship is also correct. The step is complete when the asset appears under the correct entity with the correct type, and the people who will maintain it can find it without help.
Quarantine and document what stays out
For items that were not confirmed as company-owned, such as personal home routers, guest devices or short-lived test virtual machines, leave them unlinked and move them to a documented quarantine decision rather than deleting them. Record the reason, the date of the decision and the owner who requested the exclusion, and set a recurring review so the same device does not return to the queue unexamined. Ask your team to confirm how refused devices are handled by their configured rules before relying on that behavior. The step is complete when every excluded item has a recorded reason and a review point, and the ignored queue contains only items with a documented decision.
What happens to data when a device is promoted
Promotion changes which record owns future data, but it does not erase the discovered record. When an ignored or unmanaged device is promoted into the asset inventory, GLPI links the discovered entry to a real asset, and later agent runs or discovery tasks update that asset. The discovered record keeps its original detection history, while the asset becomes the record that users, reports and ticket links point to. Before you change any rule, confirm in your own instance how your GLPI version presents the link between the two records, which history entries move with the asset and which stay on the discovered item, and whether software and port data from earlier runs are copied, merged or left behind. The exact behavior depends on your GLPI and GLPI Inventory plugin versions, so check the current documentation for both rather than relying on general assumptions.
Later agent runs decide whether the match holds. Once a device is linked to an asset, the next inventory run from GLPI Agent is matched against existing records using the identifiers the rules evaluate, such as serial number, MAC address or hostname. If the identifiers change, for example after a network card swap or a reimage that changes the hostname, a new record can appear beside the promoted asset, and that duplicate may return to the ignored or unmanaged queue. Software lists usually refresh with each run, so old installed items may be replaced, while ports discovered by SNMP are typically tied to the network device record and can detach if the switch or printer is re-matched. Treat each of these as a question to answer in testing, not as a guarantee.
Test promotion on a copy of the instance before changing production rules. Restore a recent backup into a separate environment, then promote a handful of representative devices: a laptop that has been reimaged, a network printer, a virtual machine and one device you intend to quarantine. Run the agents or discovery tasks twice, once before and once after promotion, and compare the asset history, software counts, port lists and unmanaged queue each time. Record which rule order and identifiers produced each outcome, and only then apply the same changes to production. Keep the copy's configuration close to production, because rule order and entity assignment can change where a device lands.
Security and operational risks of unmanaged devices in GLPI
Ignored and unmanaged devices sit in a gray zone: they are seen on the network but not yet trusted or owned. The risks below share one root cause, which is that a record exists in GLPI without a clear decision about what it is, who answers for it and who can change it.
Unknown devices treated as trusted
A device that appears in discovery results is not the same as a device your organization has approved. If a rule promotes unknown hardware straight into the managed asset list, reports, patch scopes and access decisions may start treating it as company equipment. Check how your import rules handle devices that match no known serial, MAC address or hostname, and confirm that unknown devices land in the ignored or quarantine state until someone reviews them.
Stale records inflating counts
Discovery runs repeatedly, so the same router or VM can be recorded under several names or left behind after it was retired. Each stale entry distorts asset totals, license counts and audit evidence. Ask whether your team has a rule for when an unseen device is marked inactive, and who signs off before a record is deleted rather than kept for history.
Discovery credentials exposed
SNMP community strings or SNMPv3 credentials used for discovery are often entered by people who later leave the team, and they can be visible to anyone with broad configuration access. Review who can read or edit those credentials in GLPI, limit them to read-only SNMP access where possible, and rotate them when staff or scope changes.
Quarantined items with no owner
A quarantined device with no named owner is a decision that never gets made. Every item in the ignored or unmanaged list needs a responsible person or team, a reason it was held and a review date. Without that, the list grows, and nobody can say whether a home router, a test VM or a printer belongs in the inventory.
Broad access to the ignored list
Being able to restore, approve or delete ignored devices is a privileged action, because it changes what GLPI trusts. Review which profiles and entities can open the ignored list and promote items, and keep that group small. Log who changed each record, so an approval can be traced back to a person and a reason.
Bulk changes without a backup
Bulk promotions, deletions and rule replays can alter thousands of records in one run, and they are hard to undo by hand. Before any bulk change, take a database and file backup of your GLPI instance and confirm you can restore it. Test the restore on a copy, because a backup you have never restored is an assumption, not a safeguard.
Questions teams ask before handling unmanaged devices
What drives the cost of cleaning up ignored and unmanaged devices in GLPI?
The main cost drivers are the number of devices to review, how many rules you need to write, how many sites and network segments are involved, and how clear ownership of each device is. A few hundred devices with clear owners and one site is a very different job from thousands of devices spread across branches with unknown owners. Costs are mostly one-time for the initial review and rule design, then recurring as new unknown devices appear and someone has to classify them. Ask any partner for a quote that splits the initial review, rule work, quarantine procedure and handover, and says which items recur, such as a monthly review of new ignored devices.
How long does a first review of unmanaged devices take?
The first review depends mainly on how many devices GLPI is holding as ignored or unmanaged, how many of them can be identified from DHCP, DNS, switch port or directory records, and how many people must confirm ownership. Teams with good network documentation move faster because most devices can be matched quickly. Teams without it spend most of their time on owner confirmation, which is outside GLPI. Ask for the review timeline in the written scope, with a list of the dependencies that could stretch it, such as access to network records or owner responses.
What does our team need to provide before a partner can start?
Expect to provide read access to the GLPI instance and its inventory and discovery views, an export or list of ignored and unmanaged devices, and the network data that explains them. That usually means DHCP scopes, switch and access point records, DNS zones, and any directory data that identifies device owners. You also need a named contact who can approve quarantine actions and a process owner for ongoing classification. Confirm in the written scope exactly which accounts and data sets will be shared, and how they will be handled.
Can our own team handle unmanaged devices without a partner?
Yes, many teams can handle this internally if they already run GLPI and have someone who understands its rule engine and their network. The work is mostly ownership research, rule writing and a repeatable process, not difficult configuration. Internal teams usually struggle when they lack time to chase owners, have no network documentation, or have to balance it with regular GLPI administration. Compare your team's capacity against the review volume and the number of sites, and decide whether a fixed-scope engagement would hand over a working process you can run yourselves.
How is a fixed-scope engagement defined in writing?
A fixed-scope engagement defines the systems in scope, the sites and network segments covered, the deliverables, the acceptance criteria and the timeline before work starts. For this topic, that usually means naming which GLPI entities and discovery tasks are included, what quarantine and promotion rules will be written, which devices are excluded, and what the client receives at handover, such as a runbook and rule documentation. It should also state what the client must provide and how changes to scope are priced and approved. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
What risks should we check before quarantining devices?
The main risk is cutting off a device that matters, such as a printer, a building controller, a hypervisor management interface or a server that appears under an unexpected name. Before quarantine, confirm which devices are business critical, who owns them, and what network path they depend on. Test the quarantine action on a small set first, and keep a documented way to restore access. Ask your partner how they will record each action so that an auditor or your own team can trace why a device was moved.
Will ignored devices be safe to promote into the asset inventory?
Promotion is safe when the device identity is confirmed by an owner and by the discovery data, not only by a name or an IP address that may have been reassigned. Check serial numbers, MAC addresses and the source system before promoting a device into the asset inventory. Use a clear rule for which device types become managed assets and which stay in a separate category. Confirm with your GLPI administrators how promoted records will be reviewed and whether they will feed any compliance evidence you need to produce later.
How DeployOpen scopes and supports GLPI inventory clean-up
DeployOpen plans, implements, hardens, documents and supports self-hosted GLPI inside your own infrastructure, including the inventory clean-up described on this page. For ignored and unmanaged devices, that work usually covers the discovery and import rules that decide where agent and SNMP data lands, the entity and asset assignments that follow, the quarantine process for devices that should never join the asset inventory, and the written procedure your service desk uses to promote real devices. The work runs in the cloud accounts, data centers or air-gapped networks you already operate, so the GLPI database, agent traffic and configuration stay under your control.
Most engagements are fixed-scope: the scope, deliverables and timelines are agreed in writing before work starts. For this topic, a written scope should name the sites and network segments in play, the number of unmanaged device classes to triage, which rules will be created or changed, how the result will be tested, and who on your side approves each rule set. Ask the partner to show how the scope will be verified against your own inventory counts, and confirm which items are excluded, such as device types that need a separate workstream. A quote follows from that written scope, and DeployOpen does not publish a price list, so compare proposals on the same scope rather than on headline figures.
Clean-up rarely ends at handover. Rules drift as new agents, sites and GLPI versions arrive, and GLPI upgrades change how plugins behave, so ongoing support is available as a retainer. Confirm before signing what the retainer covers: rule reviews, responses to new unmanaged device types, plugin compatibility checks when you move between supported GLPI releases, and documentation updates. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. If your inventory records will support an external assessment, ask your independent auditor which evidence they expect and agree that expectation in the scope.
