System administrators are constantly dealing with different and, often times, confusing problems. When troubleshooting a problem it is extremely important to review when changes were made to the system or application and also when problem or error messages first showed up. Sometimes the changes we make in one area can have an impact on other areas within the system. Unexpected results such as the loss of data or the loss of objects can happen when we make seemingly innocuous changes. And when this happens we are usually unaware of the fact that we have introduced a new problem into a working system or application. This can happen when there are dependencies that are not fully documented and that we don’t know about before making a change.
In order to find out how to fix this issue, we should know what it is exactly that we are implementing. We should also know everything that is going to be affected by this change. As much as we feel that we can make, break and fix anything it is still very helpful to read the complete descriptions of the install we will be performing and to be alert about how the system is performing before we make any changes. Remember to have an exit strategy before you make changes to a system and to know all the steps to take in order to back out any changes you make should you decided that something has gone wrong with your system. Most likely you will find that there has been a missed step and/or an incorrectly applied command.
One example of when procedures can go wrong is when you are using the Remote PowerShell.
In Exchange 2010 all management is done via Remote PowerShell. Where this differs from Exchange 2007 is that there is a greater dependency on Internet Information Server (IIS). With Exchange 2007 server, remote PowerShell requests are sent using the HTTP protocol which uses IIS to make its connections. And IIS works with WinRM, and WSMan protocol to initiate the connection.
The Exchange Management Shell (EMS) is a very integrated command oriented interface, built on Windows PowerShell v2. Using it allows you to become the admin that has the authority to perform day-to-day management of your mailboxes. It can also allow you to work as a developer who might need to automate administrative tasks using custom code. Either way, the Shell enables you to perform a lot of management functions and to make changes to your system.
When using EMS or the Exchange Management Console (EMC) on Exchange 2010 we can run into a couple problems. Although EMS and EMC are important functions to use with Exchange, it is important to ensure that configuration settings are correct and that user privileges are also set up correctly. When something changes these functions the results can range from minor annoyance to major disasters. Make sure that you know of the effects of your implementation because, if set incorrectly, it could result in errors that you never expect to happen.
One example is when you receive an error message such as:
- The connection to the specified remote host was refused. Verify that the WS-Management service is running on the remote host and configured to listen for requests on the correct port and HTTP URL. For more information, see the about_Remote_Troubleshooting Help topic.
This error usually happens when we are trying to open up either the Exchange 2010 EMS or EMC function. The cause behind this error can be one of the following conditions:
- The user does not have Remote PowerShell Enabled status.
- Windows Remote Management (WinRM) is configured incorrectly on the server.
- The MSExchangePowerShellAppPool application pool is experiencing problems or is not running.
To resolve issue #1 and #3 we are going to need access to a user’s account that has Remote PowerShell Enabled. After getting access to this account, follow these steps:
- Make sure that the MSExchangePowerShellAppPool application pool is running. If the pool is running, try to recycle it. Then, check for errors or warnings in the event logs.
- Make sure that the user who is trying to connect has Remote PowerShell Enabled status. To determine whether a user is enabled for Remote PowerShell, start Exchange Management Shell by using an account that has been enabled, and then run the following query:
- “(Get-User <username>).RemotePowershellEnabled”
- This query returns a response of True or False. If the response is False, the user is not enabled for Remote PowerShell. To enable the user, run the following command:
- “Set-User <username> -RemotePowerShellEnabled $True”
For resolving issue #2 you need to make sure that WinRM is configured correctly on the server. To do this, follow these steps:
- Run WinRM Quick Config. Click Start, type WinRM Quick Config in the Start Search box, and then press ENTER.
- Make sure that both tests pass and that no actions are required. If any actions are required, click Yes in the prompt window to allow the WinRM configuration changes to be made.
- Click Start, type cmd in the Start Search box, and then press ENTER. In the Command Prompt window, type WinRM enumerate winrm/config/listener at the command prompt, and then press ENTER.
- Make sure that a listener exists for the HTTP protocol on port 5985, and that the listener is listening on all addresses.
Having this knowledge ahead of time can help to avoid unexpected problems and also help to save time for higher priority administration projects.