How nice: Microsoft is now monitoring my Office 365 email

I hear that the much-trumpeted doubling of Exchange Online mailbox sizes to 50GB isn’t going to plan and not all tenant domains will be upgraded to the new quotas by the end of 2013. The new date is apparently “by the end of the first quarter of 2014”, which is soon enough. I cannot imagine that there are hordes of Office 365 subscribers waiting to stuff their mailboxes with sufficient junk to fill the new quotas. Then again, perhaps a great gnashing of teeth will arise due to the delay. We shall see.

In other Office 365 news, KB2891160 informs us that:

“Starting with the latest update of Microsoft Outlook 2013, Microsoft is collecting additional information from client computers that connect to the Office 365 service. This information will help the Office 365 team to identify client connectivity issues and resolve them faster. “

The thought that Big Brother (sorry, Microsoft) is monitoring my interaction with Exchange Online swims into my mind. Sure, Microsoft says that the kind of interaction they want to observe is:

And I’m certain that they will capture and analyze this data. But I am equally sure that the conspiracy theorists will have a field day with this news as they’ll imagine how Microsoft will now be silently monitoring the flow of communication between Outlook 2013 and Exchange Online as users send notes to bosses begging off work because of a mythical cold, or perhaps a note to a potential lover describing just how ardent their desire is… And is this kind of monitoring already in place for Outlook Web App (OWA) or mobile clients?  Taken to the extreme, you could imagine that this is the Microsoft equivalent of Google reading your Gmail to decide what ads should be presented alongside messages. Not that capturing some performance and connectivity data can ever be compared to analyzing the text of messages for marketing purposes!

In other news, a potential flaw in Exchange 2013 CU3 has come to light in that the ExternalURL property for the ActiveSync (EAS) virtual directory can be blanked by the update. To be fair to Microsoft, I did not observe the problem during my CU3 upgrade but sufficient data exists from other installations to indicate that a problem exists. This is similar to previously reported issues with upgraded servers "losing" the external URLs that Exchange publishes with Autodiscover to allow clients to connect to services like OWA. (Click here for a really good article about configuring virtual directories for Autodiscover).

Microsoft updated the code to ensure that the URLs for OWA and the Exchange Adminstration Center (EAC) are preserved during upgrades. Unfortunately, it seems that CU3 doesn't preserve the EAS URL. It's possible that Microsoft prioritized the fixes for OWA and ECP because if these URLs are missing OWA or EAC clients cannot connect to Exchange externally. By comparison, some EAS clients only use Autodiscover when a new connection is set up so the sudden blanking of the URL has no effect on clients that had connected prior to CU3.  The configuration process used by many mobile clients to create a new EAS connection to Exchange is usually automated and depends on the information returned by Autodiscover and the lack of an Autodiscover URL will prevent the configuration process working. 

The Get-ActiveSyncVirtualDirectory cmdlet can be used to check that the ActiveSync external URL is present on servers hosted the Client Access role following the upgrade to CU3. If required, the fix is simple and takes about 5 seconds by running the Set-ActiveSyncVirtualDirectory cmdlet with EMS. Of course, this leads to all sorts of questions why the Exchange setup program can't maintain the URL. In the example shown below, I set the value for the External URL for the ExServer1 server. 

Set-ActiveSyncVirtualDirectory -Server "ExServer1"  -ExternalUrl "https://ExServer1.contoso.com/Microsoft-Server-ActiveSync"

All of this goes to prove that it's a good idea to document the settings of Exchange servers before applying upgrades so that you know where changes have occurred and what the proper values are, should you need to reset a value. It's also a good idea to use Microsoft's Remove Connectivity Analyzer to test client connections to upgraded servers before exposing them to users.

Finally (for now), one of the items that might have surprised when you read the EHLO post announcing the arrival of Exchange 2013 CU3 was the assertion that:

“We would like to call attention to an important fix in Exchange Server 2013 Cumulative Update 3 which impacts customers who rely upon Backup and Recovery mechanisms to protect Exchange data. Cumulative Update 3 includes a fix for an issue which may randomly prevent a backup dataset taken from Exchange Server 2013 from restoring correctly. Customers who rely on Backup and Recovery in their day-to-day operations are encouraged to deploy Cumulative Update 3 and initiate backups of their data to ensure that data contained in backups may be restored correctly. “

Details of the backup problems fixed in CU3 are available in KB2888315. They certainly seem to be issues that you wouldn’t overlook, like a VSS writer not being able to determine the transaction log file signature for a database that you want to back up (essential to know what log files can be truncated following a successful backup or to indicate what log files are necessary if a database is restored from a backup). As such, it is kind of weird that this problem managed to survive the RTM release and two cumulative updates without being fixed.

The thought therefore comes to mind that backups might not be as important as they once were. After all, in the bad old days when Exchange supported just a single database and storage controllers and disks were not as reliable as they are today, database corruptions and the resultant restores were pretty common. Today, multiple database copies running inside Database Availability Groups (DAGs) (remember, two copies is barely adequate; three is much better; four is a warm feeling of comfort) mean that backups are less essential because they are not the administrator’s primary recovery method. So maybe there is some truth in the proposition that some Microsoft evangelists have been touting since DAGs first appeared that backups are no longer required because Exchange can take care of itself. Or is it simply that few companies have yet deployed Exchange 2013 into production and those that have aren’t too worried about backups?

Or it might just be that those 2112 and 2180 events have slipped by and backup failures have not been noticed. That would never happen, would it? It's time to test and install Exchange 2013 CU3 to make sure that your backups work.

Follow Tony @12Knocksinna