The Exchange Management Shell (EMS) is one of the best administrative features of Exchange. You get a command-line interface purpose built for scripting and automating management, and that runs as well locally as remotely. While Exchange admins, being Windows admins, still long for the GUI, the fact of the matter is that once you start using the EMS, you will soon grow to love it. There’s nothing that cannot be done at the command line. If graphical is your thing, the Exchange Management Console can do some things but you have to go the Exchange Control Panel for others. And if it’s not Exchange itself that is the issue, but more something in the underlying services or the operating system itself, the number of graphical elements you may have to use can grow quickly. But once you are in the shell, there’s nothing you cannot do, at least where Exchange is concerned, and you have a remarkable amount of ability to manage the underlying services and host operating system as well. And of course, there’s the added bonus of being able to reach out and admin remote boxes too.
But as great and powerful as the EMS is, sometimes, it has its little glitches, irks, hiccups, bumps in the road and oopses that require troubleshooting just like anything else. And since Exchange servers (or at least, users) don’t take kindly to rebooting in the middle of the day, knowing how to troubleshoot the EMS is a good thing to add to your repertoire. Troubleshooting can be divided up into client issues, and connectivity issues. In this post we’ll look at client issues.
You cannot run the Exchange Management Shell
EMS is just PowerShell after all, with the Exchange specific components loaded in, so it’s fully dependent upon a happy and healthy PowerShell. There are two things that can go wrong. The first will manifest as an error when you first try to launch the EMS referencing RemoteExchange.ps1 and the execution of scripts. RemoteExchange.ps1 is the PowerShell script that loads the components for EMS, including the launching of other scripts. If your PowerShell execution policy is not set to “RemoteSigned” or “Unrestricted” then EMS won’t be able to launch. While by default, and Exchange server should be set to “RemoteSigned” another admin working with PowerShell or setting a GPO might change this. Open PowerShell as an administrator and run the following commands to first see what setting you do have, and then to configure to “RemoteSigned.” The examples show case, but commands here are not case-sensitive.
Set-ExecutionPolicy RemoteSigned [enter]
The other situation you may encounter where you get errors running EMS is if you are not running the correct version of PowerShell. Exchange 2010 relies upon PowerShell v2. If you are running on an unpatched Windows Server 2008, or if you installed WMF 3.0 then you will have issues. Update your unpatched server or remove the WMF 3.0 since it is not compatible with Exchange 2007 or 2010 and you will be fine.
Multiple For-Each Cmdlets fail when pipelining
Windows PowerShell remoting does not support multiple pipelines in a single command. That’s important with Exchange because you are always running remote PowerShell, even when you launch EMS and target the machine you are on! To get around this limit, take the output of your first “For-Each” and store it in a variable. Then you can pipe the contents of the variable into your next “For-Each” command.
You Get an Error When Launching EMS, And Are Prompted for a Server
When you launch the EMS on an Exchange Server, it will attempt to connect to the Exchange Server you are on, even though strictly speaking it is remote PowerShell. If the local server is not configured to accept remote commands, or the service is stopped, EMS can fail, and will prompt you for another Exchange server.
First, check to make sure the Windows Remote Management service is running. Restart it if necessary. Then, open an administrative PowerShell prompt and run this command.
That will ensure that the server will accept remote commands if someone turned that off using the Disable-PSRemoting command.
More information on troubleshooting EMS can be found on TechNet at http://technet.microsoft.com/en-us/library/dd351136(v=EXCHG.141).aspx. That page is both the inspiration for, and the source of some of the content of this post. In our next post, we will look at connectivity issues.