You can accomplish many tasks by executing individual cmdlets or running multiple commands in a pipeline, but there may be times where you want to create a script that performs a series of operations or that loads a library of functions and predefined variables and aliases into the shell. In this recipe, we'll take a look at how you can create and run scripts in the shell.
Let's start off by creating a basic script that automates a multi-step process. We'll start up a text editor, such as Notepad, and enter the following code:
param( $name, $maxsendsize, $maxreceivesize, $city, $state, $title, $department ) Set-Mailbox -Identity $name ` -MaxSendSize $maxsendsize ` -MaxReceiveSize $maxreceivesize Set-User -Identity $name ` -City $city ` -StateOrProvince $state ` -Title $title ` -Department $department Add-DistributionGroupMember -Identity DL_Sales ` -Member $name
Next, we'll save the file on the
C:\drive using the nameUpdate-SalesMailbox.ps1.We can then run this script and provide input using parameters that have been declared using the
paramkeyword:C:\Update-SalesMailbox.ps1 -name testuser ` -maxsendsize 25mb ` -maxreceivesize 25mb ` -city Phoenix ` -state AZ ` -title Manager ` -department Sales
When the script runs, the specified mailbox will be updated with the settings provided.
The concept of a PowerShell script is similar to batch files used with cmd.exe, but, instead of a .bat extension, PowerShell scripts use a .ps1 extension. To create a script, you can use a basic text editor such as Notepad or you can use the Windows PowerShell Integrated Scripting Environment (ISE).
Just like a function, our script accepts a number of parameters. As you can see from the code, we're using this script to automate a task that modifies several properties of a mailbox and add it to a distribution group. Since this requires the use of three separate cmdlets, it makes sense to use a script to automate this task.
If we wanted to run this script against a collection of mailboxes, we could use a foreach loop, as shown:
foreach($i in Get-Mailbox -OrganizationalUnit contoso.com/sales) { c:\Update-SalesMailbox.ps1 -name $i.name ` -maxsendsize 100mb ` -maxreceivesize 100mb ` -city Phoenix ` -state AZ ` -title 'Sales Rep' ` -department Sales }
Here you can see we're simply looping through each mailbox in the Sales OU and running the script against each one. You can modify the script to run any number of cmdlets. Also, keep in mind that although we're using parameters with our script, they are not required.
Think of a script as the body of a function. We can use the same three phases of execution such as Begin, Process, and End blocks, and add as many parameters as required. You may find it easier to create all of your code in the form of functions as opposed to scripts, although one of the nice things about scripts is that they can easily be scheduled to run as a task using the task scheduler.
Here's something that seems a little strange at first and might take a little getting used to. When you want to execute a PowerShell script in the current directory, you need to prefix the command with a dot slash (.\) as shown:
[PS] C:\>.\New-SalesMailbox.ps1
We can use either the forward or backslash characters; it doesn't matter which. This is just a security mechanism which prevents you from executing a script in an unknown location. As you might expect, you can still run a script using its full path, just as you would with an executable or batch file.
Another thing to be aware of is the concept of dot-sourcing a script. This gives us the ability to execute commands in a script and also load any custom aliases, functions, or variables that are present within the script into your PowerShell session. To dot-source a script, use the dot operator: type a period, followed by a space, and then the path to the script as shown next:
[PS] C:\>. .\functions.ps1
This technique can be used to load functions, modules, variables, and aliases from within other scripts.
Windows PowerShell implements script security to keep unwanted scripts from running in your environment. You have the option of signing your scripts with a digital signature to ensure that scripts that are run are from a trusted source. In order to implement this functionality, PowerShell provides four script execution modes that can be enabled:
Restricted: In this mode the scripts will not run even if they are digitally signed
AllSigned: In this mode all scripts must be digitally signed
RemoteSigned: In this mode you can run local scripts, but scripts downloaded from the Internet will not run
Unrestricted: In this mode all scripts will run whether they are signed or not, or have been downloaded from an Internet site
The default execution policy on a machine is Restricted. When you install Exchange 2013 on a server, or the Exchange Management Tools on a workstation, the execution policy is automatically set to RemoteSigned. This is required by Exchange in order to implement the remote shell functionality.
It is possible to manage Exchange 2013 through PowerShell remoting on a workstation or server without Exchange Tools installed. In this case, you'll need to make sure your script execution policy is set to either RemoteSigned or Unrestricted. To set the execution policy, use the following command:
Set-ExecutionPolicy RemoteSigned
Make sure you do not change the execution policy to AllSigned on machines where you'll be using the Exchange cmdlets. This will interfere with importing the commands through a remote PowerShell connection which is required for the Exchange Management Shell cmdlets to run properly.
You can reference the help system on this topic by running Get-Helpabout_Execution_Policies.