Skip to main content

Resolving WinRM errors and Exchange 2010 Management tools startup failures

 Resolving WinRM errors and Exchange 2010 Management tools startup failure



Added a permissions section. in Exchange 2010 the Management tools are dependent on IIS. As was discussed in that blog, we have seen situations where the management tool connection to the target Exchange server can fail, and the error that is returned can be difficult to troubleshoot. This generally (but not always) happens when Exchange 2010 is installed on an IIS server that is already in service, or when changes are made to the IIS server settings post Exchange Install. We have seen that these changes are usually done when the IIS administrator is attempting to "tighten up" IIS security by editing the Default Web Site or PowerShell vdir settings.
The situation is further complicated by the fact that some of the errors presented have similar wording; most seem to originate with WinRM (Windows Remote Management), and in some cases different root problems can produce the exact same error message. In other words, depending on how knowledgeable you are with these errors, troubleshooting them is all around... not much fun.
I was approached by a good friend of mine and he asked what I thought we could do to make these errors a little easier to troubleshoot. I was studying PowerShell and PowerShell programming at the time (I just happened to be reading Windows PowerShell for Exchange Server 2007 SP1), and I thought that this would be a perfect opportunity to try and apply what I was learning.
This is the result.
Introducing the Exchange Management Troubleshooter (or EMTshooter for short).
What it does:
The EMTshooter runs on the local (target) Exchange server and attempts to identify potential problems with management tools connection to it.
The troubleshooter runs in 2 stages. First, it will look at the IIS Default Web Site, the PowerShell vdir, and other critical areas, to identify known causes of connection problems. If it identifies a problem with one of the pre-checks it will make a recommendation for resolving the problem. If the pre-checks pass, the troubleshooter will go ahead and try to connect to the server in the exact same way that the management tools would. If that connection attempt still results in a WinRM-style error, the troubleshooter will attempt to compare that error to a list of stored strings that we have taken from the related support cases that we have seen. If a match is found, the troubleshooter will display the known causes of that error in the CMD window. Here is an example of how this might look like:

When I was designing the troubleshooter, I could have just written a little error lookup tool that handed over the appropriate content for the error you were getting, but I felt that was not as robust of a solution as I was aiming for (and not much of a learning experience for me). So the tool runs active pre-checks before moving on to the error look-up. The amount of pre-checks it can run depends on the flavor of OS you are running on and the options you have installed on it, such as WMI Compatibility.
Basically, I have taken all of the documentation that has been created on these errors to date, and created a tool that will make the information available to you based on the error or problem it detects. Hopefully this will cut down on the amount of time it takes to resolve those problems.
Event reporting:
When you run the EMTshooter it will log events in the event log. All results that are displayed in the CMD window are also logged in the event log for record keeping.
Events are logged to the Microsoft-Exchange-Troubleshooters/Operational event log and are pretty self-explanatory.
Things to remember:
Depending on your current settings, you may need to adjust the execution policy on your computer to run the troubleshooter, using:
Set-ExecutionPolicy RemoteSigned
Or
Set-ExecutionPolicy Unrestricted
Remember to set it back to your normal settings after running the troubleshooter.
This version of the troubleshooter needs to run on the Exchange Server that the management tools are failing to connect to. While our final goal is that the troubleshooter will be able to run anywhere the Exchange Management tools are installed, the tool isn't quite there yet.
We have seen instances where corruption in the PowerShell vdir or in IIS itself has resulted in errors that seemed to be caused by something else. For instance, we worked on a server that had an error that indicated a problem with the PowerShell vdir network path. But the path was correct. Then we noticed that the PowerShell vdir was missing all its modules, and quite a few other things. Somehow the PowerShell vdir on that Exchange Server had gotten severely... um... modified beyond repair. WinRM was returning the best error it could, and the troubleshooter took that error and listed the causes. None of which solved the problem. So be aware that there are scenarios that even this troubleshooter cannot help at this time.
The troubleshooter is still a bit rough around the edges, and we plan to improve and expand its capabilities in the future. We also hope to be able to dig a little deeper into the PowerShell vdir settings as time goes on. Also note that the troubleshooter will NOT make any modification to your IIS configuration without explicitly asking you first.
Permissions required:
In order to run the troubleshooter, the user will have to have the rights to log on locally to the Exchange server (due to local nature of the troubleshooter at this time) and will need permissions to run Windows PowerShell.
Installing the troubleshooter:
First, you will need to download the troubleshooter ZIP file, which you can find here.
Installing the EMTshooter is pretty easy. Just drop the 4 files from the ZIP file into 1 folder, rename them to .ps1 and run EMTshooter.ps1 from a normal (and local) PowerShell window. I personally just created a shortcut for it on my desktop with the following properties:
C:\Windows\System32\WindowsPowerShell\v1.0\powersh ell.exe -noexit -command ". 'C:\EMTshooter\EMTshooter.ps1'"
However, as most users probably won't run this more than a few times you might not need or want an icon. Just remember that EMTshooter.ps1 is the main script to run.
Providing feedback:
As I mentioned before, the troubleshooter is still a work in progress. If you wish to provide feedback on it, please post a comment to this blog post. I will be monitoring it and replying as time allows, and also making updates to the troubleshooter if needed. If you run into errors that are not covered by the troubleshooter, please run the troubleshooter, reproduce the error through it and send me the transcript.txt file (you will find it in the folder where the 4 scripts have been placed), along with what you did to resolve the error (if the problem has been resolved). My email is sbryant AT Microsoft DOT com.
Errors currently covered:

  • Connecting to remote server failed with the following error message : The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid.
  • Connecting to remote server failed with the following error message: 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.
  • Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.
  • Connecting to remote server failed with the following error message : The WinRM client received an HTTP status code of 403 from the remote WS-Management service.
  • Connecting to the remote server failed with the following error message: The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.
  • Connecting to remote server failed with the following error message : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service:
  • Connecting to remote server failed with the following error message : The WS-Management service does not support the request.
  • Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer

source: msexchangeteam.com/archive/2010/12/07/457139.aspx

Comments

Popular posts from this blog

Question كيفية عمل share للـ outlook conntact لكل الـ Domain Users

  الحل بسيط جدا عايز الكونتاكت تتحدث دايما بحيث انك لما تضيف يوزر جديد يسمع في الكونتاكت اول حاجه بتدخل علي in office 2003 tools --- email account ---- add address book --- internet directory service (LDAP) type your server name then login info . mark this server require me to logon type any user on active directory and its password then save and close outlook and open it again now you will find all your active directory users in address book

3 things has to be done for better performance

  Tips from Goutham: 3 things has to be done for better performance: By default, XP displays extra graphic objects for menu items which can slow down your display. 1. To turn off these selectively... Right click My Computer Select Properties Click Advanced tab Under Performance, click Settings button To turn them all off, select Adjust for best performance Preference is to leave them all off except for Show shadows under mouse pointer and Show window contents while dragging 2. To speed up the display of the Start Menu Items, turn off the menu shadow. Right click open area of the Desktop Select Properties Click Appearance tab Click Effects button Uncheck Show shadows under menus 3. You can increase system performance by loading more of the system into memory. DO NOT attempt this with less then 512MBs of ram. Your system will become unstable. Click Start Click Run Enter regedit Click OK Go to HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control Session Manager Memory Management Double cli

The difference between DNS and NDS

  Novell Directory Services(NDS) - Novell Directory Services (NDS) is a popular software product for managing access to computer resources and keeping track of the users of a  network , such as a company's  intranet , from a single point of administration. Using NDS, a network administrator can set up and control a  database  of users and manage them using a  directory  with an easy-to-use graphical user interface ( GUI ). Users of computers at remote locations can be added, updated, and managed centrally. Applications can be distributed electronically and maintained centrally. NDS can be installed to run under  Windows NT , Sun Microsystem's Solaris, and IBM's  OS/390  as well as under Novell's own  NetWare  so that it can be used to control a multi-platform network. NDS is generally considered an industry  benchmark  against which other products, such as Microsoft's Active Directory, must compete. Lucent Technologies plans to integrate NDS into its own QIP product