file copy not working for non-admin users
Working on customizing a Java install (JRE 1.6.0.22). The version I'm working on will be specific to one group of users at my company, who need one of the settings changed on the Java Control Panel in order to make some Oracle apps function as they normally do. Our environment is Windows XP SP3 and Office 2007.
I've discovered changes to this setting aren't stored in the registry, but in a file C:\Documents and Settings\[user name]\Application Data\Sun\Java\Deployment\deployment.properties.
So I wrote a vbscript and some Active Setup code so that when each new user logs in, ActiveSetup runs the vbscript, which gets the user name and copies the file deployment.properties from point A to point B. I'm wrapping this all into a Wise Package Studio script (using WPS 8).
The problem is that our environment is locked down for non-admin users, so the script doesn't work unless the user happens to have admin rights.
I'm wondering if I have any options for automating this for the non-admin users, or if they'll have to make this setting change manually. I was wondering if it would be possible to turn my script into an exe (which I can do w/ VbsEdit, my script editing program) and then run that exe with administrator rights, using my ActiveSetup solution to trigger it for each new user. Not sure if this is possible--or even advisable from a security standpoint.
I also talked to the folks here at the company who handle Active Directory and Group Policy to see if that might offer any solutions, but that seems like a steep hill to climb, at least for this project.
Still working on editing the vbscript, but here's what it currently looks like:
I've discovered changes to this setting aren't stored in the registry, but in a file C:\Documents and Settings\[user name]\Application Data\Sun\Java\Deployment\deployment.properties.
So I wrote a vbscript and some Active Setup code so that when each new user logs in, ActiveSetup runs the vbscript, which gets the user name and copies the file deployment.properties from point A to point B. I'm wrapping this all into a Wise Package Studio script (using WPS 8).
The problem is that our environment is locked down for non-admin users, so the script doesn't work unless the user happens to have admin rights.
I'm wondering if I have any options for automating this for the non-admin users, or if they'll have to make this setting change manually. I was wondering if it would be possible to turn my script into an exe (which I can do w/ VbsEdit, my script editing program) and then run that exe with administrator rights, using my ActiveSetup solution to trigger it for each new user. Not sure if this is possible--or even advisable from a security standpoint.
I also talked to the folks here at the company who handle Active Directory and Group Policy to see if that might offer any solutions, but that seems like a steep hill to climb, at least for this project.
Still working on editing the vbscript, but here's what it currently looks like:
Option Explicit
Dim objFSO, objFolder, objNetwork, objWMIService, objComputer, objFile
Dim strComputer
Dim colComputer
Dim myStr
Dim tokens
strComputer = "."
Set objNetwork = CreateObject("WScript.Network")
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") 
Set colComputer = objWMIService.ExecQuery _
    ("Select * from Win32_ComputerSystem")
' Get logged-in user
For Each objComputer in colComputer
    If IsNull(objComputer.UserName) Then
        ' No user logged on, which shouldn't happen since 
        '    we're only going to run this when a user is logged in.
        WScript.Quit
    Else
        ' parse string
        myStr = objComputer.UserName
        tokens = Split(myStr,"\")
        Set objFSO = WScript.CreateObject("Scripting.FileSystemObject")
        Set objFile = objFSO.GetFile("C:\Windows\Temp\JRE622\deployment.properties")
        If (objFSO.FolderExists("C:\Documents and Settings\" & tokens(205206) & "\Application Data\Sun\Java\Deployment") = False) Then
            objFSO.CreateFolder("C:\Documents and Settings\" & tokens(229230) & "\Application Data\Sun\Java\Deployment")
        End If
        ' now copy file to the destination folder
        objFile.Copy "C:\Documents and Settings\" & tokens(259260) & "\Application Data\Sun\Java\Deployment\"
    End If
Next
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
squeakstar
13 years ago
erm, this might sound a bit basic, but won't seperating the login script so its set to run at logon (added through a GPO) perform the action correctly?
Posted by:
dunnpy
13 years ago
Ron,
Rather than having a user based 'deployment.properties' file you can have a system wide one which negates the need to do the activesetup file copy.
Search AddDeploy for 'deployment.properties' or 'deployment.config' (this is the system wide file that tells Java where to look for the 'deployment.properties')
I think my name is on some of the posts, but generally pointing back to a Sparticus post (I think).
Hope this helps,
Dunnpy
Rather than having a user based 'deployment.properties' file you can have a system wide one which negates the need to do the activesetup file copy.
Search AddDeploy for 'deployment.properties' or 'deployment.config' (this is the system wide file that tells Java where to look for the 'deployment.properties')
I think my name is on some of the posts, but generally pointing back to a Sparticus post (I think).
Hope this helps,
Dunnpy
Posted by:
anonymous_9363
13 years ago
Script is a needlessly complicated way of achieving your aim.
In your transform, create a user profile-based feature containing the file component. Then, simply set AS to run a "repair" for the MSI.
If you want to persist in the masochistic approach, which part of the script requires admin-level access? If - as seems likely - it's access to %SystemRoot%\TEMP, simply use %TEMP% or - much better - publicly accessible share as the source instead.
BTW, for future scripting (it has a place, without doubt) you will want to avoid hard-coding things like user profile path roots (e.g. "C:\Documents and settings"). To not do so restricts your scripts to a particular version of Windows. Either use the environment variables or get the paths from the registry.
In your transform, create a user profile-based feature containing the file component. Then, simply set AS to run a "repair" for the MSI.
If you want to persist in the masochistic approach, which part of the script requires admin-level access? If - as seems likely - it's access to %SystemRoot%\TEMP, simply use %TEMP% or - much better - publicly accessible share as the source instead.
BTW, for future scripting (it has a place, without doubt) you will want to avoid hard-coding things like user profile path roots (e.g. "C:\Documents and settings"). To not do so restricts your scripts to a particular version of Windows. Either use the environment variables or get the paths from the registry.
Posted by:
RonW
13 years ago
Thanks for the tips, everyone. VBScab, I think I'll go with your suggestion for a transform and AS repair, especially since I haven't used this method yet but have read about it several times in the past. One more thing I can tick off my to-learn list (I hope).
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.