Ressourcen für IT-Professionals >
Forenhomepage
>
The Official Scripting Guys Forum!
>
Permission denied copying file to Progam Files folder
Permission denied copying file to Progam Files folder
- We use SAP in our business which is installed in the Program Files (or Program Files (x86) if using 64bit OS) folder, and have a .ini file in the SAPGui folder located within Program Files which lists all connections available when the user starts the program.
This is updated from time-to-time, and is copied across from a central network location as part of the login script. We've had no issues with Windows XP at all, however, now we're testing Windows 7, I'm finding I'm getting a Permission Denied error when it's trying to copy the file locally (thanks to UAC, I guess)
I *thought* there was some "virtual" folder that was referenced for just such occassions - where a seperate folder was created outside of Program Files but with the same structure... is this not the case?
Is there any workaround for me?
Thanks
Craig
Antworten
- I believe in Vista, Windows 7, and Windows Server 2008 no one has permission to write to "Program Files" unless their permissions are elevated. In a logon script this would require using alternate credentials, which is not recommended as it exposes Administrator credentials. The "correct" solution is to have the *.ini file in the "correct" location, which is a folder that users have write access to, such as %AllUsersProfile%, %LocalAppData%, or %AppData%.
If you cannot change the location, the best solution might a script that remotely updates the *.ini files using WMI and perhaps a text file of computer names. The person running the script needs administrator permissions on all of the computers, but members of "Domain Admins" have such permission by default. Another solution might be a Startup script (which runs with system permissions), but then the update happens every time the computer starts (unless you have a way to detect that the update is needed), and you don't know when the update has been applied to each computer (unless the script writes a log entry on the network).
Richard Mueller
MVP ADSI- Als Antwort markiertgroovyf Donnerstag, 26. November 2009 14:39
Alle Antworten
- I believe in Vista, Windows 7, and Windows Server 2008 no one has permission to write to "Program Files" unless their permissions are elevated. In a logon script this would require using alternate credentials, which is not recommended as it exposes Administrator credentials. The "correct" solution is to have the *.ini file in the "correct" location, which is a folder that users have write access to, such as %AllUsersProfile%, %LocalAppData%, or %AppData%.
If you cannot change the location, the best solution might a script that remotely updates the *.ini files using WMI and perhaps a text file of computer names. The person running the script needs administrator permissions on all of the computers, but members of "Domain Admins" have such permission by default. Another solution might be a Startup script (which runs with system permissions), but then the update happens every time the computer starts (unless you have a way to detect that the update is needed), and you don't know when the update has been applied to each computer (unless the script writes a log entry on the network).
Richard Mueller
MVP ADSI- Als Antwort markiertgroovyf Donnerstag, 26. November 2009 14:39
Like Richard said, I'd probably use a startup script to do this. Your script can check whether the file already exists before copying, if needed.
Bill- Thanks for the answers. I might look into the %LocalAppData% option.
I should have mentioned we use a User Environment Variable to point to this .ini file, which (I'm hoping) should work no matter where the file is located as long as the Environment Variable points to the same place. AppData/Local should be as good a place as any.
Craig - %LocalAppData% works a treat. Many thanks!
