If you have a registered Internet domain name and you want to provide email addresses to your users based on that domain name, you have basically two options:
-
Provide an on-premises mail service and infrastructure
-
Utilise externally provisioned (hosted) mail services
Historically, the second option has only been viable with a fairly small number of email addresses. Once you get above, say, 40 or so addresses, the first option could become more economic. This was the reason that we chose in our school to implement the first option. In point of fact, we originally had some 500 email addresses on our first site mail server. The server had to be replaced and Exchange 2007 was the chosen platform. The actual implementation of our Exchange 2007 solution, as it turned out, began at about the same time as we first heard about the Live@Edu service. We put the hundreds of student email addresses onto Live@Edu Hotmail, using a subdomain, but kept our primary domain and staff email addresses on our site mail server, transferred to Exchange 2007. Over the 12 months that we have used Exchange 2007, we compared it with the services being offered free to schools on Outlook Live, and made the decision to transfer our 40 staff email addresses to Outlook Live on Live@Edu. Because the Live@Edu service is hosted free of charge, it is significantly superior to an on-premises mail server and the cost advantage blows away the traditional ISP based services which were quoted to us at $3 per user per month (around $1500 per year) and which generally offer a puny 10 or 100 MB per mailbox compared to the 10 GB that Microsoft is providing.
Well it’s now April 2010 and a few days ago I started to migrate our users off our Exchange server. The first step is, we need to be able to move their mailbox contents. In Live@Edu help, you are given a couple of suggestions, which are basically setting up an automatic migration using POP or IMAP, or going to each user’s computer and exporting their stuff from Outlook to a PST file. The auto migration option using POP/IMAP can only migrate mail, so it is not useful for migrating from Exchange. If you are using Exchange and have a computer running 32 bit Windows and Outlook 2007 with the Exchange Management Tools installed (2007 SP1), you can use the new Export-Mailbox cmdlet in the Exchange Management Powershell to export a user mailbox to a PST file without having to go to a user’s computer to do it. In order to be able to do this, you will need to grant yourself Full Access permissions to the user’s mailbox first of all. This is pretty simple to do: either use the Exchange Management Console, or in the Shell enter this command:
Add-MailboxPermission -User <your name> -AccessRights FullAccess -Identity <mailboxname>
The actual command to do the export looks like this:
Export-Mailbox -PSTFolderPath <Path_Of_PST_Folder> -Identity <MailboxIdParameter>
Path_of_PST_Folder is a folder on the computer where you are running the export. It will create a PST file in this folder which is automatically named based on the mailbox name. If you have a smallish number of mailboxes, just run each command manually for all of your users in turn. When you run the Export-Mailbox cmdlet, you are first asked to confirm the export: the response I used is A (all). Then the export will display a progress bar and status messages in the shell window as it proceeds. Finally it will provide a status report and it also files copies of the status reports in a folder in the Exchange Management Tools installation path. If you have a larger number of mailboxes and advanced knowledge of Powershell, you could further automate this process by piping in a list of users as input to these two commands. I figured that by the time I had worked out how to do this, I would have already been able to complete the manual steps so the manual process was how I did it.
After we have exported all our mailboxes, we need to import them into Exchange Live. There are two ways we could do this, only one of which is described to any degree in the Live@Edu documentation. Basically you can either use Outlook 2007 to import the PST directly, or it is possible that you could use Windows Powershell to connect to Live@Edu allowing the Import-Mailbox cmdlet to be run against the remote Exchange server. The latter option, not being configured by default in Outlook Live, would require many steps to set up and probably, going by my initial explorations, technical support from the Live@Edu helpdesk. As I only have a small number of mailboxes to import, I have gone for the first option. You can implement this option on any computer running Outlook 2007, provided you know each user’s Windows Live ID and password. All you need to do is to set up the account in Outlook in the usual way, and then use Import and Export on the File menu in Outlook to import the PST file for that user that was created from the Export-Mailbox cmdlet in Exchange Powershell.
At this point in time it is possible that you will find that your Autodiscover settings in your on site mail server are interfering with and blocking the Autodiscover DNS settings that you have configured for Outlook Live. When I initially tested this at our school, I was onsite and consequently I was able to shut down the Exchange server in order to stop the interference. However, this server is also running the Terminal Services Gateway and so I wouldn’t be able to log in remotely while it is shut down. So I tried out a few things to disable the Exchange server’s autodiscover. The first things I tried were shutting down Exchange itself by stopping all the services whose names start with “Microsoft Exchange” on the server. However Autodiscover kept running as it is actually provided by IIS. When I worked that out, I went to the IIS management console and stopped “MsExchangeAutoDiscoverAppPool” and all the other application pools with names starting with “MsExchange”. Finally, this was successful in turning off the Autodiscover, and setting up new accounts in domain connected computers could proceed.
If you look this up on the net, you will find a recommended solution from Microsoft here, this is based on setting some registry keys to stop Outlook from using the site autodiscover functionality and the registry keys have to be changed on the client computer where Outlook is running. This could be a better option if you have to keep your onsite Exchange server fully functional during or after the migration. As it is, I have the option of being able to shut down Exchange so that I don’t need to bother with client configuration.
Once you have the account set up in Outlook, you can import the PST file directly to the user’s account. The trap for unwary players here is that Outlook doesn’t immediately upload the imported content to the Outlook Live server. Instead it puts it into the offline cache and synchronises it over a period of time. If you have to migrate a number of users in this way, you need to make sure the offline cache is fully synchronised before you remove their account from the computer where you are running the imports (you would do this in order to set up the next user’s account for importing). The way to do this is to click Send and Receive and watch the progress dialog, this will show that the synchronisation task is taking a certain number of minutes, which obviously varies depending on the size of their PST file and the speed of your broadband connection. It can be a slow process this way. That is why I would like Live@Edu to facilitate people being able to import their mailboxes in Powershell because it can be automated. At the moment, importing a large mailbox through Outlook can take hours to complete, the speed of broadband being the limiting issue. The only real workaround for this at the moment is to do it on each user’s own computer and therefore because the account is set up permanently on that computer, you don’t need to wait for the synchronisation to be completed.
So as of right now, I am slowly migrating people over the next few days, and we will have to see how things go from here.