Clearing the decks for Ignite - more on Office 365 numbers, anti-malware, and PST imports
The countdown to Microsoft Ignite next week has truly begun as I have seen a barrage of tweets (is that the collective noun?) to inform me that people have started traveling. It must take a long time to get to Chicago or some camels are involved in the personal travel arrangements of the most interesting people in the technical community. In the meantime, to clear the decks before I get going myself, some interesting things have popped up over the last day or so.
April 30, 2015
The countdown to Microsoft Ignite next week has truly begun as I have seen a barrage of tweets (is that the collective noun?) to inform me that people have started traveling. It must take a long time to get to Chicago or some camels are involved in the personal travel arrangements of the most interesting people in the technical community.
In the meantime, to clear the decks before I get going myself, some interesting things have popped up over the last day or so.
First, I saw a report from Mary-Jo Foley with the comment that "Microsoft officials said today that Microsoft now has 50 million active monthly Office 365 business customers.” This interested me a lot because I have been tracking the progress of Office 365 for the last few years in an attempt to figure out just how many mailboxes run in the service. My last calculation put the number of Office 365 mailboxes at around the 90 million mark, which I still think is reasonable. A lot of free mailboxes are hosted in the service, including Microsoft employees, test domains, and the like and there are many mailboxes that have been provisioned but are not necessarily used yet. The important term in the comment was "active"; no definition was offered for what this means, but you'd assume that it is something like "has logged on within the last month".
The other interesting thing is that Microsoft now reckons that they have a 44% margin for the commercial cloud business (Azure, Dynamics CRM, and Office 365). Even with the most recent annualized run rate of $6.3 billion, that margin will take some time to pay off the massive investment in datacenters that Microsoft has made to support cloud services. The report also said that CEO Satya Nadella wanted to hit a run rate of $20 billion by 2018. Given that the most recent annual increase was 106%, it's reasonable to expect $6.3 billion to get to $20 billion in 3 years, if the same kind of progress is maintained. At that point, Exchange Online might support more than 250 million mailboxes, which is a lot of DAGs to maintain.
The second thing that caught my attention was a very interesting post by Terry Zink to inform us that the infrastructure used by Outlook.com and Exchange Online/Office 365 is converging. Terry's blog is a good one to bookmark if you are interested in the world of anti-malware and threat suppression. The focus of this post is the work that he is engaged in to move Hotmail (Outlook.com) onto the same infrastructure used by Exchange Online Protection (EOP), including topics like backscatter protection (with boomerangs of course). [Update May 1: the page is no longer available, which might indicate that someone in Microsoft didn't like the information it contained]
It makes a heap of engineering and financial sense to operate a single infrastructure to protect email streams against viruses and spam because it means that new functionality such as the Advanced Threat Protection being developed for EOP can be leveraged by all of the connected mail services. It might also mean that other features such as the enhanced non-delivery reports recently introduced into Office 365 will make it to Outlook.com.
My last topic is the news that Office 365 tenants who have signed up for First Release (like me) have a new "Import" option to play with in the Office 365 Admin console. This allows tenants to use the Office 365 Import Service that's intended to solve the problem of what to do with PSTs when companies move to Exchange Online. You can either leave the PSTs to decay in their current location (hopefully never on network file shares) or take action to exploit the large mailbox quotas available inside Office 365 to import the PST contents into online mailboxes (or archive mailboxes).
The first challenge is discovering the PSTs as most lurk hidden on personal drives. Microsoft offers a free PST Capture tool for this purpose and other commercial tools are available. As detailed in this blog, some shortcomings exist in the Microsoft tool, so it's worthwhile looking around before making a decision as to what tool to use.
The next challenge is to get the information to Office 365. You can ask users to drag and drop information from the PST to online folders using Outlook, but you know how success that strategy is likely to be. Automation is necessary – something to work behind the scenes and do the job without any involvement on the part of the user, and that's of the job of the Office 365 Import Service.
To move data to Office 365, you can package up user PSTs on 3.5 inch SATA II/III drives (up to 4 TB capacity) and ship the drives to a Microsoft datacenter and avoid the need to load potentially terabytes of PST data over the Internet. The data on the drives is protected by BitLocker encryption and includes a mapping file that associates each PST with a user account. Each drive is prepared using a special Azure Import/Export tool that creates a journal file for each drive that contains the drive ID and the BitLocker key used to protect the data.
When the drives arrive at Microsoft, they are loaded into Azure and made available to the tenant administrator, At this point, the tenant administrator can invoke an import job to start importing the data from the PSTs into the target user mailboxes. The administrator who runs the job must possess the RBAC Mailbox Import-Export role (the RBACManager tool might be useful here) and have access to the journal files. Once launched, the import job runs on Azure to process the PSTs found on the drive and uses the mapping file to move content from the PSTs into the target mailboxes. You can monitor progress of the import job from the Office 365 Admin console.
If you have a high-capacity connection to the Internet and don't have a lot of PSTs to process, you can consider moving the PSTs over the network to a Microsoft datacenter instead. In this scenario, the data is still protected because it is encrypted and you have the keys, but the shipping element is replaced by a direct network transfer. Once the data is uploaded, you can then run an import job to process the PSTs and transfer the content to user mailboxes.
It all sounds good, but the Office 365 Import service is in its early days and I am sure that some glitches will emerge before it reaches general availability to all tenants. I'll report back here when I hear more. In the meantime, the first task is to track down all those pesky PSTs…
Now I'll go and pack for Chicago and take care of the last bits and pieces for the launch of the "Office 365 for Exchange Professionals" eBook on May 4. Next week should be fun!
Follow Tony @12Knocksinna
About the Author
You May Also Like