I'm now returning from Exchange Connections after a busy week in Las Vegas. The sessions were superb and we had great speakers, including a cast of well-known Exchange MVPs who fully lived up to their reputation for independent advice. We also had some great sessions delivered by Tim McMichael and Wes Blalock from Microsoft. And of course, as is normal at a technical conference, everyone worked extremely hard and no fun at all outside the sessions was had by anyone.
When you leave any conference, an opportunity exists to reflect on the interesting tidbits that came up during discussions with people there. Here’s some of the topics that took my attention.
MVP Sigi Jaggott from Germany is a precise kind of guy who specializes in PowerShell management for Exchange and public folders. At least, that’s what you would assume from the sessions he has given over the last few years at various events, including Connections, MEC, and TechEd. This week, he ran into a baffling issue where his favourite Get-Mailbox cmdlet stubbornly refused to respect the Verbose parameter. As you probably know, passing the Verbose parameter is an extremely useful way to have a cmdlet give up some of its secrets and reveal the processing that it does to execute a command. When Sigi ran Get-Mailbox on his test Exchange server, it produced this result:
Many others tested Get-Mailbox and reported that it worked as expected against various updates of Exchange 2013 and against Exchange Online in Office 365. And then we discovered that a bug in Windows 2012 R2 causes Get-Mailbox to stay silent. The cmdlet still works, but it just doesn’t reveal its secrets. Microsoft is aware of the problem and the bug will be fixed in due course.
Paul Cunningham tracked down a bug in the Mailbox Replication Service (MRS) in Exchange 2013 CU6, which means that you can't move a mailbox to a database that has been excluded from mailbox provisioning (set with the IsExcludedFromProvisioning switch of the Set-MailboxDatabase cmdlet). The switch is supposed to stop Exchange automatically allocating new mailboxes to a database when they are created, but it shouldn't stop a mailbox move. No doubt Paul will be covering this issue on his excellent ExchangeServerPro.com site.
During the week we got a reminder of the importance of proper TCP configuration on Exchange servers when some reports surfaced in support forums of horrible Outlook client performance when connected to Exchange 2013. In this case, the clients were configured in online mode and so experienced the full glory of any network glitches along the way to the server. Cached Exchange mode was better because it insulates users from network problems, but online mode was needed to ensure that no data was left on client PCs.
Some suggestions about tuning the TcpAckFrequency parameter on clients seemed to help, but the real culprit appeared to be badly tuned TCP settings on the servers, specifically the “Receive Window Auto-tuning Level” and Receive-Side Scaling State (RSS) parameters, which should be set to “Normal” and “Enabled.”
It seems like a lot of the affected servers were virtualized but that’s no reason to avoid checking the configuration on all servers. A simple PowerShell command does the trick:
netsh int tcp show global
Paul Robichaux and I live on opposite sides of the Atlantic Ocean and it seemed opportune to get together in Vegas to record the first episode of our “Exchange Exposed” podcast. You'll notice from the photo above that no expense was spared in the recording studio we used!
We hope to do this on a regular basis to give us the chance to share our views on important developments and news in the world of on-premises and cloud Exchange. That means coverage of much more than the product itself, so we were very happy to be joined by Rick Vanover from Veeam to discuss how they are coping with an ever-increasing demand for tools that help companies to manage virtualized Exchange environments. The podcast will be available in the next few days.
This week, we’ve seen the first Apple iPhone 6 devices running iOS 8 reach customer hands and the inevitable question comes to mind: Will the appearance of a new version of iOS will cause any problems for ActiveSync connections to Exchange? The good news is that there haven’t been any reports about connectivity or other issues (that I am aware of) so far. The lack of bad news is testament to the work done by both Apple and Microsoft since early 2013 to eliminate erroneous client-side code and to bulletproof Exchange against rogue client requests.
If you want to check whether iOS8 devices are connecting to your servers, you can run the command:
Exchange 2010 and 2013:
Get-ActiveSyncDevice -Filter {DeviceOS -eq 'iOS 8.0 12A365'}
Exchange Online/Office 365:
Get-MobileDevice -Filter {DeviceOS -eq 'iOS 8.0 12A365'}
Get-MobileDevice works for Exchange 2013 too. The cmdlet name change indicates Microsoft’s move away from focusing on ActiveSync to a more expansive mobile connectivity strategy.
Finally, I was reminded that Exchange 2013 CU4 (and later) includes the very useful Update-ExchangeHelp cmdlet. Running the cmdlet updates the help for the set of Exchange cmdlets. You should really do this on every server where you use EMS to manage Exchange.
Leaving the bright lights of Las Vegas is never an issue for me. I’m quite happy to be going home to Dublin. Planning for next year’s event will start soon enough…
Follow Tony @12Knocksinna
