Programming4us
         
 
 
Applications Server

Client Access Server Architecture in Exchange 2010 (part 2)

10/18/2010 9:57:38 AM

3. New Features

This section introduces several of the new or improved Client Access Server features.

3.1. Outlook Web App (OWA)

OWA has been renamed from Outlook Web Access in previous versions of Exchange. OWA allows users to access their mailboxes using a large number of Web browsers, including Internet Explorer 6.0+, Firefox, Safari, and Chrome. As with each new version of Exchange Server, OWA includes more enhancements and comes even closer to the full client experience. The following list highlights several of the new features:

  • Conversation View

  • MailTips

  • Instant Messaging Integration with OCS 2007 R2

  • Predefined Search Filters for quick search of folder contents

  • Enhanced Right-Click

  • Attach messages to messages

Another notable change is with OWA policies. Past versions of Exchange applied OWA policies against the IIS virtual directory. In Exchange 2010, the policy settings are now created at a global level, and can be applied per user. A default policy is created during role installation, but it is not applied to any mailboxes. The default policy enables all the options. OWA policies can be applied during a new user creation, or later on with the Set-CasMailbox cmdlet or EMC.

Service Pack 1 introduces a new look and feel to simplify the UI and provide a clean view that emphasizes content. The new interface scales well with different screen sizes and resolutions, particularly for Netbooks. Figure 2 shows an example of the new interface.

Figure 2. OWA SP1


Part of the new OWA experience is an updated options menu. The most frequently accessed options are now displayed in a drop-down menu, as shown in Figure 3. Additionally, users now have the ability to apply a theme to OWA.

Figure 3. OWA themes


A very welcome addition in Service Pack 1 is the ability to print custom calendars in OWA. Users can view a printable calendar in Daily/Weekly/Monthly/Agenda views.

3.2. RPC Client Access

One of the major new architectural changes in Exchange 2010 is how RPC (or MAPI) clients access their mailbox and directory information. Figure 4 illustrates the new Exchange 2010 RPC architecture.

Figure 4. RPC Client Access changes


Previously, RPC clients such as Microsoft Outlook made a connection directly to the server running the Mailbox role. In Exchange 2010, the Client Access Server handles the task of processing all RPC requests in place of the Mailbox server. This is not 100-percent true because public folder connections still require direct connections to a Mailbox Server role after being authenticated with the Client Access Server, but these connections still use the Microsoft Exchange RPC Client Access Service on the Mailbox server.

These changes result in several benefits. The first advantage is that all Client Access uses a common route for mailbox access shown in Figure 4-5. This allows for consistent application of business logic and rules regardless of the client. Previously, clients either behaved differently or redundant code sat on multiple tiers. Features that take advantage of change include the Calendar Repair Assistant and the content conversion code.

Figure 5. Middle tier


The second benefit of channeling client connections through a common path is that it makes more efficient use of network connections, and provides better scaling (more users per mailbox server). Using a 64-bit operating system allowed Exchange 2007 to scale better than previous versions. Removing the traditional bottlenecks (such as memory) allowed new bottlenecks to appear. TCP connections became a limiting factor when trying to scale mailbox servers to large numbers of users. A connection is made up from the source IP address, source port, destination IP address, and destination port. A common issue occurred between the Client Access server and the Mailbox server. On Windows 2003, the Client Access server can use only a single source port per IP address when making an outbound connection to another computer. After the source port has been used, it is not available for any other outbound connections on the server. This becomes an issue when large numbers of connections are required, such as when Outlook Anywhere is heavily used. This was addressed in Windows 2008 by allowing the source port to be used once per source IP address. By adding additional IP addresses, the Client Access server could scale past 60,000 connections. However, DSProxy—used to provide directory access to Outlook clients when connected over Outlook Anywhere—did not take advantage of this change, and was still limited to 60,000 outbound connections to global catalog servers. Figure 6 shows the Exchange 2007 connection architecture and where the TCP connection limitations were.

Figure 6. Exchange 2007 Client Access scale


Compare this to the Exchange 2010 situation shown in Figure 7. The Client Access server now disconnects the user's connection and saves its session state information. Instead of maintaining a connection for each user between the Client Access server and Mailbox server, there is a shared pool of 100 connections. If the user's connection is not active, it just stays in a disconnected state. This design allows for the Client Access server to scale better without having to add additional NICs. The number of shared connections is not configurable or exposed to administrators, and Microsoft did significant testing during product development that suggests companies will not need to change this value. Even though Figure 4-7 shows a Client Access Array, this mechanism operates in the same way with a single Client Access server.

Figure 7. Exchange 2010 Client Access Scale


This architectural change also impacts directory access. The Client Access server now implements the Address Book Service to replace the DSProxy interface on servers with the Mailbox role. In Exchange 2000 through 2007, DSProxy was a true proxy and the global catalog provided the NSPI endpoint when clients connected using Outlook Anywhere. In Exchange 2010, the Client Access server is the endpoint and makes calls on behalf of the client to the global directory. Why the significant change? The DSProxy implementation caused a few issues. One concerned Outlook Anywhere and split connections, described in detail later in this chapter. At a high level, split connections could cause a user with Outlook Anywhere to end up with directory service calls being dropped.

Another common issue was that Outlook frequently connected to a domain controller that did not hold a writable copy of a group that users wanted to manage so they got errors when trying to perform group management. Several changes were implemented over the years to address multi-domain DL updates, but the only completely effective solution was to move all users and distribution lists to the same domain. For most companies, this is simply not possible, so they end up creating a complete group management portal, or using operations processes to control user requests. The Address Book Service detects modification of DL membership, delegate management, and certificate management and calls the appropriate cmdlets to make the necessary changes on a domain controller that has a writeable copy of the object. The service uses RBAC security to ensure that the user has the required permissions to make the change. Another great benefit of the Address Book Service is that future reads from the client session go to the same domain controller and the change is reflected immediately.

Previously, users hidden from the Global Address List (GAL) could not create profiles. The changes in Exchange 2010 also solve this known issue. Now, users can create a profile whether or not they are hidden from the GAL.

Finally, moving Client Access helps with faster and more seamless failovers, because the client maintains a connection with the Client Access server, the client is not aware of which mailbox server is hosting the active database. Therefore, it is possible to failover a single database instead of requiring the entire storage group, as in Exchange 2007. Microsoft's target failover time before users are reconnected to their mailboxes in Exchange 2010 is fewer than 30 seconds; CCR was about 2 minutes.


Other -----------------
- Exchange Server 2010 Mailbox Services Configuration (part 5) - Configuring Public Folders
- Exchange Server 2010 Mailbox Services Configuration (part 4) - Client Configuration
- Exchange Server 2010 Mailbox Services Configuration (part 3)
- Exchange Server 2010 Mailbox Services Configuration (part 2) - Database Maintenance
- Exchange Server 2010 Mailbox Services Configuration (part 1)
- Exchange Server 2007: Monitor Your Exchange Environment (part 4) - Microsoft Operations Manager (MOM 2005)
- Exchange Server 2007: Monitor Your Exchange Environment (part 3) - Performance Troubleshooter
- Exchange Server 2007: Monitor Your Exchange Environment (part 2)
- Exchange Server 2007: Monitor Your Exchange Environment (part 1)
- Use the Exchange 2007 Toolbox to Troubleshoot
 
 
Most View
- Microsoft SQL Server 2008 R2 : Setting Up Replication (part 2) - Creating a Publication
- Developing an SEO-Friendly Website : Creating an Optimal Information Architecture (part 2)
- jQuery 1.3 : Working with numeric form data (part 6) - Finishing touches
- Windows Phone 7 : Working with the Calendar - Deleting Appointments
- Windows 7 : Managing a User Account - Limiting Computer Access
- SQL Server Integration Services : The Package Execution Utility (part 2) - Running Packages
- An OLAP Requirements Example: CompSales International (part 13) - Cube Perspectives
- Microsoft ASP.NET 3.5 : Web Services for ASP.NET AJAX Applications (part 1) - Remote Calls via Web Services
- Windows Small Business Server 2011 : Deploying SQL Server 2008 R2 for Small Business
- Processing and Storing Data in SQL Server 2005 : Data Migration from One Data Store to Another Data Store
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS