How Outlook works [LegacyExchangeDN secret]
I was attending one of the Ignite sessions about Exchange back in 2010, and Ross Smith gave us a wonderful session about Outlook connectivity. I was always wondering how Outlook really discover the information it might need, and how it connects to Exchange servers, especially in complex deployments. In this blog post, I want to share with you how Outlook works and what is the story of LegacyExchangeDN.
What information Outlook needs
Outlook needs three pieces of information to connect to a mailbox:
- Database Name
- Home Server [RPC Client Access Array Server attribute of the DB] [a.k.a legacyExchangeDN]
- LegacyDN of the mailbox
The rest of information is not that important and are return by Autodiscover service.
If profile is configured, outlook will try to resolve the Home Server in the Outlook profile and connect to it using TCP. This represents the Client Access Server Array object which should not be resolving externally in all cases.
Database linkage to CAS Arrays
Each database has a GUID and an important attribute called legacyExchangeDN, also referred to the RPCClientAccessServer for that database. The information about where the database is currently mounted is not stored in AD, instead the Active Manager component in each mailbox server in the DAG [Secondary Active Manager SAM or Primary Active Manager PAM] knows about this info.
When the database is created in a mailbox server, the legacyExchangeDN is set to the CAS Array FDQN if exists in the local site or default to the first CAS server installed on that site.
This value doesn’t change if the database get mounted in different site unless that mailbox database copy is assigned an Activation Preference = 1.
The value of the legacyExchangeDN of the database is what Autodiscover returns to Outlook as the home server. Outlook if no yet configured, will honor this value. If the Outlook profile already exists and pointing to a CAS array, it will not honor the Autodiscover information about the change on legacyExchangeDN depending on different factors.
To discover how Outlook works, I will list couple of scenarios and explain what would happen in each one, and how Outlook works in each condition.
It is important to remember that neither Outlook nor CAS care about the AD site in which the CAS server is located at. If the database get mounted on different site, and you change just the DNS record of the primary CAS array to point to the CAS array of the secondary site, everything works fine. This works for RPC Clients.
Rule – The RPCClientAccessServer property of the database [a.k.a the database legacyExchnageDN] always points to the RPC CAS array that is in the same site as the copy of the mailbox database with the lowest activation preference (which equals 1).
In the below figure, when the database get mounted on MBX-C, the RPCClientAccessServer property will stay CAS-Pri.contoso.com. Outlook user will still point to cas.pri.contoso.com and CAS direct connect over the WAN will happen from CAS-Pri to MBX-C. If CAS-Pri is inaccessible, Outlook will get disconnected!
The only time the system changes the RPCClientAccessServer value on a database, is when the administrator changes the Activation Preference number on the activated database copy, such that it now has the lowest value (meaning it becomes the preferred copy), as seen below.
However, Outlook clients with an existing Outlook profile would continue to use the old RPC endpoint rather than the new RPC endpoint (even though Autodiscover detected the change). This is because the old RPC endpoint does not return an ecWrongServer response to the client.
RPC endpoint accepts the connection, therefore, Outlook ignores the Autodiscover response because it has a working connection. In the event that the old RPC endpoint becomes inaccessible, Outlook 2007/2010 would update its settings. At any time you could force Outlook to use the new RPC endpoint by forcing a profile repair in Outlook.
You can also manually change the RPCClientAccessServer property of the database to point to the new array instead of changing its activation preference.
The same happens when you move a mailbox to a database in different AD site. Outlook will continue to use the old and configured RPC CAS array unless that array become inaccessible or you trigger Outlook profile repair.
The details about how Outlook works and how LegacyExchangeDN is actually changing in major updates of Exchange. After Exchange SP2 RU3, the following changes happen:
- By default, once you have installed SP2 RU3, when you move mailboxes between AD sites, all versions of Outlook will get prompted to restart and the Outlook profile’s RPC endpoint will be updated.
- Cross Site Database Access changes:
- This behavior depends on the value of DAG property called (AllowCrossSiteRPCClientAccess). If set to $true, then the behavior in Scenario 3 will occur. That is, Outlook will stick to the original configured CAS array and cross WAN CAS direct connect will occur, unless you change the LegacyExchangeDN of the DB or change the Activation Preference and the Outlook profile get repaired or the primary CAS array is not available.
- If the value of AllowCrossSiteRPCClientAccess is set to $false, which is the default DAG property value, then Outlook profile’s RPC endpoint will be updated to be the RPC Client Access Server array that is in the same AD site where the database is active and mounted. Note that the RPCClientAccessServer property is not updated as that defines the preferred site.
Actually, the CAS array log on the primary site will ask Outlook to redirect to the CAS array in the secondary site although the LegacyExchangeDN of the database is still pointing to the primary CAS array.
I hope by know you know how Outlook works and how LegacyExchangeDN is being used in different situations. There is a great video session given by Ross Smith about this topic that will help you more learn about how Outlook works and about LegacyExchangeDN is used.