OVERALL STATUS: No, having Outlook 2003 clients is not a deployment blocker. However, you need to understand the following sections and make configuration changes as applicable.

Back since November 9th, 2009 where Exchange Server 2010 released to manufacturing (RTM), there have been a growing concern around whether enterprises are prevented from upgrading or migrating their current Exchange 2003 or Exchange 2007 based messaging infrastructure to Exchange 2010, if Outlook 2003 clients is used within the organization.

The intention with this Wiki page is to list the concerns that we have seen among our customers, partners, and in the miscellaneous Exchange communities.

As some of you probably recall, we already blogged about some of the major considerations on the Exchange team blog, but this article includes a few additional concerns and goes into more detail than the blog post.

Table of Contents



RPC Encryption Requirement

Current Status: Non-issue

Exchange 2010 SP1
With Exchange 2010 RTM, the RPC encryption requirement was an issue with mitigation. However, in Exchange Server 2010 Service Pack 1, the RPC encryption requirement has been disabled by default. This means that any new Exchange 2010 SP1 Client Access Servers (CAS) deployed in the organization won't require encryption and Outlook 2003 clients will connect without the need to enable the RPC encryption feature in the Outlook profile.


note Note

Having the RPC encryption requirement on an Exchange 2010 CAS server disabled doesn't lower the security between Outlook 2007/2010 and any Exchange 2010 CAS server. RPC communication for these Outlook versions will remain encrypted as long as the client has the RPC encryption feature enabled. It's only the requirement itself that is disabled on the Exchange 2010 CAS server.

Exchange 2010 CAS servers deployed prior to Service Pack 1, or upgraded to Service Pack 1, will retain the existing RPC encryption requirement setting.

 

Exchange 2010 RTM
When upgrading or migrating an organization that fully or partly uses Outlook 2003 to Exchange 2010, we hear there are out of the box problems, when trying to connect an Outlook 2003 client to an Exchange 2010 RTM mailbox? We heard this is because an Exchange 2010 RTM Client Access Server by default requires an Outlook client to support RPC encrypted traffic in order to be able to connect.

While it’s true the default configuration of an Outlook 2003 client doesn’t have support for RPC encryption, this requirement is fully supported with Outlook 2003.

There are two methods that can be used in order to have Outlook 2003 clients connect to an Exchange 2010 RTM mailbox:

Method 1: Enable the RPC encryption support in Outlook 2003

If “Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server” is enabled under the “Security” tab in the Outlook 2003 profile (see figure 1), the client will be able to connect to an Exchange 2010 RTM mailbox.


Figure 1: RPC Encryption enabled in Outlook 2003

If you are working with or for a small organization, it may be acceptable the end user enables this feature manually, but if you have thousands of users in the organization, you would want to enable it using a group policy (GPO). The steps necessary to implement a GPO to enable this setting are included in this KB article.


Important
The “EnableRPCEncryption” registry key mentioned in the KB article was originally introduced via a hotfix for Outlook 2003 SP2. This means that clients that either runs Outlook 2003 SP2 or an older version of Outlook 2003 doesn’t respect this registry key. In addition, Outlook 2003 clients not running SP3 are not supported by Microsoft.

 

Method 2: Disable the RPC Encryption requirement on the Client Access Servers

Instead of enabling support for RPC encryption in the Outlook 2003 profiles, you also have the option of disabling the requirement for RPC encryption on all Exchange 2010 RTM Client Access Servers in the organization.

This can be accomplished using the Set-RpcClientAccess cmdlet:

Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False


Figure 2: RPC Encryption requirement disabled on Exchange 2010 CAS servers

As mentioned earlier Exchange 2010 SP1 servers that hasn't been upgraded from Exchange 2010 RTM has the RPC encryption requirement disabled by default.

The following KB article describes the symptoms and remediation in detail:

The core Exchange 2010 TechNet documentation also describes the configuration that can be used to remediate the issue:


note Note

Unmanaged client machines cannot be controlled using GPOs or login scripts. If you have unmanaged machines connecting to Exchange 2010 using Outlook 2003, one solution would be to send those users a script or a registry file which they can run manually on their machine to enable the RPC encryption setting.

Exchange 2010 lack support for UDP Notifications

Current Status: Issue with mitigation


Important News

With Exchange 2010 SP1 RU3, UDP notifications has been re-added to Exchange 2010. This means that the below symptoms will be resolved once Exchange 2010 SP1 RU3 is applied in your Exchange 2010 SP1 environment. Roll-up update 3 for Exchange 2010 SP1 can be downloaded here. Read more about how UDP support is enabled in the following KB article: Folders take a long time to update when an Exchange Server 2010 user uses Outlook 2003 in online mode.


A Further Update
With Exchange 2010 Sp2 a lot of work was done to improve the UDP notification mechanism (which was added back as per the above news), this was done to improve the coexistence story with Outlook 2003 further. If you are planning to deploy Exchange 2010 in an environment with older Outlook clients i.e. 2003, ensure that you are running Exchange 2010 Sp2 + latest RU. This will ensure the best possible experience and that none of the keys mentioned below are required. With 2010 Sp2 in place, the experience is as optimal as possible, however you do need to enable the UDP notifications by setting the EnablePushNotifications key. This is discussed in detail in the following KB article; http://support.microsoft.com/kb/2009942

With Exchange Server 2010, there is no longer support for User Datagram Protocol (UDP) notifications. When opening a mailbox using Outlook 2003, Outlook 2003 tries to register itself to receive new message notifications. By default Outlook 2003 tried to register for UDP notifications but since this notification method isn’t supported with Exchange 2010, Outlook 2003 will instead revert to polling the Exchange server for changes in the mailbox. Despite the fact that Outlook 2003 initiates the polling behavior, the Exchange server will dictate the polling frequency. By default Outlook 2003 polls the Exchange server every 60 seconds.

Since Exchange 2010 doesn’t support UDP based notifications, Outlook 2003 won’t be able to register itself using this method, which means changes made to any of the folders in the mailbox won’t be reflected before Outlook 2003 polls the Exchange server for changes. The result of this is that notifications about new messages etc. will be reflected in the Outlook 2003 client with delays of up to 60 seconds.
More specifically, you will see the following symptoms:

Two methods exist to remediate the polling issue described above:

Method 1: Change the Polling Frequency

The issue can be remediated by installing Exchange 2010 Service Pack 1 which includes support for a new registry key that can be used to lower the polling frequency to 5 seconds.


Figure 3: Lowering the polling frequency value

Note
The registry key doesn’t reinstate UDP in Exchange 2010; it only lowers the polling frequency.

 

Method 2: Enable Cached Mode in Outlook 2003 Clients

The cached mode synchronization process uses a different architecture to update folders versus Outlook 2003 clients in online mode. So another option is to enable cached mode for all Outlook 2003 clients within the organization.

The following KB article describes the symptoms and remediation in detail:

Opening multiple shared calendars & additional mailboxes

Current Status: Issue with mitigation

Exchange 2010 SP1 together with the resolutions mentioned later in this section, allows you to open as many as 16 shared calendars or additional mailboxes simultaneously independent on whether the mailboxes are located on Exchange 2003, 2007, or 2010. If you have more than 16 calendars or additional mailboxes opened, you may randomly see error message similar to the one shown in Figure 4.


Figure 4: Error message when opening more than 16 calendars

With Exchange Server 2010 RTM deployed into an Exchange 2003 or Exchange 2007 organization, it was a common issue that when an Exchange 2003 or Exchange 2007 user tried to open more than two additional Exchange 2010 mailboxes or shared calendars using Outlook 2003, she would receive one of the following error messages:

When an Exchange 2007 user tried to send an e-mail using Outlook 2003, she would sometimes also receive the following error message:

These issues were resolved with Update Rollup 2 for Exchange 2007 Service Pack 2 and a hotfix that were released for Exchange 2003 SP2. More information about the issues and how they are resolved can be found in the following KB articles:

Although the above mentioned issues were resolved, some customers, partners, and individuals in the Exchange communities reported they still experienced issues when trying to open approximately multiple shared calendars and/or additional mailboxes using Outlook 2003.

For most organizations, the issue can be remediated by installing Exchange 2010 SP1 as this service pack includes a fix that makes it possible for an Exchange 2003, 2007, or 2010 user to open as many as approximately 16 shared calendars or additional mailboxes using Outlook 2003.


Figure 5: By default approximately 16 Calendars can be opened using Outlook 2003

If you have users that needs to open more than 16 shared calendars or additional mailboxes using Outlook 2003, you can adjust the RPC related throttling policy settings using the Set-ThrottlingPolicy cmdlet. Specifically, you need to increase the value for “RCAMaxConcurrency” which by default is set to “20”. The RCAMaxConcurrency parameter indicates how many concurrent connections an RPC Client Access user can have against a server running Exchange 2010 at one time.


Figure 6: Default setting for the RCAMaxConcurrency throttling policy value

For instance, to increase the value of the “RCAMaxConcurrency” setting in the default throttling policy from 20 to 30, open the Exchange Management Shell and run the following command to first create a variable for the policy:

$a = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}

Then pipe the variable to the Set-ThrottlingPolicy commandlet:

$a | Set-ThrottlingPolicy -RCAMaxConcurrency 30


Figure 7: Increasing the value for the RCAMaxConcurrency throttling policy setting

In order to apply the changes, restart the “Microsoft Exchange Throttling” service on each CAS server in the organization.

You can read more about Exchange 2010 SP1 throttling policies in the Exchange 2010 documentation on Microsothe Exchange Management Shell and run the following command to first create a variable for the policy:

$a = Get-ThrottlingPolicy | where-object {$_.IsDefault -eq $true}

Then pipe the variable to the Set-ThrottlingPolicy commandlet:

$a | Set-ThrottlingPolicy -RCAMaxConcurrency 30

Error message when Outlook 2003 clients try to open multiple shared calendars in Exchange Server 2010: "The connection to the Microsoft Exchange server in unavailable. Outlook must be online or connected to complete this action".

If you see event 4696 with a description similar to the following logged in the application log on the Mailbox servers in the organization:

"Mapi session "00cc8dde-64d7-4353-8050-00fc2057aae3: /O=xxxx/OU=xxxx/cn=Recipients/cn=John" exceeded the maximum of 32 objects of type "session"."

You need to increase the maximum allowed sessions per user and/or maximum allowed service sessions per user limit from "32" to "64" or even higher. See more information at: http://technet.microsoft.com/en-us/library/ff477612.aspx.

Finally it should be mentioned that in some cases it is necessary to run “Outlook.exe /resetnavpane” on the affected machines running Outlook 2003. Bear in mind, that this switch will removed any shared calendars from the profile so these must be added manually afterwards.

Adding multiple shared calendars & additional mailboxes

Current Status: Issue with mitigation

In some cases you may have an issue adding shared calendars or additional mailboxes to an Outlook profile and is presented with the following dialog box.


Figure 8: Unable to display folder when adding shared calendar or additional mailbox

This may occur even when you have increased the throttling limit for “RcaMaxConcurrency” as well as added the maximum allowed sessions per user and/or maximum allowed service sessions per user limits.

A network trace using NetMon on the client where a user tries to add a shared calendar or additional mailbox shows that a DNS query for “Instance-GUID.contoso.com” is performed against a Global Catalog server in the Active Directory domain.


Figure 9: DNS Query against

The response from the Global Catalog server returns a “Name Error” as shown in Figure 10 as the <Instance- GUID> cannot be resolved to the respective user’s alias.


Figure 10: DNS returns Name Error

To fix this issue, install the Outlook 2003 hotfix mentioned in this KB article.

 

Viewing and Modification of Delegate Information

Current Status: Issue with mitigation

 

When reviewing or modifying delegate information via Tools>Options and choosing the Delegates tab, Outlook 2003 may exhibit some or all of the following symptoms:

 

 

In previous versions of Exchange Server, the Outlook Client talked directly to a Global Catalog server after a DSProxy referral. In Exchange Server 2010, the Client Access Service runs the Address Book Service which provides the NSPI endpoint that Outlook clients connect to for accessing directory information.

This issue is caused by the method Outlook 2003 requests data from the Address Book Service on the Client Access Server. The issue is corrected in current versions of Outlook 2007 and 2010, but will not be corrected in Outlook 2003.

The workaround to this issue is to limit which users should be delegates on mailboxes, and grant general calendar sharing permissions via the following method, which is also applicable to other Outlook folders.

 

  1. Right-click the Calendar folder, and then click Properties.
  2. Click the Permissions tab.
  3. Click Add.
  4. Click the name of the user who you want to grant permissions to, click Add, and then click OK.
  5. In the Name box, click the user name, and then choose the permission level, for example Editor in the Permission Level box.
  6. Click Apply, and then click OK.

 

Methods to force Outlook 2003 to contact a Global Catalog server directly are published in the Microsoft Knowledge Base article KB319206, How to configure Outlook to a specific global catalog server or to the closest global catalog server. This technique is not supported with Exchange Server 2010 unless advised to do so by a Microsoft support representative.

Exchange 2010 Public Folder Database requirement

Current Status: Issue with mitigation

Unlike Outlook 2007 and 2010, Outlook 2003 clients rely on public folders. If a public folder database doesn’t exist, Outlook 2003 users will be blocked from connecting to their Exchange 2010 mailbox and receive the error message shown in Figure 11.


Figure 11: Error message when an Outlook 2003 user connects to an Exchange 2010 mailbox

There are several reasons why a public folder database is required for Outlook 2003 client. First, Outlook 2003 in cached mode uses the “OFFLINE ADDRESS BOOK” system folder to download the offline address book (OAB) and the “SCHEDULE+ FREE BUSY” to retrieve and update free/busy information.


Figure 12: Offline Address Book and Schedule+ Free Busy system folders

Second, if you’re installing Exchange 2010 into an existing Exchange organization running Exchange 2007, it’s important you add the Exchange 2010 public folder database to the replica list of the “SCHEDULE+ FREE BUSY” folder. If this step isn’t completed, users who use Outlook 2003 cannot publish their free/busy data in Exchange Server 2010. Instead hash marks appear in the free/busy data for these users. More information as well as the steps that can be used to remediate this issue can be found in the following KB article:

Offline Address Book (OAB)

Current Status: Issue with mitigation

If the client machine on which Outlook 2003 is installed has been configured to use a proxy server, you must enable "Bypass proxy server for local addresses" under Internet Options > Connections > LAN settings or add the CAS server or CAS arrays to the exception list shown in Figure 13.


Figure 13: Proxy server settings in Internet Explorer

If a proxy server is used in the organization and you haven’t done one of the following:

The Outlook 2003 clients will get an error when trying to download the offline address book (OAB). For more information about the error messages and the steps necessary to remediate the issue, see the following KB article:


Note
This issue also affects Outlook 2007 and 2010 clients.

Outlook 2003 clients will also receive an error message when trying to download the OAB if the correct OAB hasn’t been specified for the Exchange 2010 database(s). For more information and steps required to remediate this issue, see the following KB article:

Exchange Server name appears as Instance-<GUID>

Current Status: Issue - no mitigation

Important News

A hotfix for Outlook 2003 has been released to resolve this issue. For more information, see this KB article.

A few customers, partners, and individual folks in the Exchange community have reported that a few of the Exchange 2010 users running Outlook 2003 randomly have issues connecting to their mailbox. After examining the mail profile in Outlook 2003, you can see the Exchange server name appears as Instance-<GUID> where <GUID> is a randomly generated GUID (or number). Re-resolving ('Check Name') the appropriate server name in the Outlook mail profile resolves the issue.


Figure 14: Instance-GUID issue in Outlook 2003

 

Note
Seeing Instance-<GUID> in conversation between an Outlook 2003 client and an Exchange 2010 server is normal (when Instance-<GUID> appears inside Outlook in the folders list view on left hand side); It does NOT mean you are hitting this particular issue. You experience this issue if the Outlook mail profile gets updated to refer to the Exchange server as Instance-GUID.

 

The problem behavior can be triggered by networking issues, patch applications, server reboots, etc. It requires Outlook 2003 to lose connectivity to Exchange and have a delegate mailbox logon attempted on a connection before the primary mailbox logon is attempted on that connection. This can affect users who are accessing shared mailboxes or folders of other users from their Outlook 2003 while connecting to Exchange 2010.

Currently there is no proper resolution available for this issue. However, to remediate this issue temporarily, simply re-resolve the Exchange server name in the Outlook mail profile. If possible, you may also remove the shared mailboxes or shared folders (like calendars) from the profile, preventing this issue from occurring in the future or create a new mail profile in Outlook.

Microsoft is working to investigate this issue for a fix. You can contact Microsoft Support to report this issue and request further assistance. Currently no KB article exists for this issue.

RPC over HTTP Connectivity

Current Status: Issue with mitigation

In some situations Outlook 2003 users connecting to an Exchange mailbox using RPC over HTTP receive the following error message:

“Server Unavailable”

Although this is an Outlook 2003 specific client issue, the issue is not specific for Exchange 2010 organizations. It could also appear in organizations running Exchange 2003 or 2007.

The problem occurs if the RPC proxy server extensions do no load correctly. You can find more details and a description of how the issue can be remediated in the following KB article:

Unified Communications

Current Status: Issue – no mitigation

If the organization uses Office Communications Server (OCS), users running Outlook 2003 would the free/busy information for a meeting will not reflect in the Office Communicator client. This means that if a meeting is scheduled for a user, this isn’t showed via the Office Communicator presence status. For more details around this specific issue, see the following KB article:

This issue can only be remediated by upgrading clients to Outlook 2007 or later.

In addition to the above issue, the presence information for a Microsoft Office Communications Server user may not appear, or may appear intermittently. This issue is not specific to Outlook 2003 but can also occur to Outlook 2007 and 2010 users. The behavior occurs when a user's Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) does not match the user's primary email address or when the user has multiple email addresses and can be remediated by adding a SIP proxy address in Exchange for the user account that specifies the user’s SIP URI. In addition, when Outlook 2003 is used two registry entries must be added to the machines on which Outlook 2003 is installed. For more details around how this issue can be remediated, see the following KB article: