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!
Manual Upgrade
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.
Joseph, I’ve run into some problems updating Java through GPO and wondered if you could help me? I’ve created a GPO for installing Java 7_45. Initially I followed your instructions here – https://deployhappiness.com/deploy-java-runtime-environment-with-group-policy. Problem is it won’t install. A previous version of Java, 6_35, is already installed, so I followed the directions found on this page, as well as the 5 tips for troubleshooting GPSI. Nothing fixes the problem though.
The GPO is on my test station, so I know that much works. When viewing Event Viewer I have 3 errors:
1274 – the assignment of application Java 7 Update 45 from policy blah blah failed.
2 – The removal of the assignment of application Java 7 Update 45 from policy blah blah failed.
1274 – Failed to apply changes to software installation settings. The installation of software deployed through Group Policy for this user has been delayed until the next logon because the changes must be applied before the user logon.
Rebooting/logging off and back on does nothing. Tried several times. I then found this at Server Fault – http://serverfault.com/questions/44257/group-policy-installation-failed-error-1274, and tried to set the “always wait” setting, but I have absolutely no settings under Admin Templates. All Settings is there (with nothing inside), but System is not.
At this point I’m lost on how to get Java to update. Any suggestions on what I could do?
Sounds like quite the pick you have there! Have you seen this post:
https://deployhappiness.com/reinstall-applications-deployed-through-group-policy-software-installation/
No, I hadn’t seen that page. After reading it and walking through what was suggested, I can tell you that this machine has nothing under the HKLM/…/…/…Group Policy/AppMgmt folder. MSIManager reports nothing as well.
Figured it out! I had to set the following policy on the local test station:
Computer Config > Administrative Templates > System > Group Policy > Startup policy processing wait time > and I set it to 30 seconds. Once I did that it installed just fine. The only down side is the delay in getting to the logon prompt.
Do you know of a way to set this policy at the domain level? It’s not available on the DC.
I’ve always wondered about the need to retain old versions of the msi and entries in the policy when updating. For example, we have an application that I wrote internally that I deployed through GPSI. When updating, the subsequent versions have been deployed as upgrades. Now that I’m on version 8 of the application, I wonder if I need to keep all versions’ MSI on the share as well as the entries in the policy. What’s the process moving forward, long term?
We only keep the previous version of an application as it makes rolling back a bit easier.