2. Client Redirection
Redirection occurs
when you set up multiple Internet-facing Client Access servers in
different Active Directory sites. If a user connects to a CAS that is
not in the same site as their mailbox, and if there is an
Internet-facing CAS that is in the same site as the user's mailbox, the
user will be redirected to the Internet-facing CAS in the site that
their mailbox is in. Redirection is useful because it's generally a
good idea to avoid proxying when possible. There's nothing inherently
wrong with proxying, but the user will get the best experience when
connecting to a CAS in the same site as their Mailbox server. Also,
redirection puts less of a toll on WAN utilization.
For Outlook Web App, this redirection comes in the form of a web page redirection, as shown in Figure 4.
This is simply a web page that tells the user that they would be better
off using the CAS closest to their site. This does not happen
automatically; the user has to physically click the link to the site
that it's being redirected to.
For this process to work, the CAS that the user
connects to needs to be able to determine whether the CAS near the
user's mailbox is Internet facing. To make this determination, the
server uses the ExternalURL parameter. If the ExternalURL
is filled out, the server is considered Internet facing. Our
recommendation is to configure your Internet-facing Client Access
server web services with different URLs. Since Active Directory sites
typically align to physical regions, many organizations use a
geographic URL, such as ne-owa.domain.com or mail.europe.domain.com.
|
Over the years, we've picked up several lessons in
IT that have stuck with us. We want to share two of those lessons with
you right now. Not only are they relevant to proxying and redirection,
they are also easy to ignore, especially when you get wrapped up in a
particular design. The first lesson is to make sure that you understand
how something works before rolling out into production. And the second
lesson is to keep your designs as simple as possible.
A couple of years ago, one of the authors worked
with a client in a worldwide Exchange Server 2007 deployment. This
organization had many sites with Exchange servers and every site was
Internet facing. They didn't want their users to have to remember
different URLs for accessing OWA, so they decided to attempt using the
same namespace for every site. This client didn't understand that the
external URLs were used for redirection. So when all the external URLs
for OWA are configured for the same namespace, mail.contoso.com, nothing redirects like it's supposed to.
To get around this, they issued regional namespaces
to their Client Access servers. They then bought a third-party DNS
appliance that can resolve a DNS query differently based on the IP
address of the computer performing the query. The idea is that the user
would type in https://mail.contoso.com
and it would resolve to the DNS alias of the regional external URL
physically closest to them. This solution works fine for users who are
using OWA when they are geographically close to their Mailbox servers;
however, when users travel they get a manual redirection anyway. In
addition, this solution wreaks havoc when users use mail.contoso.com for Outlook Anywhere and Exchange ActiveSync.
The lesson here is that it would have been a lot
easier and simpler to just have users use their regional URLs to begin
with. Then thousands of dollars would have been saved by not buying the
special DNS appliances, and the complexity of the design would have
been reduced tremendously.
|
3. Client Access Arrays
Now that the RPC client access endpoint has been
moved away from the Mailbox server and out to the CAS instead, it's
especially important to ensure that your Client Access servers are
highly available. You can have a dozen mailbox database replicas in
your DAG, replicated off site, but if you have one CAS, you seriously
cripple your resiliency capabilities due to this single point of
failure. If the CAS that a user is connected to goes down, the user
will lose their MAPI connection and their profile will need to be
reconfigured to connect to another CAS in that site. To avoid this
problem, you can use a load-balanced Client Access array instead of
using stand-alone Client Access servers.
The Client Access array object in Active Directory
only provides a unified namespace for mailbox databases in the site. To
make your Client Access servers resilient, you need to use a load
balancer with the array. A variety of products are available for
load-balancing your Client Access servers. However, if you only need
basic load-balancing functionality with a small number of load-balanced
Client Access servers (fewer than eight), we recommend that you check
out Microsoft's free Network Load Balancing component, which is built
into Windows Server. If you have a heavily used environment and
anticipate having more than just a few Client Access servers in an
array, you may want to consider going with a third-party load balancer.
It's important to understand that a load-balanced
Client Access array is only used to provide resiliency for users
connected inside the network with Outlook clients. You can still have
resiliency for OWA and other web services on your Client Access
servers, but you will need to define those ports independently in the
load balancer.
3.1. Load-Balancing Your Client Access Servers
The first step in building a Client Access array is
to load-balance your Client Access servers. If you want to load-balance
fewer than eight Client Access servers and if you only need basic
load-balancing functionality, we recommend looking at the Network Load
Balancing (NLB) service in Windows Server 2008 R2. NLB presents a
virtual name and IP address for all of your Client Access servers in
the array. Each node in the array gets either a multicast MAC address
or the MAC address on one of their network cards replaced with a custom
unicast MAC address. Whether unicast or multicast is used depends
entirely on how you configure NLB.
When you configure your load balancer, you will need
to specify the ports that you want to be load-balanced between the
servers. Outlook clients inside your network establish a MAPI
connection to your CAS using RPC. Since many different applications and
processes on a server use RPC, RPC can't use a single port for
communications. Instead, RPC uses an endpoint mapper to negotiate the
port to use. The RPC endpoint mapper always uses port 135. The
negotiated port is assigned from a pool of ports ranging from port 1024
to port 65535. Therefore, to enable RPC in the load-balanced array, you
will need to specify the following ports:
You don't know which port the RPC endpoint mapper is
going to negotiate to use. So you need to use the entire range to
ensure that the port that is picked is properly load-balanced. The port
assignment in the NLB configuration is shown in Figure 5.
3.2. Configure DNS
After you have your load-balanced Client Access
servers up and running, you must ensure that DNS is updated. You will
want to create a host record that points the hostname of the
load-balanced Client Access servers to the virtual IP address that the
load balancer is using. For example, if you named your load-balanced
array outlook.contoso.com, you must ensure that outlook.contoso.com resolves to the virtual IP address of the array.
3.3. Configuring the Client Access Array
The final step is to create the Client Access array
object and assign it to a site. You can create the Client Access array
using the following command:
New-ClientAccessArray -FQDN outlook.domain.com -Site Baltimore
-Name "Baltimore Array"
By creating this object, you create a virtual CAS that mailbox databases can use for their RPCClientAccessServer
parameter. When you create a mailbox database, if a Client Access array
object exists in the site, the database automatically uses the array
for the RPCClientAccessServer. However, if you created a
mailbox database before you create the array, the mailbox database will
be using the name of the Client Access server itself for the RPCClientAccessServer. Therefore, if you have any mailbox databases that existed in the site before array was added, you need to update the RPCClientAccessServer parameters on those mailbox databases to point to the array. To do this, you would use the Set-MailboxDatabase cmdlet with the RPCClientAccessServer parameter. The following command demonstrates how this is done:
Set-MailboxDatabase DB01 -RPCClientAccessServer outlook.contoso.com
