Tag Archives: Office 365

Office 365 Personal Archives limited to 100GB

There’s a bit of misinformation, or lack of information, floating around about the use of Office 365 Personal Archives. This feature, which is included in the higher-end Office 365 service plans (including E3/E4 and the corresponding A3/A4 plans for academic organizations), is often cited as one of the major justifications for moving to Office 365. It’s attractive because of the potential savings from greatly reducing PST file use and eliminating (or at least sharply reducing) the use of on-premises archiving systems such as Enterprise Vault.

Some Microsoft folks have been spreading the good news that archives are unlimited (samples here and here), and so have many consultants, partners, and vendors– including me. In fact, I had a conversation with a large customer last week in which they expressed positive glee about being able to get their data out of on-prem archives and into the cloud.

The only problem? Saying the archives are unlimited isn’t quiiiiite true.

If you read the service description for Exchange Online (which we all should be doing regularly anyway, as it changes from time to time), you’ll see this:

Clip from Nov 2013 O365 service description

Clip from Nov 2013 O365 service description

See that little “3”? Here’s its text:

Each subscriber receives 50 GB of storage in the primary mailbox, plus unlimited storage in the archive mailbox. A default quota of 100 GB is set on the archive mailbox, which will generally accommodate reasonable use, including the import of one user’s historical email. In the unlikely event that a user reaches this quota, a call to Office 365 support is required. Administrators can’t increase or decrease this quota.

So as an official matter, there is no size limit. As a practical matter, the archive is soft-limited to 100GB, and if you want to store more data than that, you’ll have to call Microsoft support to ask for a quota increase. My current understanding is that 170GB is the real limit, as that is the maximum size to which the quota can currently be increased. I don’t know if Microsoft has stated this publicly anywhere yet but it’s certainly not in the service descriptions. That limit leads me to wonder what the maximum functional size of an Office 365 mailbox is– that is, if Microsoft didn’t have the existing 100GB quota limit in place, how big a mailbox could they comfortably support? (Note that this is not the same as asking what size mailbox Outlook can comfortably support, and I bet those two numbers wouldn’t match anyway.) I suppose that in future service updates we’ll find out, given that Microsoft is continuing to shovel mailbox space at users as part of its efforts to compete with Google.

Is this limit a big deal? Not really; the number of Office 365 customers who will need more than 100GB of archive space for individual user mailboxes is likely to be very small. The difference between “unlimited” and “so large that you’ll never encounter the limit” is primarily one of semantics. However, there’s always a danger that customers will react badly to poor semantics, perhaps because they believe that what they get isn’t what they were promised. While I would like to see more precision in the service descriptions, it’s probably more useful to focus on making sure that customers (especially those who are heavy users of on-premises archives or PST files) know that there’s currently a 100GB quota, which is why I wrote this post.

For another time: a discussion of how hard, or easy, it is to get large volumes of archive data into Office 365 in the first place. That’s one of the many topics I expect to see explored in great depth at MEC 2014, where we’ll get the Exchange team’s perspective, and then again at Exchange Connections 2014, where I suspect we’ll get a more nuanced view.

5 Comments

Filed under Office 365, UC&C

Office 365 token disclosure flaw: patch your desktops now

Happy New Year! To start the year off right, let’s talk about security. More to the point, let’s talk about Office 365 security.

One of the ways I often talk about Office 365 to customers is this: any time you move to a hosted service, you’re placing a bet that your hosting provider can do something better or cheaper than you do. Maybe they’ll deliver better uptime than you can afford to provide, or they’ll offer global reach, or some feature or function that you don’t currently have. As with any other bet, you have to carefully evaluate the odds and your counterparty (the person offering the bet). One of the big arguments in favor of Office 365 has been its security: Microsoft has invested a huge amount of money in physical and logical security for Office 365. Tie this in with the huge investment (several billion dollars and counting) brought about by Trustworthy Computing and you can see why Microsoft is eager to tout the security of their products: they have made huge strides over the last ten years. (Sadly, many other vendors are still as bad as they were back in 2005… let that thought sink in for a few minutes.)

In December, Microsoft released a patch, MS13-104, which every organization using Office 365 should immediately deploy. Microsoft rated this bulletin as “important” using their severity scale. While I understand that the “critical” severity is usually reserved for flaws that could allow remote code execution, I think this is just as bad because it allows an attacker to silently steal every document you have in a SharePoint Online document library.

Wow.

Keep this tab open, then open a new tab and use it to start figuring out how to patch your clients ASAP if you’re using SharePoint Online. Then you can come back.

I won’t repeat the excellent analysis performed by Adallom Security, the folks who reported the flaw to Microsoft in May 2013. That’s right: they reported in May 2013, and the patch was issued in December 2013. That’s a minimum of 7 months of days-of-risk, which is bad enough without considering how long this flaw was being exploited before Adallom found it. However, I do want to make a couple of additional points.

First, they wrote their post before the recent spate of disclosures surrounding the NSA’s Targeted Access Operations (TAO) team and their catalog of exploits. There is of course no evidence that NSA developed or was using this particular exploit, but this is exactly the kind of silent, virtually undetectable attack that is the specialty of nation-states. The fact that Adallom’s customer is a large, high-profile enterprise is potentially bad news for Office 365 sales efforts, given that those customers are already a little leery of cloud services because of a perceived lack of security controls.

Second, this exploit apparently doesn’t work against Exchange Online or Lync Online, but that hasn’t been proven conclusively. Don’t hold off patching Office 2013 just because you aren’t using SharePoint Online.

Third, it seems to me that this kind of flaw is the natural consequence of breaking new ground. Seamlessly tying together on-premises and cloud services through a complex desktop suite is something that no other software company has even attempted: the major Office 365 competitors, such as Box.net and Google, don’t offer traditional desktop productivity apps, preferring instead to run inside the browser, where the design patterns and potential vulnerabilities of authentication are much better understood. So I don’t think of this as sloppiness necessarily on Microsoft’s part: sometimes in complex systems, people make mistakes. 210+ days-of-risk makes me a little nervous though.

My overall takeaway: if you have truly sensitive data that you want to protect, putting it in the cloud is not necessarily any more risky than keeping it on-premises. That may seem counterintuitive, but an entity that is determined to get your data has many potential avenues of attack, and my experience tells me that the vast majority of sites have a number of local vulnerabilities (such as poor patching practices, poor intrusion detection, or inattention to basic security practices) that put them at higher risk than a relatively esoteric, hard-to-exploit flaw like this one. if you don’t believe me, just look at the number of sites hit by Cryptolocker and various banking-related Trojans. Put another way, you don’t need to worry about defending yourself against NSA if you can’t even manage to defend yourself against script kiddies.

Now go forth and patch!

Leave a comment

Filed under Office 365, UC&C

Office 365 beta exams: a few thoughts

Last week I took the beta versions of the two MCSA exams for Office 365: 71-346 is Managing Office 365 Identities and Requirements and 71-347 is Enabling Office 365 Services. I thought it might be useful to write up a few NDA-safe notes on the exams and the topics they cover. Keep in mind that the questions on the beta exam are there because they’re being tested; the objective domains (ODs), or areas of knowledge being tested, won’t change but the specific questions probably will as the beta identifies “bad” questions (those that everyone gets right or everyone gets wrong are immediately suspect!) The Microsoft exam development process is really complicated; to summarize, by the time the exams hit beta, the knowledge areas to be tested are set in stone but the questions themselves can be modified, or thrown out, based on beta exam feedback.

First, be forewarned that there are no formal study materials for these exams. I hear that Office 365 Admin Inside Out from MS Press is decent, but haven’t read it yet. Be prepared to do a lot of binging to look up specific things that you want to know how to do.

Second, the absolute best way to prepare for the exam is to sign up for a trial Office 365 E3/E4 tenant and make sure that you know how to do everything mentioned in the exam objectives in both PowerShell and the GUI. This is baloney, and it has been a hot topic of debate in the MVP community. IMHO there is little value in asking an examinee to show that they know how to do something in PS which is trivial to do in the GUI, especially if it’s a one-time task like setting up Azure RMS. Nonetheless, that’s the requirement.

For 346, specific things you should probably know include:

  • How to add a new tenant, from scratch. This includes choosing a region (and what effect that has), setting the domain purpose, and confirming domain ownership.
  • How to configure DNS records and firewall settings: SRV, CNAME, and MX records, what they point to, etc.
  • How to design ADFS: how to size it, when to use SQL Server instead of WID, and so on. Note that actually doing HA or DR with ADFS is not one of the topics listed in the OD, but you’ll need to know how to do it anyway. The ADFS 2.0 documentation content map is very helpful here.
  • How to administer (parts of) ADFS, including installing it (prerequisites too) on both Windows 2008 and 2012 (but not R2), controlling filtering, and managing dirsync. I have heard that there are questions in the pool that cover ADFS 3.0 but don’t know if that’s true.
  • How you’d conduct a pilot, including how to use connected accounts and mail forwarding.
  • What the different administrative roles in 365 are for and what they can do, including how to manage delegated admins.
  • How to provision / license users through the 365 Admin Center.
  • Basic account management through PowerShell: creating users, modifying their properties, licensing them, etc. Nothing too exotic; I expect most Exchange and Lync admins can do these types of things now without difficulty.
  • How to provision, enable, and administer AD RMS, a surprisingly cool technology that Brian Reid has written about at length already.
  • What the mail flow/message hygiene reports are and what you can do with them
  • How to do daily admin tasks: checking service health, using the RSS feeds, opening service tickets, etc.
  • Troubleshooting using the Remote Connectivity Analyzer and MOSDAL

347 is a little more of a mixed bag because it contains both admin-level material similar to ODs in 346 plus a smorgasbord of other stuff. The most important thing to know here: you must know how to do stuff with SharePoint Online. Out of the 53 questions on my beta exam, 12 of them (22.6%) were related to SPO.  Given that about 0.5% of my actual knowledge relates to SPO, that was a problem. I don’t use it, and I haven’t worked on the SPO-related parts of any deployments for Dell customers, so I was unprepared. Don’t be like me. Be prepared to demonstrate that you know:

  • All about Click-to-Run, including how it differs from MSI installations, how you customize what gets installed, how the installs themselves work, etc.
  • All about Office Telemetry. Never heard of it? Neither had I. Its inclusion in these exams seems a bit odd, since I suspect you’d see people running it before deploying Office 2013 on-prem too. It’s been a while since I was directly involved in the world of desktop deployment, though, so maybe everyone but me knows about them.
  • How to manage SPO site collections, including how to share and unshared them, set quotas, etc.
  • How to provision (including how to license) Excel and Visio Services
  • How to manage proxy, reply-to/default addresses, resource mailboxes, external contacts, and groups in Exchange— standard stuff for working Exchange admins.
  • How to work with archiving policies on both Exchange and Lync, including integration with Exchange 2013’s in-place hold mechanism
  • How to set up Lync settings for external access, including visibility of presence and per-user access to PIC

Again, you need to know how to do these things in both PowerShell and the GUI, despite the fact that many of the tasks in the ODs will be things you do once (or maybe quarterly, at most).

Should you take the beta exams? It depends, I guess. They cost the same as the “real” exam, and they’re subject to the same “Second Shot” MS program that grants you one retake of a failed exam. So you could sign up and take the beta now for $150, then take the real exam for free if you don’t pass. Based on the state of the exam questions I saw, and the lack of structured training materials, I don’t recommend that you rush to take the exam, though; the real version goes live on 17 February. Until then, your time would probably be better spent setting up a scratch tenant that you can play with, then running through the list of ODs to make sure that you know how to do the things on the list.

I’d be interested in hearing from people who took the exam to see how well you think the exam actually matches up with what Office 365 admins and designers need to know in the real world.

1 Comment

Filed under Office 365, UC&C

Microsoft, encryption, and Office 365

So the gloves are starting to come off: Microsoft general counsel Brad Smith wrote a long blog post this morning discussing how Microsoft plans to protect its customers’ data from unlawful interception by “unauthorized government access”. He never specifically mentions NSA, GCHQ, et al, but clearly the Five Eyes partners are who he’s talking about. Many other news outlets have dissected Smith’s post in detail, so I wanted to focus on a couple of lesser-known aspects.

First is that Microsoft is promising to use perfect forward secrecy (PFS) when it encrypts communications links. Most link-encryption protocols, including IPsec and SSL, use a key exchange algorithm known as Diffie-Hellman to allow  the two endpoints can agree on a temporary session key by using their longer-term private/public key pairs. The session key is usually  be renegotiated for each conversation. If Eve the eavesdropper or Mallet the man-in-the-middle intercept the communications, they may be able to decrypt it if they can guess or obtain the session key. Without PFS, an attacker who can intercept and record a communication stream now and can guess or obtain the private key of either endpoint can decrypt the stream. Think of this like finding a message in a bottle written in an unknown language, then next year seeing Rosetta Stone begin to offer a course in the language. PFS protects an encrypted communication stream now from future attack by changing the way the session keys are generated and shared. Twitter, Google, and a number of other cloud companies have already deployed PFS (Google, in fact, started in 2011) so it is great to see Microsoft joining in this trend. (A topic for another day: under what conditions can on-premises Exchange and Lync use PFS? Paging Mark Smith…)

Second is that Microsoft is acknowledging that they use data-at-rest encryption, and will be using it more often. Probably more than any other vendor, Microsoft is responsible for democratizing disk encryption by including BitLocker in Windows Vista and its successors, then steadily improving it. (Yes, I know that TrueCrypt and PGP predated BitLocker, but their installed bases are tiny by comparison.) Back in 2011 I wrote about some of the tradeoffs in using BitLocker with Exchange, and I suspected that Microsoft was using BitLocker in their Office 365 data centers, a suspicion that was confirmed recently during a presentation by some of the Office 365 engineering team and, now, by Smith’s post. Having said that, data-at-rest encryption isn’t that wonderful in the context of Office 365 because the risk of an attacker (or even an insider) stealing data by stealing/copying physical disks from an Office 365 data center is already low. There are many layers of physical and procedural security that help keep this risk low, so encrypting the stored data on disk is of relatively low value compared to encrypting the links over which that data travels.

The third aspect is actually something that’s missing from Smith’s post, expressed as one word: Skype. Outlook.com, Office 365, SkyDrive, and Azure are all mentioned specifically as targets for improved encryption, but nothing about Skype? That seems like a telling omission, especially given Microsoft’s lack of prior transparency about interception of Skype communications. Given the PR benefits that the company undoubtedly expects from announcing how they’re going to strengthen security, the fact that Smith was silent on Skype indicates, at least to suspicious folks like me, that for  now they aren’t making any changes. Perhaps the newly-announced transparency centers will provide neutral third parties an opportunity to inspect the Skype source code to verify its integrity.

Finally, keep in mind that nothing discussed in Smith’s post addresses targeted operations where the attacker (or government agency, take your pick) mounts man-in-the-middle attacks (QUANTUM/FOXACID)  or infiltrates malware onto a specific target’s computer. That’s not necessarily a problem that Microsoft can solve on its own.

Leave a comment

Filed under Office 365, UC&C

The future of importing large quantities of Exchange data to Office 365?

It wouldn’t be accurate to say “you can’t”, but Microsoft doesn’t make it easy.

Whether you’re moving mailboxes or PST data to Office 365, your imports are throttled; that is, Microsoft imposes a limit on how fast you can move information into their data centers. The exact speed of your import process will vary according to a variety of factors, including what protocol (IMAP4, MAPI, or EWS) you’re using, what migration tool you’re using, and how many concurrent threads it can spin up, how busy the data center you’re importing into is, and the mix of item sizes in the mailboxes or PSTs you’re importing.

The problem with this throttling is that it’s largely opaque. Although Microsoft publishes “observed data,” my own observations have shown that migration throughput can vary widely based on these factors and a bunch of others besides, possibly including the phase of the moon and whether you have recently said anything disparaging about Microsoft anywhere on the Internet.

Recently I had a customer who wanted to migrate 30TB of PST data to Exchange Online Personal Archives. While this might sound ridiculous, it makes perfect sense given that Office 365 E4 plans include an unlimited-size Personal Archive for each mailbox. That’s a hard deal to beat… if you can figure out how to get the data in. At one point, in a fit of frustration we asked Microsoft whether we could just send them a bunch of disk drives containing the PSTs. “Of course not,” they said (with “silly boy” being the unspoken coda to that phrase). But it turns out that Azure is now providing bulk import of data by sending disks to them: the Windows Azure Import/Export Service is now in preview. With any luck, we’ll see a similar service from Office 365 in the not-too-distant future. And when it happens, remember, Andy Tanenbaum had the idea first.

3 Comments

Filed under Office 365, UC&C

Office 365 PhotoSync and the third-party market for Office 365

Office 365 has its own thriving MVP community, and fellow MVP Loryan Strant sent me an announcement of a new product he’s developed for Office 365: PhotoSync. The purpose behind the tool is to ease the process of managing user photos in enterprises by providing a better tool for managing user photos. There are tools that provide similiar functionality for on-premises deployments, of course, but this tool’s unique approach (or perhaps unique marketing, as I haven’t tried it myself) is to focus on the fact that many Office 365 deployments will use directory synchronization to get directory information from the on-premises deployment to Office 365.

Using a shared hosted service means accepting some compromises; for example, Microsoft greatly limits subscribers’ ability to customize SharePoint or to configure various aspects of Exchange such as database and DAG settings. This might seem to limit the possibilities for developing software products to supplement Office 365. I think it’s a healthy sign that third parties such as Loryan are developing add-ons and utilities for use with Office 365, although I suspect that only the most agile organizations will be able to identify opportunities and exploit them fast enough to keep up with the cadence of feature and service updates that Microsoft seems to be aiming for.

More on PhotoSync in the future…

1 Comment

Filed under Office 365

Keeping up: Office 365 OnRamp changes

Microsoft Exchange Server 2013 Inside Out: Clients, Connectivity, and UM (colloquially known as “the book”) is now in production! I’ve reviewed all the page proofs, corrected the few composition and layout mistakes I found, and returned the proofs to the editorial staff so they can turn PDFs into paper. It’s pretty exciting, although thanks to my tardiness the book won’t be ready in time to be sold at Exchange Connections (about which, more tomorrow.) However, I’ve been assured that Tony’s book on Mailbox and HA will be available there.

About a month ago, I wrote this in the Office 365 chapter:

One of the difficulties inherent in writing about cloud services is that they can change rapidly and often. The screen shots of Office 365 in this chapter reflect its appearance and function as of late 2013, but it’s likely that some of the underlying Office 365 code will change, so don’t be surprised if what you see on screen doesn’t exactly match what you read here.

As if to reinforce that point, today Microsoft has changed the OnRamp tool that you use to assess your organizational readiness for Office 365. The readiness review portion of the tool seems to have disappeared, leaving the checklist portion (which is similar in intent to the Exchange Deployment Assistant, another topic covered in the chapter). I haven’t found where the readiness review went, but I’m fairly sure it still exists somewhere in the maze of Office 365 tools.

The moral of this story? Although Microsoft likes to mock Google’s habit of suddenly introducing changes to end users without warning, they are starting to develop the same habit, except it mostly affects administrators. I hope this particular change was just a slip and not a harbinger of the way toolset changes will be handled in the future. (The secondary moral: man, it’s going to be a challenge to keep up with Office 365 updates in anything I write in the future!)

Leave a comment

Filed under UC&C