10 things to consider before transitioning from Exchange 2003 to 2010: "
The key to a smooth Exchange transition is planning — and lots of it. Brien Posey takes you through the key aspects of the process.
Transitioning from Exchange Server 2003 to Exchange 2010 is relatively painless, but it does require a great deal of planning. This article describes some of the things you need to know as you get ready for your transition.
Note: This article is also available as a PDF download.
1: You may not be able to reuse all of your server hardware
Exchange 2010 requires a 64-bit Windows operating system. Since Exchange 2003 works only on 32-bit versions of Windows, an in-place upgrade is out of the question. You will have to acquire at least one new server before you can transition to Exchange 2010. Depending on how your Exchange organization is configured, it may be possible to perform leapfrog migrations, in which existing server hardware is reused after the server’s contents have been transitioned. Leapfrog migrations are not always possible.
2: You can say goodbye to any legacy Exchange Servers
The transition process requires you to place your Exchange organization into native mode. As a result, you will have to decommission or upgrade any Exchange servers that are running versions of Exchange older than 2003.
3: You’ll have to make changes to your Active Directory
At a minimum, your Active Directory must be set to the Windows Server 2003 functional level. In addition, you will have to make sure that at least one global catalog server in each site is running Windows Server 2003 SP2 or greater. Finally, you will have to upgrade the Active Directory schema before you will be able to install Exchange 2010.
4. You’ll need some retraining
Exchange 2010 is nothing like Exchange 2003. Even the management tools have changed. The Exchange System Manager has been replaced by the Exchange Management Console and a command-line tool called the Exchange Management Shell. When you also consider all the architectural differences, you can see why retraining is essential.
5: Front-end Exchange servers have been replaced
Some articles on migration and transition seem to compare Exchange 2003 front-end servers to Exchange 2010 Client Access servers. In some ways, this is a fair comparison, because Client Access servers (commonly called CAS servers) host OWA. While front-end servers were optional in Exchange 2003, though, CAS servers are required in Exchange 2010 even if you never plan to use OWA. Every client connecting to an Exchange 2010 organization (including Outlook, OWA, and ActiveSync clients) connects through a CAS server.
6: Routing groups and administrative groups are gone
Routing groups and administrative groups were a staple in Exchange 2003. However, these features were removed in Exchange 2007 and are not present in Exchange 2010 either.
7: You’ll need to plan for backward compatibility
Exchange 2010 Client Access servers and Hub Transport servers are not backward compatible with Exchange 2003. Therefore, you will need to leave your front-end servers, your bridgehead servers, and possibly even your mailbox servers in place until the transition is complete. If you remove these server roles too early, users whose mailboxes still reside on an Exchange 2003 server may lose functionality.
8: The Client Access server has a built-in proxy
Once you implement an Exchange 2010 Client Access server, you should configure your external DNS entries so that all OWA requests flow to it. But you should leave your Exchange 2003 front-end servers in place. The Client Access server has a built-in proxy. If users who have an Exchange 2003 mailbox connect to an Exchange 2010 Client Access server, the request will be automatically redirected to an Exchange 2003 front-end server.
9: You’ll have to learn the server roles
In Exchange 2003, there were really only two server roles: front end and backend. Exchange 2010 has several additional roles. Before you begin planning your Exchange 2010 deployment, it is absolutely critical that you take the time to understand these new roles.
10: You’ll need to use PowerShell for some management tasks
The Exchange Management Console (Exchange 2010’s replacement for the Exchange System Manager) is built on top of a command-line interface called the Exchange Management Shell. The Exchange Management Shell is a Windows PowerShell environment with numerous Exchange specific cmdlets.
This means that any administrative action you can perform through the Exchange Management Console can also be performed through the Exchange Management Shell. But the reverse isn’t true. Although the Exchange Management Console contains the basic mechanisms for managing Exchange, Microsoft hides most of the more advanced functions. It is unrealistic to expect to be able to manage Exchange 2010 without occasionally having to use PowerShell commands.
Check out 10 Things… the newsletter
Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic’s 10 Things newsletter, delivered every Friday. Automatically sign up today.
"
(Via 10 Things.)
No comments:
Post a Comment