Exchange Server's Client Access: Deploying Your Servers

In Exchange Server 2010, the Client Access server role plays a much larger part in the messaging organization than in any previous version. Because of this, it’s critical to deploy the Client Access Server correctly up front and avoid any unnecessary or unplanned downtime. In my last article, "Exchange Server's Client Access: An Introduction," I provided an introduction to the Client Access server role in Microsoft Exchange Server 2010 and Exchange 2007. In this article, I'll expand on that topic and talk about deploying and installing Client Access server. I'll focus on Exchange Server 2010, but I'll point out the differences for Exchange 2007 as I go. I'll walk you through a manual, GUI-based installation and an unattended installation, as well as discuss the prerequisites. I'll wrap up by looking at coexistence and transition, including transitioning to the Exchange 2010 Client Access server from older versions of Exchange, and how to ensure that multiple versions of the Client Access server live in harmony.

Prerequisites

Before installing the Client Access server role, make sure your server meets the prerequisites. I prefer to install prerequisites in a scriptable, repeatable manner that requires as little administrator interaction as possible. Therefore, I'll supply the commands you need to install the prerequisites rather than use the GUI. Table 1 outlines the prerequisites; note that they differ between Exchange 2007 and Exchange 2010. The .NET Framework, Windows PowerShell, and Windows Remote Management (WinRM) are baseta system requirements for Exchange. The web server and remote procedure call (RPC) over HTTP requirements are specifically for the Client Access server role.

Table 1: Software Prerequisites for Installing the Client Access Server Role

When installing Exchange 2010 on Windows Server 2008, you'll need to download the .NET Framework 3.5 SP1 from the Microsoft website at www.microsoft.com/downloads/details.aspx?FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7 and install it separately. You can install the framework without user interaction by running the executable you download with the /passive switch. The installation still displays status dialog boxes so you can see its progression.

The .NET Framework 3.5 SP1 is included as a feature that you can add in Server 2008 R2. You can install it using the Add Features option in Server Manager or with PowerShell. To install it using PowerShell, you first have to open PowerShell with the system modules loaded, which you do by right-clicking the PowerShell application and selecting Import system modules, as Figure 1 shows. Note that this option isn't available to you until you've run PowerShell at least once as the current user. After you've imported the system modules, use the command

Add-WindowsFeature Net-Framework-Core

Figure 1: Importing system modules in PowerShell

PowerShell 2.0 and WinRM are already installed in Server 2008 R2, so there are no additional steps to get those components working, but you need to install them in Server 2008. Microsoft offers PowerShell 2.0 and WinRM packaged into a single download called the Windows Management Framework Core, available from support.microsoft.com/kb/968929. You only need the Core version of the framework, not the other downloads on that page. Install the update silently using the command

Windows6.0-KB968930-x64.msu /quiet

After you install the correct version of the .NET Framework and PowerShell, you'll need to make sure the following components are installed before you can install the Client Access server role on your server:

You don't have to install each of these components through the Server Manager interface—the Exchange team provides a much easier way. There's a set of XML files in the Scripts folder on the Exchange DVD. The Exchange-CAS.xml file contains the Server Manager packages that you need for the Client Access server role. You can install these packages using the command

ServerManagerCmd.exe -ip d:scriptsExchange-CAS.xml

ServerManagerCmd.exe is deprecated in Server 2008 R2, so it may not be there in future versions. To install the packages without ServerManagerCmd, use the Add-WindowsFeature PowerShell cmdlet:

Add-WindowsFeature NET-Framework, NET-HTTP-Activation, RPC-Over-HTTP-Proxy,RSAT-ADDS, Web-Server,Web-Basic-Auth, Web-Windows-Auth,Web-Metabase, Web-Net-Ext,Web-Lgcy-Mgmt-Console, WAS-Process-Model,RSAT-Web-Server, Web-ISAPI-Ext,Web-Digest-Auth, Web-Dyn-Compression -Restart

The Client Access server role requires that the .NET TCP Port Sharing Service (NetTcpPortSharing) be set to automatic. This service allows multiple processes running on a server to use a single port. It adds a layer of logic between the network and the application. In Exchange 2010, the Mailbox Replication service relies on TCP Port Sharing to coordinate move requests originating from multiple clients. You can set up the service manually through the Services snap-in, or use one of the following commands. At a Windows command prompt, use

sc config NetTcpPortSharing start= auto

Or in PowerShell, you can use

Set-Service NetTcpPortSharing -StartupType Automatic

GUI-Based Installation

Now that the prerequisites are installed, you can install a Client Access server using the setup wizard. The Client Access server role can be installed on servers alongside of other roles, but in this example, I'm installing only the Client Access server role on the server.

Insert the Exchange 2010 installation media. If AutoPlay doesn't fire up the installer, you can launch setup.exe from the root of the DVD. Note that there are two versions of setup on the DVD—setup.exe and setup.com. Setup.com is the command-line installer, which I'll talk about later. When you launch setup.exe, you'll see a screen that's similar to Figure 2. In this example, steps 1 and 2 are grayed out because I already took care of these items when I installed the prerequisites. Click Step 3 and choose the language options you want to use. For this example, I'm going to use only the languages that are on the DVD.

Figure 2: Beginning the installation wizard

You can then click Step 4 to launch the setup wizard. You'll see an introduction screen, followed by a License Agreement that you must accept, then the option to report errors to Microsoft automatically. When you come to the Installation Type screen, select Custom Exchange Server Installation and click Next, as Figure 3 shows.

Figure 3: Selecting Custom Exchange Server Installation

Next is the Server Role Selection screen. This screen is where you'll select the option for installing the Client Access server role. When you do this, the Management Tools are automatically selected as well. Because I'm installing only the Client Access server role, those are the only two options I select, as Figure 4 shows.

Figure 4: Selecting to install only the Client Access server role

The Configure Client Access Server External Domain screen, which Figure 5 shows, is next. This screen is new in Exchange 2010 and lets you specify (during install) the external namespace that the Client Access server will service. As part of the installation, your virtual directories will be configured with this external namespace, so you don't have to do it manually after setup. This screen is completely optional, and you should only configure it for Internet-facing Client Access servers. If you're setting up an Internet-facing Client Access server and you don't specify the external namespace, you can still go back in and configure it afterward.

The remaining screens in the setup wizard run the prerequisite check for the Client Access server and perform the installation. If you followed the guidance I provided for the prerequisite software, you shouldn't run into any problems in the prerequisite check. After Exchange installs successfully, you should see a screen similar to Figure 5.

Figure 5: An example successful installation screen

Unattended Installation

Running through the setup wizard makes the installation of a Client Access server fairly simple, but if you're deploying multiple Exchange servers running the Client Access server role, you might be better off using a less interactive installation. Exchange lets you run unattended installations using the command-line setup.com tool on the Exchange installation media.

You can run setup.com with command-line parameters or you can specify an answer file. Answer files are helpful if you have a lot of options that you want to specify for a command, but unless you're installing and customizing additional roles on the same server, they won't help much for the Client Access server role. If you're not specifying any additional setup options, you can install the Client Access server role with the command

setup.com /mode:install /roles:clientaccess

You might want to use the NoSelfSignedCertificates parameter for your installation. This parameter installs the role without a self-signed certificate, which can be helpful if you're planning to remove the default self-signed certificate and use one issued by a trusted third-party Certificate Authority. Don't use this command unless you intend to install an issued certificate. You should also consider using the ExternalCASServerDomain parameter. For example:

setup.com /mode:install /roles:clientaccess /ExternalCASServerDomain:mail.contoso.com

This parameter lets you specify your external domain name for Internet-facing Client Access servers, as I mentioned in the section using the setup wizard. After you execute the setup.com command, the installation is hands-off, as Figure 6 shows.

Figure 6: An example hands-off installation

Coexistence and Transition

Coexisting with and transitioning from legacy versions of Exchange aren't too difficult in Exchange 2010—if you understand a few basics. Remember that Exchange 2010 Client Access servers can't communicate with Exchange 2003 or Exchange 2007 Mailbox servers by using MAPI. Your external-facing legacy servers need a different external namespace than your external-facing Exchange 2010 Client Access server. You might require new certificates—your legacy servers will have a different namespace, so if you don’t have a wildcard certificate, you'll have to request a new SAN certificate. And you should always transition Internet-facing Client Access servers first, followed by those that don't face the Internet.

Maintaining an additional namespace is the part of the coexistence and transition process that has the most impact on your Exchange setup. Because Exchange 2010 is designed to interoperate with legacy Client Access servers and front-end servers, you want your Exchange 2010 Client Access servers to use your existing namespace and you want to adopt a new namespace for your legacy servers.

For example, if your external namespace with your current Exchange 2007 or Exchange 2003 servers is mail.contoso.com, you probably want to use this namespace for Exchange 2010. If you keep it, users won't have to remember a new URL for Outlook Web App (OWA; formerly Outlook Web Access) or reconfigure their mobile phones or IMAP/POP clients. If you're keeping your legacy Exchange 2003 front-end servers or Exchange 2007 Client Access servers online, temporarily or permanently, there might be cases in which your Exchange 2010 Client Access server has to redirect an external client to a legacy front-end or Client Access server. For this redirection to work, your legacy servers need to have a different external namespace, such as legacy.contoso.com.

When you're ready to transition, you can deploy your Exchange 2010 Client Access servers without affecting your legacy Exchange infrastructure. Make sure that you don't make any DNS changes to your production external namespace (e.g., mail.contoso.com) until after you configure the legacy namespace and are ready for your external users to use the Exchange 2010 Client Access servers. The steps to configure the legacy namespace differ between Exchange 2007 and Exchange 2003.

For Exchange 2003 front-end servers:

Outlook 2003 and older clients still use public folders to download the OAB, so if you have these clients in your environment, make sure public folder–based distribution is still enabled as well. The virtual directory for web-based OAB distribution is added by default on the Client Access server, but you'll need to configure the OAB itself by adding the virtual directory as a web distribution point. Use the Set-OfflineAddressBook cmdlet in Exchange 2010 to add the Client Access server OAB virtual directory to the list of virtual directories allowed for your OABs. When you make this change, you must ensure that version 4 OABs are being generated. Also, make sure you include all of the existing virtual directories and the virtual directory you're adding when you execute this command. Any virtual directories that you omit will be removed from the list. Your commands should look like this:

Move-OfflineAddressBook

  "Default Offline Address Book"

  -Server CONTOSO-MBX01

Set-OfflineAddressBook

  "Default Offline Address Book"

  -VirtualDirectories

  "CONTOSO-CAS01oab*"

To create a legacy namespace for Exchange 2007 Client Access servers:

The process of transitioning your legacy infrastructure will vary between different Exchange environments. I've given you a high-level understanding of this process, but you should thoroughly test your transition and coexistence scenarios before rolling out Exchange 2010 to production.

Deployed, and Ready for the Next Layer

You should now have a good grasp of the work involved with deploying the Client Access server role in your Exchange environment. Of course, the Client Access server role has many layers. In the next article in this series, I'm going to peel back another layer and show you how you can add redundancy and high availability to your Client Access servers. Until then, a great resource that you might want to look at is the Exchange team blog post "Transitioning Client Access to Exchange Server 2010."