mikedisd Posted April 14, 2014 Report post Posted April 14, 2014 I need to deploy a package that runs a script using the current user's username. However, because SCCM uses the SYSTEM account, this changes the Windows environment variables (i.e., %username%, %userprofile%, etc.). I can't user the Run with user's rights because all user's are Standard Windows users and this needs Administrative rights. I've come up with a nasty Powershell script that grabs the logged in user's account name using WMIC, then truncates the domain name (first 5 characters) and the spaces from the end. This then goes into a Powershell variable. Is there an easier/better/more robust way of going about this? I thought this would be a rather common scenario; the need to push out a script that writes to the currently logged in user profile. Quote Share this post Link to post Share on other sites More sharing options...
oxyle Posted April 14, 2014 Report post Posted April 14, 2014 Not sure if i understand you correct. You want to run a specific script to a user that's currently logged in? Maybe this helps? The picture below is taken at the properties of a program inside a package. If you put %username% in the script, and execute it while the user is logged in it will fill in the blanks. Good luck! Quote Share this post Link to post Share on other sites More sharing options...
Peter van der Woude Posted April 14, 2014 Report post Posted April 14, 2014 It's not that common because usually if an installation needs to be in the user directory, user rights are also sufficient. There are anly dirty workarounds in case your really needs the user directory and system credentials. One last idea, whatever the installation is, try to split it up in a machine part and a user part. Run an installation with SYSTEM rights and set user settings with user rights. 1 Quote Share this post Link to post Share on other sites More sharing options...
mikedisd Posted April 15, 2014 Report post Posted April 15, 2014 One last idea, whatever the installation is, try to split it up in a machine part and a user part. Run an installation with SYSTEM rights and set user settings with user rights. Ahh why didn't I think of that?? Thanks for such a simple solution. Quote Share this post Link to post Share on other sites More sharing options...