Some pretty good things happened in the world of Exchange over the last week that might have passed you by because they didn’t receive much publicity - or maybe because we're all punch drunk from the blizzard of new functionality that has appeared in Office 365. Let me bring the on-premises crowd up to date.
First, the news broke on January 9 that Microsoft had solved the technical issues that had blocked the placement of a witness server (otherwise known as the FSW) in an Azure datacenter. The idea of using Azure as a reliable arbiter between two datacenters that formed a stretched Database Availability Group (DAG) first surfaced at TechEd North America in 2013. It’s a good idea because Azure is likely to be a highly reliable resource available to both datacenters. If one datacenter goes offline, the Azure-based witness server is still available to maintain quorum and the DAG remains operational.
However, as explained in this EHLO post of August 2013, the testing proved Azure didn’t support the two site-to-site VPN connections necessary to support a persistent connection from both datacenters to the witness server. Last Friday, Microsoft announced that they now support the use of an Azure virtual machine as a witness server. Kudos to the Exchange High Availability team and Tim McMichael, the avuncular cluster support expert who apparently made a huge contribution to this advance.
This development good news for those who operate stretched DAGs but it’s unlikely to affect the plans of the vast majority of on-premises customers. Microsoft was very careful to emphasize that they do not support the use of Azure for production Exchange servers. Although lots of people use Azure for test servers and Amazon seems quite happy to support an Exchange deployment on AWS, it seems like Microsoft is not yet convinced that Azure is a good platform for Exchange. Part of this caution might be due to the need to firm up plans around support, part might be that the economics of Azure don’t yet work for Exchange, and part might be an unwillingness to create competition with the “cloud first” mantra that is encouraging customers to move Exchange workload to Office 365. As CEO Satya Nadella said last October, “Office 365 is the new Exchange.”
Meantime, to help customers move to Office 365, Microsoft increased the maximum item size that can be migrated to Exchange Online to 150MB, a six-fold increase from the previous 25MB limit dictated by the MaxSendSize (maximum message size that can be sent) limit. In fact, the 25MB limit is really 35MB as 10MB is provided to accommodate factors such as message encoding and encapsulation. But in any case, the increase is very generous and it’s all to do with helping customers move anything and everything to Office 365, including whatever horribly large items might be lurking in the depths of user mailboxes. The new limit for migration items is noted in the Office 365 December update and is now effective.
Two facts have to be remembered. First, the increase in limit is purely for migration purposes. Once a mailbox is fully operational inside Office 365 the documented limit (25MB+10MB) applies. In other words, you might be able to move very large items to Exchange Online but you won’t be able to clog up the transport pipeline by sending them on to friends and family afterwards. Second, migrating very large items from a customer server across the Internet to Office 365 is likely to be a long and potentially error-prone process. Expect some retries and lots of chances to drink coffee. But the gigantic items will eventually get there and be happy in the cloud.
The last development is actually the coolest of the lot. Customers who want to keep part of their workload on-premises use the Hybrid Configuration Wizard (HCW) to configure the connection between their on-premises Exchange organization and Exchange Online. The HCW is a great example of how to automate the many previous steps that were involved in manually setting up the connection but it’s a bit of a black box in that the HCW is fantastic when it works but doesn’t give many clues when things go wrong.
Enter the automated Hybrid Configuration Troubleshooter, which the Exchange Hybrid Team is purposely keeping quiet for the moment. You run the troubleshooter from the same server that supports the link to Exchange Online and it helps you to understand why the HCW failed. Essentially the tool collects and interprets the logs produced by the HCW to figure out where problems might lie and then guides the administrator towards a successful conclusion. The tool is its first iteration and as is the nature of troubleshooting utilities, it will probably take a couple of versions to smoothen out rough edges and become terrifically useful. The team responsible for the tool is well aware of the work that they’ve taken on and welcome feedback to [email protected].
To wrap up recent Exchange news, the development group announced on January 12 that they plan to make changes to the way that the OWA logoff process works. Details are on the EHLO blog and the changes will be effective when Exchange 2013 CU8 is released in approximately two months. The idea is to get OWA to use consistent logoff behaviour in all circumstances and that seems to be a very good thing too.
Three advances and one heads-up notice in one week is pretty good, especially when they’re all practical steps that will help customers. It would be nice if every week were similar.
Follow Tony @12Knocksinna
