Java rollout

In response to the latest Java security hole, and the seriously broken nature of Java's ability to self-update (it sometimes takes weeks for Java to decide to install an update after a release), we have decided to automate the rollout and update of Java. There appear to be a few glitches in the ability to automate this process:

We need to be able to identify the systems that already have the latest version of Java, so that we're nor reinstalling over a good copy.

We need to be able to remove outdated versions of Java, so that they can't be requested by programs.

It appears that Oracle doesn't have a .MSI file. Worse yet, when their .EXE file is run, it auto-extracts a .MSI that's only part of the program, so an entire directory needs to be captured.

The documentation that I've been able to find for GPO or script updates of Java is all old. Nothing from Oracle about Java7, and the most recent on the web I've found so far is for Java7.4.

If you previously deployed with group policy you can tell it to replace the old version on the upgrades tab which will uninstall the old version prior to installing the new.

For detecting and bulk installing old versions I'm not sure...one could use something like http://sourceforge.net/p/windocumentor/wiki/Home/ to determine which versions on which computer and make a script to automate it's removal but that is probably the "hard way"

Run the executable but don't complete setup. C:\Users\<username>\appdata\LocalLow\Sun\Java\jre1.7.0_11 will have the msi you need.

That appears to be the same as it used to be.

SmartDrv wrote:

For detecting and bulk installing old versions I'm not sure...one could use something like http://sourceforge.net/p/windocumentor/wiki/Home/ to determine which versions on which computer and make a script to automate it's removal but that is probably the "hard way"

OK. I'm having problems getting the software installed. I created a directory and shared it out, giving Everyone read access to the share and Read&Execute/ListFolderContents/Read access on the directory. I put each application (32-bit and 64-bit Java) in it's own folder under the share, and they inheretited the permissions. I then created the GPO according to this page, performing an Assign, Linked the GPO to a test OU containing computers, and set the GPO to Enforced. I set the GPO permissions to allow Everyone read permission.

via a script to remove Java 1.5. I also had it removing many versions of Java 1.6 before 1.6_10, but I unfortunately no longer have that script handy. I remember having long sleep periods to allow each version to uninstall before running the next one. I found another suggesting

{3248F0A8-6813-11D6-A77B-00B0D0160021}is the uninstall string for 1.6_21, and I think you can see how to alter it for each Java version.

These were all on Windows XP.

I believe at some point I was using info from appdeploy.com, but at some point the site changed into something else, and I can't say if it still has the info there.

And to followup, the long sleep (like 600 seconds between uninstalls) was partially because I was running this against machines that had a thousand or more unique logins on it, and Java was touching each profile. It was quicker on machines with just a few users. I also recall, at earlier versions of Java, I had to run "net stop Java Web Start" or such before trying the uninstall.

As a side comment, make sure to test your uninstall also. While I think it was fixed, nothing made my day more when one of the older Java 1.6 versions had a defect that made the uninstall fail. This will make the GPO update fail as it won't be able to uninstall the prior package leaving you with an enterprise of machines stuck at whatever release failed.

It took a fair amount of scripting to manually remove that patch so that GPO could deploy the next release.

Those of you rolling out Java 6 via GPO did you bother to uninstall it before rolling out Java 7 via GPO?

I've never been entirely clear how Java handles multiple versions being installed?

Java tolerates multiple versions just fine, at least up to version 6. I haven't tried multiples of v7 personally since I just remove it when possible nowadays. If anyone comes up with a good script to remove all the old versions, I'd sure like a copy of it. Might save me some serious pain the first time I touch a system.

As a side comment, make sure to test your uninstall also. While I think it was fixed, nothing made my day more when one of the older Java 1.6 versions had a defect that made the uninstall fail. This will make the GPO update fail as it won't be able to uninstall the prior package leaving you with an enterprise of machines stuck at whatever release failed.

It took a fair amount of scripting to manually remove that patch so that GPO could deploy the next release.

In Altiris, I pushed out a manual delete script. Stop the associated services, scrub the registry, delete the program folders and user profile folders and let the new install take place.

Those of you rolling out Java 6 via GPO did you bother to uninstall it before rolling out Java 7 via GPO?

I've never been entirely clear how Java handles multiple versions being installed?

Java tolerates multiple versions just fine, at least up to version 6. I haven't tried multiples of v7 personally since I just remove it when possible nowadays. If anyone comes up with a good script to remove all the old versions, I'd sure like a copy of it. Might save me some serious pain the first time I touch a system.

Yeah what I meant was right now all our systems have 6 update 37 installed. Let's say I want to deploy 7 update 11 tomorrow.

Firstly if I don't know of apps that need 7, is there any benefit in moving from 6 update 37 (until next week when that gets owned)?

Secondly, would you just delete the GPO for 6 and create a new one for 7 or would you try to specify that 7 is an upgrade for 6?

Those of you rolling out Java 6 via GPO did you bother to uninstall it before rolling out Java 7 via GPO?

I'll have a manual procedure for the initial rollout, where the user uninstalls all the Java before doing a GPUPDATE and a restart. After that, it should all be automatic. Thanks to the Acrobat Reader and Flash releases that are supposed to appear today, I hope to be putting all three under GPOs at the same time (depends on Adobe's turnaround time for "Right to Distribute" request), creating only one user interruption.

hutchingsp wrote:

I've never been entirely clear how Java handles multiple versions being installed?

Multiple versions of Java can coexist on the same system just fine. The problem is that Java Applets can request older versions of Java. If they're installed, they'll be used. For most end-users, it's best to have only one version installed.

hutchingsp wrote:

Firstly if I don't know of apps that need 7, is there any benefit in moving from 6 update 37 (until next week when that gets owned)?

Only that free Java 6 support ends in a few months. After that, if you don't pay Oracle, the security flaws won't be fixed.

hutchingsp wrote:

I fucking hate Java

You and a few billion others. Most of the people who love it are the hackers who use it as a revolving door into your system.

Accs wrote:

At 8PM, I figured it out, then walked out the door. I'll update this with the fix in the morning.

The first link goes through the entire procedure. I unset the "Enforced" flag on the GPO, and set the "Always install with elevated privileges" flag in the install GPO (the movie had you put it in the Default Domain Policy). The GPO still didn't work. I found the second link above, enabled the "Startup policy processing wait time", and set the amount of time to 30 (the default, but it doesn't work without setting it). Finally, I granted Read permission to Everyone for this policy. It still didn't work.

I found a link suggesting that only one install per policy will work. I split the policy (I had been installing both 32-bit and 64-bit Java from the same GPO), and all was well.

I don't know how much of the above is critical to proper functioning of the GPO, but it works now, and I'm not going to screw with it.

I don't know how much of the above is critical to proper functioning of the GPO, but it works now, and I'm not going to screw with it.

And now it doesn't. It worked perfectly in the first two systems, then it quit working. Grrrr.

AFAIK, "Enforced" GPOs means that makes it the last one to fire off. That's not necessarily what you want to have happen.

It's worse if you've got ALL of your GPOs as "enforced", but that may make it the same as having none "enforced" or not.

I know this by experience

If you've got WinVista/Win7 machines, the "Always install with elevated privileges" is useful, as is using "run in user's security context" or WTF that option is for things other than a software install.

Also, with WinXP, it should take the second login for it to take effect, unless you push out a gpupdate/force remotely against all the systems first. The first login will get the updated GPOs, the second should do the install. With WinVista and Win7 (and Win8) AFAIK, it should be something like 45 minutes? Before the GPOs are refreshed.

Also, I've found that if you've got cruft from certain versions of the install, you'll wind up with a nonfunctioning java install after the install is done, unless you run it manually. If you run it manually, then everything fires off fine.

Versions prior to say 7u5 didn't do this, neither did 6u35 and earlier. Those could be run on top of itself without issue.

--

lurch,

thanks for that script. I've seen similar elsewhere, probably on the spiceworks community. I'll give yours a shot after I fix this nagging email issue in my org.

I've not been able to 100% find out if Java version 6 is effected, or just version 7 pre-11? I've seen that Oracle is saying anything lower than Java 7 Update 11 needs updated, but is that just within the 7.x tree? Or is EVERY version of Java major and minor effected?

While this is excellent advice, the fact (at least where I work) is that those people who will be most vocal about a "need" to run Java applets are the same users who will be least able to enable it in the browser without breaking something

I don't know how much of the above is critical to proper functioning of the GPO, but it works now, and I'm not going to screw with it.

And now it doesn't. It worked perfectly in the first two systems, then it quit working. Grrrr.

AFAIK, "Enforced" GPOs means that makes it the last one to fire off. That's not necessarily what you want to have happen.

It's worse if you've got ALL of your GPOs as "enforced", but that may make it the same as having none "enforced" or not.

None of our policies are set to "enforced" at this time.

Danger Mouse wrote:

If you've got WinVista/Win7 machines, the "Always install with elevated privileges" is useful, as is using "run in user's security context" or WTF that option is for things other than a software install.

All our Windows systems are either Windows 7 x64 (Pro or Ultimate) or Server 2008R2.

Accs wrote:

Accs wrote:

I don't know how much of the above is critical to proper functioning of the GPO, but it works now, and I'm not going to screw with it.

And now it doesn't. It worked perfectly in the first two systems, then it quit working. Grrrr.

I ran a GPRESULT /h (path), and the result showed something "interesting". The "Computer Configuration Summary" section says "no data available". Because of this,several policies show up as "empty", even though they have settings in them (all the settings are in the "Computer Configuration" section).

The new policies don't show up at all.

Also, three policies only show up by GUID, and claim to be "Inaccessible". Is there a way to translate the GUID to the correct policy name?

Also, three policies only show up by GUID, and claim to be "Inaccessible". Is there a way to translate the GUID to the correct policy name?

On the 'Details' tab of the GPO.

Doh!!! I found that these policies weren't readable by users - only by computers. As there's nothing in them that's sensative, I added read-only access for authenticated users. They now show up by name.

That still leaves the issues where the new policies don't show up at all (what I'm actively debugging) and where the "Computer Configuration" section is empty.

Can you be more specific about what's in the delegation tab? What allowed permissions do Everyone and Domain Computers have? Are any of them "from Security Filtering"? Is Authenticated Users no longer anywhere?

When you say the policy will be applied to the domain, do you mean at the root of the domain, or to your 'workstations' OU?

I've always gone pretty simple when creating a GPO that will apply to every computer in an OU (the defaults, really). Authenticated Users in Security Filtering, and left the rest of Delegation alone. Reads something like:

Can you be more specific about what's in the delegation tab? What allowed permissions do Everyone and Domain Computers have? Are any of them "from Security Filtering"? Is Authenticated Users no longer anywhere?

The "Delegation" tab had:

Domain Admins (Edit settings, delete, modify security)

Enterprise Admins (Edit settings, delete, modify security)

System (Edit settings, delete, modify security)

Enterprise Domain Conrtgollers (Read)

Domain Computers (Read)

Domain Controllers (Read)

Everyone (Read from security filtering)

"Authenticated Users" should be covered by "Everyone". Also, the software install should be done while the system is booting, so there's no authenticated user, but "Everyone" should handle this.

Under Security Filtering, I added Read access to Domain Computers and Domain Controllers, and the apps still don't install.

Spatula wrote:

When you say the policy will be applied to the domain, do you mean at the root of the domain, or to your 'workstations' OU?

The root of the domain. This is so that when someone adds a computer to the wrong place, the correct policies will still be applied.

Spatula wrote:

I've always gone pretty simple when creating a GPO that will apply to every computer in an OU (the defaults, really). Authenticated Users in Security Filtering, and left the rest of Delegation alone. Reads something like:

This looks like a good way to simplify our system installation procedures for any application that's distributed as a .MSI file. I'll have to play with these tools a bit before I can be sure they'll do what we need them to do for Java. Unfortunately, most applications are distributed as a .EXE file. While this MIGHT be able to be converted to a .MSI file, it's not always easy.

If there's nothing in Applications, what does the Group Policy Operational log say? (Applications and Services Logs\Microsoft\Windows\Group Policy\Operational)

There was some stuff in there that claimed that the policies hadn't changed, so no change was needed. I unlinked the policies, ran GPUPDATE, and rebooted the system. When the system came up, there was something that tried to run Java7, and couldn't get to it. I linked the policies back in, ran the GPUPDATE sequence yet again, and it installed the applications.

Color me confused

Spatula wrote:

If you apply to the root of the domain, do you at least have inheritance blocked for your servers OU?

No. We use LSI RAID cards in most of our servers. The monitoring tool for this uses Java. Like it or not, Java is needed, even on our servers