Application lifecycle management has always presented a special challenge for network administrators.
Admins face a number of tasks, such as deploying applications, removing obsolete ones, ensuring that everyone has the correct version of each app and that users don't damage apps or remove them from their workstations. Administrators have traditionally had two choices: performing these tasks manually or investing in expensive application management software.
Using application management software is the easiest way to maintain apps, but it typically carries a hefty price tag. Even if your company lacks the budget to invest in such application management software (or if your boss is just a cheapskate), you're not completely out of luck. You can configure a Group Policy in a way that will allow applications to be deployed and maintained by the Active Directory. This three-part series will show you how.
Group Policy-based application management is not an exact science. No matter what Microsoft's marketing department might tell you, not every application can be deployed or maintained through a Group Policy. Over the past few years, Microsoft has pushed developers to design their applications in a way that makes use of a standardized Setup program.
This goes a long way toward making more applications compatible with Group Policy, but, even so, there are still apps out there that can't be installed using the techniques I'll be showing you. Sometimes you can massage the application a bit by creating a custom MSI file or by relying on a few other tricks. But, often, there's nothing you can do.
Publishing and assigning applications
The first thing you need to know is the difference between publishing and assigning applications. Publishing an application means that you are simply using a Group Policy to make that app available to users. The act of publishing an application in and of itself does not actually install the app, but rather makes it accessible so the user can install it from the Add/Remove Programs applet in the control panel. Furthermore, applications can only be published to users, not to computers.
Assigning applications is a bit trickier. You can assign an application to either a user or a computer. When you assign an application, you are not giving the user the option of installing it. You are making the installation mandatory. . .well, sort of.
Funny thing about assigning an application. Even though you have created a Group Policy that basically tells Windows that the specified application is mandatory for a user, the app doesn't actually install until the first time a user attempts to use it. Why does Microsoft do this? If you created a Group Policy that dictates a mandatory software installation, the demand that hundreds of simultaneous app installations would place on the server could bring it to its knees. (Never mind the impact on your network's bandwidth.)
To prevent such problems, the Group Policy installs just enough of the assigned application so that it appears on the Start menu. Windows, then, is able to recognize the file extensions associated with it. (This is generally how the process works. There are always exceptions.) When users attempt to open a file associated with the application, or when they select the app from the Start menu for the first time, the Group Policy installs the rest of it (or at least the components that are needed at the moment).
Although an application is generally not installed until the employee tries to use it, there are exceptions. If you assign an application to a computer rather than to a user, the app does get fully installed, regardless of whether a user ever tries to use it or not. Furthermore, if you assign an application to a computer, a user can't uninstall it unless he has the necessary privileges. If you don't like the idea of users messing around with the applications on their machines, this is an option worth considering.
Getting started
Before I discuss how to actually create an application deployment policy, there are a few things you need to know. Since assigning or publishing applications is done through Group Policies, you must keep in mind the hierarchical nature of Group Policies and consider to whom the policy will ultimately apply. Unless everyone in your organization uses the exact same set of applications, you will have to do some planning before you deploy your first app. That way, you'll be sure that the apps are deployed to the correct users and computers. Making a mistake could cause users not to receive an application that they need to do their jobs. Even worse, a reckless deployment might give apps to users who should not be using them, resulting in a potential security risk and exposing your company to software licensing violations.
To deploy an application through a Group Policy, the application must have a supported installation file. The preferred way of deploying an application involves using a Microsoft Software Installer (MSI) package. Applications that rely on legacy Setup files can still be used, but not by themselves. You will have to either create an MSI file for the application or else create a ZAP file.
A ZAP file is similar to an MSI file, but it is used only with older applications and has some limitations. Applications installed using ZAP files can't be uninstalled. Nor can you install them in the background. Unlike assigned applications that were installed through an MSI file, those installed via ZAP files are not self-repairing. For these reasons, I don't recommend using ZAP files. Granted, not every application comes with an MSI file, but you can make your own MSI files fairly easily. Part three will explain how to do this.
Regardless of whether you are publishing or assigning an application, you will need a software distribution point. Software distribution points can be a science all their own, but they don't have to be overly complicated. The basic requirement for a software distribution point is that you copy the application that's being installed to a share on your network, one that your domain controllers and the recipient users or computers can access. That's it. You can get fancy with permissions, redundancy and using distributed file systems, but you don't have to.
Lots of planning has to go into an application deployment based on Group Policy. You can perform many network administration operations without bothering to do any prep work. Group Policy-based deployments are not one of these areas. If you take only one thing away from this article, let it be this: Without proper planning, you can really shoot yourself in the foot.
This tip originally appeared on SearchWinSystems.com.
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies.
