Note: This applies to Exchange 2010.
I always wonder how outlook knows how to connect at the end to the database hosting my mailbox. At TechEd Europe 2010 , Ross Smith gave us a nice session about this topic. I was searching for my notes until i found it. So here you go. We are talking bout Exchange 2010 here.
What information Outlook needs
Outlook needs three piece of information to connect to a mailbox.
- Database Name
- Home Server (RPC Client Access Array Server attribute of the DB), aka. The database legacyExchangeDN
- LegacyDN of the mailbox
The rest of information are not that important and are return by Autodiscover.
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, (nor internally, only if you want to force Outlook Anywhere behavior)
Database linkage to CAS Arrays
Each database has a GUID and also has an important attribute called (legacyExchangeDN). LegancyExchangeDN is also referred to the RPCClientAccessServer for that database.
The information about where the database is currently mounted is not stored in AD, instead each Active Manager server in each mailbox server in the DAG (SAM or 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 is still not 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.
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 to 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. The 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, the Outlook will get disconnected!
The only time the system changes RPCClientAccessServer value on the database is when the administrator changes the ActivationPreference number on the activated database copy such that it now has the lowest value (meaning it becomes the preferred copy), as seen below.
However, the 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.
The 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.
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.
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 ActivationPreference 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 the 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 the 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.