The essential guide to PowerShell in Exchange
A comprehensive collection of articles, videos and more, hand-picked by our editors
Microsoft built the new version of its Exchange Management Shell on top of Windows PowerShell 2.0 and WinRM for Exchange Server 2010, giving administrators a way to perform admin tasks on remote servers without installing Exchange tools on local systems.
Exchange Server 2007 was also built on top of Windows PowerShell, but its Exchange Management Shell (EMS) was a bit limited, and administrators had to run Exchange Management Console commands locally on the server console.
How to establish a remote EMS connection
You can establish a remote EMS session from any supported operating system (Windows XP, 2003, Vista, 7, 2008, or 2008 R2). Even though Exchange Server 2010 runs on a 64-bit operating system, you shouldn't have any trouble establishing a remote EMS session from a supported 32-bit OS. This is because Exchange Server binaries don't need to be installed on the remote client.
That said, you can't just fire up a copy of Windows XP and start managing Exchange. Before you can establish a remote EMS session, you must install Windows PowerShell 2.0 and WinRM 2.0 on the client computer.
$CertCheck = New-WSManSessionOption –SkipCACheck –SkipCNCheck -SkipRevocationCheck
$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri http://<your exchange server’s FQDN>/PowerShell/ -Credential $cred –SessionOption $CertCheck
The first line of code shown above isn’t always necessary, but you may find it easier to establish a remote EMS session if you use it. It is designed to bypass the certificate requirement. You'll also notice that the third line of code ends with –SessionOption $CertCheck. This parameter refers to the $CertCheck variable that was declared in the first line of code. Therefore, if you decide not to use the first line of code, you'll need to omit the –SessionOption $CertCheck parameter as well.
Note: The code listed above will only work if the workstation running PowerShell has been configured to use an execution policy that allows scripts to run. This holds true even if you don’t plan on running scripts. You can change the execution policy by using the Set-ExecutionPolicy cmdlet.
When you enter the PowerShell commands listed above, the final command will generate a warning message stating that some imported command names include unapproved verbs, which might make them less discoverable. This warning message is normal and is nothing to worry about.
As you can see, it's pretty simple to establish remote PowerShell connectivity to Exchange Server 2010. However, there are two things to keep in mind that will further simplify the process. First, because the client computer that is connecting to Exchange must have PowerShell 2.0 installed, you can turn the commands that I showed you earlier into a PowerShell script. By doing so, you don’t have to manually enter the commands each time you want to connect to Exchange.
The commands shown above are not the only way to connect to Exchange remotely. There are numerous ways you can modify these commands to make them better suited to your environment. For example, you could construct a script that establishes simultaneous remote sessions with all of your Exchange servers.
Having the option to remotely connect to Exchange Server 2010 is important because it greatly simplifies server management for anyone who is responsible for managing multiple Exchange servers. This is particularly useful for consultants who manage multiple clients and for Exchange server admins who support numerous Exchange 2010 servers.
Prior to the release of Exchange Server 2010, anyone who wanted to run an EMS command or a PowerShell script on multiple Exchange servers was forced to run the script or command individually on each machine. PowerShell 2.0 makes it possible to run scripts and commands against multiple Exchange 2010 servers without interacting with each individual server’s console.
Support for background processes
PowerShell 2.0 is also beneficial because it lets Exchange administrators run EMS commands and scripts in the background. If you've ever tried to run a large EMS command in Exchange Server 2007, then you know you have to wait for the command to complete before the EMS prompt returns.
Exchange Server 2010 lets you run EMS commands as jobs. These jobs can run in the background, thereby letting the administrator work on other things while the job is being processed.
ABOUT THE AUTHOR:
Brien Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.