Which GLPI agent inventory deployment fits your estate
If your team already feeds GLPI with hardware and software inventory and is weighing whether to add a separate OCS Inventory NG server, the GLPI Agent is the native path with fewer moving parts. Keeping OCS Inventory NG makes sense when an existing OCS deployment and its installed agents must stay in service, for example because changing agents across a large fleet is not practical on your timeline. The GLPI Agent collects hardware and software inventory and sends it directly to GLPI, and it runs on Windows, macOS and Linux, so a new estate with no legacy OCS footprint has little reason to add a second inventory server. Choose the agent path when you want one application to operate, back up and upgrade alongside GLPI itself.
Network discovery is a separate question. The GLPI Agent can perform network discovery and inventory, but for SNMP-based discovery of switches, printers and other devices that cannot run an agent, the GLPI documentation points to the separate GLPI Inventory plugin. Confirm in your own environment which device classes need SNMP coverage, which SNMP credentials and network segments the discovery jobs will reach, and whether the plugin version you plan to install matches your GLPI release line. Remember that since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates, so add that step to every GLPI upgrade plan.
Before choosing, confirm three things with your own data. First, count the machines already enrolled in OCS and check whether their agents can be redirected to GLPI or must stay on the OCS server for a transition period. Second, confirm the ocsinventoryng plugin's current compatibility with your GLPI version, since its repository is licensed under GPL-2.0 and maintenance status should be read from its own page rather than assumed. Third, decide who owns the agent deployment channel, such as your endpoint management tool, and whether it can push GLPI Agent packages. Ask your GLPI integrator for a written scope covering the migration path, the plugin set and the test plan before any production endpoints change.
How the GLPI Agent and OCS Inventory NG deployments differ
This table compares where inventory is collected, which servers you run, and how each option stays in step with GLPI. Read it as a checklist of server, licensing and upkeep differences, then confirm the OCS Inventory NG server requirements with its own documentation before you size anything. The main takeaway is that the GLPI Agent path runs fewer components, while the OCS path keeps a separate inventory server to maintain.
| Factor | GLPI Agent with GLPI Inventory plugin | OCS Inventory NG with ocsinventoryng plugin |
|---|---|---|
| Where inventory is collected | On each device by the GLPI Agent, which sends hardware and software data to GLPI | On each device by the OCS Inventory NG agent, which reports to the OCS server, which then feeds GLPI through the plugin |
| Servers to run | GLPI, with the GLPI Inventory plugin added for network discovery and SNMP | GLPI plus a separate OCS Inventory NG server, confirmed against the OCS Inventory NG documentation |
| Licensing | GLPI is GPL-3.0-or-later, and the GLPI Agent is part of the GLPI project | GLPI is GPL-3.0-or-later and the ocsinventoryng plugin repository is GPL-2.0, so confirm OCS Inventory NG server licensing separately |
| Version coupling with GLPI | Agent and GLPI are released by the same project, so upgrades follow the GLPI release line | Plugin, OCS server and GLPI versions must align, so confirm compatibility for each GLPI release before upgrading |
| Network discovery | Needs the separate GLPI Inventory plugin for network discovery and SNMP inventory | Confirm in the OCS Inventory NG documentation which discovery features the plugin exposes in GLPI |
| Agent platforms | Runs on Windows, macOS and Linux | Confirm supported agent platforms with the OCS Inventory NG documentation |
| Import and update automation | Agent reports arrive directly in GLPI, so no import script sits between them | The plugin includes a script that automates importing and updating machines, which you must schedule and monitor |
| Systems to patch and back up | GLPI and its database, plus the endpoints running the agent | GLPI, the OCS server and its database, plus the endpoints, so one more server joins your patch and backup scope |
What each inventory design runs in your infrastructure
Both designs end with inventory in GLPI, but they get there through different parts. One path uses agents that report straight to GLPI, the other keeps a separate OCS Inventory NG server in the middle. The cards below separate the components so you can see which ones your team would install, patch and monitor.
GLPI Agent on endpoints
The GLPI Agent runs on Windows, macOS and Linux endpoints and sends hardware and software inventory directly to GLPI. It is the successor of FusionInventory Agent, so teams moving off that agent will meet the same role under a new name. Check which operating systems and agent versions your fleet runs, and confirm who will push agent updates to endpoints over time.
Native reporting path to GLPI
In this design, GLPI itself is the only inventory store, so there is no second database to back up or reconcile. Inventory data lands in GLPI's asset records, which then feed ticketing, contracts and reporting. Confirm that your GLPI database and the files in its config directory are part of the backup plan, since both hold the inventory history.
GLPI Inventory plugin for discovery
The GLPI Inventory plugin is a separate component that adds network discovery and SNMP inventory, which the GLPI Agent does not cover on its own. It matters for switches, printers and other devices without an installed agent. Check which network segments the discovery scans will reach and how often they run, because both affect load and the accuracy of your asset list.
ocsinventoryng plugin and its script
The ocsinventoryng plugin synchronizes GLPI with an OCS Inventory NG server and replaced GLPI's native OCS mode from version 0.84. It includes a script that automates importing and updating machines, so the import job becomes a scheduled task you must monitor. Confirm that the plugin version you select supports your GLPI release, since plugin compatibility is a separate check from the GLPI core upgrade.
Separate OCS Inventory NG server
With the plugin route, the OCS Inventory NG server is a second application that agents report to before GLPI pulls the data in. Your team must run, patch, back up and secure that server alongside GLPI, which adds an extra attack surface and an extra failure point. Ask whether your security team already operates OCS Inventory NG and how its database and web tier would be hosted.
Synchronization risks to check
Any sync design can drift when the OCS server and GLPI disagree about a machine's identity, state or last report. The import script updates records on a schedule, so a failed run can leave stale assets that look current in reports. Before committing, ask how duplicate machines are merged, what logs show failed imports, and who gets alerted when the sync stops.
How the GLPI Agent reports and where network discovery fits
The GLPI Agent collects hardware and software inventory on each endpoint and sends it to GLPI, which is the native path this comparison starts from. The same agent family also handles package deployment and remote ESX inventory, so one installed component can cover several jobs. The agent runs on Windows, macOS and Linux, and it is the successor of FusionInventory Agent. Before you commit, confirm which of those jobs your team actually needs, how the agent is pushed and configured across your fleet, and which GLPI server address and credentials each endpoint will report to. Those decisions shape the rollout more than the agent binary itself.
Network discovery and SNMP inventory are not part of the agent's core inventory path. They need the separate GLPI Inventory plugin, so plan it as its own deployment step with its own install, activation and test window. Ask which switches, routers, printers and other SNMP devices must appear in GLPI, which community or credential settings they use, and who owns the scan schedule. If your comparison depends on the OCS Inventory NG path for network visibility, map those devices explicitly so no gap appears after cutover.
Upgrades change the plan. Since GLPI 11.0, plugins are suspended after GLPI detects a new version and must be reactivated after major updates. Every upgrade plan should therefore include a step to reactivate the GLPI Inventory plugin and any other plugin in use, followed by a test pass that confirms agents still report, discovery jobs still run and inventory records still update. Check the GLPI update documentation for the exact sequence, and make the test coverage part of the change record for each GLPI release you adopt.
Which inventory design fits each environment
When Windows, macOS and Linux endpoints are the bulk of the estate and no OCS Inventory NG server exists, the simpler starting point is usually the native GLPI Agent. It collects hardware and software inventory and sends it directly to GLPI, so there is no second inventory server to install, patch and back up. The agent runs on all three operating systems, which keeps the deployment model consistent across the fleet.
- One component to deploy: the agent reports straight into GLPI, so the inventory path has no intermediate database to size or maintain.
- Cross-platform coverage: the GLPI Agent documentation lists Windows, macOS and Linux, so you can standardize on one agent package.
- Discovery is separate: network discovery and SNMP inventory need the GLPI Inventory plugin, so plan for it only if network devices are in scope.
- Check your GLPI version: the native agent path is available since GLPI 10, so confirm the version in production before you design around it.
- Plan the deployment channel: decide how agents are pushed and updated, and who owns that process.
Before committing, confirm which GLPI version you run, how agents will be deployed, and that the GLPI server is reachable from every endpoint segment that must report.
When an organization already runs OCS Inventory NG with agents in production, replacing the agents is rarely the first move. The ocsinventoryng plugin keeps GLPI synchronized with the existing OCS server, and it includes a script that automates importing and updating machines. This lets the asset history continue while you decide whether a migration to the GLPI Agent is worth the effort.
- No agent swap on day one: the plugin keeps current OCS agents reporting while GLPI reads the results.
- Two servers to run: the OCS server and the GLPI instance both need patching, backups and capacity planning.
- Plugin version matters: the plugin is GPL-2.0 licensed, so confirm it supports the GLPI release you run, especially after a major GLPI upgrade.
- Agent compatibility: confirm which OCS agent versions report to your server and whether they match what your OCS release expects.
- Migration path: if you later move to the GLPI Agent, plan a period where both sources may report the same machines.
Confirm the plugin's support statement for your GLPI version, the OCS agent versions in use, and the host that runs the OCS server and its database.
Switches, routers, printers and other SNMP-managed equipment do not run an endpoint agent in the usual sense, so discovery is the deciding factor. GLPI handles ITIL processes and asset management natively, but network discovery and SNMP inventory need the separate GLPI Inventory plugin. The GLPI Agent can also perform network discovery and inventory, so the design question is which agent role runs against which network segment.
- Discovery needs its own plugin: the GLPI Inventory plugin is the component to evaluate for SNMP and network scans.
- Agent placement: an agent on a host inside each segment usually reaches devices that a central GLPI server cannot.
- Credentials and SNMP access: the team must manage SNMP community or credential settings for each device class.
- Scan scope and load: define which subnets are scanned and how often, since discovery traffic lands on production networks.
- Overlap with OCS: if OCS already covers some devices, decide which source owns each asset record.
Confirm the GLPI Inventory plugin version for your GLPI release, which subnets need coverage, and which host will run agents inside each segment.
In air-gapped networks or environments with strict change control, every added server is a separate approval, hardening task and evidence item. The GLPI Agent keeps the inventory path inside the GLPI instance, which means one application to approve rather than an extra inventory server. An OCS deployment adds a server, a database and its own update cycle, which is a larger approval if the network is closed.
- Fewer moving parts: the native agent path avoids a second inventory server inside the restricted zone.
- Offline installation: confirm how agent packages and plugin files will be transferred, since the controlled network may not reach public repositories.
- Supported platforms: GLPI requires PHP and MySQL or MariaDB at versions set in its documentation, so the host stack must be approved in advance.
- Update procedure: GLPI updates require backing up the database, files and config keys, then running a console update, which needs a maintenance window.
- Plugin suspension: since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates.
Before approval, confirm where each inventory component will sit, how packages and updates will reach the restricted network, and whether the plugins you need are approved for that zone.
How to move from an OCS server to GLPI Agent inventory
This sequence takes a team from an OCS Inventory NG server feeding GLPI through the ocsinventoryng plugin to GLPI Agent inventory, with checkpoints that show the data matches before the old server is retired.
Inventory the OCS-managed estate and plugin settings
The infrastructure owner exports the list of machines OCS currently reports, the OCS deployment packages and scheduled jobs, and the ocsinventoryng plugin configuration in GLPI, including sync intervals, import rules and any fields the plugin writes to assets. Record which machines are imported, which are updated, and which fields are edited by hand in GLPI so they are not lost during cutover. The output is a signed-off inventory baseline with a count per operating system and site, reconciled against the asset records already in GLPI. Confirm the plugin version against the GLPI release you run, since the plugin is maintained separately from GLPI itself.
Confirm the data-model differences before any change
Before touching production, the team reviews how the ocsinventoryng plugin maps OCS fields onto GLPI assets and how the GLPI Agent sends hardware and software data, and lists every field that differs in name, format or granularity. Use the vendor documentation for both the plugin and the GLPI Agent, and ask Teclib' or the plugin maintainers to confirm any mapping you cannot verify in your own environment. The output is a written field map that the security and asset owners approve. Do not retire anything until this map is accepted.
Pilot the GLPI Agent on a small endpoint group
The endpoint team deploys the GLPI Agent to a small, mixed group of machines that span the operating systems in use, while those machines keep reporting to OCS during the pilot. Agent configuration points at the GLPI server, and the team checks that the agent runs on Windows, macOS or Linux as each platform requires. The output is a set of pilot machines that report to GLPI with hardware and software records, which the team can match one by one against the OCS record for the same device.
Check that GLPI data matches expectations
The asset team compares each pilot device across both sources: serial number, model, operating system build, installed software, memory, disks and last-seen time. They note duplicates where the same device appears as both an OCS-imported asset and a new agent-reported asset, and decide how GLPI should merge them. The team also checks that the plugin's update script does not overwrite agent-reported values during the overlap period. The check closes when every pilot device has a documented, matching record or an agreed exception.
Widen the rollout in controlled waves
The team moves the rest of the estate to the GLPI Agent in waves, grouped by site, department or device type, with each wave held until its checks pass. For each wave, the team decides whether the OCS agent is removed or left in place, and it disables the ocsinventoryng import or update script for those machines so the two sources do not fight over the same asset. The output after each wave is a count of devices reporting to GLPI, a count still reporting to OCS, and a short list of exceptions with owners.
Run a documented fallback period on the OCS server
Once every wave has passed, the team keeps the OCS server running in read-only or limited mode for a fallback period it sets in advance and writes into the change record. During this period, the owners can compare reports from OCS and GLPI for any device that raises a question, and they can restore the plugin configuration if a gap appears. The team confirms that backups of the OCS database and the GLPI database both exist and that they can be restored in a test environment.
Retire the OCS server with sign-off
After the fallback period closes and no open exceptions remain, the team disables the ocsinventoryng plugin in GLPI, removes the remaining OCS agents and decommissions the OCS server. The GLPI record of the cutover, including the field map, wave results, exceptions and backup locations, is filed with the asset register. The step is complete when the asset owner and the security lead have signed the record and GLPI reports the expected device count without OCS as a source.
Questions teams ask before choosing an inventory design
Does the GLPI Agent alone cover hardware and software inventory?
Yes, for hardware and software inventory the GLPI Agent is the native path. It collects inventory on Windows, macOS and Linux and sends it to GLPI, and it has been part of GLPI since version 10. The agent also performs network discovery and remote ESX inventory, but network discovery and SNMP inventory depend on the separate GLPI Inventory plugin, so confirm which of those features your environment needs before you assume the agent alone is enough. Check that your endpoints can reach the GLPI server, and confirm the agent deployment method with your own endpoint management tooling.
Does network discovery need an extra component in GLPI?
Yes. Per the GLPI documentation, network discovery and SNMP inventory need the separate GLPI Inventory plugin, while the GLPI Agent handles endpoint inventory. Plan for the plugin as a second component to install, version against your GLPI release, and test against the switches, printers and other SNMP devices you need to see. Ask any implementation partner to list which discovery jobs will run, from which network segments, and with which credentials.
How does the ocsinventoryng plugin relate to GLPI versions and the old native OCS mode?
The ocsinventoryng plugin synchronizes GLPI with an OCS Inventory NG server. It replaced GLPI's native OCS mode from version 0.84, so the native mode is not the path for a current GLPI release. Because the plugin depends on both GLPI and the OCS server, check the plugin's compatibility with your exact GLPI version before any upgrade, and treat a GLPI major update as a point where the plugin must be re-validated. Your OCS Inventory NG server remains a separate system to patch, back up and monitor.
Which licenses apply to the GLPI Agent and the ocsinventoryng plugin?
GLPI is distributed under GPL-3.0, and the ocsinventoryng plugin repository is licensed under GPL-2.0. These are separate components with their own terms, so your legal team should review how the plugin, GLPI and any OCS Inventory NG server you run fit together for your distribution and internal use. Confirm the license of each OCS component you deploy with its own maintainer, because this page covers only the plugin repository. Licensing does not decide support: if you want a vendor to answer for the setup, ask who provides it under what written terms.
How much work does a migration take, and what drives it?
The effort depends on four drivers: the number of agents being moved, how much OCS history you need to keep, how much plugin configuration must be rebuilt, and how much testing you run before cutover. Agent count sets the rollout and verification work. Retained OCS data determines whether you import history or start fresh. Plugin configuration covers matching entities, inventory rules and update behavior. Testing covers a pilot group, duplicate detection and reports. No duration is given here; ask for a timeline built from these four drivers in your own environment.
Can our team run this inventory design internally?
A team with Linux and web server administration, database skills and endpoint deployment experience can often run the GLPI Agent path without outside help, and the plugin path adds a second server to maintain. Consider who will handle GLPI updates, since GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates. Also consider who owns backups of the database, files and the glpi.key and glpicrypt.key files. Assess the skills you already have against these tasks before deciding to build in house or buy help.
What should we ask for in a written scope from an implementation partner?
Ask for a written scope that names the inventory method for endpoints, whether network discovery is in or out, the plugin and GLPI versions targeted, and how OCS data will be handled. Request the list of agent deployment groups, the test plan and acceptance criteria, the rollback path to the existing OCS server, backup and documentation deliverables, and the handover to your team. Also ask what is excluded, how changes to scope are priced, and what support follows go-live. DeployOpen plans, implements and documents self-hosted platforms in the client's own infrastructure and typically works from a fixed scope agreed in writing before work starts.
How DeployOpen scopes and delivers GLPI inventory deployments
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For GLPI Agent inventory vs OCS Inventory NG plugin, we start from your current inventory sources and the data you need GLPI to hold, then agree the path in writing before any work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- The written scope lists which endpoints, operating systems and network segments the agent or OCS path will cover
- We record which inventory fields, software catalogs and discovery ranges GLPI must hold, and who approves them
- Ongoing support, upgrades and continuous testing are available as retainers after handover
How we build
- We install and configure GLPI in your environment, including the document root, PHP and database stack it requires
- We deploy the GLPI Agent or the ocsinventoryng plugin path that the written scope selects, with testing on sample machines first
- We configure LDAP authentication and inventory mapping so imported machines land in the correct entities
- We test update and synchronization behavior against the GLPI version you run, before any production rollout
How we hand over
- We document the agent deployment, plugin settings, scheduled tasks and the data flow from endpoints into GLPI
- We deliver backup procedures covering the database, files and the config directory with glpi.key and glpicrypt.key
- We provide an operator runbook for adding machines, reviewing failed inventories and running plugin reactivation after updates
- We walk your team through the handover so your staff can run the inventory process without us
How we support
- Retainers cover upgrades, patching and periodic testing of the inventory path after handover
- We review plugin compatibility before each GLPI major release, since plugins are suspended after a new version is detected
- Support scope, response expectations and included hours are set in the retainer agreement, not assumed
- Ask your DeployOpen contact to confirm the support tier and change-control process in writing before go-live
