GLPI Agent inventory deployment guide

Why GLPI Agent inventory deployment takes more planning than installing an agent

If you need accurate asset data in GLPI from laptops, servers, network devices and virtual hosts without typing it in by hand, the hard part is not the installer. GLPI Agent collects hardware and software inventory from endpoints, performs network discovery and SNMP inventory, runs remote inventory against VMware ESX hosts and handles package deployment tasks. It is the successor of FusionInventory Agent and runs on Windows, macOS and Linux, according to the GLPI Agent documentation. Each of those functions depends on decisions about credentials, scope and scheduling that you need to make before the first agent reports.

Start with credentials, because each target type needs its own. Discovery and SNMP inventory need SNMP community or version 3 settings that match each switch, router, printer and firewall you want to read. Remote ESX inventory needs an account on the hypervisor with read access sufficient for the data you want. Endpoint agents report under the local system context and need the GLPI server URL and any required trust settings. Ask the network and virtualization teams to confirm which accounts they will provide, who owns them, and how rotation will be handled. Credentials that expire silently will show up later as empty records, not as errors on your dashboard.

Scan scope and schedules deserve the same discipline. A discovery task pointed at a large address range can generate heavy traffic and noisy results, while overlapping inventory and discovery windows can load the GLPI server and the same devices at once. Define which subnets are in scope, which are excluded, and which windows are allowed for each task type. Then check the schedule against your change calendar and backup windows. Illustrative example: a discovery sweep of a /16 range scheduled during the nightly backup job will compete for the same network path and may leave both jobs incomplete. Confirm the scan targets and timing with the teams that own the network before you enable anything broadly.

Duplicates and reconciliation are where most inventory projects lose trust. The same laptop can appear once from the endpoint agent and again from a network scan, and a virtual machine can be reported by both the hypervisor and its own agent. Decide which source is authoritative for each asset type, what identifiers you will match on (serial number, MAC address, hostname or UUID), and who resolves conflicts. Also plan for agents that report successfully but are never linked to an existing asset or owner record. Those devices look healthy in the agent logs and still leave your asset register wrong. Ask for a reconciliation report from a pilot group before you expand the rollout.

This section does not cover the GLPI platform setup, SSO, upgrades or the migration from FusionInventory, because those have their own pages. Treat them as prerequisites that must be settled first, and keep your focus here on the agent-side decisions above. Before you approve a fixed-scope plan, ask the implementation partner to write down the credential inventory, the scan scope and schedule per site, the duplicate-matching rules, and the acceptance check for reconciled assets. Those written decisions are what separate a deployment that stays accurate after go-live from one that needs cleanup every quarter.

Which GLPI Agent functions and GLPI settings you will configure

GLPI Agent runs several functions on endpoints and network segments, and each one reports into GLPI, where the team defines what gets collected and which tasks run. The cards below cover the agent components on each platform and the GLPI objects that receive their data and drive their work, so you can decide what to enable before the rollout starts.

GLPI Agent on Windows, macOS and Linux

The agent is installed on each managed endpoint and is the successor of FusionInventory Agent. Your team must decide which operating systems and fleet segments get the agent first, how packages are delivered (for example through your software deployment tool), and which service account the agent runs under. Confirm supported OS versions and installer options against the GLPI Agent documentation for your agent version.

Inventory tasks and collection scope

Inventory tasks gather hardware and software data from each endpoint and send it to GLPI. The team decides what is collected, how often it runs, and whether laptops that are often offline are covered by a different schedule. Check the available collection modules and default run intervals in the GLPI Agent documentation for your version before you set them in GLPI.

Network discovery and SNMP inventory

Network discovery finds devices on defined IP ranges, and SNMP inventory queries network equipment such as printers, switches and access points. The team must decide which subnets are in scope, which SNMP credentials and versions are used, and who approves scanning of production segments. Confirm the protocol versions and required ports with the GLPI Agent documentation and your network team.

Remote ESX inventory

Remote ESX inventory lets an agent query VMware ESX hosts over the network without installing software on each host. The team must decide which agent or proxy performs the query, which read-only account it uses, and how host credentials are stored and rotated. Confirm the supported ESX versions and the connection requirements in the GLPI Agent documentation.

Package deployment tasks

Package deployment lets the agent install or run approved packages on endpoints when a task is triggered from GLPI. The team must decide which packages are allowed, who can create and approve deployment tasks, and how failed installs are reported and retried. Treat this function as a change with its own approval step, and confirm the supported package formats per platform in the agent documentation.

GLPI reports, tasks and access controls

On the GLPI side, agent reports land in asset records, and tasks are defined and assigned to agents or groups of agents. The team must decide how devices are matched to existing assets, which entity receives each report, and which profiles may view or change tasks. Confirm the task and inventory settings in the GLPI documentation for your GLPI version before you go live.

Decisions to make before the first agent is installed

This table compares the main choices for a GLPI Agent rollout, with the conditions where each option fits and the admin time, network load or support effort it creates. Read each row as a decision to settle before the first agent reports, because most of them are costly to change once inventory data and credentials are in place.

Decision	When the option fits	Operational cost
Agent installation and updates: manual, software distribution tool or GLPI package deployment	Manual suits a small pilot or a lab. A software distribution tool fits fleets already managed by endpoint tooling. GLPI package deployment fits teams that want agent tasks run from GLPI itself.	Manual costs the most admin time per machine and drifts over time. A distribution tool adds a dependency to test and maintain. Package deployment adds GLPI task configuration and needs the remote hosts reachable from the server or agents.
Ownership of discovery scope and credentials	Assign one owner for network ranges, SNMP community or account details, and ESX accounts before scanning starts. Split ownership fits when network and server teams each control their own segments.	Unclear ownership delays scans and leads to shared credentials that are hard to rotate. Expect recurring effort each time a range or credential changes, and confirm the approval path with your security team.
Network discovery from one central agent or several	One central agent fits a single flat segment with modest host counts. Several agents fit segmented networks, remote sites or firewalls that block scanning from a distant host.	A central agent concentrates scan traffic and needs firewall rules for every target. Several agents spread load and rules but add servers to patch, monitor and document.
Inventory frequency per fleet	Set shorter intervals for servers and assets that change often, and longer intervals for stable desktops or network devices. Group hosts into fleets so each one has its own schedule.	Frequent runs increase network traffic and GLPI database writes. Infrequent runs leave stale records. Review the schedule after the first full cycle and confirm the server capacity you plan to use.
ESX inventory credentials scope	Use a dedicated read-only account limited to the hosts or clusters being inventoried. Broad administrative accounts fit only where the hypervisor team has approved them in writing.	Scoped accounts take extra setup for each vCenter or host group. Broad accounts are quick to set up but create audit findings and make credential rotation harder. Confirm the required privileges with your hypervisor documentation.
Agent counts and GLPI Network subscription tiers	Consider a subscription when you need vendor support, level 3 support or marketplace plugins. Staying on the free GPL-3.0 build fits teams that can run their own support.	The self-hosted tiers are priced by month with a stated agent limit, so the count of agents drives the tier. Confirm current prices and limits with Teclib' before you size the rollout, and count agents across all sites, not only the pilot group.

How to build an inventory rollout in the right order

This sequence moves GLPI Agent from a tested pilot to production without creating duplicate assets or unplanned network scans. Each step closes with a visible check in GLPI, so the team confirms the foundation before the next layer depends on it.

Confirm the GLPI server and its prerequisites
The platform team confirms that the GLPI server meets the PHP, database and web server requirements for the version in use, and that the document root points to GLPI's public directory with URL rewriting enabled. Check the requirements in the installation documentation for your release, because the README on the main branch and the GLPI 11.0 docs list different minimums (for example, MariaDB 10.11 in the README and 10.6 in the 11.0 docs). The step closes when an administrator can sign in, GLPI reports no blocking errors on its requirements check, and current database and configuration backups exist.
Define entities and the asset types in scope
The service owner and the GLPI administrator decide which entities will own inventoried assets, which asset types (computers, monitors, network equipment, printers and so on) will receive data, and which groups will hold the test and production machines. Entity structure determines where each agent report lands, so it is settled before any agent is installed. Ask the business which sites, subsidiaries or cost centers need separate ownership. The step closes when the entity tree and asset type list are approved in writing and an administrator can create a test computer in the correct entity by hand.
Pilot agent installs on one machine per platform
The engineering team installs GLPI Agent on one Windows, one macOS and one Linux machine, then points each agent at the GLPI server. Choose reference machines whose installed software is documented, so the results can be compared. The step closes when each agent report appears on the correct asset in the correct entity, and the software list on the GLPI record matches the reference machine. Resolve any mismatch here, before scheduling begins, because every later wave repeats the same configuration.
Set inventory schedules for the pilot
Configure the agent's inventory frequency for the pilot group only, and keep the settings identical across the three platforms. Confirm how the agent checks in on a schedule and how it behaves on machines that stay offline for long periods, using the GLPI Agent documentation for your agent version. The step closes when a second scheduled report arrives from each pilot machine and updates the existing asset instead of creating a new one. Record the chosen interval so that later waves use the same setting.
Configure discovery scope and credentials in a test group
For network discovery and SNMP inventory, the network team defines the IP ranges and SNMP credential set the test group may scan. For remote ESX inventory, the team creates a limited service account on the hypervisor. Agree the scan scope with the network owner in writing, because discovery traffic on production networks needs approval. Store credentials only in the secret store your policy names. The step closes when a discovered device appears linked to an existing record instead of a new duplicate.
Review duplicates and merge rules
The GLPI administrator reviews the rules that decide when an incoming agent report or discovered device updates an existing asset and when it creates a new one. Test the rules against the pilot machines, the discovered devices from the test group and any assets imported earlier from spreadsheets or another tool. Agree in advance who may approve merges, and record each rule change. The step closes when a repeat run of the pilot creates no new duplicate assets and every merge decision is logged.
Expand to production in waves
The platform team rolls the agent out in groups it sizes itself, starting with a low-risk group for each operating system, and widens the scope only after the previous wave is reviewed. Each wave repeats the schedule, discovery and duplicate checks from the earlier steps, and the team tracks machines that have not reported. The step closes when every machine in a wave has a current report on the correct asset and each unresolved exception has a named owner. Pause the rollout if the exception count grows faster than the team can resolve it.
Set deployment tasks last
Create package deployment tasks only after inventory is stable, because inventory confirms the target population and the before and after state of each machine. Build the first task on the pilot group using packages the team has tested, and confirm the outcome in the next inventory report. The step closes when the pilot deployment completes and the software list shows the expected version on every pilot machine. Production deployment tasks follow the same wave pattern used for the agent rollout.

What drives the effort and cost of an agent rollout

This table compares the drivers that change how much work a GLPI Agent rollout takes and where partner work typically falls. Read the middle column for what makes effort grow, the second-to-last column for a practical way to reduce it, and the last column for where scoping, pilot, rollout waves, tuning and handover fit. The main takeaway is that a clean pilot, standard credential sets and staged waves reduce most of these cost drivers.

Driver	Why it adds effort or cost	How to keep it down	Where partner work usually sits
Endpoint count and OS mix	Each Windows, macOS and Linux family needs its own packaging, test and deployment path, multiplying validation work.	Pilot one group per OS, then roll out by OS family in waves.	Scoping and pilot per OS family, then rollout waves.
Network segments and SNMP device types	Each subnet needs a discovery scope, and each SNMP device type needs its own credential check.	Use standard SNMP credential sets and one discovery job per segment.	Scoping and tuning, since discovery results need review.
ESX hosts and vCenter layout	Remote ESX inventory depends on vCenter and host credentials, and scope grows with each cluster added.	Group hosts by cluster, use one read-only account per vCenter, and start with one cluster.	Pilot on one cluster, then waves per cluster.
Software inventory depth	Detailed software and process collection increases database volume, review time and report noise.	Agree a software inventory standard first and enable extra detail only where a use case needs it.	Scoping of required fields, then tuning after first reports.
Package deployment use cases	Each deployment task needs packaging, testing, targeting, a rollback plan and its own approval step.	Limit the first release to one or two packages with a tested rollback path.	Rollout waves and tuning for each package type.
Change windows and user communication	Each window, notice period and user message adds coordination across IT and business teams.	Use one standard window for every wave and one notice template.	Wave planning and notice drafts, with the client holding final approval.
Existing FusionInventory footprint	Agents already reporting to GLPI must be found, moved or retired without creating duplicate assets.	Inventory current agents first, then replace them in the pilot group before any wave.	Migration scoping and handover of the agent inventory list.
Entities and approval paths	Each GLPI entity and approver group adds mapping rules, sign-off steps and reports to check.	Map entities to one rule set and agree approvers before the pilot starts.	Scoping of entity rules and handover of the approval runbook.

How the rollout changes by environment and fleet type

In a mostly managed Windows estate, the usual path is to use the directory and existing software distribution tooling to push the GLPI Agent installer to devices in controlled batches, then let each agent report on its own schedule. Because devices are domain-joined and predictable, the rollout can be grouped by organizational unit, and the first batch is typically a pilot group that covers laptops, desktops and servers with different roles.

The settings that usually change in this context are:

Inventory schedule: set a staggered run interval so thousands of agents do not report at the same moment against the GLPI server.
Target server address: point agents at the GLPI server or its agent endpoint using a single configuration applied through policy.
Network discovery: decide per subnet whether discovery runs from a scanning agent, and limit scan scope to ranges you own.
Software and hardware fields: confirm which inventory modules are enabled so reports match what your asset team needs.

Verification focuses on coverage. Compare the directory's computer objects against assets that have checked in, look for devices that report but have stale timestamps, and confirm that the agent version is consistent across the fleet. Confirm the exact configuration keys and the Windows installer options in the GLPI Agent documentation for your version before writing deployment scripts.

How to protect credentials, scan scope and agent traffic

GLPI Agent inventory deployment touches credentials, network ranges and the channel back to GLPI, so each of these is a separate control to design and test. The cards below cover what to protect, who may change it and what to remove when devices leave the estate.

Store SNMP community strings securely

SNMP community strings grant read access to device data, and many switches and printers keep them in plain configuration. Decide where GLPI stores each community string, who can view it in the interface and which devices each string is valid for. Check that discovery tasks reference the stored secret rather than typing it into task descriptions, and confirm with your network team whether SNMPv3 credentials are an option for devices that support them.

Apply least privilege to ESX credentials

Remote ESX inventory needs an account on each VMware host or vCenter it queries. Ask the virtualization team to create a read-only account dedicated to GLPI Agent rather than reusing an administrator login. Record which hosts each account can reach, and confirm the role grants only the inventory read access your tasks need.

Limit discovery to approved subnets

Network discovery sends probes across every range it is given, so an overly broad range can trigger intrusion alerts or reach systems outside the inventory scope. Maintain a written list of approved subnets with an owner for each, and configure discovery tasks only against that list. Review the list after network changes, since a range added later can silently widen what discovery reaches.

Control who creates and edits deployment tasks

Deployment tasks can run inventory, discovery and package installation on large numbers of machines, so editing one is a privileged change. Restrict task creation and modification to a small named group through GLPI profiles, and keep read-only access for service desk staff. Confirm that changes are traceable to a person, and review the list of users with these rights at each access review.

Encrypt agent-to-GLPI traffic with TLS

Agents send inventory and receive task instructions over HTTP or HTTPS to the GLPI web server, so the transport must be encrypted and the certificate must be trusted by every endpoint. Plan the certificate source, its renewal process and the chain that Windows, macOS and Linux agents will validate. Verify that the GLPI web server, not only a load balancer, serves TLS if your design requires end-to-end encryption. Server-level setup is covered in the security hardening topic.

Back up GLPI keys and configuration

GLPI stores encrypted values, including credentials entered for discovery and ESX tasks, and decrypting them depends on the glpi.key and glpicrypt.key files together with the database. A backup of the database alone cannot restore these secrets. Include the configuration directory and both key files in every backup, store copies in a protected location with restricted access, and test a restore on a separate server. Server-level protection of these files is covered in the security hardening topic.

Remove credentials when devices retire

Credentials for retired hypervisors, switches and printers often remain in GLPI and in discovery tasks long after the hardware is gone. Add a step to the decommissioning process that removes the device from discovery targets, deletes or rotates the credential it used and updates the asset record. Ask your team to produce a periodic report of credentials not referenced by any active task.

How to test that agent inventory is accurate and fails safely

Acceptance for an agent rollout should answer two questions before the fleet is widened: does GLPI show the machines that really exist, and do failures stay visible instead of silently creating wrong records. Start with one pilot group of machines whose identity you already know. Build a reference list from your asset register, directory and hypervisor console, with hostname, serial number, operating system and owner for each machine. Then compare that list against what GLPI holds after the agent has run on its normal schedule. Record every mismatch as missing, extra or wrong in a field, because each category points to a different cause: a scheduling or connectivity problem, an out-of-scope agent, or a mapping error in the inventory data.

Next, test the data paths that most often produce false confidence. Confirm that a machine reporting under two names, for example after a rename or a reimage, is either merged into one asset or flagged for review in GLPI rather than counted twice. For network discovery, pick a few SNMP devices whose addresses and community or credential settings you know, and check that they appear with the expected type and model. Add a device in a range you have excluded from scope and confirm it is not discovered. For remote ESX inventory, compare the hosts GLPI reports with the hosts listed in vCenter, including the count, names and versions. Confirm that deployment tasks, which the agent can run as packages, target only the pilot machines by checking the task's target list in GLPI against the reference list before any task is run.

Failure tests show whether the rollout degrades safely. Stop the agent service on a few pilot machines and confirm that GLPI shows the last successful inventory date, that the asset is not deleted, and that a stale-data indicator or report flags it. Replace the credential used for SNMP or ESX discovery with an expired value and confirm that the failure appears in the discovery task log and does not produce empty assets that look valid. Block the agent's outbound port to the GLPI server with a host firewall rule and confirm that the agent retries and that the machine shows as not reporting, not as healthy. Finally, have one machine report twice, for example by running the agent manually and on schedule, and confirm that GLPI keeps one asset record.

Record acceptance evidence for each test in a single register: the test ID, the pilot machine or device, the action taken, the expected result in GLPI, the observed result, the screenshot or export of the asset or task, the log extract and the tester and date. Include the reference list version and the GLPI version under test, so the results can be repeated after an upgrade. Ask the implementation partner, or your own team, to state in the written scope which tests are included, who signs off each result, and what happens when a test fails. Confirm with your GLPI Agent and GLPI versions' release documentation how each failure is reported in your build, because log messages and status fields vary between releases.

Questions teams ask before deploying GLPI Agent

Can our own IT team run a GLPI Agent rollout without a partner?

Often yes, if your team already manages software distribution and has someone who can own the GLPI server and agent configuration. GLPI Agent is installed on Windows, macOS and Linux endpoints and reports to GLPI, so the technical steps are familiar to most endpoint teams. The harder parts are usually organizational: agreeing which asset fields matter, scheduling installs across business units, and testing inventory accuracy before you trust it for licensing or audits. A partner is most useful when you want the rollout scoped in writing with defined phases, acceptance checks and a handover. Compare the effort of your own team against a written scope before deciding.

What drives the cost and duration of a GLPI Agent deployment?

The main drivers are fleet size and diversity, how many operating systems and network segments are involved, how much discovery and SNMP inventory you add beyond endpoints, and how many change windows and approvals the rollout must pass through. Package deployment tasks and remote ESX inventory add scope if you use them. Costs split into one-time work (scoping, configuration, packaging, pilot, rollout and documentation) and recurring work (agent updates, inventory schedule changes, and admin time). Ask any provider for a written scope that lists phases, assumptions about your fleet, and the acceptance criteria that close each phase. Duration follows directly from that scope.

What do we need to provide before a GLPI Agent rollout starts?

Plan to provide named asset owners for each business unit, network access from discovery and inventory hosts to the GLPI server, and a credential approach for remote inventory and discovery targets. You also need agreed change windows, a test group of machines for the pilot, and a decision on who approves packages before they reach production. For SNMP and ESX inventory, confirm which devices and hypervisors are in scope and which credentials your security policy permits. Write these dependencies into the scope so that delays are visible early. If a provider cannot list what they need from you, treat that as a gap in the proposal.

Do we have to migrate FusionInventory data before deploying GLPI Agent?

Not always, but you must decide how existing inventory data is handled. GLPI Agent is the successor of FusionInventory Agent, so teams that already run FusionInventory need a plan for the agents already on endpoints, for the inventory history in GLPI, and for duplicate assets that appear when old and new agents report the same machine. Options include replacing agents in waves, keeping historical records as they are, or cleaning and mapping records before cutover. The migration approach is covered in a separate topic. For this rollout, confirm the sequence with your provider and test duplicate handling on the pilot group before the full fleet moves.

Does GLPI licensing depend on how many agents we deploy?

It depends on how you run GLPI. GLPI is distributed under the GNU General Public License version 3, so self-hosting the open-source platform does not require a subscription. Teclib' offers GLPI Network subscriptions. Public cloud and private cloud plans are priced per user per month, with a 25-user minimum for private cloud. Self-hosted subscriptions are tiered and the lowest tier includes a set number of agents and assets. Check the current subscription terms on the GLPI Network subscriptions page and confirm with Teclib' whether your agent count, asset count or user count affects your tier. Ask your provider to state which plan assumption the quote relies on.

What should we ask a partner for in a GLPI Agent quote?

Ask for a written, fixed scope that lists the operating systems, device types and network segments covered, the inventory schedules and discovery ranges you will use, and the package deployment tasks in scope. The quote should name each phase, the deliverables (configuration, packaging, pilot report, runbook and handover) and the acceptance criteria. Ask who pays for which component, including Teclib' subscription fees, hosting, and any third-party tooling, and which items recur after go-live. Confirm what support is included after the rollout and how changes to the scope are priced. Compare quotes on this basis rather than on headline totals.

What breaks most often during a GLPI Agent rollout?

The most common problems are network paths that block the agent from reaching the GLPI server, expired or incorrect credentials for remote and SNMP targets, and inventory schedules that overload the server during a large first run. Duplicate assets, especially after a FusionInventory transition, and endpoints with inconsistent naming or tagging also cause trouble for reports. Package deployment tasks fail when the target machines lack the right permissions or when change windows are missed. Check each of these in the pilot group, review the GLPI Agent documentation for your target platforms, and confirm agent version compatibility with your GLPI version before scheduling the full rollout.

What to monitor, document and maintain after the agents are live

Once GLPI Agent is reporting across Windows, macOS and Linux, the work shifts from rollout to keeping the inventory trustworthy. The first routine check is whether agents are still reporting. An endpoint that stops sending inventory for an extended period may be powered off, offline, blocked by a firewall change, or running an agent that no longer starts. Decide in advance how long a silent device is tolerated before someone investigates, and who receives that alert. Confirm with your monitoring team which GLPI views or reports you will use for this, and whether the alert feeds your ticketing queue or your endpoint management console.

Discovery results need periodic review as well. Network discovery and SNMP inventory will surface devices that nobody registered, including printers, network equipment, and hosts that appeared on subnets you did not expect. Review new and unexpected entries on a fixed cadence, assign each to an owner, and decide whether it is authorized, should be removed from the scan scope, or needs a security investigation. Unreviewed discovery output quietly becomes a second, unofficial asset register, which defeats the purpose of the deployment.

Agent versions and inventory settings should move through the same change process as your other endpoint software. That means a written change record, a test group, a rollback path and an approval from the owner of the affected fleet. Inventory schedules, discovery scopes, remote ESX inventory targets and package deployment tasks all change what the platform collects and where it connects, so treat them as configuration changes rather than convenience edits. Before changing inventory configuration in GLPI, take a database and file backup, and record the current settings so you can restore them if a change behaves unexpectedly.

Credentials used for SNMP, remote ESX inventory and deployment tasks need an inventory of their own. Record which account each integration uses, what it can access, who owns it, where it is stored, and when it expires or must rotate. Stale or shared credentials are a common reason discovery or remote inventory silently stops working. Ask your identity and infrastructure teams to confirm the rotation policy for each account before the first scheduled rotation, so that a password change does not break inventory collection without notice.

Document the operating rules so that someone other than the original implementers can run them. The record should cover inventory schedules, discovery and SNMP scopes, remote ESX targets, credential owners and rotation dates, and the rules that govern each package deployment task, including targets, approvals and rollback. Keep this document under change control and review it after every material change. GLPI server upgrades and encryption key handling are covered on the GLPI upgrades page, so this record should reference those procedures rather than duplicate them.

How DeployOpen scopes, builds and hands over a GLPI Agent rollout

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, and GLPI Agent rollouts follow the same method. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we scope

Inventory the Windows, macOS and Linux fleets, and confirm which operating system versions must be covered.
Define which data each agent collects, including hardware, software, network discovery, SNMP and remote ESX inventory.
Agree the written scope, deliverables and timeline for the GLPI server and the agent rollout before work starts.

How we build

Confirm the GLPI server prerequisites, including PHP and MariaDB or MySQL versions, against the installation documentation for your chosen release.
Build inventory schedules, discovery tasks and package deployment tasks, then test each on a pilot group of machines.
Plan the FusionInventory cutover, if present, so agents report once and old agents are removed without losing asset history.

How we hand over

Document the agent configuration, server targets, schedules and the deployment method used for each operating system.
Walk your administrators through checking agent check-ins, failed inventory runs and assets that stop reporting.
Provide a runbook covering agent upgrades, configuration changes and the steps for adding new device groups.

How we support

Support after go-live is available as a retainer, scoped in writing with your team.
Upgrades to the agent and the GLPI server are planned and tested on a staging copy before production changes.
Confirm with us during scoping which support hours, response expectations and escalation paths your team needs.

GLPI Agent inventory deployment