Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2011-11-08
When you plan your Microsoft Exchange Server 2010 organization, one of the most important decisions that you must make is how to arrange your organization's external namespace. A namespace is a logical structure that's usually represented by a domain name in DNS. When you define your namespace, you must consider the different locations of your clients and the servers that house their mailboxes. In addition to the physical locations of clients, you must evaluate how they connect to Exchange 2010. The answers to these questions will determine how many namespaces you must have. Your namespaces will typically align with your DNS configuration. We recommend that each Active Directory site in a region that has one or more Internet-facing Client Access servers have a unique namespace. This is usually represented in DNS by an A record, for example, mail.contoso.com or mail.europe.contoso.com.
Before you create an Exchange 2010 organization, you must decide how your organization will be configured and how your external namespaces will be defined. The decisions that you make about your namespaces will affect the following:
- How you configure DNS.
- The certificates you must have to encrypt communications
between your computers running Exchange 2010 and your client
computers and devices.
- How your clients access their mailboxes when they use Outlook
Anywhere, Outlook Web App, and POP3 and IMAP4 clients.
Making these decisions involves examining your physical and logical network structure and choosing an organizational topology. This topic discusses the different topologies and provides information about how each topology affects your Exchange organization.
Note: |
---|
This topic doesn't discuss internal namespace planning, which may be required if you deploy load balancing within an Active Directory site. For details about the impact of deploying load balancing internally, see Understanding Proxying and Redirection. |
Exchange 2010 Organizational Models
This topic examines the following types of topology:
- Consolidated Datacenter Model This
model consists of a single physical site. All servers are located
within the site, and there's a single namespace, for example,
mail.contoso.com.
- Single Namespace with Proxy Sites This
model consists of multiple physical sites. Only one site contains
an Internet-facing Client Access server. The other sites aren't
exposed to the Internet. There's only one namespace for the sites
in this model, for example, mail.contoso.com.
- Single Namespace and Multiple
Sites This model consists of multiple physical
sites. Each site can have an Internet-facing Client Access server.
Or, there may be only a single site that contains Internet-facing
Client Access servers. There's only one namespace for the sites in
this model, for example, mail.contoso.com.
- Regional Namespaces This model consists
of multiple physical sites and multiple namespaces. For example, a
site that's located in New York City would have the namespace
mail.usa.contoso.com, a site that's located in Toronto would have
the namespace mail.canada.contoso.com, and a site that's located in
London would have the namespace mail.europe.contoso.com.
- Multiple Forests This model consists of
multiple forests that have multiple namespaces. An organization
that uses this model could be made up of two partner companies, for
example, Contoso and ContosoOnline. Namespaces might include
mail.usa.contoso.com, mail.europe.contoso.com,
mail.asia.contosoonline.com, and mail.europe.contosoonline.com.
Consolidated Datacenter Model
The consolidated datacenter model is the simplest model considered in this topic. It consists of a single physical site.
The advantages of the consolidated datacenter model are as follows:
- There are fewer DNS records to manage than with multiple
namespace models.
- There are fewer certificates to manage. Communications between
the Exchange Client Access server and clients can be encrypted in
several ways. The recommended method for encryption is to use a
single certificate that supports Subject Alternative Names.
Note: A Subject Alternative Name is an attribute of a digital certificate that allows the site administrator to configure a single certificate that lists all the namespaces that require a server certificate. Note: Alternative methods for managing certificates for a consolidated datacenter model include a wildcard certificate, multiple certificates, and configuring SRV records appropriately. - End users don't have to determine which namespace to use. All
end users use the same namespace and URL to access Microsoft
Exchange.
Disadvantages to the consolidated datacenter model include:
- This model doesn't support multiple datacenters.
- If regional Internet links are slow because of low bandwidth,
high latency, or high use, end users in those regions will
experience poor performance.
Single Namespace with Proxy Sites
This model consists of multiple physical sites that use a single namespace. Behind an ISA Server computer or another firewall, one of the sites has one or more Internet-facing Client Access servers. The other sites don't contain Internet-facing Client Access servers.
Important: |
---|
Installing a Client Access server in a perimeter network isn't supported. |
Caution: |
---|
This model isn't recommended if all sites have Internet connectivity. If your topology uses multiple Active Directory sites that have Internet connectivity and aren't near to each other, consider a regional namespace model. |
This model offers the following advantages:
- There are fewer DNS records to manage than with multiple
namespace topologies. This reduces operational complexity.
- There are fewer certificates to manage. Communications between
the Client Access server and clients can be encrypted by using a
single certificate that supports Subject Alternative Names.
- End users don't have to determine which namespace to use. All
end users use the same namespace and URL to access Microsoft
Exchange.
Disadvantages to deploying a single namespace with proxy sites include:
- Some users will access their Mailbox server through proxying.
If a user connects to a Client Access server that isn't in the same
physical site as their Mailbox server, they will be proxied to a
Client Access server that's in the same physical site as their
Mailbox server. Because of the added proxying, WAN link costs will
increase and performance won't be optimal. The effect on
performance depends on the distance between the two physical
datacenters and the numbers of proxied connections.
Important: It may be necessary to configure the target virtual directories on each Client Access server in the site being proxied to for Integrated Windows authentication. For more information, see Understanding Proxying and Redirection.
Single Namespace with Multiple Sites
This model consists of multiple physical sites that use a single namespace. There are two deployment options for this model. You can use an ISA Server computer in front of one or more sites or use a Client Access server proxy site. There can be one or more Internet-accessible servers behind each site. This model also requires a load balancing solution that splits the incoming traffic equally between the Internet-facing sites.
Important: |
---|
Installing a Client Access server in a perimeter network isn't supported. |
Deployment with an ISA Server computer
In this configuration, ISA Server performs pre-authentication of the connection to determine the client's group membership. Traffic is then forwarded to the correct site based on the configured publishing rules.
The advantages of this model are as follows:
- There are fewer DNS records to manage than with multiple
namespace models. This reduces operational complexity.
- There are fewer certificates to manage. Communications between
the Client Access server and clients can be encrypted by using a
single certificate that supports Subject Alternative Names. The ISA
Server computer could be configured to use an external, trusted
certificate from a recognized provider. The traffic between the ISA
Server computer and the Client Access servers could be secured
using an internally generated certificate.
- End users don't have to determine which namespace to use. All
users use the same namespace and URL to access Microsoft
Exchange.
- Mailboxes can be moved between sites without external namespace
changes. This provides flexibility for administrators who want to
load balance traffic between sites without changing client
configuration.
- If required, a regional namespace can be added at a later
stage. This same model can be repeated in another location using a
different external URL.
- ISA Server 2006 forms-based authentication can be customized to
suit an organization's specific requirements.
The disadvantages to deploying this model include the following:
- Wide Area Network (WAN) use will likely increase. The increased
use depends on the physical location of the ISA Server
computer.
- ISA Server must be deployed and configured correctly.
- Group memberships must be managed to ensure traffic is
forwarded to the correct site. By default, Recipient Administrators
can't create security groups, so Active Directory delegation must
be configured so that dedicated Exchange Administrators can create
and update group membership. Using groups creates an additional
operational overhead that must be considered when new mailboxes are
created or moved. Placing a global catalog server close to the ISA
Server computer is the recommended way to avoid unnecessary
authentication request travel on the WAN.
Deployment with a Client Access Server Proxy Site
In this model, all client connections that originate externally go to an Active Directory site that contains no user mailboxes. The connections are then proxied by a Client Access server in that site to the site that contains the user's mailbox.
The advantages of this model are as follows:
- There are fewer DNS records to manage than with multiple
namespace models. This reduces operational complexity.
- There are fewer certificates to manage. Communications between
the Client Access server and clients can be encrypted by using a
single certificate that supports Subject Alternative Names. ISA
Server can be configured to use an external, trusted certificate
from a recognized provider. And traffic between the ISA Server and
Client Access servers can be secured using a certificate that's
internally generated.
- End users don't have to determine which namespace to use. All
end users use the same namespace and URLs to access Microsoft
Exchange. If split DNS is configured, this model could also be used
to unify an internal namespace. If split DNS isn't configured, all
internal client requests will reach the firewall and be forwarded
appropriately.
- Mailboxes can be moved between sites without the namespace
being changed from an external user's perspective. This provides
flexibility for administrators who want to load balance between
sites. It is also useful when a disaster occurs and the entire
service must be moved between sites, because the client
configuration doesn't have to be changed.
- A regional namespace can be added at a later stage, if
required. This same model can be repeated in another location,
using a different external URL.
The disadvantages of this model are as follows:
- WAN use will likely increase and depends on the physical
location of the Client Access servers in the Internet-facing
site.
- Additional Client Access servers must be deployed and
configured correctly.
- All users will access their mailbox through proxying. When a
user connects to a Client Access server in the proxy site, it isn't
in the same Active Directory site as their Mailbox server. They
will be proxied to a Client Access server that's in the same Active
Directory site as their Mailbox server. Performance won't be
optimal because of the additional proxying. The effect on
performance depends on the distance between the two physical
sites.
- Access to Windows SharePoint Services libraries and Windows
file shares isn't possible when users connect to a Client Access
server that isn't within the same site as their Mailbox server.
This is because access to Windows SharePoint Services libraries and
Windows file shares requires the user's user name and password. In
a proxying scenario, communication to Windows SharePoint Services
libraries and Windows file shares is performed through the Exchange
system account. This account isn't aware of the user's user name
and password.
Important: The ExternalURL property on each virtual directory in a site that contains user mailboxes must be set to $null. Important: Client Access servers don't support multiple levels of proxying. Each site that contains user mailboxes must be accessed by the Client Access servers in the dedicated proxy site. Note: Additional network configuration might be required if multiple locations are used. This can include configuring hardware load balancers, multiple DNS records, and route redundancy. The physical deployment will vary based on your organization's network topology.
Regional Namespaces
The multiple site model that uses a different namespace for each site is known as a regional namespace model. The advantages of this model are as follows:
- Proxying is reduced because a larger percentage of users will
be able to connect to a Client Access server in the same Active
Directory site as their Mailbox server. This will improve the
end-user experience and performance. Users who have mailboxes in a
site that doesn't have an Internet-facing Client Access server will
still be proxied.
The disadvantages to this model are as follows:
- Multiple DNS records must be managed.
- Multiple certificates must be obtained, configured, and
managed.
- Managing security is more complex because each Internet-facing
site requires an ISA Server computer or other firewall.
- Each user must connect to their own regional namespace. This
may result in additional helpdesk calls and training.
Important: The regional namespace model is generally recommended for any topology that involves multiple Active Directory sites that have their own Internet connectivity.
Multiple Forests
This model consists of multiple forests with multiple namespaces. An organization that uses this model could be made up of two partner companies, Contoso and ContosoOnline. Namespaces might include mail.usa.contoso.com, mail.europe.contoso.com, mail.asia.contosoonline.com, and mail.europe.contosoonline.com.
Consider implementing a regional namespace model for each forest to provide the highest level of performance for end users. Multiple certificates must be managed for each forest.