Vous êtes sur la page 1sur 148

Module 3: The Client Access Server

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, email addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. These materials are intended for distribution to and use only by Microsoft Premier Customers. Use or distribution of these materials by any other persons is prohibited without the express written permission of Microsoft Corporation. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

2010 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Table of Contents
MODULE 3: THE CLIENT ACCESS SERVER..................................................................................................... 8
Introduction ................................................................................................................................................................ 8 Objectives .................................................................................................................................................................... 8

SECTION 1: OUTLOOK WEB APP ...................................................................................................................... 10


Introduction .............................................................................................................................................................. 10 Objectives .................................................................................................................................................................. 10

Overview of Outlook Web App ............................................................................................................. 11 Outlook Web App Features in Exchange Server 2010 SP1 ................................................................... 13 Coexistence of the Client Access Server with Outlook Web App .......................................................... 15 The Exchange2003URL Parameter....................................................................................................... 16 Tools for Managing Outlook Web App ................................................................................................ 17 Section 1 Review .................................................................................................................................. 18 SECTION 2: EXCHANGE ACTIVESYNC ................................................................................................................. 19
Introduction .............................................................................................................................................................. 19 Objectives .................................................................................................................................................................. 19

Exchange ActiveSync Features ............................................................................................................. 20


Improvements to Conversation View ...................................................................................................................... 21 Server-Side Information Rights Management Support .......................................................................................... 21

Exchange ActiveSync with Exchange Server 2003................................................................................ 23 Exchange ActiveSync with Exchange Server 2007................................................................................ 25 The Allow Block Quarantine Feature ................................................................................................... 27 The Allow Block Quarantine Configuration.......................................................................................... 28
Blocking Devices........................................................................................................................................................ 30 Quarantining Devices ............................................................................................................................................... 31

Mobile Device Discovery ...................................................................................................................... 33


Retrieving a High-Level View of Exchange ActiveSync Clients............................................................................... 34 Retrieving a Device List View ................................................................................................................................... 35 Viewing Device Statistics .......................................................................................................................................... 35

Troubleshooting Exchange ActiveSync................................................................................................. 37


The Start Logging Option .......................................................................................................................................... 38 Exchange ActiveSync Logging .................................................................................................................................. 39

Section 2 Review .................................................................................................................................. 41 SECTION 3: RPC CLIENT ACCESS SERVICE .......................................................................................................... 42


Introduction .............................................................................................................................................................. 42 Objectives .................................................................................................................................................................. 42

Overview of the RPC Client Access Service ........................................................................................... 43 RPC Encryption and Outlook ................................................................................................................ 44 Client Access Server Arrays and Network Load Balancing ................................................................... 45 Network Load Balancing Modes .......................................................................................................... 46
Unicast Mode ............................................................................................................................................................ 46

Multicast Mode ......................................................................................................................................................... 46 Best Practice .............................................................................................................................................................. 46

Network Load Balancing Configuration ............................................................................................... 48


Installing the Windows Server 2008 NLB Component ........................................................................................... 48 Creating the Client Access Server Array Host Record in DNS ................................................................................ 49 Creating the Client Access Server Array Object in AD DS ...................................................................................... 49 Creating a NLB Client Access Server Array .............................................................................................................. 49 Adding Additional Hosts to the Client Access Server Array ................................................................................... 51 Configuring Mailbox Databases ............................................................................................................................... 51

Mailbox Databases and the RPC Client Access Service ........................................................................ 52


Mailbox Databases in High Availability Environments ........................................................................................... 52 RPC Client Access and Outlook Behavior During Cross-Site Failover .................................................................... 52

Section 3 Review .................................................................................................................................. 54 SECTION 4: TROUBLESHOOTING RPC CLIENT ACCESS ........................................................................................... 55


Introduction .............................................................................................................................................................. 55 Objectives .................................................................................................................................................................. 55

RPC Client Access-Related Events ........................................................................................................ 56 RPC Client Access Protocol Logging ..................................................................................................... 63 Performance Counters ......................................................................................................................... 66 Testing Outlook Connectivity ............................................................................................................... 68 Lab 3A: Configuring RPC Client Access ................................................................................................. 71 Section 4 Review .................................................................................................................................. 72 SECTION 5: SCALABILITY AND PERFORMANCE ..................................................................................................... 73
Introduction .............................................................................................................................................................. 73 Objectives .................................................................................................................................................................. 73

Overview of Client Throttling ............................................................................................................... 74 Client Throttling Policies ...................................................................................................................... 75 Throttling Policy Settings ..................................................................................................................... 77 Throttling Policy Parameters ............................................................................................................... 78 Section 5 Review .................................................................................................................................. 80 SECTION 6: THE ADDRESS BOOK SERVICE .......................................................................................................... 81
Introduction .............................................................................................................................................................. 81 Objectives .................................................................................................................................................................. 81

Overview of the Address Book Service ................................................................................................. 82 Global Address List Selection ............................................................................................................... 84 Section 6 Review .................................................................................................................................. 85 SECTION 7: THE AUTODISCOVER SERVICE .......................................................................................................... 86
Introduction .............................................................................................................................................................. 86 Objectives .................................................................................................................................................................. 86

Locating the Autodiscover Service ....................................................................................................... 87 Autodiscover Service Types .................................................................................................................. 89 Using Client Access Server Arrays ........................................................................................................ 92 Autodiscover Site Scope for Client-Only Sites....................................................................................... 93

Troubleshooting the Autodiscover Service ........................................................................................... 94 Event Logging ...................................................................................................................................... 96 Performance Counters ....................................................................................................................... 102 Section 7 Review ................................................................................................................................ 104 SECTION 8: OUTLOOK ANYWHERE .................................................................................................................. 105
Introduction ............................................................................................................................................................105 Objectives ................................................................................................................................................................105

Overview of Outlook Anywhere ......................................................................................................... 106 Outlook Anywhere and the Client Access Server................................................................................ 107 Section 8 Review ................................................................................................................................ 108 SECTION 9: SECURE SOCKETS LAYER AND CERTIFICATES ...................................................................................... 109
Introduction ............................................................................................................................................................109 Objectives ................................................................................................................................................................109

Digital Certificates ............................................................................................................................. 110 Secure Sockets Layer Handshake ....................................................................................................... 111 Troubleshooting Certificates .............................................................................................................. 113 Lab 3B: Using the Certificate Wizard ................................................................................................. 117 Section 9 Review ................................................................................................................................ 118 SECTION 10: EXCHANGE WEB SERVICES .......................................................................................................... 119
Introduction ............................................................................................................................................................119 Objectives ................................................................................................................................................................119

The Availability Service ...................................................................................................................... 120 Availability Service Process Flow........................................................................................................ 122 Overview of MailTips ......................................................................................................................... 123
MailTips in Complex Topologies ............................................................................................................................124 Group Metrics .........................................................................................................................................................124 MailTips Limitations................................................................................................................................................124

MailTips Evaluation ........................................................................................................................... 125 MailTips Organizational Settings Configuration ................................................................................ 127 Troubleshooting MailTips .................................................................................................................. 129
Caches ......................................................................................................................................................................129 Problem Limited to Outlook Clients ...................................................................................................................... 129 Problem Limited to Only Some MailTips ...............................................................................................................129 Problem Limited to Group Metrics-Based MailTips .............................................................................................130

Enabling Outlook MailTips Logging ................................................................................................... 131 MailTips Log Files ............................................................................................................................... 132
GetServiceConfiguration Log File...........................................................................................................................132 GetMailTips Log File................................................................................................................................................135

Federated Sharing .............................................................................................................................. 138 Message Tracking .............................................................................................................................. 139


Microsoft Exchange Transport Log Search Service Indexing ...............................................................................139 Tracking Message Latency .....................................................................................................................................140

Troubleshooting Exchange Web Services........................................................................................... 141

Recreating the Exchange Web Services Virtual Directory .................................................................. 144


Backing Up and Restoring the IIS Configuration ...................................................................................................144 Removing and Recreating the Exchange Web Services Virtual Directory ..........................................................145

Lab 3C: Configuring and Testing MailTips in Exchange Server 2010.................................................. 146 Section 10 Review .............................................................................................................................. 147 Module 3 Summary............................................................................................................................ 148

Module 3: The Client Access Server

Introduction
The Client Access server role supports the Microsoft Outlook Web App and Exchange ActiveSync client applications, and the Post Office Protocol version 3 (POP3) and Internet Message Access Protocol version 4 (IMAP4) protocols. The Client Access server role also provides access to free/busy data by using the Availability Service and enables certain clients to download automatic configuration settings from the Autodiscover service. In Microsoft Exchange Server 2010, the Client Access server role includes a task that was not included in Exchange Server 2007. This task manages the processing from MAPI clients such as Microsoft Office Outlook. In Exchange Server 2007, Office Outlook clients connecting to an Exchange server from inside an organizations firewall connect directly to the Exchange Server 2007 Mailbox server. In Exchange Server 2010, that processing has been moved to the Exchange Server 2010 Client Access server. This module describes how to administer, operate, and troubleshoot the clients and services supported by the Client Access server. Additionally, this module describes troubleshooting for Certification Authority (CA) certificates, and for scalability and performance.

Objectives
After completing this module, you will be able to:

Manage Outlook Web App. Use the new Exchange ActiveSync features. Troubleshoot Exchange ActiveSync.

Understand the RPC Client Access Service feature. Configure network load balancing (NLB) for the Client Access server array. Enable mailbox databases to use the RPC Client Access service. Troubleshoot the RPC Client Access service. Describe the Address Book Service. Manage and troubleshoot the Autodiscover service. Configure Outlook Anywhere with the Client Access server array. Understand and troubleshoot digital certificates. Manage and troubleshoot Exchange Web Services.

Section 1: Outlook Web App

Introduction
Outlook Web App allows you to access your Exchange Server mailbox from almost any Web browser. This section describes Client Access server integration with Outlook Web App and the tools for managing Outlook Web App.

Objectives
After completing this section, you will be able to: Describe how the Client Access server integrates with Outlook Web App. Describe Outlook Web App features in Exchange Server 2010 Service Pack 1 (SP1). Use the Exchange2003URL parameter. Manage Outlook Web App.

Overview of Outlook Web App

Outlook Web App provides users with a single URL for accessing their mailboxes, regardless of the users mailbox versions. To access a mailbox: 1. Open a Web browser and access the URL that points to the Client Access server. For example: https://mail.contoso.com/owa. 2. Enter your credentials in the forms-based authentication dialog box. The Client Access server authenticates the user and accesses Active Directory Domain Services (AD DS) to retrieve the following information, depending on the user: Users mailbox version. Users mailbox location, if known. If the users mailbox resides in the same AD DS site as the Client Access server against which the user is authenticatingthat is, the mailbox is a local mailboxand this mailbox resides on Exchange Server 2007, then Exchange Server returns the external URL of the 2007 Client Access servers Outlook Web App virtual directory while ensuring that the authentication settings match those of the 2010 Client Access server. If the users mailbox is not local and the mailbox resides on Exchange Server 2007 or Exchange Server 2010, then Exchange Server returns the external URL of the 2007 or 2010 Client Access servers Outlook Web App virtual directory, if defined.

If the users mailbox is located on Exchange Server 2003, the Exchange2003URL parameter defined on the Client Access server's Outlook Web App virtual directory is returned and the user is automatically redirected to that URL.

The following scenarios occur for mailboxes that reside on an Exchange Server 2010 Mailbox server: If the mailbox is local, the Client Access server retrieves and renders the users mailbox data from the Mailbox server and provides the data view back to the user. If the mailbox is not local and an external URL is specified on the Client Access server on the target Active Directory site, the Client Access server prompts the user with a redirection page identifying the correct URL the user should be using. The user then clicks on the correct URLs link and enters the credentials into the formsbased authentication dialog box on the target (redirected) Client Access server. This Client Access server authenticates the user, retrieves and renders the users mailbox data from the Mailbox server, and provides the data view back to the user. If the mailbox is not local and an external URL is not specified on the Client Access server on the target Active Directory site, the Client Access server proxies the session to a Client Access server in the appropriate Active Directory site.

Outlook Web App Features in Exchange Server 2010 SP1

Outlook Web App in Exchange Server 2010 SP1 offers the following improvements and new features: Simplified user interface behavior and appearance for the conversation reading pane and the calendar view. Printable calendar view available in daily, weekly, monthly, and agenda views. New mail alerts. Themes. To select a theme, in Exchange Control Panel, click Options, click Settings, and then click Themes. Performance improvements. Pre-fetching causes some actionssuch as delete and moveto asynchronize. For performance monitoring, latency information about sent messages included in the Internet Information Services Manager (IIS) log. Better integration with Microsoft Office Communications Server 14, including instant messaging invite alerts and instant messaging chat alerts. In Unified Contact Store (UCS) mode, buddy lists and contact lists are installed on Exchange Server, not in Office Communications Server. This means that Exchange Server is the primary contact store for Office Communications clients. The Office Communications Server maintains a mirror image so that it can support legacy clients. This mirror can become outdated, and the Office Communications Server 14 client (or any UCS preferred endpoint) is responsible for updating it. Improved privacy awareness so that when privacy is turned on, only users in your buddy list will see your presence.

Business-to-business (B2B) solution storage improvements. Some B2B data is now stored in AD DS instead of the configuration files, which means that custom information cannot be lost. Added support for inline images and web parts. Monitoring enhancements

Coexistence of the Client Access Server with Outlook Web App

By default, installing the Client Access server role on a computer that is running Exchange Server 2010 enables Outlook Web App. You must install the Client Access server role in every Exchange Server-based organization and in each Active Directory site that has an installed Mailbox server role. The 2010 Client Access server does not support rendering mailbox data from legacy versions of Exchange Server. Depending on the target mailbox's version or location, the Client Access server does one of the following: If an Exchange Server 2007 mailbox is in the same Active Directory site as the 2010 Client Access server, the 2010 Client Access server silently redirects the session to a 2007 Client Access server. If an Exchange Server 2007 mailbox is in another Internet-facing Active Directory site, the 2010 Client Access server manually redirects the user to a 2007 Client Access server. If an Exchange Server 2007 mailbox is in a non-Internet-facing Active Directory site, the 2010 Client Access server proxies the connection to a 2007 Client Access server. For Exchange Server 2003 mailboxes, the 2010 Client Access server silently redirects the session to a predefined URL.

The Exchange2003URL Parameter

As described previously, the 2010 Client Access server silently redirects sessions to a predefined URL if the mailbox is an Exchange Server 2003 mailbox. This URL is defined by the Exchange2003URL parameter. The Exchange2003URL parameter is a property that appears in the 2010 Client Access server's Outlook Web App virtual directory. This means that it is not a global property; it is a property assigned on the basis of the Outlook Web App virtual directory. You set this property when interacting with Exchange Server 2003 because Exchange Server 2003 is not Active Directory site aware, and it does not have settings published in AD DSsuch as ExternalURLthat allow the Client Access server to determine the best front-end server to which a client should be redirected. For this reason, Exchange Server 2010 leverages the Exchange2003URL parameter on the Outlook Web App virtual directory.

Tools for Managing Outlook Web App

The following table lists the tools that you can use to configure and manage Outlook Web App in Exchange Server 2010.
Tool Exchange Management Console Exchange Management Shell and associated command-line plug-ins IIS Description Manages an Exchange Server 2010 organization. You can use the Exchange Management Console to manage the most common settings for Outlook Web App. Automates administrative tasks and management for many features that are not included in the Exchange Management Console. Manages user access to the Outlook Web App virtual directories. For example, this can help you simplify the URL and force users to use an HTTPS address. Allows you to configure specific Outlook Web App settings. You must configure some settingssuch as ConnectionCacheSize and MaxRequestLengthby modifying Web.config because these settings are specific to ASP.NET. Modify Web.config only by using tools such as Notepad. If you modify Web.config by using IIS, the file becomes corrupt. Allows you to configure specific Outlook Web App settings. You must configure some settingssuch as the PublicClientTimeout, TrustedClientTimeout, and SSLOffloadedby using Registry Editor. Caution: Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. You may not be able to resolve problems resulting from incorrectly editing the registry. Before editing the registry, back up any valuable data.

Web.config

Registry Editor

Section 1 Review

Answer the questions listed on the slide above.

Section 2: Exchange ActiveSync

Introduction
Exchange ActiveSync in Exchange Server 2010 enables users to synchronize their mobile phones with their Exchange Server mailboxes. They can synchronize email messages, calendar information, contact and task data, and also manage their Deleted Items folders, email signatures, and automatic-reply settings to let people know they are away. By default, Exchange ActiveSync is enabled when you install the Client Access server role on the computer that is running Exchange Server 2010. This section describes new features for Exchange ActiveSync, Exchange ActiveSync troubleshooting, and Exchange ActiveSync integration with Exchange Server 2003 and Exchange Server 2007.

Objectives
After completing this section, you will be able to: Describe the new Exchange ActiveSync features. Manage Exchange ActiveSync coexistence with Exchange Server 2003 and Exchange Server 2007. Use the Allow Block Quarantine feature. Use mobile device discovery. Troubleshoot Exchange ActiveSync.

Exchange ActiveSync Features

Exchange ActiveSync contains the following new features in Exchange Server 2010: Block/Allow/Quarantine list. You can setup a single list to block and allow mobile devices as needed. You can also quarantine devices such as new untested devices. Over the Air Update mode. You can push Windows Mobile updates to Windows Mobile 6.1 and above. This means you no longer have to wait for a new Windows Mobile operating system version to obtain a new version of Outlook Mobile. SMS Sync. The ability to send Short Message Service (SMS) text messages through Exchange Server and Exchange ActiveSync synchronizes SMS messages with users mobile devices. The benefits of SMS Sync include: Users can respond to messages with Outlook Web App, Outlook, and Outlook Mobile. SMS messages are backed up on the server. Recipients can respond to users messages. Users can switch window views while still seeing all their messages.

IMAP4/POP3 service discovery. You can autodiscover and autoconfigure the IMAP4/POP3 settings from your mobile device by specifying your email address.

In Exchange Server 2010 SP1, you can manage Exchange ActiveSync devices using the Exchange Control Panel. The My Organization container allows you to manage phone and voice devices. The available options are: Configure the access level automatically granted to all devices.

Configure email alerts that enable administrators to take action when a device is being quarantined. Personalize the message that is sent to users when their devices are being recognized or quarantined. Provide a list of all quarantined devices. Create and manage device access rules permitting administrators to allow, block, or quarantine specific devices. Allow or block a given device for a particular user.

Under the individual users mailbox properties, the administrator can: Enumerate the devices of a given user. Remote wipe devices. Remove old partnerships. Initiate the creation of a rule for all users of a particular device, and allow or block a given device for a particular user.

Additionally, improvements in SMS synchronization functionality allow you to choose which folder to use to save received SMS messages. The Exchange ActiveSync version 14.1 protocol allows you to perform SMS synchronization against any email folder, including the default Inbox, Outbox, Sent Items, and Drafts folders. To use this functionality, the clients devices must support the upgraded Exchange ActiveSync protocol.

Improvements to Conversation View


Conversation items include the following information: Conversation topic List of senders starting with the most recent one Unread message count in the conversation Timestamp of the most recent message in the conversation Follow-up flag and importance flag, if set Attachment icon, as needed

Exchange ActiveSync also synchronizes with mobile devices. The Exchange ActiveSync version 14.1 protocol allows you to retrieve only the difference between emails of a particular conversation. To use this functionality, the clients devices must support the upgraded Exchange ActiveSync protocol.

Server-Side Information Rights Management Support


Information Rights Management (IRM) for Exchange ActiveSync clients is controlled by Exchange ActiveSync policies. By default, IRM is enabled when you create a new Exchange ActiveSync policy. It is also enabled on the default Exchange ActiveSync

policy. Exchange Server now allows non-Windows mobile devices to decrypt protected emails. When the IRM property is enabled on an Exchange ActiveSync policy, IRM email is decrypted on the server and sent to the mobile device in a decrypted state with additional properties such as the restrictions and the template. When the IRM property is disabled, IRM email is not decrypted on the server and the email is sent to the mobile device as a traditional IRM message and rights-protected message (.rpmsg) attachment. Exchange ActiveSync devices connect to Exchange Server and advertise which features or policies they support. When the device advertises that it supports IRM and the users Exchange ActiveSync policy indicates that IRM is enabled for that user, any IRM email synchronized to the phone is decrypted and synchronized to the device. If the device advertises IRM support and the connection between the device and Exchange Server is not encrypted, Exchange Server treats the device as if it does not support IRM. This ensures that no IRM content is sent over a non-Secure Sockets Layer (SSL) or secure channel. To read IRM emails without requiring the client to retrieve certificates from the domain network, the clients devices must support the upgraded Exchange ActiveSync protocol.

Exchange ActiveSync with Exchange Server 2003

Users with Exchange Server 2003 mailboxes who try to use Exchange ActiveSync through a 2010 Client Access server receive an error and are unable to synchronize unless they enable Integrated Windows authentication on the Microsoft-Server-ActiveSync virtual directory in Exchange Server 2003. This allows the 2010 Client Access server and the 2003 back-end server to communicate using Kerberos authentication. To enable authentication on Exchange Server 2003, do one of the following: Install http://support.microsoft.com/?kbid=937031, and then use the Exchange System Manager to adjust the authentication settings of the Exchange ActiveSync virtual directory. Set the msExchAuthenticationFlags attribute to a value of 6 on the Microsoft-ServerActiveSync object within the configuration container on each 2003 Mailbox server. You can find a sample script at http://technet.microsoft.com/enus/library/cc785437.aspx.
Note: Do not use IIS to change the authentication setting on the Exchange ActiveSync virtual directory. Doing so causes the DS2MB process within the System Attendant to overwrite the settings that are stored in AD DS.

Exchange Server 2003 (and Exchange Server 2007) end users will see the legacy domain namespacefor example, legacy.contoso.comin their browser address bars, Exchange ActiveSync settings, and Test Auto-Configuration output within Outlook. They continue to use the legacy domain namespace as their access point into the organization for messaging services. Administrators should direct customers to use the legacy domain namespace for all external connectivity mechanisms.

Note: The legacy domain namespace must be specified in the External URL setting on Outlook Web App and the Exchange ActiveSync virtual directory of an Exchange Server 2007 Internet-facing Client Access server, or in the Exchange2003URL parameter on an Exchange Server 2010 Internet-facing Client Access server.

Exchange ActiveSync with Exchange Server 2007

To introduce Exchange Server 2010 into your Internet-facing Active Directory site while still supporting your Exchange Server 2007 mailboxes, do the following: Move the primary Exchange ActiveSync namespace associated with the 2007 Client Access server array to the 2010 Client Access server array. Create a new namespace for legacy access and associate it with your 2007 Client Access server array.

Additionally, for the 2007 Client Access server within the Internet-facing Active Directory site, configure the Exchange ActiveSync ExternalURL parameter to use the legacy namespace so that Exchange ActiveSync can redirect devices that support Autodiscover. The cmdlet is:
Set-ActiveSyncVirtualDirectory <CAS2007>\Microsoft-Server-ActiveSync* -ExternalURL https://legacy.contoso.com/Microsoft-Server-ActiveSync

On the 2010 Client Access server, set the ExternalURL parameter to your primary mail namespace. The cmdlet is:
Set-ActiveSyncVirtualDirectory <CAS2010>\Microsoft-Server-ActiveSync* -ExternalURL https://mail.contoso.com/Microsoft-Server-ActiveSync

Unlike Exchange Server 2003, Exchange Server 2007 does not require authentication changes. For Exchange ActiveSync proxy communication to work between the 2007 Client Access server in the Internet-facing Active Directory site and the 2007 Client Access server in

the non-Internet-facing site, you must enable Integrated Windows authentication on the Exchange ActiveSync virtual directories on the non-Internet facing site. With Exchange Server 2007 Service Pack 2 (SP2) and Exchange Server 2010, setup creates a subdirectory named proxy under the Microsoft-Server-ActiveSync virtual directory. This proxy virtual directory is enabled for Integrated Windows authentication. When the 2010 Client Access server has to proxy Exchange ActiveSync traffic to a 2007 or 2010 Client Access server, it uses the Microsoft-Server-ActiveSync\proxy virtual directory for the proxy traffic.
Note: Exchange ActiveSync proxying between 2007 Client Access servers still requires Integrated Windows authentication to be set on the Exchange ActiveSync virtual directory.

The Allow Block Quarantine Feature

Because Exchange ActiveSync is an open protocol, Exchange ActiveSync client developers can build devices with any set of limitations or functionality. These devices may not comply with recommended security policies. This openness makes it difficult for administrators to control access to their networks without using another product such as Microsoft System Center Mobile Device Manager 2008. The Allow Block Quarantine feature limits network access based on the makes and models of mobile devices. Administrators can toggle an organization-wide switch that can: Allow all devices to synchronize with the server, except for: Devices assigned to users block lists. Device models or device type groups that are explicitly blocked or quarantined.

Block all devices from retrieving information from the server, except for: Devices assigned to users allow lists, and Device models or device type groups that are explicitly allowed or quarantined.

Quarantine new devices so that administrators can grant or block access by adding: Devices on an individual basis to a users allow or block list The model or device type groups to the organization-wide list as blocked or allowed.

By default, Exchange Server allows devices to sync with the server.

The Allow Block Quarantine Configuration

Once a device model is allowed, any user using that device can synchronize with Exchange Server. Similarly, if a model is blocked, all such devices found on the network are unable synchronize with Exchange Server. Unfortunately, not all devices tell the server what kind of devices they are. For an unknown device, the Allow Block Quarantine feature returns the user agent string, along with other pertinent information, which may help administrators determine the device model. The following cmdlets configure the Allow Block Quarantine feature: Set-ActiveSyncOrganizationSettings toggles the global setting for all devices that are not affected by organization-wide rules, and are not assigned to individuals or blocked on an individual basis. New-ActiveSyncDeviceAccessRule creates device rules based on the device models or DeviceTypes, which should map to wider classes of devices. Get-ActiveSyncDeviceAccessRule Set-ActiveSyncDeviceAccessRule Remove-ActiveSyncDeviceAccessRule

You can set the rules to: Allow certain devices while blocking the rest. Block certain devices while allowing the rest. Quarantine all unknown devices until a decision is made about them. Create rules for new kinds of devices that appear.

For maximum security, use the global quarantine flag, and then assign devices individually with the following cmdlet:
Set-CasMailbox <user> -ActiveSyncAllowedDeviceIDs <DeviceID>

When you quarantine a device, each user specified with the SetActiveSyncOrganizationSettings cmdlet receives a message indicating that a device is quarantined and an action is required. Users are notified as their devices pass through the various stages of the system. The device discovery stage occurs over a short period of timeup to 60 minutesand it is an automated quarantine period that Exchange Server uses to identify devices. This period is smallest on the newest devices that use the latest protocol versions. Users do not receive status messages during this time period. The default configuration when viewing Get-ActiveSyncOrganizationSettings is:
RunspaceId : 82fa3f21-ecc1-4627-be4f-43e87a7e1257 DefaultAccessLevel : Allow UserMailInsert : AdminMailRecipients : {} Name : Mobile Mailbox Settings OtherWellKnownObjects : {} AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) DistinguishedName : CN=Mobile Mailbox Settings,CN=CONTOSO,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com Identity : Mobile Mailbox Settings Guid : 9d5799bd-6253-41a4-8059-118c684e5a5f ObjectCategory : Contoso.com/Configuration/Schema/ms-Exch-Mobile-MailboxSettings ObjectClass : {top, msExchMobileMailboxSettings} OrganizationId : OriginatingServer : DC.Contoso.com IsValid : True

By default, theAdminMailRecipients parameter is $null, which may be a problem if a block or quarantine is enabled prior to configuring AdminMailRecipients. The mobile devices will still behave according to the block or quarantine rules, but users will not be notified. The syntax for the Get-ActiveSyncOrganizationSettings cmdlet is:
Get-ActiveSyncOrganizationSettings [-Identity <ActiveSyncOrganizationSettingsIdParameter>] [-DomainController <Fqdn>] [-Organization <OrganizationIdParameter>]

The syntax for the New-ActiveSyncDeviceAccessRule cmdlet is:


New-ActiveSyncDeviceAccessRule -AccessLevel <Allow | Block | Quarantine> -Characteristic <DeviceType | DeviceModel> -QueryString <String> [-Confirm [<SwitchParameter>]] [-DomainController <Fqdn>] [-Organization <OrganizationIdParameter>] [-WhatIf [<SwitchParameter>]]

You can create multiple device groups such as allowed devices, blocked devices, and quarantined devices. Example The following cmdlet creates a device access rule that allows SmartPhone devices.
New-ActiveSyncDeviceAccessRule -QueryString SmartPhone -Characteristic DeviceModel -AccessLevel Allow

Blocking Devices
The following cmdlet blocks a device:
Set-ActiveSyncOrganizationSettings DefaultAccessLevel Block

The emulator test client fails with an error message that tells the user that the configuration on the Exchange server prevents synchronization. If you immediately change the DefaultAccessLevel parameter back to Allow, then emulator synchronization works properly without resetting IIS or taking other corrective actions. When blocked, the IIS log on the Client Access server displays the following error:
2009-09-11 18:22:43 65.53.13.193 POST /Microsoft-Server-ActiveSync/default.eas Cmd=GetItemEstimate&DeviceId=BAD73E6E02156460E800185977C03182&DeviceType=PocketPC& Log=V140_LdapC24_LdapL77_RpcC17_RpcL46_S129_Error:DeviceIsBlockedForThisUser_As:Bl ockedG_Budget:(A)Conn%3a0%2cAD%3a%24null%2f%24null%2f0%25%2cCAS%3a%24null%2f%24nul l%2f2%25%2cAB%3a%24null%2f%24null%2f0%25%2cRPC%3a%24null%2f%24null%2f0%25%2cFC%3a% 24null%2f0%2cHash%3a37689768_&Translated=T 80 contoso.com\fred 65.53.12.95 - 200 0 0 4782

Note: There are no administrative events logged on the server when this synchronization failure occurs.

When blocked, the device owner receives an email notification such as the following:
From: Microsoft Outlook Sent: Friday, September 11, 2009 2:08 PM To: Fred Flintstone Subject: Your mobile phone has been denied access to the server via Exchange ActiveSync because of server policies. Your phone won't be able to synchronize with the server via Exchange ActiveSync because of an access policy defined on the server. Information about your mobile phone: Device model: Microsoft DeviceEmulator Device type: PocketPC Device ID: BAD73E6E02156460E800185977C03182 Device OS: Windows CE 5.2.21741 Device user agent: MSFT-PPC/5.2.5024 Device IMEI: 000 Exchange ActiveSync version: 14.0 Device access state: Blocked Device access state reason: Global

Sent at 9/11/2009 11:08:38 AM to Fred@contoso.com.

The device owner must follow up with the Exchange Server administrator for corrective action to allow device synchronization. Example The following cmdlet creates a device access rule that blocks PocketPC devices.
New-ActiveSyncDeviceAccessRule -QueryString PocketPC -Characteristic DeviceModel -AccessLevel Block

Quarantining Devices
The following cmdlet quarantines a device:
Set-ActiveSyncOrganizationSettings DefaultAccessLevel Quarantine

Testing with a mobile device emulator that had previously completed a successful synchronization prompts the user with a warning message to approve a resynchronization. After clicking Yes in the Warning Message dialog box, all Exchange Server data is wiped from the device, pending administrative approval. The synchronization fails with an error (0x80883002) that states that the device will be resynchronized during the next synchronization. The warning message does not appear for new devices that have not previously completed a successful synchronization with the server. Instead, the user simply receives the synchronization error. During quarantine, the administrator receives an email notification similar to:
From: Microsoft Outlook Sent: Friday, September 11, 2009 2:54 PM To: Administrator Subject: The mobile phone that belongs to contoso \fred has been quarantined. Synchronization with the server via Exchange ActiveSync is blocked until you take action. The Exchange ActiveSync service has quarantined the mobile phone listed below. It won't be able to synchronize Exchange content until you take action. If you want to assign the phone to its user, or block it for that user, please use

After the administrator resolves the quarantined (or blocked) status, the next device synchronization generates the following email notification to the device owner:
From: Microsoft Outlook Sent: Friday, September 11, 2009 3:44 PM To: Fred Flintstone Subject: Your mobile phone has been granted full access to the server via Exchange ActiveSync. Your phone has been granted full access to synchronize with the server via Exchange ActiveSync. Information about your mobile phone: Device model: PocketPC Device type: PocketPC

Device ID: BAD73E6E02156460E800185977C03182 Device OS: Device user agent: Device IMEI: Exchange ActiveSync version: 14.0 Device access state: Allowed Device access state reason: Global Sent at 9/11/2009 12:44:39 PM to Fred@contoso.com.

Note: The DeviceAccessStateReason: Global line confirms that a global configuration was responsible for the quarantine.

Mobile Device Discovery

You can easily discover which mobile devices are active in your organization by executing the Get-ActiveSyncDevice cmdlet. The syntax is:
Get-ActiveSyncDevice [-Identity <ActiveSyncDeviceIdParameter>] [-DomainController <Fqdn>] [-Filter <String>] [-Organization <OrganizationIdParameter>] [-OrganizationalUnit <OrganizationalUnitIdParameter>] [-ResultSize <Unlimited>] [-SortBy <String>]

Get-ActiveSyncDevice -Mailbox <MailboxIdParameter> [-DomainController <Fqdn>] [-Filter <String>] [-Organization <OrganizationIdParameter>] [-OrganizationalUnit <OrganizationalUnitIdParameter>] [-ResultSize <Unlimited>] [-SortBy <String>]

Example 1 The following cmdlet returns all of the Exchange ActiveSync devices that Tony Smith has used that are associated with his mailbox.
Get-ActiveSyncDevice -Identity "TonySmith"

Example 2 The following cmdlet also returns all of the Exchange ActiveSync devices that Tony Smith has used that are associated with his mailbox.
Get-ActiveSyncDevice -Mailbox "contoso\TonySmith"

Here is an example of the default Get-ActivesyncDevice output:

RunspaceId : 82fa3f21-ecc1-4627-be4f-43e87a7e1257 FriendlyName : Pocket_PC DeviceId : BAD73E6E02156460E800185977C03182 DeviceImei : 000 DeviceMobileOperator : Fake Network DeviceOS : Windows CE 5.2.21741 DeviceOSLanguage : English DeviceTelephoneNumber : ********0001 DeviceType : PocketPC DeviceUserAgent : MSFT-PPC/5.2.5024 DeviceModel : Microsoft DeviceEmulator FirstSyncTime : 9/10/2009 11:19:36 AM UserDisplayName : Contoso.com/Users/<username> DeviceAccessState : Allowed DeviceAccessStateReason : Global DeviceAccessControlRule : DeviceActiveSyncVersion : 14.0 AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) Name : PocketPCBAD73E6E02156460E800185977C03182 DistinguishedName : CN=PocketPCBAD73E6E02156460E800185977C03182, CN=ExchangeActiveSyncDevices,CN=<username>,CN=Users,DC=Contoso,DC=com Identity : Contoso.com/Users/<username> /ExchangeActiveSyncDevices/PocketPCBAD73E6E02156460E800185977C03182 Guid : 82b24e84-b3fe-4aeb-9d40-9d8a03621f3c ObjectCategory : Contoso.com/Configuration/Schema/ms-Exch-Active-SyncDevice ObjectClass : {top, msExchActiveSyncDevice} OriginatingServer : DC.Contoso.com IsValid : True

The data shown above represents a user connection from a Windows Mobile 6.1 emulator. The output contains more data than Outlook Web App provides in its View Mobile Phone Details window.

Retrieving a High-Level View of Exchange ActiveSync Clients


Although device synchronization state files are stored in each users mailbox, you cannot easily gather the data from the mailboxes to retrieve a simple count of all the devices that use Exchange ActiveSync. Instead, use AD DS to track the devices that are or have retrieved data from Exchange Server. View the device entries under the CN=ExchangeActiveSyncDevices node found under the AD Users node. This data is utilized by the Get-ActiveSyncDevice cmdlet. To extract a list of device models that are retrieving information from Exchange Server, pipe the output of the Get-ActiveSyncDevice into a group-object task. For example, the following cmdlet lists the clients that use Exchange ActiveSync:
Get-ActiveSyncDevice | group-object -property DeviceModel noelement

The sample output is:


Count ----169 Name ---PocketPC

4 552 54

HERM200 SGH-i780 HTC Touch Diamond P3700

The output does not provide details about the blocked, allowed, or quarantined status of the devices.

Retrieving a Device List View


You can use the Get-ActiveSyncDevice cmdlet to list all devices that have synchronized with the server. The cmdlet returns all devices with an Active Directory entry. Depending on your purpose, you may want to filter the list. Specifying the Get-ActiveSyncDevice cmdlet with the Filter parameter returns a list of devices based on the specified filtering characteristics. Example 1 The following example returns a list of all the devices whose model is HERM200:
get-ActivesyncDevice -Filter: {DeviceModel -eq 'HERM200}

Example 2 The following example returns a list of all the devices that have a model starting with HERM in their names:
get-ActivesyncDevice -Filter: {DeviceModel -like 'HERM*} to get all devices

Example 3 The following example returns a list of all devices whose user agents start with MSFT:
get-ActivesyncDevice -Filter: {UserAgent -like 'MSFT*'} to get

Example 4 The following example returns a list of all devices that report as connecting to a Mobile Operator and that have a name starting with the letter T:
get-ActivesyncDevice -Filter: {OperatorNetwork -like 'T*} to get all

Viewing Device Statistics


Devices that are in device discovery mode or quarantined may receive an HTTP 403 error if they try to add content to the server. The user may need to initiate synchronization manually to exit that state. While some administrators may know which devices they want to allow or block, others may need to discover the devices that are attached to their mailboxes and decide based on the limited information that the device shares with the server. Administrators with doubts about a particular device model can list all such devices found in the organization by

using the Get-ActiveSyncDevice cmdlet. Then, using the Get-ActiveSyncDeviceStatistics cmdlet, they can retrieve mailbox details about any or all listed devices. The Get-ActiveSyncDeviceStatistics -Mailbox <username> cmdlet returns statistical information about a users devices. In the following example, the Pocket PC device was quarantined.
RunspaceId : d66ad292-6157-4302-bca0-40f21a71db4d FirstSyncTime : 9/10/2009 6:19:36 PM LastPolicyUpdateTime : 9/11/2009 7:20:28 PM LastSyncAttemptTime : 9/11/2009 7:25:56 PM LastSuccessSync : 9/11/2009 7:25:56 PM DeviceType : PocketPC DeviceID : BAD73E6E02156460E800185977C03182 DeviceUserAgent : DeviceWipeSentTime : DeviceWipeRequestTime : DeviceWipeAckTime : LastPingHeartbeat : RecoveryPassword : ******** DeviceModel : PocketPC DeviceImei : DeviceFriendlyName : DeviceOS : DeviceOSLanguage : DevicePhoneNumber : MailboxLogReport : DeviceEnableOutboundSMS : False DeviceMobileOperator : Identity :Contoso.com/Users/FredFlintstone/ExchangeActiveSync Devices/ PocketPCBAD73E6E02156460E800185977C03182Guid : 82b24e84b3fe-4aeb-9d40-9d8a03621f3c IsRemoteWipeSupported : True Status : DeviceOk StatusNote : DeviceAccessState : Quarantined DeviceAccessStateReason : Global DeviceAccessControlRule : DevicePolicyApplied : Default DevicePolicyApplicationStatus : PartiallyApplied LastDeviceWipeRequestor : DeviceActiveSyncVersion : 14.0 NumberOfFoldersSynced : 6 SyncStateUpgradeTime :

Troubleshooting Exchange ActiveSync

Although mobile devices do not contain email configuration test tools like Outlook does, they do log Autodiscover information. Check the Settings tag to view the URLs the device uses to connect to the network. In the following sample output, the MobileSync section lists the server.
2009-09-14 13:29:24.0000 AutoDiscover Sending request to contoso.com 2009-09-14 13:29:24.0000 AutoDiscover Sending request to server contoso.com with SSL=true, body: <?xml version="1.0" encoding="utf8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/requestschema /2006"><Request><EMailAddress>mod4user7@contoso.com</EMailAddress><AcceptableRespo nseSchema>http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responsesc hema/2006</AcceptableResponseSchema></Request></Autodiscover> 2009-09-14 13:29:25.0000 EstConnection WOI NOT requested 2009-09-14 13:29:25.0000 EstablishConn hr=0x0, handle=0x3dfa28b6, pri=0x8000, status=0x10, flags=0x0, wait=0 2009-09-14 13:29:26.0000 AutoDiscover Received HTTP 404, HR=0x0 2009-09-14 13:29:26.0000 AutoDiscover SendRequest HR 0x85010005 2009-09-14 13:29:26.0000 AutoDiscover Sending request to autodiscover.contoso.com 2009-09-14 13:29:27.0000 AutoDiscover Sending request to server autodiscover.contoso.com with SSL=true, body: <?xml version="1.0" encoding="utf8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/requestschema /2006"><Request><EMailAddress>mod4user7@contoso.com</EMailAddress><AcceptableRespo nseSchema>http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responsesc hema/2006</AcceptableResponseSchema></Request></Autodiscover> 2009-09-14 13:29:27.0000 EstConnection WOI NOT requested 2009-09-14 13:29:27.0000 EstablishConn hr=0x0, handle=0x5f81704a, pri=0x8000, status=0x10, flags=0x0, wait=0 2009-09-14 13:29:34.0000 AutoDiscover Received HTTP 200, HR=0x0 2009-09-14 13:29:34.0000 AutoDiscover Received response: <?xml version="1.0" encoding="utf-8"?>

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschem a/2006"> <Culture>en:us</Culture> <User> <DisplayName>Mod4 User7</DisplayName> <EMailAddress>Mod4User7@contoso.com</EMailAddress> </User> <Action> < Settings> <Server> <Type>MobileSync</Type> <Url>https://mail.contoso.com/microsoft-server-activesync</Url> <Name>https://mail.contoso.com/microsoft-server-activesync</Name> </Server> </Settings> </Action> </Response> </Autodiscover> 2009-09-14 13:29:34.0000 AutoDiscover SendRequest HR 0x0 2009-09-14 13:29:35.0000 AutoDiscover Server setting obtained successfully

The Start Logging Option


In the Exchange Control Panel, on the Mobile Phones page, an option called Start Logging appears when you select a device from the list. This is an easy way to view logs from users after they reproduce their problems. When the user clicks the Start Logging button, the server runs cmdlets that initiate Exchange ActiveSync logging and tracks interaction with the device. An information message appears before Exchange Server initiates logging. When the user clicks Yes, the following cmdlet runs:
Set-CasMailbox ActiveSyncDebugLogging $true Identity <userMailbox>

Important: On busy servers, we recommend waiting for up to 3 minutes to ensure the log has started and is ready to capture the problem being reproduced. It can take a few attempts to capture the needed output.

When the logging starts, the Start Logging option changes to Retrieve Log. The Retrieve Log option stops the log. The following cmdlet runs:
Set-CasMailbox ActiveSynceDebugLogging $false Identity <userMailbox>

Then, the Exchange server retrieves the log and sends it to the user. The following cmdlet runs:
Get-ActiveSynceDevicesStatistics mailbox <userMailbox> -GetMailboxLog NotificationEmailAddresses <usermailbox@domain.com>

The mail arrives as an attachment in the mailbox specified by the NotificationEmalAdresses option.

Exchange ActiveSync Logging


Exchange ActiveSync logging is similar to device-side logging. It shows every command being sent to and from a mobile device. However, some of the information is sanitized for security purposes. For example, some email address entries are suppressed as shown in the following example.
</Collection> <Collection> <SyncKey>190336203</SyncKey> <CollectionId>2</CollectionId> </Collection> <Collection> <SyncKey>146175163</SyncKey> <CollectionId>5</CollectionId> <ConversationMode/> </Collection> <Collection> <SyncKey>320708661</SyncKey> <CollectionId>RI</CollectionId> </Collection> </Collections> <windowSize>100</windowSize> </Sync> AccessState : Allowed AccessStateReason : Global RespondHeader : HTTP/1.1 200 OK MS-Server-ActiveSync: 14.0

ResponseBody : [No XmlResponse] ResponseTime : 09/16/2010 07:03:07

View the log with Notepad. Each log section contains a log entry number with a log following below it, as shown below.
----------------Log Entry: 1 ----------------RequestTime : 09/16/2010 07:03:07 ServerName : NAE10CAS AssembleyVersion : 14.00.0639.011 Identifier : 236C2D70 RequestHeader : Post /Microsoft-Server-ActiveSync/ default.eas?Cmd=Syn&DeviceId=BAD73E6E02156460E900185977C03182&DeviceType=PocketPC HTTP/1.1 Cache-Control: no-cache Content-Length: 14 Content-Type: application/vnd.ms-sync.wbxml Accept-Encoding: gzip Accept-Language: en-us Authorization: ******* Host: mail.contoso.com MS-ASProtocolVersion: 14 X-MS-PolicyKey: 4161689659 RequestBody : <?xml version="1.0" encoding="uft-8" ?> <Sync xmlns="AirSync:"> <Collections> <Collection> <SyncKey>1092690365</SyncKey> <CollectionId>1</CollectionId> </Collection> <Collection> <SyncKey>1976925631</SyncKey> <CollectionId>11</CollectionId>

Section 2 Review

Answer the questions listed on the slide above.

Section 3: RPC Client Access Service

Introduction
In Exchange Server 2010, managed-code remote procedure call (RPC) endpoints were introduced in the Client Access server role. These endpoints sit on top of the core business logic layer shared by the other internal Exchange Server roles. This is called the RPC Client Access service. This section describes the RPC Client Access services role within your Exchange Server environment.

Objectives
After completing this section, you will be able to: Describe the RPC Client Access service. Define RPC encryption requirements for Outlook. Describe Client Access server arrays and NLB clustering. Create a load-balanced Client Access server array. Enable mailboxes to use the RPC Client Access service.

Overview of the RPC Client Access Service

In Exchange Server 2007, messaging API (MAPI) clients such as Outlook connecting to an Exchange server from inside an organizations firewall connected directly to the Mailbox server. In Exchange Server 2010, the Client Access server performs this processing. This change means that MAPI clients connect directly to the Client Access server rather than to the Mailbox server. This improves consistency when applying business logic to clients, and allows a higher number of concurrent connections per server and a higher number of mailboxes per server. Additionally, this architecture change improves the client experience when failover occurs. When a failover occurs in Exchange Server 2007, Outlook clients are disconnected from the Mailbox server for between one and fifteen minutes. Within Exchange Server 2010, if a Client Access server in a Client Access server array fails, the client immediately reconnects to another Client Access server in the array. If a Mailbox server fails, the client is disconnected for only 30 seconds.

RPC Encryption and Outlook

All Outlook clients supported by Exchange Server 2010that is Outlook 2003, 2007, and 2010can connect to the RPC Client Access service on a 2010 Client Access server or server array.
Note: The Outlook client connects to the Client Access server role as its MAPI endpoint for all connections except public folder access. Outlook clients connect directly to Mailbox servers for public folder access. The RPC Client Access service is still available on Mailbox servers for public folder connections.

In Exchange Server 2010, the RPC Client Access service requires encryption for RPC connections. However, RPC encryption is disabled by default in Exchange Server 2010 SP1. You can check this setting using the following cmdlet:
Get-RpcClientAccess | fl

We recommend enabling RPC encryption on the server side if you do not have Outlook 2003 clients in the environment. To enable this setting server-side, use the following cmdlet:
Set-RpcClientAccess Server <CAS Server or Mailbox Server> EncryptionRequired $true

Note: If you disable server-side RPC encryption, remember that you must do so on both the 2010 Client Access server and the 2010 Mailbox server. You must do this because the RPC Client Access service still contains connections to back-end Mailbox servers.

Client Access Server Arrays and Network Load Balancing

In a non-load-balanced environment, a Mailbox servers mailbox database is associated with one Client Access server. In a load-balanced environment, the mailbox database is associated with a load-balanced array of Client Access servers. By default, Exchange Server does not create Client Access server arrays. However, once created, you can associate all existing mailbox databases with the array. All newly created mailbox databases are automatically associated with the Client Access server array. To configure your Client Access server array, use the NLB clustering technology as described in a later topic. This technology load balances traffic across hosts. It also provides high availability by detecting host failures and automatically redistributing traffic to operational hosts. For more information about load balancing, you can refer to: Understanding Load Balancing in Exchange 2010 http://technet.microsoft.com/en-us/library/ff625247.aspx Load Balancing Requirements of Exchange Protocols http://technet.microsoft.com/en-us/library/ff625248.aspx

Network Load Balancing Modes

You can configure a NLB cluster for either unicast or multicast streaming when you want to load balance the RPC traffic to the RPC Client Access service.

Unicast Mode
In unicast mode, the media access control (MAC) address of each servers network adapter changes to a virtual cluster MAC address, which is the MAC address that all servers in the Windows NLB cluster use. When you enable unicast mode, clients can only connect to the servers through the virtual IP (VIP) address on the network interface card that is configured with the virtual cluster MAC address.

Multicast Mode
In multicast mode, a multicast MAC address is added to the cluster adapter of each server in the cluster. Each server retains its original MAC address. A NLB cluster, no matter what mode it is configured in, works with only one network adapter installed in each server. We recommend that you install a second network adapter in each server for optimal performance and to separate ordinary and cluster-related network traffic.

Best Practice
As a best practice, we recommend that you install two network interface cards (NICs) on each Client Access server. Optimally, use unicast mode so that the host and cluster network traffic reside on separate network interfaces. However, if you only have the option of installing one NIC in each Client Access server, or if you are forced to use multicast mode because of the switches used in your organization, you should pick multicast mode.

Suppose you are using unicast mode with two NICs. To configure the second NIC in each 2010 Client Access server, do the following: 1. In the Network Connections dialog box, click Name, and then name each local area network (LAN) with a meaningful name, such as NLB. 2. In the Network Connections dialog box, click Advanced. 3. In the Advanced Settings dialog box, change the binding order of the NICs in each Client Access server that will be part of the NLB cluster. List the production NIC first.
Note: You may need to hold down the CTRL key to view the Network Connections menu because it is hidden by default.

Network Load Balancing Configuration

The NLB configuration process described below is: 1. Install the Windows Server 2008 operating system NLB component. 2. Create a Client Access server array host record in the Domain Name System (DNS). 3. Create a Client Access server array object in AD DS. 4. Create a NLB Client Access server array, which includes adding new port rules for each client type. 5. Add additional hosts to the Client Access server array. 6. Configure mailbox databases.

Installing the Windows Server 2008 NLB Component


Unlike previous Windows Server versions, the NLB component is not installed by default in Windows Server 2008. To install the NLB component on Windows Server 2008, you can either use the Server Manager GUI or the ServerManagercmd executable: ServerManagercmd.exe -install NLB. To install the component on Windows Server 2008 R2, you can also use Microsoft Windows PowerShell. In the Server Manager GUI, do the following: 1. Select Features, and then click Add Features. 2. In the Add Features wizard, check the Network Load Balancing option, and then click Install. 3. Click Finish after NLB installation completes.

Creating the Client Access Server Array Host Record in DNS


Do the following to create a Client Access server array host record in DNS: 1. Log on to a domain controller in your Active Directory forest. 2. Click Start, click Run, and then type dnsmgmt.msc to open the DNS Manager. 3. Expand the Forward Lookup Zones container, and then right-click on the respective forward lookup zone for your Active Directory site. 4. On the context menu, select New Host (A). 5. In the New Host dialog box, under Name, type the name you want to use. The name must be unique and not a machine name or another DNS entry. 6. Under IP address, type the IP address you plan to use for the load-balanced Client Access server array. The name must be unique and not used by any other DNS entry. We recommend naming it outlook.domain.com.

Creating the Client Access Server Array Object in AD DS


If you did not previously create a Client Access server array object in AD DS, do so now with the following cmdlet:
New-ClientAccessArray Name <name of CAS array> Fqdn <fqdn of CAS array> -Site <name of AD site>

Creating a NLB Client Access Server Array


Create the load-balanced Client Access server array as follows: 1. Click Start, point to Administrative Tools, and then click Network Load Balancing Manager. 2. Select Cluster, and then click New. 3. Enter the name of the first node you wish to add to the array, and then click Connect. 4. In the New Cluster: Connect page, select NLB, and then click Next. 5. On the Host Parameter page, leave the defaults as is, and then click Next. 6. On the New Cluster: Cluster IP Addresses page, select the IP address that you wish to associate with the array, click Add, and then click Next.
Note: This address should be the same IP address that you specified when you created the DNS record (outlook.domain.com) for the Client Access server array.

7. On the New Cluster: Cluster Parameters page, specify the fully qualified domain name (FQDN) in the Full Internet name text box.

8. Select the Unicast option unless your Client Access servers are on top of a VMware ESX server or have other requirements for choosing multicast mode, and then click Next. 9. On the New Cluster: Port rules page, delete the default port rule, and then click Add. 10. On the Add/Edit Port Rule page, unselect All, and then specify the first port you wish to add to the array. For example, this port could be the TCP 135 endpoint mapper port, which is required for the Client Access server array. 11. Ensure that the port rule is set to single affinity, and then click OK. 12. Create additional port rules for RPC traffic. That is, specify the RPC ports that are used by the Outlook clients and the Client Access server array. Ensure that you select single affinity. For example, these ports could be TCP port 59531 for mailbox connections and TCP port 59532 for directory access connections. If you chose to use other static RPC ports or the default dynamic range of RPC ports, specify those instead. When you do not specify to use static RPC ports, add TCP port 59531 - 60554 in the port rule.
Note: For more information about port range changes in the Windows Vista and Windows Server 2008 operating systems, refer to http://support.microsoft.com/kb/929851/

Note: To configure static RPC ports on Exchange Server 2010, refer to http://social.technet.microsoft.com/wiki/contents/articles/configuring-static-rpcports-on-an-exchange-2010-client-access-server.aspx

13. If you are using this array for other Exchange Server clients, add port rules for these clients. Some port requirements are: Outlook Anywhere: TCP/443 Exchange ActiveSync: TCP/443 Outlook Web App: TCP/443 Secure IMAP4: TCP/993 Secure POP3: TCP/995 Internal IIS redirection (HTTP > HTTPS): TCP/80

Note: As a best practice, configure the secure IMAP4 and POP3 port rules with affinity set to none.

14. Click Finish.

Adding Additional Hosts to the Client Access Server Array


As required, add additional arrays to the Client Access server array as follows: 1. In the Network Load Balancing Manager console, right-click on the new array, and then select Add Host to Cluster. 2. On the Add Host to Cluster: Connect page, enter the network basic input/output system NetBIOS or FQDN of the 2010 Client Access server you want to add to the array, click Connect, and then click Next. 3. On the Add Host to Cluster: Host Parameters page, click Next. 4. On the Add Host to Cluster: Port Rules page, click Finish. The WNLB array adds the extra node(s) and updates the configuration as necessary.

Configuring Mailbox Databases


Before the Outlook MAPI client can use the Client Access server array, you must configure any mailbox databases within the Active Directory site where the Client Access server array was created so that they use the arrays FQDN. To configure the mailbox databases, open the Exchange Management Shell, and then enter the following cmdlet:
Set-MailboxDatabase <name of DB> -RpcClientAccessServer outlook.domain.com

Mailbox Databases and the RPC Client Access Service

By default, each mailbox database is enabled to use the RPC Client Access service. This process completes during new database creation or during setup if a Client Access server exists within the environment. During mailbox database creation, the server or cluster offering the RPC Client Access service is read from the Client Access server arrays object in AD DS. The array object contains the networkAddress attribute, which itself contains the FQDN network path. Set the NetworkAddress parameter with the New-ClientAccessArray cmdlet to create a new Client Access server array entry. You can also change this attribute with the SetClientAccessArray cmdlet. If the cmdlet has never been run, the mailbox databases RpcClientAccessServer setting is not set to an array.

Mailbox Databases in High Availability Environments


When you use database availability groups (DAGs) for database replication, the Active Manager tracks which mailbox database is currently active. The Active Manager reports this information to the 2010 Client Access servers in the Client Access server array. Because of this, the Outlook client does not have to track this data and continues to only communicate with the Client Access server array. When the Active Manager detects a database failure, it sends the newly active database location to the Client Access servers so that it can continue to service the requests coming from the client.

RPC Client Access and Outlook Behavior During Cross-Site Failover


In a DAG cross-site scenario in which there is a Mailbox server or database failover, the Outlook client behavior depends on whether the value of the RPCClientAccessServer property on the database has changed or not.

In Exchange Server 2010, if you do not change the RPCClientAccessServer property as part of the database failover: Clients continue to connect to the primary Client Access server array. Clients are not updated; clients do not require a restart. The primary Client Access server array directly connects to the Mailbox server in a secondary data center if the database is activated on a Mailbox server in a different Active Directory site.

If you do change the RPCClientAccessServer property to point to a secondary data center Client Access server array as part of the database failover, clients continue to connect to the primary Client Access server array at least initially. Additionally: Outlook 2010 clients perform Autodiscover requests and retrieve the updated Client Access array value. After restarting Outlook, the clients connect directly to the secondary Client Access server array. Outlook 2007 clients perform Autodiscover requests and retrieve the updated Client Access server array value. However, they do not apply the profile changes if the clients can still connect to the primary Client Access server array. A profile repair corrects the profile. If the primary Client Access server array is unavailable so that Outlook fails to connect on both TCP and HTTPS, then Outlook triggers a full Autodiscover and updates all profile configuration settings. This requires a client restart. Afterwards, the client connects to the secondary Client Access server array. Outlook 2003 clients never get updated to use the secondary Client Access server array unless you perform a profile repair or create a new profile. If the primary Client Access server array is unavailable for any reason, these clients cannot connect.

In Exchange Server 2010 SP1, the Set-DatabaseAvailabilityGroup cmdlet includes a new parameter called AllowCrossSiteRpcClientAccess. The AllowCrossSiteRpcClientAccess parameter specifies whether to enable or disable cross-site RPC client access connectivity for the DAG. By default, cross-site connections are disabled. If cross-site connections are allowed, the RPC Client Access service connects to the Mailbox server in the other site. If cross-site connections are not allowed, the RPC Client Access service redirects Outlook to the site that contains the mounted database.

Section 3 Review

Answer the questions listed on the slide above.

Section 4: Troubleshooting RPC Client Access

Introduction
Exchange Server contains the following tools that you can use to troubleshoot the RPC Client Access service: RPC Client-Access related events RPC Client Access protocol logging Performance counters Test-OutlookConnectivity cmdlet

This section describes how to troubleshoot the RPC Client Access service.

Objectives
After completing this section, you will be able to: Troubleshoot RPC Client Access by using events, protocol logging, and performance counters. Use the Test-OutlookConnectivity cmdlet.

RPC Client Access-Related Events

The following RPC Client Access-related events are available in Exchange Server 2010.
RPC Client Access-Related Events Name of Event: RpcClientAccessServiceStartPrivateSuccess Description: The RPC Client Access service has started successfully and is now ready to accept logons to private mailboxes. Event ID: 1000 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogAlways Comment: MSExchangeRPC server has started successfully

Name of Event: RpcClientAccessServiceStopSuccess Description: The RPC Client Access service has stopped successfully. Process ID %1. %2 %3. Event ID: 1001 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogAlways Comment: MSExchangeRPC server has stopped successfully

Name of Event: SpnRegisterFailure Description: Failed to register service principal name %1. Failed with error code %2. Event ID: 1002 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogOneTime Comment: ServicePrincipalName.RegisterServiceClass failed.

Name of Event: CannotStartServiceOnMailboxRole Description: Shutting down the RPC Client Access service because the Mailbox server role is installed on the current server. Event ID: 1004 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogOneTime Comment: Shutting down MSExchangeRPC service.

Name of Event: DuplicateRpcEndpoint Description: The RPC Client Access service cannot be started because the EMSMDB interface is already registered by another process. Event ID: 1005 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogOneTime Comment: Failed to start MSExchangeRPC service.

Name of Event: StartingRpcClientService Description: Starting the RPC Client Access service. Process ID %1. %2 %3. Event ID: 1006 Event Type: Information Severity: Success Category: General

Level: Lowest When Logged: LogOneTime Comment: Starting MSExchangeRPC service.

Name of Event: StoppingRpcClientService Description: Stopping the RPC Client Access service. Event ID: 1007 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogOneTime Comment: Stopping MSExchangeRPC service.

Name of Event: RpcClientServiceUnexpectedExceptionOnStart Description: Encountered unexpected error when starting the RPC Client Access service. Error details: %1 Event ID: 1008 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogAlways Comment: Encountered unexpected exception when starting MSExchangeRPC service.

Name of Event: RpcClientServiceUnexpectedExceptionOnStop Description: Encountered unexpected exception when stopping the RPC Client Access service. Error details: %1 Event ID: 1009 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogAlways Comment: Encountered unexpected exception when stopping MSExchangeRPC service.

Name of Event: RpcClientServiceUnexpectedExceptionOnStop Description: Encountered unexpected exception when stopping the RPC Client Access service. Error details: %1

Event ID: 1009 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogAlways Comment: Encountered unexpected exception when stopping MSExchangeRPC service.

Name of Event: RpcClientServiceOrganizationInformationReadingFailure Description: Failed to read organization information from AD DS. The RPC Client Access service stops. Event ID: 1012 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogOneTime Comment: Failed to read Organization Information from the Active Directory. MSExchangeRPC service will be stopped.

Name of Event: RpcClientServiceRemovingPrivilegeErrorOnStart Description: Cannot start the service due to a Win32 error when removing unnecessary privileges. Event ID: 1010 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogOneTime Comment: Cannot start the service due to a Win32 error when removing unnecessary privileges.

Name of Event: ConfigurationLoadFailed Description: The configuration cannot be loaded and the service cannot start. Error details: %1 Event ID: 1013 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogOneTime Comment: Service cannot be started if its configuration cannot be loaded.

Name of Event: UnexpectedExceptionOnConfigurationUpdate Description: An unexpected exception was encountered when updating the configuration for the RPC Client Access service. Error details: %1 Event ID: 1014 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogAlways Comment: MSExchangeRPC service experienced an unexpected failure while updating its configuration in response to a change notification.

Name of Event: ConfigurationUpdateFailed Description: The configuration update failed. The service will use the last known good configuration until the error is corrected. Error details: %1 Event ID: 1015 Event Type: Warning Severity: Warning Category: General Level: Lowest When Logged: LogPeriodic Comment: Configuration information in either Active Directory, Registry or app.config file was invalid. If the service was already running with some active valid configuration, it will continue to do so. If not, it will shut down. Look for preceding messages in the event log to determine the invalid configuration element.

Name of Event: ConfigurationInvalidValueType Description: The following configuration information is invalid: the value '%2' for %1 should be of type %3. Event ID: 1016 Event Type: Error Severity: Error <facility>Interface</facility> <language>English</language> Category: General Level: Lowest When Logged: LogPeriodic

Name of Event: ConfigurationInvalidValue

Description: The configuration information is not valid. Value '%2' is not valid for %1. Event ID: 1017 Event Type: Error Severity: Error Category: General Level: Lowest When Logged: LogPeriodic

Name of Event: ServiceProtocolNotEnabled Description: Outlook connectivity protocols are disabled for the current server. The service is being stopped. Event ID: 1018 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogOneTime Comment: Stopping MSExchangeRPC service.

Name of Event: ConfigurationUpdateAfterError Description: The configuration information has been successfully reloaded after previous errors. Event ID: 1019 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogAlways Comment: Configuration reloaded.

Name of Event: RpcClientAccessServiceStartPublicSuccess Description: The RPC Client Access service has started successfully and is now ready to accept sign-ins to public folders. Event ID: 1020 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogAlways Comment: MSExchangeRPC server has started successfully

Name of Event: ConfigurationUpdate Description: Configuration information has been successfully reloaded. Event ID: 1021 Event Type: Information Severity: Success Category: General Level: Lowest When Logged: LogAlways Comment: Not output by default. Can be enabled by setting the registry setting LogEveryConfigurationUpdate to REG_DWORD 0x1.

RPC Client Access Protocol Logging

By default, RPC Client Access protocol logging is enabled on every Client Access server. It logs all connect and disconnect operations completed by users. The log can help administrators verify when users last connected to the network or if a user has ever successfully connected at all. The default settings are located in the Microsoft.Exchange.RpcClientAccess.Service.exe.config file. They are: Default folder setting: %ExchangeInstallDir%\Logging\RPC Client Access\ Maximum size allowed for a log file before a new one is generated: 10240 kilobytes (KBs) Maximum size allowed for the entire directory of logs before the oldest log is deleted: 1048576 KBs Length of time a log file can cover before a new one is generated: 1440 minutes Log type tags to be logged: ConnectDisconnect

You can change the default values as needed. The two most useful values to change are: Default folder. Location of the log files, which you can move to a different drive as desired. Log type tags to be logged. You can add log details beyond the connect and disconnect operations. Your other options are: Rops. This option offers you a top-level mention of the remote operation being performed. Remote operations include Logon, OpenFolder, Release, GetContentsTable, and CreateMessage.

OperationSpecific. This option returns additional details for each remote operation. For example, SetProps on a CreateMessage operation.

In the following test trace, Mod1 User5 creates a new message and sends the message to Mod1 User1:
#Software: Microsoft Exchange #Version: 14.00.0532.002 #Log-type: RCA Protocol Logs #Date: 2009-05-22T16:03:22.199Z #Fields: date-time,session-id,seq-number,client-name,client-software,clientsoftware-version,local-endpoint,remoteendpoint,protocol,mailbox,operation,status,processing-time,operation-specific 2009-05-22T16:07:20.069Z,69,94,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>CreateMessage;>SetProps;>Release;>Rele ase;>RemoveAllRecipients;>FlushRecipients;>SetProps;>SubmitMessage;>GetPropertiesS pecific;<CreateMessage;<SetProps;<Release;<Release;<RemoveAllRecipients;<FlushReci pients;<SetProps;<SubmitMessage;<GetPropertiesSpecific 2009-05-22T16:07:20.084Z,69,95,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>Release;<Release 2009-05-22T16:07:21.100Z,69,96,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,DoAsyncWaitEx(handle=1073741893 flags=0) 2009-05-22T16:07:22.725Z,69,97,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,DoAsyncWaitEx(handle=1073741893 flags=0) 2009-05-22T16:07:43.195Z,69,98,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>RegisterNotification;>GetContentsTable ;>RegisterNotification;>SetColumns;>QueryPosition;<RegisterNotification;<GetConten tsTable;<RegisterNotification;<SetColumns;<QueryPosition 2009-05-22T16:07:48.195Z,69,99,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>OpenFolder;>RegisterNotification;>GetP ropertiesSpecific;<OpenFolder;<RegisterNotification;<GetPropertiesSpecific 2009-05-22T16:07:48.195Z,69,100,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>OpenFolder;>RegisterNotification;>GetP ropertiesSpecific;<OpenFolder;<RegisterNotification;<GetPropertiesSpecific 2009-05-22T16:07:48.210Z,69,101,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>GetContentsTable;>SetColumns;>SetColum ns;>SortTable;>QueryPosition;<GetContentsTable;<SetColumns;<SetColumns;<SortTable; <QueryPosition

2009-05-22T16:07:48.210Z,69,102,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>OpenFolder;>RegisterNotification;>GetP ropertiesSpecific;<OpenFolder;<RegisterNotification;<GetPropertiesSpecific 2009-05-22T16:07:48.257Z,69,103,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>GetContentsTable;>SetColumns;>QueryRow s;<GetContentsTable;<SetColumns;<QueryRows 2009-05-22T16:07:51.773Z,71,15,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,,0,,>Release;>Release;>Release;>Release;>Re lease;>Release;>Release;<Release;<Release;<Release;<Release;<Release;<Release;<Rel ease 2009-05-22T16:07:51.789Z,71,16,/o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Mod1 User5,,,192.168.0.20,::1,ncacn_ip_tcp,,Disconnect,0,,

A CreateMessage operation generates the new message, and then immediately afterwards you see that the SetProps operation sets the properties on the message.

Performance Counters

The following performance counters are available to help you monitor RPC Client Access operations in your environment.
Performance Counter RPC Requests RPC Packets/sec RPC Operations/sec RPC Averaged Latency RPC Clients Bytes Read RPC Clients Bytes Written RPC Clients Uncompressed Bytes Read RPC Clients Uncompressed Bytes Written Connection Count Active User Count User Count Client: RPCs attempted Client: RPCs succeeded Description The number of client requests that are currently being processed by the RPC Client Access service. The rate at which RPC packets are processed, per second. The rate at which RPC operations occur, per second. Latency, in milliseconds, averaged for the past 1024 packets. Total number of bytes that were read from RPC clients. Total number of bytes written to RPC clients. Total number of uncompressed bytes read from RPC clients. Total number of uncompressed bytes written to RPC clients. Total number of client connections maintained. Number of unique users that have shown some activity in the last two minutes. Number of users that are connected to the service. Total number of RPCs attempted by the users since the service was started. Total number of successful RPCs since the service was started.

Performance Counter Client: Background RPCs succeeded Client: Foreground RPCs succeeded Client: RPCs Failed Client: Background RPCs Failed Client: Foreground RPCs Failed Client: Latency > 2 sec RPCs Client: Latency > 5 sec RPCs Client: Latency > 10 sec RPCs

Description Client-reported total number of successful background RPCs since the service was started. Client-reported total number of successful foreground RPCs since the service was started. Client-reported number of failed RPCs since the service was started. Client-reported number of failed background RPCs since the service was started. Client-reported number of failed foreground RPCs since the service was started. Client-reported number of successful RPCs with latencies greater than two seconds. Client-reported number of successful RPCs with latencies greater than five seconds. Client-reported number of successful RPCs with latencies greater than 10 seconds.

Testing Outlook Connectivity

The Test-OutlookConnectivity cmdlet validates HTTP and MAPI Outlook client connections, TCP/IP, and Outlook Anywhere. The end-to-end verification process includes Autodiscover connectivity, user profile creation, and user mailbox logon. If the cmdlet fails, the output notes the step at which it failed. The following sample output displays after specifying TCP as the Protocol parameter. For each named computer, it shows the scenario, the result, and the event type.
PSComputerName RunspaceId MailboxDatabase Id ClientAccessServer Scenario ScenarioDescription PerformanceCounterName Result Error UserName StartTime Latency EventType LatencyInMillisecondsString Identity IsValid PSComputerName RunspaceId MailboxDatabase Id ClientAccessServer : : : : : : : : : : : : : : : : : : : : : : NAE10CAS.contoso.com 4f90fce7-01e3-4b23-a0f9-1ceccc7c512a Mailbox Database 1900108553 Autodiscover NAE10CAS.contoso.com Autodiscover: Web service request.

Success
NAE10CAS.contoso.com\extest_52b8d1353b354 6/1/2009 11:24:26 AM 00:00:00.1093750 Success 109.38 True NAE10CAS.contoso.com 4f90fce7-01e3-4b23-a0f9-1ceccc7c512a Mailbox Database 1900108553 GetReferral NAE10CAS.contoso.com

Scenario ScenarioDescription PerformanceCounterName Result Error UserName StartTime Latency EventType LatencyInMillisecondsString Identity IsValid PSComputerName RunspaceId MailboxDatabase Id ClientAccessServer Scenario ScenarioDescription PerformanceCounterName Result Error UserName StartTime Latency EventType LatencyInMillisecondsString Identity IsValid PSComputerName RunspaceId MailboxDatabase Id ClientAccessServer Scenario ScenarioDescription PerformanceCounterName Result Error UserName StartTime Latency EventType LatencyInMillisecondsString Identity IsValid PSComputerName RunspaceId MailboxDatabase Id ClientAccessServer Scenario ScenarioDescription PerformanceCounterName Result

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

RFRI::GetReferral. RFR: Get referral latency Success NAE10CAS.contoso.com\extest_52b8d1353b354 6/1/2009 11:24:26 AM 00:00:00.0468750 Success 46.88 True NAE10CAS.contoso.com 4f90fce7-01e3-4b23-a0f9-1ceccc7c512a Mailbox Database 1900108553 GetProfileDetails NAE10CAS.contoso.com NSPI::GetProfileDetails. NSPI: profile creation/repair latency Success NAE10CAS.contoso.com\extest_52b8d1353b354 6/1/2009 11:24:26 AM 00:00:00.0468750 Success 46.88 True NAE10CAS.contoso.com 4f90fce7-01e3-4b23-a0f9-1ceccc7c512a Mailbox Database 1900108553 MailboxConnect NAE10CAS.contoso.com Mailbox::Connect. Mailbox: Connect latency Success NAE10CAS.contoso.com\extest_52b8d1353b354 6/1/2009 11:24:26 AM 00:00:00.0000001 Success 0.00 True NAE10CAS.contoso.com 4f90fce7-01e3-4b23-a0f9-1ceccc7c512a Mailbox Database 1900108553 MailboxLogon NAE10CAS.contoso.com Mailbox::Logon. Mailbox: Logon latency Success

Error UserName StartTime Latency EventType LatencyInMillisecondsString Identity IsValid

: : : : : : : :

NAE10CAS.contoso.com\extest_52b8d1353b354 6/1/2009 11:24:26 AM 00:00:00.0156250 Success 15.62 True

Lab 3A: Configuring RPC Client Access

Section 4 Review

Answer the questions listed on the slide above.

Section 5: Scalability and Performance

Introduction
In an Exchange Server 2010 proxy environment, poor performance may occur when the Client Access servers receive too many concurrent requests. Web service requests from ASP.NET can exhaust threads and available connections, which in turn can cause the Client Access servers to deny requests or exhibit high latency when the requests are being processed. To resolve these issues, you can configure several ASP.NET parameters by editing the Machine.config file on the Client Access server. For more information about how to configure these parameters, see Microsoft Knowledge Base article 821268, Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications. This section describes how to use client throttling to improve scalability and performance.

Objectives
After completing this section, you will be able to: Define client throttling. Use client throttling policies.

Overview of Client Throttling

Exchange Server tracks the resources that each user consumes and uses client throttling to enforce connection bandwidth limits. Exchange Server uses a limits-based system that tracks a single users actions and drops requests when the user has gone over the acceptable limits. Additionally, client throttling provides a way to slow users down by sleeping their threads when the CPU for a given application is too high. Client throttling controls users across the following areas. Number of open concurrent connections. Time spent connected to the Client Access server. Time spent performing Active Directory look ups and calls. Time spent performing RPC calls to Mailbox servers. Number of mail messages that users can send.

Client throttling is implemented by each application that connects to an Exchange server. All client connection points use the same throttling configuration and actions so that the throttling configuration and experience is the same across all client connections.

Client Throttling Policies

Exchange Server 2010 uses client throttling policies to manage the performance of your Exchange Server organization. A client throttling policy consists of a group of settings that control how many resources each user or connection can use against the Exchange Server organization. You can only use throttling polices for users that use Exchange Server 2010 servers. The policies do not apply to previous Exchange Server versions. Throttling policies are stored in the following locations in AD DS: CN=Global Settings, CN= Exchange Org, CN= Microsoft Exchange, CN=Services, CN= Configuration, DC= Domain, DC = COM.

Exchange Server generates a budget based on the throttling policy settings. The budget controls the amount of access that is allowed to users and applications. Budgets are generated from the throttling policy based on the number connections users are allowed to make and on how much activity users can do in one minute in a given area. Two budgetary exceptions are for delegates and service accounts, as follows: Delegates. Delegates are charged against their own budget when they access a resource that they are delegated to use. For example, suppose John is Marys delegate and has access to her calendar. When John accesses Mary calendar, the issued commands come from Johns budget, not Marys budget. Service Accounts. Service accounts that use Exchange Server impersonation to accomplish work on behalf of users have access to user budgets if this is specified in the linked throttling policy. Service account actions are not charged to users budgets. However, the service account uses the same budget as the account for which it is working.

In Exchange Server 2010 Enterprise installations, there is a single default throttling policy called First Organization. Exchange Server applies a throttling budget to a user when the user connects to a Client Access server. The basic logic that each application uses to determine if a user is under or over budget is: 1. Application receives a client request. 2. Client Access server authenticates the user. 3. Exchange Server checks to see if the budget user exists. 4. If the budget exists: Is it over budget? If the budget does not exist, look up budget in AD DS: Is the user over budget? 5. If under budget, proceed with the request and charge the users budget. If over budget, return a server-too-busy error message

Throttling Policy Settings

In the Exchange Management Shell, manage throttling policies with the following cmdlets: Get-ThrottlingPolicy New-ThrottlingPolicy Set-ThrottlingPolicy Remove-ThrottlingPolicy

Throttling policies apply to the following features: Exchange ActiveSync Exchange Web Services Outlook Web App IMAP4 POP3

Throttling Policy Parameters

Use the following policy parameters with the throttling policy parameters:
Parameter <Acronym>MaxConcurrency <Acronym>PercentTimeInAD Description Specifies how many concurrent connections a specified user can have against an Exchange server at one time. Specifies what percentage of a minute can be spent running Lightweight Directory Access Protocol (LDAP) requests. Specifies what percentage of a minute can be spent running Client Access server code. Specifies what percentage of a minute can be spent running mailbox RPC service requests.

<Acronym>PercentTimeInCAS <Acronym>PercentTimeIn MailboxRPC

The acronym is:


Feature Exchange ActiveSync Exchange Web Services Outlook Web App IMAP4 POP3 Acronym EAS EWS OWA IMAP POP

Do not set throttling policy parameters to $null unless there is a business requirement. This causes users to place a high load on the server.

Example 1
Set-ThrottlingPolicy Identity TestPolicy IMAPMaxConcurrency 4

Example 2 By default, users are assigned the default throttling policy if you do not specify a policy when you are creating a new mailbox with the New-Mailbox cmdlet. To set a throttling policy on an existing mailbox, use the Set-Mailbox cmdlet. The following cmdlet assigns the TestPolicy policy to user Mod1User2.
Set-Mailbox Identity Mod1User2 ThrottlingPolicy TestPolicy

Example 3 To remove the policy, run the following cmdlet:


Set-Mailbox Identity Mod1User2 ThrottlingPolicy $null

Section 5 Review

Answer the questions listed on the slide above.

Section 6: The Address Book Service

Introduction
This section describes the Address Book Service, which provides directory access for clients. This service is new for Exchange Server 2010. In previous Exchange Server versions, Exchange Server provided a referral service that told clients such as Outlook where they could find a server running the Name Service Provider Interface (NSPI). This referral usually pointed Outlook to a global catalog server. In Exchange Server 2010, the NSPI endpoint now runs on the Client Access server role, which means that both mailbox access and directory access are handled by the Client Access server.

Objectives
After completing this section, you will be able to: Define the Address Book Service. Describe global address list (GAL) selection.

Overview of the Address Book Service

In Exchange Server 2010, three possible actions occur when Outlook contacts the Client Access server: If the users mailbox is on an Exchange Server 2007 Mailbox server or an Exchange Server 2003 Mailbox server, the directory request is referred to the users 2007 or 2003 Mailbox server, respectively. If the users mailbox is on an Exchange Server 2010 Mailbox server, and if the users mailbox is in the same site as the Client Access server, the request is referred to the Client Access server. If the users mailbox is on an Exchange Server 2010 Mailbox server in a different site than the Client Access server, the request is referred to a Client Access server in the remote site.

The Client Access server hosts both the referral service and the NSPI endpoint. These two components are necessary for directory access to flow through the Client Access server. DSProxy is not longer necessary, as it was with previous Exchange Server versions.
Note: If your Client Access server is installed on a domain controller, Outlook communicates directly with the domain controller and bypasses the Client Access server.

Previously, in environments that deployed multiple domains, there was potential for a client to be referred to a global catalog server that did not own the object the end user was attempting to modify. Exchange Server tended to refer a user to a global catalog server

that was in the same domain as the user, but distribution group changes were never guaranteed. The Address Book Service specifically detects ModProps RPC and ModLinkAtt RPC requests and takes the appropriate action if the modification is scoped to distribution group membership, delegate management, and certificate management. Assuming the user has the rights to modify these propertieswhich are controlled through role based access control (RBAC)the Address Book Service utilizes the appropriate cmdlet to commit the change to AD DS. Future requests are sent to the same global catalog server so that the changes are reflected, and so there is no need to wait up to 15 minutes for AD DS replication.

Global Address List Selection

In prior Exchange Server versions, each client computed the users GAL in a different manner. For example, Outlook chose the GAL based on AD DS access control lists, while Client Access components used the out-of-box GAL or honored the msExchQueryBaseDN attribute, if set. The result was that it was difficult to configure organizations with multiple GALs for different user segments. In Exchange Server 2010, all clients select user GALs through the same code path regardless of access control lists and msExchQueryBaseDN. Additionally, GAL membership no longer implies GAL assignment. Exchange Server retrieves all GALs under the organizations GAL container by evaluating access control lists that users can access. The logic is: 1. If msExchQueryBaseDN is set, return the GAL that it specifies. 2. Otherwise, build a set of accessible GALs by evaluating the access control lists to retrieve all GALs under the organizations GAL container that the user may access. 3. Select one container as the default container. A. If there is only one container, return it. B. If there is more than one container, find all GALs in which the user is a member. (1) If there is only one container, return it. (2) If there is more than one container, or the user is not a member of any container, return the largest of the remaining set.

Section 6 Review

Answer the questions listed on the slide above.

Section 7: The Autodiscover Service

Introduction
Exchange Server 2010 includes the Autodiscover service. The Autodiscover service does the following: Automatically configures user profile settings for clients running Outlook 2007, Outlook 2010, and supported mobile phones. Provides access to Exchange Server features for Outlook 2007 and Outlook 2010 clients. Uses a users email address and password to provide profile settings to Outlook 2007 and Outlook 2010 clients, and supported mobile phones. If the Outlook client is joined to a domain, the users domain account is used.

This section explains how the Autodiscover service works, how it configures Outlook clients, and what options there are for deploying the Autodiscover service in your messaging environment.

Objectives
After completing this section, you will be able to: Locate and use the Autodiscover service. Use Client Access server arrays with the Autodiscover service. Troubleshoot the Autodiscover service.

Locating the Autodiscover Service

Autodiscover information is stored in a service connection point for domain-joined clients. During Client Access server installation, the service connection point is created in AD DS and configured with the default values. If you have multiple Client Access servers there will be multiple service connection points. For nondomain clients, the email accounts Simple Mail Transfer Protocol (SMTP) address retrieves Client Access server information from the DNS server. Outlook is hard-coded to use several URLs according to the SMTP address. For example: https://autodiscover.<domain name>.com. To access this address over the SSL, you should include it in the subject alternative name (SAN) certificate. The following client information is configured during the Autodiscover process: Exchange Web Services Out-of-office information Availability Service Unified Messaging information MailTips in Outlook 2010 Offline address book download information Exchange Server 2010 Personal Archives Exchange Control Panel settings in Outlook 2010

These settings are configured when you setup the Client Access server with the This is an external facing Client Access Server option. The Exchange Remote Connectivity

Analyzer can help you to troubleshoot your Autodiscover problems. Refer to www.testexchangeconnectivity.com for more information.

Autodiscover Service Types

Exchange Server 2010 includes two types of Autodiscover service: Autodiscover Service (POX): This service provides a mechanism that uses XML messages that consist only of XML payloads without an enclosing SOAP envelope. Autodiscover Service (SOAP): This service uses the messaging framework for messages sent between the client application and the Exchange server.

An example of an Autodiscover SOAP request might look like:


<?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:a="http://schemas.microsoft.com/exchange/2010/Autodiscover" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> <a:RequestedServerVersion>Exchange2010</a:RequestedServerVersion> <wsa:Action>http://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/G etUserSettings</wsa:Action> <wsa:To>https://EX2010CAS.com/autodiscover/autodiscover.svc</wsa:To> </soap:Header> <soap:Body> <a:GetUserSettingsRequestMessage xmlns:a="http://schemas.microsoft.com/exchange/2010/Autodiscover"> <a:Request> <a:Users> <a:User> <a:Mailbox>UserName@domain.contoso.com</a:Mailbox> </a:User> </a:Users> <a:RequestedSettings> <a:Setting>UserDisplayName</a:Setting>

<a:Setting>UserDN</a:Setting> <a:Setting>UserDeploymentId</a:Setting> <a:Setting>InternalMailboxServer</a:Setting> <a:Setting>MailboxDN</a:Setting> <a:Setting>ActiveDirectoryServer</a:Setting> <a:Setting>CasVersion</a:Setting> <a:Setting>EwsSupportedSchemas</a:Setting> </a:RequestedSettings> </a:Request> </a:GetUserSettingsRequestMessage> </soap:Body> </soap:Envelope>

The elements of this request are: GetUserSettingsRequestMessage Mailbox Request RequestedServerVersion RequestedSettings Setting User Users

The response includes each requested item in its own section of the returned XML. For example, in the following response you can see the return valuedenoted by <Value> under each element that was returned. The UserDisplayName returned Joe Smith, and the CasVersion returned 14.00.0478.000.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="1"> http://schemas.microsoft.com/exchange/2010/Autodiscover/ Autodiscover/GetUserSettingsResponse</a:Action> </s:Header> <s:Body> <GetUserSettingsResponseMessage xmlns="http://schemas.microsoft.com/exchange/2010/Autodiscover"> <Response xmlns:i="http://www.w3.org/2001/XMLSchema-instance"> <ErrorCode>NoError</ErrorCode> <ErrorMessage /> <UserResponses> <UserResponse> <ErrorCode>NoError</ErrorCode> <ErrorMessage>No error.</ErrorMessage> <RedirectTarget i:nil="true" /> <UserSettingErrors /> <UserSettings> <UserSetting i:type="StringSetting"> <Name>UserDisplayName</Name> <Value>Joe Smith</Value>

</UserSetting> <UserSetting i:type="StringSetting"> <Name>UserDN</Name> <Value>/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/ cn=Recipients/cn=Joe Smith</Value> </UserSetting> <UserSetting i:type="StringSetting"> <Name>UserDeploymentId</Name> <Value>a40d2742-13c6-4060-8dd2-d42f120c22b8</Value> </UserSetting> <UserSetting i:type="StringSetting"> <Name>CasVersion</Name> <Value>14.00.0478.000</Value> </UserSetting> <UserSetting i:type="StringSetting"> <Name>EwsSupportedSchemas</Name> <Value>Exchange2007, Exchange2007_SP1,Exchange2010</Value> </UserSetting> <UserSetting i:type="StringSetting"> <Name>InternalMailboxServer</Name> <Value>machinename.contoso.com</Value> </UserSetting> <UserSetting i:type="StringSetting"> <Name>ActiveDirectoryServer</Name> <Value>machinename.contoso.com</Value> </UserSetting> <UserSetting i:type="StringSetting"> <Name>MailboxDN</Name> <Value>/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/ cn=Configuration/cn=Servers/cn=EXCH2010SRVR/cn=Microsoft Private MDB</Value> </UserSetting> </UserSettings> </UserResponse> </UserResponses> </Response> </GetUserSettingsResponseMessage> </s:Body> </s:Envelope>

We recommend that you use the SOAP Autodiscover service instead of the POX Autodiscover service because it: Supports batch requests. Allows you to request only the settings that you need. Is supported in the Exchange Web Services MAPI. Is updated with new Autodiscover features.

Using Client Access Server Arrays

You can configure your Autodiscover environment to use Client Access server arrays. To do this, change all of the service connection points to the arrays FQDN. If you have already setup an RPC Client Access service array, you can use the same array name. To change the service connection points, specify the following cmdlet:
Set-ClientAccessServer AutodiscoverServiceInternalUri https://<array's FQDN>/autodiscover/autodiscover.xml

The Client Access server array submits client requests when the requests access any service connection point. You can also set the AutodiscoverServiceInternalUri parameter on your Exchange Server 2007 SP2 servers so that when a client finds any Client Access server, it will use the array entry and all requests will automatically be load balanced.

Autodiscover Site Scope for Client-Only Sites

The Autodiscover service always distributes URLs that are in the same Active Directory site as the users Mailbox server. However, certain Outlook clients may not be able to find a local Autodiscover service. The way a domain-joined client can find a local Autodiscover service is by utilizing the Autodiscover site scope information that is part of the service connection point object in AD DS. During server installation, the service connection point object is populated with the Active Directory site of its corresponding Client Access server. This means that any clients that are in the same Active Directory site as the Client Access server will be able to use the local server to make Autodiscover requests. Outlook clients may not be able to find the local Autodiscover service when they are associated with Active Directory sites that have no Exchange servers. By default, these Outlook clients use a random Client Access server for Autodiscover, or the first one that comes back from AD DS in a LDAP query. To select an Active Directory site for these clients, add the client sites to the AutodiscoverSiteScope attribute on each Client Access server in the closest Active Directory site. By doing this, you conserve bandwidth and improve performance by keeping Autodiscover traffic relatively local. Use the Set-ClientAccessServer cmdlet to manually populate the AutodiscoverSiteScope attribute. For example:
Set-ClientAccessServer -identity <server name> -AutodiscoverSiteScope Site1,Site2,Site3

For more information about the AutodiscoverSiteScope attribute, refer to How to Configure the Autodiscover Service to Use Site Affinity at http://technet.microsoft.com/en-us/library/aa998575.aspx.

Troubleshooting the Autodiscover Service

The following tools can help you troubleshoot the Autodiscover service: Outlooks Test Email AutoConfiguration You can quickly retrieve the settings for any user, which can help you determine if the settings Outlook is retrieving are as expected. To test only Autodiscover settings, uncheck the Use Guessmart and Secure Guessmart Authentication options before clicking Test. To enable this tool, press CTRL and the Outlook icon located in the icon tray, and then click Test Email AutoConfiguration. Exchange Server Remote Connectivity Analyzer This tool allows you to perform a variety of connectivity tests from outside the organization. You can use it after you are sure that Autodiscover was configured correctly for external access. This includes DNS, certificate placement, and the enabling of Outlook Anywhere. You can access this tool at www.testexchangeconnectivity.com. Outlook logging The Outlook log file contains the raw XML data and the URLs that Outlook uses to attempt to contact the Autodiscover service. By default, logging is disabled. To enable logging, from the Office button, click Options, click Advanced, and then check the Enable Troubleshooting logging (requires restarting Outlook) option. The name and the location of the generated log file is olkdisc.log at \Users\<user name>\AppData\Local\Temp.

Test-OutlookWebServices Use the Test-OutlookWebServices cmdlet. For example, the following cmdlet performs a test using the e2k10user1 account and the NAE10CAS server.

Test-OutlookWebServices e2k10user1 ClientAccessServer NAE10CAS

Event logging Performance counters

Event Logging

The Autodiscover service uses the following events to inform you of successes or failures in your environment.
Autodiscover Events Name=ErrWebException Description: Unhandled Exception "%1"%nStack trace: %2 Event ID: 0001 Event Type: Error Severity: Error Category: Web Level: Lowest

Name=ErrCoreInvalidRedirectionUrl Description: The setting "PodRedirectTemplate" specified in the site's web.config file is not a valid URL format string. Event ID: 0102 Event Type: Error Severity: Error Category: Core Level: Lowest

Name=WarnCoreElementIsEmpty Description: Element "%1" is empty. Request processing stopped. The event is logged because the AcceptableResponseSchema element from the client request is empty.

Event ID: 1101 Event Type: Warning Severity: Warning Category: Core Level: Expert

Name=WarnCoreValidationError Description: Request XML Format Validation %1:"%2", Line:%3, Position:%4. The client request did not comply with the Microsoft Exchange Autodiscover service request schema. Event ID: 1103 Event Type: Warning Severity: Warning Category: Core Level: Expert

Name=WarnCoreValidationException Description: Request XML Format Validation Exception: "%1". The Microsoft Exchange Autodiscover service will be unable to complete processing the request because the request has XML format errors. Event ID: 1104 Event Type: Warning Severity: Warning Category: Core Level: Expert

Name=WarnCoreProviderNotFound Description: Requested provider for Request Schema:"%1" and Response Schema:"%2" cannot be found. Event ID: 1105 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnCoreProviderLoadError Description: Error "%1" while loading the assembly "%2".%nStack Trace:%3. This error may occur because the provider file is corrupt, is in an incorrect format, or has insufficient permissions. Event ID: 1106 Event Type: Warning Severity: Warning

Category: Core Level: Lowest

Name=WarnCoreProviderFileLoadException Description: Error "%1" while loading assembly "%2".%nStack Trace:%3. The event is logged because the Microsoft Exchange Autodiscover service found the managed assembly or DLL it was referencing, but failed to load the assembly. Event ID: 1108 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnCoreProviderReflectionTypeLoadException Description: Error "%1" while loading assembly "%2".%nStack Trace:%3. This event is logged when the loader that Autodiscover is using to load an assembly or DLL has failed because the loader may not be valid. Event ID: 1109 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnCoreProviderBadImageFormatException Description: Error "%1" while loading assembly "%2".%nStack Trace:%3. The event is logged when the Autodiscover provider is unable to load the assembly it is referencing because the assembly or DLL could be in an invalid format. Event ID: 1110 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnCoreProviderSecurityException Description: Error "%1" while loading assembly "%2".%nStack Trace:%3. The event is logged when Autodiscover is unable to load an assembly because the assembly file does not have appropriate access permissions (executable and read permissions). Event ID: 1111 Event Type: Warning Severity: Warning Category: Core

Level: Lowest

Name=WarnCoreProviderFileNotFoundException Description: Error "%1" while loading assembly "%2".%nStack Trace:%3. The event is logged when Autodiscover is unable to find an assembly or DLL that Autodiscover is trying to reference. Event ID: 1112 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnCoreProviderAttributeException Description: Provider "%1" has invalid attribute - "%2". The entry is not added to the table. Event ID: 1113 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnCorePerfCounterInitializationFailed Description: Error "%1" while initializing performance counters. Stack Trace:%2 Event ID: 1114 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnCorePerfCounterIncrementFailed Description: Error "%1" while incrementing performance counters. Stack Trace:%2 Event ID: 1115 Event Type: Warning Severity: Warning Category: Core Level: Lowest

Name=WarnProvErrorResponse Description: Time:%1, Id:%2, Error Response with the ErrCode:"%3", Message:"%4", DebugData:"%5" was generated for EMailAddress:"%6", LegacyDN:"%7" by "%8". Event ID: 1201

Event Type: Warning Severity: Warning Category: Provider Level: Expert

Name=InfoWebApplicationStart Description: The Autodiscover service started successfully. Event ID: 2001 Event Type: Information Severity: Success Category: Web Level: Lowest

Name=InfoWebSessionStart Description: The Autodiscover session started. User SID:"%1", HostAddress:"%2", HostName:"%3". Event ID: 2003 Event Type: Information Severity: Success Category: Web Level: Expert

Name=InfoWebSessionSuccess Description: The Autodiscover request processed successfully. User SID:"%1", HostAddress:"%2", HostName:"%3". Event ID: 2004 Event Type: Information Severity: Success Category: Web Level: Expert

Name=InfoWebSessionFailure Description: The Autodiscover request processed with an error. User SID:"%1", HostAddress:"%2", HostName:"%3". Event ID: 2005 Event Type: Information Severity: Success Category: Web Level: Lowest

Name=InfoCoreProvidersLoaded Description: Providers %1 were loaded. Event ID: 2101 Event Type: Information Severity: Success Category: Core Level: Lowest

Name=InfoProvRedirectionResponse Description: Response with RedirectUrl:"%1" was generated for EMailAddress:"%2", LegacyDN:"%3" by the provider "%4". Event ID: 2201 Event Type: Information Severity: Success Category: Provider Level

Name=InfoProvConfigurationResponse Description: The configuration was generated for "%1". Event ID: 2202 Event Type: Information Severity: Success Category: Provider Level: Expert

Performance Counters

The following performance counters monitor Autodiscover service requests.


Autodiscover Performance Counters Counter Name="TotalRequests" DisplayName: Total Requests: Help: Total Requests is the number of Autodiscover requests processed.

Counter Name="TotalErrorResponses" DisplayName: Error Responses: Help: Error Responses is the total number of Autodiscover error responses since the service was started or restarted.

Counter Name="TotalErrorResponses" DisplayName: Error Responses: Help: Error Responses is the total number of Autodiscover error responses since the service was started or restarted.

Counter Name="ErrorResponsesPerSecond" AutoUpdatedByCounterTotalErrorResponses/AutoUpdatedByCounter DisplayName: Error Responses/sec: Help: Error Responses/sec is the number of Autodiscover error responses each second./Help:

Autodiscover Performance Counters Counter Name="PID" DisplayName: Process ID: Help: Process ID is the process ID that is hosting Autodiscover.

Section 7 Review

Answer the questions listed on the slide above.

Section 8: Outlook Anywhere

Introduction
This section describes Outlook Anywhere integration with the Client Access server.

Objectives
After completing this section, you will be able to: Describe Outlook Anywhere. Describe how Outlook Anywhere integrates with the Client Access server.

Overview of Outlook Anywhere

Outlook Anywhere provides Internet-based access to the messaging environment. It eliminates the need to use virtual private networks (VPNs) to access servers that are running Exchange Server 2003 SP1, Exchange Server 2007, and Exchange Server 2010. It uses the Address Book Service on the Client Access server for directory-related requests.

Outlook Anywhere and the Client Access Server

When you enable Outlook Anywhere on a server that is running Exchange Server 2010 with an installed Client Access server role, users use RPC over HTTP to connect to their Exchange Server mailboxes. Outlook Anywhere clients generate two connections spawned by the RPC over HTTP client component to represent a single RPC connection. This occurs because HTTP connections are half duplex. That is, they either allow you to send information or receive information, but not both at the same time. In the case of RPC, connections need to be long lived and full duplex, so the RPC_IN_DATA connection acts as the sending half duplex connection, while the RPC_OUT_DATA connection acts as the receiving half duplex connection. Since HTTP requires that each connection be given a maximum length, each connection is 1 gigabyte (GB) and terminates when it reaches this limit. Each of these connections is tagged with a client session identification. When the RPC server component receives the RPC_IN_DATA and RPC_OUT_DATA with the same client session ID, it knows that for any request received on the RPC_IN_DATA connection, it must reply back on the RPC_OUT_DATA connection. In previous Exchange Server versions, split HTTP connections caused by DSProxy proxying RPC_IN_DATA and RPC_OUT_DATA independently and then sending these connections to different domain controllers could break directory connections for Outlook Anywhere. This is no longer an issue becauseas with OutlookExchange Server 2010 uses directory referrals for all directory requests for Outlook Anywhere and registers the NSPI endpoint on the Client Access server.

Section 8 Review

Answer the questions listed on the slide above.

Section 9: Secure Sockets Layer and Certificates

Introduction
By default, Outlook Web App, Exchange ActiveSync, and Outlook Anywhere communications are encrypted by using the Secure Sockets Layer (SSL). By default, POP3 and IMAP4 are not configured to communicate over SSL. For an Exchange Server 2010 computer with an installed Client Access server, SSL helps secure communications between the server and the clients. Clients include mobile devices, computers inside an organizations network, and computers outside an organizations network. These clients may or may not have VPN connections. This section describes how the SSL integrates with digital certificates for secure communications.

Objectives
After completing this section, you will be able to: Describe the SSL and digital certificates. Troubleshoot certificates.

Digital Certificates

SSL requires digital certificates. A digital certificate is a statement that is issued by a Certification Authority (CA) that vouches for the identity of the certificate holder and enables encrypted client communications. Digital certificates do the following: Authenticate that their holderspeople, websites, and network resources such as routersare truly who or what they claim to be. Protect data that is exchanged online from theft or tampering.

Digital certificates can be issued by a trusted third-party CA or the Windows public key infrastructure (PKI) by using Certificate Services. They can also be self-signed. Each certificate type has its advantages and disadvantages, and each is tamper-proof. A certificate must be signed to be valid. A self-signed certificate has limitations. For example, not all mobile devices let a user install a digital certificate in the trusted root certificate store. The ability to install certificates on a mobile device depends on the mobile device manufacturer and the mobile operator. Some manufacturers and mobile operators disable access to the trusted root certificate store. In this case, neither a selfsigned certificate nor a certificate from a Windows PKI CA can be installed on the mobile device. Most mobile devices come with several preinstalled third-party commercial certificates. For the optimal user experience, implement certificate-based authentication for Exchange ActiveSync by using devices that are running Windows Mobile 6.0 and a digital certificate from a trusted third-party CA.

Secure Sockets Layer Handshake

During a SSL handshake, the server sends the client a certificate to authenticate itself. The client uses the certificate to authenticate the identity the certificate claims to represent. A SSL-enabled client authenticates a servers identity as follows: 1. Check the server certificates validity period. If the current date and time are outside of that range, the authentication process does not go any further. 2. Verify that the issuing CA is a trusted CA. Each SSL-enabled client maintains a list of trusted CA certificates. This list determines which server certificates the client will accept. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list. 3. Validate the issuing CAs public key against the issuers digital signature thereby determining that the server certificate is valid. The client uses the public key from the CAs certificate to validate the CAs digital signature on the server certificate that is being presented. If the information in the server certificate has changed since it was signed by the CA, or if the CA certificates public key does not correspond to the private key that was used by the CA to sign the server certificate, the client does not authenticate the servers identity. 4. Verify that the domain name in the servers certificate matches the domain name of the server itself, thus confirming that the server is actually located at the same network address that is specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a man-in-the-middle attack.

Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names do not match. 5. Authenticate the server. If authentication fails at any stage, Exchange Server issues a warning and informs the user that an encrypted and authenticated connection cannot be established. For more information, see: Description of the Server Authentication Process During the SSL Handshake http://support.microsoft.com/kb/257587/EN-US/ Description of the Secure Sockets Layer (SSL) Handshake http://support.microsoft.com/kb/257591

Troubleshooting Certificates

Missing or invalid certificates can cause security leaks. As an Exchange Server administrator, you must keep the certificates updated and enabled for all required services, such as SMTP, IIS, POP3, and IMAP4. The Exchange Certificate wizard can help you create and import certificates with the correct SANs and enable them for the correct services. Run the following cmdlet to see the status and configuration of your certificates:
Get-ExchangeCertificate | format-list

The cmdlets output can help you troubleshoot your invalid certificates. In particular, pay attention to the highlighted properties shown below:
AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.Cr yptoKeyAccessRule} CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com} HasPrivateKey : True IsSelfSigned : False Issuer : CN=3rdPartyCAExample.com NotAfter : 8/7/2008 10:04:02 AM NotBefore : 8/7/2007 10:04:02 AM PublicKeySize : 2048 RootCAType : ThirdParty SerialNumber : 83FAE8B2398F2A9E44485CBA85D548DF Services : POP Status : Valid Subject : C=us,o=contoso corp, CN=fourthcoffee.com Thumbprint : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

CertificateDomains. This property may include the host name or FQDN that is used to access the server. To use a certificate, the FQDN that a client uses to connect to the server must appear on the CertificateDomains field for the certificate. Certificates support wildcard names. However, some legacy clients and mobile devices do not support wildcard names on a certificate and therefore may not support using wildcard domains. The SAN field is not exposed through Exchange Server directly. You can view it only in Certificate Manager in the Microsoft Management Console (MMC) or through IIS. IsSelfSigned. This property indicates whether a certificate is self-signed. A selfsigned certificate is usually a root certificate, which is a certificate that has no other certificates in the certificate chain. The self-signed certificate in Exchange Server usually refers to the following types of certificates: A certificate generated when Exchange Server is installed on a server where no qualifying certificate is present. A certificate that results from running the New-ExchangeCertificate cmdlet. When the Hub Transport, Edge Transport, Unified Messaging, or Client Access server roles are installed, a self-signed certificate is generated during Exchange Server setup. If a valid certificate exists in the personal certificate store on the host computer, the existing certificate will be used and the self-signed certificate generated during setup will not be used. The valid values are true or false.

NotAfter and NotBefore. These properties represent a date range in which the certificate is valid for use. If the current date falls after the NotAfter date, the certificate is considered expired. Exchange Server can use expired certificates, but the clients will generate warnings and the server will log appropriate events into the event log. RootCAType. This property identifies the type of CA that issued the certificate. If the IsSelfSigned parameter is set to true, the value of the RootCAType property should be none. Otherwise, the certificate could cause unexpected results to occur in the certificate selection process. Other possible values are: Registry. An internal, private PKI root CA that was manually installed in the certificate store. ThirdParty. A public, third-party root CA. GroupPolicy. An internal, private PKI root CA that was deployed with Group Policy. Enterprise. An internal, private PKI root CA that was deployed with AD DS. Unknown. A certificate type that could not be determined. Understanding how the root CA certificate was installed may help you diagnose inconsistent trust policies. Such inconsistencies may cause certificates to validate on some servers but not on other servers.

Services. This property identifies the services with which you can use this certificate. The valid values are SMTP, POP3, IMAP4, Unified Messaging, and IIS. Status. This property identifies whether the certificate is valid and can help you troubleshoot certificate problems. If the status for a given certificate is not valid, the certificate will not be used by the Exchange server. Values for this property include the following: Unknown. This status generally indicates that the certificate status cannot be verified because the certificate revocation list is unavailable or this server cannot connect to it. Ensure that the computer can connect to the Certificate Revocation Authority. Valid. The certificate is working correctly. Revoked. The certificate revocation list indicated that this certificate was revoked. You must generate a new certificate. DateInvalid. This status indicates that the system time is incorrect, the certificate has expired, or the time of the system that signed the file is incorrect. If the certificate has expired, you must generate a new certificate. Verify that the following conditions are true: The local computer clock is accurate. The certificate has not expired. The sending system clock is accurate.

Untrusted. This status indicates that the certificate is not self-signed. However, it is signed by a CA that is not trusted by the local computer. You must add the CA certificate to the Trusted Root Certification Authorities store on the computer. For more information about how to manually add certificates to the local certificate store, see the Help file for Certificate Manager in MMC. Invalid. Some other issue has invalidated this certificate, such as an untrustworthy, invalid, or revoked certificate somewhere in the certificate path.

Thumbprint. This property is a unique string that identifies the certificate. If the same certificate is installed on multiple Exchange servers, you can identify them by their thumbprint. The same certificate is usually installed on multiple Exchange servers when multiple Edge Transport servers are accepting mail with the same FQDN. It is more cost efficient to install the same certificate on multiple servers than to request new certificates for each server. However, the certificate must have an exportable private key.

In conclusion, inspect the output of the Get-ExchangeCertificate cmdlet to validate that the following information is true: The domain names that you expect to be present are listed for the CertificateDomains property.

The HasPrivateKey property is set to true. The RootCAType property is set correctly. The required services are enabled for the certificate. The status is set to valid.

Lab 3B: Using the Certificate Wizard

Section 9 Review

Answer the questions listed on the slide above.

Section 10: Exchange Web Services

Introduction
Exchange Web Services provides the functionality to enable client applications to communicate with the Exchange server. Exchange Web Services provides access to much of the same data that is available through Outlook. Exchange Web Services clients can integrate Outlook data into Line-of-Business (LOB) applications. SOAP provides the messaging framework for messages sent between the client application and the Exchange server. The SOAP messages are sent by HTTP. This section describes the major Exchange Web Services features that were enhanced or are new for Exchange Server 2010: The Availability Service MailTips Federated Sharing Message tracking
.

Objectives
After completing this section, you will be able to: Use the Availability Service. Use and troubleshoot MailTips. Describe Federated Sharing and message tracking. Troubleshoot Exchange Web Services.

The Availability Service

The Availability Service provides tools that can help you create enhanced Exchange Server 2010 client applications that can: Retrieve live free/busy information from Exchange Server 2007 and Exchange Server 2010 mailboxes and be configured to retrieve free/busy information for users on earlier versions. Retrieve live free/busy information from other Exchange Server 2010 forests. Retrieve published free/busy information from public folders. Retrieve suggested meeting times. Supply up-to-date free/busy data to improve scheduling tasks. Supply specific data that describes the status of users and resources, such as the start times and the end times of individual appointments, subjects, locations, and work hours. Secure the distribution of free/busy data by specifying the level of detail to share with specified users. Provide access to automatic-reply messages that users send when they are out of the office or away for an extended period of time.

In Exchange Server 2010, distribution group expansion is processed on the 2010 Exchange server instead of on the Outlook client. In Exchange Server 2007, distribution group expansion is processed on the 2007 Exchange server. Moving distribution group expansion to Exchange Server 2010 provides consistent behavior for Availability Service consumers.

In previous Exchange Server versions, the free/busy data for the distribution group members did not display when the number of users in a distribution group was too large. In Exchange Server 2010: The Availability Service expands a distribution group up to only two-levels deep, regardless of the total number of distribution group members. A distribution groups free/busy data can expand up to one hundred members.

Additionally, for each target person or group, users can select one of the following sharing levels for their calendar information: Share nothing. Share their free/busy information. Share more details including subject, location, and timing. Share full calendar details.

Availability Service Process Flow

The Availability Service process flow is: 1. Outlooks Scheduling Assistant calls Exchange Web Services GetUserAvailability function using the URL determined through the Autodiscover service. 2. The users Client Access server determines which mailboxes are local and which are in remote sites. 3. Exchange Web Services retrieves local free/busy information through MAPI RPC from the mailbox. 4. Exchange Web Services proxies remote requests to remote Client Access servers. 5. The users Client Access server combines the local and remote results and returns them to Outlook.

Overview of MailTips

MailTips are informative messages that display when users are composing messages. Exchange Server 2010 analyzes each message, including the list of recipients to which they are addressed, and if it detects a potential problem, it notifies the user with MailTips prior to sending the message. With the help of the information provided by MailTips, senders can adjust their messages to avoid undesirable situations or nondelivery reports. You can turn MailTips on or off from the client-side or the server-side. The following unproductive messaging scenarios are common in any messaging environment: Messages that violate restrictions configured in an organization, such as message size restrictions or maximum number of recipients per message. Messages sent to recipients that do not exist, are restricted, or have full mailboxes. Messages to users who use automatic replies.

To support MailTips, the offline address book includes the following properties for each recipient: Message delivery restrictions. Custom MailTips. Maximum receive size. Moderation enabled.

For distribution groups, the offline address book includes the total member count and the external member count.

MailTips in Complex Topologies


MailTips that rely on recipient mailbox data are evaluated by making a connection to the Mailbox servers that hold the recipients. The mailbox full and automatic reply MailTips fall under this category. For these MailTips, the Client Access server directly queries the Mailbox server using RPC, but only if the recipients reside in the same site. For recipients that reside in other sites or forests, this information is gathered through serverto-server Internet requests between Client Access servers.

Group Metrics
Group metrics refer to the total-size and external-recipients counts for distribution lists. The Microsoft Exchange Service Host service measures the groups and writes the metrics to a file, which is then copied to Client Access servers by the Microsoft Exchange File Distribution service. The MailTips web service looks up audience size information from these files.

MailTips Limitations
MailTips are subject to the following limitations: MailTips are not supported when you are working in offline mode. When a message is addressed to a distribution group, the MailTips for individual recipients that are members of that distribution group are not evaluated. However, if any of the members are external recipients, the external recipients MailTips are displayed, which shows the sender the number of external recipients in the distribution group. If the message is addressed to more than 200 recipients, individual mailbox MailTips are not evaluated due to performance reasons. Customized MailTips are limited to 250 characters. If the sender starts composing a message and leaves it open for an extended period of time, the automatic reply and mailbox full MailTips are evaluated every two hours.

MailTips Evaluation

Exchange Server evaluates MailTips as follows: 1. The mail client queries Exchange Web Services on the Client Access server for MailTips that apply to the recipients in the message. 2. The Client Access server gathers MailTips data: A. The Client Access server queries AD DS and reads group metrics data. B. If the recipient is a mailbox that is located on a Mailbox server in the local site, the Client Access server queries the Mailbox server to gather the automatic reply and mailbox full MailTips. If the recipients mailbox is on another site, the Client Access server requests MailTips information from the Client Access server in the remote site. C. The Client Access server in the remote site queries the local Mailbox server for MailTips data. D. The remote Client Access server proxies the results back to the requesting Client Access server. 3. The Client Access server returns MailTips data back to the client. Exchange Server 2010 Client Access servers that access 2007 Mailbox servers only return Active Directory-based MailTips. Mailbox-based tips are not supported due to changes in the Exchange Server Object (XSO) that prevent access to 2007 Mailbox servers. Exchange Server 2007 Client Access servers do not support MailTips. Depending on your Exchange Server versions, the types of MailTips available are:

Client Access Server Version Accessed Exchange Server 2010

Mailbox Server Version Accessed Exchange Server 2010

Types of MailTips Available All mailbox and Active Directorybased MailTips

Exchange Server 2010

Exchange Server 2007

Active Directory-based MailTips

Exchange Server 2007

Exchange Server 2010

No support for MailTips

MailTips Organizational Settings Configuration

The following examples show how to perform common MailTips tasks. Example 1 To enable MailTips:
Set-OrganizationConfig -MailTipsAllTipsEnabled $true

Example 2 To configure a large audience size for your organization:


Set-OrganizationConfig MailTipsLargeAudienceThreshold 50

Example 3 The external recipients MailTips is disabled by default. To enable this MailTips:
Set-OrganizationConfig -MailTipsExternalRecipientsTipsEnabled $true

Example 4 To enable MailTips that rely on mailbox data:


Set-OrganizationConfig -MailTipsMailboxSourcedTipsEnabled $true

Example 5 To enable MailTips that rely on group metrics data:


Set-OrganizationConfig -MailTipsGroupMetricsEnabled $true

Example 6 To configure custom MailTips:

Set-Mailbox -Identity "Help Desk" -MailTip "A Help Desk representative will contact you within 2 hours."

Set-DistributionGroup -Identity "HR" -MailTip "This distribution group is used for Human Resources departmental communications. If you want to contact an HR representative, please e-mail HRQuestions@contoso.com."

Troubleshooting MailTips

MailTips aggregates information from many sources in a way that presents potentially complicated back-end situations in a simple manner. This does mean, however, that you may need to look in various places to troubleshoot MailTips.

Caches
MailTips caches data at many levels on the server and on clients. Sometimes the only problem is that a cache has yet to be updated. Restarting clients such as Outlook or Outlook Web Appand sometimes services such as IISmay solve the problem. Additionally, group metrics only update every night, so keep this in mind when you see group metrics-based tips.

Problem Limited to Outlook Clients


If MailTips works as expected in Outlook Web App, but Outlook does not display MailTips, the problem might be related to the Autodiscover service. Outlook uses Autodiscover to find the URL for Exchange Web Services. Exchange Web Services retrieves MailTips data. If Autodiscover is not working, or if the Exchange Web Services URL provided by Autodiscover is incorrect, then Outlook cannot contact the MailTips web service.

Problem Limited to Only Some MailTips


MailTips determines whether a recipient is internal or external by comparing the domain of the ExternalEmailAddress propertywhich corresponds to the targetAddress attribute in AD DSwith the list of accepted domains. At times, external recipients MailTips may appear for internal recipients whose email is hosted on a system that is not on the accepted-domain list. In general, the solution is simply to add the domain to the accepteddomain list.

The Set-OrganizationConfig cmdlet has options that allow you to disable group metricsbased and mailbox-based MailTips, so it is worth checking those, too. Automatic reply MailTips are only available for recipients whose mailboxes reside on Exchange Server 2010 Mailbox servers.

Problem Limited to Group Metrics-Based MailTips


Group metrics periodically count the members of all groups on Mailbox servers and use Exchange Server file distribution to send the group metrics files to the Client Access servers. To begin troubleshooting, look for the file sharesuch as \\mailboxserver\GroupMetrics that contains your group metrics data. If you do not see a group metrics file share on a Mailbox server, Exchange Server is not generating group metrics. By default, Exchange Server generates group metrics each night at a random time within two hours of midnight. It generates the group metrics on Mailbox servers that generate offline address books. Use the Set-MailboxServer cmdlet to specify when to generate group metrics data. You must use the 24-hour clock notation (HH:MM) when specifying the generation time. The following examples specify to generate group metrics on servers MBX1 and MBX3 at 11:30 p.m. and 3:00 a.m., respectively.
Set-MailboxServer MBX1 -GroupMetricsGenerationTime 23:30 Set-MailboxServer MBX3 -GroupMetricsGenerationTime 03:00

If you do not use offline address books, then you must explicitly specify where you want group metrics to be generated with the following cmdlet:
Set-MailboxServer <server> -ForceGroupMetricsGeneration $true

Note: This cmdlet is only useful for organizations that do not use offline address books. If a Mailbox server generates an offline address book, it also generates group metrics regardless of this setting.

Verify that the files within the group metrics file share have updated within the past 24 hours. Restarting the Microsoft Exchange Service Host generates a fresh file. The process may take minutes or hours depending on the number of groups in your organization. Ensure that the Microsoft Exchange File Distribution service is running on the Client Access servers and Mailbox servers, and that your Client Access servers can connect to the group metrics file share.

Enabling Outlook MailTips Logging

Client-side logging can help you troubleshoot MailTips issues by isolating whether the problem is related to the Outlook client or the Client Access server. Outlook 2010like Outlook 2007generates log files that can help you troubleshoot Outlook connectivity issues. Once enabled, the logs record the exchange of SOAP messages between the Outlook client and the Client Access servers. To enable diagnostic logging on your Outlook 2010 client, do the following: 1. Click the Office icon, click Outlook, and then click Options. 2. In the Outlook Options dialog box, click Advanced. 3. Under Other, check the Enable troubleshooting logging (requires restarting Outlook) option. 4. Exit and restart Outlook. After troubleshooting, disable client-side logging.

MailTips Log Files

MailTips log files are stored in the %LocalAppData%\Local\Temp\Outlook Logging directory on the Outlook client machine. This directory contains the following log files:
Log Name YYYYMMDD-<Time Stamp>-OOF.log YYYYMMDD-<Time Stamp>-MailTips.log FirstRun.log <user@domain.com>.ost.log OPMLog.log Description Out-of-facility troubleshooting log MailTips troubleshooting log Outlook steps performed during first startup Offline storage log Outlook program log

Exchange Server generates at least two log files. One log file contains the initial service configuration information downloaded to the client upon startup. The other contains the MailTips evaluation for the recipient addressed on the message. The easiest way to identify the log of interest is to sort the logs by the modified date. Usually the first mailtips.log file is the one that contains the initial MailTips configuration request. Look for the Request Action line. It should contain one of the following entries: GetServiceConfiguration. Contains the request to Exchange Web Services for the general MailTips configuration settings. GetMailtips. Contains the request for MailTips for one or more recipients.

GetServiceConfiguration Log File


The following example shows the MailTips configuration settings request format:

2009/06/25 17:05:45.415: Request to URL: https://ex02.contoso.com/EWS/Exchange.asmx 2009/06/25 17:05:45.415: Request action: http://schemas.microsoft.com/exchange/services/2006/messages/GetServiceConfigurati on 2009/06/25 17:05:45.415: Request XML: <?xml version="1.0"?> <q:Envelope xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/"> <q:Header> <ex12t:RequestServerVersion Version="Exchange2010"> </ex12t:RequestServerVersion> </q:Header> <q:Body> <ex12m:GetServiceConfiguration> <ex12m:ActingAs> <ex12t:EmailAddress>Administrator@contoso.com</ex12t:EmailAddress> <ex12t:RoutingType>SMTP</ex12t:RoutingType> </ex12m:ActingAs> <ex12m:RequestedConfiguration> <ex12m:ConfigurationName>MailTips</ex12m:ConfigurationName> </ex12m:RequestedConfiguration> </ex12m:GetServiceConfiguration> </q:Body> </q:Envelope> 2009/06/25 17:05:45.415: Sending request 2009/06/25 17:05:45.930: Request sent 2009/06/18 16:33:42.797: Request to URL: https://ex02.contoso.com/EWS/Exchange.asmx 2009/06/18 16:33:42.797: Request action: http://schemas.microsoft.com/exchange/services/2006/messages/GetServiceConfigurati on2009/06/18 16:33:42.797: Request XML: <?xml version="1.0"?> <q:Envelope xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/"> <q:Header> <ex12t:RequestServerVersion Version="Exchange2010"> </ex12t:RequestServerVersion> </q:Header> <q:Body> <ex12m:GetServiceConfiguration> <ex12m:ActingAs> <ex12t:EmailAddress>Mod1User1@contoso.com</ex12t:EmailAddress> <ex12t:RoutingType>SMTP</ex12t:RoutingType> </ex12m:ActingAs> <ex12m:RequestedConfiguration> <ex12m:ConfigurationName>MailTips</ex12m:ConfigurationName> </ex12m:RequestedConfiguration> </ex12m:GetServiceConfiguration> </q:Body> </q:Envelope>2009/06/18 16:33:42.797: Sending request2009/06/18 16:33:42.922: Request sent2009/06/18 16:33:42.922: Response error code: 00000000 2009/06/18 16:33:42.922: HTTP status code: 200 2009/06/18 16:33:42.922: XML response:<?xml version="1.0" encoding="utf-8"?>

The following example shows the MailTips configuration settings response format:
2009/06/25 17:05:45.930: Response error code: 00000000 2009/06/25 17:05:45.930: HTTP status code: 200 2009/06/25 17:05:45.930: XML response:<?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Header> <h:ServerVersionInfo MajorVersion="14" MinorVersion="0" MajorBuildNumber="621" MinorBuildNumber="0" Version="Exchange2010" xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/> </s:Header> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <GetServiceConfigurationResponse ResponseClass="Success" xmlns="http://schemas.microsoft.com/exchange/services/2006/messages"> <ResponseCode>NoError</ResponseCode> <ResponseMessages> <ServiceConfigurationResponseMessageType ResponseClass="Success"> <ResponseCode>NoError</ResponseCode> <m:MailTipsConfiguration xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"> <t:MailTipsEnabled xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">true</t:MailTi psEnabled> <t:MaxRecipientsPerGetMailTipsRequest xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">50</t:MaxRecip ientsPerGetMailTipsRequest> <t:MaxMessageSize xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">10485760</t:Ma xMessageSize> <t:LargeAudienceThreshold xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">25</t:LargeAud ienceThreshold> <t:ShowExternalRecipientCount xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">false</t:ShowE xternalRecipientCount> <t:InternalDomains xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"> <t:Domain Name="contoso.com" IncludeSubdomains="false"/> </t:InternalDomains> </m:MailTipsConfiguration> </ServiceConfigurationResponseMessageType> </ResponseMessages> </GetServiceConfigurationResponse> </s:Body> </s:Envelope>

Tip: To improve readability, open the client log files using Microsoft Office Word and perform a search to replace >< with >^p<. This will add returns to the log file, making it easier to read.

GetMailTips Log File


The following example shows the MailTips request format:
2009/06/25 17:06:17.056: Request to URL: https://ex02.contoso.com/EWS/Exchange.asmx 2009/06/25 17:06:17.056: Request action: http://schemas.microsoft.com/exchange/services/2006/messages/GetMailTips 2009/06/25 17:06:17.056: Request XML: <?xml version="1.0"?> <q:Envelope xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/"> <q:Header> <ex12t:RequestServerVersion Version="Exchange2010"> </ex12t:RequestServerVersion> </q:Header> <q:Body> <ex12m:GetMailTips> <ex12m:SendingAs> <ex12t:EmailAddress>Administrator@contoso.com</ex12t:EmailAddress> <ex12t:RoutingType>SMTP</ex12t:RoutingType> </ex12m:SendingAs> <ex12m:Recipients> <ex12t:Mailbox> <ex12t:EmailAddress>Mod1User1@contoso.com</ex12t:EmailAddress> <ex12t:RoutingType>SMTP</ex12t:RoutingType> </ex12t:Mailbox> </ex12m:Recipients> <ex12m:MailTipsRequested>OutOfOfficeMessage MailboxFullStatus CustomMailTip ExternalMemberCount TotalMemberCount MaxMessageSize DeliveryRestriction ModerationStatus InvalidRecipient </ex12m:MailTipsRequested> </ex12m:GetMailTips> </q:Body> </q:Envelope> 2009/06/25 17:06:17.056: Sending request 2009/06/25 17:06:20.727: Request sent

The following example shows the MailTips request response format:


2009/06/25 17:06:20.727: Response error code: 00000000 2009/06/25 17:06:20.727: HTTP status code: 200 2009/06/25 17:06:20.727: XML response:<?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Header> <h:ServerVersionInfo MajorVersion="14" MinorVersion="0" MajorBuildNumber="621" MinorBuildNumber="0" Version="Exchange2010" xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/> </s:Header> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <GetMailTipsResponse ResponseClass="Success" xmlns="http://schemas.microsoft.com/exchange/services/2006/messages"> <ResponseCode>NoError</ResponseCode> <ResponseMessages>

<MailTipsResponseMessageType ResponseClass="Success"> <ResponseCode>NoError</ResponseCode> <m:MailTips xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"> <t:RecipientAddress xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"> <t:Name/> <t:EmailAddress>Mod1User1@contoso.com</t:EmailAddress> <t:RoutingType>SMTP</t:RoutingType> </t:RecipientAddress> <t:PendingMailTips xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"/> <t:OutOfOffice xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"> <t:ReplyBody xml:lang="en-us"> <t:Message>&lt;div&gt;&amp;#65279;&lt;style&gt;&#xD; &lt;!--&#xD; p.x_MsoNormal, li.x_MsoNormal, div.x_MsoNormal&#xD; {margin:0in;&#xD; margin-bottom:.0001pt;&#xD; font-size:11.0pt;&#xD; font-family:"Calibri","sans-serif"}&#xD; span.x_MsoHyperlink&#xD; {color:blue;&#xD; text-decoration:underline}&#xD; span.x_MsoHyperlinkFollowed&#xD; {color:purple;&#xD; text-decoration:underline}&#xD; span.x_EmailStyle17&#xD; {font-family:"Tahoma","sans-serif"}&#xD; .x_MsoChpDefault&#xD; {font-family:"Calibri","sans-serif"}&#xD; div.x_Section1&#xD; {}&#xD; --&gt;&#xD; &lt;/style&gt;&#xD; &lt;div class="x_Section1"&gt;&#xD; &lt;p class="x_MsoNormal" style="text-autospace:none"&gt;&lt;span style="fontsize:8.5pt; font-family:&amp;quot;Tahoma&amp;quot;,&amp;quot;sansserif&amp;quot;"&gt;I will be out of the office on 7/4/2009&lt;/span&gt;&lt;/p&gt;&#xD; &lt;/div&gt;&#xD; &lt;/div&gt;</t:Message> </t:ReplyBody> </t:OutOfOffice> <t:MailboxFull xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">false</t:Mailb oxFull> <t:CustomMailTip xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"/> <t:TotalMemberCount xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">1</t:TotalMemb erCount> <t:ExternalMemberCount xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">0</t:ExternalM emberCount>

<t:MaxMessageSize xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">10485760</t:Ma xMessageSize> <t:DeliveryRestricted xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">false</t:Deliv eryRestricted> <t:IsModerated xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">false</t:IsMod erated> <t:InvalidRecipient xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">false</t:Inval idRecipient> </m:MailTips> </MailTipsResponseMessageType> </ResponseMessages> </GetMailTipsResponse> </s:Body> </s:Envelope>

Federated Sharing

Federated Sharing allows users to securely share informationfree/busy availability, calendar, contacts, and so onwith recipients external to their organizations. Federated Sharing uses federation. Exchange Server 2010 uses the Microsoft Federation Gateway, an identity service that functions over the Internet and beyond your corporate network domain. Exchange Server organizations wanting to use federation establish a federation trust with the Microsoft Federation Gateway, allowing it to become a federation partner to the Exchange Server organization. To do this, you must request an X.509 SSL certification from a CA trusted by Windows Live. The trust allows users authenticated by AD DSknown as the identity providersto be issued Security Assertion Markup Language (SAML) delegation tokens by the Microsoft Federation Gateway. These tokens allow users from one federated organization to be trusted by another federated organization. With the Microsoft Federation Gateway acting as the trust broker, organizations are not required to establish multiple individual trust relationships with other organizations. Users can access external resources using a single sign-on (SSO) experience.

Message Tracking

Using the Exchange Control Panel in combination with Exchange Web Services message tracking allows you to track the delivery path a message took within the organization. Message tracking runs on the Client Access server and allows message tracking between servers in the same site and across sites. When tracking the message path in the same site as the server, the message tracking service uses RPC calls to retrieve the tracking log data from the Hub Transport servers. When tracking a message between sites, the Client Access server in the source site issues a web call to the message tracking service on the Client Access server in the target site. The Client Access server in the target site then retrieves the requested log information and returns it to the requesting server.

Microsoft Exchange Transport Log Search Service Indexing


In both Exchange Server 2007 and Exchange Server 2010, message tracking information is written to comma-separated values (CSV) files on the Hub Transport and Mailbox servers. In Exchange Server 2007, searching the message tracking logs could be timeconsuming because of the large file sizes and the lack of indexing. In Exchange Server 2010, the Microsoft Exchange Transport Log Search service indexes message ID and address information from the message tracking log. This results in faster log searches. For more details about how message tracking indexing works, refer to Module 4.

Tracking Message Latency


Exchange Server 2010 contains service level agreement (SLA) instrumentation and reporting features that allow administrators to easily monitor the health of their Exchange servers, whether Client Access servers or Hub Transport servers: Delivery latency (end-to-end latency) Server component latency Historical reporting of message statistics

Message tracking records both delivery latency and component latency within the organization. Intra-organizational delivery latency is measured from the point of entry into the organization based on trusted (internal) server IP ranges defined in the organization. Message header information is utilized to transmit latency information between servers. Each Hub Transport server that the message traverses records server latency and uses the information from the previous server to calculate the total latencythat is, how long it takes to deliver a message. The resulting information is stored within the message tracking log file. For more information about message latency, refer to Module 4.

Troubleshooting Exchange Web Services

In addition to using diagnostic logging as one of your basic troubleshooting tools, troubleshooting Exchange Web Services connectivity issues should begin with a review of the settings in the Exchange Web Services virtual directory that is stored in IIS. This virtual directory is installed under the default website during Client Access server role installation. Use the Get-WebServicesVirtualDirectory cmdlet to review the current Exchange Web Services settings. The default settings for the Exchange Web Services virtual directory are:
RunspaceId : 8af51d58-c6e7-4293-9a22-91bc02fc3ac8 CertificateAuthentication : True InternalNLBBypassUrl : https://EX02.contoso.com/ews/exchange.asmx GzipLevel : High Name : e (Default Web Site) InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : False DigestAuthentication : False WindowsAuthentication : True MetabasePath : IIS://EX02.Contoso.com/W3SVC/1/ROOT/EWS Path : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\EWS Server : EX02 InternalUrl : https://EX02.contoso.com/EWS/Exchange.asmx ExternalUrl : AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0)

DistinguishedName : CN=EWS (Default Web Site),CN=HTTP,CN=Protocols,CN=EX02,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso, DC=com Identity : EX02\EWS (Default Web Site) Guid : 463e5cd3-f128-44da-9e44-a1639e312fa2 ObjectCategory : Contoso.com/Configuration/Schema/ms-Exch-WebServices-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchWebServicesVirtualDirectory} WhenChanged : 5/22/2009 1:33:17 PM WhenCreated : 5/22/2009 1:33:17 PM WhenChangedUTC : 5/22/2009 8:33:17 PM WhenCreatedUTC : 5/22/2009 8:33:17 PM OrganizationId : OriginatingServer : EX02.Contoso.com IsValid : True

The following table summarizes the common default Exchange Web Services settings.
Critical: Do not use the IIS console to modify the Exchange Web Services virtual directory. Instead, use the Exchange Management Shell and the SetWebServicesVirtualDirectory cmdlet to modify virtual directory settings.

Setting BasicAuthentication

Description

Default Value

Specifies whether basic authentication is $false enabled on the Exchange Web Services virtual directory. You can use this parameter with the DigestAuthentication and WindowsAuthentication parameters. Specifies whether certificate authentication $true is enabled. This parameter affects the <Servername>/ews/management/ virtual directory. It does not affect the <Servername>/ews/ virtual directory. Specifies whether digest authentication is enabled on the virtual directory. $false

Certificate Authentication

DigestAuthentication ExternalUrl

Specifies the host name used to connect to $null / blank the Exchange server from outside the firewall. This setting is also important when you use SSL. Identifies the Gzip compression configuration for the Exchange Web Services virtual directory. High

GzipLevel

InternalNLBBypassUrl

Specifies the URL of the Client Access HTTPS://<CAS server, regardless of whether it is behind a FQDN>/ews/ NLB array. Although the InternalUrl exchange.asmx parameter is set to the URL of the NLB array, the InternalNLBBypassUrl parameter should always be set to the URL of the Client Access server. This is because certain Exchange Web Services calls

Setting

Description require machine affinity, and Exchange Web Services proxies incoming calls to a more appropriate Client Access server whenever possible.

Default Value

InternalUrl

Specifies the host name of the Exchange HTTPS://<CAS server for a connection from inside the FQDN>/ews/ firewall. This setting is also important when exchange.asmx you use SSL. This parameter is not supported on the Exchange Web Services virtual directory. This parameter is reserved for internal Microsoft use. $false $false

LiveIDBasicAuthentication LiveIDSpNego Authentication WindowsAuthentication

Specifies whether Integrated Windows $true authentication is permitted on the Exchange Web Services virtual directory. Specifies whether security authentication is $true enabled on the Exchange Web Services virtual directory. You can use this parameter with BasicAuthentication, DigestAuthentication, and WindowsAuthentication.

WSSecurityAuthentication

Recreating the Exchange Web Services Virtual Directory

The IIS metabase that stores the Exchange Web Services virtual directory can become corrupt, which can affect a clients ability to retrieve and display MailTips. To correct this situation, it may be necessary to remove and recreate the Exchange Web Services virtual directory. Removing and recreating the virtual directory should not be your first troubleshooting step, but you can employ this solution after you have exhausted all other troubleshooting methods. The following sections outline the steps necessary to remove and recreate the virtual directory. Before changing the IIS configuration, create a backup copy of the IIS server configuration, which also backs up the IIS metabase.

Backing Up and Restoring the IIS Configuration


Backup and restore the IIS configuration as follows: 1. Click Start, right-click Command Prompt, and then select Run as Administrator. 2. Change the directory to C:\Windows\System32\inetsrv 3. Backup the IIS metabase with the following cmdlet:
Appcmd Add Backup Name of Backup

4. Verify that the backup was created properly with the following cmdlet:
Appcmd List Backup

Note: IIS automatically generates history snapshots of ApplicationHost.config each time a change is detected, enabling you to easily restore to a prior version. By default, IIS checks for a new version every 2 minutes, and saves 10 prior versions

of the file. IIS7 stores these snapshots in the %systemdrive%\inetpub\history folder.

5. To restore the backup, use the following cmdlet:


Appcmd Restore Backup Name of Backup

Removing and Recreating the Exchange Web Services Virtual Directory


After backing up IIS, remove and recreate the Exchange Web Services virtual directory as follows: 1. Start the Exchange Management Shell on the Client Access server. 2. Remove the Exchange Web Services virtual directory with the following cmdlet:
Remove-WebServicesVirtualDirectory Identity <servername>\ExchWeb (Default Web Site)" Confirm: $false

3. Verify that the virtual directory was removed with the following cmdlet:
Get-WebServicesVirtualDirectory

4. Recreate the Exchange Web Services virtual directory with the following cmdlet:
New-WebServicesVirtualDirectory -WebsiteName "EWS (Default Web Site) -InternalUrl "https://Sites/EWS/Exchange.asmx" -basicauthentication 1 -windowsauthentication 1

5. Verify that you created the Exchange Web Services virtual directory with the following cmdlet:
Get-WebServicesVirtualDirectory

6. Run the following commands to disable kernel mode authentication on the Exchange Web Services virtual directory:
cd $env:windir\system32\inetsrv Appcmd.exe Unlock Config "-section:system.webserver/security/ authentication/windowsauthentication" Appcmd.exe Set Config "Default Web Site/ews" "-section:windowsAuthentication" "-useKernelMode:False" /commit:apphost

7. Restart IIS by running the following command:


Run IISReset /noforce

Critical: Do not use the IIS console to manually remove these virtual directories. This can cause problems when you try to recreate the directories. Instead, use the Exchange Management Shell and the commands listed in this section to remove and recreate the Exchange Web Services virtual directory.

Lab 3C: Configuring and Testing MailTips in Exchange Server 2010

Section 10 Review

Answer the questions listed on the slide above.

Module 3 Summary

This module described the Client Access Server role for Exchange Server 2010.