Hybrid Headache: Modern Public folders and Exchange Online
Over the past few years, Microsoft has made many attempts to do away with public folders. If are...
Michael Van Horenbeeck MVP, MCSM
A little over two years ago, I wrote about an issue I encountered with a KEMP load balancer and how Microsoft performs hybrid mailbox moves. More specifically, the issue evolved around a seemingly different interpretation between KEMP and Microsoft regarding the implementation of the expect 100-continue header. As I noted then, the workaround was to configure the KEMP load balancer to ignore the 100-Continue rules as described in RFC 2616.
A while ago, my good friend Bhargav Shukla reached out to me informing me that KEMP had tracked and solved the problem I described back then. As it turns out, Microsoft had based their interpretation of the expect 100-Continue header on RFC 7231 which superseded RFC 2616. I believe KEMP based itself on the latter, ultimately leading to the issue I described. This illustrates that it’s not always easy to keep up with the fast pace in the tech industry…
Alas, as it turns out, KEMP seems not the only one based themselves on the older RFC-2616 specification… Recently, I was working with a client which used Barracuda load balancers. When first performing a mailbox move to Office 365, we noticed the moves were super slow: 1MB-per-hour-slow!
When examining the individual move request using the Get-MailboxStatistics –IncludeReport cmdlet, I stumbled onto the following information. Note that I omitted irrelevant information for brevity:
The error returned in the details (SourceMailboxAlreadyBeingMovedTransientException) proved all but helpful. Because moves between Exchange servers were pretty fast, I did not want to start troubleshooting there. Instead, I decided to focus on the networking gear. In front of the Exchange servers was a Barracuda load balancer I am quite unfamiliar with. The load balancer was not used to distribute traffic across severs –that would cause other problems.
Instead, two virtual services with each a single Exchange server were setup. The main reason for doing this was to have a device in between the external firewall and the internal servers. While this might sound stupid at first, it does provide an additional layer of security (even if not a lot of additional security features were enabled). Personally, I’d rather see a direct connection –but sometimes you have to make do with what you are presented with.
Regardless of my limited experience with Barracuda, I decided to take a peek anyhow and see if I could spot any glaring holes in the configuration. Sure enough, there was one setting on the Virtual Service that immediately caught my attention: “Ignore Expect Headers”. Remembering my previous endeavors, I suggested to turn on this feature and, sure enough, the mailboxes started moving and the performance was above average --if not great.
The story behind all this is that I am baffled that after all this time I am still running into the same problem which seems to affect more than a single vendor and not more attention or information about this is available. Even more so, based on the information I received from KEMP, I can only conclude like that vendors like Barracuda still seem to be following the RFC 2616 guidelines.
Although I cannot comment if this is really the case here, I would love for network equipment vendors to switch to a different default behavior. If that is impossible, at least they could do a better job of documenting what it takes to make their gear work with Office 365 hybrid deployments. After all, a hybrid mailbox move is a very popular way to onboard mailboxes.
If you have encountered similar issues with other vendors, please let me know. I’d be very interested in hearing about your experience!
