it-services
asked on
Vista Default User.v2 profile and Java 1.6
We are about to engage in a Vista SOE rollout, but have uncovered a problem with our implementation of Java 1.6.4 for the Default User.v2 roaming profile.
We have set up an account just the way we want it on the local PC and copied it to the %server%\netlogon\ share. This server copy of the default user profile was created using the standard Microsoft procedure
http://technet2.microsoft.com/WindowsVista/en/library/fb3681b2-da39-4944-93ad-dd3b6e8ca4dc1033.mspx?mfr=true
The account used for creating the Default User has been tested with Java and works OK. However, when a new user picks up this profile the following errors are displayed when attempting to access a site that uses Java.
java.security.PrivilegedAc tionExcept ion: java.io.IOException: Access is denied
java.lang.NullPointerExcep tion
java.lang.NullPointerExcep tion
The Java console shows that the java user home is poitning to the expected directory, c:\users\username .
Things we have tried;
If we replace the nutser.dat file in the Default User.v2 directory with a nutser.dat from a vanilla install, Java works fine.
It appears that the issue is related to the creation of the c:\users\user\username\app data\local low folder. This folder is created at logon for the vanilla nutser.dat but not for the customised profile.
We have tried uninstalling and reinstalling Java, in fact we first found this problem with Java 1.6.2 and have tried each version up to 1.6.4 but the issue persists. The job of rebuilding the customised profile and testing at each change will be tried as a last resort, but will be a time consuming exercise we would prefer to avoid.
We are using Vista Business edition as the base for our SOE
Any alternative suggestions?
We have set up an account just the way we want it on the local PC and copied it to the %server%\netlogon\ share. This server copy of the default user profile was created using the standard Microsoft procedure
http://technet2.microsoft.com/WindowsVista/en/library/fb3681b2-da39-4944-93ad-dd3b6e8ca4dc1033.mspx?mfr=true
The account used for creating the Default User has been tested with Java and works OK. However, when a new user picks up this profile the following errors are displayed when attempting to access a site that uses Java.
java.security.PrivilegedAc
java.lang.NullPointerExcep
java.lang.NullPointerExcep
The Java console shows that the java user home is poitning to the expected directory, c:\users\username .
Things we have tried;
If we replace the nutser.dat file in the Default User.v2 directory with a nutser.dat from a vanilla install, Java works fine.
It appears that the issue is related to the creation of the c:\users\user\username\app
We have tried uninstalling and reinstalling Java, in fact we first found this problem with Java 1.6.2 and have tried each version up to 1.6.4 but the issue persists. The job of rebuilding the customised profile and testing at each change will be tried as a last resort, but will be a time consuming exercise we would prefer to avoid.
We are using Vista Business edition as the base for our SOE
Any alternative suggestions?
Sorry, I should have said, but the reason for the suggestion above is because Java by default tries to write to the C:\Windows\Temp folder, which no standard user has access to write to. Have fun.
ASKER
Hey Lester
Thanks for your reply. It is good to know that we aren't the only people with this problem.
I've worked out a simpler workaround fix than yours so I wanted to share it with you.
I determined that the problem was that the LocalLow folder wasn't being automatically created. If you manually create the LocalLow folder then the permissions aren't set correctly to allow programs like Java to write to the area.
Reading this website http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html I realised that Java was running in Low Integrity mode and that the LocalLow folder needed to be marked as Low Integrity as well.
Using the icacls command from that article I saw that a properly created LocalLow folder has the following permissions:
C:\Users\marchiba\AppData> icacls LocalLow
LocalLow LIB-STAFF\marchiba:(F)
LIB-STAFF\marchiba:(OI)(CI )(IO)(F)
NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)( IO)(F)
BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI )(CI)(IO)( F)
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
A manually created folder doesn't have that bottom permission and it is this permission that allows java to write to it.
So to resolve this problem I added the following script to my logon script.
This script creates the LocalLow folder if it doesn't exist and uses the icacls command to set the Low Mandatory Level on the folder. Once this is done Java is able to write to that folder.
That should simplify your script.
Thanks for your reply. It is good to know that we aren't the only people with this problem.
I've worked out a simpler workaround fix than yours so I wanted to share it with you.
I determined that the problem was that the LocalLow folder wasn't being automatically created. If you manually create the LocalLow folder then the permissions aren't set correctly to allow programs like Java to write to the area.
Reading this website http://theinvisiblethings.blogspot.com/2007/02/running-vista-every-day.html I realised that Java was running in Low Integrity mode and that the LocalLow folder needed to be marked as Low Integrity as well.
Using the icacls command from that article I saw that a properly created LocalLow folder has the following permissions:
C:\Users\marchiba\AppData>
LocalLow LIB-STAFF\marchiba:(F)
LIB-STAFF\marchiba:(OI)(CI
NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(
BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
A manually created folder doesn't have that bottom permission and it is this permission that allows java to write to it.
So to resolve this problem I added the following script to my logon script.
This script creates the LocalLow folder if it doesn't exist and uses the icacls command to set the Low Mandatory Level on the folder. Once this is done Java is able to write to that folder.
That should simplify your script.
Sub ChkLocalLow()
Dim sUserProfile
'Check that the folder %USERPROFILE%\AppData\LocalLow exists and that the correct
'permissions are set to allow applications to write to this folder.
sUserProfile = wshShell.ExpandEnvironmentStrings("%USERPROFILE%")
If Not objFSO.FolderExists(sUserProfile & "\AppData\LocalLow") Then
'Folder doesn't exist. So create it
objFSO.CreateFolder(sUserProfile & "\AppData\LocalLow")
End If
'Set the permissions on this file so that it's integrity level is low.
wshShell.Run "icacls.exe " & sUserProfile & "\AppData\LocalLow /setintegritylevel (CI)(OI)L"
End Sub
ASKER
While I have determined a workaround fix for this problem I'd still like to know why the LocalLow folder isn't being created automatically so if any experts can advise me on that problem it would be much appreciated
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Open in new window