Exchange Server 2007 has several cmdlets built into Exchange Management Shell (EMS). You can also create custom cmdlets to automate tedious or repetitive tasks in Exchange 2007. But one common problem experienced after creating your own cmdlets is getting them to run. Here's what you need to know about cmdlet execution, including PowerShell policy settings, and how to create your own custom cmdlet library.
The Exchange Management Shell is built on Windows PowerShell, a rich scripting environment. A problem with PowerShell is that Microsoft focused heavily on security to prevent that environment from becoming the ultimate tool for creating viruses, Trojans and other types of malicious scripts. Therefore, Microsoft limited what can be done through PowerShell.
EMS has several built-in cmdlets, but you're restricted in what you can do with them. You're allowed to include calls to all built-in cmdlets as well as those that you build. For example, Get-Mailbox is a built-in cmdlet; it's also acceptable to include this command within a self-designed cmdlet.
You can't, however, modify any built-in cmdlets. The cmdlets you make exist as .PS1 files, while Microsoft embedded built-in cmdlets in a .DLL file to prevent tampering. In addition, you can't make a direct call to a custom cmdlet.
For example, if you were to create a cmdlet named TEST.PS1, you wouldn't be able to run it by opening the Exchange Management Shell and entering TEST.PS1. Instead, you must enter the full path to the cmdlet, even if the .PS1 file resides in the current directory. Therefore, entering TEST.PS1 would be invalid; entering something like C:\TEMP\TEST.PS1 would be valid.
Microsoft also included execution policy settings in PowerShell to prevent scripts from being executed accidentally. There are three built-in execution policies.
To continue reading for free, register below or login
To read more you must become a member of SearchExchange.com
>AllSigned -- This policy means that PowerShell scripts will not execute unless a trusted certificate authority has digitally signed the script.
RemoteSigned -- When this policy level is in effect, any scripts that have been downloaded from the Internet must be signed, but local scripts don't have to be signed.
Unrestricted -- As the name implies, when this policy level is in effect, Windows allows any PowerShell script to execute, regardless of whether or not it's been digitally signed.
Having a choice of execution policies raises the question of which policy is in effect, and how you can change policies if you want to. You can check the current execution policy by opening either PowerShell or Exchange Management Shell and entering:
Get-ExecutionPolicy
A native PowerShell deployment will use the AllSigned execution policy by default. When you install Exchange 2007 onto a server, the execution policy is set to RemoteSigned. If the execution policy is set to RemoteSigned, you should be able to execute any cmdlets you create, as long as they reside on the server.
Creating a custom cmdlet library
As you work with PowerShell, you'll eventually grow more comfortable with it. Over time, you'll probably start accumulating a collection of custom cmdlets. I recommend setting up a cmdlet library, which is simply a collection of cmdlets.
I don't think Microsoft has any official guidelines for setting up a cmdlet library. If you only have a single Exchange 2007 server, creating the library is as easy as creating a folder on the server and copying the cmdlets to it.
If you have multiple Exchange 2007 servers, then you'll probably want the cmdlets to reside on each server. One way to accomplish this is to create a distributed file system (DFS) tree in which the folder containing cmdlets is replicated to each Exchange 2007 server.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
