Understanding Namespace Planning For Exchange Server 2007
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
When you plan your Microsoft Exchange Server 2007 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 is usually represented by a domain name in DNS. When you define your namespace, you must consider the various locations of your clients and the servers that house their mailboxes. In addition to the physical locations of clients, you must evaluation how they connect to Exchange 2007. 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 such as mail.contoso.com or mail.europe.contoso.com.
Before you implement an Exchange 2007 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.
What certificates you must have to encrypt communications between your computers that are running Exchange 2007 and your client computers and devices.
How your clients access their mailboxes when using Outlook Anywhere, Outlook Web Access, and POP3 and IMAP4 clients.
This process involves examining your physical and logical network structure and choosing an organizational topology. This topic provides an overview of the various topologies and provides information about how each topology affects your Exchange organization.
Note
This topic does not discuss internal namespace planning, which may be required if you deploy load balancing within an Active Directory site. For details on the impact of deploying load balancing internally, see Understanding Proxying and Redirection.
Exchange 2007 Organizational Models
This topic examines the following topologies:
Consolidated Data Center Model This model consists of a single physical site. All servers are located within one physical site and there is a single namespace, such as 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 physical sites are not exposed to the Internet. There is 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 is 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 is located in New York City would have the namespace mail.usa.contoso.com, a site that is located in Toronto would have the namespace mail.canada.contoso.com, and a site that is 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 Data Center Model
The consolidated data center model is the simplest model considered in this topic. It consists of a single physical site. The following figure illustrates this model.
The advantages of the consolidated data center 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 is to use a single certificate that supports Subject Alternative Names. For more information about certificates that support Subject Alternative Names, see Unified Communications Certificate Partners for Exchange 2007 and for Communications Server 2007.
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 data center model include a wildcard certificate, multiple certificates, and configuring SRV records appropriately. For more information about these methods, see White Paper: Exchange 2007 Autodiscover Service.
End users do not have to determine which namespace to use. All end users use the same namespace and URL to access Microsoft Exchange.
There are also several disadvantages to the consolidated data center model. These include the following:
This model does not support multiple data centers.
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 do not contain Internet-facing Client Access servers.
Important
Installing a Client Access server in a perimeter network is not supported.
The following figure illustrates this model.
Warning
This model is not recommended if all sites have Internet connectivity. If your topology uses multiple Active Directory sites that have Internet connectivity and are not in close proximity, a regional namespace model is recommended.
The advantages of this model are as follows:
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 do not have to determine which namespace to use. All end users use the same namespace and URL to access Microsoft Exchange.
There are also several disadvantages to deploying a single namespace with proxy sites. These include the following:
A high percentage of users will access their Mailbox server through proxying. If a user connects to a Client Access server that is not in the same physical site as their Mailbox server, they will be proxied to a Client Access server that is in the same physical site as their Mailbox server. Because of the added proxying, WAN link costs will increase and performance will not be optimal. The effect on performance depends on the distance between the two physical data centers and the numbers of proxied connections.
Access to Windows SharePoint Services libraries and Windows file shares is not possible when users connect to a Client Access server that is not within the same site as their Mailbox server. The failure occurs 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 the Windows SharePoint Services libraries and Windows file shares is performed through the system account of the Client Access server. This account is not aware of the user's user name and password.
Clients that use the POP3 or IMAP4 protocols will be unable to access their mailbox if the Client Access server they connect to is not in the same site as their Mailbox server. POP3 and IMAP4 connections cannot be proxied between sites.
Important
It is necessary to configure the target virtual directories on each Client Access server in the site being proxied to for Integrated Windows authentication.
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 server 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 is not supported.
Deployment with an ISA Server
The following figure illustrates deploying this model behind an ISA Server or other firewall.
In the configuration shown in the figure, ISA Server performs pre-authentication of the connection in order 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 server could be configured to use an external, trusted certificate from a recognized provider. The traffic between the ISA Server server and the Client Access servers could be secured using an internally generated certificate.
End users do not 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.
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.
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 amount of increase depends on the physical location of the ISA Server server.
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 cannot 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 taken into account when new mailboxes are created or moved. Placing a Global Catalog server close to the ISA Server server is the recommended way to avoid having unnecessary authentication requests travel over the WAN.
Important
We do not recommend deploying a topology that has a single namespace and multiple Active Directory sites. If your topology uses multiple Active Directory sites, we recommend that you use a regional namespace model.
Note
To deploy a single namespace with multiple sites, you must clear the ExternalURL values for the virtual directories on the Internet-facing Client Access servers if you want to disable redirection and enforce proxying.
Deployment with a Client Access Server Proxy Site
The following figure illustrates this model.
In this model, all client connections that originate externally go to Active Directory Site C. The connections are then proxied to the site that contains the user's mailbox by the Client Access server in Site C.
The advantages to 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 is internally generated.
End users do not need 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 is not 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 does not need 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 utilization 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 the user connects to a Client Access server in Site C, it is not in the same Active Directory site as their Mailbox server. They will be proxied to a Client Access server that is in the same Active Directory site as their Mailbox server. Performance will not be optimal due to 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 is not possible when users connect to a Client Access server that is not 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 is not aware of the user's user name and password.
Clients that use the POP3 or IMAP4 protocols will be unable to access their mailbox if the Client Access server they connect to is not in the same site as their Mailbox server. POP3 and IMAP4 access cannot be proxied between sites.
Important
The ExternalURL property on each virtual directory in a site that contains user mailboxes must be set to $null.
Important
Client Access servers do not support multiple levels of proxying. Each site that contains user mailboxes must be accessible to 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 following figure illustrates the regional namespace model.
The advantages of this model are as follows:
- Proxying will be 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 does not 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 help desk calls and training.
Important
The regional namespace model is 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.
We recommend that you implement 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.
For More Information
For more information about namespace planning and its effects on Exchange Server security, see the following topics: