1

Specifics: SBS2008, Exchange 2007, 6 Mailboxes. Target: To move all exchange mailboxes to O365 and decommission Exchange.

Basically the client has a really bad exchange 2007 implementation from the previous amateur. Usual .local, No split DNS, no SSL, DNS all wrong, etc. The exchange server is costing the poor small company hundreds a year in running costs and they just wish to outsource it all. Now I have done some research in getting it moved to the cloud using this link and this link. The method I was thinking of implementing is the cutover migration however it seems that an SSL certificate is required which means I'll also have to implement Split DNS let alone changing the OWA url's. All seems too much headache for the budget they have and the time I have let alone the fragility of the setup.

I was wondering if I could take a shortcut by simply; purchasing the 6 accounts they need in O365, changing the external DNS and MX record settings for the domain in question to point to O365. Adding a webmail.xxx.com A record. Secondly Export all their PST files to an External Disk (maximum of 10gb between all of them). Remove their outlook profile and link it to the new O365 one then simply attach the PST's back to each of them and upload the emails in batches (for e.g. Copy the entire inbox of the pst into the inbox of the O365 profile, same for sent items and deleted items and then just disconnect the PST and keep it as a backup for them?

It may take a little more time but surely its much less headache then messing with a totally amateur AD, DNS, Exchange setup. I really don't want to be messing with that server and AD.

Possible? Or is there an even faster alternative method?

Thanks

dqnet
  • 305
  • 2
  • 9

1 Answers1

1

Yes that will work and may be the quickest and least complex method for getting their email into O365/Exchange Online for a small set of users. A few things:

Just import the PST file, don't bother with copying from folder to folder. An import will allow you to import the PST file into the same folders in the mailbox (Inbox to Inbox, Sent Items to Sent Items, etc.).

You'll need to disable the SCP lookup for internal Outlook clients so that they don't look for the internal Exchange Server.

If you're planning on using Azure AD Connect to sync your on premises users to Office 365 then you'll need to do that beforehand and you'll have additional configuration that needs to be done.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • Fantastic (good catch on import PST source to location thing) - a quick question, could I not just disable SCP on the exchange server forcing outlook to use DNS? No Azure DNS, they just use the simple features of AD. Any specific way to decommission exchange or just delete the mailboxes, unmount the DB, and disable the services? Thanks – dqnet Mar 21 '18 at 23:42
  • The best and most complete solution would be to uninstall Exchange once you've moved the mailboxes. That will remove Exchange and the SCP from AD. Outlook autodiscover uses several "discovery" methods to find a users email server and mailbox, the first of which for domain joined clients is the SCP. Short of uninstalling Exchange, you can disable the SCP method a number of ways, the easiest of which is with Group Policy by using the relevant Microsoft Office GPO templates. – joeqwerty Mar 21 '18 at 23:48
  • Perfect - one last thing before we close this off. With regards to uninstalling exchange, would you recommend this on the fragile setup? Would it be more appropriate to silence it rather then remove it? I've done a basic google on removing exchange from sbs2008 and most url's that point to Microsoft Articles throw up a 404. Obviously a dated product. The only article that I found in detail was this: https://www.infostream.cc/2011/10/removing-exchange-2007-from-small-business-server-2008/ [technically nothing to lose trying to remove it but AD issues later maybe]? – dqnet Mar 22 '18 at 01:13
  • Ah. I overlooked that this was SBS. You might be better off disabling the Exchange services and disabling the SCP autodiscover method via Group Policy. Then put together a second project to remove Exchange and SBS from the domain (after the O365 migration is complete). – joeqwerty Mar 22 '18 at 01:43
  • 1
    Just an update - all systems are go. Above procedure works fine. If the business has very large exported PST files however, the 'import into O365' can take quite a while with a slow connection or even if you have a fast one with many uploads going on. – dqnet Apr 08 '18 at 22:15