Extended support for the Microsoft Desktop Optimization Pack ended on 14 April 2026, and AGPM went with it. The final release was AGPM 4.0 SP3. There is no version 5 and no replacement from Microsoft, and the documentation is archived with a content date of 2017.
Microsoft’s own migration note points MDOP customers at Intune and Configuration Manager. Neither does change control over Group Policy Objects. Many organizations will continue to leverage Active Directory for years.
Why this lands harder in regulated industries
Most places treat a GPO as plumbing: a screen lock, a mapped drive, a proxy setting. In a bank, a hospital or a utility, the same object is often the technical implementation of a control related to privacy or security. Password length. Account lockout. Audit policy. Removable media.
So, the process around the GPO is part of the control. NIST 800-53 wants configuration change control (CM-3) and restrictions on who can make a change (CM-5). NERC CIP wants a documented baseline and authorization for anything that deviates from it. SOX ITGC testing and PCI DSS assessment come down to the same four things: the change was requested, somebody other than the person making it reviewed it, it was approved, and here is the record.
For a lot of organizations that record was AGPM.
Where it starts to bite
Unsupported software is testable in its own right. PCI DSS v4.0 requirement 12.3.4 asks for an annual review of the technologies in use, confirming each one still gets security fixes from its vendor. Anything end-of-life needs a documented remediation plan with senior management’s approval on it. “Our Group Policy change control runs on software that stopped getting security updates in April” is an awkward line in that review, and it gets worse the second year you write it.
The compatibility clock. AGPM is a GPMC extension on administrator desktops, talking to a server. Microsoft has made no commitment that it keeps working with future versions of Windows Server or its console. That tends not to surface as a security incident. It manifests as a server refresh that quietly can’t proceed.
Retention runs from the change, not from the product. Twelve months of audit log history under PCI DSS. Three calendar years of compliance evidence under NERC CIP. Six years of documentation under the HIPAA Security Rule. SOX puts no such obligation on the company itself, though seven years is what the external auditor keeps under SEC Rule 2-06, and most issuers match it. A change recorded in AGPM on its last supported day still must be producible well into the 2030s. In practice that means keeping the decommissioned server switched on to answer for the past: an unsupported system holding regulated evidence, indefinitely. Which is roughly where this started.
What to look for in an AGPM replacement
The archive is the constraint, not the feature list. Before anything else:
- The history has to come across: versions, the comments recorded against each change, the approvals attached to them. If the record restarts at cutover, the old server stays.
- Attribution has to survive. An approval only evidences separation of duties if it is still credited to the approver, not to whoever ran the import.
- Every step, not just the outcome. Check out, check in, submit, approve, deploy. A version number on its own doesn’t show that a process ran.
- It has to cover every domain, acquired forests and isolated networks included. The domains sitting outside the process are the ones that end up in findings.
Where UPA fits
Universal Policy Administrator runs the same controlled process (managed repository, editor and approver roles, check-out and check-in, version history, rollback) from a web console rather than a GPMC extension, across every domain including untrusted ones. AGPM versions, comments and history import with it, so the record carries on instead of restarting.
The deadline has gone. What is left is whether the next several years of Group Policy change control, and the evidence for it, run on an unsupported product.