When it’s time to say goodbye to 2003…

Let’s face facts, 2010 is out, 2007 has been out, and that means that 2003 is slowly but surely fading into obscurity.  Make no mistake, we’ll see lots of 2003 in the real world for some time to come, but many of my clients are starting their migrations to the newer Exchange Server platforms.  There’s a lot of good reasons to migrate, and a lot of great native and 3rd-Party tools to help, but when you are at the point where you want to turn off the Exchange 2003 servers for good, don’t forget you need to do a few things first.

Exchange 2003 servers may seem to be alike, but the first server you installed in your environment holds special significance in the Exchange Organization.  So as you migrate users off and into the new systems, make sure you don’t simply shut down the first Exchange 2003 server and walk away.  Some of the things you need to do to that first server are critical!

If you use Public Folders, you need to replicate any folders that reside on the first Exchange server of the site. Chances are that you have already done this for your more common folders, but have a long, hard look at the PF tree and make sure that there are no folders homed only on that Exchange 2003 box.

The Exchange 2003 Offline Address Book will be homed on that first server as well.  If you are upgrading, make sure to create multiple versions of the OAB on one or more of the new servers (OAB3 OAB4, etc).  Make sure your users are then getting their OAB info from the new servers instead of the first 2003 server in the site.

Ensure that another server holds all necessary Master Roles for Exchange.  Many of these roles aren’t required for newer versions of Exchange, but it pays to do the homework to make sure.

If you use custom connectors that must continue to work in the new versions of Exchange; make sure you get them set up on your Hub/Transport and Edge servers to ensure communication continues.  SMTP is native, but others are not.

Once you step through these items (and possibly a few others like Schedule+ info which needs to be migrated, not simply moved), you can safely remove that first Exchange 2003 server in your site.  If you need to figure out which one was the first, or if you need more details, check out the KB article from Microsoft on how to go about doing this:

http://support.microsoft.com/kb/822931

Migration is a fact of life that most of us will face in the next year or two.  Don’t get caught short because you missed one or more critical steps for that one last Exchange 2003 box.

Manage your migrations to minimize co-existence

Exchange 2010 is beginning to get traction out in the real-world, which is by no means a bad thing.  As folks begin to upgrade, though, there is a chance that you’ll end up with extended co-existence between different software versions and packages, and that can make life a living hell for technical staff. Multiple versions of multiple platforms can be difficult to manage at best, and if that management must continue for months (or longer) you could be setting yourself up to fail right from the start.

Co-existence of platforms is a necessary thing. Especially in larger organizations, the likelihood that you will be able to move all your users and systems from one software package to another in a weekend is slim at best. So, no matter if you are moving from a totally foreign system like Notes, or just upgrading between 2003 and 2010 on the Exchange platform, you will almost definitely need to have both systems running for a period of time as you move users and 3rd-Party tools.  The key is to keep that time period as short as you can, and here’s why.

When multiple versions of a messaging platform (or multiple platforms) you must make sure you’re patching both independently, staying up to date on multiple security threats and dealing with end users who have to have changes made across both system sets.  Since it is highly unlikely that you will have the benefit of extra staff during the migration, that means that the existing staff suddenly find themselves doing twice the work.

If the same number of people are forced to do twice the work, things fall through the cracks.  Patches get applied incorrectly or not at all, threats are left unaddressed and shortcuts abound.  It’s easier to open a hole in the firewall than try to deal with two sets of rules to manage connectivity. It’s easier to only focus on news and updates for the newer systems than to try to keep up with the influx of information for both platforms. The upshot of this is; that the longer you have both systems co-existing, the more opportunity you’ll find for something to break on one platform or the other.  This endangers both systems, and possibly everything else in your environment.

So, when planning for your migrations, work as much as you can to ensure that you do not require extended periods of co-existence if they can be avoided.  Sometimes you will need to have extended migration timelines – it’s unavoidable – but wherever you can do migrations quickly, you should.

Look before you leap

There’s a great deal of talk these days about migrating directly to Exchange 2010 instead of jumping first to the 2007 version of the platform.  The arguments for and against this got more complicated when Microsoft did a reversal for support and announced that 2007 would be able to run (at some future point) on Server 2008 R2.  This effectively extended the support cycle of 2007, which means that a slightly older, and more thoroughly tested and widely installed, version is a legitimate option going forward.  That being said, many clients are opting to just go to Exchange 2010 from whatever they’re on now, skipping 2007 if it isn’t already in place.

I’m going to avoid discussing the pros and cons of going to Exchange 2010 directly in this particular post (that’s fodder for quite a few additional posts though).  Let’s just say that you’re jumping from an earlier version directly to 2010 and go on from there.  While most of the process isn’t too bad overall, there are a couple of sticking points that you’ll need to have sorted out before you make the move.  In smaller organizations, these are pretty easy issues to take care of, but on large-scale roll-outs, they can be a problem.

First, make sure your domains are at least at Server 2003 native functional domain levels.  Most of you are already there, but just in case you had a few NT servers hanging around, be ready for this one.  As long as all your servers are 2003 and up, making this change doesn’t have a lot of impact on your domain.  You can find out about the impact of raising Domain Functional Levels in this TechNET article.  So, what if you DO still have Exchange 2000/Windows 2000 servers in your environment?  You need to upgrade to Exchange 2007 as an interim step to 2010.  Since the Exchange 2000 life-cycle is definitely over (and has been for a while), Microsoft offers no method of co-existence between Exchange 2000 and Exchange 2010 – migration or otherwise.

Once your domain is prepped to 2003 or 2008 native mode, you then must plan to keep your old Exchange infrastructure long enough for the migration to occur.  That’s because the Mailbox systems for one version of Exchange can’t talk to any other in most cases.  So a 2003 Mailbox Server can’t talk directly to a 2010 Mailbox Server without some assistance.That assistance is in the form of Bridgehead servers (2003) or Hub/Transport and Client Access Servers (2007). You will need to have at least one of each for each Site you have set up in Exchange/AD.  One note, this has nothing to do with the migration itself, this is all about the period of co-existence you’ll need to go through until everyone is on the 2010 architecture.

After you have upgraded your Domain Functional Level and set up your front-end server systems, you can begin the process of installing the first of your Exchange 2010 server systems.  Start with the Hub/Transport and Client Access roles (unless you are installing them on the Mailbox Role server itself) to allow for message routing to get set up.  This lets mail flow between the 2010 and legacy front-end servers, so when you start moving mailboxes, you don’t lose mail connectivity.

Finally, once you’re sure mail is flowing correctly and that no one is about to get lost in the shuffle, take one more backup of the legacy systems (just to be safe) and start your migration.

You can find a guide to preparing for and deploying Exchange 2010 at this TechNET site.  Along with other blogs and Microsoft sites, this should be required reading before you even download the software and play with it in a lab.  With a migration that includes a period of co-existence with earlier versions of Exchange; careful, proper planning is not a nice-to-have thing.  It is a solid requirement that must not be overlooked or under-appreciated.

Something Old, Something New

As many of you know, Exchange Server 2010 Released To Manufacturing (RTM) today, with TechNET and MSDN releases to follow later this week.  There are a ton of new features, like Database Availability Groups and Archiving and compliance put in place in this version, so it’s a big step for Microsoft.  As you might expect, I’ll be writing quite a few articles on the new features as Exchange 2010 rolls out.

In the meantime, a recent 180 degree turn by Microsoft on support for Exchange 2007 has extended the theoretical useful lifetime of that platform by quite a bit.  It may not be time to start writing off Exchange 2007 just yet =)

As reported by Mary-Jo Foley in this ZDNet Blog post, MSFT has announced that they will continue to support Exchange 2007 into the Server 2008 R2 platform.  Prior to this point, official support for Exchange 2007 would end on the Server 2008 RTM platform, limiting the lifespan of the 2007 product to the 2008 RTM server. That wasn’t going to be tomorrow, or anything like that, but it certainly would be a shorter time-span than if Exchange 2007 got R2 support. 

Yielding to immense pressure from the end-user community, MSFT did acknowledge that not everyone was ready to upgrade to Exchange 2010.  There were no details on exactly when an update for Ex2007 would be available for R2, but suspicions are that it will be done via either a Roll Up or possibly even a new Service Pack early in calendar 2010.  Traditionally, this type of compatibility update had been done as part of a Service Pack, so my bet is riding on that idea.

Either way, the news that Exchange 2007 will live on to Server 2008 R2 is welcome.  This allows organizations who are in the middle of roll outs to not worry about if their servers are installed with Server 2008 RTM or R2, and will allow those migrations to complete on the 2007 platform.  This, in turn, allows upgrades to 2010 to occur without being rushed due to OS incompatibility issues.  There is something to be said for the fact that this decision will slow adoption of Exchange 2010 overall, but it will mean better, more structured roll-outs over time.  Safer, stronger and better planned upgrades are never a bad thing.

Update on Wildcard certificates

Not that long ago I talked about using wildcard certificates to allow you to move OWA and ActiveSync services from one physical server to another.  Since single certificates are assigned to a single server, failing over or moving to another server would cause the clients to suddenly lose SSL connectivity, as the certificate would not match up, and ActiveSync devices cannot pop up the error about a non-secure connection. OWA can, but it can be troublesome with end-users who suddenly start seeing security warnings.

Following up on this theory of using a domain-assigned wildcard certificate, research has shown that older Windows Mobile devices (WM 5 or earlier) cannot leverage these types of certificates at all.  WM 6 and higher can leverage this technology, but earlier versions were not coded with the required information to recognize that a certificate could possibly be assigned to more than one physical server or networked device.

So, for those using WM 6, OWA and Outlook Anywhere, you can use wildcard certificates to allow for services to move from server to server as required.  For those using earlier versions of WM (or the 3G iPhone - though the jury is still out on that one), you must use server-specific certificates, and re-configure the devices' ActiveSync connection if the server itself moves. 

None of this impacts Blackberries, as they authenticate via the RIM network, and not directly to the Exchange servers.  If you're using Blackberries, wildcard certificates offer the ability for all other mobile systems (OWA, Outlook Anywhere, etc) to move with your servers in the event of a loss of a particular physical machine, while RIM will handle moving the Blackberry devices.

Long story short, if you're on WM 5 or earlier, be ready for a few support calls when you need to move the services or fail over between servers - even if you use wildcard certificates.  If your users are on the new iPhone systems, be sure to keep a close watch on Apple's forums, as new information is being discovered every day.

From the field

Brace over at Double-Take Software had a great report from the field with info for those folks who are about to move their Exchange infrastructure to a new location:

"A good engineer that I worked with on a Dell project contacted me yesterday and brought up a good question. He is working with a client in New England and they are in the process of planning to move their Exchange Server to a different site subnet. Because Exchange is so tightly integrated with Active Directory there is much more to plan for with moving Exchange than there is Double-Take. However, the question is below and I have some answers from our of our own PS engineers.

"I'm working on a project where the customer needs to change the IP address of all their existing Exchange 2003 servers and move them to another subnet. I'm familiar with the process for Windows and Exchange, but how does that affect Doubletake? Are there any KB articles that might explain the process?"

If using the DTAM functionality within Double-Take it should be as easy as re-enabling protection once the server has been moved. "Just disable protection before doing the re-IP'ing, then go back through setting up the protection afterwards. Should probably not select the "use last configuration" or whatever that option is...since it might get the wrong IPs."

Pretty easy but as a best practice you should always contact our technical support department for any tpe of planning deployment just to verify potential changes being made. Double-Take Technical Support can be reached at 24/7 at 800-775-8674 or 317-598-2066.
For Technical Support in the European Union +44 (0)1905 330820 +33 (0)1 47 77 15 06 +49 69 6897776-66
Or find answers online at support.doubletake.com!"


Of course, that client would probably want to check out the latest version of the Full-server Failover Option too, as that could make life a lot easier during migrations of Exchange, or anything else running on Windows.