In Part 1 of this two-part post, we discussed how to troubleshoot issues users might encounter when trying to run the Exchange Management Shell. We looked at execution policy, pipelining, wrong versions, and finally PS-Remoting; how to recognize those as issues causing problems for an admin and, finally, how to fix those. In this post, we’re going to look at connectivity issues that can cause problems when trying to run the Exchange Management Shell (EMS.) Let’s jump right in.

Don’t dismiss the basics

Exchange administration is a very advanced skill, and it’s easy to assume that problems must have complex causes. However, if you jump right into the advanced issues without first confirming some of the fundamental issues, you might feel rather silly hours later when you finally get around to things like

• DNS resolution
• Windows firewall/network firewall
• Routing
• Server up
• Typos

Make sure you check these out early on when you have a problem running EMS, especially if you are running it on one machine, trying to connect to another. You might be surprised how often DNS is broken, or simple IP connectivity isn’t where you need it to be between points A and B. And always verify servernames, especially when people tend to abbreviate them or shortcut them e.g. the servername is “mailboxserver01” but admins call it “mail1.””

Authentication and Authorization

Speaking of basics, you want to make certain that the credentials you are using (or that the other admin is using, when helping others), are both valid and have the necessary permissions to access the EMS. Make sure that you read any error text that comes back when launching the EMS. If you see things like “Access Denied” in there, there’s a pretty good chance that the user is launching EMS using credentials that don’t have permission to access EMS on any Exchange server, or if they are providing creds in the launch command, they fat-fingered the password.

Wrong VDir

The EMS relies upon IIS when connecting to a remote Exchange server, so if you see a 403 response in the error output when trying to launch EMS, then either the default virtual directory has been changed, or you specified an incorrect path in your launch script.

Certificate errors

When using HTTPS, if the machine launching EMS does not trust the certificate used to secure the session, you will see an error response that includes the words “unknown certificate authority.” You will either need to install the root (and any intermediate) CAs into the client’s certificate store, or obtain a certificate from a trusted CA for the Exchange server. Of course, you could also use HTTP instead of HTTPS.

Incorrect Authentication method

Exchange wants to use Kerberos to authenticate connections to EMS. If you specify a different authentication method, such as Basic, but the VDir is not configured to allow that method, you will see an error. If the computer is not trusted for delegation, you will also see an error. You can reconfigure the IIS directory to allow another method, but you should fix the delegation issue and use Kerberos.

If you run into connectivity based issues when trying to launch the EMS, the information above should help you resolve those quickly. Just remember to check the basic, and then to actually read the response in any error. The answers are in there if you just take the time to look!

More information on troubleshooting EMS can be found on TechNet at http://technet.microsoft.com/en-us/library/dd351136(v=EXCHG.141).aspx. 

Be Sociable, Share!

•