Windows Server How-To
Working with PowerShell Scripts
Brien walks you through how to craft and excute scripts in PowerShell.
Although Windows PowerShell is probably most commonly thought of as a command line environment for administrators, it can be used for more than just running commands. PowerShell can also be used to create and run scripts. In this article I will show you how.
PowerShell scripts are useful for performing management tasks that are either complex or that need to be repeatable. For example, suppose that you routinely use PowerShell to create new user accounts and provision Exchange mailboxes. If this is something that you do often then it probably doesn't make sense to manually type the commands every time that you need to create a new user account. It's easier to create a PowerShell script. By doing a little bit of work up front you can save yourself some work in the long run. Furthermore, using a well-tested script is far less prone to administrative error than typing the commands manually each time you use them.
Of course I am only using a user account creation script as an example. Pretty much anything that you can do in PowerShell can also be scripted.
A PowerShell script is really nothing more than a text file that contains a series of PowerShell commands. Microsoft actually classifies scripts as a type of PowerShell modules. When imported, modules allow administrators to execute code that does not exist within the core command set. In essence, the script that you create has a file name, and that file name can be treated as a PowerShell command. It is worth noting however, that not all PowerShell modules are based around scripts. There are four different types of PowerShell modules, and modules are commonly used to extend the cmdlet set. For example, the Hyper-V module adds Hyper-V related cmdlets to the core cmdlet set.
There are really only two main requirements for creating a PowerShell script. First, the script must be a text file that has a file extension of .PS1. Second, the script must include code that PowerShell can run. This means sticking to native cmdlets or importing the necessary modules.
To show you how this works, let's pretend that we have a need to periodically make sure that all of the RPC services are running. We could accomplish this through the following line of code:
Get-Service RPC* | Sort-Object status
This line of code lists all of the RPC-related services, and moves any services that have stopped to the top of the list.
Now let's pretend that we want to automatically start any of the services that aren't running and then verify that the various services are running. The code required for doing so would look like this:
Get-Service RPC* | Sort-Object status
Get-Service RPC* | Where-Object {$_.Status –eq "Stopped"} | Start-Service
Get-Service RPC* | Sort-Object status
You can see how these commands work in figure 1.
[Click on image for larger view.] Figure 1. These three lines of code work together to start and verify the running of RPC services.
Although these commands work when entered manually, placing them into a script makes it possible to reuse the code in the future. You can see what such a script might look like in figure 2. As you can see in the figure, I have named the script RPC.ps1.
[Click on image for larger view.] Figure 2. This is an example of a PowerShell Script.
Running the Script
To run a script, you must navigate to the folder containing the script and then enter ./ followed by the name of the script. However, Windows disables the use of scripts by default. If you look at figure 3, you can see an error message indicating that I am not allowed to run scripts on this system. Windows disables scripts to prevent scripting attacks.
[Click on image for larger view.] Figure 3. Scripts are disabled by default.
In order to run scripts, you will have to change the server's execution policy. There are four execution policies to choose from including:
- Restricted -- Scripts are not allowed to run.
- AllSigned -- Scripts signed by a trusted publisher are allowed to run.
- RemoteSigned -- Scripts from the Internet must be signed by a trusted publisher. Scripts created locally are allowed to run.
- Unrestricted -- All scripts are allowed to run.
To change the execution policy, open a PowerShell window with elevated privileges and enter the Set-ExecutionPolicy command, followed by the execution level. For example, in figure 4, I am setting the execution policy to unrestricted and then running my script.
[Click on image for larger view.] Figure 4. The execution policy must allow scripts to be run.
PowerShell scripts can be used to automate complex tasks and to make repeat use of code possible. However, you must configure the server's execution policy prior to running your scripts.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.