Cross-Site RPC Client Access Connectivity Behavior (RTM, SP1, SP2 through SP2-RU2)

Cross-Site RPC Client Access Connectivity Behavior

With Exchange 2010, a major change was instituted in the way clients connect and access mailbox related data. Unlike previous versions, clients no longer connect directly to the Information Store on the Mailbox server role to access mailbox data. Instead, clients connect to a set of services on the Client Access server (CAS) role and services within the CAS role access mailbox data using MAPI/RPC from the Mailbox server on behalf of the connecting user.

Figure A

Figure B

Basically, one simple change was made such that all mailbox-related MAPI connectivity goes through the RPC Client Access service on the Client Access server role.

A new property was added to the Mailbox database, RPCClientAccessServer, which defines the legacyExchangeDN that should be used to access the particular database. This property takes a FQDN as its value. To ensure that you have high availability and fault tolerance in the event a CAS fails, this value should be the FQDN of a load-balanced CAS array. This load-balanced FQDN is what we refer to as an RPC Client Access Server array.

Figure C

Outlook Experience

All Outlook versions behave in a consistent fashion in a single datacenter (or single Active Directory site) scenario. The Outlook profile’s RPC endpoint is the RPC Client Access Server array (or a specific CAS if for some reason you did not create an array, which you should have done). Whenever a failure occurs within the DAG (database failure, server failure, etc.), the RPC endpoint does not change, thus Outlook continues to connect to the same RPC Client Access Server array. Whenever a failure within the CAS array (CAS failure, load balancer failure, etc.) occurs, the RPC endpoint does not change, thus Outlook will continue to attempt to connect to the RPC Client Access Server array.

If we change the RPC Client Access Server array DNS entry’s IP address to now point to the secondary/standby datacenter’s RPC Client Access Server array. Autodiscover continues to hand out the primary datacenter RPC Client Access Server array as the RPC endpoint. Existing Outlook clients do not need any reconfiguration; once the DNS cache on the client is updated, the client simply connects to the endpoint that now resides in the standby datacenter

Note: Neither the client nor the CAS really care about the site in which the CAS exists, they simply accept that they are able to connect and that the CAS the client is connected to is able to provide access to the mailbox.

Cross-Site Database *over Behavior

To understand this scenario, it is important to understand that when you configure a multi-site DAG, the RPCClientAccessServer property for a given database is typically associated with the RPC Client Access Server array that is in the same AD site as the copy of the mailbox database with the lowest activation preference number. For example: Figure D

Figure D

If we activate the copy of the database in the secondary/standby datacenter, the users will continue to leverage the RPC Client Access Server array from the AD site where the mailbox database with the lowest activation preference value resides as their connectivity endpoint.(figure E)



A simpler way to look at this behavior is that Outlook always connects to the configured RPC endpoint (assuming it is reachable) regardless of the database’sRPCClientAccessServer property value.

System ever change the RPCClientAccessServer value?

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 (Outlook 2003, on the other hand, would not as it does not leverage Autodiscover). At any time you could force Outlook to use the new RPC endpoint by forcing a profile repair.

When administrator manually updates the RPCClientAccessServer value after a cross-site database *over event

If the administrator manually updates the RPCClientAccessServer value to point to cas-sec.contoso.com for MDB1 after the mailbox database copy on MBX-C is activated (whose ActivationPreference value is greater than 1), then Outlook clients with an existing profile will continue to use the old RPC endpoint rather than the new RPC endpoint as long as the old RPC endpoint remains available (profile repairs will correct the issue). Outlook profiles created after the RPCClientAccessServer value change would use the new RPC endpoint.

Moving Mailboxes between Active Directory Sites

Prior to Exchange 2010, when you moved mailboxes across servers, the Outlook RPC endpoint would update to point to the Mailbox server (or clustered Mailbox server instance) hosting the database where the mailbox resides. After the mailbox move was completed, the Outlook client user would be prompted with the “The Exchange administrator has made a change that requires you quit and restart Outlook” dialog. After restarting Outlook, the client would be connected to the new RPC endpoint.

With Exchange 2010, you may have noticed that when you moved mailboxes between AD sites, users did not receive this dialog. Furthermore, you may have noticed that users also did not have their RPC endpoint updated to reflect the RPC Client Access Server array associated with the mailbox database in the AD site where the mailbox now resides. 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.

If the old RPC endpoint becomes inaccessible, Outlook would update its settings (Outlook 2003, on the other hand would not as it does not leverage Autodiscover). At any time you could force Outlook to use the new RPC endpoint by forcing a profile repair.

Mailbox Moves SP2 RU3 and beyond

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.

If you review the RPC Client Access logs on the source RPC Client Access array you will see:

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Notice that the RPC operation (ROP) is WrongServer (also known as ecWrongServer). This forces the Outlook client to do a profile discovery and update the profile based on new information found within the directory. The profile gets updated and once the client is restarted, the client establishes its connections to the new RPC endpoint.

And since this question will be asked, what other conditions will warrant the “The Exchange administrator has made a change that requires you quit and restart Outlook” dialog?

1. When you specify the DoNotPreserveMailboxSignature property on New-Moverequest.
2. When the source and target mailbox databases have a different public folder hierarchy store.
3. When you move your mailbox from a legacy version of Exchange to Exchange 2010.

Cross-Site Database *over Events

Cross-Site database *over event behavior will depend on the value of DAG property AllowCrossSiteRPCClientAccess.  If you set theAllowCrossSiteRPCClientAccess property value to $true, then the behavior, described in the previous section is the default behavior - in the event that the database is activated in the standby datacenter, the users will continue to leverage the RPC Client Access array in the AD site where the mailbox database with the lowest activation preference value resides as their connectivity endpoint.

If you set the AllowCrossSiteRPCClientAccess property value to $false (the default value for the property is $false), 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 RPCClientAccessServerproperty is not updated as that defines the preferred site.

if you review the RPC Client Access logs on the source RPC Client Access Server array you will see:

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Like in the move mailbox scenario, the WrongServer ROP forces the Outlook client to do a profile discovery and update the profile based on new information found within the directory. The profile gets updated and once the client is restarted, the client establishes its connections to the new RPC endpoint.

Conclusion

So there you have it – with SP2 RU3 (or later) you can ensure that mailboxes moved between AD sites will have their profile updated correctly. In addition, in the cross-site database *-over scenario, you can control whether to allow the cross-site RPC connectivity or to force the Outlook client to use the RPC Client Access Server array that is in the same AD site as the activated and mounted database (the default behavior)

IIS LOGS - Log Parser (tool)

Logparser

Logparser is a Tool developed by Microsoft which you can use to analyze different Log files and File formats. It is not primary designed for Exchange Server but can be used to analyze the different Exchange and IIS log files.

Stable release : LogParser 2.2.10  / 2005

Download : http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=en

GUI for Logparser

The GUI has only a few menu items. The function to save a query for later execution or edit is nice.

Download: http://www.logparser.com/simpleLPview00.zip.

The command SELECT * FROM System will show you all system event log entries on the local machine.

You can export the query results to a CSV file.

Architecture

Logparser can analyze Log files from many different Log file formats like Textfiles, EventLogs and Registry. Microsoft Logparser uses a SQL like Engine to make Data queries, to aggregate data and to format data for displaying.

IIS Services and Log file Formats

The following table shows the supported log file formats for Exchange services like Web, SMTP and NNTP.

 

IIS W3C Protocol fields

If you want to analyze the W3C log files for OWA usage, you must know which Properties you can specify in the Logparser tool. You will find the same table for SMTP Log Fields in the Online help from Microsoft Exchange 2003.

Input Formats

The input formats provided by Log Parser 2.2 include:

• Input formats that parse log files generated by IIS and return the entries in the logs
• Input formats that parse generic text log files formatted according to the CSV, TSV, NCSA, W3C, and XML standards and return the fields contained in the logs
• An input format that returns events from the Windows Event Log
• Input formats that return information on Active Directory objects, on files and directories, and on registry keys
• An input format that parses NetMon capture files and returns information on TCP/IP packets and connections

Output Formats

Output formats perform the opposite function of the input formats: they consume records and do something useful with the fields contained in the records. The output formats provided with Log Parser 2.2 can:

• Save records to text files formatted according to the CSV, TSV, W3C, and XML standards
• Save records to text files formatted according to generic user-specified templates
• Display records to the console or to a GUI window
• Upload records to a table in a SQL database
• Format records according to the Syslog standard, and dispatch records to a Syslog server, to a text file, or to a user
• Create Excel-style charts that present the record’s numeric data in a graphical format

Logparser Basics

If you are using Logparser for the first time you should open Logparser with the /? Command to display a list of available commands. As you can see, Logparser is capable of many Input formats.

A simple query

The following Picture shows Logparser in Action to query a logfile in W3C format to find how often the IP address 84.233.178.2 is in the logfile. Logparser queries the Exchange Logfile named EX060326.LOG.

Output

With the help of the “NAT” option, Logparser will display the results in the CLI (Command Line Interface) a little bit clearer. You can also use Logparser to display Logparser results as HTML reports. To use Logparser with HTML output you must use Templates. Templates will give Logparser the option to display query results in HTML format.

The following example shows a graphical HTML Report with a template.