Some of relatively common and difficult issues we see in support are related to Outlook connectivity to Exchange. There are several variations that we classify as connectivity (related to server performance or otherwise). They can include:
Note: If you are an Office 365 customer with users having mailboxes in Exchange Online, we highly recommend using our new Office 365 Support and Recovery Assistant (aka SaRA) to troubleshoot Outlook connectivity and other common issues. SaRA is available at http://diagnostics.office.com.In every case, it's best to spend some time understanding what the user is actually experiencing. Understanding the full client experience and effect can help determine the logging and troubleshooting path. When you define the users issue, you should also run the Microsoft Office Configuration Analyzer Tool (OffCAT) on the client to have a good view of configuration that can impact their experience.
Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\ Value name: KeepAliveTime Value Type: 1800000 (30 minutes, in milliseconds) (Decimal)
Clients > Firewall > Load Balancer > CASIn this example, if you have a firewall in the path from client to CAS, we are referencing the firewall “idle” time out and not the persistence time out. This value should be greater than the load balancer and the load balancer time out should be greater than CAS. Note that it is not recommended to go below 15 minutes for Keep Alive on CAS or TCP idle timeout on the load balancer.
Firewall time out = 40 minutes LB TCP Idle time out = 35 minutes CAS Keep Alive = 30 minutes2. If the load balancer supports it, the preferred option is to configure it to use “Least Connections” with “Slow start” during typical operation. With the “least connections” method, be mindful it is possible for a CAS to become overloaded and unresponsive during a CAS outage or during patching/maintenance. In the context of Exchange performance, authentication is an expensive operation. The TechNet article Exchange 2013 Sizing and Configuration Recommendations describes the differences as:
A hardware or software load balancer should be used to manage all inbound traffic to Client Access servers. The selection of the target server can be determined with methods such as “round-robin,” in which each inbound connection goes to the next target server in a circular list, or with “least connections,” in which the load balancer sends each new connection to the server that has the fewest established connections at that time. These methods are detailed further in the following blog Load Balancing in Exchange 2013 and TechNet Load balancing.3. For ActiveSync persistence setting, set the load balancer to use “Authorization header cookie" to avoid one CAS becoming overloaded because source IP will send all the connections to one server as per this.
Expected values are“CDG 1 7 7 1 0 1 1 7 1” as shown in the following table. For testing, a DC can be excluded by using the Set-Exchangeserver –StaticExcludedDomainControllers parameter as shown in this section, however, troubleshooting Global Catalog access should also be done as soon as your testing is completed. Statically excluding a GC takes effect immediately and will be viewable on the next 2080 Event ID with all zero values. Some additional resources on the subject:
Example: Enable-OutlookAnywhere -Server 'ConE10' -ExternalHostname Mail.Contoso.com' -ClientAuthenticationMethod 'Ntlm' -SSLOffloading $false –IISAuthenticationMethod Basic, NTLM
To set the SCP for AutoDiscover (example): Set-ClientAccessServer ConE10 -AutoDiscoverServiceInternalUri https://Mail.Contoso.com/autodiscover/autodiscover.xml
Example: Get-ClientAccessServer |fl *uri* AutoDiscoverServiceInternalUri : https://Mail.Contoso.com/autodiscover/autodiscover.xml
In Exchange 2013, there are several logs in the logging folder. For Outlook clients one of the first logs to examine are the HTTP Proxy logs on CAS. The connection walk-through section shows the process that is used to connect to Exchange 2013. This complete process is logged in the HTTP Proxy log. Also, if it is possible, add Hosts file to the client for one specific CAS to reduce the number of logs. The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\RpcHttpHTTP Proxy AutoDiscover Logs
Exchange 2013 has HTTP Proxy logs for AutoDiscover that are similar to the logs shown earlier that can be used to determine whether AutoDiscover is failing. The logs on CAS are located here by default: C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\AutoDiscoverHTTP Error Logs
HTTP Error logs are failures that occur with HTTP.SYS before hitting IIS. However, not all errors for connections to web sites and app pools are seen in the httperr log. For example, if ASP.NET threw the error it may not be logged in the HTTP Error log. By default, HTTP error logs are located in C:\Windows\System32\LogFiles\HTTPERR. Information on the httperr log and codes can be found here.IIS Logs
IIS logs can be used to review the connection for RPC/HTTP, MAPI/HTTP, EWS, OAB, and AutoDiscover. The full data for the MAPI/HTTP and RPC/HTTP is not always put in the IIS logs. Therefore, there is a possibility that the 200 connection successful may not be seen. IIS codes. In Exchange 2013 IIS logs on the CAS should contain all user connections on port 443. IIS logs on the Mailbox server should only contain connections from the CAS server on port 444. Most HTTP connections are first sent anonymously which results in a 401 challenge response. This response includes the authentication types available in the response header. The client should then try to connect again by using one of these authentication methods. Therefore, a 401 status found inside an IIS log does not necessarily indicate an error. Note that an anonymous request is expected to show a 401 response. You can identify anonymous requests because the domain\username is not listed in the request.RPC Client Access (RCA) Logs
The RCA logs can be used to find when a user has made a connection to their mailbox, or a connection to an alternate mailbox, errors that occur with the connection, and more information. RCA logs are located in the logging directory which is located at %ExchangeInstallPath%\Logging\RpcClientAccess. By default, these logs have a maximum size of 10MB and roll over when size limit is reached or at the end of the day (based on GMT), and the server keeps 1GB in the log directory.Outlook ETL Logging (requires a support case with Microsoft to analyze the log) ETL logs are located in %temp%/Outlook Logging and are named Outlook-#####.ETL. The numbers are randomly generated by the system. To enable Outlook logging In the Outlook interface:
You can use Perfmon for issues that you suspect are caused by performance. http://experfwiz.codeplex.com/ Exchange 2013 has daily performance logs that captures the majority of what is needed. These logs are by default located in C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogsLog Parser Studio
Log Parser Studio is a GUI for Log Parser 2.2. LPS greatly reduces complexity when parsing logs. Additionally, it can parse many kinds of logs including IIS Logs, HTTPErr Logs, Event Logs (both live and EVT/EVTX/CSV), all Exchange protocol logs from 2003-2013, any text based logs, CSV logs and ExTRA traces that were converted to CSV logs. LPS can parse many GB of logs concurrently (we have tested with total log sizes of >60GB). Blog with tips/how to about LPS: http://blogs.technet.com/b/karywa/Exmon tool (aka Microsoft Exchange Server User Monitor)
We use this tool to get detailed information about client traffic.Hopefully this is helpful; we expect that we will make some updates to this checklist as time goes on! Thanks to Brendon Lee, Marc Nivens, Nasir Ali, Louise Budrow and The Exchange Performance V-Team for technical review. Charlene Weber
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.