Weekend Scripter: Run PowerShell Scripts from Remote File Share: Part 2
Summary: Microsoft Scripting Guy, Ed Wilson, continues his discussion about running scripts on a remote file share.
Microsoft Scripting Guy, Ed Wilson, is here. This week has been absolutely bizarre. I have been really busy working with a select group of Honorary Scripting Guys for upcoming blog posts. I must say, there is some absolutely way cool, knock-out stuff in the works. But of course, to make all of this streamlined, I had to set up a shared Office 365 SharePoint site, grant permissions, create views, test things out, and all of that. You know what? Dude, it was easy!!! As you may guess from the three exclamation points, I was surprised. I must say that I was dreading it. I will also say that it was so intuitive that I did not once have to use Help or search for How-To articles. It really makes sense, and it has actually been a fun project. As one twentieth-century philosopher said, “I love it when a plan comes together.”
Examining script execution policy
Note This is the second in a multipart series of posts. The first post was Running Scripts from a Remote File Share.For good background info about running Windows PowerShell scripts from a remote file share, check out the guest blog post written by June Blender and Judith Herman: How to Run PowerShell Scripts from a Shared Directory.
By default when you open Windows PowerShell, the execution of scripts is disabled. This is because the default script execution policy in Windows PowerShell is restricted. To see the current script execution policy, use the Get-ExecutionPolicy cmdlet. For the current user, all you need to do is type the cmdlet name. This is shown here:
PS C:\> Get-ExecutionPolicy
RemoteSigned
To see all of the execution policies, use the –List switch as shown here:
PS C:\> Get-ExecutionPolicy -List
Scope ExecutionPolicy
----- ---------------
MachinePolicy Undefined
UserPolicy Undefined
Process Undefined
CurrentUser RemoteSigned
LocalMachine Unrestricted
You can see that there are multiple levels to which the script execution policy can be set. An ordinary user can change the CurrentUser script execution policy (unless it is specified via Group Policy. In that case, it cannot be modified by a local user). When the execution policy is first checked, it is restricted; therefore, no scripts will run. In the following example, the execution policy is set to RemoteSigned for the current user, and a check verifies that the change works.
What is RemoteSigned, anyway?
A good setting to use in an enterprise situation is RemoteSigned. This means that a script from a remote location must be signed by a recognized Certification Authority (CA) with a code-signing certificate. There are specific trusted roots that are set up automatically. I can see them by using the Cert PS: drive and looking at CurrentUser\Root. The command is shown here:
dir Cert:\CurrentUser\Root
The following image shows the command and output from the command.
So, if a script runs from a remote location, it must be signed by one of the CAs with a root listed in the previous output. I can use Group Policy to add a trusted CA, so I can issue code-signing certificates on my local network. I can also purchase a code-signing certificate from the Internet and if it is trusted, everything will be groovy. But I only need to do that if the location is remote.
Note Refer to the post listed earlier by Judith and by June for more information about this.
Because Windows PowerShell relies on the Internet Explorer definition of what is remote, a network share on my home domain is considered remote. Therefore, it needs to be signed. But more than that, even if I set my execution policy to Unrestricted, it STILL will prompt prior to running. This is by design, but it can be annoying. The best way to modify the Internet Explorer trusted sites setting is to use Group Policy. This is shown here:
In my mind, the best way to do this via Group Policy is to create a special Group Policy Object (GPO) with this setting and then apply it to appropriate scope within the domain. Give it a nice name so it makes it easy to keep up with.
After I have made my changes—even with RemoteSigned as the execution policy—I can run my scripts from network shares. This is because the network shares are not considered remote. This is shown here.
Well, that is about it for today. I am going to head out to my woodworking shop and work on my hand-cut dovetails. Join me tomorrow when I will continue this discussion about remotely running scripts from file shares.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy