A quick post regarding the new release beta release of AGPM 4.0 SP1
It is a part of the MDOP pack, along with Dart, MED-V, App-V, MBAM.
But what does it do? The name AGPM stands for Advanced Group Policy Management. It gives you an extension of the existing Group Policy Management and adds more features. Today if you want to create or edit a policy, well then you either have access to the policy or you don’t. And if youre not sure if your policy will work, wouldn’t you like to get a senior administrator to take a look at it before you deployed it?
And what if someone altered a policy, didnt take a copy before he/she altered it and you have no idea what was in the previous policy?
All of these problems are adressed with AGPM.
The features included are:
If your central store is offline you have no way to edit your policies, since AGPM stores its policies in another sentral archive you can still edit your policies.
As I said before AGPM is just an extenstion to the group policy management console. Some people might be a bit confused and try to look for a AGPM console 🙂
In a typical ITIL world, no changes will be done unless they are approved by the «Change Manager» So AGPM adresses this issue by creating different roles where 1 can edit and request and another can approve the policies.
You have the ability to grant administrators different functionality within AGPM, either they have the full access, approval access, editor access, or reviewer.(Look at the different roles further down the post.
And yes you can use AGPM to control polies in different forests.
Overview of the services and roles:
AGPM Client: A computer that runs the AGPM snap-in for the Group Policy Management Console (GPMC) and from which Group Policy administrators manage GPOs.
AGPM snap-in: The software component of AGPM installed on AGPM Clients so that they can manage GPOs.
AGPM Server: A server that runs the AGPM Service and manages an archive. Each AGPM Server can manage only one archive, but one AGPM Server can manage archive data for multiple domains in one archive. An archive can be hosted on a computer other than an AGPM Server.
AGPM Service: The software component of AGPM that runs on an AGPM Server as a service. The service manages GPOs in the archive and in the production environment in that forest.Archive: In AGPM, a central store that contains the controlled GPOs that the associated AGPM Server manages, in addition to the history for each of those GPOs. This includes all previous controlled versions of each GPO. An archive consists of an archive index file and associated archive data that may include data for GPOs in multiple domains. An archive can be hosted on a computer other than an AGPM Server.
Controlled GPO: A GPO that is being managed by AGPM. AGPM manages the history and permissions of controlled GPOs, which it stores in the archive.
Uncontrolled GPO: A GPO in the production environment for a domain and not managed by AGPM.
AGPM comes with 4 access roles.
- AGPM Administrator: Gives the user full control and permission to delegate permissions to other Group Policy administrators.
- Approver: Group Policy administrators assigned the Approver role can deploy GPOs to the production environment for a domain. Approvers can also create and delete GPOs and approve or reject requests from Editors. Approvers can view the list of GPOs in a domain, view the policy settings in GPOs, and create and view reports of the policy settings in a GPO. They cannot edit the policy settings in GPOs unless they are also assigned the Editor role.
- Editor: Group Policy administrators assigned the Editor role can view the list of GPOs in a domain, view the policy settings in GPOs, edit the policy settings in GPOs, and create and view reports of the policy settings in a GPO. Unless they are also assigned the Approver role, Editors cannot create, deploy, or delete GPOs. However, they can request that GPOs be created, deployed, or deleted.
- Reviewer: Group Policy administrators assigned the Reviewer role can view the list of GPOs in a domain and create and view reports of the policy settings in a GPO. Unless they are also assigned the Editor role, they cannot edit policy settings in a GPO.
So how does a typical request go forth here?
User 1 is Editor
User 2 is a Approver
User 1 requests a new policy named «Test» send it to for approval. User 2 Approves the policy, and the policy will be created in the archive. User 1 then checks out the policy from the archive and starts editing the policy. When user 1 is finished with the policy he checks it in to the archive again, a send a request for approval to deploy the edited policy. User 2 again goes inn and approves the request and the policy is applied.
Now first we can download the beta client from connect.microsoft.com
This basicly contains a client and a server. For the purpose of this post, we will install both these roles on the same server.
NOTE: If you don’t have Group Policy Management Console installed, the installer will take care of this for you( And also installes other prerequistes as needed )