Colin’s IT, Security and Working Life blog

July 27, 2012

What your mother never told you about Exchange 2010 Migrations

Filed under: Techy — Tags: — chaplic @ 3:32 pm

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 logfile 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 ongoing 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 maibox 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.


February 6, 2012

Considerations for Scheduling Exchange 2010 Migrations

Filed under: Techy — Tags: — chaplic @ 8:49 pm

So, you’ve designed your shiny new exchange environment, and you’re probably migrating from a creaking Exchange 2003 environment?

In theory, the outage for users takes as long as the size of their mailbox and connection speed. However, most organisations will want to schedule migration in batches probably out-of-hours, to allow for full system backups and operational tests.  It also makes user comms that much simpler.

Obviously it depends on your users work profiles, but if we assume standard office workers and a Monday to Friday working week, how many days to do migration? For the purposes of planning, I’d always include a spare day to allow a rescheduling of a failed migration. So, you could migrate 6 days-a-week, but what about the helpdesk hit when 3 times as many people get their migrated mailbox on a Monday morning?

How do you actually build a schedule for user moves? There are a few choices/ Decisions to be made


  • Per Server – start with the first user and first server and keep going till the last user on the last Server. Means you’ll get old servers shut down ASAP. However, the challenge here is how quickly can the old server spit out data? This is likely to be a choke point.


  • Per Business Unit – will likely mean a random split of users across all source exchange servers. However.. What if something goes drastically wrong – would you knock an entire department out at once? Depending how good your directory services are, just getting this information could be tricky


  • How Many people/ data – Given the speed of your connectivity and source servers (I really hope performance of your new exchange 2010 tin isn’t a concern!) your testing will suggest how much data you can transfer in a single migration window. However, if you could migrate tens of thousands of users in a night as they all had small mailboxes, what’s your appetite for helpdesk calls should even 0.1% of people have problems

Here’s an option that mixes the two approaches.

Firstly, don’t migrate on a per-business-unit approach. This makes scheduling a nightmare, but more to the point introduces the risk of an entire team being knocked out at once. So pick users seemingly at random then communicate with them individually

If you have 5 exchange servers, take one person off each Exchange server and increase your person counter, and also total up their mailbox size. Assuming you don’t reach your limit of number of people to migrate OR maximum data to transfer, then move to the next mailbox server and add the next user.

If you do reach a user or mailbox size limit, then zero your counters and declare a new batch.

Keep adding batches till you have a fixed set, of, say, two weeks s worth of migrations.

This approach should evenly spread the load across all source Exchange servers, and minimises the impact to an individual business area should a problem occur

The logic to actually achieve this is a bit complex. I resolved this issue for a client with a little bit of VBscript that throws all the values needed (mainly from AD)  into an SQL database, then a second bit of VBSCript which produces excel spreadsheets with the user details on them.

Decide how much advance warning you want to give users, 2 weeks from initial communication is probably enough.

14 days before you plan to migrate your first batch, email the users and let them know, inviting then to reschedule if inconvenient.

If you’re increasing users mailbox quotas, be sure to tell them this on the email, because for them it’s probably the biggest feature!

The next day, email your second batch of users, the next day your third batch, and so on.

Obviously, you will need follow-up reminder emails closer to the time. I’d recommend informing users you need at least 48 hours to cancel scheduled migrations.  OK, so we all know that’s not strictly true and important cancellations will still happen at the last minute but hopefully it will reduce the number of last-minute migrations.

Keep the messages clear, short and snappy, but direct users to an intranet site for further explanation and a wiki/ FAQ site.





Blog at