Tech & Work

How to avoid obstacles when distributing software with Group Policies

One of the most useful aspects of Group Policies is the ability to distribute software to users. However, using Group Policies for software distribution isn't easy. Here are some common obstacles you'll face and how to overcome them.


Using Group Policies is a powerful strategy for managing the configuration of a client. Organizations can use Group Policies to enforce configurations on their client machines. But in most cases organizations have not tried to use Group Policies to distribute software to end users. Although there are limitations to deploying software with Group Policies, it is an effective tool for those who have not yet purchased or installed a software management tool such as Microsoft's SMS.

Although Group Policies software distribution is a substantial leap forward for those without software distribution, using Group Policies to distribute software does have limitations. Knowing those limitations and how to deal with them will make software distribution via Group Policies more effective in your organization.

Multisite distribution
Group Policies software distribution relies upon a single UNC name from which each package is delivered. This creates problems in multisite organizations where delivering from a single server might mean an excessive delivery time for some packages.

You can use the Distributed File System (DFS) included in Windows 2000 to create a single DFS share, which is referenced by Group Policies for delivery from the packages. However, DFS is problematic in most environments because clients often don't pick the correct server to talk to. If you are talking about small files, such as corporate Word templates, the issue of whether or not the right server is chosen is trivial. However, with software distribution the files sizes are much larger. If a client chooses the wrong server from the DFS root, it could seriously impact the speed of the installation and the entire network because the requests will have to be rerouted by DFS across the network.

DFS also creates the problem of synchronizing content between the various servers in the DFS share. Although there is a replication built into DFS, it does not work well with large amounts of data. The end result of all of this is that even though it is technically possible to use Group Policies software distribution with one master DFS root in a multisite environment, it is difficult to get it right. It is, however, possible to create a separate set of software distribution Group Policies on each site. While it takes more time to setup, it does guarantee that the correct server will be chosen.

Publishing applications vs. assigning applications
There are two different ways that software can be distributed to client machines with Group Policies. The first way that software can be distributed is through published software. Published software is not actually installed on the client computer until a user requests the installation. The user goes to the Add/Remove Programs tab and can choose from a list of published applications. You would use published software when the software is not required but is available to the user if they want it. For instance, let us say that your organization has a loan calculator application that some of your users like to use—and others do not. If the loan calculator is published, then users who want to use it can install it themselves.

The other way of distributing software is to assign the software. When software is assigned it is installed on the machine without user intervention. Once the Group Policy is applied, the software will be installed without asking the user. The key aspect of this is that the Group Policies must be applied to the computer. In practical terms, this means that the client must be rebooted. In situations where the users shut down their computers each night there is no problem, however, for those organizations that instruct their users to leave their machines on at night, this might be a problem. You will have to devise a way to reboot their systems for them. Alternatively, you can force Group Policies to be reloaded during the logon script to force any non | applied Group Policies to be applied.

Assigning software can only be done for a computer; it cannot be done for a user. This means that the Group Policy where you publish the software from must be set such that the computer policies are applied. If you accidentally—or purposefully—disable the application of the computer components of the policy, the software distribution settings for assigned software will not be applied.

MSI required
Technically, Group Policies software distribution has the ability to distribute both MSI files and a special text description file called a ZAP file. However, there are two key reasons why you should only use Group Policies software deployment to only deploy MSI files. MSI files are Windows Installer files. These files are processed by the Microsoft Installer service.

MSI files are the only files that can be delivered as assigned packages. In addition, MSI files are installed with the privileges of the Microsoft Installer service, typically the local system account. The implication of this is that even regular users can install software that requires elevated privileges if it is an MSI file. This is not true of the other kinds of files that could be distributed by Group Policies.

In addition, MSI files are simply a better choice because MSI files can have built into them features like automatic application healing and installation on first use; these features are not available for ZAP files.

Network performance
Another limitation of Group Policies software distribution, particularly with assigned software, is that it installs when the Group Policies are applied. This is typically first thing in the morning as the users all sit down to work within a few moments of each other and all try to log into the server at the same time. If there are larger software packages being delivered, such as a service pack, a substantial or even excessive amount of network bandwidth can be consumed by the software delivery. When considering the delivery of software through Group Policies, consideration should be given to the impact that the software deployment can have on your network.

Considering the impact to the network and the needs of the users, it might make more sense if you asked the users to reboot their computers before they leave for the evening and allow the computers to run all evening. Of course, not every user will take the suggestion to reboot their system before they leave; however, if enough of them do remember, it will substantially reduce the amount of load on the network in the morning when they come in and turn their systems on.

Network shares
Before establishing the Group Policies to deliver the software, you will need to locate the software somewhere on the network where the users will be able to access it easily. Most network administrators have created dozens of shares so this step is not particularly intimidating.

However, when creating most shares the default security for the share and the security already configured on the folder are sufficient to allow access. Since the software, if assigned, will be installed from the local system account of the machine that the software is being deployed to, the default for the share will not work. By default a share allows Everyone full access to the share. Because a computer object cannot be a member of the Everyone group, the share won't work.

In creating the share, you must add the Computers group with at least Read permission to the share and to the directories and files that make up the software being distributed. Once these two settings are in place it becomes possible to assign software to a workstation as well as publish it to a user or workstation.

Broken installations
Occasionally, you will think that you have everything set up correctly and yet when you go to a workstation you will not find the software installed on the machine. This can happen for three basic reasons:
  • The Group Policy was not applied.
  • The share the Group Policy referenced was not available.
  • The software refused to install on the operating system.

There are a few reasons why a Group Policy might not be applied to a workstation, which will prevent your software from installing. The first potential cause is that the Group Policy has not been replicated to all of the servers yet and the server that processed the logon for the computer did not have the Group Policy yet. You can always go into Active Directory Sites And Services (Start | Programs | Administrative Tools | Active Directory Sites And Services), expand the sites folder, the site name of your local site, servers, the server that you updated, and then click on NTDS Settings. From there you can right-click each of the settings on the right-hand side of the console and select Replicate Now from the context menu. This will force replication to happen immediately. You have the option of doing this only for the servers you believe are likely to service the request or for every server in the local site.

The second potential cause is that the computer attempted to reference the share where the software was located and it failed. It could be that the machine could not resolve the name, the share did not have permissions that allowed the computer to access it, or the server containing the share was down during the boot process. Determining exactly what happened can be a bit difficult since there are no direct errors logged. The first step is to turn on auditing on the server containing the share, particularly for unsuccessful attempts. The next step is to attempt to access the share from the computer once you are logged into the workstation. Remember that this does not ensure that the computer can access the share. Computers use their local system accounts to access the share where you will be using the account on which you are logged in.

The third and final potential cause is that the software started to install but aborted the installation because the MSI file detected that it should not be installed against the operating system of the workstation. This generates log entries in the application log, which you can review using Event View. One good example of this behavior is the Automatic Updates Client that's available free as a part of Microsoft Software Update Services. The Automatic Updates client is included, starting with Windows 2000 Service Pack 3 and in Windows XP. If you assign the Automatic Updates client to machines running Windows 2000 Service Pack 3 or higher, or Windows XP you will receive a message in the application event log every time the server is rebooted.

In every case it is important to realize that the user will be allowed to log on without the Group Policies being applied. Unlike a mandatory roaming profile, which will not allow the user to log on if the profile is not present, Group Policies software installation will not prevent a user from logging in even if the software was not installed successfully.

Creating your own MSI files
All of the above is great if you are distributing a package from Microsoft in which it provides the MSI file that you need. However, in many organizations there are little software programs that you have written to solve a particular need of your organization. Generally these have simple EXE installer programs that were created by a tool like Visual Studio's Package and Deployment Wizard.

The solution to situations like this, where you do not have an MSI available, is to purchase a package such as Wise's Wise Package Studio (http://www.wise.com/wps.asp). Wise Package Studio will read your Visual Studio or Visual Studio .NET file and use that to create an MSI file that you can use to distribute your software with Group Policies.

Editor's Picks

Free Newsletters, In your Inbox