Last week, I described how to prepare for deployment of Java to an organization. With those pieces, we were able to deploy the software silently in several different ways. In this post, I will go into the details on how we deployed software with Group Policy.
First stop would be to upload the files to a location. We deployed to a smaller organization and simply used the location \\TheDomain\NETLOGON and created a folder for Java with a folder under that for versions and an additional folder for both x86 and x64. This may be overkill for your needs but helps with separation and troubleshooting in the future. This also gives you the ability to add another version prior to removing a previous version, which is discussed at the end of this post.
Once the folders are created, upload the .MSI, .MST, and .CFG files for each installation to the appropriate locations.
Once uploaded, Navigate to Control Panel –> System and Security –> Administrative Tools –> Group Policy Management and navigate to a test Organizational Unit. Right click on the OU and select “Create a GPO in this domain, and Link it here…”
Name the new GPO and leave Source Starter GPO as none.
Once created, right click on the GPO and select “Edit”
Next, navigate to Computer Configuration –> Policies –> Software Settings –> Software installation. Once there, right click in the right pane and select New –> Package…
A window will appear and you will be able to select the MSI package for Java.
At Deploy Software, select Advanced and push OK.
There will be a short pause while the MSI info is read into the system. A properties box will appear with much of the needed info already filled in. The setting to edit are on the Deployment and Modifications tabs. First, add a check in Deployment for “Uninstall this application when it falls out of the scope of management.”
Next, go to the Modifications tab and click Add. Navigate to the MST file and click OK to open.
Select OK one more time and you have selected this version of Java.
Now that you have done this for one architecture, do the same for the other (x86 or x64)
Once completed for both architectures, wait or force replication between all sites. Once replicated, a forced test can be accomplished by running the following from a computer within the test OU:
gpupdate /force
Once ran, a reboot will be required. If everything was successful, the software (s) should install prior to allowing users to login. Once successfully tested, apply this GPO to other OUs by right clicking on OU within Group Policy Management and selecting “Link an Existing GPO…”
A popup gives you an option to select the newly created Java GPO.
Now that you have deployed the software, what happens next week when either Java releases a new version or you are ready to move to the next supported version?
To start, leave the original GPO in place until you are ready to replace that version in production. This will prevent the software from being “Upgraded” which can cause issues. It also ensures that you don’t push the next versions directly to production when it should be tested first.
Assuming you have tested and deployed a new version, we can now navigate to the old version. We did not upgrade any elements so there should be no dependencies to cause issues. You are also protected if the computer goes to a different OU that has a different version as it will uninstall since we selected the “Uninstall this application when it falls out of the scope of management.” To uninstall, right click and edit the desired version’s GPO. Navigate to the software to be uninstall by going to Computer Configuration –> Policies –> Software Settings –> Software installation. From there, right click and choose All Tasks –> Remove.
A pop up is displayed, select “Immediately uninstall the software from users and computers”
Once the policy has replicated to all sites, again force a Group Policy to update on the endpoint and restart. The software should uninstall prior to login.
A few words of advice and caution.
First, this will work if you are using a Direct Access VPN, computer authenticated wireless LAN or wired LAN. Direct Access VPN works best with Windows 8.1 or better.
Second, deploying through GPO can cause slowness upon startup for users. This is hardly noticed upon a modern LAN but can be significant on older WLANs or on slower Direct Access VPN connections.
Third, try to avoid upgrading from version to version within the same GPO. I discovered that the version that was upgraded from did not uninstall.
Fourth, this deployment style works well but do not provide easily accessible reporting nor a way to remove all previous versions. You can use WMIC commands to remove software BUT you are not able to easily remove and deploy all in one place.
Lastly, I can’t stress how important testing is before large scale deployments. Testing will help prevent end user complaints as well as extra time for IT staff.
Thanks for viewing and stay tuned from a scripted version that can accomplish a remove of ALL previous versions prior to installation of new version. Please comment if you have questions, comments, or requests!
Tips are appreciated – BTC 1NTuVYMcGUMSYZ6tkhg7qMEr7XP2fcQJjL