Migrating from IceWarp to Exchange 2013 -- any tools to assist with migration?

Cerulean

[H]F Junkie
Joined
Jul 27, 2006
Messages
9,476
Greetings,

We will be migrating from IceWarp to Exchange 2013 over the weekend at midnight. Here is the problem:

Users sign out and go home on Friday evening. Between this time and midnight when we update MX records to point to the external IP address of the Exchange 2013 servers, e-mails will still be going to mailboxes at the IceWarp server. How do we make sure these e-mails get to the proper mailboxes in the Exchange 2013 server?

Microsoft Transporter Suite only officially supports up to Exchange 2007, and my co-worker had said that from his research Microsoft discontinued that program because of how many problem it had and how third-party tools were doing a significantly better job. (My question: what are those "third-party tools were doing a significantly better job"?)

Our IceWarp is storing [email protected]'s Outlook Test Message e-mail message at D:\Programs\VisNeticMailServer\mail\company.com\john.doe\Inbox as 201207132117130209.imap. 201207132117130209.imap is readable plaintext.

EDIT: I found http://sourceforge.net/projects/migrationtool/, but it does not have an option to migrate everything except for anything older than x days; the only options it has is "everything" and "anything older than x days"
 
I would put a spam filter in the loop that can store mail if a server is offline.Usually I use a hosted one but internal as long as it can hold the mail would work too.

1 - change MX midweek to use spam filter. no mail is harmed since it either goes to server or spam filter. tell spam server to send to existing server.

2 - on friday close the firewall ports on the existing server. Spam server holds on to mail and everything new is queued.

3 - migrate server data and ensure exchange 2013 is ready. possibly use a second temp domain for this.

4 - once complete tell spam server to send to Exchange server and let it send all the new mail in.

5 - change MX to go direct to exchange - again no mail harmed.

6 - grab beer.
 
Above is the best way. And generally you want the outside spam company for spam and message spooling. Also good for outbound smart host and even message continuity

We use McAfee
 
Unless you have a very specific reason for Exchange 2013, I'd either put your migration on hold or use Exchange 2010 instead. I've done an numerous Exchange 2010 installs, and Exchange 2013 for both my own office and a client that specifically requested it. IMHO, Exchange 2013 is another MS product that's been released before it's been properly polished. For example, Coexistence with 2010 is not available yet until the first CU, that's due out this quarter. That's just getting started... Short version, stick with 2010 for now.
 
I would put a spam filter in the loop that can store mail if a server is offline.Usually I use a hosted one but internal as long as it can hold the mail would work too.

1 - change MX midweek to use spam filter. no mail is harmed since it either goes to server or spam filter. tell spam server to send to existing server.

2 - on friday close the firewall ports on the existing server. Spam server holds on to mail and everything new is queued.

3 - migrate server data and ensure exchange 2013 is ready. possibly use a second temp domain for this.

4 - once complete tell spam server to send to Exchange server and let it send all the new mail in.

5 - change MX to go direct to exchange - again no mail harmed.

6 - grab beer.
This won't work because there will still be users on Friday that expect to have e-mails delivered. There will be people that leave at 3:30 PM, people that leave at 5:00 PM, people that leave at 7:30 PM, people that leave at 10:30 PM, people that leave at 11:59 PM, people who are on vacation and/or out of office and had never bothered to check their e-mail (aka do a POP3 pull), etc.

Our IceWarp server is already set to use its own built-in [POS] anti-spam functions, but if you're talking about temporarily getting an external anti-spam server -- okay, even though nobody in the department feels confident enough to pull something like this off -- say we did that. Step #2 is where this won't work; as soon as you do that, factoring in my last paragraph, (1) there will already be mail on the IceWarp server that hasn't been read for countless numbers of users and (2) there will be users that still expect to receive mail, unless of course we do it at Midnight or 1AM or 2AM Saturday (but either way point #1 will be true if not both 1+2 depending on when to execute Step #2).

Unless you have a very specific reason for Exchange 2013, I'd either put your migration on hold or use Exchange 2010 instead. I've done an numerous Exchange 2010 installs, and Exchange 2013 for both my own office and a client that specifically requested it. IMHO, Exchange 2013 is another MS product that's been released before it's been properly polished. For example, Coexistence with 2010 is not available yet until the first CU, that's due out this quarter. That's just getting started... Short version, stick with 2010 for now.
Unfortunately that is not possible at this time as it is already fully setup with matching e-mail accounts already existing and prepared since 3-4 months ago. Since then, additional preparation and testing and diagnosis has been performed. My supervisor wouldn't fly for the idea of downgrading to Exchange 2010, especially at this point in time. The migration I think is scheduled for next weekend (not this coming weekend), and may possibly be delayed 1 more weekend.

At the moment, only our Corporate division is actually migrated away from our 8 year old in-house server hardware to the new fully VDI environment; our other 4 overseas divisions are still operating on their terribly old in-house hardware; only 2 of those overseas divisions are making some connection to our new system at Rackspace (1 of them through Citrix, and the other through VMware View/VDI). On top of this, we've got a challenge with the fact that there is a file server at each overseas division (that does not sync or replicate to any other server) and is also joined to their overseas division forest domain (i.e. division.company.com -- old domain didn't use .local for TLD), with one fileserver located at a DC local to Corporate that all overseas division (including Corporate) connect back to and is joined to the root domain (company.com). New system domain is company.local. To add to the fun, we've got handfuls users at our overseas divisions that were setup on Outlook Express, many on Outlook 2003, very few on Outlook 2010, very few on Outlook 2007, etc; there are some machines out there that run Windows 2000 (that potentially have e-mail setup via & i.e. through Outlook Express).

So with that said, the plan at the moment is that we're going to have to work either a short or long weekend (the entire department), hope that a script from Microsoft works (which may determine how long we're going to be working), and login to every user account on our VDI system that has a matching username in IceWarp... and at the moment I have no idea how this will cover users located at overseas divisions (since nobody else but Corporate uses the VDIs).
 
Are you familiar with mailbagging? That is essentially what Cerulean is suggesting, and I also think it applies to your situation. You might want to google mailbagging and look into it.
 
First since you do not already have a plan in place, you are NOT ready to migrate on Friday. The plan is created, then vetted, then tweaked, then vetted agian, then tweaked again, then vetted again, then communicated and only after all that is implemented. Not enough time for all that at this point.

If it was me doing this, I would be looking at the network as a whole. Depending on how your network is setup I might do something like use the firewall if all the external addresses are terminated on it control connectivity.

Also don't you have a Barracuda accepting your incoming and outgoing e-mail? It sounded like you did in your other thread.

1) Have people export their e-mail to PST files. Communicate that there will be downtime starting at Time X on Friday. Desktop group has to be ready to either push out a configuration change or go around to every computer and change the settings to connect to the new Exchange server.

2) If they want some of that e-mail back up on the new Exchange server they can put that up there later. But remind them of the mailbox size limit on the new Exchange Server (You did create a policy for how much mail people can store on the server right?)

3) On the firewall point the external IP address to the new Exchange box for the ports for Pop, IMAP, SMTP, HTTP, etc. Though in my mind I would rather point SMTP at the Barracuda box.

3A) I would also rather have people move away from POP & IMAP and use RPC over HTTPS or Outlook Anywhere instead.

4) change the Barracuda to deliver to the Exchange Server instead.

5) confirm e-mail is flowing in and out of the Exchange server

6) Pop open a beer and call it a night.
 
You are STILL researching on even how to do this when you plan on cutting over tomorrow?? Dear Lord.... :eek:
 
Would the MX Backup/pooling from Dyn be the same as mailbagging? :?

Not unless they are providing a service that will hold your e-mail while you make the cut over. So far just doing a quick look at the page you linked it is only back up DNS, not backup mail services.

Again see my previous message.

YOU ARE NOT READY TO MIGRATE, AS YOU DO NOT HAVE A PLAN IN PLACE AND COMMUNICATED AT LEAST 24 HOURS IN ADVANCE. I would prefer at least a weeks notice with this large of a system change, but that is just me and I have seen these types of projects go REALLY HORRIBLY bad.
 
I used MXsave for awhile. My current web reseller account includes cPanel, which allows configuration as a mailbagger.
This would be the mailbagging product from DynDNS

I think there is still time to carry this off tonight, especially if Exchange is already up and running. If not, learning experience for you and chuckles for us if you let us know what happened. I'm guessing you are going forward no matter what, so I'm providing information in that light.

Just a note on mailbagging- premium features you may consider are being able to login to the mailbag to check e-mails, and being able to force forwarding to your primary mail server.
Basic systems don't allow checking e-mail until your primary is up. They also typically forward on a logarithmic schedule- the longer your primary is down, the longer it waits to forward- you could have your primary up, but your mail is not forwarded for 24 hours.
 
Not unless they are providing a service that will hold your e-mail while you make the cut over. So far just doing a quick look at the page you linked it is only back up DNS, not backup mail services.
Eh sorry, my bad, wrong link. My co-worker has been the one that has been thoroughly researching Dyn. The correct link is the one provided by RocketTech: http://dyn.com/email/dyn-email-backup-mx/

I remember my co-worker mentioning how the MX Backup/mailbagging would only cost like $40-50/year.

The migration is scheduled for next weekend (not this coming weekend, as I have said already), and it is possible it may be delayed for 1 more weekend (also mentioned this earlier). The plan is to establish exactly what we're going to do and at what time, and upon establishment a 1-2 week notice will be sent out to the entire company notifying everyone that a very big migration to Exchange will be occurring on whatever weekend we'll be doing it on, and asking everyone to make sure they do a few things before they finish for that Friday and head off to the weekend.
 
do you have a roll back plan as well if things are getting completely fubar'd?

you need to have things going in stages for this size of a migration, once stage 1 is done then continue to 2, if 2 cannot be done, what is the rollback options?

like the others are stating it sounds like no one has the confidence/know how to deal with this migration as this type of planning should have been looked at way before getting all the users setup in the exchange 2013 environment. You may have been better off looking at say office365 and having it hosted online even if for a couple months, get your other internal domains sorted out and then migrate your email into an internal exchange setup.
 
Back
Top