Hopefully this will cut down on the amount of time it takes to resolve those problems. 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.īasically, 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. So the tool runs active pre-checks before moving on to the error look-up. 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). Here is an example of how this might look like: If a match is found, the troubleshooter will display the known causes of that error in the CMD window. 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 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 it identifies a problem with one of the pre-checks it will make a recommendation for resolving the problem.
First, it will look at the IIS Default Web Site, the PowerShell vdir, and other critical areas, to identify known causes of connection problems. The EMTshooter runs on the local (target) Exchange server and attempts to identify potential problems with management tools connection to it. Introducing the Exchange Management Troubleshooter (or EMTshooter for short).
#MICROSOFT EXCHANGE MANAGEMENT CONSOLE 2010 DOWNLOAD WINDOWS#
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. 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. In other words, depending on how knowledgeable you are with these errors, troubleshooting them is all around. 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. 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. 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. 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. As was discussed in the previous (related) blog post " Troubleshooting Exchange 2010 Management Tools startup issues", in Exchange 2010 the Management tools are dependent on IIS.