Dave Kawula - TriCon
To start off -- I would like to state that almost all of my clients are on Exchange 2003 and Outlook 2003 Sp3. This issue below will impact all of them in a big way as each of them currently uses some type of Terminal Server or Citrix Farm to publish Outlook. This has put the brakes on a lot of migrations right now as it is going to put a lot of work on the projects team if Microsoft cannot find a reasonable solution to this.
The stock answers I have received thus far have been -- Just turn on Cached Mode -- (Problem -- Doesn't work on Terminal Servers (Citrix) or Hack the registry to get the polling frequency down from 60 seconds to 10 seconds.
The problem is that the 10 second lag won't pass UAT and has effectively stopped a lot of Migration / Upgrade projects for us.
Cautionary note is this -- DO NOT Upgrade to Exchange 2010 if you have Outlook 2003 SP3 clients on a Terminal Server or Citrix Farm. Unless you are planning to upgrade ahead of time. Save yourself a lot of pain.
Below are my notes from the issue we have experienced.
Issue: Outlook 2003 Slow Performance – Deleting Items
Symptoms: Online Outlook 2003 Clients experience delays in deleting items from inbox:
New e-mail notifications from Exchange to Outlook, we receive them all the time. Most of us never look at the technique, because in most cases this works so there"s no need. But what if it doesn"t or you are experiencing delays? With Exchange 2010 this situation is more likely to occur than with earlier versions of Exchange, because many people are still using Outlook 2003 or earlier clients. To understand why this happens, you need to understand how these notifications work (or should I say worked).
Note: To improve readability, you should read “Outlook 2003 or earlier versions in online mode” when it reads “Outlook 2003″ from here on, unless states otherwise.
When Outlook 2003 connects to Exchange, it tries to register itself to receive notifications. If registration is successful, Outlook 2003 tells Exchange on what port it expects (UDP) packages to arrive, and it by default this is in the port range 1024-65535. When sending notifications, the Exchange server will also open a dynamic port in this range and connect to the registered client port. After receiving the notification, Outlook 2003 will retrieve the message, will display it in the appropriate folder, make a sound, show a systray icon, change your cursor, etc. When the registration for new mail notifications fails, Outlook 2003 will use a polling mechanism the check for changes.
The related knowledgebase article (kb2009942) mentions two solutions. One solution is a mere pretext and explains increasing the polling frequency. To do so, it requires applying Exchange 2010 Rollup 1 on the CAS server and configuring the following registry key on that CAS server:
HKLM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem\Maximum Polling Freqeuency (DWORD, range 5000-120000)
The reason for performing this step on the CAS server is that Exchange 2010 will determine the polling frequency, not the client. The setting will work immediately, but clients need to reconnect in order for the new value to become effective. Note that setting this value lower than 10000 has no effect because Outlook 2003′s minimum poll rate is 10000.
This solution seems to improve the performance but is not a complete fix. In my testing it appears to take anywhere from 7 to 12 seconds to delete and item. Now if a user simply presses the down arrow key or changes focus on the window the deletion is immediate.
Another solution is to enable cached mode for Outlook 2003 clients. This will not solve the delay in receiving new e-mail notifications, but it will solve the most annoying issue, being the delay in visual feedback. In cached mode users won"t notice the delay because they"re working with a local copy of their mailbox. Any changes (sends, deletes, moves) will happen in the local cached file (OST), and Outlook will update their Exchange mailbox in the background.
Although this option will work for most of the desktops and remote locations it will not work for our Citrix Farm. Citrix / MS Terminal Servers do not allow us to turn on Cached Mode for Outlook.
If Outlook client versions are upgraded to Outlook 2007 or higher this problem is non-existent. As Outlook 2007 and on communicate via Asynchronous (push notification) with Exchange Server.
Microsoft has escalated the case to their Escalation Engineers. They are going to have us run some diagnostics on the Exchange Server and are looking at filing a bug for this particular issue. Once that is done they are going to see if they can release a custom Hotfix or release a new rollup that addresses this issue. I am hopeful that Solution 4 comes up with a fix as it is the least invasive for the project team or the end users. I expect a call back tomorrow morning and will update more information on Solution for as it is available.
Note: Downgrading is not an option
Once the Schema has been extended to Exchange 2010 it cannot be downgraded for Exchange 2007 compatibility. Thus downgrading the Farm is not an option.
Of all of the options listed above I have prioritized the solutions in the following order:
1. Escalate the case with Microsoft and hopefully they will release a custom hotfix that will address this issue. This is a major bug and it will be affecting every Exchange 2003 to Exchange 2010 deployment running older Outlook clients. (If # 1 works none of the below is required)
2. Use Cached mode on all workstations – This will allow us to move over their accounts to the new Exchange Server. They will not experience slowness
3. Leave the Outlook Version the same on the Citrix Server and publish a support article for the end users and inform them how to work around this issue.
4. Have users use the new OWA – In comparison to what you get with Outlook 2003 Full Version I believe it has a richer end user experience than the older version.
5. Upgrade the Outlook Client to 2007 or 2010 only the Citrix Servers for now and then phase in the rest of the upgrades as time permits.
TriCon Technical Services Inc.