How the SCCM plugin brings SCCM computers into GLPI
A team that already runs System Center Configuration Manager for Windows device management and wants those computers in GLPI's asset inventory has one supported route: the GLPI SCCM plugin. The plugin adds two automatic actions. SCCMCollect queries the SCCM server with MsSQL queries and builds an XML file per computer in FusionInventory format, and SCCMPush injects those files into GLPI over HTTP or HTTPS. The plugin depends on the FusionInventory plugin for GLPI, so that dependency must be installed and kept compatible before any SCCM data flows.
This work applies only to self-hosted GLPI. The SCCM plugin is not available on GLPI Cloud, so a team using a hosted GLPI tenant cannot take this route and needs to plan a different inventory path or a self-hosted instance. Confirm this with the plugin's documentation and with your GLPI provider before you scope the project, because the answer determines whether the SCCM plugin is even an option.
Before you commit, confirm three things in your own environment: that your SCCM site runs version 1802 or later, that the Microsoft Drivers for PHP for SQL Server can be installed on the GLPI application server, and that the GLPI server can reach the SCCM database. The SCCM plugin documentation sets out these requirements in full. Treat the SCCMCollect account's read access to the SCCM database as a control to review with your database and security teams, since it is the link that exposes device data outside SCCM.
What the SCCM plugin needs before you start
The SCCM plugin depends on several components working together: a supported GLPI host, the FusionInventory plugin, a driver that lets PHP reach SQL Server, and a read path into the SCCM database. Check each one before you install anything, because a gap in any layer shows up later as empty or stale computer records.
FusionInventory plugin for GLPI
The SCCM plugin builds its output in FusionInventory format and relies on that plugin's data model to store what it receives. Install and activate FusionInventory on the GLPI instance first, and confirm the version you plan to run is compatible with your GLPI release. Also check that the team responsible for FusionInventory knows it is a dependency, since changes to it can break the SCCM data flow.
SCCM 1802 or later
The plugin documentation sets SCCM 1802 or later as a requirement. Confirm your site server and its database version before scoping the work, because an older branch means the queries the plugin expects may not match your schema. Record the exact build in the project file so the assumption can be checked during the design review.
Microsoft Drivers for PHP for SQL Server
SCCMCollect runs MsSQL queries from PHP, so the web server's PHP runtime needs the Microsoft driver for SQL Server installed and enabled. Verify the driver loads under the same PHP version and service account that GLPI uses, not only from a command line session. A missing driver usually appears as a failed automatic action rather than a clear install error.
Supported GLPI host stack
Self-hosted GLPI needs a PHP version and database that the installation docs currently support for your release. For GLPI 11.0 the docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and state that only MySQL and MariaDB are supported. Confirm the exact versions for your target release before you pick the host, since the requirements differ between GLPI branches.
Network path to the SCCM database
SCCMCollect opens a direct SQL connection from the GLPI server to the SCCM database, so firewall rules must allow that traffic on the SQL Server port your site uses. Map which host runs the query, which segment it crosses, and whether a database listener or replica is involved. Test the path with the same driver and credentials that the plugin will use, not with a generic client.
Read-only database account
Create a dedicated SQL login for the plugin and grant it only read access to the SCCM database objects the queries need. Avoid reusing an administrator account, since a compromised GLPI server would then hold rights over the site database. Confirm the exact object-level rights with the plugin documentation before you request them, because the required set depends on the plugin version.
Configuring the collect and push sequence
This sequence connects SCCM to GLPI in a fixed order: prerequisites first, then the SCCM connection, then SCCMCollect before SCCMPush. Each action runs manually once so you can check the output at every stage before the schedule takes over.
Install and activate FusionInventory
A GLPI administrator installs the FusionInventory plugin on the GLPI instance and activates it from the plugin list. The SCCM plugin depends on FusionInventory because SCCMCollect builds its XML files in the FusionInventory format. Done means FusionInventory shows as active and its pages load without errors for an administrator. After any GLPI update, check the plugin list again, because GLPI 11 suspends plugins when it detects a new version.
Install the SQL Server driver for PHP
A server administrator installs the Microsoft Drivers for PHP for SQL Server on the GLPI host, using the build that matches the PHP version and thread-safety mode in use. GLPI runs under the web server's PHP, so enable the extension there and confirm it loads in that context, not only from the command line. Done means a small test page or PHP check shows the SQL Server extension as loaded, and the GLPI host can reach the SCCM database server over the network.
Enter the SCCM connection settings
A GLPI administrator opens the SCCM plugin configuration and enters the connection details for the SCCM site database that the collect action will query. Confirm with your SCCM team that the SCCM version is 1802 or later and ask for a database account with read access limited to the inventory data the plugin needs. Done means the settings save, and any connection test the plugin offers succeeds from the GLPI host.
Schedule SCCMCollect before SCCMPush
In the GLPI automatic actions, a GLPI administrator sets SCCMCollect to run on a schedule. Collect must run before push because it creates the XML file for each computer, and push only sends what collect has already built. Agree the interval with your SCCM team, considering how often SCCM inventory changes and how much query load the SCCM database can carry. Done means SCCMCollect is listed as enabled with the chosen interval.
Run SCCMCollect manually and inspect the XML
Run SCCMCollect by hand from the automatic actions page and read its result. Check the output location for XML files, then confirm there is one file per computer returned by SCCM and that each file is in the FusionInventory format. Pick two or three computers you know are in SCCM and confirm their files exist. Done means the action reports success and the expected test computers each have a matching XML file.
Schedule SCCMPush after a completed collect
Schedule SCCMPush so it runs after SCCMCollect has finished, with enough spacing that the two never overlap. Push sends the XML files to GLPI over HTTP or HTTPS, so choose HTTPS for production and confirm with your network team that the GLPI host trusts the certificate for its own GLPI endpoint. Done means SCCMPush is enabled and its schedule follows a completed collect cycle.
Run SCCMPush and verify test computers in GLPI
Run SCCMPush manually, then search the GLPI computer list for the test computers from the collect check. Open one computer and compare its name, hardware and software details with the same device in SCCM. Review the action log for failed injections. Done means each test computer appears as a computer item with the expected data, and the log shows no failed pushes for them.
Choosing the route for your Windows estate
Some organizations keep Configuration Manager as the authoritative record of managed Windows devices, for example because software deployment, patching and compliance reporting already run from it. In this case the SCCM plugin reads from the site database and copies what SCCM knows into GLPI, so GLPI becomes a consumer of that data rather than the owner of it. The SQL connection is the critical dependency: the collect action queries the SCCM server with MsSQL queries, so the database account, network path and driver must stay healthy for as long as SCCM is authoritative.
- SQL access: Plan a read-only database account scoped to the reporting views the plugin needs, and confirm this with your SCCM administrator and the plugin documentation.
- FusionInventory dependency: The plugin depends on the FusionInventory plugin for GLPI, so its upgrade cycle becomes part of your GLPI upgrade plan.
- Driver maintenance: The Microsoft Drivers for PHP for SQL Server must be kept compatible with your PHP version on every GLPI server.
- Source conflicts: Decide which fields GLPI may overwrite and which it must leave to other agents, so two feeds do not fight over the same asset.
- Ongoing work: Each SCCM upgrade, schema change or GLPI upgrade can break the collect step, so schedule checks after each change.
Before committing, confirm that your SCCM version meets the plugin's stated minimum and that your security team accepts a database connection from the GLPI host.
Teams that plan to retire or reduce SCCM still need accurate inventory during the transition, and the GLPI feed can serve as a bridge. The risk is building a long-lived dependency on a plugin for a system you intend to remove. A useful approach is to treat the SCCM feed as temporary, record which asset fields it owns, and plan the point at which another source takes over each field. Ask your team to state the retirement horizon before any SQL account is created, because that date determines how much maintenance the bridge deserves.
- Field ownership map: List each inventory field, its current source and its future source, so the switch does not leave gaps.
- Parallel running: Compare GLPI records from the SCCM feed with the replacement tool for a period before cutting over.
- Decommission steps: Remove the automatic actions, the SQL account and the plugin configuration in a documented order.
- Historical data: Decide whether assets collected from SCCM keep their history or are re-keyed when the new source arrives.
- Cost of the bridge: The plugin dependency, driver and database access all recur until the feed is removed, so count them as ongoing cost.
Before starting, confirm with your replacement tooling owner which fields it will supply and when, because a bridge without a retirement date tends to outlive its purpose.
For many estates, installing GLPI Agent on each endpoint is simpler to operate than querying a central SCCM database. The agent collects hardware and software inventory and sends it directly to GLPI, and it runs on Windows, macOS and Linux. This removes the SQL connection, the Microsoft driver and the dependency on SCCM's database schema. The trade-off is that every device needs the agent deployed and kept current, so your deployment tooling and update process become the main workload. GLPI Agent is also the successor of FusionInventory Agent, so teams already running FusionInventory should plan that migration rather than assume it is automatic.
- No SQL dependency: Endpoints report directly, so there is no database account to rotate or driver to patch.
- Deployment reach: Confirm that your software deployment method covers every Windows device, including laptops that are often off the network.
- Agent updates: Plan how agent versions are rolled out and checked across the fleet.
- Network path: Confirm that endpoints can reach the GLPI server over the transport you choose.
- Overlap control: If SCCM also reports to GLPI, decide which source owns each device to avoid duplicate assets.
Before choosing this route, ask your team how many devices are not reliably reachable by SCCM and whether they are already managed by any agent.
The right route depends on which system must remain authoritative, how long SCCM will stay in use, and how much your team wants to maintain the connection itself. Organizations with SCCM as the long-term record usually accept the SQL and driver work. Organizations leaving SCCM usually want a bounded bridge with a clear end date. Estates where endpoints are hard to reach through SCCM or where the team wants fewer moving parts often find the agent route easier to run. Many organizations combine routes for different device groups, which is workable only if field ownership is written down.
- Authority: Name the system that wins when two sources disagree about the same device.
- Retirement horizon: Record the date SCCM is expected to stop being a data source, if one exists.
- Maintenance owner: Name who patches the driver, updates the plugin and watches the collect action.
- Coverage gaps: List device groups SCCM does not reach today.
- Combined routes: Decide in advance whether a device may be reported by both paths.
Before you commit, ask your GLPI partner to put the chosen route, field ownership and maintenance owner into the written scope.
Which SCCM data lands in which GLPI fields
This table traces each kind of SCCM inventory from the source query through the per-computer FusionInventory file into GLPI computer, operating system, hardware and software records. Read each row as a path to check, since the final value depends on FusionInventory parsing and the SCCM data your site collects, so validate a sample of records against the SCCM console before go-live.
| Data area | How it reaches GLPI | Validate before go-live |
|---|---|---|
| Computer name and serial number | Queried from the SCCM database by SCCMCollect, then written into the computer section of the FusionInventory file | Compare name, domain suffix and serial for sample machines against the SCCM console |
| Operating system | Written to the operating system section and stored on the GLPI computer after FusionInventory parsing | Compare version and build strings, since FusionInventory formatting can change their wording |
| Processor, memory and BIOS | Written to hardware sections and stored as GLPI component records | Confirm core counts and memory totals, which depend on the SCCM hardware inventory enabled at your site |
| Disks and network adapters | Mapped to storage and network components only when the source query returns them | Confirm disks and MAC addresses appear, as virtual or filtered adapters may be absent |
| Installed software | Added as software and installation records, depending on the software query in the plugin | Compare several titles and versions with the SCCM console, as the lists may not match exactly |
| Logged-on user | Mapped to the user on the computer when the source data includes one | Confirm the last user matches, because GLPI user matching depends on your authentication setup |
| Last inventory date | Set from the time of the collection or push run, which may differ from the SCCM client scan time | Confirm which timestamp GLPI shows and how it compares with SCCM client activity |
| Fields with no SCCM source | Left empty, or filled by GLPI rules or manual entry | Agree who owns location, status and purchase data before the first sync runs |
How collect and push move data between the systems
The SCCM plugin splits the work into two automatic actions. SCCMCollect runs MsSQL queries against the SCCM site database and writes one XML file per computer in FusionInventory format. SCCMPush then reads those files and injects them into GLPI over HTTP or HTTPS. The two actions are independent, so a collect run can succeed while the push fails, and the reverse is also possible. Plan for them as two separate points of failure, each with its own schedule, logs and alerting. Confirm the frequency of each action in your GLPI automatic actions configuration, because the two schedules determine how stale an asset record can become relative to what SCCM knows.
Failed runs leave different traces depending on where they fail. If SCCMCollect cannot reach the SQL Server, the most recent XML files stay in place and GLPI keeps showing the previous inventory, which can look current for a long time. If SCCMPush fails, files accumulate on the GLPI host until a later run injects them. Ask whether the plugin deletes or archives files after a successful push, how long failed files are kept, and who owns disk space on that host. Track the age of the newest file per computer and the count of unprocessed files, and check both after any change to the SQL account, certificates or the GLPI URL.
The data crosses two trust boundaries. The first is between the SCCM database and the host running SCCMCollect, where a SQL login with read access must be reachable from that host and the connection is governed by your SQL Server encryption settings. The second is between the GLPI host and the GLPI endpoint that receives the pushed files, where HTTPS with a certificate that GLPI and the SCCM-side host both trust is the setting to insist on. The XML files contain hardware and software details for every managed computer, so restrict who can read the directory where they are written and treat it as sensitive data. Confirm the exact transport and file location with the plugin documentation before you set up network rules, since these details can differ by plugin version.
Securing the SQL connection and the push channel
The SCCM plugin moves inventory data across three boundaries: from the SCCM site database to the GLPI host, through a staging directory of XML files, and into GLPI over HTTP or HTTPS. Each boundary needs its own control, and the settings below should be confirmed against your SCCM and GLPI versions before go-live.
Read-only SQL account scoped to the site database
The SCCMCollect action queries the SCCM server with MsSQL queries, so it needs a database login that can read inventory views and nothing more. Create a dedicated SQL login mapped to the site database with read permissions only, and avoid reusing a domain administrator or a broad service account. Confirm which views and tables the plugin reads in your SCCM version, and check that the account cannot write, drop or read other databases on the same instance. Review the grant after each SCCM upgrade, since the schema the plugin depends on can change.
Encrypted SQL transport
The connection from the GLPI host to SQL Server carries hardware and user data, so it should use TLS. Confirm that the Microsoft Drivers for PHP for SQL Server version you install supports encryption with your SQL Server version, and that the server certificate is trusted by the GLPI host. Do not disable certificate validation to get a connection working. If the plugin's connection settings do not expose an encryption option, record that gap and decide whether the SQL listener and the network path between the two hosts are sufficient compensating controls.
HTTPS for the push channel
The SCCMPush action injects generated XML files into GLPI over HTTP or HTTPS. Use HTTPS with a certificate issued by an internal or public CA that the sending host trusts, and keep plain HTTP off the path entirely. Restrict which hosts can reach the GLPI inventory endpoint with network rules, and confirm that the push credentials, if any, are not stored in plain text in shared locations. Check the GLPI URL configuration after any change of hostname or certificate, because a mismatch often fails silently.
Restricting plugin configuration rights
Anyone who can edit the SCCM plugin configuration in GLPI can change the SQL connection target, the push destination and the schedule of automatic actions. Limit plugin configuration to a small administrator profile, and confirm that the standard profiles used by helpdesk and technicians cannot open the setup page. Enable GLPI's logging for configuration changes where available, and review who holds administrator rights in the entities that receive SCCM data. Document the change owner for the SQL and push settings so a change request is required before any edit.
Protecting the XML staging directory
Between collection and push, the plugin writes one XML file per computer, and those files contain hostnames, serial numbers, installed software and user associations. Place the staging directory outside the web root, grant write access only to the service account that runs the collection and read access only to the push process, and remove inherited permissions for other users. Confirm the directory location and file cleanup behavior in your plugin version, and decide how long files may remain on disk, since stale files are a common leak.
Patching the GLPI host and its dependencies
The GLPI host runs the web server, PHP, the database client, the FusionInventory dependency and the SCCM plugin, so every layer adds to its exposure. Keep the operating system, PHP and the Microsoft driver on supported, patched releases, and check the GLPI version you run against the release notes before applying an update. Plugin compatibility is a common blocker for GLPI upgrades, so test the SCCM plugin on a staging copy first and keep a tested rollback that includes the configuration and key files.
Why SCCM sync fails and how to fix it
This table lists the failures most often seen when the GLPI SCCM plugin is set up, with the cause and fix for each. Read it top to bottom during a first setup or when a sync stops, and check the causes in order because several failures share the same symptom: no computers appear in GLPI.
| Failure | Likely cause | Fix |
|---|---|---|
| Plugin does not work at all | The FusionInventory plugin for GLPI is not installed or not active, and the SCCM plugin depends on it | Install and activate FusionInventory first, then confirm the SCCM plugin is active before enabling its automatic actions |
| PHP cannot reach SQL Server | Microsoft Drivers for PHP for SQL Server are missing, or the driver version does not match the PHP version and thread-safety build in use | Install the driver build that matches the PHP version and web server runtime, then restart the web server and check the PHP extensions loaded |
| SQL connection or login errors | Wrong SQL Server host, instance name, port, database name or service account, or the database is not reachable from the GLPI server | Test the connection from the GLPI server using the same account, confirm the SCCM site database name, and open the required network path and port |
| Unsupported SCCM version | The SCCM site is older than version 1802, which is the minimum the plugin documentation lists | Confirm the SCCM version in the console before troubleshooting further, and plan an SCCM upgrade if the site is older |
| Push fails with endpoint errors | The SCCMPush action cannot reach the GLPI inventory endpoint over HTTP or HTTPS, often because of a wrong URL, a proxy, or a firewall rule | Check the GLPI URL configured for the push, test reachability from the machine running cron, and confirm the web server accepts the inventory requests |
| Certificate errors on HTTPS push | The GLPI certificate is self-signed, expired, or issued by an authority the GLPI host does not trust | Install a certificate the GLPI host trusts, including the internal certificate authority chain, and confirm the expiry date |
| Automatic actions never run | The GLPI cron task is not configured on the server, or the SCCMCollect and SCCMPush actions are not enabled in the automatic actions list | Configure the GLPI cron job on the host, enable both automatic actions, and review the task history after the next scheduled run |
| Collected files exist but no computers appear | SCCMPush runs before SCCMCollect has produced files, or the push target rejects the files | Run SCCMCollect first, confirm the XML files are created, then run SCCMPush and check the GLPI logs for rejected items |
Questions buyers ask before hiring help with SCCM sync
What drives the cost of an SCCM to GLPI sync project?
The cost follows the size and shape of your SCCM environment and how much of the plugin chain you must build yourself. The main drivers are the number of SCCM sites and managed computers the collect action will query, the SQL Server connection and driver work on the GLPI host, the FusionInventory plugin setup and its own configuration, the testing you need against real SCCM data, and the ongoing maintenance you want after go-live. One-time work covers the build and first validation. Recurring work covers plugin updates, GLPI version upgrades that touch the plugin chain, and checking that collection still matches your SCCM schema. Ask for a written, fixed-scope quote that lists each of these items separately, with the environments you expect to cover and the test data you will provide.
How long does an SCCM inventory sync take to set up?
The duration depends on your environment, so no fixed timeline applies here. The work moves faster when there is one SCCM site, a clean SQL Server read account, a GLPI instance that already runs and a FusionInventory setup that follows its documentation. It slows down with several SCCM sites, network paths that need firewall changes, database access that requires new approvals, or a large number of computers that must be checked for duplicates against existing GLPI records. Request a schedule in the written scope that shows the discovery, build, test and handover phases, and name the dependencies that could move each one.
Can our internal team build the SCCM sync without outside help?
Yes, a capable internal team can build it, provided it has the skills and access the work requires. The build touches four areas: the SQL Server connection from the GLPI host using Microsoft Drivers for PHP, the FusionInventory plugin dependency, the SCCMCollect and SCCMPush automatic actions, and the import results inside GLPI. Your team needs someone who can read the SCCM database schema, someone who runs the GLPI web server and PHP stack, and someone who can test the results against known computers. Many teams find the testing and the upgrade planning take more time than the first build. Outside help is most useful when the internal team lacks SQL or PHP driver experience, has no test window, or wants a documented handover.
What do we need to provide before the SCCM sync work starts?
You need to provide four things. First, read access to the SCCM site database or the query path the collect action will use, along with the list of sites in scope. Second, a test window on both the GLPI instance and the SCCM side, so the collect and push actions can run against a limited set of computers before a full run. Third, administrator rights on the GLPI host to install the Microsoft Drivers for PHP for SQL Server, enable the plugins and configure the automatic actions. Fourth, a named contact who can approve firewall changes between the SCCM server and GLPI over HTTP or HTTPS. Put these in the scope document so the quote reflects what is available on day one.
Does the SCCM plugin work on GLPI Cloud or only self-hosted GLPI?
The SCCM plugin is not available on GLPI Cloud, according to the plugin documentation. It needs a self-hosted GLPI instance where you can install the FusionInventory plugin, the Microsoft Drivers for PHP for SQL Server and the plugin itself, and where you can reach the SCCM database from the GLPI host. If your organization uses a managed GLPI service, confirm with the provider whether it allows custom PHP extensions and plugins before you plan the sync. The plugin documentation also lists SCCM 1802 or later as a requirement, so confirm your SCCM version before you start.
What data does the SCCM plugin bring into GLPI, and what should we check?
The SCCMCollect action queries the SCCM server with MsSQL queries and builds an XML file per computer in FusionInventory format. The SCCMPush action then injects those files into GLPI over HTTP or HTTPS. Engineers should check that hardware fields, operating system values, software lists and computer names arrive in the expected GLPI fields after each run. Compare a sample of computers against the SCCM console. Check for duplicate computer records, especially when GLPI already holds devices from another inventory source, and confirm that the automatic actions run on the schedule you set, with their logs reviewed after each run.
When is GLPI Agent a better choice than the SCCM plugin?
GLPI Agent is usually the better choice when you want inventory from each device directly rather than through SCCM, or when you are moving away from SCCM as the source of truth. According to the GLPI Agent documentation, the agent collects hardware and software inventory, runs on Windows, macOS and Linux, and is the successor of FusionInventory Agent. It removes the SQL Server driver and the SCCM database dependency from the GLPI host. Keep the SCCM plugin when SCCM is the system of record for your fleet, your processes depend on its data model, and a direct SQL read is approved. Many organizations decide with a short comparison of coverage, approval paths and the data each option must carry.
How do we keep the SCCM sync working after GLPI and SCCM upgrades?
Plan for upgrades from the start. Each GLPI major release can change plugin compatibility, and the update procedure requires backups of the database, files and configuration keys, followed by the console database update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so the SCCM and FusionInventory plugins need a retest after every major move. SCCM changes its database schema over time, so the collect queries should be reviewed when you upgrade SCCM. Ask any provider for a written maintenance scope that covers version testing, query review, and how the work is billed, whether as a retainer or as a separate change request.
How DeployOpen scopes and delivers SCCM inventory sync
DeployOpen plans and implements GLPI and Microsoft SCCM inventory synchronization inside infrastructure you control, starting from a written scope. The work covers the SCCM plugin, its SQL Server and FusionInventory prerequisites, and the verification and handover that let your team run the sync after go-live.
How we scope
- Confirm which SCCM site servers, databases and collections feed GLPI, and which computer attributes you need.
- Check the SCCM version, the GLPI version and PHP and SQL Server driver prerequisites against your environment before work starts.
- Agree scope, deliverables and timelines in writing, since most engagements are fixed-scope.
How we build
- Install and configure the FusionInventory dependency and the SCCM plugin on your GLPI instance.
- Set up the SCCMCollect and SCCMPush automatic actions with database access and HTTP or HTTPS transfer tested end to end.
- Test sample computers and compare collected hardware and software fields in GLPI against SCCM records.
How we hand over
- Document the configuration, service accounts, automatic action schedules and the data mapping used for each asset field.
- Walk your team through troubleshooting for failed MsSQL queries, driver errors and rejected pushes.
- Record a clear decision on whether the SCCM plugin or GLPI Agent should remain the long-term inventory route.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that covers GLPI and plugin changes.
- Plan re-testing whenever GLPI, the FusionInventory plugin, SCCM or the SQL Server driver is upgraded.
- Confirm with your team who owns the sync after handover, including monitoring of the automatic actions.
