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.
Get-ExecutionPolicy -List | Format-Table -autosize
I forgot to mention that the file is unblocked.
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.
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
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.
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.