AGPM Operations (under the hood part 2: check out)
Published Apr 04 2019 05:14 PM 988 Views
First published on TechNet on Apr 04, 2011

Sean again, here for Part 2 of the Advanced Group Policy Management (AGPM) blog series, following the lifecycle of a Group Policy Object (GPO) as it transitions through various events. In this installment, we investigate what takes place when you check-out a controlled GPO.

Before editing an AGPM controlled GPO, it is checked out. There are several potential points of failure for the check-out procedure. Network communications during the backup can drop, leaving the Archive copy only partially created. Firewall rules can block network traffic, preventing the AGPM client from contacting the server. Disk corruption can cause the Archive copy of the GPO to fail to restore. We use the same tools to collect data for these blog posts and to troubleshoot most issues affecting AGPM operations.

In Part 1 of this series ( Link ) we introduced AGPM and followed an uncontrolled “Production” GPO through the process of taking control of it with the AGPM component of the Group Policy Management Console (GPMC). If you are unfamiliar with AGPM, I recommend you refer to the first installment of this series before continuing.

Environment Overview:

The environment has three computers: a domain controller, a member server, and a client.

  • CONDC1 : Windows Server 2008 R2 Domain Controller

  • CONAGPM : Windows Server 2008 R2 AGPM Server

  • CONW71 : Windows 7 AGPM Client

For additional information regarding the environment and tools used below, please refer to Part 1 of this series ( Link ).

Getting Started:

We start on our Windows 7 computer logged in as our AGPM Administrator account (AGPMAdmin). We need GPMC open, and viewing the Change Control section, which is the AGPM console. We are using the “Dev Client Settings” GPO from the previous blog post, so let’s review the GPO details.

  • The GPO GUID : {01D5025A-5867-4A52-8694-71EC3AC8A8D9}

  • The GPO Owner : Domain Admins (CONTOSO\Domain Admins)

  • The Delegation list : AGPM Svc, Authenticated Users, Domain Admins, Enterprise Admins, ENTERPRISE DOMAIN CONTROLLERS and SYSTEM

We also log into the AGPM Server and the Domain Controller and start the data capture from each of the tools mentioned previously.

As with most actions within AGPM, checking out a GPO is a simple right-click and select operation. Right click the “Dev Client Settings” GPO to bring up the context menu and select the “Check Out…” option.

Notice the grayed out “Edit” option for a checked in GPO. AGPM prompts for comments from logged on accounts with the AGPM Admin or Editor role delegated. Clicking “Ok” displays a progress window that updates us as the AGPM server request is processed. When it is complete, we return to the AGPM console and see the changed status.

Notice how the AGPM console differentiates between a "Checked out" GPO, and one that is "Checked in". The icon has a red outline, and the “State” column updates. The “Comment” column displays the comment entered during the most recent operation on the GPO; it is useful to add relevant information to the comment whenever possible.

Let’s look at the data we’ve collected for the Check-Out operation.

The AGPM Client

Network Monitor shows the AGPM Client and AGPM server communications. TCP port 4600 is the default for the AGPM server; this is configurable during the installation or afterwards ( Link ).

Process Monitor on the AGPM Client highlights the simple nature of the work done by the AGPM Client itself during the Check-Out procedure. The MMC process accesses gpmctabs.dll to generate the AGPM console, followed by access to agpm.log to write entries related to the communications between the AGPM Client and Server.

There were several entries in the GPMC log ( gpmgmt.log ) pertaining to the opening of the GPMC.msc snap-in, and looking up each of the accounts defined in the delegation tab for the GPOs. There were no entries in the log during the time of the Check-Out operation, however.

AGPM Logging shows the exact same block of entries that we saw when taking control of a production GPO.

This log only shows entries related to the client establishing a connection with the AGPM server and sending it the instruction “ExecuteOperations()” and that the instruction has been completed.

The AGPM Server

Since we focused on the traffic between the AGPM Client and Server in the section above, we now examine the traffic between the AGPM Server and the Domain Controller. The first thing we notice is a lot of SMB traffic with the AGPM Server regarding a policy GUID that is different from that of the GPO we are checking out.

A search of the network trace for the “Dev Client Settings” GPO {01D5025A-5867-4A52-8694-71EC3AC8A8D9} turns up nothing. A quick refresh of GPMC.msc shows a brand new GPO in the list.

There are several important bits of information in the screenshot above. First, notice the name of the GPO “[AGPM] Dev Client Settings”. The GUID is the one we see in the network trace. Notice the "Created Date/Time": it's the “Dev Client Settings” GPO check-out time. The GPO is not linked anywhere, the GPO history does not match that of the GPO it shares a name with and the Delegation list shows full control granted to the account that checked it out. From here on, we refer to this GPO as the “Offline GPO”.

Within the network trace, we see the request to create the policy GUID folder in SYSVOL.

AGPM takes the same action to create the rest of the policy folder structure and contents. Security is set on these folders as well.

The AGPM Server log ( agpmserv.log ) shows the entries related to the process it goes through "IAgpmServer.SendMessage()" to send the appropriate messages along to the Domain Controller to perform the actions we’ve requested via the AGPM console.

Process Monitor shows entries that confirm its writing to the Agpmserv.log file. It retrieves the registry path to the AGPM Archive and we access gpostate.xml (located within the Archive). As mentioned in the first blog post, gpostate.xml contains a historic view of GPOs known to AGPM.

It reports gpmgmt.log access within Process Monitor as well. It’s important to note the user account in the path. The security context of the account that is performing the actual GP management work is the one logging all of the entries.

The AGPM Server accesses the Archive path and copy the GPO folder and contents to a path beneath the Archive’s Temp folder.

Next, we see the creation of the “Offline” GPO path in SYSVOL. GPMC builds out the new GPO based on the information copied from the AGPM Archive.

The gpmgmt.log created in the AGPM service account’s profile path shows the process taken to build the new GPO folder from the AGPM Archive copy. The log addresses each aspect of the GPO, from assigning security to configuring the GP settings. The process looks like a GPO Restore.

The Domain Controller

Looking at the network capture on the domain controller shows very little from the client (CONW71). SMB protocol negotiation, session setup and connection from the client to the DC’s IPC$ share are shown. We reviewed the network traffic from the AGPM server earlier in this post.

The DC security log shows several "Security-Auditing” 5136 events generated by the creation of the Offline GPO.

Editing the GPO

We now see what has taken place during a controlled GPO Check-out. Let’s modify the GPO slightly, adding a setting or two. On our AGPM Client (CONW71), right clicking on the checked-out GPO brings up the context menu, and the “Edit” entry is now clickable.

Notice the two new entries to the context menu, “Check In…” and “Undo Check Out…” We’ll come back to those in a bit. Editors and Administrators alone hold the ability to edit a GPO controlled by AGPM, so if we see the option still grayed out on a checked-out GPO, we need to make sure we have the appropriate permissions within AGPM. There is no prompt for comment within AGPM when editing a GPO. Windows 2008 and later allows us to comment at the GPO level as well as at the setting level (within Administrative Templates), if we need to. With the Group Policy Editor started, we can use it to make changes to the checked out GPO.

If we decide to check the GPO back in without saving any changes, we can select “Undo Check Out…”. This simply deletes the Offline GPO created during the Check-Out procedure, and removes the reference to it in gpostate.xml .

In Closing

In this second installment, we covered a procedure repeated every time there’s need to modify a GPO within AGPM. During the Check-Out of a GPO, the following steps are performed:

  • The Archive copy of the GPO is copied to a temp folder.

  • From the duplicated Archive data, a new “Offline” GPO is created with the [AGPM] prefix by performing a GPO Restore.

  • The GPOs entry within the Archive’s gpostate.xml file is updated to reflect its checked-out state, and references the newly created “Offline” GPO.

  • Once the Check-Out procedure is complete, the temp copy of the Archive data is deleted.

  • The “Offline” GPO is not linked anywhere, and edits to it are made in real-time.

From this information, we can make an important observation: any changes made to an AGPM-controlled GPO outside of the AGPM console (i.e. the rogue Domain Admin that doesn’t bother with the AGPM console and edits the GPO directly through GPMC.msc ) are overwritten the next time the GPO is deployed from the AGPM console. Since the Check-Out procedure builds the editable “Offline” GPO from the AGPM Archive data, the Admin’s changes are not included automatically. We do have the option of using the “Import from…” feature to pull the settings from the production GPO again prior to the Check-Out, which updates the Archive data with any changes made outside of AGPM.

Come back for Part 3 of this series, where we will check our GPO back in.

Complete series ...

Sean "To the 5 Boroughs " Wright

Version history
Last update:
‎Apr 04 2019 05:14 PM
Updated by: