UNDER CONSTRUCTION
UNDER CONSTRUCTION

Howto use GPO to deploy software packages

How to use a Group Policy on Windows Server to deploy software packages to machines which are members of Active Directory.

SHARE

Create a new directory on the server, which will store the MSI files and provide (readonly) access to them.

Right click on the directory, and choose to edit its properties.

On the Share tab: activate sharing. Allow read access to that share for the special group "Domain Computers", or to everyone, and write access for yourself.

On the Security tab: grant read access to the special group "Domain Computers", or to everyone, and write access for yourself.

Next I highly recommend that you create subdirectories there, one for each software package that you plan to deploy. You will soon have several MSI files for each package, one for each version. And you want to keep old versions around for a while. Why? If you disable ARP uninstall in the MSI files (what I recommend), then uninstall can be done only through GPO, and if that fails, you want access to the MSI file. Because with that file you can trigger uninstall by right-clicking on it.

When you copy MSI files there, give them a version number in their filename, and make sure that the version number is also in the MSI-propery ProductName. The version in the filename just makes it easier for you to know which file is what. The version number in the ProductName will be shown on the server in the list of packages when viewing the GPO, and you can make the clients show it to the users while packages are being installed, updated, or removed. You can also edit the name in the GPO, but if it is already in the MSI, then the server will automatically copy it from there.

When you copy AIPs to that MSI directory, make a subdirectory for each one, i.e. for each version, use the version number as directory name.

Please note that you cannot later rename or move files or directories, once a GPO points to them, and the path inside the software deployment GPOs cannot be modified. You can only remove the package from the GPO, and then re-add it with the new path. Avoid this by creating a good directory structure before adding the paths to GPOs.

DFS

This step is not strictly required, but highly recommended. If you do not understand it, please find and read a description of DFS. The main advantage is that if you use DFS names instead of conventional share paths, you can later move the share to another server without having to adjust the share path everywhere. Note that the share path in software deployment GPOs cannot be edited, so you would have to recreate them all.

Install the server role File-Services.

Select an existing or create a new DFS namespace (use a domain based name space). In that namespace create a DFS name which points to the share with the MSI files.

Better yet create directories for SoftwareDistribution on two file servers, activate DFS and DFSR on two servers, let DFSR replicate the two directories, and let DFS point one DFS-name to both shares.

Settings

You should use GPO to deploy a few settings, before using it to deploy software.

THIS SECTION IS UNDER CONSTRUCTION

Administrative Vorlagen / System
  Ausführliche im Vergleich zu normale Meldungen
XP: zeigt nicht nur was installiert wird, sondern auch vorbereitungs-schritte
7: zeigt ohne dies einfach nur "please wait"
Administrative Vorlagen / System / Anmeldung
  Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten
XP: nicht erst beim übernächsten boot
7: ohne dies generell unzuverlässig

GPO

Go to Group Policy Management.

Create a new GPO for each software package that you want to deploy.

Make sure that only the machines see the GPO which should apply it: Either link the GPO only in the OU where the selected machines are listed, or use the security settings of the GPO, or a mixture of both. My favourite method is to create a group for each GPO, make the machines members of that group, and set the security settings of the GPO such that only the members of that group will get it applied. This has the advantage that it is very flexible, and it is easy to change which machines gets what software: just put the machine into the right groups.

Inside the GPO go to Computer Configuration, Policies, Software Settings, Software Installation. Right-click on Software installation and select New Package.

Select the MSI file that you want to deploy, preferably by using the domain based DSF name, i.e. not \\server.domain\share, but \\domain\namespace\name.

After selecting the MSI file, do not immediately click OK. Instead select "advanced", and then OK.

Now go to the Deployment tab, and check "Uninstall this application when it falls out of the scope of management". Otherwise you later cannot uninstall it through GPO.

Updates

Put new versions of the same software into the same GPO. Do not immediately remove the previous version from that GPO, keep always at least one old version (for testing and just in case you must downgrade because the new verison acts up). You may remove older ones, but you should keep their MSI files (in case you need one for manual uninstall).

In theory some updates can simply be installed over the previous version. These update packages automatically take care of removing the old stuff. In reality this rarely works well, even if the software vendor claims that it should (exception: Adobe Flash). You can easily end up having multiple entries of the package in the list Add/Remove Programs. If you uninstall either of them, none of the versions works any more.

Other update packages require that the old versions are removed before the new ones are installed.

Sometimes when you add a new version of a package to a GPO, Windows Server automatically detects all the old versions and lists them in the Upgrades tab (example: Adobe Flash).

Sometimes you must manually add them there: After selecting the MSI file and choosing "advanced", go to the "Upgrades" tab. Add all previous versions there, which you still have in the GPO. Otherwise they will be installed all in parallel, instead of having the old ones removed.

This tab has also an option "Package can upgrade over the existing package". In most cases the correct value is auto-detected by the server. Do not manually add this checkmark, if it was not detected by the server. Doing so would cause old versions to remain listed in Add/Remove Programs! You might be tempted to check this option because you hope that then upgrading would be faster, but often there is no measurable time difference (example: Java 7). It is always safer to not have this checked.

Testing

You should never deploy a software package without first testing it on one machine. Sometimes MSI-files are broken and just do not work. Sometimes installing does work, but removing fails. It is better to detect this before it creates a mess on a large number of machines.

The test should include install, uninstall and reinstall. If you test a new version of an already existing package, leave the old version in the GPO, such that the uninstall downgrades to the previous versions.

Ideally the test should be done by creating a new GPO, make sure that it applies only to one or a few machines, and configure it to install, remove, and reinstall the package. If the package is an update to an existing package, first install the previous version, add the new, remove it, and re-add it.

Alternatively a quick test can be done without GPO by installing with the command
msiexec /qb /i package.msi
Now test it. Then uninstall with
msiexec /qb /x package.msi
Verify that it has been fully uninstalled, then reinstall with
msiexec /qb /i package.msi
But whenever you can, you should make the test via GPO. Only then you can check what happens with upgrades, like does it really downgrade to the previous version if you remove the latest one.

If your MSI-file does not install, you can get a logfile with this:
msiexec /qb /i package.msi /L* c:\log.txt

If something goes wrong, and you cannot find the mistake, you can do a more realistic test (running it in the SYSTEM account) with this:
psexec -i -s cmd.exe
net use \\server\share /user:%computername%$
msiexec /qb /i package.msi TRANSFORMS=transform.mst /L* c:\log.txt

Manual Cleanup

Sometimes things go wrong and you end up with a half-installed package that does not work and/or cannot be uninstalled (example: try to uninstall Flash Player version 11.4.402.278).

Here are two tricks that I found useful in some such cases.

First make sure that the GPO does not apply any more to the affected machine, run gpupdate, then reboot.

Trick 1:
Right-click on the MSI-file of the version that was installed last, select uninstall. If this does not work select repair and then uninstall. If that does not work either try install followed by uninstall.

Trick 2:
Use regedit to view HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. This contains keys with the IDs of all installed software packages. Select one key to see the name of the package, usually in the value DisplayName. Find the offending package, then run "msiexec /x " followed by the ID including the curly brackets. This should manually uninstall the package and remove it from the list in Add/Remove Programs. Do this for all versions of the package that are installed.

Then let the GPO apply again to the machine, run gpupdate, and reboot.


see also
Microsoft: Deploying and upgrading software