Office 365 – What does it mean for Exchange?
Earlier this week, Microsoft announced the next generation of their cloud online services, Office 365. This new suite of online services will offer Exchange Online, Sharepoint Online, Lync Online (the next generation of Office Communications Server) and the desktop Office Professional Plus suite.
When it comes to messaging, the next generation of Exchange Online provides Exchange 2010 SP1 along with mailbox sizes up to 25GB, online archiving features, Voicemail integration with On Premises PBX's and enterprise email features such as retention policies and cross-mailbox search.
One of the fundamental differentiators of Office 365 was announced on the Exchange Team Blog; the ability to integrate closely with On Premises Exchange. ADFS 2.0 powered Single Sign On will enable what has been known as "Connected Federation". This allows users to login using their On Premises Active Directory credentials, Mailbox Moves either way between On Premises and Exchange Online, Cross Premises Mail Tracking & Routing, and management of both On Premises and Exchange Online from from a familiar toolset - a single Exchange Management Console, and ECP and Exchange Management Shell. As well as all this, more basic, critical features like availability (free/busy) and Calendar and Contact sharing will be supported via Federated Sharing.
So - why would a cross-premises (where some mailboxes remain On Premises and some are hosted on Office 365) have a business case, especially where it hasn't been considered in the past? The key reason to consider a cross-premises deployment is so your business can take advantage the best of both worlds. It's already gaining traction in the server virtualization area (just look at what VMware are aiming for) and it's a great fit for messaging. When looking to move to Exchange 2010, a lot of enterprises are considering consolidating their Exchange infrastructure and avoiding managing mailbox servers at small branch offices. Hosting mailboxes in the cloud makes a lot of sense in this situation as it can remove a major point of failure - the internet or WAN links into the regional or main HQ. Road warriors commonly only need an internet connection, so again, hosting their mailbox using Office 365 makes a lot of sense. However - in larger offices, where the bandwidth required for all Outlook Clients to connect out to the internet, or where a loss of connectivity to Exchange could paralyse the business, it still makes sense to host Exchange On Premises. Utilizing a cross-premises deployment with Office 365 could save money and effort when it comes to those branch offices and mobile users, but also allows the user mailboxes to be moved back On Premises (or vice-versa) as the user's role in the organisation changes.
Of course, there are some questions and possible caveats that still need to be answered by Microsoft and assessed against your business needs before even thinking about whether Office 365 will be appropriate; for example, how are 25GB Office 365 mailboxes managed? If a user gets a new laptop, will they need to sync tens of gigabytes of data with their local copy of Outlook? Online Archives have been mentioned by Microsoft, so one might assume the 25GB will be split between the primary mailbox and the Archive. If so, it will be interesting to find out what those ratios are so the impact of an OST sync can be taken into account. The other critical area is backups. Anyone reading up about Exchange 2010 will no doubt have read that Microsoft is now advocating the use of 3+ Database Copies instead of backups, leaving "Recover from Deleted Items" the only option for recovering deleted data. Currently, they employ this method of backup on the "beta" of Office 365's Exchange Online, Live@EDU's Outlook Live so I wouldn't be too surprised if this is the case for Office 365 also.
So where does these leave the future of On Premises messaging? I think, given even the sort of caveats mentioned above, Office 365 and other cloud based services have a compelling business case, simply because the capital expenditure required to implement isn't required. Many On Premises deployments today take into account what the business projects it will need over the next 3 to 5 years and the appropriate hardware to meet the worst-case scenario is bought up-front whether it will be used to it's full capacity or not.
I believe that a more appropriate vision for the future of Exchange On Premises deployments has to be able to justify itself against cloud services cost models like Office 365's, which are targeted toward operational expenditure. In the future, On Premises Exchange deployments could also aim to look at this model where the business is charged back based on what they are actually using rather than buying it all up-front. Of course - initial investment is needed, but by only buying the capacity needed initially - thin provisioning mailboxes (i.e. providing larger mailbox quotas than the underlying disk storage allows) will reduce those costs considerably. This model of chargeback and building out capacity as it's required is already in widespread use in the virtualization area, and as someone who runs such an environment, I can say it works well and is popular with customers. Even if this sort of model doesn't equate exactly, it does provide a model to ensure costs can be compared with cloud messaging offerings fairly, and provides a little motivation to move away from over provisioning and wasted storage.
Another question typically on the minds of IT staff is "will a move to Office 365 cost me my job?". My personal opinion is that it most cases, no it won't - at least no more than a move to On Premises Exchange 2010 will. In larger enterprises, there may be some re-deployment where large Exchange Admin teams exists - but due to massive improvements in the product quality since Exchange 2003 (and to a lesser extent, Exchange 2007), Exchange 2010 takes a lot less work to keep running. A move to Office 365's Exchange Online service might require a similar level of planning as a move to Exchange 2010 (and will in most situations involve some Exchange 2010 servers in the mix anyway), and on-going administration still remains. Cloud services like Email might be sold as light-touch, especially by Google, but the reality is that the end users still require the same things. Someone still needs to do the IT work to create mailboxes (or automate that process), deal with shared mailboxes and distribution groups, override access rights and troubleshoot mail delivery issues. These can all be delegated - but they also can be delegated in the exact same way with On Premises Exchange 2010.
Whist it's common knowledge the Office 365 re-brand takes BPOS (Business Productivity Online Mouthful) under it's wing, it's definitely worth noting that Live@EDU is also being brought into the fold. Why does this matter? Because by understanding that Outlook Live and Live@EDU are basically the production beta for Office 365, you can start learning more about what Office 365 will offer straight away. For example, I've recently published a post about Federated Sharing with Outlook Live which I believe will also (with small modifications) apply to Office 365's Exchange Online. I also worked with Microsoft on a Q&A about what my employer can already do with Live@EDU, which includes some of these very benefits.
So, what does this all mean for Google? I think it's obvious that what Office 365 brings to the table will be a quantum leap over what Google Apps's GMail has provided so far. Up against the rich cross-premises, enterprise functionality offered by Office 365, GMail is more clearly defined as a consumer product competing in the enterprise market. That said, I am certainly not dismissing Google; for example, they have supported SAML 2.0 SSO for Google Apps for a long time, and provide excellent APIs that allow you to write your own rich provisioning systems.
Google also have a big advantage when it comes to smaller businesses, the sort of size where the company doesn't want or need internal IT infrastructure. These are traditionally the kind of companies who otherwise would stamp hotmail, gmail or yahoo email addresses onto their business cards and for them, Google is a well known brand and is easy to use. Office 365 will have some ground to make up here, but I think a major battle ground will be in the SME sector, competing in ground where server provision was previously provided by a Windows Small Business Server installations.
However Google still have massive hurdles in the enterprise to overcome. Take Jaguar, who faced problems when they first migrated, then had to overcome a user revolt, according to the comments from Jaguar employees here. Eventually Jaguar had to re-train it's staff to use Google Apps, according to this press release. Reports like this don't help the case for moving systems to Google's cloud (and neither do the incorrect cost comparisons) and don't forget, Google doesn't provide an exit strategy either. I never thought I'd say this a few years ago, but at the moment Microsoft provides the least lock-in for enterprise email in the cloud.
Comments for/against Google aside, I certainly think that Office 365 is a very interesting development and it will be worth watching what happens next. If you haven't registered for the beta of Office 365, you can register here.
Exchange – Bulk-add forwarding addresses
There's not many circumstances where you'd want to set forwarding on lots of mailboxes at once - but if you're in that situation (perhaps you're moving mailboxes to a Cloud mail provider) it's useful to know that it's fairly straightforward and can be accomplished with a little PowerShell.
In the example below, we're assuming that your on-premise Exchange 2007/2010 domain is contoso.com and all your mailboxes are in the Staff OU.
The Cloud provider you're moving your mail to will eventually take over the MX record for your domain, but will also accept mail to each user's Username@cloud.contoso.com. We'll keep mail contacts used for the forwarding in the OU CloudContacts.
To accomplish this, we quite simply need to get the mailboxes in the specific OU, create a mail contact for each one (with the external email address they will use on the cloud provider's domain) and then set the forwarding address on the mailbox:
# Loop though the object returned by Get-Mailbox with each element represented by $mailbox
foreach ($mailbox in (Get-MailBox -ResultSize Unlimited -OrganizationalUnit contoso.com/Staff)
{
# Create the forwarding address string $ForwardingAddress= $mailbox.SamAccountName + "@cloud.contoso.com"
# Check there isn't a contact, then add one
If (!(Get-MailContact $ForwardingAddress -ErrorAction SilentlyContinue))
{
New-MailContact $ForwardingAddress-ExternalEmailAddress $ForwardingAddress- OrganizationalUnit contoso.com/CloudContacts }
# Set the forwarding address Set-Mailbox $mailbox -ForwardingAddress $ForwardingAddress
}
Of course, that's a fairly simple example. What if the email addresses at the cloud provider don't match the Windows Logon ID or anything else that is an attribute of the Mailbox? Well the simple solution is to use something like a CSV file containing a mapping between an attribute on each Mailbox and the external email address for that user:
SamAccountName,ForwardingAddress jamesw,jimbo@cloud.contoso.com philipg,phil@cloud.contoso.com
In this example, we'll save that file as input.csv and use that as are input to the foreach loop. Again CloudContacts OU will contain our new mail contact objects:
# Loop through the object returned by Import-Csv with each element represented by $person
foreach ($person in (Import-Csv .\input.csv))
{
# Check the Mailbox for the person exists
If ((Get-Mailbox $person.SamAccountName))
{
# Check the mail contact doesn't exist and if not add it
If (!(Get-MailContact $person.ForwardingAddress))
{
New-MailContact $person.ForwardingAddress -OrganizationalUnit contoso.com/CloudContacts }
# Set the Forwarding Address on the Mailbox Set-Mailbox $person.SamAccountName -ForwardingAddress $person.ForwardingAddress }
}
Word of caution - it's worth (as always) running these commands in your test environment first - and of course consider appending -WhatIf to the New-MailContact and Set-Mailbox commands to check they'll do what you want in your production environment.
Hope this helps,
Steve


