In most organisations workstations are managed from two places: through Group Policy in Active Directory and through a separate endpoint management tool that installs applications, deploys patches and keeps inventory. Both mechanisms can change the registry, run scripts and enforce settings. Until somebody decides which one is responsible for what, sooner or later they start to fight.
What Group Policy does well
Group Policy is tied to identity: the user and the computer in the directory. It applies at system start and logon, with no agent, no extra licence, and precise targeting through organisational units and filters.
Natural areas:
- system security settings: password policies, user rights, auditing, the built-in firewall,
- everything that depends on identity: drive mappings, folder redirection, settings that vary by user group,
- a configuration baseline aligned with an industry standard,
- settings that must be in force before the user does anything.
Limitations: policies apply only when the computer can see a domain controller, so a laptop outside the office without VPN stays at its last known state. Software installation through Group Policy exists but is unfit for anything beyond the simplest cases. Compliance reporting is practically non-existent.
What an endpoint management tool does well
An agent-based tool works regardless of where the computer is, communicates over the internet, reports the state of every machine and allows remote action.
Natural areas:
- installing, updating and removing applications,
- operating system and third-party patches, with a schedule and a report,
- hardware and software inventory,
- remote actions: running a script, restarting, remote support,
- machines that are rarely or never on the corporate network.
Limitations: the agent is another component to maintain, the licence is a cost, and changes apply on the agent’s schedule rather than at logon.
The shared area and the conflict
Both mechanisms can set a registry key, deploy a script, change power settings or browser configuration. If Group Policy sets value A and the tool sets value B for the same key, the computer will flip between them at every refresh. The symptoms look random and the root cause takes a long time to find, because each administrator sees in their own console that their setting was applied.
The rule that solves it: every settings area has exactly one owner. Not “both can”, but “this is managed by Group Policy and that by the tool”.
A split that holds
| Area | Owner |
|---|---|
| System security, user rights, auditing | Group Policy |
| Identity- and group-dependent settings | Group Policy |
| Domain configuration (DNS, authentication, trust) | Group Policy |
| Applications: install, update, remove | tool |
| OS and application patches | tool |
| Inventory, compliance, reporting | tool |
| Machines outside the corporate network | tool |
| Registry settings and scripts | one owner per setting, recorded in documentation |
When a setting changes owner, remove it from the old mechanism first and only then add it to the new one. The reverse order guarantees a conflict during the transition.
Summary
Group Policy and an endpoint management tool do not compete. One manages what the computer is in the organisation, the other what runs on it. The conflict begins only when nobody has written down where the boundary lies.