Outlook 2003 Clients and Exchange Server 2010

I have a customer that has chosen to move their mailboxes from Exchange 2007 to Exchange 2010, and pending a desktop refresh has chosen to retain Outlook 2003 as the client running on Windows XP

As far as possible they would also like to minimise any impact to the users and the desktop profiles, while at the same time updating them to reflect that the mailboxes have been moved. There is a pending desktop upgrade to W7 and Office 2010 on the horizon, and we don’t want to touch the workstations twice if we can avoid it.

Long story short, it’s a headache.

There are a few things  to get your head around.

How to update Outlook 2003 to recognise the mailbox has moved, as it isn’t auto-discover aware.

Exchange 2010 isn’t Outlook 2003 friendly, we need to enable UDP push, and this involves client side registry changes and possibly firewall rules.

Outlook 2003 relies on Public Folders and these aren’t accessed via the CAS or the CAS Array in Exchange 2010.

We then as far as possible don’t want to change anything in the profile, like secondary mailboxes, other account settings, public folder favourites etc..

There are a few things we need to do to make this work.

Outlook 2003 and UDP Push Notifications

UDP Push notification wasn’t part of Exchange 2010 when it RTM’d but it was added in SP1 RU3.

However what was added was an option to enable it, the feature is there, but the functionality isn’t turned on. It’s fairly well documented, but it can be easy to misunderstand, especially the first diagram can be slightly misleading. The diagram shows a TCP/IP port that is statically configured, and if you just glance through the article you may assume that this is done server side, like the RU3 update, and then everything will work. It isn’t, and it won’t.

Outlook 2003 talks to the Exchange server on TCP 135, and typically negotiates a random high end UDP port to use for UDP Push notifications. Negotiation isn’t an issue if you have all your TCP/UDP ports open between the client and the server, but if you have a firewall in the way, if Exchange is hosted or in the cloud, then a fixed port allows the Outlook 2003 client to tell the Exchange server which port to use. Exchange then send notification traffic to the client on that port.

There will probably be few  situations where the client can connect on TCP 135 from outside a firewall, but I have seen this done. Using RPC/HTTPS, all of this is encapsulated in traffic over TCP 443 and it’s a non issue.

Normally we do this the other way around, we hard code TCP ports given out by the RPC endpoint mapper on the server side for example, but in the case of UDP Push we’re doing it in the other direction.

The port is fixed by a registry value, and it’s well documented in the article above, but for the record its

HKEY_CURRENT_USERSoftwareMicrosoftOffice11.0OutlookRPC, DWORD “FixedUDPPort, and the value should be in decimal, I used 59532.

Just to be clear, without UDP Push the Outlook client will default to polling every 60 seconds, the symptoms are that the client appears to be intermittently unresponsive, message don’t send immediately etc… but Outlook will connect and behave, it just seems slow.

The 60 second delay isn’t an issue in RPC/HTPS or OA either, because everything is encapsulated of HTTPS which typically is allowed thru the firewall, so it’s basically only a problem for Outlook 2003, online, over MAPI, behind a firewall.

Public Folder Access

Interestingly, we also have the issue where Outlook talks directly to the Mailbox server hosting the public folders, it doesn’t go via the CAS, so it’s a good idea to use hard coded or static ports for PF and Address book, and while MS don’t advise this, I use the same port for both UDP Push and Public Folders. This is discussed here. In fact, when you read this second article you understand why the TCP/IP port is shown in the diagram in the previous article.

It’s important to understand what they are used for, and what direction they go, UDP out to a fixed port is for Push Notification, TCP in to a fixed port is Public Folder Access to the Mailbox servers directly.

There may be some confusion if the same port is being used, but it’s for different reasons in different directions.

Netstat -a should show you the foreign address (server) established on 59532 if you browse the public folders, and the local address listening on UDP 59532 with no remote host connected, because UDP is connectionless.

C:>netstat -a
Active Connections
Proto  Local Address         Foreign Address        State
TCP    WKSTN18:1193          MAIL.DOMAIN.COM:59533   TIME_WAIT
TCP    WKSTN18:1199          92.24.14.150:59532      TIME_WAIT
TCP    WKSTN18:1259          MAIL.DOMAIN.COM:59532   TIME_WAIT
TCP    WKSTN18:1262          MAIL.DOMAIN.COM:epmap   ESTABLISHED
TCP    WKSTN18:1264          MAIL.DOMAIN.COM:59533   TIME_WAIT
TCP    WKSTN18:1265          MAIL.DOMAIN.COM:59532   ESTABLISHED
TCP    WKSTN18:1266          MAIL.DOMAIN.COM:epmap   ESTABLISHED
TCP    WKSTN18:1267          MAIL.DOMAIN.COM:59533   ESTABLISHED
TCP    WKSTN18:1268          MAIL.DOMAIN.COM:59532   ESTABLISHED
TCP    WKSTN18:1269          MAIL.DOMAIN.COM:59533   TIME_WAIT
.
.
.
UDP  WKSTN18:microsoft-ds  *:*
UDP    WKSTN18:isakmp        *:*
UDP    WKSTN18:1026          *:*
UDP    WKSTN18:1027          *:*
UDP    WKSTN18:1073          *:*
UDP    WKSTN18:1345          *:*
UDP    WKSTN18:4500          *:*
UDP    WKSTN18:8082          *:*
UDP    WKSTN18:59532         *:*
UDP    WKSTN18:ntp           *:*
UDP    WKSTN18:netbios-ns    *:*

Above you can also see TCP 59533 connected, because I’ve hardcoded this for the Address Book Service.

The Outlook /RPCDialog should also show a Public Folder connection directly to one of the PF servers by name because the connection to the Public Folders doesn’t go via the CAS or the CAS Array, and the server name is visible to the Outlook client, so you may need to open this port directly to each of the servers holding a replica of the folders, and you may want to choose a server name or use a naming convention that you don’t mind being visible.

So far so good. The Outlook client should now be able to connect to the server, but what other issues are we likely to have.

Delegate Sent Items

Way back when I first put this customer on Exchange 2007 with Outlook 2003 we had the Delegate Sent Items issue. A registry fix on the Outlook 2003 client allowed items sent on behalf of a mailbox owner to go to the owners mailbox, and not stay in the delegate mailbox. This worked with both cached and non-cached mode, over both RPC/HTTPS and MAPI. Roll along Exchange 2010, and this feature broke. Now it only works in cached mode.  The symptom here is that mail sent by a delegate on-behalf-of another user stays in the outbox of the sender. The recipient get’s the mail, but on the sender side, it just sits in the outbox. Turning on cached mode solves the issue instantly.

MS are very clear about this here.

Not all of my customers mailboxes are running in cached mode, legacy hardware, small disks, large mailboxes, security concerns, there are a number of reasons, but “turn on cached mode” isn’t really a good enough answer.

There are a number of discussions on this for example here, and here but on August 29th MS announced a solution (mostly), and thankfully it’s no longer a client side registry fix. The small caveat is that right now the options I need, namely SendAsItemsCopiedTo and SendOnBehalfOfItemsCopiedTo using the value from is the one that doesn’t work, but at least having the mail in both mailboxes solves the majority of the issues.

http://blogs.technet.com/b/sachinshah/archive/2012/08/29/mystery-of-the-sent-item.aspx

In fact in the official support article the “from” option is no longer even listed, so it looks like that one has faded into the background.

Global Address List Issues

This is an unusual one. In Outlook 2007 or 2010 a GAL entry is visible as Display Name <SMTP Address>

In Outlook 2003 it’s visible as Display Name <user CN portion of LEDN>

Outlook 2003 displays LEDN values for recipients

We moved the mailboxes using native Exchange 2010 power shell. In order to ensure that all mail is reply-able post migration we’ve populated all of the new target mailboxes with the LEDN values of the source mailboxes as X500 addresses.

This basically means that any addresses cached by Outlook 2003 will still work, and any mail received pre-migration can be replied to post migration, however, because Outlook caches the LEDN value of the mailbox, and this has now changed, the new LEDN value of the target mailbox is now cached as well as the old value!

You can test this behaviour by editing the LEDN value in the target mailbox. The auto-complete value cached and then displayed by the Outlook 2003 client is the edited LEDN.

In Outlook 2003 post migration, every user in the GAL that you’ve previously sent mail to will appear twice in the client presented from the auto-complete cache after you send them the first message.

Either address will work, both deliver mail to the correct and only mailbox for that user, and over time the old entries will drop out of the cache, but in the beginning it’s a headache, and not one you can do much about, except purge the cache, which is probably a bigger issue in itself.

On a side note, we noticed that post migration some client side rules may not process correctly when for example receiving mail from specific people. Clearing the auto-complete cache seems to help with this, so there is some client side processing based on the LEDN that get’s confused or hung up post migration on the old LEDN value, which the client no longer receives mail from and hence the rules don’t run.

You can delete the cached entries, and only the Exchange 2010 (target) LEDN comes back. A small but forgivable issue is that Exchange 2010 now appends a 3 digit random identifier to each LEDN to ensure uniqueness (post SP1 RU6), so Training, 10 becomes Training, 10c27. I think most people that even notice this can live with it, although it will prompt a few questions.

PRF files

So now that I know how to make Outlook 2003 behave with Exchange 2010, and I understand some of the issues I’m going to face, how do I actually update the client to recognise the fact that the mailbox has been moved. I need to factor in the use of MAPI, RPC/HTTPS and or cached mode client.

Our initial thought was to use the trusty PRF file. In fact we pushed out  the client config three years ago using a PRF file, so initially changing the server name in the PRF file looked easy enough. It is, up to a point.

Let me save you the time and testing I went through.

The [ServiceEGS] portion of the PRF file is the Exchange General Section

If you right click on your mailbox, and get Properties, then Advanced, or select the More Settings… button when configuring your mail account you are in the General section of your profile.

The options you see differ slightly on the General tab depending on which method you use to open it up, you may either see the Exchange Account name

Exchange Account Nam

or the Microsoft Exchange server: name

Exchange Server Name

This Global Section of the profile includes the Additional Mailboxes on the Advanced tab, and the Exchange Proxy Settings in the Connection tab as well as Cached Mode settings etc..

Any changes to this section of the PRF file will re-create the entire section, and you lose all of the existing settings, including additional mailboxes. This is frustrating, because if you manually edit the profile you can keep all the settings you need, and change just the ones you need, but if you use the PRF file it just wipes everything and recreates it with the new settings.

True, you can pre-cconfigure the cached mode options, and the exchange proxy settings, but what you can’t recreate are the user specific additional mailboxes.

This is documented here under Method 4. This article is about the need to enable RPC encryption for Outlook 2003, which you don’t necessarily have to do any more because Exchange 2010 post SP1 it’s off by default now, but the specifics about the EGS section in the PRF file are what’s relevant.

The following article gives some more information on changing settings in the PRF file, but it was this whitepaper that pretty much nailed this coffin closed, where it describes the process for changing the server name, and this involves editing the EGS section. (Page 6)

We did a lot of testing, which involved creating, backing up, updating profiles, and moving mailboxes. It is possible I guess that we missed a trick, and maybe this can be done, so this isn’t any kind of official statement, but suffice it to say I couldn’t make it work.

What we did do in the end was far simpler, and may or may not work depending on your situation.

We moved the mailboxes with Power Shell, and then we changed the DNS entries so that the old server name resolved to the new CAS Array. Outlook 2003 didn’t care, the cached mode clients didn’t have to re-cache, the additional mailboxes opened as normal, and everybody was happy. We didn’t have to touch the clients at all.

 Other Issues

There are several other issues with Outlook 2003 and Exchange 2010

These include

IMAP users of Outlook 2003 may experience issues on Exchange 2010 with sent items and deleted items folders

Outlook 2003 can only publish 2 months Free-Busy info on Exchange 2010

There are no “mailtips”, or “archive mailboxes” for Outlook 2003 users.

Outlook 2003 by default does not encrypt MAPI-RPC connections, however Exchange 2010 RTM does, ( although this changed in SP1)

Outlook 2003 can work with Exchange 2010, but like every step forwards, you take the new features for granted very quickly, and it’s only when you have to step back a few years to work with older technology you realise where the limitations are!