top of page

Weekly Round-up - 9th July

Apart from a couple of small jobs – and a broken car which sort of hampered my onsite work for a couple of days (why do vehicles always choose an inopportune moment to break?!) - this week has been all about migrating from #SBS2011 to #Office365.

My customer has been using the built-in POP3 and Smarthost connectors in SBS to receive and send emails. This has worked perfectly for years but as SBS2011 is coming to the end of its life and the company has a greater requirement for mobile working we have been planning this migration for a while. However, our hands were forced after the company’s domain host made changes to the email protocols which broke the Smarthost send-connector - not helpful!

Office 365 has a number of options for importing emails from existing providers. If you use a remote server via IMAP and SMTP it is an easy process to implement and all done remotely between the existing email server and Office 365. You simply create a CSV file with the login details for each existing mailbox together with the Office365 target mailbox. The emails are then imported automatically.

In the case of an on-premises server – i.e. SBS2011 – there are other considerations to take into account, primarily the Internet bandwidth from the customer premises as the email accounts have to be uploaded. Also, if the SBS is using a self-signed security certificate, the automatic import will not work as there is no way to upload and install the certificate on the Office 365 servers, so the automatic process will not work.

This was the case with this customer’s server and in any case it was likely the volume of emails would have taken days to import, due to the relatively low upload speed from their site which is 1.5Mbps. It is important to note that for day to day running with Office365 that this speed combined with their download speed of 20Mbps is more than adequate but only has implications for the migration.

To get around this, Office365 offers the facility to upload mailboxes in bulk in PST format, but there is a bit more work required to implement this. Each Exchange mailbox has to be opened in Outlook and set to synchronise the required number of years of emails – in this case two years. Once these are downloaded from the Exchange server, they are exported to a PST file, which includes the calendar and contacts for each mailbox. The PST files are then copied into one folder. We ended up with 8 mailboxes totalling 29GBs.

Due to the upload speed we opted to copy these files to a memory stick and use our own much faster internet connection to bulk upload the files to Office365 – it still took 4 hours to complete this upload. Then using the import features in Office365 we were able to migrate these emails into the relevant Office365 mailboxes, carrying out a test migration first with one mailbox. The import process took another 4 hours and was run overnight on Friday into Saturday.

It is then simply a case of creating a new Outlook profile for each user and setting up the Office365 email accounts.

It is actually possible to manually import the PSTs into the new email account within Outlook. However, we’ve found that if the upload speed is low and the PST file is large, this can prevent new emails from downloading while Outlook synchronises with the Office365 servers. This does not happen if the emails are all being downloaded to Outlook from Office365.

Final point – before starting this process, ensure all the necessary Office365 DNS changes are made and are operational so the emails are going to Office365 and not the SBS server. Otherwise emails can get missed – and you have to import all over again!

Now we just have to import the documents from SBS into Sharepoint Online, but the customer is still sifting through the files they want to retain – quite an unenviable task! Think we’ll be implementing retention policies in Office365……..

15 views0 comments

Recent Posts

See All

So - quiet August.....

In my last post, I alluded to August being a quiet month normally. I might have been wrong! In the last two weeks we've been inundated with calls to deal with hard disk failures, network problems and

Wot - no blog posts?

Well - I've been a bit decadent and had another week's holiday - strictly no more this year though! Still carried out a bit of remote support for clients - what would we do without mobile data? August


bottom of page