Separate target user #50
Conversation
ghost
mentioned this pull request
Default to the current user to preserve standard behaviour
Default to the current user to preserve existing behaviour
install.ps1
Outdated
|
|
||
| echo "Changing settings for user $targetUser with SID $targetUserSID" | ||
|
|
||
| $Env:LocalAppData = "C:\Users\$targetUser\AppData\Local" |
There was a problem hiding this comment.
Any reason on why C: is hard coded here? Not everyone installs Windows on that drive.
There was a problem hiding this comment.
No that's a great point. I'll have a look for a better way, do you have any suggestions before I look into it?
There was a problem hiding this comment.
You might try to see if systemroot environment variable can be used.
uninstall.ps1
Outdated
| $targetUserObject = New-Object System.Security.Principal.NTAccount($targetUser) | ||
| $targetUserSID = $targetUserObject.Translate([System.Security.Principal.SecurityIdentifier]).value | ||
|
|
||
| $Env:LocalAppData = "C:\Users\$targetUser\AppData\Local" |
There was a problem hiding this comment.
Same here with hard coded drive name.
…minal-shell into separate-target-user Pulling changes
|
I've opted for $Env:HOMEDRIVE as it seems a clean way to get there |
|
@peter1rhodes look up the profile path from registry, some people change the drive that contains the windows profile and home drive may not be the same as the system drive. don't assume all account profiles are in the same drive.. see : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList There's probably an easier Win32 call to get this info... or some ready made .NET API. |
|
|
…latile Environment reg keys)
|
Thank you both @rwasef1830 and @lextm. I have found a way to get to the correct user profile directory using HKEY_USERS[SID]\Voltatile Environment which seems to work well. |
…stall and uninstall scripts
Get target user fn
|
I've refactored the key parts to use Volatile Environment for both LocalAppData and for the USERPROFILE path. I have also moved all that logic for finding the required paths for the target user to a new function Get-TargetUser, in a new file called TargetUser.psm1, which is then imported by both install.ps1 and uninstall.ps1. The Get-TargetUser function prompts the user to select a user for which to install the context menus, defaulting to the current user if Enter is hit without input. It then returns a custom object containing the required info about the targetUser (their username, SID, LocalAppData path and USERPROFILE path), which can then easily be referenced by the calling scripts. |
|
I've tried this PR on my computer and it works |
|
Tried this PR as well, did work for my non-admin account on Windows 10. EDIT: in order to run this script, one needs to set |
5 participants
On my work laptop, I have a standard user that I use regularly, but also a local admin account that lets me install stuff. I have therefore modified the install script to allow installation for another user.
I am very open to feedback, as I am a complete Powershell beginner. It is likely that I have not done things in the best way. However, the install script worked well for me