Thursday, 6 October 2016

Are All Your Exchange Services Running?

How any Exchange troubleshooting should start:

  1. Scratch head.
  2. Confirm all Exchange server services are running.
  3. Plot out the next steps.
I have recently been involved in troubleshooting an issue where resource automatic booking stopped working. Additionally OOF replies were not sent either.

All sorts of elaborate reasons flew through my mind as to why this may happen, from misconfiguration right down to mailbox corruption. Went through all troubleshooting steps imaginable and things that worked elsewhere with similar settings didn't work for this organization.

Then I came across Terence Luk's post here. And then I had a D'OH! moment: are the services running? Sure enough, the Microsoft Exchange Mailbox Assistants service stopped.

Started the service, tested it again, and Bingo!

As the screenshot indicates, there may be other services stopped, affecting different functionality. Services may stop randomly for random reasons. The point is that I have come across very few organizations that implement Exchange server service level monitoring and alerting.

The morale: Make it a habit to check services first before engaging in more complex troubleshooting.

Thursday, 29 September 2016

Don't Forget to Bounce the Autodiscover Application Pool

This has been widely documented but I feel the need to share my experience.

The Scenario

Mailboxes are moved from Exchange 2010 to Exchange 2013 or 2016.
Users are prompted to restart Outlook.
Outlook fails to reconfigure the profile and it doesn't connect to the mailbox on the new server.
Test E-mail AutoConfiguration fails:

The Gist

When you finish moving mailboxes from Exchange 2010 to 2013 or 2016, don't forget to restart the Autodiscover application pool on your new 2013/2016 CAS servers:

Restart-WebAppPool MSExchangeAutodiscoverAppPool

Exchange 2016 is an all-in-one server which combines all roles, but it shows as Mailbox server when doing a Get-ExchangeServer command, so you will have to bounce the pool on every Exchange 2016 server.

The Reason

It doesn't happen too often, but when it does then it can be inconvenient. I just finished moving some mailboxes from Exchange 2010 to Exchange 2016, only to be called because users' Outlook failed to connect to their mailbox.

My initial thoughts were that Outlook is not up to date and it fails to connect via MAPI-HTTP (enabled by default in Exchange 2016), or there may be a proxy (mis)configuration. It even crossed my mind that there may be a dodgy HOSTS file entry that overrides DNS settings.

None of these proved to be the case. Instead, the issue lies in the fact that the Autodiscover application on the Exchange 2013/2016 server caches configuration information. After a mailbox is moved, the application still thinks that the mailbox is on the old server. Therefore it will proxy the connection to the old Exchange 2010 server, which then bounces it back to Exchange 2016. They will be ping-ponging Outlook profile reconfiguration autodiscover requests until the Autodiscover application cache expires and the information is refreshed. The workaround is documented at and it seems to suggest that the timeout can be up to 12 hours. Recycling the application pool will refresh the cache and Outlook will connect successfully.

Therefore do yourself a favor and recycle the app pool when the moves are complete. It will improve your sleep (think supporting users in different time zones).

Even better, before you start moving mailboxes, configure the pool to recycle on a schedule, say every 5 or 10 minutes, for then you don't have to watch the progress. The steps are documented at and it boils down to the following:

Happy moving!

Friday, 9 September 2016

Think Load Balancing Before You Ditch Your Exchange DAG Administrative Access Point

With Exchange 2013 SP1, Microsoft introduced an alternative to the traditional failover cluster on which DAGs are based: no virtual IP, no Cluster Name Object, no worries. For
details see

Backup is the most quoted reason why you may still want to have an administrative access point. Backup software needs an always-on resource to connect to in order to back up
Exchange. And that is, conveniently, the cluster administrative access point. However backup software vendors are catching up with the times and they don't really need a
cluster resource anymore.

So why would you still want to have one? Well, think of inbound SMTP load balancing, and, implicitly, High Availability (HA).

Have you ever tried to load-balance SMTP? If so then you've probably encountered some or all of the following:
  • In the Exchange transport logs, all SMTP traffic appears to be coming from a single IP address - that of the load balancer. How do you tell the "real" source without looking at the e-mail headers?
  • You have a number of internal devices that need to send unauthenticated e-mail to any recipient, including external ones. Think open relay with restricted access. But if all traffic seems to come from the load balancer, then the only way to allow your multifunction device to scan a document to an external mailbox is to authorise the load balancer as approved source of unauthenticated SMTP traffic. Or you need to send e-mail alerts to an external party as par of your support agreement. Suddenly you have a security problem and a career challenge (you'll cause your organization's servers to be blacklisted in no time and you'll need to explain that to your manager).
  • Enable source routing on the load balancer. Bingo, your Exchange server sees the real source. Open relay issue solved. But hey, that will result in asymmetrical routing. Not ideal and usually difficult to diagnose if issues arise. So by solving one problem you introduced another one...

Most of these, and some other aspects, are documented in Paul Cunningham's blog at

The alternative: hang on to your cluster administrative point. The benefits:
  • You can send SMTP traffic from internal sources straight to the DAG administrative access point, bypassing the load balancer. No open relay issues, no transport log analysis issues.
  • No asymmetrical routing issues.
  • Multi-role servers are becoming the norm. In fact, with Exchange 2016, it is the only option. Therefore as long as you have at least one online DAG member, you'll also have implicitly a Hub Transport server too to accept SMTP traffic which will be reachable via the - guess what - thine good olde DAG administrative access point. Therefore service is maintained even if individual DAG members fail.
The solution has one obvious drawback: all inbound SMTP traffic will be processed without any load balancing, by a single Exchange server, the one which holds the name and IP address of the DAG
administrative access point.

As at the time of this post I am yet to see an Exchange infrastructure whith such a heavy inbound SMTP traffic that load balancing (not to be confused with HA) would be a necessity. Therefore the only drawback that I can spot is so insignificant that it can be safely discounted in most environments.

Having said that, I learned to "never say never". If you know of any circumstances where this workaround would not work then please drop me a comment.


Tuesday, 21 June 2016

Delete That Stubborn Exchange 2016 Database

Quick solution for the impatient: move/remove/disable User, Archive, Arbitration, PublicFolder and AuditLog (yes, AuditLog - new in Ex2016) mailboxes.

So you have your shiny new Exchange 2016 server, but you don't like the name and/or location of the database created for you by default. You create a new mailbox database, give it a nice name and place it on its shiny new drive.

Time to remove the default database. Well, you could technically rename it and move it elsewhere and just keep using it, but that would render the rest of the article irrelevant.

You move all user mailboxes, then what you do is:

Remove-MailboxDatabase "Mailbox Database random_number"

Bummer! That didn't work. Forgot about the various other mailbox types...

It's a new database, so no user mailboxes are on it. You check it, just in case. Then you read the eye-hurting screenful of red text and you work your way through the list of mailbox types you'll need to delete:
  • User mailboxes (we covered it above).
  • Mailbox plans - oh, you can't even run the Get-MailboxPlan command 'coz it's a cloud command and your server is on-prem. That was a tad misleading...
  • Archives
  • Public folders
  • Arbitration mailboxes
You try again and say Bummer! for the second time today. All looks clear:

Time to scratch head. Aha, forgot about the monitoring mailboxes (well, they don't need to be removed in order to delete the database, but you say "well, just in case...")...: you disable or remove the monitoring mailboxes:

Try again... Bummer, bummer, bummer! What else??? You read the Get-Mailbox online reference. You also read the output of Get-Help Get-Mailbox -Full. Nothing.

Then you hit the Web, spend the next half day searching, only to arrive here. Says the article:

Huh?... You saw the online reference and the Get-Help result, and they both say that it is not your business as an administrator to mess with the AuditLog parameter. In fact you couldn't even tell what it is for as Microsoft chose not to disclose it:

Get-Help is no different:

You follow the instructions, only to find that you do have an AuditLog mailbox. In fact Exchange creates one in the default database when it is installed - so the above article too is misleading in that it isn't straight forward about how you ended up having one.

You move/remove/disable the mailbox, try to delete the database and - BINGO!

Grab a well-deserved beer and start growing back some of the hair you pulled out.

It isn't the first time that (mis)documentation of the Remove-MailboxDatabase command caused some head-scratching. Tony Redmond blogged about it here. The Exchange team also blogged about it here, suggesting to use the -Verbose switch to figure out who is still in the database. But guess what: the -Verbose switch didn't work for me on my Exchange 2016 CU1 server:

Well, here we are a few years after Exchange 2013 has been released, and "the relevant team" (as the Microsoft blog puts it), despite its "awareness", chose to carry across the same inaccuracies in the documentation, adding some more inaccuracies to it in the process.

Tuesday, 14 June 2016

Get or Set Mailbox Database Maximum Size

Here are two scripts to get or set the maximum mailbox database size.

The scripts are based on this TechNet article. Snippets were pinched from here and there, and therefore due acknowledgement applies accordingly.

The scripts work with DAG-replicated, as well as single-copy mailbox databases, and were tested on Exchange 2010 and 2013. It should also work on Exchange 2016, however I haven't tested it.

The scripts do NOT work with Exchange 2007 as they rely on remote PowerShell which is unavailable in PowerShell v1. Remote PowerShell requirements are detailed here. Practical application examples of PowerShell remoting are here.

The scripts don't accept piped input.

Both scripts should be invoked in an elevated Exchange Management Shell console:

Getting the Maximum Database Size Limit


Get-MaximumMailboxDatabaseSize.ps1 -Database <DatabaseName>

Default size returned if no limit has been configured - maximum default size is determined by your Exchange server version and edition:

After setting the maximum size to 500Gb:

Listing the maximum size of every mailbox database in the environment:

Get-MailboxDatabase | ForEach {.\Get-MaximumMailboxDatabaseSize.ps1 $_.Name}

Output on my 2-server test system where each node has a local mailbox database, as well as a DAG-replicated database on both nodes in the DAG:

Setting the Maximum Database Size Limit

Use the Set-MaximumMailboxDatabaseSize.ps1 script to set the maximum size of a mailbox database. The script finds all servers that host a copy of the database and updates the Registry on each server.


Set-MaximumMailboxDatabaseSize.ps1 -Database <DatabaseName> -Size <New_Maximum_Database_Size_Limit_In_Gb>

Set-MaximumMailboxDatabaseSize.ps1 -Database <DatabaseName> -Default

The following command configures the maximum size of DB1 to 500Gb:

Set-MaximumMailboxDatabaseSize.ps1 -Database DB1 -Size 500

Effectively the script sets the Database Size Limit in GB Registry value as per the above TechNet article.

In order to revert the size limit to default, simply delete the Registry entry from all servers and DAG members where a copy of the database exists:

Set-MaximumMailboxDatabaseSize.ps1 -Database DB1 -Default

Licence Agreement

The scripts are licenced under the NMF (Not My Fault) agreement.
Edit, change and use the scripts at your own risk.
Give credit where due.


Enjoy :-)

Tuesday, 3 May 2016

List All SMTP Addresses for a Domain

Hi there,

Here is a quick script that lists all SMTP addresses for a given domain on an Exchange 2007/2010/2013 (and probably 2016 too) server.

The script dumps a raw, unsorted list of SMTP addresses to a text file that can be directly consumed by, say, to populate its recipient validation list (this was the purpose I produced it for).

Download it from

The NMF (Not My Fault) licence applies. Test it first and use it at your own risk.

Enjoy :-)

Sunday, 13 March 2016

Find hosts that send SMTP traffic to an Exchange server

Recently I had to identify all SMTP sources that were still sending mail via legacy servers, with a view to reconfigure them and decommission the old infrastructure.

Wrote a script that did just that for me. Download it from

An obvious prerequisite is to have Receive connector logging enabled for some time to allow traffic to be captured.

Enjoy :-)