Tag Archives: Office 365

Executive summary: there aren’t any, so plan accordingly.

Recently I was working with a customer (let’s call him Joe, as in “Joe Customer”) who was considering moving to Office 365. They went to our executive briefing center in Austin, where some Dell sales hotshots met and briefed them, then I joined in via Lync (with video!) for a demo. The demo went really well, and I was feeling good about our odds of winning the deal… until the Q&A period.

“How does Office 365 provide mailbox-level backups?” Joe asked.

“Well, it doesn’t,” I said. “Microsoft doesn’t give you direct access to the mailbox databases. Instead, they give you deleted item retention, plus you can use single-item retention and various types of holds.” Then I sent him this link.

“Let me tell you why I’m asking,” Joe retorted after skimming the link. “A couple of times we’ve lost our CIO’s calendar. He uses an Outlook add-in that prints out his calendar every day, and sometimes it corrupts calendar items. We need to be able to do mailbox-level backups so that we can restore any damaged items.”

At that point I had to admit to being stumped. Sure enough, there is no Office 365 feature or capability that protects against this kind of logical corruption. You can’t use New-MailboxExportRequest or the EAC to export the contents of Office 365 mailboxes to PST files. You obviously can’t run backup tools that run on the Exchange server against your Office 365 mailbox databases; there may exist tools that use EWS to directly access a mailbox and make a backup copy, but I don’t know of any that are built for that purpose.

I ran Joe’s query past a few folks I know on the 365 team. Apart from the (partially helpful) suggestion not to run Outlook add-ins that are known to corrupt data, none of them had good answers either.

While it’s tempting to view the inability to do mailbox-level backups as a limitation, it’s perfectly understandable. Microsoft spent years trying to get people not to run brick-level backups using MAPI. The number of use cases for this feature is getting smaller each year as both the data-integrity and retention features of Exchange get better. In fact, one of the major reasons that we now have single-item recovery in its current form is because customers kept asking for expanded tools to recover deleted items, either after an accidental deletion or a purge. Exchange also incorporates all sorts of infrastructure to protect against data loss, both for stored data and data in transit, but nothing really helps in this case: the corrupt data comes from the client, and Exchange is faithfully storing and replicating what it gets from the client. In fairness, we have seen business logic added to Exchange in the past to protect against problems caused by malformed calendar entries created by old versions of Outlook, but clearly Microsoft can’t do that for every random add-in that might stomp on a user’s calendar.

A few days after the original presentation, I sent Joe an email summarizing what I’d found out and telling him that, if mailbox-level backup was an absolute requirement, he probably shouldn’t move those mailboxes to Office 365.

The moral of this story, to an extent that there is one, is that Microsoft is engineering Office 365 for the majority of their users and their needs. Just as Word (for instance) is supplemented by specialized plugins for reference and footnote tracking, mathematical typesetting, and chemistry diagrams, Exchange has a whole ecosystem of products that connect to it in various ways, and Office 365 doesn’t support every single one of those. The breadth and diversity of the Exchange ecosystem is one of the major reasons that I expect on-premises Exchange to be with us for years to come. Until it finally disappears, don’t forget to do some kind of backups.

Remember when I posted about the 100GB limit for Personal Archive mailboxes in Office 365? It turns out that there was another limit that almost no one knew about, primarily because it involves mailbox retention. As of today, when you put an Office 365 mailbox on In-Place Hold, the size of the Recoverable Items folder is capped at 30GB. This is plenty for the vast majority of customers because a) not many customers use In-Place Hold in the first place and b) not many users have mailboxes that are large enough to exceed the 30GB quota. Multiply two small numbers together and you get another small number.

However, there are some customers for whom this is a problem. One of the most interesting things about Office 365 to me is the speed at which Microsoft can respond to their requests by changing aspects of the service architecture and provisioning. In this case, the Exchange team is planning to increase the size of the Recoverable Items quota to 100GB. Interestingly, they’re actually starting by increasing the quota for user mailboxes that are now on hold— so from now until July 2014, they’ll be silently increasing the quota for those users. If you put a user on hold today, however, their quota may not be set to 100GB until sometime later.

If you need an immediate quota increase, or if you’re using a dedicated tenant, you’ll still have to use the existing mechanism of filing a support ticket to have the quota increased.

There’s no public post on this yet, but I expect one shortly. In the meantime, bask in the knowledge that with a 50GB mailbox, 100GB Personal Archive, and 100GB Recoverable Items quota, your users probably aren’t going to run out of mailbox space any time soon.

I don’t usually put on my old man hat, but indulge me for a second. Back in February 2000, in my long-forgotten column for TechNet, here’s what I said about single-factor passwords:

I’m going to let you in on a secret that’s little discussed outside the security world: reusable passwords are evil.

I stand by the second half of that statement: reusable passwords are still evil, 14 years later, but at least the word is getting out, and multi-factor authentication is becoming more and more common in both consumer and business systems. I was wrong when I assumed that smart cards would become ubiquitous as a second authentication factor; instead, the “something you have” role is increasingly often filled by a mobile phone that can receive SMS messages. Microsoft bought into that trend with their 2012 purchase of PhoneFactor, which is now integrated into Azure. Now Microsoft is extending MFA support into Outlook and the rest of the Office 2013 client applications, with a few caveats. I attended a great session at MEC 2014 presented by Microsoft’s Erik Ashby and Franklin Williams that both outlined the current state of Office 365-integrated MFA and outlined Microsoft’s plans to extend MFA to Outlook.

First, keep in mind that Office 365 already offers multi-factor authentication, once you enable it, for your web-based clients. You can use SMS-based authentication, have the service call you via phone, or use a mobile app that generates authentication codes, and you can define “app passwords” that are used instead of your primary credentials for applications— like Outlook, as it happens— that don’t currently understand MFA. You have to enable MFA for your tenant, then enable it for individual users. All of these services are included with Office 365 SKUs, and they rely on the Azure MFA service. You can, if you wish, buy a separate subscription to Azure MFA if you want additional functionality, like the ability to customize the caller ID that appears when the service calls your users.

With that said, here’s what Erik and Franklin talked about…

To start with, we have to distinguish between the three types of identities that can be used to authenticate against the service. Without going into every detail, it’s fair to summarize these as follows:

• Cloud identities are homed in Azure Active Directory (AAD). There’s no synchronization with on-premises AD because there isn’t one.
• Directory sync (or just “dirsync”) uses Microsoft’s dirsync tool, or an equivalent third-party tool, to sync an on-premises account with AAD. This essentially gives services that consume AAD a mostly-read-only copy of your organization’s AD.
• Federated identity uses a federation broker or service such as Active Directory Federation Services (AD FS), Okta, Centrify, and Ping to allow your organization’s AD to answer authentication queries from Office 365 services. In January 2014 Microsoft announced a “Works With Office 365 – Identity” logo program, so if you don’t want to use AD FS you can choose another federation toolset that better meets your requirements.

Client updates are coming to the Office 2013 clients: Outlook, Lync, Word, Excel,  PowerPoint, and SkyDrive Pro. With these updates, you’ll see a single unified authentication window for all of the clients, similar (but not necessarily identical) to the existing login window you get on Windows when signing into a SkyDrive or SkyDrive Pro library from within an Office client. From that authentication window, you’ll be able to enter the second authentication factor that you received via phone call, SMS, or authentication app. During the presentation, Franklin (or maybe Erik?) said “if you can authenticate in a web browser, you can authenticate in Office clients”— very cool. (PowerShell will be getting MFA support too, but it wasn’t clear to me exactly when that was happening).

These client updates will also provide support for two specific types of smart cards: the US Department of Defense Common Access Card (CAC) and the similar-but-civilian Personal Identity Verification (PIV) card. Instead of using a separate authentication token provided by the service, you’ll plug in your smart card, authenticate to it with your PIN, and away you go.

All three of the identity types of these methods provide support for MFA; federated identity will gain the ability to do true single sign-on (SSO) jn Office 2013 clients, which will be a welcome usability improvement. Outlook will get SSO capabilities with the other two identity types, too.

How do the updates work? That’s where the magic part comes in. The Azure Active Directory Authentication Library (ADAL) is being extended to provide support for MFA. When the Office client makes a request to the service the service will return a header that instructs the client to visit a security token service (STS) using OAuth. At that point, Office uses ADAL to launch the browser control that displays the authentication page, then, as Erik puts it, “MFA and federation magic happens transparent to Office.” If the authentication succeeds, Office gets security tokens that it caches and uses for service authentication. (The flow is described in more detail in the video from the session, which is available now for MEC attendees and will be available in 60 days or so for non-attendees).

There are two important caveats that were a little buried in the presentation. First is that MFA in Outlook 2013 will require the use of MAPI/HTTP. More seriously, MFA will not be available to on-premises Exchange 2013 deployments until some time in the future. This aligns with Microsoft’s cloud-first strategy, but it is going to aggravate on-premises customers something fierce. In fairness, because you need the MFA infrastructure hosted in the Microsoft cloud to take advantage of this feature, I’m not sure there’s a feasible way to deliver SMS- or voice-based MFA for purely on-prem environments, and if you’re in a hybrid, then you’re good to go.

Microsoft hasn’t announced a specific timeframe for these updates (other than “second half calendar 2014”), and they didn’t say anything about Mac support, though I would imagine that the rumored v.next of Mac Office would provide this same functionality. The ability to use MFA across all the Office client apps will make it easier for end users, reducing the chance that they’ll depend solely on reusable passwords and thus reducing the net amount of evil in the world— a blessing to us all.