Guest Post: What your mother never told you about Exchange 2010 Migrations
Colin Chaplin is a freelance IT Consultant specializing in IT transformation projects involving Microsoft software, and very occasional blogger ( https://colinchaplin.wordpress.com/ ). If you cut him in half, it would probably say 'infrastructure'
Microsoft do a pretty good job of getting knowledge ‘out there’ to us techs; there’s formal documentation, blogs direct from the people that put it together, quick-start documentation – in just about any format you want. Best of all, it’s not hidden away behind a support contract login, It’s one Search away from locating it.
So, if you’re planning an Exchange 2010 migration, you’re probably familiar with the term ‘you had me at ehlo’ and various books with a blue/black cover.
But there’s no substitute for experience, and although no two migrations are ever the same, here’s my top list of my ‘surprises’ from an email migration running into the tens of thousands of mailboxes. You may never encounter them, nor may I again, but maybe, just maybe it’ll save you a 1AM conference call…
1) You really, really need to understand your user profile
Don’t rely on the Microsoft defaults provided with the Calculator. You have, I assume, an Exchange environment already, and that you can go out there and measure. Once you have these stats, you might find that the idea of hosting 20,000 mailboxes on the old P3 laptop you’ve found in the corner of the office isn’t going to fly. Or more likely, you will find that your initially generous assumptions about deleted item retention and mailbox recovery might need to be trimmed a bit, and log file disks and required IOPS bumped a little. Or a lot.
2) Firewalls need love, too.
Traditionally, a firewall would be put between the bad guys on the internet, and the internal network, and perhaps some partner organisations. However, in a diverse network arrangement, it’s quite common that there might be a firewall between your internal client machines and your CAS’. Your firewall guys will be wise to the fact that a ‘traditional’ outlook client connection uses MAPI based on RPC, in which we’ll look to use TCP/135 and high ports. So, bang the protocols and destination IP addresses in the firewall, and away we go?!
Not so.
Modern firewalls can determine exactly what is the nature of the RPC traffic and allow/deny access based on the specific nature of the protocol. So they can allow outlook MAPI traffic, but deny the pointing of a compmgmt.msc at your CAS machines. This is done by specifying the UUID of the MAPI communication protocol.
When your client machine initially connects on port 135 there’s a conversation with the server about the desired universally unique identifier your client is looking for. The firewall, being piggy-in-the-middle sees this communication then allows on going communication based on it not only ‘liking’ the UUID but also the destination and ports discussed in the connection with the RPC server
Firewalls being things that like order and predictability will then seek to statefully inspect these communications, and make sure everything is just so.
And herein lies some fun.
Your firewall might boast big numbers like “10GBit throughput” but that’s only half the story. Doing such analysis as described above is expensive in terms of firewall resources, and you may find you quickly run out of CPU capacity, and the default-size state table sizes aren’t big enough. And whilst, we’re here, you might find that one packet in a million isn’t liked by the stateful inspection on the firewall.
3) If you’re migrating from Exchange 2003, you’re really migrating to Exchange 2007 too
I don’t mean you’re doing some kind of painful two step migration. Naturally, a lot of the literature about Exchange 2010 is comparing it to Exchange 2007.
That’s great if that’s your source platform is exchange 2007 but I bet many of you reading this are planning a migration away from Exchange 2003. During your preparations, you should read all the Exchange 2007 upgrade guidance too. Then you might figure things out like:
- The users will notice a difference when their mailboxes are moved (and I don’t just mean they will get ‘your mailbox is full’ messages less frequently. Outlook 2007 (and 2010 of course) are somewhat stifled by Exchange 2003 and doesn’t expose as many features to the users. This includes better free/busy information showing calendar entries (also known as “OMG EVERYONE CAN SEE MY CALENDAR” (you shared it out years ago!) ), modified out of office and better room booking
- You’d probably better check before you assure the secretary’s that they can access the boss’ mailboxes no problem no matter who is migrated and who isn’t
- And – just for fun- let’s stop anyone editing a Distribution List that’s over 5000 entries. The big boss’ PA love this when they want to send out a business critical email (actually, I’m pretty sure that’s not in the 2007 guidance, but I thought Id throw that in there as a freebie for y’all)
4) Storage also needs love
Now, you’re a switched on chap/ lady (you’ve read this far!) so you know that Exchange 2010 is putting to bed the notion that a big, expensive SAN is not necessary and good old DAS is the way forward. That’s great, but it doesn’t always play well in large organisations who have certain ways of doing things and storage teams looking after spinning disk. Plus, with large re-seed times, it can sometimes make sense to avail the services of a SAN.
If your lovely Exchange 2010 databases with their low IO requirements are set to nestle on a SAN, don’t just assume that because you’re using an army of super-expensive disks, all will be well. These disks connect through a fabric, and a storage controller, which all need to be up to the task of handling at least twice the load (or whatever your DR scenario is)
Sometimes, the more things change, the more they stay the same. Jetstress is still a critical tool in your arsenal whilst testing your change environment. Make sure you plan for it, and use it. It’s possibly a good idea at this moment to have a frank chat about jetstress, and day-to-day Exchange load on a SAN with your storage vendor, because you might find their interpretation of what’s required and what Microsoft produce out of the calculator (which you feed in to JetStress) might differ. Before you have that chat, have a look at the ESRP website, too. This provides paradigms of Storage designs that are certified to work in particular use cases. Chances are it might not fit your environment perfectly, but it provides a goo exemplar of what your design should achieve.
So, a few late nights then?
I’ve been involved with Exchange in one form or other since Exchange 4.0 and it’s probably my favourite Microsoft product. Whilst it is scalable and more robust than ever, the complexity has ratcheted up a few notches too and if nothing else I hope I’ve convinced you that you cannot be resourced, planned and prepared enough when if comes to an Exchange 2010 rollout and migration.
Useful Links