A few months ago, I wrote an article explaining how you could use a group policy to deploy software applications to your users (http://www.windowsnetworking.com/articles_tutorials/Group-Policy-Deploy-Applications.html). Although that article addressed the basics of application deployment, space constraints didn’t really permit me to talk about the best practices for application deployment via group policy. In case you haven’t already figured it out, not every application can be successfully deployed through a group policy setting. Even if an application is designed in such a way that allows it to be deployed through a group policy though, there is a lot of room for things to go wrong. In this article, I want to share some techniques with you that will maximize your chances of a successful deployment.
The first best practice that I want to share with you is that you should prepare the application that you will be deploying prior to actually assigning it or publishing it. More specifically, if you plan on making any modifications to a Windows installer package, you must make those modifications prior to publishing or assigning the application. Otherwise, your modifications will be ignored. If you do find that a modified package is being ignored, then you will have to uninstall the application and remove it from being published or assigned and then re-publish or reassign the modified version. If you do accidentally deploy an application prior to modifying the installer, you can sometimes get away with deploying the modified application package and tricking Windows into thinking that it is an upgrade to the unmodified version as an alternative to completely removing and reinstalling the application that was deployed accidentally.
Use MSI Files Instead of ZAP Files
When you deploy an application through a group policy, the group policy editor requires you to specify the name of the application’s installation package. There are two different types of packages that you can use; MSI and ZAP.
MSI packages are always preferable to ZAP packages. MSI packages (Microsoft Software Installer packages) are the MSI files that you see included with all of the applications that Microsoft has released over the last several years. These files are also somewhat widely used by third party applications. MSI files are definitely the preferred mechanism for deploying applications, but since not every application comes with an MSI files, Microsoft allows the use of ZAP files.
ZAP files are basically just text files that you can create to act as an installation package for applications that don’t include an MSI package. Of course there is a reason why I said that MSI files are preferable to ZAP files. In many cases, an assigned application that is deployed via a group policy and that includes an MSI file can be self repairing. This means that if one of the application’s files is accidentally deleted from a user’s computer, the file can often be automatically replaced. If the application was installed through the use of a ZAP package though, the self healing mechanism can not be used.
There are a few other limitations associated with using a ZAP package to install applications. Applications installed using a ZAP package can not be uninstalled, and background installations are not supported.
Right now you might be wondering why I am bothering to tell you this. After all, most people would only go through the trouble of making a ZAP file if there is no MSI file available. The reason why I am telling you to use MSI files instead of ZAP files is because you can create your own MSI file. Traditionally, MSI files have been pretty tough to create unless you are a developer, but there are a few third party applications that can create an MSI file for your application through the use of diffing. The idea is that you install a clean copy of Windows onto a PC and then take a snap shot of the PC’s hard drive. You then install the application that you want to build the MSI file for and take another snap shot of the hard drive. The two snapshots are compared for differences, and an MSI file is created based on those differences.
If your company has an in house development staff, you are at an advantage. You should encourage the developers to create MSI files for any applications that they create.
Assign or Publish Applications in an Organized Manner
One of the toughest things about working with group policies in medium and larger sized companies is their hierarchical nature. Individual group policy objects can be assigned at the local computer, domain, site, and Organizational Until levels of the Active Directory, to form a group policy. What makes things even more complicated is that group policy objects can be applied to either users or to computers at any of the levels that I just mentioned. What this means is that there can be a whole lot of pieces that make up a group policy and there is a lot of room for confusion, overlapping, or contradictory policies.
As such, it is essential that you define software deployment policies in such a way that allow you to keep track of which applications are being deployed to which users or computers. It is also important for you to define software deployment policies in such a way that prevents them from overlapping.
This particular recommendation won’t work for every organization, but I have found it helpful to stick to publishing or assigning applications to either users or to computers, but not to both. Problems can sometimes result if an effective policy assigns or publishes an application both to the user and to the computer. That being the case, I usually try to only assign or publish applications to users. That way you don’t have to worry about the same application being assigned or published at the computer level. Of course there is no reason why you can’t publish and assign applications to both users and to computers, you just have to be careful if you do.
Another trick that you can use to help avoid confusion is to publish and assign applications near the top of the group policy hierarchy. Group policy elements are applied first at the local computer level and then at the domain, site, and Organizational Unit levels. If a contradiction occurs, then the setting in a higher level policy will override a setting from a lower level policy. For example, if a setting was applied at the domain level and then a contradictory setting was applied at the Organizational Unit level, then the Organizational Unit level setting would trump the domain level policy setting.
One way that you can take advantage of the way that group policies work and avoid confusion at the same time is to only publish and assign applications at a single level within the Active Directory (preferably the Organizational Unit level). Of course this brings up the question of how you control which users or computers applications are deployed to if you are only using a single location within the Active Directory to define application deployment related policies.
I don’t really recommend using this trick for other types of group policy settings, but it tends to work pretty well for application deployments. A lot of people don’t realize it but, group policy elements actually have access control lists associated with them. You can use these access control lists to control who an application is and is not made available to. For example, pretend that you published an application at the Organizational Unit level and that in doing so, the application was made available to everyone. Let’s pretend though that you don’t have enough licenses to be able to deploy the application to everybody, so you want to prevent the application from being rolled out to the Accounting department. To accomplish this, you could right click on the listing for the published application and select the Properties command from the resulting shortcut menu. You could then select the Security tab and use the Access Control List that it contains to prevent the policy from being applied to the Accounting department.
The Access Control List for a group policy element doesn’t actually control who has access to the software that’s being deployed. Instead, it controls who has the ability to read or to modify that particular policy element. Therefore, if you remove the Read permissions from the Accounting group, then that group will be unable to read the policy element that publishes the application, and the application will therefore not be made available to members of that group.
As you can see, using group policies to deploy application can be a huge time saver over deploying applications manually. Even so, you must be careful to design your group policies in a way that will prevent contradictory or overlapping policies from causing problems on your network.