Tag Archive: client access



If I have a NLB or hardware load balancer – why do I need a CAS array?

This is an excellent question and it’s all about client connectivity, transparency of the connection to the user and automagic cutover in the event of a CAS array member failing. this becoems even more important now that ALL client connections including RPC MAPI connections are now going through the CAS role. Heck if you look at the MAPI account config for an exchange mailbox user it now shows the CAS server name, not the Mailbox role server name. To avoid client reconfiguration or disconnection and forcing a re-query for available CAS boxes, we have CAS arrays to assist in this.

The following information was found in this TechNet page Understanding RPC Client Access. NOTE – this is for RPC high availability, if you still want OWA / EAS  / ECP high availability MS recommends a solution like Forefront Threat Management Gateway.

When a Client Access server array is defined in an Active Directory site, it serves as a single contact point for all client connections within that Active Directory site. A Client Access server array can include one or many Client Access servers.

Each Active Directory site can have a single Client Access server array. A Client Access server array doesn’t provide load balancing. A separate load balancing solution is still needed. For more information about load balancing, see Understanding Load Balancing in Exchange 2010.

Microsoft recommends that you create a Client Access server array even if you only have a single Client Access server within your organization. When a Client Access server array is created, clients connect through the virtual name of the Client Access server array rather than directly to the fully-qualified domain name (FQDN) of your single Client Access server. If a single Client Access server needs to be replaced within an Active Directory site or a second Client Access server is added, no profile updates are necessary on the clients.

After a Client Access server array is defined within an Active Directory site, all Client Access servers within that Active Directory site are automatically part of the Client Access server array.

The high level steps are here..

  1. Create a Client Access array
  2. Configure load balancing
  3. Configure IP ports
  4. Configure RPC encryption settings
  5. Configure your Mailbox databases
  6. Ensure low latency and sufficient network speed

     Create a Client Access Array

You can create a Client Access array within your Active Directory site by using the following command.

New-ClientAccessArray -Name name -Site site_name -FQDN internal_only_CAS_Array_FQDN

Ee332317.note(en-us,EXCHG.141).gifNote:

After the Client Access array has been created, you’ll also need to create the address in DNS and associate it with the virtual IP address used for the Client Access array.

It’s important that the (FQDN) specified in the command be only resolvable internally. If the name is also resolvable externally, these external clients will attempt to connect to the array via a TCP connection instead of HTTPS.

  Configure Load Balancing

Load balancing is recommended for high availability, failover, and for spreading the traffic load over multiple servers to help performance. When you choose a load balancing solution, consider the following:

  • Windows Network Load Balancing isn’t supported on Windows failover cluster servers.
  • You can’t use a Client Access array across multiple Active Directory sites. Instead, create two Client Access arrays and load balance separately within the sites.
  • Hardware load balancers typically monitor return traffic, port availability, or service availability to ensure that servers that can’t answer client requests aren’t given network connections.
  • Some load balancing solutions, such as ISA 2006 or TMG 2010, can’t do RPC load balancing or monitor RPC services. These solutions aren’t recommended unless all clients are connecting via Outlook Anywhere and all traffic is encapsulated inside HTTP.

For more information about load balancing, see Understanding Load Balancing in Exchange 2010.

Configure IP Ports

An IP port is an opening through which information can pass from the originating computer to the destination computer. By default, the dynamic port range for outgoing connections on Windows Server 2008 R2 is 49152 to 65535. Exchange 2010 Client Access changes this range to 6005 through 59530. The range was expanded to provide sufficient scaling for large deployments. This is a large range of ports to balance through your firewall between the client and the Client Access servers or Client Access array.

By fixing the MAPI and directory endpoints, you can greatly reduce the number of ports that need to be load balanced. The MAPI endpoint can be statically configured in the registry and the directory endpoint can be fixed in a configuration file.

To fix the MAPI endpoint, use the following setting in the registry.

HKLM\SYSTEM\CurrentControlSet\ Services\MSExchangeRPC\ParametersSystemTCP/IP Port [DWORD] is the value for the IP port to use

To fix the directory services endpoint, edit the RpcTcpPort value in the configuration file Microsoft.Exchange.AddressBook.Service.Exe.config.

Ee332317.note(en-us,EXCHG.141).gifNote:

Microsoft doesn’t recommend that you change the default value of the Outlook Anywhere ports.

 

  Configure RPC Encryption Settings

In Exchange 2010, the RPC endpoint is encrypted by default. However, Outlook 2003 doesn’t enforce encrypted MAPI connections. When you upgrade your organization to Exchange 2010, your clients running Outlook 2007 or later versions will automatically be compatible with the change to RPC Client Access, since they support RPC encryption by default. Outlook 2003 doesn’t use RPC encryption, however, and RPC Client Access requires it by default. If you haven’t turned off RPC encryption, which we don’t recommend, your users will need to configure Outlook 2003 for RPC encryption or you’ll need to use a Group Policy to force Outlook 2003 to use RPC encryption.

Symptoms of this problem include the following error messages:

  • Cannot start Microsoft Office Outlook. Unable to open the Office window. The set of folders could not be opened.
  • Unable to open your default e-mail folders. The information store could not be opened.

If your users are using Cached Exchange Mode, Office won’t display an error, but will start in disconnected mode.

For more information about this issue, including workarounds, see Outlook Connection Issues with Exchange 2010 Mailboxes.

 

  Configure Outlook 2003 to Use RPC Encryption

To configure Outlook 2003 to use RPC encryption, use the following steps.

  1. Click Tools > E-Mail Accounts > View or Change an Existing Account.
  2. Select the account and click More Settings.
  3. Select the Security tab.
  4. Select Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server.
  5. Click OK

In addition to the RPC encryption requirement, UDP notification support was removed from Exchange 2010. As a result, Outlook 2003 can only use polling notifications in online mode. This will result in a slight delay in updates to item status (30 seconds on average with up to a one-minute delay) when changes are made to items in a mailbox accessed by Outlook 2003. There are two workarounds for this issue:

  • Use Outlook 2003 in Cached Exchange Mode.
  • Adjust the polling interval on the Client Access server. This will impact the performance of the Client Access server.

For more information about this issue, see E-mail messages take a long time to send and receive.

  Configure Your Mailbox Database

Each Mailbox database contains an RPCClientAccessServer value. This value is established when the database is created and it determines the Client Access server or Client Access array that the clients with mailboxes on that Mailbox server will use. This value also determines the location of the RPC end point. For Outlook 2007 and Outlook 2010 clients, this value is obtained from the Autodiscover service.

The default value of the RPCClientAccessServer is determined by the following rules:

  • If you have configured a Client Access Server array within your Active Directory site, the address of that array will be used.
  • If an array does not exist within the Active Directory site and if you have both the Client Access server role and the Mailbox server role on the same physical server, the value of RPCClientAccessServer property for a particular Mailbox server will be the same as the Mailbox server.
  • Otherwise, the value of the RPCClientAccessServer property for a particular Mailbox server will be set to a random Client Access server within the Active Directory site.

    Ee332317.note(en-us,EXCHG.141).gifNote:

    We don’t recommend that you install all the server roles on a single computer that’s also a domain controller. Although this configuration is supported, it’s not recommended.

  • If you created a Mailbox database before the creation of a Client Access array or the installed a Client Access server within the Active Directory site, you’ll need to reconfigure the value of the RPCClientAccessServer property. If no Client Access server exists in the Active Directory site when the Mailbox database is created, the value of the RPCClientAccessServer property will be set to the FQDN of the Mailbox server. To configure the value of the RPCClientAccessServer property, use the following command.
    Set-MailboxDatabase <name> -RPCClientAccessServer <internal_only_CAS_Array_FQDN>

  Latency and Bandwidth Requirements

For users running Outlook without Cached Exchange Mode, high latency times between the client and the server directly affect how frequently Outlook is unresponsive. In general, a latency of greater than 200 milliseconds (ms) to the home Mailbox server will result in poor client performance.

Because latency between the Client Access server and the mailbox should be less than 10 ms, we recommend that the value of the RPCClientAccessServer property always be configured to a Client Access array in the active Mailbox database site.

Ee332317.note(en-us,EXCHG.141).gifNote:

Changing the value of the RPCClientAccessServer property will force all clients to reconnect.

  Configuring the Address Book Service

The Address Book service is configured through the Microsoft.Exchange.AddressBook.Service.config file. This file allows you to configure the following:

  • The number of concurrent connections per user (the default limit is 50).
  • Disable or enable logging.
  • The location, size, and retention period for the log files.

To set the value of the maximum number of sessions per user, use the following value: <add key=“MaxSessionsPerUser” value=“50” />

To enable logging, use the following value: <add key="ProtocolLoggingEnabled" value="true" />

Advertisements

Now the following post has some parts from our friends at Exchangeserverpro.com. Please follow them on Twitter – @Exchservpro. Instead of re-inventing the wheel here I’d post some of their great content from the following two links..

Exchange 2010 CAS backup and recovery

and

Exchange 2010 Hub Transport backup and recovery

 

Now understand these steps listed below are if you are NOT going to be doing bare-metal or full server backups. Those obviously would be the easiest route.

Planning the Client Access Server Backup

As you plan the Client Access server backup strategy there are different techniques that you can consider depending on your requirements.

Backing up Everything

A full system backup of the Exchange 2010 Client Access server, along with a working Active Directory, will have all of the required information to recover the Client Access server.  Naturally this backup takes the longest to run, and will use up the most backup storage.

Backup up the Minimum

To reduce backup storage and keep the backup time frame shorter the minimum data on the Client Access server can be backed up.  This involves backing up the system state of the server, and configuration files stored in the \ClientAccess path of the Exchange Server 2010 installation folder (C:\Program Files\Microsoft\Exchange Server\V14 by default).

Backing up Nothing

It may be practical to not back up the Client Access server at all if:

  • There are multiple, redundant Client Access servers deployed (ie Client Access Server Array)
  • The SSL certificates are exported or retrievable from elsewhere
  • Customizations to the Client Access server virtual directories can be quickly reapplied using an existing script

If all of those conditions are true then the Client Access server may not need to be backed up at all.

Backing Up and Restoring Client Access Servers

In this demonstration a Client Access server has been configured as a single-node NLB cluster and Exchange 2010 CAS array.

Exchange 2010 Client Access server configured with NLB

Exchange 2010 Client Access server configured with NLB

The external URL has also been configured.

[PS] C:\>Get-OwaVirtualDirectory | fl name, *URL*

Name            : owa (Default Web Site)
Url             : {}
Exchange2003Url :
FailbackUrl     :
InternalUrl     : https://ex3.exchangeserverpro.local/owa
ExternalUrl     : https://mail.exchangeserverpro.local/owa
Recovering an Exchange 2010 Client Access Server

Because most of the Client Access server configurtion is stored in Active Directory when a Client Access server has failed you can recover the server using the following procedure.

  1. Install a new server to host the Client Access server role
  2. Configure the server to have the same name, IP address, and domain membership as the server that failed
  3. Install the Exchange Server 2010 pre-requisites
  4. Perform a recovery mode install of Exchange Server 2010

To run Exchange Server 2010 setup in Recovery Mode use the following command from an elevated command prompt.

setup /m:recoverserver

Setup performs a server recovery using the configuration information stored in Active Directory.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to

http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/

...............
No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Client Access Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Client Access Role Checks         ......................... COMPLETED

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Client Access Server Role         ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

After the reboot you can verify that some configurations have been recovered, such as the OWA virtual directory URLs. However any other customized configurations that were stored in the system state or the file system are not recovered by this process. Those settings will need to be reapplied from the minimal backups, or reapplied manually or by using a script.

 

 

 

Planning the Hub Transport Server Backup

When you are planning the Hub Transport server backup strategy there are different approaches you can take depending on your requirements.

Backing up Everything

A full system backup of the server, along with a working Active Directory, encompasses all of the required information for a recovery.  However this backup takes the longest and will consume the most backup storage.

If a server failed and needed to be recovered from a full backup any undelivered messages still in the transport queue would be lost.  But it is impractical to backup the entire server multiple times a day just to protect the transport queue databases from data loss.

Depending on the Exchange environment and the backup infrastructure in place a full server recovery may take longer than simply rebuilding the server from scratch.

Backing up the Minimum

To save on backup storage and minimize the backup time frame the minimum data on the Hub Transport server can be backed up.  For most environments this would mean only backing up the transport queue databases and the log files on the file system.

Because these would be relatively fast to back up this type of backup could be performed multiple times per day to minimize the risk of losing undelivered messages.  This concern would mostly apply to high volume email environments where the transport queues are regularly backlogged.  Of course in those cases some attention should be paid to whatever performance bottleneck is causing the backlog, if it is something within the control of that organization to fix.

Backing up Nothing

A perfectly feasible backup strategy for the Hub Transport server is to back up nothing at all.  This would be practical if:

  • there are multiple, redundant Hub Transport servers deployed
  • the transport queues are not frequently backlogged
  • the organization does not wish to retain any log files from the Hub Transport servers

If all those conditions are true then it may not be necessary to back up the Hub Transport servers at all.

Backing Up and Restoring Hub Transport Servers

For the purposes of this demonstration I’ve configured a Hub Transport server with an additional Receive Connector.

alt

Message tracking logs are also enabled.

alt

Recovering a Hub Transport Server

As mentioned earlier most of the critical Hub Transport server configuration is stored in Active Directory.  When a Hub Transport server has failed you can recover the server using the following process.

  1. Install a new server to host the Hub Transport server role
  2. Configure the server with the same name and IP address as the failed server, and join it to the domain
  3. Install the Exchange Server 2010 pre-requisites
  4. Perform an installation of Exchange Server 2010 using Recovery Mode

To run setup in Recovery Mode use the following command to launch Exchange Server 2010 set from an elevated command prompt.

C:\Admin\Exchange 2010>setup /m:recoverserver

Setup performs a server recovery instead of a normal installation.

Welcome to Microsoft Exchange Server 2010 Unattended Setup

By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to

http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/

...............
No key presses were detected.  Setup will continue.
Preparing Exchange Setup

    Copying Setup Files              ......................... COMPLETED

The following server roles will be recovered
    Hub Transport Role
    Management Tools

Performing Microsoft Exchange Server Prerequisite Check

    Hub Transport Role Checks        ......................... COMPLETED
 This computer requires the 2007 Office System Converter: Microsoft Filter Pack.
 Please install the software from http://go.microsoft.com/fwlink/?LinkId=123380.

Configuring Microsoft Exchange Server

    Preparing Setup                  ......................... COMPLETED
    Stopping Services                ......................... COMPLETED
    Copying Exchange Files           ......................... COMPLETED
    Restoring Services               ......................... COMPLETED
    Hub Transport Server Role        ......................... COMPLETED
    Exchange Management Tools        ......................... COMPLETED
    Finalizing Setup.                ......................... COMPLETED

The Microsoft Exchange Server setup operation completed successfully.
Setup has made changes to operating system settings that require a reboot to tak
e effect. Please reboot this server prior to placing it into production.

Restart the server as prompted.  When the server has finished restarting you can verify that configurations such as the additional Receive Connector and the message tracking log configuration have been recovered with the server.

alt

alt

However the log files themselves are not restored during a Recovery Mode install of Exchange Server 2010.

alt

Neither are additional applications or agents that were previously installed ont he server.  For the Hub Transport server one notable item would the Microsoft Office Filter Pack.

Therefore the server is not fully recovered until all of those items, along with any further customizations to the server, have been manually applied.