Group Policy Application Deployment Done Right
In this article I’ve outlined what I recommend for best utilising Group Policy to deploy applications. Deploying applications via Group Policy is a fairly straight-forward process, if a little limiting, however if you don’t do it right you could be setting yourself up for some pain down the track.
Successfully deploying applications with Group Policy requires a solid base in Active Directory. There are a few things you’ll need to ensure are in place and working correctly before you start. These include:
- Active Directory;
- DNS; and
- Distributed File System (DFS).
Active Directory
Of course the first thing you are going to need is Active Directory and there are two components of Active Directory that should be configured before you start looking at Group Policy.
1. Sites and subnets. If you haven’t configured your sites and subnets you must look at these. I’ll discuss why in more detail when I get to DFS. You should create a site and corresponding subnets for each physical subnet or subnets that are well connected. Well connected can mean different things to different organisations, but a site should define those subnets where you can afford to distribute applications. If you can’t handle deploying traffic between specific subnets, divide them into separate sites. Also create sites for subnets even if you don’t have domain controllers at those sites.
2. Organisational Units. One of the differences between a good Group Policy implementation and a great one is organisational unit structure. Judicious use of organisational units will allow you to reduce the number of Group Policy objects or links you require.
I have three main rules that I apply to OU structure:
- Justify the creation of each OU. You should have a good reason for creating organisational units.
- Keep organisational units to no more than three levels deep.
- Limit the use of block inheritance.
Organisational unit structure will differ for every organisation, however if you apply these guidelines to application deployment, here’s all that you need to create:
. This can be a problem if you want to move your application source files or have an unrecoverable issue with the server on which they are located. If you remove the application and add it again from a new path, the application will be redeployed (and in some cases be removed before redeployment).
How do we get around this? Distributed File System. DFS provides a path that will always be static while the real path points to an actual share on a server. This allows us to deploy applications from a DFS path and if we need to change real path we can do so without touching Group Policy or affecting the applications at all.
Another great thing about DFS is that you can take advantage of your AD sites - DFS is site aware. If you have a copy of your application share close to your workstations they will pull the installation from a local server rather than across a WAN link. For example, if we have a DFS path \company.localPublicApplications that points to \SERVER1Apps at site A and \SERVER2Apps at site B, workstations at site B will connect to \SERVER2Apps when Group Policy is applied to deploy applications.
