Java 7 no go with SYSTEM install - and a fix?

(imported topic written by SystemAdmin)

Hi All.

I was hoping with a new JRE out

(download)

that they’d fix the install as SYSTEM context issue for 32-bit java on 64-bit windows. I tested and they did not.

This may not be news to some, but this method really does seem to work to fix the issue on a 64-bit machine:

:Batch File

if not exist “%windir%\system32\config\systemprofile\AppData\LocalLow\Sun\Java” mkdir “%windir%\system32\config\systemprofile\AppData\LocalLow\Sun\Java”

if not exist “%windir%\SysWOW64\config\systemprofile\AppData\LocalLow\Sun” mkdir “%windir%\SysWOW64\config\systemprofile\AppData\LocalLow\Sun”

mklink /J “%windir%\SysWOW64\config\systemprofile\AppData\LocalLow\Sun\Java” “%windir%\System32\config\systemprofile\AppData\LocalLow\Sun\Java”

I’d like to hear from someone at BigFix who can explain perhaps why this won’t work instead of the RunAsCurrentUser method of the 64-bit fixlet. With UAC on, it’s a losing proposition.

The most ideal thing to do might be to use a relevance clause to check for the existence of that Java directory junction in the mklink command and make sure it resolves to the right place - that the directory exists that it resolves to. Create it if not. I know from experience that running the command one time isn’t guaranteed to make it stick around forever - those directories can be deleted. But making this a Policy action would be a super good thing.

If it works at all! What does anyone think?

Try it out -

psexec -s cmd.exe

whoami

jre-7-windows-i586.exe /s /norestart

I notice that unlike the update versions of 6 which uninstall what is being updated, this leaves JRE 6 on your machine.

I really don’t like managing Java.

(imported comment written by SystemAdmin)

Hi Folks –

Seeing that the fixlets for JRE 7 just came out, does anyone have commentary on whether the above post has been integrated into the fixlets?

(imported comment written by SystemAdmin)

Nope - because I wrote the post when java 7 had just come out.

I really don’t want to disable UAC so I can patch Java reliably. Any comment from BigFix staffers - pretty sure the method I described up there works and everyone is happy.

(imported comment written by SystemAdmin)

Err sorry, you were asking about if the changes were rolled into the java installer now that the fixlet is out - and the fixlet wasn’t out.

But the 32-bit java 7 (on 64-bit windows) fixlet, number 7056022, still does the UAC will fail part with:

//if UAC is on, this MAY fail

waithidden __Download\RunAsCurrentUser-2.0.3.1.exe --w --q cmd.exe /c __Download\jre-7-windows-i586.exe /s /norestart

(imported comment written by SystemAdmin)

We are looking into this issue. We’ll post an update here soon.

(imported comment written by SystemAdmin)

Anything on this?

Need to get this bad boy going!

(imported comment written by SystemAdmin)

I’ve been working on a fixlet that does this just as a test.

In the fixlet action, though, it fails to delete or create any directory in C:\Windows\System32\config\systemprofile\AppData\LocalLow

Here’s the bit of fixlet logic

dos rmdir /Q /S 
"C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun" dos rmdir /Q /S 
"C:\Windows\system32\config\systemprofile\AppData\LocalLow\Sun" dos mkdir 
"C:\Windows\System32\config\systemprofile\AppData\LocalLow\Sun\Java" dos mkdir 
"C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow\Sun" dos mklink /J 
"{pathname of windows folder & "\SysWOW64\config\systemprofile\AppData\LocalLow\Sun\Java
"}" 
"{pathname of windows folder & "\System32\config\systemprofile\AppData\LocalLow\Sun\Java
"}"

I even made the path completely explicit rather than relying on relevance or an environment variable to locate the windows directory. I’ve done this many different ways, and always the same problem - can remove / create directories in syswow64, but not in system32.

I’ve done this:

createfile until _end_ @ECHO OFF rmdir /s /q 
"%windir%\SysWOW64\config\systemprofile\AppData\LocalLow\Sun" > NUL 2>NUL rmdir /s /q 
"%windir%\system32\config\systemprofile\AppData\LocalLow\Sun" > NUL 2>NUL mkdir 
"%windir%\system32\config\systemprofile\AppData\LocalLow\Sun\Java" > NUL 2>NUL mkdir 
"%windir%\SysWOW64\config\systemprofile\AppData\LocalLow\Sun" > NUL 2>NUL mklink /J 
"%windir%\SysWOW64\config\systemprofile\AppData\LocalLow\Sun\Java" 
"%windir%\System32\config\systemprofile\AppData\LocalLow\Sun\Java" > NUL 2>NUL   _end_   move __createfile 
"__Download\x32JavaOnX64SymLink.bat" waithidden 
"{pathname of system folder & "\cmd.exe
"}" /C 
"{(pathname of client folder of current site) & "\__Download\x32JavaOnX64SymLink.bat
"}"

which didn’t work (looks like for the same reasons)

and this, which is probably the least error prone and most correct way - just like the top way. It doesn’t work. This is just to show that I know not to hardcode the windows directory :slight_smile:

dos rmdir /Q /S 
"{pathname of windows folder & "\SysWOW64\config\systemprofile\AppData\LocalLow\Sun
"}" dos rmdir /Q /S 
"{pathname of windows folder & "\system32\config\systemprofile\AppData\LocalLow\Sun
"}" dos mkdir /Q /S 
"{pathname of windows folder & "\system32\config\systemprofile\AppData\LocalLow\Sun\Java
"}" dos mkdir /Q /S 
"{pathname of windows folder & "\SysWOW64\config\systemprofile\AppData\LocalLow\Sun
"}" dos mklink /J 
"{pathname of windows folder & "\SysWOW64\config\systemprofile\AppData\LocalLow\Sun\Java
"}" 
"{pathname of windows folder & "\System32\config\systemprofile\AppData\LocalLow\Sun\Java
"}"

For the life of me, I can’t figure out why it won’t do any directory operations in the System32\config\systemprofile\AppData\LocalLow directory, but it will do those operations in the SysWOW64\config\systemprofile\AppData\LocalLow\ directory.

There are other issues with even the default fixlet in general, though. Big problems I would say, if I’m right.

If the java installer executable fails to complete successfully – that is it executes, extracts the msi to the wrong place, it can’t call msiexec with the right path and quits – the line in the fixlet that says this

regset 
"[HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation]" 
"InstallingJava7_32"=dword:00000001

is all that is necessary for the applicability relevance to show the machine as ‘fixed’ - leading someone to believe that java was successfully installed. That bit of relevance looks like this:

if (exists key 
"HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation" of registry) then (not exists value 
"InstallingJava7_32" whose (it = 1) of key 
"HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation" of registry) 

else 

true

The registry key InstallingJava7_32 is only deleted when the following condition is met

continue 

if 
{((exists value 
"DisplayVersion" whose ((it >= 
"7.0.0") of (it as string as version)) of keys whose (value 
"DisplayName" of it as string as lowercase contains 
"j2se runtime environment" OR value 
"DisplayName" of it as string as lowercase starts with 
"java(tm)") of it) AND (exists key whose (((it contains 
"java" OR it contains 
"j2se") AND (it contains 
"runtime environment" OR it contains 
"update")) of (value 
"DisplayName" of it as string as lowercase)) of it)) of key 
"HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall" of x32 registry
}

and so it’s never deleted, and the machine is shown as fixed. In order for the fixlet to become relevant again, I simply manually delete that registry key.

I’ve been plugging away at this for a long, long time now and getting nowhere - I’m pretty new at all this stuff.

(imported comment written by SystemAdmin)

We have been looking into this issue and faced similar problems of not being able do any directory operations in the System32\config\systemprofile\AppData\LocalLow directory. This causes the solution of creating a symbolic link to fail. This is still under investigation on what might be causing this issue.

However, I have created a workaround based on the fact that the jre executable when run extracts itself to an .msi in the “SystemWow64\config\systemprofile\AppData\LocalLow\Sun\Java” folder.

Could you try replacing the action in the fixlet JRE 7 (32-bit) Available (x64) -

waithidden __Download\RunAsCurrentUser-2.0.3.1.exe --w --q cmd.exe /c __Download\jre-7-windows-i586.exe /s /norestart

by the following action script commands -

waithidden __Download\jre-7-windows-i586.exe /s /norestart waithidden msiexec /i 
"{system wow64 folder as string & "\config\systemprofile\AppData\LocalLow\Sun\Java\jre1.7.0\jre1.7.0.msi
"}" /qn

and check whether it works for you or not.

The above presented solution works in our initial testing and we would like to confirm whether it is a viable solution or not.

Issues concerning the general fixlet:

The line of action script command in the fixlet

regset 
"[HKEY_LOCAL_MACHINE\SOFTWARE\BigFix\EnterpriseClient\JavaInstallation]" 
"InstallingJava7_32"=dword:00000001

is present to help differentiate between a successful install of JRE and a corrupt installation of JRE. Thus when the normal fixlet actually fails to install jre correctly due to some reason (in this case due to JRE SYSTEM context issue) the normal fixlet reports fixed. This means that JRE is now in a corrupt state and this should make the CORRUPT fixlet of the corresponding JRE relevant, which is its intended behavior. You should be using the corrupt fixlet in order to install the fixlet on the machine that fails installing JRE instead of manually going to the affected machine and removing the registry key.

(imported comment written by SystemAdmin)

Thanks for the explanation on the Corrupt Patch detection / registry key.

I took a look at the fixlet solution you mentioned, and that’s a quick way to go. However, I wasn’t sure if that was a complete install, knowing what I know about Java installs from over the years. As it turns out, if you only install the MSI other stuff isn’t installed - Java Auto Update at the least. So while some customers might want this, others may not. There is a fixlet that can be deployed to disable Java Updates (and we just don’t allow jusched.exe to run via group policy), but I’m guessing some IT staff do want that autoupdate check done.

I tested and confirmed that it doesn’t install the auto update service by installing just the msi referenced, and noting the lack of a Program Files (X86)\Common Files\Java directory that contains jusched.exe (and other stuff). Then, I ran the full installer - jre-7-windows-i586.exe and it was there. So the exe does multiple things, only one of which is the actual installation of the core runtime binaries.

Furthermore, I found this webpage

Which I think describes why the symlink trick I wrote didn’t work - I couldn’t perform any operations in system32. And, as luck would have it, back in September another poster did use the symlink trick with the sysnative workaround to do a Java deployment. The usage of sysnative is not unknown to fixlet authors, but doesn’t seem to be super common.

google.com - sysnative site:(bigfix.com)

This might be something folks need to pay close attention to in certain circumstances.

Forum member for 32-bit Java on x64 uses sysnative and the symlink trick I mentioned at the very top. It’s more elegant than my solution.

Right now, for me, the fixlet above is not working, but I plan to restart this machine to see if it is something related to the multiple java installs/uninstalls in the last hour or so. The fixlet will have to be altered for non c:\windows %windir%'s but I’m hoping it’s solid and you guys can put your stamp on it.

(imported comment written by SystemAdmin)

We’ve tested with the action code provided by Mayank on Win7-64 with UAC enabled. The Java 7 installation does complete with the revised action code. However, subsequently, we get a UAC prompt to allow ssvagent.exe to run every time IE is opened.

We have no need for Java Auto Update, so that’s not a barrier to using the MSI installation for us. But having a UAC prompt come up when a user launches a browser won’t work in our environment.

If anyone has other ideas about what we should test, we’d be happy to help out.

(imported comment written by SystemAdmin)

I think I have a fix here. Well, a work-around rather.

You have to import this registry key, which changes the system profile image path, then restore it after the java install completes.

I have attached my fixlet which seems to be working!

(imported comment written by SystemAdmin)

Anyone try this?

It continues to work for me with all of my 32 on 64 java installs included the latest Java 7 Update 2

(imported comment written by SystemAdmin)

Hey Canyon,

Thanks for the fixlet. I cannot reproduce the problem so am not being able to test the modified fixlet. Hopefully other folks who face such a problem will and let us know.

(imported comment written by SystemAdmin)

If you want to reference, for example, c:\windows\system32, on a x64 system, you need to either explicitly use the “x64 folder” inspector or insert this at the start of your actionscript “action uses wow64 redirection false”.

(imported comment written by SystemAdmin)

Hi Folks –

CanyonRCH’s solution works for us, installing 32-bit java on Windows 7 64 with UAC set at maximum. It works for both Java 6 and Java 7. Going forward, each new java version will require the same modifications to the standard fixlet to import the reg key and then restore it afterwards.

Is there any way to add another action to future java fixlets, somthing like “Click here to upgrade machines with UAC enabled”? This would replace the existing Important Note that the installation may fail with UAC enabled.

(imported comment written by SystemAdmin)

We approached this a little different. Instead of running an EXE installer, we extract an MSI and use msiexec without “runasacurrentuser” route. So in short, it works like this (shown for jre6b32 but JRE7 is the same idea):

download http://********:443/Uploads/4958c55e4e51536a225eab2b6dbdea7962034f4a/jre1.6.0_32.tmp

continue if {(size of it = 13394327 AND sha1 of it = “4958c55e4e51536a225eab2b6dbdea7962034f4a”) of file “jre1.6.0_32.tmp” of folder “__Download”}

extract jre1.6.0_32.tmp

waithidden msiexec.exe /i “__Download\jre1.6.0_32.msi” /qn ADDLOCAL=ALL IEXPLORE=1 MOZILLA=1 SYSTRAY=0 REBOOT=REALLYSUPRESS /L*V “c:\temp\jre6b32_install.log”

To extract an MSI from EXE, follow these steps: http://www.java.com/en/download/help/msi_install.xml. Precache the folder with MSI and CAB and give it a try.

(imported comment written by SystemAdmin)

Why does the standard Java fixlet patch still have trouble with UAC after all this time? Can we have a better resolution than creating our own fixlets?

(imported comment written by Xie_Ran91)

Are you still experiencing UAC prompt with the latest JRE fixlets?

We have changed the installation action since JRE 7 Update 11 using the symbolic links. You can refer to this

Thread

For all our test machines, even with the UAC set to the highest level, we don’t see any issue using our fixlets to install JRE.

(imported comment written by SystemAdmin)

Thanks Xie_Ran91!! I’ve had time to test, and can confirm, it’s working to update the Java clients with UAC enabled. Had to run both the original Java Patch, then the CORRUPT PATCH and system reboot but it’s working properly. Huge Time savings so thanks!!

(imported comment written by SystemAdmin)

It’s working for us as well since your change. No more having to change the code for each fixlet. Thank you so much!