How GLPI software package deployment works and when to use it
If your team already keeps asset and software records in GLPI, the next question is whether GLPI can also install and update applications on the machines it inventories. It can. GLPI Agent includes package deployment alongside its hardware and software inventory and network discovery, so the same agent that reports what is installed can also act on instructions from the GLPI server. The work is organized around three objects. A deployment package defines what to install or remove, the files or commands involved and the conditions under which it applies. A *target group* is a set of computers chosen either by a saved query that refreshes as inventory changes (dynamic) or by a fixed list of members (static). A *scheduled task* connects the two: it says which package goes to which group, when, and how the agent should behave if a machine is offline or a step fails.
This approach fits best when the estate is already well covered by GLPI Inventory, the audience is mostly Windows, macOS or Linux workstations and servers, and the team wants fewer tools to maintain. It is a weaker fit when you need deep patch compliance reporting, complex staged rings, mobile device management or software distribution to hosts that cannot run the agent. In those cases a dedicated endpoint management product may still be the better home for that work, and GLPI can remain the system of record for what was installed. Before you rely on it, confirm which GLPI Inventory plugin release and GLPI Agent version your organization runs, because deployment behavior and supported package types depend on both, and check the matching compatibility notes in the agent documentation. Test the full path on a small pilot group first, including a failed install and a machine that was offline during the run, since those cases decide whether the task is safe to scale.
Which targeting method fits which rollout
This table compares the three ways to choose which computers receive a GLPI software deployment package: static groups, dynamic groups and direct assignment. Read each column as a membership model, then check the row on rollout fit to match it to a pilot or a fleet-wide update. The main takeaway is that every method depends on inventory data, so the membership list must be checked against real inventory before any task runs.
| Factor | Static group | Dynamic group | Direct assignment |
|---|---|---|---|
| How membership is set | An administrator adds computers by hand or by import and they stay until someone changes them | Membership is computed from criteria such as operating system, software present or tags held in inventory | An administrator selects individual computers for the package or task one at a time |
| What changes when inventory changes | Nothing changes automatically, so a renamed, reimaged or replaced computer keeps its old membership | Membership shifts as the inventory data shifts, so a computer can enter or leave the target without any edit | Nothing changes automatically, and a computer that is replaced must be selected again |
| Risk of deploying to the wrong machines | Stale lists can include retired devices or miss new ones, so the target drifts from intent over time | A broad or mistyped criterion can match far more machines than planned, and inventory gaps can silently exclude some | Low risk of overreach, but a manual selection error or a missed machine is easy to make at scale |
| Best fit for a pilot | Suited to a small, named test set that the team agrees on and reviews before each run | Less suited, because the pilot population can change between runs unless the criteria are tightly defined | Well suited to a handful of known computers chosen by the owner of the change |
| Best fit for a fleet-wide update | Workable but laborious, since the list must be maintained across every site | Well suited when the criteria reliably describe the fleet and the update targets an agreed version gap | Impractical for large fleets, but useful for a final exception to a broader rollout |
| Check before a task runs | Compare the list with a current inventory export and remove retired or duplicate entries | Preview the members the criteria return and confirm the count matches the expected population | Confirm each selected computer is online, enrolled and reporting the expected inventory |
| Review after the run | Confirm the group still reflects the intended population for the next wave | Check which computers were added or removed since the last run and why | Record which computers were targeted and reconcile against deployment results |
Setting up a package deployment from build to verified install
This sequence takes a software package from a tested build through a pilot, a defined target group and a scheduled task, then confirms in GLPI that the install happened. Each step closes with a check you can record, so a failed deployment is found on the pilot rather than across the fleet.
Confirm agent and plugin versions
The platform or infrastructure team checks that the GLPI Agent version on the target machines and the GLPI Inventory plugin on the GLPI server are compatible with the deployment features you plan to use. Compare the agent release notes and the plugin documentation for the versions you run, and record both in your change ticket. Confirm the GLPI version itself against the GLPI release history, since the GLPI 11 and 12 lines change how plugins are handled after upgrades. Done when you hold a written version matrix for the server, plugin and agents, and every pilot machine reports one of the approved agent versions.
Prepare and test the package on a pilot
The packaging engineer builds the installer or script with silent install and uninstall switches, then runs it on one or two pilot machines that match your standard build. Test install, repeat install, uninstall and a failure case such as a missing prerequisite, and capture the exit codes for each. Keep the pilot machines in a separate group so their results do not mix with production data. Done when the package installs silently, exits with the code you expected, and the application appears in the local software list of each pilot machine.
Create the deployment package record
An administrator creates the deployment package in GLPI Inventory, entering the package name, version, the file or download location, and the action commands for install and uninstall. Attach the detection rule that tells GLPI how to recognize the software after install, so later inventory runs can confirm the result. Store the package in a location reachable from the agents, or from a mirror server at remote sites. Done when the package record saves without errors and a manual test download from one pilot machine completes with a matching checksum.
Define the target group
The administrator builds the group of computers that should receive the package. A dynamic group fills itself from rules such as operating system, entity or existing software, and suits fleets that change often. A static group holds a fixed list and suits pilots or controlled waves. Review the membership count and check a sample of names against your asset inventory before the task is scheduled, since a loose rule can pull in machines that should not change. Done when the group lists the pilot machines alone during testing, and the production membership matches the list the change owner approved.
Schedule the deployment task
The administrator creates a deployment task that links the package to the target group and sets the schedule, the number of concurrent deployments and the behavior on failure. Run the task against the pilot group first, then extend it to production in waves once the pilot results are clean. Confirm that the task is linked to the right package version and that the notification settings reach the people who will review results. Done when the pilot task shows as scheduled, the agents pick it up at their next contact with the server, and the task log begins to record activity for the pilot machines.
Check the task log for each machine
The administrator reviews the task log entries for each targeted computer, looking for the final status and the exit code returned by the package commands. A success status alone is not enough, because the installer may have reported success while the application did not install. Investigate any machine that is pending, offline or reported with a non-zero code, and keep those machines in the group until they are resolved. Done when every pilot machine shows a completed status with the expected exit code, and the failures have a recorded cause and next action.
Verify the install in the next inventory run
After the agents run their next inventory, the administrator confirms that the installed software appears on each pilot computer under the expected name and version, and that the detection rule matched. This check uses the inventory data itself, so it shows what GLPI can see rather than what the task reported. Record the result against the package record and move the group to the next wave only when the software is present on every pilot machine. Done when the inventory shows the software with the correct version on all pilot machines, and the package record links to that evidence.
Mirror servers for remote sites compared with direct downloads
On a fast local network, most machines can fetch packages directly from the central location named in the deployment task, so a local mirror is often optional. Bandwidth is rarely the limiting factor, which makes simplicity the main argument: fewer components to patch, monitor and keep current, and one source of truth for every package version. The GLPI Agent documentation describes how agents retrieve deployment content, and that is the first read before deciding.
- Source: agents download from the central location over the local network, with no intermediate host in the path.
- Mirror contents: if you add a local copy anyway, it must hold exactly the package files the tasks reference, with matching checksums.
- Bandwidth: large installers still load the shared link during a fleet-wide rollout, so stagger rollout waves across the day.
- Failure handling: a central outage stops every deployment at once, so retry behavior and task reporting matter more than cache layout.
Confirm in the documentation for your GLPI and GLPI Agent versions which download locations the agent contacts, how it validates package integrity and how failed downloads are reported back to the server.
Branch links with limited capacity can be saturated when many machines pull the same large installer at once. A local mirror lets each package cross the WAN link once, after which the branch installs from its own network. The mirror then becomes a sync target that must track the central catalog, and its health becomes part of every branch deployment.
- Source: agents at the branch fetch from a server inside the branch network, which obtains packages from the central side.
- Sync scope: the mirror must hold every package version targeted to that branch, including the previous version needed for rollback, and should drop packages no longer assigned.
- Sync timing: schedule copies outside business hours so they do not compete with user traffic on the same link.
- Failure handling: if the WAN link fails, a mirror that already holds a package keeps branch installs working, while direct downloads stop entirely.
- Operations: the mirror is another host to patch, back up and monitor, and its disk must hold the full set of staged packages.
Confirm how your version registers a mirror, which sync mechanism it uses, how often content refreshes and how the server shows a failed or stale sync.
At some sites, firewall policy prevents the central GLPI server from opening connections into the local network. In that case the design must work in one direction: a mirror inside the site pulls content outbound, and agents on local machines fetch only from that mirror. Agents never need to reach the central server for package content, which keeps the inbound rule set unchanged.
- Source: the on-site mirror pulls packages over an outbound connection the site firewall permits, while agents read only from the local mirror.
- Mirror contents: the same package set as a branch mirror, plus any content needed for offline installs, verified against checksums before it is staged.
- Connection details: confirm which side initiates the connection, which ports and proxy settings apply and whether TLS certificates are validated end to end.
- Failure handling: a broken outbound path stops refreshes but not installs of packages already staged, so alert on the time of the last successful sync.
- Access control: a mirror stores software and any credentials it uses, so limit it to the packages and accounts the site needs.
Confirm with your security team and the documentation for your version which direction traffic flows, how the mirror authenticates to the central side and whether agents can be pointed at the local mirror without new inbound rules.
What drives the effort and cost of a deployment project
The largest cost in a GLPI software deployment project is rarely the GLPI setup itself. It is the packaging and silent-install testing for each application, because every package must be built, tested without user interaction, and proven to install and remove cleanly on each Windows build in your fleet. Each application adds its own install switches, dependencies, prerequisites and uninstall logic, so effort scales with the number of applications and the number of distinct OS and architecture combinations they must support. Ask any partner to list the applications in scope, the target operating systems and the test matrix that will be used to sign off each package.
The size and diversity of the endpoint fleet, the number of sites and the number of mirror servers drive the recurring and rollout cost. A fleet with many hardware models, user profiles or network segments needs more pilot coverage and more verification of dynamic group membership, while each remote site with a mirror server adds a server to configure, patch and monitor. Change approval also takes time that does not appear in any technical task: a deployment that must pass a change board, a maintenance window or a security review will be scheduled around those gates. Confirm who approves each change, how long that process takes in your organization, and whether a pilot ring must be signed off before wider rollout.
Separate one-time work from recurring work when reading a quote. One-time work includes initial setup of the deployment configuration, packaging and testing each application, building the test matrix, and designing the pilot ring and its exit criteria. Recurring work includes packaging each new application version, retiring packages that are no longer used, reviewing failed deployment tasks and keeping mirror servers current. A quote should list each package with its test scope, the number of pilot rings, the sites and mirrors covered, the change process included and the recurring tasks with their frequency. Any effort figure should come from the written scope of the work, not from a general estimate.
Why software deployments stall, fail or hit the wrong machines
Most failed GLPI software deployments trace back to a few predictable causes: packages that behave differently on real hardware, groups that pull in the wrong devices, schedules that disrupt users, stale mirrors, and agents that never report back. Each card below names the symptom, the likely cause and the check that catches the problem before it reaches the fleet.
Silent installs that prompt on real machines
A package that installs without interaction on a test machine can stop at a license prompt, a reboot request or a missing dependency on other devices. The symptom is a deployment task marked as started but never completed, or a user reporting a dialog they cannot dismiss. The likely cause is that the test image already had the runtime, the admin rights and the answers the installer expected. Before wide rollout, run the package on a clean machine from each common build, using the same account context the deployment uses, and confirm the exit code and the inventory entry afterward.
Dynamic groups matching unexpected devices
A dynamic group built on a broad software or operating system criterion can pull in servers, kiosks or lab machines that were never meant to receive a change. The symptom is a deployment appearing on devices the change owner did not list. The likely cause is a criterion that matches on a name fragment, a legacy agent field or an entity that contains more machines than expected. Preview the group membership before saving the deployment, compare the count and sample names with an expected list, and exclude device types that need separate change control.
Tasks running during working hours
A deployment scheduled without a maintenance window can restart machines, saturate a branch link or interrupt a user in the middle of a call. The symptom is help desk tickets from users reporting restarts or slow applications at the same time each day. The likely cause is a task scheduled for its default timing, or one set to run on every agent contact rather than in an agreed window. Set the window with the business owners of each site, test the timing with a small pilot group in the same time zone, and confirm that retries will not fire outside the window.
Mirrors falling out of date
A mirror server at a remote site holds a copy of packages that stops matching the central catalog after a new version is published. The symptom is agents at that site downloading an older installer, failing checksum checks or reporting a version that differs from the central record. The likely cause is that the synchronization job failed quietly, or that the mirror was not in the list of sources when the package was updated. Track the last successful sync for each mirror, compare file checksums for a sample package after each release, and alert when a mirror falls behind the central catalog.
Agents offline or on old versions
Devices that have not contacted the server or still run an old agent will not receive new deployment tasks, and the gap is easy to miss in a large fleet. The symptom is a deployment that reports success for most devices while a segment of the fleet shows no result at all. The likely cause is a stale agent, a blocked outbound path, a certificate mismatch after a server change, or a laptop that rarely connects. Before each rollout, list devices by last contact date and agent version, and decide in advance whether unreachable devices are excluded, retried or handled by a separate process.
Results not checked against inventory
A task that reports success does not prove the software is present, at the right version, on the intended device. The symptom is a compliance report or a helpdesk request that contradicts the deployment status. The likely cause is that the team relied on task status rather than the next inventory run. Build a verification step that waits for the agent to send a fresh inventory after the install window, then compares the installed software and version against the target list. Keep the mismatched devices in a follow-up queue instead of closing the task.
Securing packages, tasks and agent traffic during rollout
The first control to settle is who may create packages and tasks, because a deployment task can push software to every computer in a group. Decide which GLPI profiles can define deployment packages, build dynamic and static groups, and schedule tasks, and keep those rights separate from the people who approve what gets deployed. Review the profile and entity assignments for these rights before the first pilot, and confirm how the GLPI version you run restricts them. Check whether a package can be edited after it has been approved for distribution, and whether that change triggers a new approval.
Next, verify each package source before it reaches a device. Every package should record where its files came from, a checksum for each file, and the person who approved it. Store installers in a controlled location that only the deployment service account can write to, and never let a task point at an arbitrary download URL. For mirror servers at remote sites, apply the same rule to the mirror: restrict who can upload to it, keep it on a network segment managed by your team, and confirm how the mirror is synchronized and whether its contents are checked against the approved checksums. Ask your partner or the GLPI documentation for the exact mirror and checksum options available in your release.
Install scripts often need credentials, and those must never be written into a package definition, a command line visible in the GLPI interface, or a task log. Use a service account with the narrowest rights the installer needs, store its secret in a vault your organization already operates, and inject it at run time only where the installer requires it. Logging deserves the same care: confirm which deployment events GLPI records (package created, changed, approved, task started, task finished, and per-computer results), how long those records are kept, and who can read them. Keep audit logs for deployment activity in a location that administrators of GLPI cannot quietly edit. Agent traffic between computers and GLPI, including certificate validation and SSL-only enforcement, is covered in the separate topic on securing GLPI Agent communication, so confirm those controls there before enabling deployment at scale.
Limits to confirm before you commit to package deployment
Package deployment depends on what the plugin version, the agent platform matrix and your network layout will actually do. Each item below is a question to put to the vendor or to test in a pilot group before you commit a fleet to automated installs.
Supported package types and install methods
Confirm which installer formats, script types and silent install switches your installed GLPI Inventory plugin version can build and run. Ask whether packages can be built from existing MSI, EXE, PKG and shell or script sources, and whether command arguments, pre-checks and file copies are all supported. Test one package of each type you rely on against a pilot group before you write the rest of the catalog.
Maximum package size and transfer behavior
Ask what the largest supported package size is, how files are split or chunked, and whether a failed transfer resumes or restarts from zero. Large installers over slow WAN links are the most common reason a rollout stalls, so measure transfer time on your slowest site. Also confirm how the agent verifies file integrity after download.
Mirror server coverage for every site
Confirm that the mirror server role can be placed at each remote site you need, including sites with no local Windows server, and how endpoints discover their nearest mirror. Check how mirrors are kept in sync with the central instance and what happens when a mirror is offline. Plan the site list and mirror placement before groups are built, because gaps appear only when a remote office is missing a mirror.
Rollback for failed installs
Ask whether the platform can run an uninstall or a previous package version when an install fails, and whether that rollback is automatic or manual. Find out how a failed task is reported back to GLPI, and whether a partial install is detected and marked. Test a deliberately failing package in the pilot so you know what state an endpoint is left in and who must clean it up.
Reboot handling during installs
Confirm whether a package can declare that it needs a restart, whether the agent defers the reboot to a user-friendly window, and whether a deployment can force a restart at a set time. Ask how the task status is recorded while an endpoint waits for a reboot. Reboot behavior has to be agreed with the service desk and the change process before any mass deployment starts.
Agent platform matrix for your endpoints
Confirm that the GLPI Agent version you deploy runs on each Windows, macOS and Linux version in your fleet, and that the package deployment feature is available on each of those platforms, not only on Windows. Check which features differ by operating system before you build dynamic groups that mix platforms. Record the exact versions in your pilot results so the support matrix matches what you tested.
Questions teams ask before deploying software with GLPI
Can our own team run software deployments from GLPI without outside help?
Yes, many teams do, provided someone owns the packages, the test process and the GLPI Inventory configuration over time. The work is mostly repeatable: build a package, test it on a small set of machines, target it to a group, schedule it and check the results. What decides whether an internal team can carry it is not the GLPI console itself but whether they have time for packaging, a lab of representative machines and a clear rollback method. Teams that already run scripted installs and a change calendar usually find the transition smaller than teams starting from manual installs. Ask a partner to show you the same steps on your own estimate of packages before deciding.
How long does a first deployment pilot take to set up, and what sets that time?
The pilot length depends mainly on the number of packages, how many distinct machine builds you must cover, and how much of the GLPI Inventory setup already works. If agents already report to GLPI and the software inventory is clean, the pilot is mostly packaging and testing. If agents, rules and inventory data still need work, that comes first and adds time. Installer complexity matters too: silent install switches, prerequisites and reboot behavior each add test cycles. The change approval process at your organization can also set the pace. Ask any partner for a written timeline tied to a named package list and a named test group rather than a generic figure.
What does the work need from our side?
Plan on four kinds of input before work starts. Packaging skills are needed to turn installers into repeatable deployment packages, including silent install arguments and success checks. You need test machines that match your real builds, including some with older operating system versions or unusual software sets. Change windows must be agreed for production groups, with a named approver for each. Finally, the GLPI and agent side needs administrator access to the GLPI instance, the relevant entities and profiles, and enough rights on the target machines or the deployment share to test installs. Write these down in the scope so each dependency has an owner and a date.
Does GLPI software deployment replace our endpoint management tool?
It depends on what your current tool does. GLPI Agent can collect inventory, perform network discovery and deploy packages, so for some fleets it can cover the basic install and update path. Many organizations, however, already use an endpoint management product with patching, policy enforcement, reporting and vendor support contracts. In that case, GLPI is usually better positioned as the inventory and asset record that drives targeting, while the existing tool keeps execution duties. Decide by listing the functions you rely on today, such as compliance reporting, user self-service and rollback, and checking which ones the agent path can meet. Confirm current feature coverage with the GLPI documentation for your version.
How do mirror servers change the plan for remote sites?
Mirror servers change where the package files come from and how much traffic crosses your wide area links. Without a local copy, every workstation at a remote site pulls the installer from the central location, which can slow installs and saturate links during a large rollout. With a mirror, the package is staged once at the site and clients fetch it locally. The plan then needs a sync schedule, storage at each site, a check that the mirror holds the same package version as the central server, and a way to handle a site that goes offline during a task. Confirm how your GLPI version and agent handle mirror configuration before you commit to a design for many sites.
What does a fixed-scope engagement cover?
A fixed-scope engagement covers the work named in a written scope before it starts: the packages to build, the groups and tasks to create, the test plan, the mirror design if remote sites are included, the handover documents and the acceptance criteria. DeployOpen plans, implements, documents and hands over self-hosted open-source platforms inside your own infrastructure, so the work runs in your environment, not on a shared service. Scope, deliverables and timelines are agreed in writing, and a quote follows from that scope. Anything outside it, such as a new package wave or ongoing support, is priced separately. Ask for the list of deliverables and the exclusions in writing before comparing proposals.
What drives the cost of a software deployment project?
The main cost drivers are the number of packages, their installer complexity, the variety of machine builds and the number of sites that need mirrors. One-time costs include packaging, test setup, pilot runs and handover. Recurring costs appear when new software versions must be repackaged and retested, when the fleet changes, or when you buy ongoing support. Your internal staff time is also a cost, even when no invoice exists. When requesting a quote, ask the partner to itemize packaging, testing, mirror setup, documentation, training and support separately, and to state which items recur and which assumptions about your environment the price depends on.
How DeployOpen scopes and delivers GLPI software deployment
DeployOpen plans, implements, documents and supports self-hosted GLPI inside your own infrastructure, including the deployment packages, groups, schedules and mirror servers used to push software from GLPI Inventory. Engagements are fixed-scope, so the packages, target groups and rollout waves are agreed in writing before any build starts.
How we scope
- Inventory the applications to deploy, their installers, silent switches and licensing constraints before anything is packaged.
- Define which computers belong to static groups and which to dynamic groups, and the criteria that place each device in them.
- Agree the sites that need mirror servers, the bandwidth and network paths they use, and the maintenance windows for each.
How we build
- Create deployment packages and test them on representative Windows, macOS and Linux devices before any production group is targeted.
- Configure task scheduling, rollout waves and failure handling so each package can be paused, retried or rolled back.
- Set up mirror servers for remote sites and verify that agents fetch packages from the nearest source and report results back to GLPI.
How we hand over
- Document each package, its target groups, schedules, dependencies and the steps to update or retire it.
- Walk your administrators through task status, deployment logs and the checks used to confirm that a package installed correctly.
- Provide the configuration records and runbooks your team needs to add new packages without a new engagement.
How we support
- Ongoing support, upgrades and testing of GLPI and its plugins are available as a retainer, scoped in writing.
- Review package and agent behavior after each GLPI, GLPI Agent or GLPI Inventory plugin upgrade before changes reach production.
- Confirm with your team which change process, approvals and change records apply to each new package before it is released.
