IT tutorials
Applications Server

Installing Exchange 2013 : Namespace planning

11/15/2013 8:43:42 PM
- Windows 10 Product Activation Keys Free 2019
- How to active Windows 8 without product key
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019

Namespace planning describes the activity companies go through to determine the public connectivity points that will be offered to clients that wish to access email services through the Internet and how those connections will be secured. The most basic situation occurs when a single connectivity point such as is used to access all Exchange services, including ActiveSync for mobile clients, Outlook Anywhere, Outlook Web App and Exchange Administration Center for browser access, and Exchange Web Services. Because Exchange uses Secure Socket Layer (SSL)-based client–server connections across the Internet, you also need to install certificates to prove that the services are offered by the company and not by an imposter. Exchange Server 2013 Inside Out: Connectivity, Clients, and UM contains a more comprehensive description of how the Exchange 2013 CAS uses certificates.

Self-signed certificates

When you install Exchange 2013 on a server, Exchange automatically creates three self-signed certificates (Figure 1) to enable the server to communicate with other servers and clients within the organization. However, only other Exchange servers in the organization automatically trust the self-signed certificates presented by a server. Self-signed certificates that Exchange creates include the server name and its FDQN in the Subject Alternate Name field and last for five years. The biggest advantage of a self-signed certificate is that it is free, but aside from providing the basis for testing inside an organization, that is its only advantage.

A screen shot showing the Get-ExchangeCertificate command being run to display information about the three default certificates installed on an Exchange 2013 server.

Figure 1. Viewing the self-signed certificates on an Exchange 2013 server

Some companies have deployed self-signed certificates into production because they want to avoid the cost of buying certificates signed by an external vendor. This is a regrettably short-sighted step because saving the relatively low cost of the certificate cannot justify the security exposure that a self-signed certificate can create. Indeed, an Australian researcher reported in July 2012 how Android and Apple iOS devices might fall victim to a man-in-the-middle attack by using ActiveSync when self-signed certificates were used. The attack could result in wiping out device contents. All Exchange 2013 deployments that offer services through the Internet should buy and install the certificates necessary to secure the services.

Security alert: Limitations with self-signed certificates

A self-signed certificate can be used with all Exchange communications within the firewall and supports some external connections (Outlook Web App and ActiveSync) after the certificate has been copied into the trusted root certificate store on the client computer. Some mobile devices don’t permit this, so you can’t use these devices with self-signed certificates. However, you cannot use these certificates to secure Outlook Anywhere connections. Microsoft Outlook 2007 accepts self-signed certificates used for internal communications quietly in that it doesn’t display any errors when they connect to an Exchange 2010 server. Outlook 2010 and Outlook 2013 are more cautious and signal a potential problem to a user (Figure 2).

A screen shot showing the Security Alert flagged by Outlook 2013 when it discovers that the security certificate installed on the Exchange server to which Outlook is connected is not trusted.

Figure 2. Outlook 2013 flagging a problem with a self-signed certificate

In most cases, because of the limitations imposed on the supported functionality and the difficulty of managing the certificates over time, self-signed certificates are used for test deployments or deployments that do not support external client connectivity only.

Using the Exchange 2013 CAS to handle connections

If you run Exchange 2007 or Exchange 2010 today and want to introduce Exchange 2013 at some point in the future, you must bring Exchange 2013 CAS servers into operation. The recommended approach is to have the Exchange 2013 CAS take over the namespace (for example, for the organization so that it then works with its Exchange 2007 or Exchange 2010 counterparts to route incoming client connections to the correct mailbox servers. The Exchange 2007 and Exchange 2010 servers must first be updated to enable them to coexist with Exchange 2013 inside the organization.

In many companies, the usual approach to handle incoming connections is to deploy a load balancer in front of the CAS. (For the purposes of this section, “CAS” means either an individual CAS or a member of a CAS array in an Internet-facing site.) It doesn’t matter whether the load balancer operates at layer 4 (now supported by Exchange 2013) or layer 7. What does matter is that the load balancer will pass incoming client connections to the CAS.

At this point, the CAS has to decide where to direct the connection. The location of the destination mailbox determines how processing proceeds. If the mailbox is on an Exchange 2013 Mailbox server, the CAS can proxy the connection direct to that Mailbox server without any problems. However, if the mailbox is on an Exchange 2007 or Exchange 2010 server, the CAS has to use an HTTP proxy or redirection to transfer the connection to an Exchange 2007 or Exchange 2010 CAS, which then takes responsibility for making the final connection to the mailbox.

The proxy from the Exchange 2013 CAS uses Kerberos to communicate with its earlier counterparts, and the destination is the RPCproxy or Outlook Anywhere endpoint (the /rpc virtual directory in Internet Information Services [IIS]), which requires secured connections. If you configure Basic Authentication for Outlook Anywhere, IIS enables only Basic Authentication on the /rpc virtual directory. For this reason, IIS has to be updated to support Integrated Windows Authentication (IWA—previously known as NTLM) connections; otherwise, Kerberos won’t work. However, if you were to modify IIS to support IWA, Exchange would overwrite it and incur the side effect of changing the authentication mechanism that clients use to connect to the CAS, which is probably not what you want to happen.

The workaround is reasonably simple—you run the Set-OutlookAnywhere cmdlet in the Exchange Management Shell to update IIS on all your older CAS servers so that internal (between CAS) connections are authenticated with Kerberos, and external (client) connections continue to use BASIC. The command is as follows:

Set-OutlookAnywhere –Name ExCAS01 –ClientAuthenticationMethod Basic –IISAuthenticationMethods Basic, NTLM

If you’ve already decided to enable NTLM for Outlook Anywhere, you don’t need to make any changes to IIS. However, even if this is the case, you still need to consider how the Exchange 2013 CAS proxies connections to other CAS servers located in internal or non-Internet-facing sites (that is, without a direct connection to the Internet through a firewall and so on).

This requirement does not exist for previous versions of Exchange, so it’s unlikely that Outlook Anywhere is enabled on CAS servers in non-Internet-facing sites because they do not expect to process incoming Outlook Anywhere connections. However, if the Exchange 2013 CAS has to proxy an incoming connection because the target mailbox is on a server in an internal site, the proxy is to the Outlook Anywhere endpoint. It therefore follows that the CAS servers in these sites need to be updated by running the Enable-OutlookAnywhere cmdlet so that they can accept the incoming proxy to their Outlook Anywhere endpoint with NTLM authentication enabled.

The case for protocol-specific namespaces

Perhaps the Exchange developers were unaware of the law of unintended consequences when they decided to change the Exchange load-balancing requirement from layer 7 to layer 4 of the network stack. In most situations, the change is good. For some, especially those responsible for deployments that have to cater to large numbers of incoming client connections, it creates an interesting question about protocol handling that deserves some attention during the planning for the implementation of Exchange 2013.

Anyone dealing with high-end deployments based on Exchange 2007 and Exchange 2010 is very aware of the need to manage incoming connections carefully. Typically, the solution involved a hardware-based load balancer (running on physical or virtual hardware) that terminated the incoming SSL connection and then sent it on to one of an array of CAS servers that then processed the connection and directed it to the correct mailbox server. Usually, this worked, albeit at the expense of having a load balancer and some complexity in ensuring proper client connection affinity.

Exchange 2013 greatly simplifies matters. You still need to deploy hardware-based load balancers when high availability for client connections is required, but Exchange 2013 supports solutions such as Windows NLB and round-robin balancing to handle lower-end deployments. All this is because the Exchange 2013 CAS doesn’t do the rendering and protocol handling that its predecessors did. Instead, the Exchange 2013 CAS simply proxies connections to the appropriate mailbox server, which does all the real work. The idea is to break the version linkage that previously existed between CAS and mailbox insofar as you couldn’t upgrade one without the other. Version independence is a big theme for future versions of Exchange, and if all goes well, you’ll be able to upgrade different parts of the infrastructure in the knowledge that the new components won’t break anything running on the old bits.

Simplification is always good in computer technology because complexity invariably leads to additional cost, confusion, and potentially poorer results. However, any change has consequences, and one consequence that flows from the move to L4 is the loss of protocol awareness. When a load balancer terminates an incoming SSL connection at L7, it can sniff the packets and discover the protocol to which the connection is directed. Exchange offers a rich set of protocols and services, including Exchange Web Services (EWS), Outlook Web App, ActiveSync (EAS), the Offline Address Book (OAB), and Exchange Administration (ECP), each of whose endpoint is represented as an IIS virtual directory. However, when an L4 load balancer handles a connection, it sees it going to TCP port 443 and the IP address for the external connectivity point (such as Later, the CAS will sort out the connection and get it to the right place, but that’s too late to have any notion of protocol.

- Installing Exchange 2013 : Security groups and accounts Exchange creates
- Installing Exchange 2013 : Versions, cumulative updates, and service packs (part 2) - Object versions, Reporting licenses
- Installing Exchange 2013 : Versions, cumulative updates, and service packs (part 1) - Cumulative updates, Version numbers
- Exchange Server 2013 : Deploying an Exchange 2013 server (part 3) - Recovering a failed server
- Exchange Server 2013 : Deploying an Exchange 2013 server (part 2) - Setup logs, Uninstalling Exchange
- Installing Exchange 2013 : Deploying an Exchange 2013 server (part 1) - Running Setup
- Installing Exchange 2013 : Creating the Exchange 2013 organization
- Installing Exchange 2013 : Types of Active Directory deployment that support Exchange
- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 4) - General Application Settings, Apps, Navigation
- Sharepoint 2013 : Welcome to the Central Administration Web Site (part 3) - Backup and Restore, Security
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
programming4us programming4us
Popular tags
Video Tutorail Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8 BlackBerry Android Ipad Iphone iOS