Summary: Microsoft Scripting Guy, Ed Wilson, continues his discussion about running scripts from a remote file share.

Microsoft Scripting Guy, Ed Wilson, is here. Some things should just be easier. For example, I should have access to client-side cmdlets to work with SharePoint. Many times, as a user, I need to accomplish repetitive tasks, and a few cmdlets could really come in handy. Running scripts from remote file shares should be easier as well.

Easier? What am I talking about? Well when someone asks a question, there are so many “it depends,” “maybe,” and “whatever” stuff going on that it really makes what should be easy very complicated. For example, in a freshly created Windows Server 2012 forest, I created a share on the domain controller. I modified the script execution policy on the client, and I could run scripts from the share just fine. No configuration, no signing, no nothing. It just worked. But to make a proclamation would take hours of testing in all different sorts of variables.

The easy way to run a script

Note  This is the third in a multipart series of posts. The first post was Running Scripts from a Remote File Share. The second post was Weekend Scripter: Run PowerShell Scripts from Remote File Share: Part 2. 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.

The easy way to run a script from a remote file share is to use the Bypass methodology. This is not a security hole, because the script execution policy and the associated settings are not really security features—they are a security convenience. This means that they are in place to remind me to do the right thing—to encourage me to follow best practices. But they are not put in place to discourage getting the job done.

So, all the discussion about the script execution policy and signed scripts can be bypassed if I need to do so. What is a common requirement? Well, running a script from a scheduled task, or from within a Group Policy Object. If the desktop and network configuration are complicated to the point of not knowing what will go on, I can use Bypass mode and still get my scripts to run.

To illustrate this point, I change my script execution policy to Restricted. This is the way it comes out of the box. Scripts do not run.

Using Bypass mode

So, if I want to run a script in Bypass mode, I can use the Run dialog box. One problem I have with the Run dialog box is that it is very small, and it does not resize. The Run box is shown here:

So, what I like to do is open Notepad, compose my command, and then paste it into the run dialog box. There are a couple of things that are important to the command. First, I add –NoExit. From a scheduled task, I would not do this. I would, instead, have my script output to a log file. I added –NoExit so that I could see the output. The key to making this work is specifying the –ExecutionPolicy parameter of Bypass. I then provide the UNC path to the script that I want to run. I would use this exact sort of syntax (without the NoExit) to run a script from a scheduled task.  Here is my command:

powershell -noexit -executionpolicy bypass -file \\dc1\Share\ServerNameBios.ps1

Here is the command in Notepad:

When the command runs, it opens a new instance of Windows PowerShell, executes the script, and displays the output from the script. The execution policy of the newly created instance of Windows PowerShell is Bypass. This is shown in the following image.

Well, that is it for today. I am heading outside, so have a great day, and join me tomorrow as I begin Active Directory Domain Services Migration Week.

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