It’s 4:55 p.m. on Friday and just as you pack up your stuff and get ready to leave the office, the phone rings. You answer the call and find out that users are having trouble connecting to their mailboxes through Outlook Anywhere. What do you do? And how do you prevent this problem from recurring? In this last article of my five-part series on the Exchange Server Client Access role, I discuss Client Access server administration, including what you need to monitor on a regular basis to help ensure that your Client Access servers are operating at optimal health and what to do when things go wrong. (For earlier articles in the series, see the Learning Path.)
Your Client Access servers only make up a slice of your Exchange Server 2010 infrastructure. Other Exchange server roles require an equal or greater amount of attention on a regular basis, and each role has its own focus for administration. Because the primary responsibility of the Client Access role is to facilitate connectivity for your messaging clients, it should come as no surprise that your focus in administering this role is to ensure that your clients can successfully connect to your Exchange organization and access their mail. The administration of the Client Access role can be summed up in three basic tasks:
- Managing Client Access role settings
- Monitoring servers’ performance and diagnostics
- Troubleshooting problems that arise
Managing the Role Settings
Even after your Client Access servers are up and running, you’ll likely need to adjust their configuration periodically. The Client Access role has multiple settings that you can manage; the most common ones are exposed through Exchange Management Console (EMC). For less common settings, you need to use Exchange Management Shell (EMS), either remotely or from an Exchange server.
Figure 1: Installing Exchange Management Tools
You can remotely manage your Client Access servers in one of two ways. The first method is to install Exchange Management Tools on your workstation. Installing these tools gives you the same functionality that you’d have if you were logged on to the Client Access server directly. However, these tools have some restrictions—perhaps the biggest of which is that they can be installed only on 64-bit workstations. If your administrators are running 32-bit Windows clients or Windows XP, this remote management strategy won’t work. However, if you’re running a 64-bit client OS on Windows Vista SP2 or later or a 64-bit server OS on Windows Server 2008 R2 or Windows Server 2008 SP2, then you can install Exchange Management Tools. To install the tools, run setup.exe from the Exchange installation media, perform a custom install, and select Exchange Management Tools, as Figure 1 shows.
Alternatively, you can use an unattended installation method to install the tools. Enter the following command:
setup.com /role:ManagementTools
The second option is to use remote PowerShell. Exchange 2010’s remote PowerShell capability lets you connect remotely from any workstation that has PowerShell 2.0 and Windows Remote Management (WinRM) 2.0 installed. You can then remotely run EMS commands on your Client Access servers. One of the advantages of using this approach is that you can manage your Client Access servers from a 32-bit client. The range of supported Windows client versions is also broader with this method because remote PowerShell can be used on OSs as old as XP and even Windows Embedded. Both PowerShell 2.0 and WinRM 2.0 are available in the Windows Management Framework Core package that you can download. Windows Management Framework Core can be installed on either 32-bit or 64-bit client OSs that are running XP SP3, Windows Vista SP1, or later.
After you install Windows Management Framework Core, you can use PowerShell 2.0 to establish a remote connection to your Client Access servers through the remote PowerShell virtual directory. When you connect with PowerShell remotely, your client loads the cmdlets that your account has access to and lets you run them from your workstation. These cmdlets actually run on the Client Access server in the back end, but it appears as if they’re running from your workstation. Assuming that you’re logged on to a computer in the domain and that you have SSL enabled on your PowerShell virtual directory, you can use the following commands from the PowerShell console on your workstation to connect remotely:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://contoso-ex01.contoso.com/PowerShell/ -Authentication NegotiateWithImplicitCredential Import-PSSession $Session
Monitoring Performance and Diagnostics
When monitoring your Client Access servers, you want to make the process as automated as possible. Having to log on and manually check the state of servers is time consuming and unnecessary. Several monitoring products are available, including Microsoft System Center Operations Manager and Quest Software’s Spotlight on Messaging. If you want to monitor your Client Access servers without third-party software, you can use Windows’s built-in tools—but you must be disciplined enough to be proactive about monitoring. You need to keep an eye on several things as you monitor your Client Access server infrastructure.
Exchange administrators often jump straight into advanced diagnostic or troubleshooting tools when a problem arises. However, you should monitor your Client Access servers’ Windows event logs because these logs can act as an early alert system that something is wrong. Exchange writes events to the application log. You should also monitor the system logs for warnings and errors that pertain to the underlying OS. Sometimes the error is with Windows Server rather than Exchange. In particular, you want to keep an eye out for events that pertain to the Client Access protocols, Autodiscover, and the address book. When issues exist on servers hosting the Client Access role, these are the common problems areas. Anything IIS related can affect access for clients over Outlook Web App (OWA), Exchange ActiveSync, Exchange Web Service, and Outlook Anywhere, so it’s important to keep IIS healthy. RPC Client Access errors don’t manifest themselves through IIS, so you should deal with error events that have MSExchange as the event source as soon as possible.
Another thing you need to monitor is your Client Access servers’ performance. You should collect information about hardware and services to ensure that they’re operating within healthy thresholds. You can use the Performance Monitor tool, perfmon.exe, to collect this information. Performance Monitor uses counters that Exchange Server makes available.
Table 1: Important Hardware Performance Counters
You’ll want to monitor aspects of the hardware performance, as well as Client Access server service endpoints. Table 1 identifies a few key counters to consider when monitoring hardware performance. Table 2 outlines the performance counter objects that are associated with Client Access server service endpoints.
Table 2: Performance Counter Objects for Client Access Server Service Endpoints
Each Client Access server service endpoint has unique needs, so one performance threshold won’t apply to all services. For example, latency has a higher threshold in ActiveSync monitoring than in RPC Client Access monitoring. Table 3 outlines some important performance counters to monitor for these services and virtual directories.
Table 3: Performance Counters for Client Access Server Service Endpoints
Troubleshooting Client Connectivity
Because the Client Access role’s main functionality is to provide client connectivity, the majority of the problems you encounter with the Client Access server are related to clients not connecting as expected. When you experience client connectivity failures, you should attempt to isolate the problem and determine whether the problem is really with the Client Access server or if it could be on the client’s end.
Remote connectivity testing. One of the easiest ways to test connectivity is to use the Exchange Remote Connectivity Analyzer, found at www.testexchangeconnectivity.com. This online connectivity test tool, which Figure 2 shows, is maintained by Microsoft and can help determine whether a problem is with the client’s connection or with the Exchange server.
Figure 2: Exchange Remote Connectivity Analyzer
Connectivity test cmdlets. Exchange includes several cmdlets that you can use to test various aspects of the Client Access server for connectivity problems. Table 4 lists these cmdlets and explains what each of them does.
Table 4: Connectivity Test Cmdlets
The connectivity test cmdlets use a preconfigured mailbox to run tests against various virtual directories on the Client Access server. Before you can run the tests, you must generate the account for the cmdlets to use. To generate this account, you use the PowerShell script called New-TestCasConnectivityUser.ps1. You can find this script in the Scripts folder of your Exchange installation path, which by default is C:\Program Files\Microsoft\Exchange Server\V14\Scripts. You can run the script without any parameters, or you can specify the organizational unit (OU) for the account and its Unified Messaging settings. When you create the account, you’re prompted for a one-time password. You never need to know this password again because Exchange manages it after the account is created and because it’s changed on a regular basis.
Diagnostic logging. To troubleshoot at a level deeper, you can turn on diagnostic logging for several Client Access server components. Exchange 2010 provides an interface to use in EMC. You can access the diagnostic logging interface for Client Access servers by selecting Server Configuration, Client Access. Choose the Client Access server that you want to enable logging on and select Manage Diagnostic Logging Properties from the Actions pane. The logs generated from the diagnostic logging process are written to the Application log in the Windows event logs.
Protocol logs. The RPC Client Access, Address Book, IMAP4, and POP3 services all offer the ability to turn on protocol logging. Protocol logging lets you see the conversation between the client that’s trying to connect and the Client Access server that’s responding. These logs are stored as comma-separated files that can be opened in any text editor. Some of the information in the protocol logs is common across all the services, and some of the information is unique to the service you’re logging. Figure 3 shows the protocol logs for the RPC Client Access service. Note that this log contains some valuable information that’s specific to RPC Client Access troubleshooting, such as the client software (outlook.exe), the version (12.0.4518.1014), and even which mode it’s running in (cached).
Figure 3: Protocol logs for the RPC Client Access service
Protocol logging is enabled on these services either through the service’s configuration file or through EMS. The default location for the logs is C:\Program Files\Microsoft\Exchange Server\V14\Logging. Table 5 describes how to enable the protocol logs.
Table 5: Enabling Protocol Logging for the Client Access Server Services
For client protocols that use IIS (OWA, Exchange Control Panel, Exchange ActiveSync, Exchange Web Service, Autodiscover, Outlook Anywhere, and remote PowerShell), you can use the IIS logs to gather similar log information. By default, these logs are in the folder C:\inetpub\logs\LogFiles. Logging in IIS is enabled by default, so no additional configuration is necessary to use these logs.
Go Forth and Administer
Client Access servers comprise only a single piece of your overall Exchange infrastructure—a lot of the focus in Exchange administration leans toward data administration on mailbox servers. Administering Client Access servers doesn’t require a lot of time or attention, but you can spend a lot of time troubleshooting if something goes wrong. To prevent little problems from turning into large outages, you should proactively monitor and troubleshoot your Client Access servers.
In this series I walked you through various aspects of the Client Access server role in Exchange 2010 to help you better understand what it does and how to work with it. The information I provided in the series will help you effectively deploy and manage a common Client Access server implementation.