Tuesday, February 14, 2012

How to ... Handle Application Deployment GPOs

A few times per month, I'm being asked if the customer should use one GPO for all their Application Deployments or one GPO's for each deployment?

As with almost everything in life, it depends... And both ways got pros and cons. And of course, there is a middle way, where you have a couple of GPO's with all your deployments in.

I've seen environments where they have had thousands of GPO's in the AD. And where they have totally lost control and don't really know which GPO is linked where and what it contains.
These customers usually tend to lean toward also using one GPO per Deployment.
I think it creates a false feeling of control and a lot of extra administration to do it that way.

First of all, using that many GPO's is usually an old inheritance. Somewhere it got out of control and it's too much work to consolidate the GPO's so they just keep on working like that, adding more and more GPO's.
Using one GPO per Deployment might have been how they have handled Application Deployments with the built in Group Policy Software Installation (GPSI) engine so they could filter the GPO on Security Groups and control which clients got the app.
But it's not needed in Specops Deploy, since we can use Targets inside the GPO. Meaning, a customer can basically link the Specops Deploy Application GPO to the Root of the Domain and handle all Deployments with one GPO. (I wouldn't recommend anyone to really link it to the Root, but rather to the OU's.)

The pros of using multiple GPO's for Deployments is that it's easy to control who the GPO is applied to and it will reduce the risk of corrupted deployments (more on that later).
Also, by using a lot of GPO's and security filtering, it's possible to reduce the number of GPOs (and targets) the client has to process.
The cons is that it causes a lot of administration. It's hard to get a good overview of your deployments.
And when you want to look at the Feedback, you have to open multiple GPOs so see it, takes time.

One GPO to Rule them all ... This is usually what I recommend. It gives you the full power of Specops Deploy. You have one place where you work with your Deployments, you can reuse your Targets and don't have to create new ones in each GPO. It's easy to see the Deployment Feedback.
And from my point of view, it gives best control.

Using just one GPO's when you have several hundred targets and thousands deployments in one GPO will cause all your clients in the environment to process all those Targets each time the computer boots and also each GPO.
Which in our testing is still not slower than dividing the settings into multiple GPO's. Because, loading a new GPO is generally slower than processing our targets.




But, having one GPO can cause an administration problem. As you know, with GPO's its the last write who wins. So if two or more admins are editing the same Specops Deploy GPO, it can become corrupted. Having more than one GPO will reduce that risk.
If you have a license for it, using Microsoft Advanced Group Policy Management (AGPM) will make it possible to have just one admin working on a GPO at a time. So the corruption problem will not happen.


Alternatively using 2-4 GPOs will also reduce the risk of two admins working on the same GPO at the same time. For example, divide the apps into 4 GPO's Microsoft, Adobe, Line of Business, Other



No comments:

Post a Comment