Updating software with Group Policy is the most difficult aspect of GPSI. To make things complicated, the software you are upgrading may not have been deployed with Group Policy to begin with! So what is an administrator to do? How can we avoid blowing our legs off when we upgrade? Follow these steps and find out!
Your first step should be to manually upgrade the software. Do this before you even think about updating software with Group Policy! A manual test upgrade will show you a ton of information! You will want to make note of several things. First, note the duration. I’ve deployed some large updates before and I am always on edge if it starts to a take a while to install. Knowing the manual upgrade duration time will save you from worrying (and prevent you from doing something stupid like restarting the machine during installation).
You will also want to note any special prompts on upgrading. Finally, pay attention to the upgrade pattern. Does the upgrade uninstall the older version or does it write to a new location? If it writes to a new location, you will need to remove the software. It is very important that you test the software in the same way that GPSI will install it.
Actually Updating Software with Group Policy
When deploying software with GPOs, I prefer a separate policy for each application. When upgrading software, you have an additional option to consider. Do you want to add the software an as upgrade to an existing GPO or create a separate GPO for each application version? This is assuming you deployed the older version with a GPO. Personally, I keep all of my application upgrades in a single GPO.
If you didn’t deploy the application with GPSI (or if the uninstall was dirty), you have a little bit of extra work left. We are going to use Java Runtime Environment as an example and we are going to upgrade from Java 6 Update 26 (manual install) to Java 6 Update 29 (GPSI).
If I tried to install the newer version of Java in Group Policy, it would probably fail. I would get an Application error with an EventID of 104. Basically, Java is telling me that it can’t install because an older version of Java was still found. Even if Java was removed from Add/Remove Programs, it could still fail. During the installation process, Java checks HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\ to see if any previous versions can be found.
Sure enough, the old version of Java left an old key named “4EA42A62D9304AC4784BF238120662FF”. Once deleted (and after a reboot), the install proceeded perfectly! Using Group Policy Preferences, I can create a registry item that deletes this key. For easy documentation, I can add this preference item to the GPO that is installing my upgrade. For safety, I can even use an Item Level Target to specify that the GUID needs to match my software name.
So tell me, what problems have you had when updating software with Group Policy? Does this tip make life any easier or less stressful when upgrade time comes? Finally, if you don’t want to fall prey to these 5 common GPSI mishaps, check out this guide.