Best practices for a stable AGPM deployment

Over the years I have worked a lot with Advanced Group Policy Management (AGPM), our solution for change management of Group Policy. This small tool is part of Microsoft Desktop Optimization Pack (MDOP). AGPM has always flown under the radar, but is deployed in surprisingly many enterprises. By reviewing and troubleshooting some of these deployments I have picked up what works well, and what does not. In this blog I want to share some pointers on improving AGPM deployments.

AGPM does not use the PDC

Let's start with a big one. If you know your group policy, you will be aware of the special role of the PDC role: it is targeted as the default Domain Controller for editing Group Policy. This means that when you start the GPMC or the GP Editor, they will look at the PDC for reading and writing GPO. Most (not all) Client-Side Extensions (CSE) such as the Admin Templates, Security and others also play nice with this convention. However, AGPM does not honor the convention of using the PDC emulator when reading or writing GPOs. Instead, it relies on the default DCLocator behavior and will simply select the closest DC, usually one in its own site. Problem? You bet.

Suppose you are editing a GPO that is managed with AGPM. Also, assume that the AGPM server is deployed in a site with significant replication latency to the site with the PDC. You start the edit cycle with a check out of a GPO, so AGPM will push a copy of the GPO to its own site. If you try to edit the GPO immediately after the checking out, it will not have replicated to the PDC yet, or perhaps only partially. You might see no GPO at all, or an empty one, or worst case: a corrupted one! Variations of this theme happen on check-in or GPO redeployment.

Fortunately, we have an obvious but partial solution: make sure the AGPM server shares the same site as the PDC. This minimizes replication latency to the PDC. Why is it partial? Because AGPM might still pick another DC in the same site instead of the PDC itself, leaving room for replication latency issues. Still, it's much better than having the AGPM server associated with another site.

But what if the AGPM server is physically in another location than the PDC emulator? Then we can still solve it by using a little trick: we use a /32 subnet to hardwire the AGPM server to the site of the PDC:

1. In AD Sites & Services, create a new subnet with the IP address of the AGPM server.
2. As a netmask suffix, use /32
3. Link the subnet to the site containing the PDC emulator
4. Add a comment to the effect that you are hardwiring the AGPM server to the PDC site.

It might look as follows:

AGPM does not like FRS

We have seen that AGPM depends on SYSVOL replication, and that the faster replication is, the better your AGPM experience will be. Actually, AGPM depends on AD replication as well because a GPO has both an AD and a SYSVOL component but let's leave that be for now. The old-school FRS mechanism is dead slow compared to DFS-R. So, if you still have your Domain running on FRS, it's time to migrate it to DFS-R, as I have blogged before.

However, even if you are running DFS-R already, you still may have occasional errors and problems. Due to the rate of change that AGPM pushes on SYSVOL when checking out or deploying, DFS-R might run into problems. Most of these have been fixed, but to benefit from these fixes you still need to deploy the latest versions of the DFS-R binaries. If you are on Windows Server 2016 or 2012 R2 and have kept up with update rollups, you are probably fine.

But, if you are on Windows Server 2008 R2 SP1 with original binaries, you really want to upgrade. For this reason and many other fixes, please deploy the Convenience rollup update for Windows 7 SP1 and Windows Server 2008 R2 SP1.

AGPM likes to control all GPOs

The biggest reason why AGPM deployments fail is actually not a technical one. It's process related. Imagine that you have 500 GPOs, of which 450 are controlled by AGPM, and 50 are not. You need to edit a particular one, but before you can do that you first need to know if you need to go through AGPM or not. The only way to know is look in AGPM, even if the GPO is not controlled there. Admins tend to get tired of this confusion pretty fast, and resort to editing GPOs outside of AGPM all the time. This causes the AGPM archive to become outdated compared to production. This is a significant hazard in itself: what happens if someone deploys an outdated GPO from the AGPM archive, and overwrites the current production GPO? You need only one or two incidents like that before someone decides to get rid of APGM altogether.

Again, a simple solution: get buy-in to manage really all GPO's in the domain using AGPM. If you can't get this buy-in, don't deploy AGPM. Believe me, I have seen enough of this. The only two policies that you might want to leave out for security reasons are the two built-in policies: Default Domain Policy, and Default Domain Controller Policy.

Having all GPOs in AGPM has an additional advantage: it can be used as the single backup solution for GPO, including versioning, history, and change rollback. This does require that the AGPM server itself has a backup.

Locking down Domain Admins is good for AGPM

By default, Domain Admins can edit GPOs without using AGPM. While convenient, this can cause a lot of problems as outlined in the previous section: outdated archives. For this reason, I usually recommend giving Domain Admins read-only access on all GPOs. Of course, this means nothing from a security perspective because Domain Admins can reset the permissions and do as they please. However, it prevents accidents and would take a deliberate action from an admin to edit a GPO outside of AGPM. A PFE colleague has blogged about this before:

• https://blogs.technet.microsoft.com/askds/2011/06/21/forcing-domain-admins-to-use-agpm-but-not-really/

Have a look, and take from it what you need. It shows how to stop Domain Admins from accidentally creating and deleting GPOs as well. Personally, I'd not go as far to stop Domain Admins from linking GPOs to OUs or to the domain.

AGPM should always have the latest version of all GPOs

As you have seen, you are asking for problems when a currently deployed GPO is more recent than the AGPM archive version; if you would deploy the GPO from the archive, it would overwrite the production version with old data. There are multiple reasons why the AGPM archive might be outdated:

• You changed the GPO security filtering
• You added or removed a WMI filter
• You did an emergency change outside of AGPM
• You had to restore the AGPM archive
• You restored a GPO outside of AGPM
• etc.

There are two questions here:

1. How do I know that the AGPM archive is outdated? Answer: have a look at an older blog of mine: Find out if your AGPM archive needs updating. This blog has a reference to a script that will show you exactly which GPOs are at risk by comparing timestamps of the archive with AD.
2. How do I recover and make sure the AGPM archive is up to date? Answer: for each affected GPO, you do an Import from Production. See the following screenshot in case you have not done this before.

Keep up with the latest AGPM version

AGPM is in maintenance mode, and bugs do get fixed. The current version (December 2017) is AGPM 4.0, Service Pack 3, Hotfix Level 3. While AGPM has both a client and a server part, it's the server part that does the work. So please prioritize the AGPM service when upgrading AGPM. If AGPM is not doing what it should, execute an in-place upgrade first. Do read the documentation; you may have to install a newer version of the .NET platform.

Specifically, if you want to use AGPM to control GPOs for Windows 10 or for Windows Server 2016, you do need to run the MDOP 2016 version or later.

Comments

• Anonymous
  December 11, 2017
  Great post
• Anonymous
  December 11, 2017
  Do you have a link to the current version?
  • Anonymous
    December 13, 2017
    Hi Anthony,You can get the download from the SA section on the Volume License Service Center, for which you need a corporate account. Alternatively, get MDOP 2015 from MSDN, and upgrade it with the latest public hotfix as documented here: https://blogs.technet.microsoft.com/389thoughts/2016/10/26/hotfix-2-for-agpm-4-0-sp3-allows-you-to-keep-custom-read-permissions/
    • Anonymous
      December 13, 2017
      Oh I already use MDOP but you mention the current version (December 2017) is AGPM 4.0, Service Pack 3, Hotfix Level 3. Where can I find that online. I can only seem to find the September 2017 release.
      • Anonymous
        December 13, 2017
        There is no new release for december. I just meant to say that this is the current state of affairs in december 2017 should any people read this blog years from now. The public download for the servicing release is here, by the way: https://www.microsoft.com/en-us/download/details.aspx?id=54967.
        • Anonymous
          December 14, 2017
          Ah. Thank you!
• Anonymous
  December 13, 2017
  I was told AGPM does not function when using multiple forests. A colleaque said Microsoft confirmed. I wonder if you have seen different?
  • Anonymous
    December 13, 2017
    You were told correctly. The scope of AGPM is a single forest; this is similar to the GPMC itself. You can use AGPM for multiple domains in a single forest, although you have to set some custom permissions.