Why teams deploy GLPI Agent with Active Directory GPO
Most Windows estates need hardware and software inventory in GLPI without someone visiting each machine. Group Policy delivered through Active Directory is a practical way to reach that goal when the devices are domain-joined. GLPI Agent collects hardware and software inventory and sends it to GLPI, and according to the GLPI Agent documentation it also performs network discovery and inventory, package deployment and remote ESX inventory. It is the successor of FusionInventory Agent and runs on Windows, macOS and Linux, so the agent itself is not the Windows-only part of the decision. The distribution method is.
Active Directory Domain Services stores users, computers and other objects, and it lets administrators domain-join Windows devices and manage desktops and servers with Group Policy. That makes GPO a natural channel for a Windows fleet that already sits in one or more domains. Linux and macOS machines do not get that benefit from Active Directory in the same way. Microsoft's comparison notes that Linux needs third-party tools or must be configured to authenticate as a Kerberos realm, so teams with mixed fleets should plan a separate method for non-Windows devices.
Before committing to GPO, confirm which OUs hold the target computers, who can edit the relevant policies, and whether any machines sit outside the domain or behind segmented networks that cannot reach the GLPI server. Ask your Active Directory administrators to confirm the domain functional level and that the GLPI server address is reachable from every target subnet. These checks decide whether GPO alone covers the fleet or whether some devices need a different route.
Which GLPI Agent install options to set and when each fits
This table compares the install-time options a GPO rollout depends on, including the GLPI server URL, tags and whether settings are global or per OU. Read each row for what the option controls, when it fits, and what to check in the GLPI Agent documentation for the exact key names and the version you are deploying.
| Option | What it controls | When it fits | Confirm before rollout |
|---|---|---|---|
| GLPI server URL | Where every installed agent sends its inventory, so it must match the GLPI instance the team runs | Always set. A single production GLPI endpoint is the usual case, and a test instance needs its own pilot OU | Confirm the exact parameter name for the server or target setting in the agent version you package, and whether the URL must include a trailing path |
| Tags | A label attached to each machine that GLPI can use to group assets and drive rules | Useful when departments, sites or device classes share one GPO but need different treatment in GLPI | Confirm the tag parameter name, allowed characters and whether tags can be changed later without reinstalling |
| Global configuration | One set of options applied to every machine that receives the GPO | Fits a single-site fleet with one GLPI endpoint and no per-group differences | Confirm that the script or MSI applies the same values regardless of OU, and test on a pilot group first |
| Per-OU configuration | Different options for different OUs, such as separate tags or a separate server for a test ring | Fits fleets with distinct business units, pilot rings or sites that need different tags | Plan one GPO link per OU and confirm how the script reads OU-specific values without duplicating secrets |
| Scheduled run and logging | How often the agent runs and where its logs are written for troubleshooting | Set when you need consistent inventory timing or log retention for support | Confirm the scheduling and log path options in the agent documentation for your version |
| Install mode and privileges | Whether the agent installs silently under the computer account with the rights it needs | Required for every GPO-driven rollout because the install runs at machine startup or logon | Confirm the silent install switches and required privileges with the MSI version you distribute |
Setting up the GPO rollout step by step
This sequence moves GLPI Agent from a tested install package to a managed rollout across a Windows fleet, with a check and a rollback point at each stage. The pilot gate keeps a faulty script or wrong server URL from reaching every machine at once.
Confirm the GLPI server URL and network path
Your infrastructure team confirms the exact GLPI server URL the agents will contact, including the protocol and any path, and checks that pilot Windows machines can reach it over the network. Test from a machine in the pilot OU using a browser or a simple HTTP request, and confirm any proxy, firewall or certificate chain the agent will meet. Done when the test machine gets a valid response from the GLPI server with a trusted certificate. Rollback point: nothing has changed yet, so stop here if the path is not clean.
Stage the agent MSI on a read-only share
Download the GLPI Agent Windows installer from the official release channel, record its version and checksum, and copy it to a file share your domain controllers and file servers host. Grant read permissions to the computer accounts that will install it, not to users, and check that a test computer account can read the file. Done when a test machine can open the MSI path over the network without signing in as an administrator. Rollback point: remove the staged file and its share entry if the package is wrong.
Prepare the deployment VBS script and settings
Write or adapt the deployment VBS script so it runs the MSI silently and passes the install options your design requires, such as the server URL and tags. Confirm the exact property names and parameters in the GLPI Agent documentation for your agent version, because options differ between releases. Run the script by hand on one isolated test machine as a local administrator and read the install log. Done when the agent service is present and the log shows no errors. Rollback point: uninstall the test agent and keep the script unchanged in version control until the test is clean.
Create the GPO and link it to a pilot OU
Create a Group Policy Object that runs the startup script (or the computer configuration method your team uses) and link it only to a pilot organizational unit containing a small set of non-critical machines. Set the GPO link to enforced only if your standards require it, and keep the scope to that OU. Run gpupdate on a pilot machine or wait for the normal refresh, then check the Group Policy results. Done when the policy applies to the pilot machines and the agent install completes. Rollback point: unlink the GPO from the pilot OU, which stops new installs without touching machines already installed.
Verify pilot machines appear in GLPI with tags
In GLPI, confirm each pilot computer appears as a new asset with the expected entity and tags, and that its hardware and software inventory has been received. Compare the computer name, operating system and last contact time with the machine itself. If records are missing or tags are wrong, check the agent log on the endpoint and the server-side import rules before widening scope. Done when every pilot machine reports to GLPI with the correct tags on at least one full inventory cycle. Rollback point: unlink the GPO and remove pilot assets from GLPI if the data is not usable.
Widen scope in controlled waves
Link the GPO to further OUs in waves, starting with a group that represents a typical configuration, and repeat the GLPI check for a sample of machines in each wave. Watch for machines that do not appear, duplicate records created by renamed hosts, and endpoints blocked by security tooling. Record any exceptions in your change log so later waves can be adjusted. Done when each wave reports to GLPI at the rate your team expected. Rollback point: unlink the GPO from the wave that caused problems and fix the cause before the next wave.
Plan agent version upgrades through the same path
When a new GLPI Agent version is released, stage it on the share alongside the current package, test it on the pilot OU first, and confirm the install options still match the documentation for that version. Change the script or MSI reference only after the pilot check passes, then move the GPO to the new package wave by wave. Confirm that agents report under the same asset records after the upgrade. Done when the pilot machines show the new agent version in GLPI and no duplicate assets appear. Rollback point: point the GPO back to the previous MSI, which remains on the share until the rollout is complete.
How the rollout changes for domain-joined, hybrid and non-domain Windows devices
Group Policy applies to Windows devices joined to an on-premises Active Directory domain, so this is the situation where the GPO method described on this page works as written. Group Policy scope stays with on-premises Active Directory, which is the directory that domain controllers replicate and that administers computer objects and organizational units. The rollout here depends on your own directory design rather than on any cloud service.
- Organizational unit scope: Confirm which organizational units hold the computers that should receive the agent and which should be excluded, such as kiosks or lab machines.
- Startup script or software install: Decide whether the VBS script or MSI install runs at computer startup, and check that the deployment account can read the MSI share.
- Install options: Set the GLPI server URL, tags and other options in one policy so every domain-joined machine reports to the same instance.
- Upgrade ownership: Assign a named owner for agent version changes, since an updated package must be published to the share and reapplied through the same policy.
- Policy review: Check that existing software deployment or startup policies do not conflict with the new agent policy.
Before the build, ask your Active Directory team to confirm the domain functional level, the OU layout and who controls Group Policy changes.
Many organizations run Active Directory on premises and sync identities to Microsoft Entra ID with Microsoft Entra Connect. Microsoft describes Entra ID as the cloud identity as a service evolution of Active Directory, but synced identities do not move Group Policy into the cloud. Devices that are domain-joined to on-premises Active Directory still receive GPO, while cloud identity features do not replace that path for agent delivery.
- Join state per device: Identify which machines are domain-joined, which are Entra joined and which are hybrid joined, because each state has different management options.
- Sync scope: Confirm with the identity team which objects Entra Connect synchronizes, since sync scope affects user sign-in data, not the GPO applied to computers.
- Separate delivery path: Plan a different delivery method for cloud-managed devices, such as the one your endpoint management tool supports, and document it next to the GPO method.
- Consistent settings: Use the same GLPI server URL, tags and agent version across both paths so inventory records do not split by delivery method.
- Change control: Agree with the identity team which changes to synchronization or join state would move a device out of GPO scope.
Confirm with your identity team exactly which device join states exist today and which of them Group Policy reaches.
Devices that are not joined to the domain are outside the reach of Group Policy, so the MSI and VBS method cannot install the agent on them. These can include contractor laptops, field equipment, lab systems and some servers in separate networks. Microsoft's comparison notes that Active Directory manages Windows devices through Group Policy once they are domain-joined, so a non-domain device needs another route to receive GLPI Agent.
- Inventory the population: List devices outside the domain and record their owners, locations and how they are currently managed.
- Choose an alternative method: Select a delivery tool your organization already runs for unmanaged or workgroup machines, or install the agent manually where few devices exist.
- Credentials and trust: Confirm how the agent reaches GLPI from networks outside the domain, including any proxy or certificate requirements.
- Ownership of exceptions: Decide who approves each exception and how it is reviewed when the device changes state.
- Inventory gap tracking: Flag these devices in GLPI so missing data is visible rather than silently absent from reports.
Ask your security and identity teams to confirm which workgroup or non-domain machines are permitted on the network before choosing the method.
Securing the install share, the agent channel and the GPO scope
A GPO rollout gives one configuration path reach across every targeted Windows machine, so the same weakness repeats everywhere. The risks below cover the places where that reach can be abused: the installer share, the GPO and script, the agent transport, the install parameters and the rollout account. Check each one before the first pilot OU receives the policy.
Write access to the MSI share
Anyone who can write to the share that holds the GLPI Agent MSI can replace the installer, and every machine that runs the deployment script will install whatever is there. Limit write permissions to a small administrative group, leave read access to computer accounts, and record a hash of the approved MSI so you can compare it before each rollout wave. Confirm who holds write rights through inherited permissions on parent folders, not only the share itself.
Editing the GPO and its script
The GPO and the VBS deployment script run with elevated rights on every targeted computer, so editing either one is equivalent to running code as an administrator across the scope. Restrict edit rights on the GPO to a named group, keep the script in the same controlled location as the MSI, and review changes through your normal change process. Confirm that delegated GPO editors cannot link the policy to OUs outside the pilot scope.
Transport to GLPI
If agents send inventory to the server over plain HTTP, the data can be read or altered in transit, and an attacker on the network path can impersonate the GLPI server. Use the HTTPS server URL, let the agent validate the server certificate, and test validation on one pilot machine with your internal CA installed. Confirm which certificate chain your GLPI server presents, because a private CA that is missing from Windows trust stores causes failures that teams often bypass by turning validation off.
Install parameters that reveal structure
Server URLs, tags and other install options are written into the policy, the MSI command line and often the agent configuration on each machine. Tags such as site names, department codes or network ranges can describe your internal layout to anyone who reads the GPO or the installed configuration. Choose tags that identify the rollout wave and the group, avoid embedding passwords or tokens in the script, and review which values a standard user can read on the endpoint.
The account the rollout runs under
Software installs through GPO run in the computer context, but the people and service accounts that create, link and monitor the policy hold rights that can reach the whole domain. Use a dedicated admin account for the rollout, keep it out of daily use, and grant it only the rights needed for the GPO scope and the share. Ask your directory team to confirm that the account cannot modify unrelated GPOs or domain-wide settings.
Upgrading GLPI Agent versions after the first rollout
An upgrade is not a repeat of the first install. On the first rollout, GPO runs the deployment script on machines that have no agent. For a version change, the question is whether the new MSI on the share replaces the installed agent cleanly and whether the script's install options (server URL, tags and any other settings you pass) still match what you want. Replace the MSI on the distribution share only after you have confirmed how the target release handles an in-place upgrade, and keep the previous installer in place until the pilot is finished so you can roll back. Confirm the exact upgrade behavior, including whether options must be restated and whether a reboot is needed, against the agent release notes for your target version in the GLPI Agent documentation.
GPO does not push software changes on a timer you control. Machines pick up the revised startup or logon script on their next policy refresh, or on the next restart or logon depending on how the script is linked, so the rollout will be spread out across the fleet over time. Stage the new version on a pilot OU first: link the updated script to that OU only, let it run on a small set of representative machines (laptops that are often offline, servers, and machines in other sites), and wait for a few policy cycles before widening the link. Keep the pilot scope and the change window in your change record, because a bad MSI will reach every machine that picks up the link.
Check the version each machine reports in GLPI after each stage, not only the install logs on the endpoint. Filter the computer list by agent version and compare the counts against your expected population each day of the rollout. Machines that lag are usually offline, locked by a policy that blocks the script, or still waiting for a restart. For each laggard group, confirm whether it has contacted the server recently, whether the script ran, and whether a restart is pending before you treat it as a failure. Keep a short list of the stragglers and set a date after which you escalate them to a manual install.
What to confirm in your environment before a GPO rollout
A GPO rollout touches the agent version, the domain controllers that host the share and policy, the Windows Server licensing behind them, and the GLPI server that receives the data. Each card below names one item to verify and the check that proves it before any policy is linked to an organizational unit.
Agent version and Windows support
Confirm which GLPI Agent release you will package and that it supports every Windows version in the target fleet, including older desktops and servers that may still be in use. Record the exact version in the MSI file name and in your change ticket so that later upgrades and rollbacks refer to the same artifact. Test the package on one machine from each Windows build in your inventory before you link it to a production OU.
Domain controller edition and CALs
Identify which domain controllers host AD DS, the policy, and the SYSVOL share that will serve the deployment script and installer. Check the Windows Server edition and core count on each, then confirm that Client Access Licenses cover every user or device that reaches those servers. Ask your licensing partner to confirm pricing in your region, because the published suggested prices vary by region.
Windows Server lifecycle status
Check the mainstream and extended support end dates for the Windows Server version that runs AD DS in your forest. A domain controller past its support window will be a poor place to host the policy and share, and any upgrade should be scheduled before the rollout rather than during it. Record the dates in your change calendar and confirm them against Microsoft's lifecycle pages.
Reach to remote sites
Determine whether the GPO and the MSI share can be reached from every site, or whether some sites rely on a slow WAN link or a distant domain controller. Confirm which site hosts the share and how clients in remote sites will fetch the installer. Test a machine in each remote site and confirm that the agent contacts the GLPI server through the expected path, since a missing route will show up as silent inventory gaps.
GLPI server version and reachability
Confirm the GLPI version on the server that will receive agent data, with GLPI 11 or 12 as the supported target for new work. Check that the server URL in the installer resolves and is reachable from every client network, and that the web server exposes GLPI through its public directory. Plan the agent rollout after any GLPI upgrade, because the server should be stable before thousands of clients begin reporting.
Change ownership and rollback plan
Name who owns the GPO, the share, the GLPI server URL, and the agent package, and agree on how each is changed. Document how to unlink the policy, remove the installer, and handle agents already installed, since a bad server URL can leave machines reporting to the wrong place. Keep the previous MSI on the share until the new version has been validated on the pilot OU.
What does a GLPI Agent GPO rollout cost and how long does it take?
What drives the cost of a GLPI Agent GPO rollout?
The main cost drivers are fleet size, the number of OUs and Active Directory sites, how much testing the change needs, how much packaging and script work is required, and how much internal change control the rollout must pass through. A flat fleet of a few hundred machines in one site is a different job from a fleet spread across many OUs, branch offices and subnets with different firewall rules. Each added OU adds GPO links, filtering and validation, and each site may need its own path to the MSI share or its own network check. Ask the provider to break the quote down by these drivers so you can see which ones you control.
Which parts of a GPO rollout are one-time and which recur?
The one-time work covers design, the deployment VBS script, the MSI share, the initial GPO objects, pilot testing and the first full rollout. Recurring work covers agent upgrades when a new GLPI Agent version is adopted, testing those upgrades against your Windows builds, updating install options such as the server URL or tags, and handling new machines that join the domain. Ask whether the quote includes a documented upgrade procedure and how many upgrade cycles it covers, so you know what the next version will cost in effort.
Can an internal team roll out the GLPI Agent through GPO alone?
Yes, if your Active Directory administrators already manage Group Policy, can build a software or script deployment, and have a test OU and a change process they trust. The work is mostly configuration rather than new software, so the constraint is usually time and review capacity rather than skill. Teams often struggle with the first pass because they have not tested install options, logging or how a failed install is retried. An external partner is most useful when the rollout is blocked by scale, multiple sites, or a tight change window, and you should confirm which of these applies before you decide.
What does the rollout need from our side?
Plan for Active Directory administrators who can create and link GPOs and who can approve changes, a test OU with representative Windows machines, a reachable GLPI server URL from every target network, and a defined change window for each wave. You also need access to a file share that all target computers can read, and a decision on who owns the GLPI side, including tags and entity assignment. Confirm that your Windows Server and client builds are in support before the pilot, because lifecycle dates affect what you can test against.
Does the rollout need a change window and how should we plan for it?
Yes, most organizations require a documented change window for GPO changes that affect many machines. Plan a pilot wave in the test OU, then production waves by OU or site, with a rollback step for each wave. Agents usually check in during normal startup or policy refresh, so inventory data can take time to appear in GLPI. Ask the provider how they expect your change board to review each wave and what evidence they will hand over at the end of each one.
What should we ask for in a written scope before we sign?
Ask for the list of OUs and sites in scope, the GLPI Agent version and install options to be deployed, the deployment method (VBS script, MSI share and GPO objects), the test plan and pilot criteria, the rollout waves and change windows, the rollback steps, and the handover items such as the runbook and upgrade procedure. Also ask what is excluded, such as non-Windows devices, servers outside the domain, or custom tags. Request the schedule as milestones tied to acceptance, and confirm who approves each milestone. Because DeployOpen works on fixed-scope engagements, the written scope is the document that sets the quote.
How do we keep the rollout secure while agents report to GLPI?
Agents send inventory to the GLPI server, so the server URL, transport and certificate handling need to be agreed before the pilot. Confirm how the agent will validate the server certificate, including any private CA, and who controls the GPO and the MSI share so that only approved packages run. Restrict write access to the share and review GPO change logs as part of the change process. Transport hardening is covered in more depth in the agent communication guidance linked from this page.
How DeployOpen scopes and delivers a GLPI Agent GPO rollout
DeployOpen plans, implements and documents GLPI Agent rollouts through Active Directory Group Policy inside your own domain and infrastructure. The work starts with a written scope that fixes which OUs, server URLs, tags and agent versions are covered, so the rollout can be tested and handed over with clear evidence.
How we scope
- We confirm the Active Directory forest, domains, OUs and GPO permissions the rollout will use.
- We record the GLPI server URL, tags, install options and target Windows device groups in the written scope.
- We agree which Windows versions, pilot groups and upgrade rules are in or out before work begins.
How we build
- We build the deployment VBS script and MSI share with access limited to computer accounts that need them.
- We create and link GPOs in a pilot OU first, then test install, check-in and inventory results on sample devices.
- We stage agent version upgrades through the same GPO path so later changes follow a tested, repeatable process.
How we hand over
- We document the GPO structure, script logic, share permissions and every install option used in the rollout.
- We provide a verification checklist that shows how to confirm agents appear in GLPI for each target OU.
- We walk your administrators through rollback steps and the procedure for publishing a newer agent version.
How we support
- Fixed-scope engagements end with the agreed deliverables, and any further work is quoted from a new written scope.
- Ongoing support, version upgrades and continuous testing are available as a retainer if your team wants them.
- Before a retainer starts, we confirm response expectations and which GLPI and GLPI Agent versions are in service.
