6 comments

Running PowerShell Scripts From An UNC Path (Share)

Published on Sunday, May 15, 2011 in ,

Introduction

Lately a colleague of mine was struggling with the following: he wanted a script to be ran from within a Startup Script GPO. Now the problem he was encountering was the following Security Warning from PowerShell:

image

In words:

Security Warning
Run only scripts that you trust. While scripts from the Internet can be useful, this script can potentially harm your
computer. Do you want to run \\file.setspn.com\scripts\script.ps1?
[D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"):

Now if you have to run something like this occasionally, you can type R and get on it with it. However if this is a script which has to automatically run at startup, this will be a showstopper. So here is some additional information on how to avoid these warnings.

I didn’t tested this in the context of a computer starting up and executing such a script. I just tested this from the Administrator point of view: you run a PowerShell script from a share and you want to avoid that warning. Now what? I will briefly explain Execution Policies and Execution Policy Scopes before actually presenting a solution.

PowerShell Execution Policies

As most of us know by now, PowerShell comes with an execution policy. This policy define which scripts can ran and from which location. By default it’s configured to restricted:

image

In words:

File \\file.setspn.com\scripts\script.ps1 cannot be loaded because the execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:37
+ \\file.setspn.com\scripts\script.ps1 <<<<
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

However we can easily change the policy to one of the following options:

  • Restricted: no scripts
  • AllSigned: only signed scripts
  • RemoteSigned: local [+detected as local intranet] scripts and signed scripts remotely
  • Unrestricted: all scripts but comes with warnings when running from a share
  • Bypass: all scripts, no warnings

If you want a full explanation on each of these policies, check TechNet: about_Execution_Policies

PowerShell Execution Policy Scope

Now if you changed the above policy using the Set-ExecutionPolicy Policy command, you changed it for everyone running PowerShell scripts on the current machine. Did you know there is an alternative? You can actually specify a scope using the –scope parameter! This can come in very handy when you just want to open up PowerShell temporary for the installation of a product. The following scopes exist:

  • Process: affects only the current PowerShell session
  • CurrentUser: affects only the current user
  • LocalMachine: affects all users on the current computer

If you want a full explanation on each of these scopes, check TechNet: about_Execution_Policies There’s also additional info available if you want to control this by using GPO.

Determing The Active PowerShell Execution Policy

Using the Get-ExecutionPolicy command you can get the current policy, however if you add the –list parameter you can see where it’s coming from:

image

image

Now after running Set-ExecutionPolicy –Scope Process Unrestricted

image

Now the advantage is that whenever this PowerShell session is closed, the overall policy remains to what is was before my modification.

Getting Rid Of the Warning

All of the options below will explain how you can get rid of the warning when execution a script from an UNC path. Between [] I’ve added the PowerShell execution policies this is working with. The PowerShell script I’m running is located on \\file.setspn.com\scripts and it only contains one line: “write-host –forefgroundcolor green “script executed successfully””.

Option 1: use a shortname in the path [RemoteSigned/Unrestricted]

image

Why does this work?

image

By default IE7 and up are configured to automatically detect intranet network. This one checkbox actually is equivalent to checking the 3 options below it. Because we use a UNC path with a short name (\\file), it’s detected as an Intranet and hence no warning is displayed. However once you use a FQDN (\\file.setspn.com), this detection does not work. Reference: Enabling "Automatically Detect Intranet Network" on a domain member computer will enable all the three Intranet Options automatically.

Do we like this? I don’t. I hate NetBIOS names. On to the next option

Option 2: Specify Local Intranet Sites [RemoteSigned/Unrestricted]

The security warning only comes up when the script is ran from an untrusted location, we can add the UNC path to the local intranet. We can do this using one of the following formats:

  1. \\*.setspn.com
  2. file://*.setspn.com
  3. \\file.setspn.com
  4. file://file.setspn.com
  5. *.setspn.com
  6. file.setspn.com

The first 4 options will only affect files accessed from UNC paths, however option 5 & 6 will also involve HTTP/HTTPs traffic. Option 1 & 2 are in fact the same. The same goes for option 3 & 4. Whenever you enter an UNC path like \\location it will automatically be converted to file://location by IE. After adding \\*.setspn.com:

image

The script now runs just fine:

image

Option 3: Copy The Script Locally [RemoteSigned/Resctricted]

Obviously this is not applicable in certain scenario’s, but as a quick work around it’s a possibility.

image

Option 4: Sign your scripts [AllSigned/RemoteSigned/Resctricted]

Another possibility is to sign your scripts. A detailed guide is out of the scope of this post, a good description of the process can be found here: Scott Hanselman: Signing PowerShell Scripts

Option 5: Use The Bypass ExecutionPolicy [Resctricted/AllSigned/RemoteSigned/Resctricted]

All of the above options (beside #1) require you to do some modifications. There’s also a way to just suppress these warnings: the Bypass exeuction policy! I think you can apply it in one of the following ways:

  1. Set-ExecutionPolicy Bypass
  2. Set-ExecutionPolicy Bypass –Scope Process
  3. Powershell.exe –ExecutionPolicy Bypass –file \\file.setspn.com\script.ps1

Option 1 just doesn’t feel right. I myself would definitely go for option 2 or 3. They are more or less equivalent. Option 3 is ideally for calling a PowerShell script from within a bat file. Option 2 is just neat as it’s only active temporarily.

Conclusion

I’m not favoring one of the above options. I think PowerShell execution policies should be part of the Workstation/Server design. A given policy should be decided upon and pushed through GPO. Once that baseline is established, I would choose one of the above options to make a certain script work in the given scenario.

Like if RemoteSigned would be active on workstations, I would consider adding the UNC path to the Local Intranet sites. On the other hand if I would be administering servers (RemoteSigned active) and I’d have a script which I have to run just once, I would consider changing the execution policy to Bypass just for this PowerShell.exe instance (-scope process).

Happy PowerShelling!

Related Posts

6 Response to Running PowerShell Scripts From An UNC Path (Share)

Anonymous
09 August, 2011 17:54

very helpful, thanks a bunch!

Anonymous
04 November, 2011 20:35

How would you implement Set-ExecutionPolicy Bypass via a GPO? The GPO setting included with Windows Server 2008 does not list Bypass as an option.

20 November, 2011 11:26

Sorry for the latish answer. I checked 2008 R2 GPO's and it's not available over there as well. I'm not sure whether setting bypass is a great idee. But if you must I'd use preferences to set the required registry key.

Location: HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
Create a string "ExecutionPolicy" and set "Bypass" as value. If you test with a dummy value you'll see the PowerShell Get-ExecutionPolicy cmdlet defaults to restricted.

Good luck.

24 November, 2011 11:20

Excellent pieces. Keep posting such kind of information on your blog. I really impressed by your blog.
Vee Eee Technologies

Anonymous
19 December, 2011 23:56

you are the man! i just sent your site out to the rest of our department here. I'm defnitely incorporating some of this into our mix.

Anonymous
19 January, 2012 15:07

See: Adding trusted sites using PowerShell:
http://blog.mapdojo.com/2011/01/adding-trusted-site-using-powershell.html

Add Your Comment