Best practice for upgrading from 2003 - 2010?

Is there a preferred method for upgrading Exchange 2010 and Client 2010?

Is there a recommended way to upgrade client server exchange? Should the exchange server be upgraded first to 2010 from 2003. Then the clients or does it really matter?

Find more posts tagged with

Comments

Turgon

You need an Exchange Architect to advise you. Royal no longer posts due to his professional obligations. Hopefully you will get some advice. Either way, take advice from your inhouse Exchange specialist. Heads can roll in a botched Exchange upgrade. High impact.

N2IT

Turgon wrote: »

You need an Exchange Architect to advise you. Royal no longer posts due to his professional obligations. Hopefully you will get some advice. Either way, take advice from your inhouse Exchange specialist. Heads can roll in a botched Exchange upgrade. High impact.

Thanks for the reply. This was just for high level knowledge more than implementation. I guess I was just being nosey that's all.

Thanks again Turgon!

Turgon

No worries. If you are PM for a messaging project do ensure your technical specialists are extremely well resourced, both internally, and externally through specialist consultancies and a direct line to Microsoft support. The technical requirements can be complex, speaking as someone who supported Exchange in the past. Problems with messaging will impact the whole company and get the PM fired.

ptilsen

As Turgon said, you really want an Exchange engineer to advise you on this. I have performed several Exchange 2003 to 2010 migrations in single-server and SBS environments, and even those had some specifics that had to be done differently based on the environment. In a more complex environment with roles separated and load-balanced/clustered across multiple servers, the migration can get trickier.

Even the high-level breakdown can be incredibly complex and will vary greatly between environments. Again, even in one-to-one migrations the specifics can vary, although I could provide a pretty good framework for such environments.

Also, the advice to have MS available is good. If the technical implementation is not performed by a very skilled Exchange engineer, you'll want to have Microsoft on the line. The cost of a support incident is immaterial, and if something goes wrong MS can, in some cases, walk the engineer through an entire phase of a migration like this.

Turgon

Echo that. N2IT if there is an Exchange migration on the horizon in your company and it's not going to be resourced properly, run away. 6 months at least to plan that properly. Let someone else take the bullet if the resources are not there.

N2IT

Turgon wrote: »

Echo that. N2IT if there is an Exchange migration on the horizon in your company and it's not going to be resourced properly, run away. 6 months at least to plan that properly. Let someone else take the bullet if the resources are not there.

Appreciate the heads up.

I was basically wondering if rolling out the client first before upgrading the new exchange servers was a big no-no or not a big deal.

It probably depends

Turgon

It entirely depends on what the Exchange expert tells you. Listen to what the specialist tells you and then plan accordingly. This is one of those situations where you are completely reliant on the expertise of your engineers.

N2IT

Turgon wrote: »

It entirely depends on what the Exchange expert tells you. Listen to what the specialist tells you and then plan accordingly. This is one of those situations where you are completely reliant on the expertise of your engineers.

Works for me!

Turgon

Cool. Do everything you can as a PM to support your engineers. They have the answers a PM lacks, and needs.

ptilsen

The client application in use matters quite a bit. If we are talking Outlook 2003, there are a couple minor things to watch for. If you're talking a wide variety of non-Outlook client access methods such as Entourage, POP or IMAP clients, ActiveSync phones, BES, etc, it can get messy. Outlook 2003 and on in pretty straightforward in use with Exchange 2003+, but the other methods have some details to them. Watch out for Mac client access in particular as the way certain Entourage versions work with Exchange is a completely different method between 2003 and 2010.

But, overall, I will agree with Turgon once again. If the technical expertise working on it is not up to the task, run away.

Turgon

Yup run away. PMP. Harvard MBA. It won't save the project. Expertise required and protected by a PM that listens and gives them every protection and all the resources they need..

N2IT

ptilsen wrote: »

The client application in use matters quite a bit. If we are talking Outlook 2003, there are a couple minor things to watch for. If you're talking a wide variety of non-Outlook client access methods such as Entourage, POP or IMAP clients, ActiveSync phones, BES, etc, it can get messy. Outlook 2003 and on in pretty straightforward in use with Exchange 2003+, but the other methods have some details to them. Watch out for Mac client access in particular as the way certain Entourage versions work with Exchange is a completely different method between 2003 and 2010.

But, overall, I will agree with Turgon once again. If the technical expertise working on it is not up to the task, run away.

I was just wondering if it was common practice to keep your exchange version at 2003 yet upgrade the clients to 2010. I just thought that was strange, but what the heck do I know? We have some users on 2003 and 2010 as well. Just thought I'd throw that in the mix as well.

ptilsen

N2IT wrote: »

I was just wondering if it was common practice to keep your exchange version at 2003 yet upgrade the clients to 2010. I just thought that was strange, but what the heck do I know?

Not strange at all. Client upgrades are cheap (in terms of labor), easy, and come with improvements visible to management (eg, Outlook gets prettier). Server upgrades are an enigma to management, and in many organizations are put off well past end of life. I'm just pleased to have not had any of my clients get stuck on Exchange 2000, with a healthy majority agreeing to upgrade to 2010.

On the other hand, not upgrading the client is also common. I have a handful of clients on all 2010-era MS software still using Office 2003. SMBs really like to cut corners, and luckily (for them), Microsoft has largely made this very possible. The vast majority of MS products made since 2002 still largely work as intended, even when mixed in a given environment. Exchange, Outlook, and friends exemplify this.

N2IT

ptilsen wrote: »

Not strange at all. Client upgrades are cheap (in terms of labor), easy, and come with improvements visible to management (eg, Outlook gets prettier). Server upgrades are an enigma to management, and in many organizations are put off well past end of life. I'm just pleased to have not had any of my clients get stuck on Exchange 2000, with a healthy majority agreeing to upgrade to 2010.

On the other hand, not upgrading the client is also common. I have a handful of clients on all 2010-era MS software still using Office 2003. SMBs really like to cut corners, and luckily (for them), Microsoft has largely made this very possible. The vast majority of MS products made since 2002 still largely work as intended, even when mixed in a given environment. Exchange, Outlook, and friends exemplify this.

PT I had a chance to talk to our exchange admins and they said that the reasons we are having a lot of the calendar issues is because of the 2003 server version and then 2010 client. Just wanted to give you the heads up. Another factor to consider (potentially) is that we still have some users on 2003.

Everyone

Easier to upgrade the clients first. Things go a lot smoother with Outlook 2010 on the client side. You can keep the clients on Outlook 2003, but there's more work to be done server side if you go that route AND want it to go smoothly. Really six of one, half dozen of the other there.

My preference is to roll out Office 2010 first.

Any Calendar issues are more from mix of Outlook 2003 and Outlook 2010 users, and only with shared calendars. You'll find that Outlook 2003 users don't have issues with calendars of other Outlook 2003 users, only with 2010 users. 2010 users seem to have no issues with either. Upgrade the Outlook 2003 user and watch the problem disappear. I think there was also a server side patch for Exchange 2003 that fixed this too, can't remember right now.

Things have become a LOT easier if you use the latest service packs and updates. It was a lot harder to get things to go smoothly with a 2003 to 2010 migration 2 years ago with RTM. SP1 made things a lot easier, and SP2 even more so. Plus a few hotfixes on the 2003 side.

fly2dw

N2IT wrote: »

Is there a preferred method for upgrading Exchange 2010 and Client 2010?

Is there a recommended way to upgrade client server exchange? Should the exchange server be upgraded first to 2010 from 2003. Then the clients or does it really matter?

Sorry if I am a little late on this, but thought I would try to help anyway. Good points have already been made, but I will try and give some food for thought.

In my opinion, it really does not matter which way round you deploy this, the main thing is to understand why you are upgrading in the first place. Exchange 2010 brings with it a wealth of new functionality, however if you have not sat down and thought about what it is you actually want it for, things may become difficult during deployment, due to bad planning. You need to look at functionality you are interested in and plan it into your infrastructure (Maybe even change you infrastructure to incorporate it).

For example a DAG (Database Accessibility Group) can give you great high availability, however it requires a great deal of storage planning. You need to make choices whether to utilise that expensive SAN that you may have already invested so much into, or purchase new cheap servers, with cheap storage (Create islands of storage for your DAG). No right or wrong answer as every environment is different, but careful planning is required. By the way I apologise if you think this is teaching you to suck eggs, but I am giving advice, based on mistakes I have witnessed in previous projects. I am not suggesting you have not already thought of this, but if you have then you are already in a good position.

To illustrate my point lets say you have Exchange 2007 and your mailbox servers are in a cluster (Lets say CCR) using a SAN as centralised storage. You want Exchange 2010 to take advantage of a DAG so you put 2 mailbox servers within your DAG using your SAN as centralised storage, well you could argue how exactly is this different from where you came from in principal? you have a tick in the box that you now have Exchange 2010 and a DAG, but totally missing the point and purpose of a DAG. With a little more research and planning you could make this so much more.

To use Outlook Web App with full functionality you need to use certain web browsers and certain versions within those web browsers. See here:

Exchange Server 2010 OWA Support Browser Matrix

If you don't then you end up accessing Outlook Web App using the light version (A stripped down interface and limited functionality). In theory this is the same as different Outlook client versions connecting to different Exchange servers. If you connect to Exchange 2010 using Outlook 2003, it works but you don't get all the functionality, you kind of get a light version in comparison to outlook 2010. Something end users need to be aware of, as sometimes they presume a new Outlook version means all functionality comes with it, which won't be the case if you are still on Exchange 2003.

Once you understand what functionality it is you most want from Exchange 2010, you may want to have a look into the future on other aspects of your infrastructure. For example if you heavily utilise public folders you may consider keeping an Exchange 2003 server in a co-existing environment with Exchange 2010 so that you can manage them better. If you are looking to decommission public folders in favour of another method or they aren't a dependency in your environment you can look to remove Exchange 2003 entirely.

Personally I would think on the point of Public Folders (As they can cause problems if left) and if you don't utilise them other than as an Outlook 2003 dependency then upgrade your clients first to Outlook 2010, introduce Exchange 2010 in a co-existing environment, and phase the Exchange 2003 infrastructure out. But like I said before it doesn't matter which way you choose as you could deploy Exchange 2010 first, but just be sure to work through all the default settings that may cause problems to your environment. Deploying Exchange 2010 with SP1 or SP2 can sort a lot of this for you. Exchange RTM does need a little tweaking here and there though. Best to check no matter what Exchange version you are deploying.

Best of luck!

thenjduke

Try the exchange 2010 deploy assistant from microst.

cknapp78

I would be glad to assist on this as well. I have designed and implemented 5 Exchange 2010 migrations in excess of 20,000 users in the past 2 years and just took over as Messaging Architect for a big Oil/Gas company in the NE US. Dealing with sites in 33 countries now. Talk about a headache...

Either way...feel free to reach out here or PM me if you need any help!