Saturday, November 1, 2008

Exchange 2007 Migration - Common Issues

During my recent Exchange 2007 Migration Projects, I had to work on and produce solutions for a number of interesting problems.

To ease your pain and shorten the troubleshooting process associated with such issues, I will try to list some of the most common issues and their solutions in this post. All of the problems and solutions listed here can also be found in different discussion forums, blog sites or KB articles, but so far I haven't seen any consolidated document for common issues in Exchange 2007 migrations. I hope this post will fill in this gap.

1. Problem with Autodiscover (Outlook Web Services) on Windows 2008
2. Outlook Anywhere (RPC over HTTP) Does not Work on Windows 2008
3. ActiveSync (EAS) Issue with dedicated CAS and Exchange 2003 Back-end
4. Unable to Uninstall Legacy Exchange Server (2003)

1. Problem with Autodiscover (Outlook Web Services) on Windows 2008
When Outlook 2007 is used to connect to an Exchange 2007 server, by default Offline Address Book, Out of Office Assistant and Scheduling Assistant features try to connect to the Web based services. All these features actually depend on Autodiscover feature of the Exchange 2007 Client Access server (CAS).

Outlook 2007 users detect problems with Offline Address Book, Out of Office Assistant and Scheduling Assistant. Especially, when trying to "Add Attendees" using Scheduling Assistant, Outlook crashes and restarts.

The problem is caused by .NET 2.0 SP2. Uninstalling .NET 2.0 SP2 resolves the issue, all Autodiscover related features start to function properly.The details of the problem and recommended solution can be found at my previous post:

2. Outlook Anywhere (RPC over HTTP) Fails on Windows 2008
For Outlook Anywhere feature to work properly, Client Access servers (CAS) need to access three TCP ports on the Mailbox Server: 6001, 6002 and 6004. Even in single server Exchange 2007 implementations, these three ports are needed.

When you try to access these three ports through telnet tests, you will notice that 6001 and 6002 are accessible. However, you cannot access port 6004. If you check the ports on the Mailbox Server using netstat, you can verify that the server is listening on the all three ports. For some reason, because when IPv6 is enabled (and it's enabled by default on Windows 2008), it prevents access to TCP port 6004. There is one workaround and one permanent solution.

For the quick workaround you can add the server's IP address and name in the local HOSTS file. Surprisingly this simple action re-enables access to port 6004.

For the permanent solution, you need to disable IPv6 for good. To disable IPv6, you need to perform the following steps:

In the Network Connections folder, obtain properties on all of your connections and adapters and clear the check box next to the Internet Protocol version 6 (TCP/IPv6) component in the list under This connection uses the following items. This method disables IPv6 on your LAN interfaces and connections, but does not disable IPv6 on tunnel interfaces or the IPv6 loopback interface.

Add the following registry value (DWORD type) set to 0xFFFFFFFF:

This method disables IPv6 on all your LAN interfaces, connections, and tunnel interfaces but does not disable the IPv6 loopback interface. You must restart the computer for this registry value to take effect.

You will also need to replace the following line in HOSTS file

::1 localhost

with this line:

#::1 localhost

and add the following lines
IPv4 address hostname of the computer
IPv4 address FQDN of the computer

(Please replace IPv4 address with the IP address value of your server and names with the actual name of your server for the entries given above)
After these changes, you need to restart the server. Following the restart you will notice that you can connect via RPC/HTTP(s) with no problems.

MS Exchange Team Blog has an excellent post about this topic at the following link:

Also Aaron Marks describes the problem and the solution in detail at his blog site:

3. ActiveSync (EAS) Issue with dedicated CAS and Exchange 2003 Back-end
During a well planned transition to Exchange 2007 from legacy Exchange environment, one of the recommended actions is to install a CAS server (on a seperate box other than Mailbox server) and redirect all OWA, RPC/HTTP and ActiveSync requests to this new CAS server. Since CAS uses a process called proxying, and has the ability to proxy for both Exchange 2003 and Exchange 2007 mailboxes, all requests will be proxied to proper back-end (or mailbox) server. For This setup provides the best co-existence support with the legacy Exchange mailboxes and lets you seamlessly transition to Exchange 2007. You can find more information on this topic at the following MS Exchange Team Blog post:

For mailboxes located on Exchange 2003 back-end server, you have to enable Integrated Windows Authentication on /Microsoft-Server-ActiveSync virtual folder in the Exchange System Manager (ESM) interface. Otherwise, OWA and Activesync access fails. Now comes the tricky part: When you try to enable "Windows Integrated Authentication" for /Microsoft-Server-ActiveSync virtual directory, you will notice that you cannot click on "Authentication" button since it's dimmed by default. If you enable "Integrated Windows Authentication" on the virtual directory using IIS Manager interface, Activesync users will receive multiple username/password prompts and will fail to access their mailboxes. This is behavior is the result of DS to Metabase (DS2MB) process which turns off Integrated Windows Authentication on the Windows 2003 back-end server.

Download and install the hotfix described in the following MS KB Article:

As described in the KB article, this hotfix enables the dimmed button, and lets you select "Integrated Windows Authentication" in ESM. Modifying the setting in ESM makes it permanent, and Activesync users can seamlessly access their mailboxes regardless of their Exchange server version.

4. Unable to Uninstall Legacy Exchange Server (2003)
At the final stages of an Exchange 2003 to Exchange 2007 Migration, you need to uninstall Exchange 2003 server(s) as a cleanup process.

When you try to uninstall the old Exchange server, you cannot select "Remove" option and receive the following message:

The component "Microsoft Exchange Messaging and Collaboration Services" cannot be assigned the action "Remove" because:

-One or more users currently use a mailbox store on this server. These users must be moved to a mailbox store on a different server or be mail disabled before uninstalling this server.

You double check the old Mailbox Store and make sure that no mailboxes are listed, the mailboxes were either moved to Exchange 2007 stores or removed from the organization. However Exchange Uninstall still creates the warning message and does not let you proceed with the "remove" operation.

The problem is actually not directly related to Exchange mailboxes. The uninstall program queries AD for the msExchHomeServer attribute and tries to find the name of the old server. If a match is found, simply produces the above error message and refuses to proceed.

To resolve the problem, you need to perform the following steps:
  1. Right-click the domain container, and then click Find
  2. Select the Advanced tab
  3. Select User from the Field button
  4. From the list of attributes displayed, choose Exchange Home Server
  5. Set the Condition field to Ends With
  6. Enter the Exchange server name into the Value field (Exchange 2003 server name)
  7. Click Add
  8. Click the Find
  9. In the results Window, select the listed user account
  10. Right-click on the user account name, then select "Exchange Tasks"
  11. Click Next on the first screen
  12. Select "Remove Exchange Attributes" on the second screen click Next and continue with the wizard till the end
  13. Repeat the steps 9 to 12 for each user in the results list
After this cleanup operation, you will be able to select "Remove" during the Exchange Setup, and will be able to proceed with the uninstall with no problems.

Following Microsoft KB Article discusses the same topic with a slightly different resolution:

Oz Ozugurlu also describes the problem and resolution at his blog site:

No comments: