3

So apparently there's no easy way to directly run a .ps1 script as administrator by double clicking it; you can edit the registry to run it, but then in order to make it run as administrator, apparently you have to tell it to open a new elevated PowerShell from within the already running PowerShell. Unfortunately, as far as I've been able to see, every time this is done, the elevated prompt opens up in a different directory than the original script! So, for example, if I have the following script:

$principal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent())
if($principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator))
{
  .\mylocalscript.ps1
  Write-Host "Just an example!"
}
else
{
  Start-Process -FilePath "powershell" -ArgumentList "-NoExit $('-File ""')$(Get-Location)$('\')$($MyInvocation.MyCommand.Path)$('""')" -Verb runAs
}

It fails because, upon being opened as administrator, the local script that was once local to the original script is no longer local, and then it cannot find it. Essentially, I need a way to tell the new elevated PowerShell window that opens to automatically change back to the directory of the original script.

What's the best way to do this?

3

You can use set-location with -Path $PSScriptRoot to change to the directory which the script that contains those commands reside, and then you can run the rest of your logic after that command to ensure it is set back to the needed directory before any commands run.

Set-Location -Path $PSScriptRoot

Further Resources

  • Set-Location
  • Automatic Variables

    • $PSScriptRoot

      Contains the directory from which the script module is being executed. This variable allows scripts to use the module path to access other resources. In PowerShell 3.0+ this is available everywhere, not just in modules.

  • 1
    This works, thank you very much. I just had to put it in the beginning of the if statement and now it runs perfectly. I appreciate it! – jippyjoe4 Jul 3 '18 at 19:05
  • "So apparently there's no easy way to directly run a .ps1 " This is by design, .ps* are associated with a text editor and MS specifically does not recommend changing this. This will just open you up to having you and or your users getting popped my drive by hacks and the like using one of the most powerful automation tools on your system. Don't treat .ps* like .bat/.cmd files. Sure, you can change this, vis File Explorer and or the registry, but again, don't. You just call powershell.exe with the name of the script and the needed elevation, to do what you are after and use the RunAs options. – postanote Jul 3 '18 at 19:12
  • @postanote, I'm only doing this on my personal system for my own convenience, but I'm curious; what "drive by hacks" are you referring to? Can you give some examples? – jippyjoe4 Jul 3 '18 at 19:37
  • So I think that the primary concern in this is what you've said here: "if you are not prompted to elevate the command explicitly, then it could run more easily unnoticed." However, couldn't a malicious script just change the "HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell\Open\Command" registry key itself and then run powershell scripts at will? I'm failing to see how doing this myself (making the scripts run by double clicking them) puts me at any additional risk when something as simple as that could be done. – jippyjoe4 Jul 3 '18 at 20:09
  • Agree, you are correct. Anything could happen maliciously to do anything technically so yes. That's just the train of thought I suppose with that feature—to make someone consciously say "Yes, run this elevated".... ha like sudo I suppose, right!! – Pimp Juice IT Jul 3 '18 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.