Editor’s Note: This article is an excerpt from Siegfried Jagott and Joel Stidley, Microsoft Exchange Server 2010 Best Practices (Microsoft Press, 2010) and is reprinted with the publisher’s permission.
Before you set up your Microsoft Exchange Server 2010 organization, one of the most important areas that needs to be planned is your internal (organization-facing) and external (Internet-facing) namespace. A namespace is a logical structure commonly represented by one or more domain names in DNS.
Namespace planning is most important for the Client Access Server role. However, many considerations are also needed for the Hub Transport and Edge Transport roles. This article should provide the general basis for understanding the importance for namespace planning. During migration or transitions, you also might need to consider special namespace requirements. Those topics are discussed in more detail in Siegfried Jagott and Joel Stidley, Microsoft Exchange Server 2010 Best Practices (Microsoft Press, 2010).
The official Microsoft support statement for Exchange 2010 and SLD/Disjoint/Non-contiguous Namespaces can be found at http://msexchangeteam.com/archive/2009/10/27/452969.aspx.
Namespace Scenarios
When you implement your Exchange 2010 organization, you need to decide how your internal and external namespace will be defined. This is important because it affects the following areas:
- DNS configuration of your Exchange servers
- How your certificates are created and what names they include
- Client Access (Outlook Anywhere—OA, Outlook Web App—OWA, POP3 and IMAP4, SMTP)
If you have multiple data centers available where your Exchange 2010 servers are located, consider the following general advice for namespace planning:
- Plan your namespaces such that both data centers can be active.
• This still allows for incremental deployment.
• You provide failover capabilities or can manually switch over a data center.
- Each data center needs the following namespaces, depending on your client connectivity capabilities:
• Outlook Web App/OA/Exchange Web Services (EWS)/Exchange ActiveSync (EAS) namespace
• POP3/IMAP4 namespace
• RPC Client Access namespace
• SMTP namespace
- Consider which data center will maintain the Autodiscover namespace.
To start planning your namespace, you need to consider the various locations of clients and servers and the physical connections they have to the Exchange servers. Typically the namespaces align with your DNS configuration.
You can choose from the following namespace-planning options:
- Consolidated data center
- Single namespace with proxy sites
- Single namespace with multiple sites
- Regional namespaces
- Multiple forests
Consolidated Data Center
This namespace scenario is the simplest one and includes a single namespace to access a single physical site where all the Exchange servers are hosted. This scenario has the following advantages:
- Only one or very few DNS records need to be managed.
- Only one or very few certificates are required for your Exchange organization.
- All users use the same URL to access the Exchange server.
This namespace scenario is configured by providing Internet access to the Client Access server by opening the relevant ports by a firewall or implementing an application layer firewall such as Forefront Threat Management Gateway (TMG) in the perimeter network.
If you want to provide POP3/IMAP4, you need also to consider how the clients will send their messages using SMTP. To overcome this easily, you can configure the Hub Transport role on each Client Access server. Otherwise, you need to plan separately for message sending and message receiving namespaces.
Single Namespace with Proxy Sites
This model is based on the consolidated data center model but proxies the requests to the physical Mailbox server located at another site. One of the sites has one or more Internet-facing Client Access servers that proxy the requests.
This scenario has the following advantages:
- Only one or very few DNS records need to be managed.
- Only one or very few certificates are required for your Exchange organization.
- All users use the same URL to access Exchange server.
The disadvantage of this model is that most users will access their mailboxes using proxying, thus accessing their data might be slower across latent WAN links.
To configure this namespace model, you need to configure the ExternalURL option of the Client Access server(s) at one site, and make sure that the ExternalURL settings on all the other sites are configured to $Null. This configuration ensures that the Client Access server does not redirect the connection to the target Client Access server, but instead proxies it. Redirect means that the Client Access server forwards the connection to the target Client Access server; proxy means that the Client Access server contacts the target Client Access server and retrieves the data for the connection.
Single Namespace with Multiple Sites
This model uses a single namespace for an organization that has multiple sites. A possible candidate for this approach would be a company that has multiple physical sites and wants to use a single namespace. The two possible approaches to implementing a single namespace with multiple sites are with a Client Access server proxy site or an intelligent firewall:
- The Client Access server proxy site approach includes Client Access servers based in a separate Active Directory site that is used to proxy the traffic to the site where the user’s mailbox is located. To configure this namespace model, you need to configure the ExternalURL option to the single namespace of the Client Access servers at all sites.
- The intelligent firewall approach uses an application-layer firewall such as Forefront TMG and decides during client authentication that the traffic is forwarded to the correct target site based on configured rules. To configure this namespace model, you need to configure the ExternalURL option to the single namespace of the Client Access servers at all sites.
This scenario has the following advantages:
- Only one or very few DNS records need to be managed.
- Only one or very few certificates are required for your Exchange organization.
- All users use the same URL to access Exchange server.
The disadvantage of this model is that you must either have an application-layer firewall that is capable of forwarding the traffic to the correct physical sites like Microsoft Forefront TMG or a Client Access server proxy site.