Archive for the ‘Microsoft Exchange’ Tag

Exchange 2010 Virtualization Bans Have Been Lifted!   Leave a comment

Ok maybe I was a  little dramatic in my title but the Exchange Team recently release the following article which states some big news for companies looking to virtualize as much as possible. Here is a little snip from the article:

“As of today, the following support scenarios are being updated, for Exchange 2010 SP1, and later:

  • The Unified Messaging server role is supported in a virtualized environment.
  • Combining Exchange 2010 high availability solutions (database availability groups (DAGs)) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers, is now supported.”

For the full article please go here.

The posts are provided “AS-IS” with no warranties, and confers no rights


The Exchange Management Troubleshooter   Leave a comment

I have had several customers with Exchange Management tool issues. There are several articles by different sites on how to troubleshoot these problems. However, even though most issues are well documented it can be challenging finding the issue and getting it fixed. The below article was posted by the Exchange Team to help ease the troubleshooting process of Exchange Management tool issues with a tool called EMTshooter. I provided the direct link to the article at the bottom of this post for reference as well.  

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. 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


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\powershell.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

Steve Bryant


The posts are provided “AS-IS” with no warranties, and confers no rights

Exchange Server Performance and Data Gathering with ExCollect   Leave a comment

If you haven’t heard of it before you will wish you had. ExCollect has been around a while, developed by Jason Sherry (Exchange MVP), to help gather Exchange 2003 and 2007 information about performance and various statistical information. You can find the tool and information on how to use it here.

Please note I said 2003 and 2007. They are working on support for 2010.

This tool is useful for performance troubleshooting and during a design exercise for moving to 2010. You can use the statistical information to determine things like how many logs files are generated which is very useful when creating an Exchange 2010 DAG that will stretch across two sites.

I recommend checking it out and seeing how it can be useful to you.

The posts are provided “AS-IS” with no warranties, and confers no rights

Updated – Exchange Active Sync with Apples iOS4   Leave a comment

Check out the article by the MS Exchange Team on what issues they are seeing how they are handling them.


The fix appears to be in place for the iOS.

The posts are provided “AS-IS” with no warranties, and confers no rights.

Posted July 21, 2010 by Chris Morgan in Exchange/UC

Tagged with , , ,

Exchange 2010 Mailbox Moves – In Depth   Leave a comment

The MS Exchange team recently released a great article on Exchange 2010 mailbox moves. I recommend reading through it.

The posts are provided “AS-IS” with no warranties, and confers no rights.

Uninstalling Exchange – What mailboxes?   Leave a comment

Ever try to uninstall Exchange or remove an Exchange database only to be left with an error similar to this:

One or more users currently use this mailbox store. These users must be moved to a different mailbox store or be mail disabled before deleting this store.

Ok, no worries, you will go to look at the store and see what mailboxes exist and just delete them. Right? But when you go look there are no mailboxes in the database. What’s the deal?? Just to make sure that Exchange hasn’t gone loopy you might even reboot the server and try again. Only to be hit in the face with the same message.

Now you are sure Exchange has gone loopy so you begin to scramble on google to find out how you can get rid of Exchange so you can move on with your life. Well you are in luck. You have stumbled across this barely accessed blog of mine. 🙂

This is actually a very common issue and luckily there is a very easy fix for it. If you have never used dsquery before you are about to. My guess is you will begin to see other applications for it as well.

First we open up a command prompt.

Now type in the following command:

dsquery * DC=domain,DC=com -filter “(&(objectclass=user)(msExchHomeServerName=/o=EXOrgName/ou=AdministrativeGroupThe ServerIsIn/cn=Configuration/cn=Servers/cn=MAILSERVERName))” -attr distinguishedName > c:\mailboxes.txt

  • Replace the DN with the DN of your domain name. So if you are, the DN would be DC=corp,DC=xyz,DC=local.
  • Replace the “EXOrgName” with the Organizational Name of Exchange. This can be found at the top of your management GUI for Exchange.
  • Replace “AdministrativeGroupTheServerIsIn” with…do I really need to say it? 🙂 
  • Replace “MAILSERVERName” with the server you are trying to uninstall.

What you wind up with is an output of users with the attribute still populated. Don’t fret, this happens over time. Now that you have this list you can simple go to the user with in Active Directory Users and Computers (ADUC), right-click and remove Exchange attributes. Try uninstalling Exchange again and watch in peace and it gracefully disappears. Ahh, I love it when stuff works!

The posts are provided “AS-IS” with no warranties, and confers no rights.

Exchange Tip – Setting Quotas on all Mailbox Stores   Leave a comment

Ever have a need to set the same quota on all your mailbox stores? Here’s a simple command to help you out:

Get-MailboxDatabase | Set-MailboxDatabase -ProhibitSendReceiveQuota -ProhibitSendQuota -IssueWarningQuota

Then if you want to verify the settings:

Get-MailboxDatabase | FL Name,*quota

But I only want to assign to certain Mailbox Databases and not all. How can I do that?? Simple, you just need make sure you do a Get-MailboxDatabase that finds only the Databases you want. Like you may want all Databases on a server. So you would do:

Get-MailboxDatabase -Server MBXServerName | Set-MailboxDatabase -ProhibitSendReceiveQuota -ProhibitSendQuota -IssueWarningQuota

If you had a list of Databases in a file you could also do something like this (I haven’t tested this myself yet but should get you close if not work out of the gate).

Get-content databaselist.txt | ForEach-Object -Process {Set-MailboxDatabase -ProhibitSendReceiveQuota -ProhibitSendQuota -IssueWarningQuota }

Additionally you will want to be aware that values in quotas are in KB’s. You can specify MB or GB for the values but without it you may wind up with a 1KB mailbox instead of a 1GB mailbox, so be careful! Below is an example:

Set-MailboxDatabase -IssueWarningQuota 800MB -ProhibitSendQuota 900MB -ProhibitSendReceiveQuota 1GB

What if I want to be promted for the values? Not a problem. You could do something like this:

[string]$WRN = Read-host “Mailbox Database Warning Quota”

write-host “”

[string]$Send = Read-host “Mailbox Database Prohibit Send Quota”

write-host “”

[string]$SendRcv = Read-host “Mailbox Database Prohibit Send/Recieve Quota”

write-host “”

Write-host “Setting Mailbox Quota Values..”

Get-MailboxDatabase | Set-MailboxDatabase -ProhibitSendReceiveQuota $SendRcv -ProhibitSendQuota $Send -IssueWarningQuota $WRN

“Verifying Mailbox Quota Values…”

Get-MailboxDatabase | FL Name,*quota

Now you can take the information from the begining of this article and modify the above script to fit your needs.

Can’t have a good article without a BIG WARNING….

****Warning – testing is always a big part of ensuring desired results and avoiding catastrophic events. Verifying the limits you are setting along with using the “-Whatif” parameter will help you avoid the screaming phone call, the loud door knocking, or the devastating pink slip. 🙂

The posts are provided “AS-IS” with no warranties, and confers no rights.

%d bloggers like this: