Chuck Exchange mailboxes into the cloud... sysadmin style How do we migrate Exchange mailboxes into the cloud? A customer of mine has recently approached me with a request to move his mail hosting into the cloud, and it had to include BlackBerry support. After some discussion of the options available, a hosted exchange solution was deemed best, with Microsoft's own Office 365 emerging …
The vast majority of MTAs run by clueful admins these days no longer bother sending or forwarding bounce messages due to the massive queue backlog that results if you're the victim of a large spam run, and also because of the "backscatter" problem.
So don't get your hopes up that many people will actually see bounce messages if you firewall incoming traffic. (Not to mention how many people are either ignorant or paranoid about what a bounce message is - they might for example think it's a phishing attack, or are just too lazy to bother looking.
This post has been deleted by its author
Actually...
Most proper email admins configure thier servers so that messages rejected by spam filters do not produce bounces. They also configure the servers so that mail sent to non-extant users does not bounce. (Indeed, I have CentOS VMs front-ending my Exchange deployments to provide anti-spam via SpamAssassin, ClamAV, etc. that do LDAP lookups against the internal AD to determine if a user exists or not, so that isn't an excuse.)
But bounce messages ARE typically configured if there is an error sending to a legitimate user for any reason other than "nommed by the spam filter." I admit, this is a PITA to configure correctly in Sendmail, but it’s easy peasy in Postfix, Qmail or Exchange itself. Even in smarthost/front-ended spam filtering configurations.
You don't get backscatter in this configuration, but it does take some actual effort on behalf of the mail admin...
That's not really relevant though. The most important thing is that mail is not delivered successfully to a server that is no longer part of your mail store. This could happen if an MTA (or the NS server it queries) caches NS lookups.
By locking out the server, you don't want bounces, and fortunately, you don't get them. Any MTA that would discard or bounce an email after one failed delivery attempt is moronic.
Most will keep them in an outgoing queue, and attempt to redeliver them at a later date. What you hope here is that when it attempts to deliver it later, it will use the correct DNS name and deliver it to the correct MTA.
Only if an MTA has attempted redelivery multiple times will it contemplate bouncing the email back to the sender.
So...your proposed solution to managing and maintaining an email infrastructure is to presume that everyone else manages and maintains their infrastructure properly?
..WHAT?!?
Always presume that everyone else on the internet is a complete idiot. What you are describing is exactly how two properly configured email servers would communicate. I have rarely run across much in the way of properly configured MTAs.
Most MTAs I know will retry send every 5 minutes, up to a maximum of 5 attempts at which point they bounce. I need to design any infrastructure I run on my side such that it works well for people running things properly and in the advent that senders have email admins with brains made out of rocks.
That means close the ports on my side so that their MTA can retry or bounce as the local admin desires. It means configuring my MTA so that if you try to send me a 100MB email to a legitimate address and the server says no, you get a bounce explaining why. It means paying attention to my DNS settings and my TTLs so I know what should be happening, but bearing in mind the fact that DNS providers often have their own cache rules that don’t pay any attention whatsoever to TTL.
I can’t make other admins run servers properly. I can however try to run mine well, and rely on the tools at hand (including bounces!) to attempt to convey information to others about what is going on as they try to interact with my network.
Remember that "could not deliver, server didn't respond" boucnes aren't bounced by the MTA I control; they are bounced by the sending MTA. And gods only know who configured the sending MTA to do what, when, where and why.
Oh, and just for the record, my gripe about poorly configured MTAs isn't a dig at default configs of these MTAs, it is a discussion of the actual implemented configs I see in the wild. Default configs can be what they want; some email admins make stupid choices resulting in the weirdest configurations...
...and if you're running Exchange 2003 (or older) then you're screwed as the Outlook Anywhere component is not available for these versions. Not that it provides anything exactly complicated, but MS would like you to upgrade instead. So to migrate 2003 or earlier Exchange then you must first pay to upgrade to 2007 and then upgrade or suffer the consequences with what can be a very nasty upgrade process. This is before the nightmare if anything SBS related is taken in to account. It's pretty much a miracle that an SBS Exchange server like the one described transferred properly, but if it's true then it's a good thing as ridding the world of SBS is a noble aim.
This does leave one very serious future problem though. What happens when one wants to migrate out of the Office 365 cloud to a different provider or solution? What provisions are there for this?
For email, you can just do an imap drag & drop from google to a local host. Set up email forwarding and off you go.
If you go proprietary, you'd better be *very* sure that the functions required are provided.
Better to stick with open protocols. I seem to think OOo used to have FTP built in. Not great, but a cool idea in its time. If you run KDE/GNOME enabled apps on *nix you can probably use ssh/sftp as your file transport. That should give you SSO and decent encryption.
Ditto, we're currently using another hosted Exchange provider (Cobweb), and were looking to migrate, but I couldn't get a test migration to pull anything except a user list through, despite having OA enabled.
There are companies that specialise in moving mail and calendar data from any mail system into any other, of course, they charge.
Would it not be easier to set up Office365 as a lower preference MX record.
Then when it comes time to swap over, simply shut down the ports on your firewall, the email will automatically get routed to the next MX record and there are no bounce backs. Then you can simple change the MX records at your leisure?
It's one way to do it, yes. However I prefer simply cutting over the DNS for the simple reason that in many cases the sysadmin doesn't have control over the firewall. (There is often a strict segregation between roles.) Indeed, in many cases the exchange admin doesn't have the rights on the system necessary to manage the local system's firewall!
So if you have total control over all the things, your way is better. If you don't (as is often the case when I am serving as contractor,) then the DNS cutover is more likely to work the first time.
Only problem I foresee with that is there's no guarantee that incoming traffic will route through your higher priority MX's just because they're up and running.
Forgetting about MTA idiosyncracies, all it would take is a routing/connectivity issue between the sending host and the receiving primary MX and they would ignore that host and deliver to the secondary, tertiary etc.
Which is normally fine, unless you're in a migration scenario where you're not yet monitoring the mailboxes on the new system.
Now I actually have some resentment at that statement, sir. Do you have any idea how long it took me to wade through Microsoft's myriad documentation and figure out exactly what needed to be done for this stuff? MS is great at churning out whitepapers. Not so great at cutting them down into a single document and making them comprehensible.
After I had done the legwork and made the document for my own use internal to my company, I simply figured that it would be something that some of my readers could use as well. That way, when the time comes, they don’t have to go slogging through the incomprehensible mess that is Microsoft’s unsearchable, disorganised, chaotic mess of an online presence seeking this info.
Instead, I you now have all the links and a step-by-step. Might not mean much to you today, but when the call comes, you’ll remember you saw it on The Register. And El Reg’s Search actually works.
Fine - you did a lot of work.... which is a bit irrelevant if you are deciding whether something is a marketing piece or not.
It's still aimed at moving from Microsoft local to Microsoft cloud. I understand the objection that it's a marketing piece (though your comment above re difficulty of finding how to actually do this seems to balance the "easy peasy" tone of the article quite a bit ;)
I do applaud your effort and I'm sure it might come handy for somebody who is attempting to do the same, but why not then also write up an Exchange=>Zimbra, Exchange=>Scalix, Exchange=Sogo, Exchange=>Postfix guide etc...
The answer is simple: I haven't had to do them yet in the real world. I have been asked by a client to move Exchange --> Office 365. I spent a lot of time doing the research and writing up an internal document, it seemed like a quick-and-easy way to get a pair of sysadmin blog articles out with only some minor rewriting. Preferably sysadmin blog articles that might mean something to a reasonable chunk of my potential readers.
If and when I run across the need to document more things, I am sure they will find their way into these pages as well. (You can always go to http://www.egeek.ca and hire out my company to do whatever project you want. I am certain that if I have to do enough research/generate enough documentation to do that project, at least some aspect of it will end up rewritten in blog format here. Or, you know...ask me if I am willing to write an article on a given topic...)
In the meantime, you might like some of my previous articles:
SpamAssassin front-ending exchange: http://www.trevorpott.com/?p=275
Basic Linux bandwidth shaping: http://www.trevorpott.com/?p=308
I am working on documenting some of the tools I use with Google Apps (migration, maintenance, overcoming some of the missing features like shared contacts, etc.) I am sure that will eventually be at least one article.
Regarding the specific products you mentioned...the simple truth of the matter is that I haven't done a Zimbra migration in about 3 years. (I've done several "from scratches", but no migrations.) I haven't touched Scalix or Sogo in forever. I've never moved Exchange --> Postfix, though I probably set up a Postfix or Qmail server every week. (Virtualmin!)
As a general rule, I write an article when:
I have to do something new adn this creates documentation
I found something actually took some effort
Something interests me that I feel would interest my readers
As to being a shill...
There are only two vendors who have ever sent me demo gear to play with. Pano Logic and Intel. I’ve been a Pano fan for ages, so I never turn down the opportunity to play with their latest stuff. (I do have to send that back when I’m done.)
Intel once managed to get me a few 10GBe cards. This was in part so that I could do some tests for an article, but had much more to do with my attempts at the time to woo a customer looking at a 5000-node render farm deployment towards Intel’s gear and away from Brocade. (I was demoing Intel’s cards actually doing offload and not failing.)
In every other case, I have either had to buy the equipment myself, or (in some cases literally) beg local sysadmins for the chance to work with equipment they have on hand.
If you have a personal bias against Microsoft, fine. Have fun with that. But please don’t assume I am shilling for them. I abhor all megacorporates equally. With the sole exception of Intel – who once gave some previous-generation network cards to one of the marketing companies they retain to deal with resellers and the press, who in turn gave them to me – what have any of these companies ever done for me? (And frankly, I feel that is more on the PR company involved than Intel proper.)
I’m an SME sysadmin, man! I – and my entire customer base – don’t even exist to these companies!
Yes, The Register exists because of advertising dollars. Yes, some of those dollars do pay for my sysadmin blog. But my sysadmin blog receives zero direction as to content. Zip, zilch, zero. If it says “sysadmin blog” on the article, or it is in the sysadmin blog section…it is 100% the product of me, my two purring kitties (who insist on putting some the characters into the article by walking on the keyboard), the number 42 and the almighty coffee.
If you want me to write an article about a given topic…ask. I am not Dell or Microsoft. I am not some faceless megacorporate or untouchable journo who never engages with the readers. I’m just a guy, you know? I fix computers, I troll people on the internet and I write things on a blog.
If I have time to do the research, you’ll find I am usually willing to give it a try. I can’t guarantee that I’ll get around to it, but that’s only because I don’t have a “permanent” writing gig here on The Register. I get approximately one article a week, and I don’t know how many I have left.
If that still makes me a shill writing "advertisements", well…you’re even more paranoid than I am.
Have you done this and did I miss it?
On another note, re: "Take a coffee break: we need to wait for MX records to propagate, as many DNS providers put a minimum TTL in place that overrides your settings." Microsoft Windows 2003 AD does the same thing.
We moved our group to BPOS first but can't see it having changed that much(upgraded to 365 in march)...
We moved MX records to point at Microsoft and then migrated users in batches or individuals. Microsoft servers then checked if user had migrated and IF YES, stayed in their environment and IF NO, they relayed back to our old server until all users had gone across.
This worked really well and didn't even lose messages mid transition. Users had to wait while it physically switched but was generally 20-30 mins not hours.
As I say, can't imagine why 365 would not allow same but we obviously migrated from BPOS to 365...again seamless, no issues for around 170 users.
As a user of outsourced email, salesforce, HR Software and much Dropbox for roaming management I can't recommend it enough.
As much as it may raise down votes in this audience, given limited budgets, skills and staff cover, does your company or team really have better environments, skills and backups than Microsoft, google and salesforce etc? I know if my car had a problem I would be closest, most passionate, know its history but....guarantee main dealer would be most knowledgable and best placed to resolve problems....more of the time?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
