I’ve not been doing as much work with Exchange Server as I’d like in recent years; so when a friend asked me to help out with carry out an Exchange Server 5.5 to 2003 migration for one of his contacts I was happy to get involved (although I was slightly nervous as this was effectively a refresher course for me being carried out on his production system).
I’m not going to make this a “how to do it” post as I posted an article about migrating from Exchange Server 5.5 to 2003 a couple of years back and one of the areas where the Exchange Server team have really excelled is in the creation of the Exchange Server Deployment Tools which guide an administrator through each step of the process, running diagnostic and setup utilities as they go. For further information, the Exchange Server Deployment Guide is also worth a read.
This article highlights simply some of the issues I came across (on what was a fairly simple migration – Outlook Web Access and Exchange Server 5.5 on two separate servers to a new Exchange Server 2003 server in the same organisation and site) and how to resolve them:
- The first problem came when Exchange Server setup detected that the installation was being performed on a Windows Server 2003 service pack 1 (SP1) computer (Windows Server 2003 R2 is effectively the same as Windows Server 2003 SP1) and advised that this has known compatibility issues with Exchange Server 2003. After reviewing the Exchange Server system requirements it turned out that it’s not a problem on a non-clustered server if Exchange Server is also running SP1 or later so Exchange Server service pack 2 (SP2) was installed immediately after Exchange Server setup had completed.
- The Active Directory Connector (ADC) is probably the most difficult part of an Exchange Server 5.5 upgrade but the latest version of ADC includes tools to guide an administrator through the process of creating connection agreements between the Active Directory and Exchange Server directory services and verifying replication. In this case, the ADC Tools highlighted an issue which meant it was necessary to grant Full Control NTFS permissions to the Exchange Server 5.5 service account on the C:\Documents and Settings\username\Local Settings\Application Data\Microsoft\Active Directory Connector folder (as described in Microsoft knowledge base article 820268). Further problems with objects reporting as not replicated (as described in Microsoft knowledge base article 842142) were resolved by reinstalling the ADC, using the version supplied with Exchange Server 2003 SP2.
- After installing Exchange Server 2003, one shutdown took an extended period of time; however this is a known issue, described in Microsoft knowledge base article 555025.
- One of the great features of Exchange Server has always been the referral mechanism that allows MAPI clients to update their profiles when a mailbox is moved between servers; however, on this occasion, some Outlook 2003 clients failed to update their MAPI profiles. This is a known issue and is resolved by installing Office 2003 SP2, as described in Microsoft knowledge base article 914855. No such problems were experienced with Outlook 2002 (XP) clients, although the site replication service (SRS) did hang on one occasion and needed to be started before clients could successfully remap their profiles.
- When accessing Outlook Web Access (OWA), requests to http://exchange2003servername/exchange/ appeared to be diverting to http://exchange55servername/exchange/; however it was later discovered that the referral was only taking place where the currently logged on user (domainname\Administrator in my case) had a mailbox that had not yet been migrated. Once all mailboxes had been moved across, OWA stopped redirecting access.
- Many Exchange Server 5.5 administrators are used to being able to access all objects (including the contents of other user’s mailboxes) using the Exchange Server service account; however with Exchange 2003, even when an account is delegated Exchange Full Administrator rights over the Exchange organisation it is unable to access other mailboxes as inherited permissions apply an explicit deny over certain rights. This is by design but can be overridden as described in Microsoft knowledge base article 821897 to give an account full access to all objects in a particular store. In this case I delegated Exchange Full Administrator rights to a global security group called Exchange Admins (and added that group into the local Administrators group on the Exchange server), then granted another account full control over all objects in the mailbox store. This mean that I had a group over which the membership could be edited as required to grant rights to administer the Exchange organisation, plus another account (I should really have made this a group too) that could view the contents of other user’s mailboxes.
In all, the migration was reasonably successful, although I do still need to decommission Exchange Server 5.5 (it was left in place to allow the Outlook profiles to update as users log in to the system) and some HTTPS publishing issues with Proxy Server 2.0 need to be resolved before I can call the job complete. In fact, those HTTPS publishing issues turned out to be the cause of much panic on Monday morning when Exchange seemed to be falling down around us. One of the methods we had tried to proxy inbound SSL was using the Winsock proxy client on the Exchange Server as described in Microsoft knowledge base article 184030. Although the SSL proxying hadn’t worked, the Winsock Proxy Client had been left installed on the Exchange Server – it didn’t seem to be causing any issues on Sunday night but by Monday morning the Exchange System Manager and Active Directory Users and Computers administration tools were inaccessible, which Microsoft knowledge base article 325322 suggests is related to a DNS problem. It was purely by chance that I managed to trace this back to the Winsock proxy client (as described in Microsoft knowledge base article 280833) and once this was uninstalled, all services became available.
One final issue left to resolve was to restore access to mailboxes for BlackBerry users, caused by the problems publishing OWA via HTTPS (although any change to the URL used to access OWA externally would have caused this). The resolution was to remove existing account details from users’ Vodafone Mobile E-mail profiles and recreate them using the new address as described in BlackBerry knowledge base article KB-03133.
Finally, for all Exchange Server admins, whether migrating to a new version of Exchange or administering an existing system, there are many tools for Exchange Server 2003 available for download from the Microsoft website.
Mark,
hopefully you can help me. I did a 5.5 to 2003 migration and went well as far as migrating the mailboxes and Exchange profiles picking up the new 2003 server.
I left both server running for a while and when decided to remove the 5.5, the unistallation did go so well. I got several dll errors, so I decided to do an installation to that NT with 5.5 box and that didn’t take it.
Is there any way I can remove the old 5.5 server from ESM assuming the 5.5 server is offline?
Thanks.
Conna,
I’m pretty sure there are some Microsoft knowledge base articles for forcibly removing servers from the organisation… unfortunately I don’t have the numbers here but you should find the information if you follow the step-by-step instructions in the Exchange Server Deployment Tools.
HTH, Mark