Moving to the Cloud: Where it worked and where I was challenged

I am running a whole environment at home to experience our technology. However, up to now it was all “on premise”, no Cloud integration. This has to change. Therefore I was more than happy to join our internal  Hosted Exchange 14 beta program. We are offering the hosted Exchange program to Live@Edu – but we can use it for Friends and Families as well – which I wanted to do. There were a few requirements I had:

• As I am hosting (or better: was hosting) quite some mailboxes for my family ending on @halbheer.ch and @halbheer.info, I needed a migration which is smooth and easy and gives me the possibility to move back on premise, whenever I feel like it
• Due to historical reasons, I am hosting two domains for one mailbox. So, roger@halbheer.ch and roger@halbheer.info – that’s just me
• I want to have Outlook 2007 and Outlook 2010 Technical Preview as the client
• My users are real end-users, so I do not want to have any impact on them (well I have but that’s something for later)

This was my starting point. I then looked at outlook.com. The information about outlook.com is on help.outlook.com. After studying the webiste (yes, I read the manual) I decided to go for it - and started this Friday.

The migration by itself was basically straight-forward:

• Signing up for the service for halbheer.ch
• Adding the mailboxes, which are needed (this can be automated via scripts – samples are included on the help-site)
• Adding a few DNS records (e.g. SRV, autodiscovery)
• Changing all the DNS records (MX, SPV)
• Confirming the setup and making sure it is active
• Signing up for the service for halbheer.info (as a secondary domain)

The admin website just looks like this:

So, it is easy to do and straight-forward. You can even have a joint address book with external people you want to have in your organization.

It was time to get ready for the first Outlook client. As the environment requests – well, even requires – autodiscovery, this is only a matter of setting the DNS-servers right. The reason why autodiscovery is required is simple: When our Exchange Online people decide to move our mailboxes to a different server, Outlook shall automatically change the configuration. After a few hiccups, this simply worked. Take Outlook, add an account, use your e-mail address and the password and the rest is done by Outlook.

And that was it! I was pretty much impressed – it took me a little bit more than an hour and then I switched off my Exchange server. This sound too good to be true – well, it is not that easy…

Let’s briefly look into a few considerations when doing something like this:

Basically, there are different levels of could services. Christofer Hoff, Cisco made a good distinction based on the OSI model:
and then he maps it to the security controls:

Clearly I use Software as a Service in this model. I move my whole mail-system to the cloud. Therefore I have to address a few questions:

Compliance, Policy Enforcement and Risk Mitigation: This is not a big deal in my case – however, it might be one for you. I am using here a free, beta service. There are some policy options you can enforce in this given service through Powershell. However, if you enter a deal to outsource a service, make sure you understand how you can ensure policy compliance. From a risk perspective, I significantly reduced the risks with regards to availability – which was my goal. I actually transferred it.

Data Security and Control: From my point of view, this is probably the “easiest” of all challenges for an e-mail application. There are basically two options to protect the confidentiality of your mails: You can use S/MIME and encrypt the mails or use Rights Management Services, which does much more than to encrypt the mail – it protects if from forwarding, copying etc. As long as you control the key and/or access to the services (in the case of RMS), you are pretty much safe. The problem stays with the contacts, tasks and calendar which you cannot encrypt nor RMS-protect. In my case, this is not a problem and we have to see –again – the scope of the service I use.

Service Availability and Reliability: Well, this was the real reason, why I moved to the cloud. This is now not my problem anymore and I guess that Microsoft has more experience running such a service and a little bit more capacity than me…

Application Security: In the case of mail, there is no real difference on the application layer security between on-premise and in the Cloud as we both use Exchange. The only discussion point here is about patch management. This is now outsourced as well. I guess we are on par here as my servers are usually updated(and rebooted!) within a few days after the release of a security update.

Identity and Interoperability: Leaves the biggest one in the cloud in my opinion – the identity (interoperability is not really a problem in the mail scenario). As this offering is targeted at a service we call Live@Edu, where we offer Live services to the education sector, the identity management problem is solved as it bases transparently on LiveID to deliver the service. The accounts are generated if necessary as soon as you create the mailbox. Transparent and easy. In my case it was a bigger challenge as I am running my on-premise domain. Currently in this environment we would need to be able to federate my on-premise identity out to the Live environment, which is not a scenario, which is supported with the mail service offered. What you can do is a GAL sync to synchronize your Active Directory environment with the Exchange environment, which already helps you to keep the accounts in line. However, to me the whole area of federated identities and claims-based identities will most probably be the big theme of the cloud.

A few final challenges and remarks: So, after the migration, everything works well and fine and smooth – well, until I realized that there are a lot of internal services, which count of an accessible SMTP-server which does not require authentication (sometimes this is solvable) but for sure no encryption. SCOM, WSUS, SharePoint, my NAS, my Access Points, my Photo Gallery – just to name a few. All of a sudden a service, which was offered internally, is not offered anymore… I finally solved this as well – but honestly, this was the biggest junk of work at the end of the day. The whole planning of the migration did not consider such dependencies – or better: My planning of the migration… The dependencies in your network should not be underestimated. Especially the ones you never knew of…

Roger