Run PowerShell Scripts Stored on a Central File Share
Summary: Learn about Windows PowerShell Script Execution policies and how they effect running scripts from a central file share.
Hey, Scripting Guy! I am curious as to the best place to store scripts. I want to maintain a master list of approved scripts, but I am not certain as to the best way to do this. I am wondering if a simple file share inside the network will be sufficient for my purposes. What do you think? Will a file share work for sharing scripts inside the network?
— SG
Hello SG, Microsoft Scripting Guy Ed Wilson here. When it is 31 degrees Fahrenheit outside (-0.5 degrees Celsius) the Scripting Wife begins to whine that it is cold. In fact, she interrupted me last night while I was reading a novel by Dorothy Sayers that I picked up at the public library over the weekend, to “come look at the snow.” Seeing our snowfall last night was somewhat of a trick. First, I had to turn on the outside light. Next, I had to stand in a certain position and gaze up toward the moon. If I held my head real still, I could see a few flakes as they tumbled to earth. There was no accumulation. In fact, I believe that the flakes were doomed to revert to raindrops before even touching the ground. But it was a nice treat to see the snow.
Anyway, as I started to say, the Scripting Wife began to whine.
“It is cold. See it is snowing. I want to go to Hawaii,” she said.
“I want to go to Hawaii too, but I am not allowed to fly,” I replied.
“So I will go by myself to help out at SQL Saturday in Honolulu,” she threatened.
I pulled up a picture I had taken during our last trip to Honolulu to teach a Windows PowerShell class. Warm aqua water, deep sapphire blue skies, and snowflake white beaches peer playfully in the distance behind my favorite tree, the palm tree. This idyllic scene appears in the following figure.
“Hmmm …,” I uttered, “if I am still unable to fly when SQL Saturday rolls around, why don’t you go ahead and pop out there. You can bring me back some Kona coffee, a box of chocolate covered Macadamia nuts, and a Sugar Loaf Pineapple.”
Speaking of things that are sweet, SG, you can indeed store your scripts on a centralized network share. In fact, I do this very thing because it provides quick access to the scripts I use for both client and server deployment.
Of course, accessing scripts from a remote share could cause you to have problems with the script execution policy. In fact, running scripts in and of themselves can sometimes cause problems with the script execution policy. For more information, see “The Scripting Wife Sets the Script Execution Policy” Hey, Scripting Guy! Blog post.
By default, when Windows 7 is installed, or when Windows PowerShell is installed, the script execution policy is set to restricted. You can use the Get-ExecutionPolicy Windows PowerShell cmdlet to verify the setting of the Windows PowerShell execution policy. This is seen here.
PS C:\> Get-ExecutionPolicy
Restricted
PS C:\>
When the script execution policy is set to restricted no Windows PowerShell scripts will run. It does not matter if the script resides on a remote server in a file share, or if the script is located in a local folder. This is seen in the following figure.
If you only want to run a script from a remote share without modifying the default script execution policy, you can use the bypass switch when launching Windows PowerShell. You can specify the path to the script by using the file parameter. This is seen in the following figure.
You can also open up a Windows PowerShell console with the bypass policy set by using the following command to launch Windows PowerShell.
powershell -executionpolicy bypass
After you have a Windows PowerShell console that is running in bypass mode for the execution policy, you can run the remote script. This seen here.
PS C:\Users\ed.NWTRADERS> \\hyperv-box\shared\bios.ps1
SMBIOSBIOSVersion : A06
Manufacturer : Dell Inc.
Name : Phoenix ROM BIOS PLUS Version 1.10 A06
SerialNumber : BDY91L1
Version : DELL – 15
To modify the Windows PowerShell script execution policy, use the Set-ExecutionPolicy Windows PowerShell cmdlet and specify the desired new level. This command must be launched as an Administrator. On Windows Vista or later, this means right-clicking on the Windows PowerShell console, and selecting Run As Administrator from the action menu. On earlier versions of Windows it means using the RunAs command to run with different credentials. If you try to use the Set-ExecutionPolicy cmdlet without admin rights, an error will be displayed. This is seen in the following figure.
In an enterprise setting, Group Policy should be used to control the Script Execution policy.
Interestingly, admin rights are not required to launch PowerShell in bypass mode. Remember, the script execution policy is not a Security feature. It is a convenience feature. In a car, a seat belt actually protects you, and is therefore a security feature. The beeper that annoys you until you put the seat belt on is a convenience feature (i.e., it does not actually protect you). Because Windows PowerShell is simply an application such as Microsoft Word or even Solitaire, the user has the rights to launch and to use Windows PowerShell. If you want to restrict it from users, then you should use software restriction policies. But keep in mind, that would preclude you from using Windows PowerShell for your logon scripts and for many other administrative purposes.
To set the execution policy to require digital signatures if the script comes from a remote location, set the execution policy to remotesigned. The command is seen here.
Set-ExecutionPolicy remotesigned
When setting the script execution policy, I generally first see what it is, then set the policy, and then check again to make sure that I have properly set the policy. This is seen in the following figure.
After I have made the change, I immediately close the Windows PowerShell console, and open up a non-elevated Windows PowerShell console. If I try to launch a script that comes from a remote location that is not digitally signed, the error seen in the following figure appears.
The error seen in this figure is because the script was downloaded from the Internet. The file itself has the block property set. To unblock the script, right-click the script, click Properties and then click the unblock button as seen in the following figure. After the script is unblocked, it will run without any problems.
Be aware you should first examine a script to make sure that you know what it actually does! In addition, testing scripts in a Virtual Machine is a great practice to enter. Scripts that are copied from the Scripting Guys Script Repository will not be blocked (as of this writing) because you do not actually download the script. You copy it to the clipboard, and then paste it into your script editor. This makes Windows PowerShell think the script was locally generated. Therefore, it will not be blocked. As with any other script, you should also ensure you know what scripts downloaded from the Scripting Guys Script Repository do also.
What about scripts that reside on a file share inside the network? On my computer they run just fine. Keep in mind, that Windows PowerShell honors the Internet Explorer Security Zones. Therefore it depends on which security zone your intranet servers live in. The Internet Explorer Security Zones can be configured through Group Policy.
SG, that is all there is to using a file share to store Windows PowerShell scripts. Script location week will continue tomorrow when I will talk about modules.
I invite you to follow me on Twitter or Facebook. If you have any questions, send email to me at scripter@microsoft.com or post them on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
Light
Dark
0 comments