Author Posts

March 1, 2017 at 2:18 pm

I'm testing Visual Studio Code with the PowerShell extension, under a run-as account, different from the account that I am logged into the workstation as. I keep getting the following warning when executing a .ps1 from a UNC path \\fqdn.domain.example\example...\test.ps1. I do not get the warning when executing the .ps1 from my C: drive, using VSC and the same user context. I do not get the warning when executing the .ps1 from the UNC in PowerShell ISE running under the same user context. I suspect trusted sites are involved, but I don't know why it would run in PS ISE w/ no warning, and in VSC with a warning, both under the same user context.

Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning message.

Output of

Get-ExecutionPolicy -List | Format-Table -autosize

Scope ExecutionPolicy
—– —————
MachinePolicy Undefined
UserPolicy Undefined
Process Unrestricted
CurrentUser Bypass
LocalMachine Bypass

Any ideas?

March 1, 2017 at 2:19 pm

I forgot to mention that the file is unblocked.

March 1, 2017 at 2:22 pm

That's normal execution policy behavior for the exact, somewhat edge-case scenario in which you're running. You fall under the Process policy, which – while Unrestricted – will still warn about remote scripts. Bypass is what shuts off all the complaining. I'm not exactly sure how you'd modify that, other than to run Set-ExecutionPolicy inside VSC every time. But it isn't Trusted Sites, no.

March 1, 2017 at 2:28 pm

Thanks for the quick response. I don't understand the difference in behavior in PS ISE vs. VSC, but I will work in the following into my VSC startup routine.

Set-ExecutionPolicy Bypass -Scope Process

March 1, 2017 at 4:26 pm

Setting the Process ExecutionPolicy to Bypass changed the warning to an error about the script not being digitally signed. Launching a command prompt under the context of the user I run VSC as, then launching inetcpl.cpl from the cmd prompt, and adding the FQDN used in the UNC path resolved the problem, and no errors now. It is a specific situation, but I need to admin systems via powershell under a different user context, and I'm testing VSC vs. PS ISE for this purpose.

Thanks!

March 1, 2017 at 4:28 pm

Clarification:

Launching a command prompt under the context of the user I run VSC as, then launching inetcpl.cpl from the cmd prompt, and adding the FQDN used in the UNC path to Intranet Sites resolved the problem, and no errors now.