Office 365 install

[wardoursecure]

After a pretty successful 25 user email migration from one hosted solution to a office 365 across multiple locations I though I would share my thoughts and observations.

Back story, insurance brokers based locally with 2 users in Cornwall, 6 in Jersey and 4 home workers, mixture of devices and versions of office.

Lessons.

1. Never rely on the web host to make the required DNS changes correctly the first time, in this case the ttl on autodiscover was set to 38000 seconds instead of 3800 (1 hour)
2. Check outlook 2013 for how much it has downloaded off the existing server before exporting or you will have to do it again.
3. Check for local files.

Observations.

Have a copy of office 2007 sp2 handy as you might need it.
Remember to run the desktop setup if users not running office 2013

You can't have enough backups/exported folders

Create a new outlook profile for 365 so you can check back on old system if needed.

Renaming office.nk2 to Office365.nk2 is a great help for restoring cached contacts, remembering to use an nk2 editor to remove the in office users.

Remember it's usually a huge deal for the end users so listen as they explain any issues as most will panic.

All in all fairly painless for all concerned.

 

[callthatgirl]

Nice write up.


Some tips from my past experiences...
One trick I learned is that I export the contacts and calendars first, then the inbox. And when the new account is added to their profile, I import the calendar and contacts first as the import of the mail can take awhile if they have a lot of mail. I figure why wait around until the end when it can take hours.

Remember, they can't receive email in Outlook until the mail is done syncing with the server, so I have them use their phones or the web portal.

 

[YeOldeStonecat]

Banged out a big migration at an insurance company over the weekend....retired their SBS03 and put in new Essentials 12 server and O365 e3.

I prefer using a neutral web based tool for my SBS to O365 migrations...."migrationwiz.com".

Makes it sooooo easy and reduces the time I spend BIG TIME! HUGE reduction in time spent. (and time saved is more profit on the job) I just check in every few hours to monitor the progress bars.

I stopped worrying about .nk2 files for migrations off of mail servers...too many little hiccups down the road with them. Yeah end users moan 'n groan a little bit at first...but in reality the .nk2 files build new again and in a week or so they stop groaning.

 

[krtechsolutions]

migrationwiz.com is a money maker!! start the prep work during business hours, so a full pass, then do a test pass, then let it eat, while the migrationwiz is doing the lifting you go and make DNS changes!!

i agree with the nk2 files, they should be using the address book as it was designed.

 

[wardoursecure]

I will checkout migration wiz ready for my next one.

Forgot to mention there were a couple of macs which I am not too familiar with. One didn't import any sent items so I had to download his old mail as IMAP, export sent items and import back into 365.

Seeing as they had zero support before I now have some recurring coming in.

For the larger mailboxes they are using owa while they sync. It's better than their current office 2007 so there will be some office upgrades and hardware upgrades coming too.

 

[Markverhyden]

Thanks, great information.

FYI, migrationwiz.com is now bittitan.com. And it's a great tool. I used the premium version (or whatever they call it). The problem with migrations is many users have huge stores. One I just finished a user had around 12gb. Took almost 45 hours to migrate. Appriver advised it was around 2-4 hours per GB. What we did was an initial pass on all accounts. These got stored to the new exchange accounts and were accessible via webmail using a temp onmicrosoft.com account for each user. Then on migration day we made the MX change and then started the second and final pass. Of course that did not take near as long as it was only an incremental.

I've been using appriver.com for O365 as recommended by several on here. They will setup mail bagging during the actual migration.

Another hint. Make sure and confirm everything in advance, including login credentials for all sites. Many no longer remember or even know the credentials to their domain registrars and dns providers. Also do not assume a host lookup provides the actual email server. People using a third party anti-spam service will have that server listed as the MX record rather than the actual email provider. This is important as you need the actual email provider credentials to use the migwiz service.

On the Apple side. As long as they are using IMAP or Exchange migwiz will move the emails. Of course local stores are a totally different matter irregardless of the OS.

 

[wardoursecure]

Got to agree there' I had a username and password list, unfortunately one remote site wanted a local firm to do the whole thing, I presume some form of incentive was offered, so they didn't send any machine passwords.

As most were on Office 2007 thee were plenty of updates to do including office service packs so this did delay.

I think I will make this a criteria for the companies to ensure they have at least the windows updates done.

 

[YeOldeStonecat]

Thanks, great information.

FYI, migrationwiz.com is now bittitan.com. And it's a great tool. I used the premium version (or whatever they call it). The problem with migrations is many users have huge stores. One I just finished a user had around 12gb. Took almost 45 hours to migrate.

You select the impersonate option, right? Allows the migration to bypass default throttle rules...much better for bulk hauls. The migration I did last weekend, the infostore was just over 60 gigs. Kicked it off around 0600 Sat morning, all but 2 mailboxes were done by Sunday noon..and the remaining wrapped up later Sunday evening. All were done by start of biz day Monday.

I also make sure I bounce the source server ahead of time, kill as many unnecessary processes as I can, and I kill the AV on it. If it's an old and ratty server...good to run some ESEUTIL defrag on the infostore ahead of time too. Anything to make sure the source server is standing up tall and able to dedicate good resources to the huge upload.

Also for larger clients....kill all the activesync associates first. As they take up IIS resources and sessions...you want to leave as much as those free for MigrationWiz as possible.

...course client had good bandwidth too...this is required regardless of what approach you take. Comcast 50/10 pipe..so that 10 meg upload make it zip.

Also the "delta passes" are a nice feature. Since DNS can sometimes run slow...the old mail server often still receives a little mail over the next day or three....so the ability for MigrationWiz to run a couple of delta passes a few days later is a great feature. It will see those "new" e-mails on the old server that arrived after the migration and just move those.