What features are driving people to Exchange 2010?

Looking at Exchange 2010?

In the Loudhouse research- “The Great Email Migration” commissioned by us at Mimecast- 57% of IT managers said they were upgrading to Exchange 2010 because of new features.

What are some of those features?

What’s been a real focus for Exchange 2010 is to directly enable the email user to do more, and to do it more easily.

Free/busy is a great example of where Exchange 2010 is a great improvement.

Free/busy is a well known feature to users worldwide, however in older versions of Exchange it’s nearly impossible to see the free/busy status of another user in another organization. Exchange 2007 enabled cross-forest free/busy lookup to another Exchange organization if the pre-requisites were in place. But it was still just free/busy.

Exchange 2010 builds significanly to that, by allowing organizations to federate with each other, and exchange free/busy information with detail, controlled by the administrators.

Assuming that partner companies in different forests and different networks need to see each other, Microsoft will broker and vouch for the authenticity of the relationship via a hosted service, and then enable each company to dial up or down the detail visible to the OTHER companies recipients.

Free/busy is akin to the availability feature of Lync or OCS when it comes to making the decision to make a call or not. Seeing another companies free/busy massively empowers users to work faster and more efficiently.

Another big step forward is MailTips with Exchange 2010 Outlook Web App and Outlook 2010.

MailTips enables the person emailing to see the Out of Office of the recipients before they send the mail. This eliminates that frustrating workflow associated with sending a mail again after thinking it was dealt with.

Managing availability between organisations and MailTips are just two of the many new productivity features available in Exchange 2010 which truly reclaim minutes in the information workers day. Help your people be more effective with Exchange 2010.

Migration on the other hand, isn’t always easy… so we’ve produced a series of webinars and how to guides to help you migrate in the Migration Readiness Kit (registration required).


Minimizing the risk of an email migration

Last week Mimecast announced the results of their Great Email Migration research, conducted by Loudhouse Research.  Loudhouse surveyed 500 IT decision makers in the US, UK and South Africa and asked them about their email migration plans.

According to the report, “The potential loss of data is at the top of the list with more than half (52%) of the companies mentioning this.”

Companies are right to be concerned at the possibility of data loss. Infrastructure which is in flux opens companies up to be vulnerable to data loss, due to bad process, unmanaged configuration change and/or bad discipline. How can companies possible hope to mitigate these kinds of risk.

It is an old axiom that failing to plan is tantamount to planning to fail. In this context, planning should be a formal activity of every migration project, with a formal and on-going deliverable known as the migration plan.

Migration plans are only as good as the effort put into them and the accuracy of the scope which they are fed by. Accurate quantification of source environments, labs which approximate live environments, and a sample of representative user data are all prerequisites to ensuring a migration plan has the best possible chance of succeeding.  In fairness, most of us don’t migrate for a living, so it’s not unreasonable to expect not knowing where to start. Here we will offer two suggestions:

Follow the military approach to planning by starting with the end goal in mind, and working backwards through every objective until the base understanding of the requirement is defined, without knowing how to solve every objective or process requirement. The end goal must be a clearly defined business or technical requirement.

Follow up by adding process planning for each stage, known or unknown, and add technology choices last, so that technology becomes the enabler to the process, and not the other way around.

Migrations are epitomised by environments in flux. Flux is risky and is mitigates by process, planning and management. Migration planning as an on-going exercise as well as a living document is a foundation stone in the on-going exercise to mitigating on-going risk.


Migrating to Office 365 from BPOS without Mimecast

This is a Guest Post from a prolific blogger- Andy Kemp who has recently moved from a long standing customer of Mimecast and to a Microsoft Gold Partner UniTech, one that doesn’t have Mimecast in place but excited about what the toolset could do for them. One of the recent things he’s been tasked to do is their Migration from BPOS to Office365 both internally and for a number of serviced clients, and it’s interesting to see what life without Mimecast is like…

I finally took the plunge and migrated our primary email domain to Office 365 from BPOS the other weekend- we still don’t have Mimecast but we didn’t want to wait any longer! It could have gone better but on the other hand it could have been more painful like it was when I migrated one of our secondary domains.

The two issues I faced when migrating were:

  1. Migrating the data from BPOS to Office 365
  2. Migrating the Domain from BPOS to Office 365

1. Migrating the data from BPOS to Office 365

Unfortunately there isn’t a really clean automated way to do this, the only way possible which I found to do this was to attach the new Office 365 Mailbox using the address to their exchange profile and copy/move the folders across.

This was pretty simple for the mail, contacts and task folders but the calendar folder was done in a slightly different way, you need to change the calendar view to a list and then copy and paste the entries into the new Office 365 Mailbox:

As the Exchange Folders were cached I needed to let the local folders sync up to the Online Exchange Server to then enable me to setup a clean outlook profile with only the 365 exchange account connected.

As this was all done pre migration it meant I had all my data in Office 365 when I switched over domains. This was the next step, although what should be a simple process proved to be my biggest worry with the migration even though I had done it before.

2. Migrating the Domain from BPOS to Office 365

As I have mentioned before this process although sounds straight forward is the most laborious part of the migration. If you are moving from an on prem setup or another hosted solution, then it is nowhere near as painful as moving from BPOS to Office 365.

The problem I had was with FOPE (Forefront Online Protection for Exchange) for BPOS although the Domain no longer existed in BPOS there were still artefact DNS records in FOPE which meant if I added the domain to Office 365 and then sent an email to an account using that Domain I would get an NDR immediately due to a possible mail loop. As the FOPE for Office 365 would see the DNS records in FOPE for BPOS and get a little confused and then just return a “Computer says No!” in the form of the NDR.

What I had to do was fill in a Standard Request form for removal of artefact DNS records and submit that as a Service Request via the BPOS admin centre and then call Microsoft BPOS support with the Service Request number and asked them to hurry the process up… well that made them sort it in 2 days as opposed to 6!

After a week into the move things have finally calmed down and users are running with no issues.  I have several Service requests open with Microsoft for Office 365 due to small issues that I’ve had in the admin portal but on the whole things are running well.

We are taking full advantage of Lync 2010 and the ability to federate with other organisations. We are now in the process of setting up our company intranet and extranet using SharePoint online.


Simplify your Cloud Migration

Migrating to the Cloud at the moment? Or at least planning to sometime soon? Lots of businesses are either moving key IT services out to the Cloud right now, or are planning to in the near future. Many organizations have adopted the “Cloud First” ethos, of procuring Cloud solutions for new platforms, rather than on prem.

Most IT departments I talk to have a solid plan for these migrations, a plan that’s been well thought out and even tested; but I think it’s fair to say some don’t. The latter is usually found when a C-level manager has dictated the use of a Cloud solution in a “get it done and don’t bother me with the details” type of management style. Very 1997 I know – I thought those days were over, Mr Gekko?

IT departments are unlikely to declare IT Bankruptcy and ship everything out to the Cloud over the next long holiday weekend, even if there is pressure from the C suite to get ‘Cloud first’ apps in place as quickly as possible. Migrating systems to the Cloud, needs careful planning and consideration, not just the move itself but an understanding of the data, processes, policies, APIs, people, & supporting platforms involved. In other-words, the details.

Take a move to the latest version of Microsoft Exchange for example. Of course I mean Office 365, but many businesses are still thinking about how best to get to Exchange 2010; you see they’re still lingering on their trusty Exchange 2003 infrastructure. We have spoken before about the complexity of the peripheral applications that surround the Exchange Server being a hindrance to a migration project, and how dealing with this complexity makes you and your business ‘Migration Ready‘. Most of the careful planning and consideration has to take into account all those peripheral applications and services first, extending the scope of the project into, perhaps, much more than was first considered. Hardly surprising we lose track of the details and start to focus on the final outcome.

So let’s stick with Microsoft Exchange as an example: How about this as an alternative strategy to get your business to the cloud. At Mimecast we often talk about a strategy called “Just Enough on Site” which is about finding the balance between on-site and Cloud. You’re augmenting your network with Cloud. Exchange 2010 is an on-ramp to Office 365 Exchange Online – what do I mean by that? Well, rather than try to move everything and everyone to Office 365 Exchange Online now, simply take your time. The Exchange 2010 migration should be a focused move to a platform that will allow you to introduce the Cloud into your business in small well planned steps.

Jumping into standing up cloud instances all over the place might work, but it’s far better to take your time to sweat the details for a while, and think about how you and introduce the cloud to the network over a number of smaller migrations rather than one great big one.

As they say round here – “Let the network see the cloud”.