Pro Exchange 2013 SP1 PowerShell Administration: For Exchange On-Premises and Office 365 (2014)
Chapter 3. Exchange 2013 Client Access Server
The Client Access server role is the most important role in any Exchange deployment because it provides access for all mail clients to the mail data. Without a Client Access server you will have no access to your data. As someone from the Microsoft Exchange product group once said during a conference, “You can have the most beautiful and redundant Mailbox server environment with a DAG and everything, but without a Client Access server you cannot access it and it’s useless.”
And that's true. The Client Access server is used by all clients, whether they connect from the internal network or from the Internet. And whether they are Outlook clients or browser-based clients, or POP3 and IMAP4 clients, all clients connect to the Client Access server and then are routed to the correct Mailbox server.
So, whenever a Mailbox server is used, a Client Access server needs to be used as well. This can be on the same server as the Mailbox server, but it can also be a dedicated server.
The Client Access server consists of the following roles or services:
· Client Access Front End (CAFE), which is used to authenticate client requests and proxy connections to the correct Mailbox server.
· Front End Transport Server (FETS), which is used to accept inbound SMTP messages from other SMTP hosts. FETS can also be used to route outbound messages to other SMTP hosts, but this is optional.
· Unified Messaging Call Router (UMCR), which is used to redirect inbound voice calls (using the Session Initiated Protocol, or SIP) to the Unified Messaging service on the correct Mailbox server.
Because the Client Access server is nothing more than a proxy server, the Mailbox server also contains Client Access components. Both work together to offer one seamless service. Similarly, FETS is working together with the Transport service on the Exchange 2013 Mailbox server and together they form the “transport pipeline.”
In this chapter we’ll start with an overview of the Client Access technologies: client connectivity and the Client Access Front End role. Next will be a description of the Front End Transport server, and we’ll close this chapter with some words about publishing the Exchange 2013 Client Access servers to the Internet. The Unified Messaging call router will be discussed in Chapter 8.
Overview of Client Access Technologies
Microsoft has made major infrastructural changes to the Client Access server role, ensuring it is possible to use it in a multiple data-center environment. In earlier versions of Exchange Server, this was possible to some extent, but it was far from optimal. Some parts of the technology haven’t changed that much, like the virtual directories, the SSL certificates, and use of the single unified namespace. Other parts have changed significantly, though, like client behavior or Autodiscover. These Client Access technologies are a responsibility of both the Client Access server and the Mailbox server (for example, Autodiscover), so some technologies are covered in the following sections while others are covered in Chapter 4.
Introducing the Client Access Front End Service
In previous versions of Exchange Server (Exchange Server 2007 and 2010), the various server roles were “tightly coupled.” The Client Access server and the Hub Transport server roles needed a high-bandwidth, low-latency network connection with the Mailbox server to facilitate the RPC traffic between them. This worked fine as long as all server roles were located on the same network in the same data center, but when someone was using multiple locations, that user faced some challenges.
One of the objectives in developing Exchange Server 2013 was to create a “loosely coupled” infrastructure whereby the server roles are less dependent on each other and on a good network connection. In Exchange 2013, the servers are no longer tied together using the RPC protocol; rather, they are now more independent and they communicate using the same protocol as the original client connection. But most important, all client protocols are Internet protocols and as such they are easy to route through the network, as well as not being 100 percent dependent on a high-speed, low-latency network connection, as were the previous versions of Exchange Server. Sometimes you hear the comment “Every server is an island,” and that's a good description of this arrangement.
The Client Access server is a domain-joined server in the internal Active Directory forest. The Client Access server comprises three components:
· Client access protocols (HTTP, IMAP4, POP3)
· SMTP Front End Service
· UM call router
Compared to Exchange 2010, all business logic has been removed from the Client Access server and moved to the Mailbox server. At the same time, all the processing and rendering now takes place on the Mailbox server, whereas in Exchange 2010 this took place on the Client Access server.
The result is that the Exchange 2013 Client Access server is a thin and stateless server that handles all incoming connections in a load-balanced configuration. It is not truly stateless, though; the SSL connection is terminated at the Client Access, the client is authenticated, and the client is proxied to the correct Mailbox server or other down-level server. When a Client Access server is lost, all connected clients need to re-authenticate against another Client Access server. The fact that no data is stored on the Client Access server is the reason that Microsoft refers to the Client Access server as “stateless.” Stateless, but not clueless, is a good description here. This service is referred to as the Client Access Front End (CAFE) service.
Since all processing is taking place on the Mailbox server and no longer on the Client Access server, session affinity or persistence is no longer needed on the Client Access server and therefore a layer-4 load balancer can be used in combination with the Exchange 2013 Client Access servers (see Figure 3-1).
Figure 3-1. Protocol flow through the Client Access server and Mailbox server
Note Since the Exchange 2013 Client Access server is a domain-joined server in the corporate forest, it is automatically located on the internal network. An Exchange 2013 Client Access server located in the perimeter network is not supported!
So, all clients on the internal and external networks connect to the load balancer and then to the Client Access server. Outlook Web App, Exchange Administration Console, Outlook Anywhere, Exchange ActiveSync, MapiHttp, and PowerShell all use HTTP as their underlying protocol. All requests are sent to the Internet Information server running on the Client Access server. After authentication, the Client Access server determines which Mailbox server hosts the active mailbox database copy, and the client request is proxied to this Mailbox server.
POP3 and IMAP4 have their own services running on both the Client Access server and the Mailbox server. Again, after authentication the POP3 or IMAP4 service determines the active copy of the mailbox database and proxies the request to this Mailbox server.
SMTP is a bit different. The SMTP connection request is sent to the Client Access server. The Front End Transport service running on the Client Access server proxies the request to a Mailbox server, based on the recipients of the message, which in turn accepts the actual SMTP message. The Client Access server does not accept the message and therefore it does not store any information regarding that message.
When it comes to Unified Messaging (UM), there’s no proxying because of the real-time nature of SIP traffic. When a SIP request is sent to the Client Access server—for example, from a Lync Server 2010 or Lync Server 2013 Front End server—it is accepted by the UM call router running on the Client Access server. The UM call router determines which Mailbox server hosts the active copy of the mailbox database where the recipient is hosted, and it redirects the SIP request to the Unified Messaging service running on that particular Mailbox server. From that moment on, the Lync server communicates directly with the Mailbox server.
The Death of RPC/TCP
Clearly visible in Figure 3-1 is that all major clients are HTTP based and the traditional MAPI (or RPC over TCP) is no longer used. That's right, Outlook clients now connect to the Client Access server only using Outlook Anywhere, sometimes still referred to as “RPC over HTTP.”
But how does Outlook Anywhere actually work? The Outlook client sets up an HTTPS connection with the Exchange 2013 Client Access server. This is a normal HTTPS connection and as such it is fully routable via the Internet. The Client Access server terminates the SSL connection, authenticates the request, and determines the correct Mailbox server to proxy the request to. This means that the connection between the Client Access server and the Mailbox server is also a normal HTTPS connection, although it’s using a different TCP port. The HTTPS connection is then terminated on the Mailbox server—more specifically, on Internet Information Server (IIS) on the Mailbox server—and the AppPool on the back end decapsulates the RPC traffic from the HTTPS stream. A local connection is then set up using local RPC (LRPC) to the Mailbox service running on the Mailbox server.
So, the Outlook client connects to the Client Access server using HTTPS and an SSL certificate is used on the Client Access server for making this connection. Outlook is very sensitive to the type of certificate being used and only accepts normal, preferably third-party Unified Communications (UC) certificates, although UC certificates issued by an Active Directory Certification Authority can be used as well. When using SSL certificates issued by your local Active Directory CA, you have to be careful that all clients and servers trust this CA. If they don’t, the server does not accept the SSL certificate and a certificate warning is shown.
Since the Outlook clients now connect to the correct Mailbox server, it is no longer necessary to use the RPC Client Access server array (also known as CAS array). This CAS array was introduced in Exchange 2010 and was used as the MAPI endpoint for Outlook clients. The FQDN of the CAS array was also the server name that was visible in the Outlook profile. But in Exchange 2013, the RPC CAS array is no longer needed. The FQDN being used in the Outlook profile has been replaced with the mailbox GUID, followed by the default accepted domain name (see Figure 3-2).
Figure 3-2. Instead of the RPC CAS array, the mailbox GUID is shown
The good thing is that this mailbox GUID is unique within the entire Exchange organization. If a mailbox is moved from one server to another, from one database availability group (DAG) to another, or from one data center to another, the mailbox GUID does not change. Therefore, the dreaded message “The Exchange administrator has made a change that requires you to quit and restart Outlook” no longer appears after whatever mailbox move you have performed.
In summary, the advantages of substituting the earlier MAPI client connectivity in Exchange 2013 are:
· There’s a much more reliable connection between the Outlook client and the mailbox.
· The RPC CAS array is no longer needed.
· There’s no more restarting Outlook after moving mailboxes.
· Data center redundancy is made easier.
So, the Client Access server is used to intercept connections from clients and to proxy these connections to the correct Mailbox server. But besides this traffic, there are a couple of other connections that are set up from the Outlook client to the Client Access server:
· Autodiscover
· Exchange Web Services (EWS)
· Offline Address Book downloads
Outlook Anywhere is enabled by default, but it is not configured at all. Therefore, Outlook Anywhere should be configured with the appropriate server name used for the proxy servers. Also, the SSL requirements must be set manually for both internal and external clients. To configure Outlook Anywhere, open the Exchange Management Shell and enter the following command:
Set-OutlookAnywhere -Server AMS-EXCH01 -ExternalHostname webmail.contoso.com
-ExternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod:Basic
-InternalHostName webmail.contoso.com -InternalClientsRequireSsl:$true -InternalClientAuthenticationMethod:Basic
What actually happens is that Outlook Anywhere on Exchange Server AMS-EXCH01 is configured with the external hostname webmail.contoso.com, which is the Client Access server running the RPC proxy service. At the same time, SSL usage is enforced by the -ExternalClientsRequireSsl parameter. The same settings in the command shown above are used for internal clients.
Introducing MapiHttp
In Exchange 2013, the traditional RPC over TCP is no longer used and only Outlook Anywhere running on RPC over HTTPS is used, but it’s still RPC traffic. RPC is an ancient protocol, developed in the 1980s for servers running on a normal and stable network (like in your office) but not on flaky networks like the Internet. Despite the fact that Outlook Anywhere is pretty stable, when you have an intermittent network connection, your HTTPS connection can deal with that but RPC within the HTTPS packets probably cannot.
Microsoft Exchange can work perfectly with HTTPS connections. Look at ActiveSync, for example, or OWA; they can work fine on a flaky network like the Internet. If you lose the Internet connection for a small period of time because you’re connecting to another wireless network, OWA continues to work. The same is true for ActiveSync. You can travel throughout the country without noticing that your mobile device is switching networks all the time.
Another issue with Outlook Anywhere is that it relies on the RPC proxy service on the Windows Server. As such, the RPC Proxy service is not a responsibility of the Exchange Product Group at Microsoft but is of the Windows Product Group at Microsoft. Now you may think this is not a big deal, but consider this. When a bug is discovered in Outlook Anywhere and it turns out to be an issue with the RPC Proxy service, the Exchange product group needs to submit an incident to the Windows product group and hope the latter will fix the problem. Needless to say, this is a less than desirable situation.
To overcome this problem, Microsoft has developed a new protocol called MapiHttp, which is basically native HTTPS traffic. The Outlook client is no longer using RPC for its MAPI communication but instead is using HTTPS directly. The same is true for the Exchange server, which also no longer uses RPC. The difference is shown in Figure 3-3.
Figure 3-3. The difference between Outlook Anywhere (RPC/HTTPS) and MapiHttp
You can imagine that changing protocol usage like this has a tremendous impact from an engineering perspective, both on the Exchange server and on the Outlook client. That’s the reason that right after the release of Exchange 2013 SP1, the only client supporting MapiHttp is Outlook 2013 SP1. At the moment of this writing it is unknown if Microsoft is going to release a (major) update for Outlook 2010 that could support MapiHttp. When it comes to Outlook 2007, I personally do not expect an update supporting MapiHttp. From a version perspective, this product is too old and not worth the investment at this point.
MapiHttp is enabled on a global level; you enable it in the entire organization at one moment. To enable MapiHttp, open the Exchange Management Shell and enter the following command:
Set-OrganizationConfig -MapiHttpEnabled $TRUE
Please note that it can take several hours for this change to take effect.
For the MapiHttp protocol, Microsoft introduced a new virtual directory on the Exchange 2013 SP1 Client Access server: the MAPI virtual directory. The MAPI virtual directory should be configured with the correct values for the InternalURL, ExternalURL, and IIS authentication properties. This can be achieved in EMS using the following command:
Get-MapiVirtualDirectory –Server AMS-EXCH01 | Set-MAPIVirtualDirectory –InternalURL https://webmail.contoso.com/mapi -ExternalURL https://webmail.contoso.com/mapi
-IISAuthenticationMethods Basic
When all is configured, clients running Outlook 2013 SP1 will pick up this change using Autodiscover. The client will be reconfigured, basically the Outlook Anywhere settings will be removed from the Outlook Profile, and when finished the Outlook client will need to be restarted. The user will see a popup window as shown in Figure 3-4.
Figure 3-4. The restart Outlook popup message
Outlook 2013 SP1 will send an Autodiscover request to the Exchange 2013 SP1 Client Access server, and one of the additions in SP1 is that it adds a MapiHttp capability to this request. In return, the Client Access server sends the MapiHttp configuration back to the Outlook client. Since it can take some time before the Outlook client sends an Autodiscover request to the Client Access server, it can also take some time before Outlook “realizes” it has to reconfigure its profile and thus needs to be restarted.
For testing purposes, it is possible to temporarily change this behavior using the following registry key on the Outlook 2013 SP1 client:
[HKEY_CURRENT_USER\Software\Microsoft\Exchange]
"MapiHttpDisabled"=dword:00000001
To implement this registry key on your workstation, you can use the following PowerShell command:
New-ItemProperty -Path 'HKCU:\Software\Microsoft\Exchange' -Name MapiHttpDisabled -Value 1
-PropertyType DWORD
This will prevent Outlook from advertising its MAPI over HTTP capability in the Autodiscover requests, and Outlook will revert to using Outlook Anywhere. To allow Outlook 2013 SP1 to use the MapiHttp protocol again, simply delete the MapiHttpDisabled DWORD in the registry or set its value to “0.”
For more information, you can check the “What’s New in Outlook for Office 2013 SP1” article on the Microsoft website, http://bit.ly/OL2013SP1.
Client Connectivity
An Exchange 2013 Client Access server is interesting; in short, it’s pretty useless without email clients. There are several email clients available that work with Exchange 2013; for example:
· Outlook clients
· Web-based clients
· Mobile clients
· POP3 and IMAP4 clients
These types of clients are treated in detail in the following sections.
Outlook Clients
One of the most important changes in Exchange Server 2013 is that Outlook no longer uses direct MAPI (RPC over TCP); Exchange Server 2013 is only accessible using Outlook Anywhere, using RPC over HTTPS. The reason for this change is the loose coupling of the Exchange 2013 server roles, as explained in Chapter 1. Direct MAPI is pretty rigid and requires a fast and reliable network connection. Also, routing issues when multiple data centers are used contributed to this decision for change. So, only RPC over HTTPS, also known as Outlook Anywhere, is always used by Outlook clients, both internally and externally.
A new protocol in Exchange 2013 SP1 is MapiHttp, which will slowly replace Outlook Anywhere as the primary protocol for Outlook. Initially, Outlook 2013 SP1 is supported, but over time MapiHttp will be supported by the latest version of Outlook 2010 as well. MapiHttp is discussed in the previous section of this chapter.
I already mentioned Outlook 2013, but Outlook 2010 SP1 (with April 2012 Cumulative Update) and Outlook 2007 SP3 (with July 2012 Cumulative Update) are also fully supported in combination with Exchange Server 2013; but again, they are supported only with Outlook Anywhere. Outlook 2007, 2010, and 2013 rely heavily on the Autodiscover functionality. Autodiscover is used not only for creating the Outlook profile during the initial startup of the Outlook client but also once an hour to request the latest configuration information from the Exchange 2013 server.
Outlook 2007, 2010, and 2013 also rely heavily on IIS. Using the Exchange Web Services (EWS), the Outlook client can request free/busy information or set an out-of-office message; the Offline Address Book is also downloaded via a normal IIS connection. The tricky part here is that when Autodiscover is not functioning correctly, the Outlook client will not get the appropriate information from the Exchange 2013 server, resulting in a non-working EWS environment, for example. Since HTTPS is playing such an important role in an Exchange 2013 environment, SSL certificates play an even more important role than in previous versions of Exchange Server. Not having a proper SSL certificate on the Exchange 2013 CAS will result in Outlook clients not connecting at all.
As mentioned in Chapter 1, Outlook 2003 clients are no longer supported. It’s not only unsupported, it’s also not working, so the oldest supported Outlook client working against an Exchange Server 2013 environment is Outlook 2007.
Outlook clients can run in cached mode, or in online mode where cached mode is the default (and preferred) mode. When run in cached mode, Outlook works with a copy of the mailbox on the local machine and all changes are made to this “cached” copy. Outlook automatically synchronizes this copy in the background with the mailbox on the Exchange Server. All processing takes place on the Outlook client’s workstation, not on the Exchange Server, thereby reducing processor cycles and (expensive) disk I/O on the Exchange Server.
Please note that Outlook 2007 and Outlook 2010 will store a complete copy of the mailbox on the workstation’s hard disk when running in cached mode. Outlook 2013 can be adjusted using the “slider bar” to prevent creating a full copy of the user’s mailbox on the local hard disk.
When run in online mode, Outlook works directly against the Exchange Server and there’s no copy of the mailbox on the local workstation. It’s obvious that this will increase the load on the Exchange Server, plus the Outlook client will always need to be online. Offline working—for example, while traveling—is not possible in this scenario. Outlook running in online mode can be seen when used in a terminal server environment, although Outlook 2010 running in cached mode on a terminal server is fully supported nowadays.
Web-Based Clients
Web-based clients are becoming more and more important, and because of the increasing functionality and user friendliness, are easier to work with. The primary web-based client is Outlook Web App (OWA). This is driven by Office 365 because OWA was developed by the Microsoft Exchange product team, while Outlook was developed by the Microsoft Office product team. It’s easier for the Microsoft Exchange product team to release updates for OWA than it is for the Office team to do likewise for Microsoft Outlook.
There are various web-based clients and protocols available in Exchange 2013:
· Outlook Web App (OWA)
· Exchange Admin Center (EAC)
· Exchange Web Services (EWS)
· Office Web Apps
· Mobile clients
· POP3 and IMAP4
These are discussed in more detail next.
Outlook Web App
Outlook Web App, or OWA, is the webmail client for Exchange Server 2013. A native part of Exchange 2013, it offers a rich client and a very similar look and feel as Outlook 2013. At the same time, OWA has a consistent view across different browsers on different operating systems. You can run OWA on IE11 and get the same user experience as when running OWA in a browser on an iPad or on Windows surface. The Microsoft Exchange Team blog contains an interesting posting about OWA running on different devices; see http://bit.ly/OWARocks.
New in Exchange Server 2013 is the option to use OWA offline, and integrated apps for OWA enrich the user interface and offer additional functionality.
Microsoft is offering cross-browser supportability, so besides Internet Explorer, also Mozilla Firefox 17 or later, Google Chrome 24 or later, and Apple Safari 5 or later are fully supported for use with Exchange Server 2013. Of course, the latest versions of these browsers support most features, but for an up-to-date overview of available functionality per browser version, please navigate to the Microsoft Technet site at http://bit.ly/OWAWhatsNew.
OWA Offline
In the past, a commonly heard feature request was the ability to use OWA offline. This is now possible with Exchange Server 2013. For this feature to work you need at least Internet Explorer 10, Safari 5.1(Mac only) or later, or Chrome 24 or later.
If your browser is capable of supporting offline OWA, it’s just a matter of selecting “Offline settings” from the settings menu in OWA, as shown in Figure 3-5, and you’re ready to go.
Figure 3-5. To enable offline usage in OWA
Not all information is available in OWA offline. It is comparable to, for example, the amount of information available in Windows Phone. Only three days of email (or 150 items, whichever is larger) will be available, as will the current and next month of calendar information; there are no archive folders, for example.
The browser determines where to store the offline information, and this poses a security risk. Anyone who has access to the PC where OWA offline is used also has access to this information, so it should not be used on a PC that is shared by multiple users.
Outlook Apps
New in Exchange Server 2013 is the concept of apps. Apps on the Exchange Server are integrated in OWA and Outlook 2013, and they give the user added functionality. For example, there is a default Bing Maps App (see Figure 3-6). If there’s a street address in an email, the Bing Maps app can look it up and provide additional information regarding the address, such as the location on a map or directions to the site. At the time of this writing, only U.S. addresses are recognized, but Microsoft is actively working on world regional support.
Figure 3-6. Bing Maps shows the address in an email app
By default, there are five apps available out of the box: Action Items, Bing Maps, My Templates, Suggested Meetings, and Unsubscribe. These are globally enabled by default.
The Exchange administrator has the option to add, remove, disable, or enable apps in the EAC as a global setting (see Figure 3-7), but the user can also install, enable, or disable apps in the EAC.
Figure 3-7. The out-of-the-box apps are enabled by default
Additional apps are available in the Office Store. Microsoft also encourages independent software vendors (ISV) to write additional apps and distribute them through the Office Store.
Exchange Admin Center
The Exchange Admin Center is the web-based management interface for Exchange 2013. You can access the EAC using your browser by navigating to a URL like https://webmail.contoso.com/ecp. The name of the EAC virtual directory is actually ECP, a leftover from the past when it was called Exchange Control Panel in Exchange 2010.
The EAC is accessible for everyone, both users and Exchange Administrators. Depending on the permissions granted to the account, you can have a variety of functions available. Normal users have very limited permissions; they can only manage their own user and mailbox properties. The Exchange Administrators can manage most of the functions available in EAC. That’s most, but not all, because there are features not available by default, even not for Exchange Administrators like the Enterprise Search function, for example, and permissions are controlled via role-based access control (RBAC), which is discussed in Chapter 10.
It is possible to completely turn off the EAC. In an Exchange Management Shell window, enter the following command to turn off EAC for a particular server:
Set-ECPVirtualDirectory -Identity "AMS-EXCH01\ecp (default web site)" -AdminEnabled $false
Note You have to be very careful when changing this setting. When you do, it’s no longer possible to manage the Exchange environment using the Graphical User Interface and the only management option you have then is the Exchange Management Shell.
Exchange Web Services
The Exchange Web Services is not a client but a protocol. Clients like Outlook 2007 and later use Exchange Web Services to retrieve additional information from the Exchange server, like free/busy. Also, the out-of-office settings on an Exchange server are controlled by an Outlook client via Exchange Web Services.
Another well-known client that relies heavily on the Exchange Web Services is Outlook for Mac, a version of Outlook that’s actually completely built on top of Exchange Web Services. As such, it’s not using MAPI or Outlook Anywhere. The Exchange Web Services is not a fast and efficient protocol for a mail client, and the downside of this is that Outlook for Mac isn’t fast, either. Even worse, if you have a lot of Outlook for Mac clients communicating with your Exchange 2013 Client Access server, you’ll see a dramatic increase in processor usage and disk I/O (in general, caused by writing to IIS log files).
Exchange Web Services can be leveraged for developing your own client applications, and these can also be PowerShell scripts. To achieve this, you have to install the Microsoft Exchange Web Services managed API, which can be downloaded fromhttp://bit.ly/EWSAPIDownload. More information, including code samples, can be found on the MSDN Office | Dev Center—in particular, the “Explore the EWS Managed API” page at http://bit.ly/ExploreEWS.
Office Web Apps
In Exchange Server 2010, it was possible to use the attachment preview functionality in OWA. On the Exchange 2010 server, a technique called WebReady document viewing provided this function.
In Exchange Server 2013, the attachment preview function is still available, but instead a complete new server application, called Office Web Apps server 2013, may be used to render the actual document and send the HTML information to the OWA client. When an OWA client wants to preview an attachment, the request is forwarded to an Office Web Apps server. Exchange Online users in Office 365 have this function available by default; for an Exchange on-premises deployment, an additional dedicated Office Web Apps server is needed.
Installing and configuring the Office Web Apps server is beyond the scope of this book, but you can find more information on how to do this at http://bit.ly/WebApps2013 - Office Web Apps 2013.
When the Office Web Apps server is up and running, the Exchange 2013 environment can be configured. The first step is to enable it on an organizational level in Exchange 2013. You can use the following command in the Exchange Management Shell to achieve this:
Set-OrganizationConfig –WACDiscoveryEndpoint https://webapps.contoso.com/hosting/discovery
Note WAC is an acronym for Web Access Companion, a code name used when developing the Office Web Apps server.
When this is set on the organizational level, you can configure the OWA virtual directories for using the Office Web Apps server. You can configure the OWA virtual directories using the following commands in EMS:
Get-OWAVirtualDirectory –Server AMS-EXCH01 | Set-OWAVirtualDirectory
-WacViewingOnPublicComputersEnabled $true -WacViewingOnPrivateComputersEnabled $true
If you want to force users to the Office Web Apps, you can use the -ForceWacViewingFirstOnPublicComputers and -ForceWacViewingFirstOnPrivateComputers options:
Get-OWAVirtualDirectory –Server AMS-EXCH01 | Set-OWAVirtualDirectory
-WacViewingOnPublicComputersEnabled $true -ForceWacViewingFirstOnPublicComputers $true
-WacViewingOnPrivateComputersEnabled $true -ForceWacViewingFirstOnPrivateComputers $true
To check if the configuration change was applied successfully, you can enter the following commands:
Get-OrganizationConfig | select WACDiscoveryEndPoint
Get-OWAVirtualDirectory | Select Server,*WAC*
The output of these commands is shown in Figure 3-8.
Figure 3-8. Configuring the OWA virtual directory for use with Office Web Apps
When you have configured this in your Exchange 2013 environment, and you receive an email message with Microsoft Office documents attached, you can open these in your browser without having a local installation of Microsoft Office on the workstation you’re using. This can be valuable when reading email on a nontrusted workstation—for example, in an Internet café.
Mobile Clients
Exchange ActiveSync (EAS) is the protocol used by mobile clients connecting to the Exchange 2013 environment over the Internet. This includes Windows Phone clients, iOS clients like iPhone and iPad, and Android clients. Also, the Mail client on Windows 8 (i.e., Windows 8 running on a tablet) uses EAS to retrieve mail data from the Exchange 2013 server.
Microsoft is licensing the EAS protocol and its interfaces to third parties and independent software vendors. It is up to the vendor to write actual applications to use the EAS protocol. One of the problems with this is that Microsoft “forgot” to enforce standard implementations or quality control. Therefore, each vendor has its own interpretation of using the EAS protocol, resulting in some applications that run fine but others that are horrible to use. Additionally, there are applications that have a major performance impact on the Exchange 2013 server. For example, there are several known problems with iOS applications that result in poor performance or corrupt items in a user’s mailbox, such as acceptance of recurring appointments, a common task users perform. Unfortunately, the (older) iOS client cannot handle this well.
Mobile clients are typically very sensitive when it comes to SSL certificates, and not all SSL certificates are accepted by mobile clients. To get EAS working properly, there needs to be a supported third-party SSL certificate.
Most mobile clients rely on the Autodiscover function of the Exchange 2013 server, as do Outlook clients, so again having a fully working Autodiscover environment is prerequisite for running EAS successfully.
A new development for mobile clients is the use of special mail apps—for example, those for the iPhone and iPad. These are apps built by Microsoft, but instead of using Exchange ActiveSync, they are running on top of OWA. Unfortunately these apps are available for use only with Office 365 at this point, and it is unknown if they will become available for the regular on-premises Exchange 2013 server. The reason for their not being available for Exchange 2013 on-premises is that these clients need a special subscription, a subscription that’s not available in on-premises Exchange 2013 servers. More information can be found at http://bit.ly/OWAforIPhone.
POP3 and IMAP4
Although still widely used and still under active development, POP3 and IMAP4 are not commonly employed in a Microsoft environment. POP3 and IMAP4 are primarily used in (low-cost) hosting environments running some UNIX flavor, but they can also be configured for use on Exchange Server 2013. There are also business applications that can access a particular mailbox using the POP3 or IMAP protocol to retrieve messages.
POP3 and IMAP4 are installed on the Exchange 2013 server by default, but the relevant services are set to “manual start,” so if they are needed, the POP3 or IMAP4 service has to be reset to “automatically start.” Also, the authentication (encrypted login or plain text login) needs to be set. Exchange Server 2013 allows the basic POP3 and IMAP4 protocol, but also allows the encrypted version—that is, POP3S (POP3 over SSL) and IMAPS (IMAP4 over SSL).
Note The POP3 and IMAP4 protocols are only used for retrieving messages. The mail client should be configured for sending outbound mail via a SMTP mailhost. Of course, this can be the Exchange 2013 Client Access server running the Client Front End connector.
Namespaces
Namespaces play an increasingly important role in Exchange Server; this started with the introduction of Autodiscover and its namespace in Exchange 2007.
A namespace is a domain name used by clients to access the Client Access server to access the Exchange environment. An example of a namespace can be webmail.contoso.com, for example.
Browsers can use webmail.contoso.com/owa to access Outlook Web App, mobile devices can use webmail.contoso.com/Microsoft-Server-ActiveSync to retrieve content from the mailbox, and Outlook Anywhere can use webmail.contoso.com as the RPC proxy server.
An additional namespace being used in an Exchange server environment is autodiscover.contoso.com. This is used by Outlook clients to send the Autodiscover requests to the Client Access server.
The minimum number of namespaces in an Exchange environment is two: the protocol namespace and the Autodiscover namespace, as mentioned above. It is possible to add more protocol-specific namespaces. I have seen customers use smtp.contoso.com to set up an encrypted partner—send connector, for example. Another well-known namespace is pop.contoso.com for POP3 or IMAP4 clients.
Note In Exchange 2010, there was another namespace used by the RPC Client Access service, something like outlook.contoso.com. This namespace was implemented by using the Client Access service array and was used by internal Outlook clients as the RPC endpoint. Since RCP/TCP is no longer used in Exchange 2013, the RPC CAS array is no longer used.
Namespaces are important to consider, especially when using multiple data centers. Another important factor is SSL certificate usage. More namespaces automatically means more domain names on your SSL certificate. In a typical environment the webmail.contoso.com andautodiscover.contoso.com namespaces are used, and therefore these are the only names that need to be configured on the SSL certificate.
From a load-balancing perspective as well, namespaces are an important factor to consider. In Exchange 2013, the only stateful connection that’s used is between the Client Access server and the Mailbox server where the user’s mailbox resides. All rendering now takes place on the Mailbox server and no longer on the Client Access server, as in Exchange 2010. Therefore a stateful connection between the client and the Client Access server is no longer required and thus a layer-4 load balancer can be used.
A layer-4 load balancer cannot do any content inspection and therefore cannot determine which protocol is used in a particular namespace. For example, a load balancer on layer-4 cannot determine whether a request is for Exchange Web Services, the MAPI Virtual Directory, or Active Sync; it only knows the namespace webmail.contoso.com. As a result, the load balancer cannot check the individual service’s health.
It is possible to work around this by terminating the SSL connection at the load balancer, do the content inspection of the incoming traffic, and re-encrypt the traffic. In Exchange 2013 SP1, SSL offloading is fully supported by Microsoft, so this is no longer an important factor. Both SSL offloading and load balancing are discussed later in this chapter.
Another important namespace comes into play during a transition from Exchange 2007 to Exchange 2013 and you have to build a coexistence scenario, as explained in the previous chapter. Since Exchange 2013 cannot proxy client requests to the Exchange 2007 Client Access server, the request needs to be redirected to the Exchange 2007 Client Access server. Therefore, the Exchange 2007 Client Access server needs an additional unique namespace and in all Microsoft documentation the namespace legacy.contoso.com is used. Please note that this naming convention is not required; you can use any namespace to assign to the Exchange 2007 Client Access servers.
Split-DNS
In the previous section, namespaces were briefly discussed but these were external namespaces—that is, namespaces used by clients that do not reside on the internal network. Internal clients need to connect to the Exchange 2013 environment as well, so namespaces are also used on the internal network.
When an Exchange 2013 Client Access server is installed, it is typically accessed using its fully qualified domain name (FQDN), which can be something like:
· Ams-exch01.contoso.com
· Ams-exch02.contoso.com
· Lon-exch01.contoso.com
While these are all valid names and can be safely used, it makes life much easier if the same namespace is used on the internal as on the external network—that is, webmail.contoso.com. Using one namespace is not only clearer, there’s also no need to use additional names on an SSL certificate.
When webmail.contoso.com is used from the Internet, the external IP address of the load-balanced array of Client Access server is resolved—for example, 176.62.196.244. When webmail.contoso.com is used on the internal network, the IP address of the internal load-balanced array of Client Access server is resolved, as in 10.38.96.244.
This configuration is called a split-DNS, or split-brain DNS, configuration and is the recommended approach for namespace planning.
Single Common Namespace
One of the advantages of the loosely coupled architecture of Exchange 2013 is its unified namespace. It is now possible to use only one or two namespaces for the entire Exchange organization. It is even possible to use only one namespace like webmail.contoso.com for all Exchange servers, even if there's worldwide deployment.
For example, a user called John logs on to webmail.contoso.com when he's in Amsterdam. This is where his mailbox is located. He is authenticated by the local Exchange 2013 Client Access server and his request is proxied to the appropriate Mailbox server, also in Amsterdam.
When John is traveling to New York, he still accesses webmail.contoso.com. The Geo-DNS solution resolves to a local Exchange 2013 Client Access server where his request is authenticated. The Client Access server detects that John’s mailbox is located in Amsterdam, and thus proxies the request, over the internal network, to the Mailbox server in Amsterdam (see Figure 3-9).
Figure 3-9. A single, common namespace using a Geo-DNS solution
Virtual Directories
By now it should be clear that Exchange 2013 uses the HTTP protocol extensively. The following Exchange 2013 services have their own virtual directories, which are also visible in the IIS Manager:
· Autodiscover (/Autodiscover)
· Outlook Web App (/OWA)
· Exchange Admin Console (/ECP)
· Exchange Web Services (/EWS)
· Exchange ActiveSync (/Microsoft-Server-ActiveSync)
· Offline Address Book (/OAB)
· Remote PowerShell (/Powershell)
· RPC Proxy (/RPC)
· MAPI (/Mapi)
For regular maintenance, the IIS Manager is not used at all; all Exchange 2013 maintenance is done using PowerShell (EMS) or EAC. When using EMS, you can configure every little detail of the Exchange 2013 virtual directories, but in EAC, only the most important parts of the virtual directories can be configured, so EMS is the preferred management interface.
Each virtual directory has a number of properties, and the internalURL and externalURL properties are the more important ones. These properties are stored in Active Directory, and they determine which URL the various clients use when accessing the services. This can be via the Internet (externalURL) or via the internal network (internalURL).
For OWA and EAC, it's not a big deal. You can use any URL to access OWA as long as the name is resolved to the IP address of the Client Access server. You'll see a certificate warning that the name in the request does not match the name on the certificate, but other than that, you can access the service.
For Outlook clients and mobile clients, it's different because these clients get their Exchange configuration via Autodiscover. And if something is configured incorrectly, the wrong data is returned to the client and the client in turn cannot connect to the various services.
When the Exchange 2013 Client Access server is installed, none of the virtual directories is configured properly with the internalURL and externalURL:
· The value of the internalURL property is set to the FQDN of the Client Access server, like ams-exch01.contoso.com.
· The value of the externalURL property is left blank during installation of the Client Access server.
As explained in the previous section, Microsoft recommends using a split DNS scenario whereby both internally and externally the same URL is used, such as webmail.contoso.com. When a split DNS scenario is used, you can provide the following EMS commands to configure the internalURL and the externalURL properties:
Set-OWAVirtualDirectory -Identity AMS-EXCH01 -ExternalURL https://webmail.contoso.com/owa
-InternalURL https://webmail.contoso.com/owa
Set-ECPVirtualDirectory -ExternalURL https://webmail.contoso.com/ecp
-InternalURL https://webmail.contoso.com/ecp
Set-ActiveSyncVirtualDirectory -ExternalURL https://webmail.contoso.com/Microsoft-Server-ActiveSync
-InternalURL https://webmail.contoso.com/Microsoft-Server-ActiveSync
Set-WebServicesVirtualDirectory -ExternalURL https://webmail.contoso.com/ews/Exchange.asmx
-InternalURL https://webmail.contoso.com/ews/Exchange.asmx
Set-OABVirtualDirectory -ExternalURL https://webmail.contoso.com/OAB
-InternalURL https://webmail.contoso.com/OAB
Set-PowershellVirtualDirectory -ExternalURL https://webmail.contoso.com/Powershell
-InternalURL https://webmail.contoso.com/Powershell
Set-MAPIVirtualDirectory –ExternalURL https://webmail.contoso.com/mapi
-InternalURL https://webmail.contoso.com/mapi
If there are multiple Client Access servers, be very careful when configuring the various options in the virtual directories; this is even more critical when using multiple Client Access servers in a load-balanced array. If one of the Client Access servers in the array is misconfigured, you'll see erratic results. This won’t be consistent, though, because the remaining servers might be configured correctly. You'll see problems arise every now and then, and these problems are the toughest to troubleshoot.
Since all communication is going via virtual directories (in IIS) on the Exchange 2013 Client Access server, a lot of logging takes place on an IIS level. The default location of IIS log files is the directory C:\inetpub\logs\LogFiles\W3SVC1, and for an average Exchange 2013 Client Access server, it is not uncommon that hundreds of megabytes of data are stored on a daily basis. This amount of data can quickly fill up the system and boot disk of your Client Access server, so you need to act accordingly.
Fellow Exchange Server MVP Paul Cunningham has written a script that will compress the log files into monthly archives and store the archive files in a central archive location. You can find more information regarding this script and a download option on hisExchangeServerPro.com website at http://bit.ly/IISLogsCleanup.
SSL Certificates
Because Exchange 2013 extensively uses HTTP to communicate between the client and the Client Access server, the SSL certificates are very important. When a Client Access server is installed, a self-signed SSL certificate is created (see Figure 3-10). This self-signed certificate contains only the NetBIOS name of the server as its common name and the FQDN of the server in the “subject alternative name” field. Such a certificate can be used for encryption, but it cannot be used for server authentication, since its issuer (the Exchange server itself) is not trusted by any other machine.
Figure 3-10. The self-signed certificate on a Client Access server
Note An exception to this is the “Default SMTP Certificate” in an Edge Subscription. When the Edge Subscription is created, the thumbprint of the certificate is copied to the Edge Transport server. This in turn is used for server authentication.
For the Client Access server, this self-signed certificate can be used for testing purposes to see if OWA and EAC are working correctly and to configure the server, but it is not meant for production purposes.
A normal SSL certificate has only one name on it; this is the certificate's common name (CN), and it will work perfectly when the server that's configured with this certificate is accessed by a URL that's equal to the common name. For example, a webshop can be accessed using a URL like https://shop.contoso.com and its certificate would have a common name of CN=shop.contoso.com. If this site is accessed with a URL like https://webshop.contoso.com, it will result in a certificate error such as the one shown in Figure 3-11, saying "The security certificate presented by this website was issued for a different website's address."
Figure 3-11. Certificate warning when the URL does not match the certificate's common name
If you select “Continue to this website (not recommended),” you can proceed with access, but you'll see a certificate warning in the navigation bar.
The “problem” with a Client Access server is that this server can be accessed using a normal URL like webmail.contoso.com, but external Outlook clients (that do not have access to Active Directory) automatically try to access the Client Access server using the URLautodiscover.contoso.com. If you have a normal SSL certificate, this attempt will fail because the autodiscover.contoso.com server name does not match the CN=webmail.contoso.com name.
To work around this problem, you can use a Unified Communications (UC) certificate. This UC certificate can hold multiple server names next to its normal common name. These additional server names are stored in an attribute called “subject alternative name.” A typical UC certificate for contoso.com would have a CN=webmail.contoso.com and autodiscover.contoso.com entries. If a split-DNS configuration is used in your environment, these server names are sufficient and this is also according to Microsoft best practices. However, there are plenty of successful Exchange Server installations where the local hostname (for example, ams-exch01.contoso.com) is included in the subject alternative names attribute without any complications. Some organizations see this as a possible security issue and prefer not to include the local hostname in the UC certificate.
A UC SSL certificate can be issued by an Active Directory integrated certificate authority (CA), as shown in Figure 3-12, but this works fine only for other servers and workstations that are members of this particular Active Directory domain.
Figure 3-12. The contoso Unified Communications certificate
These domain members don't have to be connected to the Active Directory domain though, so domain-joined laptops should work fine when you are working at home or in a hotel and connecting via the Internet. Non-domain-joined computers will work fine as well, but you have to add the root certificate of the CA to the local certificate store of the client.
Doing the latter can become challenging when you’re using mobile devices. You can add the root certificate of the CA to these devices, but it takes a considerable amount of work. You have to ask yourself if you want to spend your time on this additional labor or if it would be better to buy a third-party certificate.
The preferred way is to use a third-party certificate from a trusted CA. Both well-known and Microsoft-supported CAs include, for example, Verisign (now owned by Symantec), Entrust, Comodo, and Digicert.
Note A list of all supported SSL certificates can be found in the Microsoft knowledge base article KB929395, “Unified Communications Certificate Partners,” available at http://support.microsoft.com/kb/929395.
Of course, these certificates are not free, but the advantage is that almost all clients support the certificates and there's less certificate management to take care about.
Request a New SSL Certificate
To request a new SSL certificate, log on to the Exchange 2013 Client Access server (or multi-role server, for that matter) as an Exchange Administrator and enter a command in EMS similar to the following:
$Data = New-ExchangeCertificate -FriendlyName "Contoso SSL Certificate" -GenerateRequest
-SubjectName "c=US,o=Contoso,cn=webmail.contoso.com"
-DomainName webmail.contoso.com,autodiscover.contoso.com -PrivateKeyExportable $true
Set-Content -path "\\ams-fs01\management\SSLCertRequest.req" -Value $Data
Note A management server with the Exchange Management Tools installed can also be used to request a new SSL certificate.
You have to use the UNC path when storing the SSL certificate request; EMS (and EAC) do not accept use of a local path like C:\Temp. You can use the contents of this file to request an SSL certificate from the Active Directory integrated CA or from your third-party CA, whichever you prefer. When the SSL certificate is returned from the CA, it is important that you finish the SSL certificate creation from the server you used for generating the initial request. In EMS, again use a command similar to the following to finalize the SSL certificate creation:
Import-ExchangeCertificate –Server AMS-EXCH01 -FileData ([Byte[]]$(Get-Content -Path "\\ams-fs01\management\certnew.p7b" -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate
-Server AMS-EXCH01 -Services IIS
Export an SSL Certificate
When the SSL certificate is installed and configured correctly, you can use the Export-ExchangeCertificate command to create a backup file of the Exchange certificate. This backup file can be stored in a safe location, but it can also be used to import on additional Exchange 2013 Client Access servers.
To create an export file of the SSL certificate, you first have to find out the thumbprint of the SSL certificate. This thumbprint is a unique identifier of the SSL certificate within the Exchange environment. The thumbprint of the SSL certificates is shown when executing a Get-ExchangeCertificate command in EMS, as shown in Figure 3-13.
Figure 3-13. Retrieving the thumbprint of the SSL certificate
To request the properties of the webmail.contoso.com certificate, you can use the following command in EMS:
Get-ExchangeCertificate -Thumbprint 803AD1BD6E8CD3188E7493BFB4DAD679CE094D55 | fl
The following commands can be used to export the SSL certificate and store this export in an export file:
$ExportFile = Export-ExchangeCertificate -Thumbprint FAB97CD9A7A212952524A42C6EEC9807950CC82
-binaryencoded:$true -password (Get-Credential).password
Set-Content -Path \\ams-fs01\management\webmail-contoso-com.pfx -Value $ExportFile.FileData -Encoding Byte
Note The Get-Credential command in the previous example shows a dialog box where credentials can be entered. For the Export-ExchangeCertificate command, only the password is used. Use of this password is a security matter when saving the exported certificate.
Import an SSL Certificate
When you have an exported SSL certificate, you can use PowerShell to import this SSL certificate on additional Exchange 2013 Client Access servers. To do this you can use commands similar to the following in EMS:
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content
-Path \\ams-fs01\management\webmail-contoso-com.pfx -Encoding byte -ReadCount 0))
-Password:(Get-Credential).password | Enable-ExchangeCertificate –Services IIS
Note If you have a load-balanced array of Exchange 2013 Client Access servers, it is important that the SSL certificates used on these servers be identical.
Load Balancing
In the early days of Exchange Server, there was hardly any load balancing, and the Microsoft solution for load balancing was to use Windows Network Load Balancing (NLB). Although NLB works fine, it has some drawbacks:
· NLB is a service in Windows Server, and thus is dependant on the server.
· Scalability of an NLB cluster is not that great and is limited to eight nodes.
· The only option for affinity is source IP.
· When you are adding or removing nodes to or from an NLB cluster, all clients are automatically disconnected and have to reconnect.
· When NLB is used in unicast mode, it is possible that port- or switch-flooding occurs.
· NLB cannot be combined with a database availability group (DAG) on a multi-role server. A DAG is using fail-over clustering software that cannot be combined with NLB software.
· There’s no service awareness, a possible “black hole”
Starting with Exchange Server 2010, Microsoft began recommending the use of hardware load balancers in front of Client Access servers, a recommendation that continues for Exchange 2013.
Note A recommendation to use a hardware load balancer does not mean that use of NLB is no longer supported; this is absolutely not the case. In both Exchange Server 2010 and 2013, use of NLB is fully supported (when not used on servers that are also DAG nodes). It is just not the recommended approach.
In Exchange 2013, layer-4 load balancing is recommended, whereas in Exchange 2010 it was layer-7 load balancing that was recommended. Layer-4 load balancing is a relatively “dumb” load-balancing mechanism because it does not have access to the information within the requests.
Let’s compare load-balancing layers to the OSI model. A layer-7 load balancer is a solution whereby the load balancing takes place on the application layer. The SSL session is terminated at the load balancer and the load balancer can do pretty smart things to the connection, like modifying the HTTP headers or using cookie information in the HTTP stream. This information is then employed to identify the session and make sure the session is always connected to the same Client Access server.
With a layer-4 load balancer, the load balancing takes place on the network layer. An incoming connection is accepted and distributed across multiple Exchange 2013 Client Access servers “as is”—no processing takes place at all. The Client Access server, in turn, accepts the connection and after authentication the connection is forwarded to the appropriate Mailbox server. Since the connections to the Client Access server are stateless, there's no need to worry about affinity. If a Client Access server fails the connection, it is rerouted to another Client Access server. There will be a minor performance penalty, owing to automatic re-authentication, but the connection on the Mailbox server is preserved.
The load balancer is configured with a virtual service, and this virtual service has an FQDN (like webmail.contoso.com) and an IP address. The IP address is referred to as the “virtual IP,” or VIP. A client connects to this VIP and thus connects to the load balancer. The load balancer keeps track of the source IP of the connection request and forwards the request to one of the Exchange 2013 Client Access servers.
Keep in mind that, in a layer-4 load balancer, the SSL connection is terminated at the Client Access server and not at the load balancer. Therefore, the load balancer cannot inspect any of the traffic between the client and the Client Access server. If multiple services, such as OWA, EAC, Outlook Anywhere, PowerShell, and ActiveSync, all use the same VIP at the load balancer, the load balancer cannot inspect the traffic, nor can it inspect the destination virtual directory for health concerns.
Thus, if one service on the Exchange 2013 Client Access server fails, the load balancer only detects that the Client Access server in general has failed and it will initiate a fail-over to another Client Access server. To overcome this problem, there are two possible solutions:
· Use multiple VIPs for various services so that the individual VIPs can be checked for health (see Figure 3-14).
Figure 3-14. Multiple VIPs on the load balancer for Exchange 2013
· Use a layer-7 load balancer so that the load balancer can inspect the traffic for the individual services. This can be combined with SSL offloading.
In Figure 3-14, there are eight separate VIPs—one VIP for each server—and they are independent of each other. When the OWA AppPool on the Client Access server fails, only the OWA traffic is redirected to another Client Access server and other traffic continues to be serviced by this particular Client Access server.
SSL Offloading
New in Exchange 2013 SP1 is support for SSL offloading. When using SSL offloading, the SSL traffic is terminated at the load balancer; beyond the load balancer, the traffic can continue unencrypted. This was not supported in Exchange 2013 RTM, so re-encryption had to be used in Exchange 2013 versions prior to SP1.
With SSL offloading, it is possible to perform content inspection and thus evaluate the individual client request and then proxy these individual client requests to individual virtual directories on the Client Access server. In this scenario the individual services don’t interact with each other, so when one service fails the other service continues working—like the example in the previous section with the multiple VIPs. A single namespace with SSL offloading is shown in Figure 3-15.
Figure 3-15. A single namespace with layer-7 load balancing and SSL offloading
SSL offloading for the individual web services is not enabled by default, so it has to be enabled on each virtual directory on the Client Access server. To achieve this you can use the following commands in EMS:
Import-Module WebAdministration
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None"
-PSPath IIS: -Location "Default Web Site/OWA"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None"
-PSPath IIS: -Location "Default Web Site/ECP"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None"
-PSPath IIS: -Location "Default Web Site/OAB"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None"
-PSPath IIS: -Location "Default Web Site/EWS"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None"
-PSPath IIS: -Location "Default Web Site/Microsoft-Server-ActiveSync"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None"
-PSPath IIS: -Location "Default Web Site/Autodiscover"
Set-WebConfigurationProperty -Filter //security/access -name sslflags -Value "None"
-PSPath IIS: -Location "Default Web Site/MAPI"
Note These commands can be downloaded from the Apress website.
For Outlook Anywhere on Exchange 2013, SSL offloading is enabled by default. If for some reason the SSL offloading for Outlook Anywhere is not enabled, you can use the following commands in EMS to enable SSL offloading:
Get-OutlookAnywhere -Server AMS-EXCH01 | Set-OutlookAnywhere
-ExternalHostname webmail.contoso.com -ExternalClientsRequireSsl:$true
-ExternalClientAuthenticationMethod:Basic -InternalHostName webmail.contoso.com -InternalClientsRequireSsl:$true -InternalClientAuthenticationMethod:Basic
SMTP Transport
In Exchange 2013, the complete set of services, components, connections, and queues that deal with item transport is called the “transport pipeline.” This transport pipeline is made up of three different services:
· Front End Transport service (FETS) FETS is the part that is running on the Exchange 2013 Client Access server. It acts as a stateless SMTP protocol proxy for inbound and outbound SMTP traffic. FETS accepts connections from the Internet and routes them to the appropriate Mailbox server or down-level Hub Transport server. FETS does not store any information in a queue on the local disk, and therefore it cannot do any content inspection.
· Transport service The Transport service is comparable to the Hub Transport server role in Exchange Server 2010 and 2007, except that it is no longer a dedicated server role; instead, it is part of the Mailbox server. Because of this, the message routing, especially in multi-site database availability groups, is much more efficient. The Transport service performs message categorization and can perform message inspection. All internal routing between Exchange servers is always performed by the Transport service, but the Transport service never communicates with the Mailbox databases.
· Mailbox Transport service The Mailbox Transport service runs on all Mailbox servers and is made up of two different services:
· The Mailbox Transport delivery service accept messages from the Transport service and delivers the message to the Mailbox database via a local RPC connection with the Mailbox database.
· The Mailbox Transport submission service connects to the Mailbox database using local RPC, but retrieves messages from the Mailbox database that are in the user's outbox and delivers those messages, using SMTP to the Transport service for further processing.
Note The entire transport pipeline will be discussed in Chapter 4. That chapter is about the Exchange 2013 Mailbox server, and SMTP transport is a major component of this server role.
So, FETS running on the Client Access server accepts messages from the Internet and from the Transport service running on the Mailbox server. For receiving messages, “receive connectors” are used. For sending messages, a “send connector” is used. A send connector is used by the Transport service on the Mailbox server, but it can use the Client Access server as a local proxy that is controlled with the FrontEndProxyEnabled parameter when creating the send connector.
The Send Connector
To use the Front End proxy function in the Exchange 2013 Client Access server, you first have to create a send connector. You can create a new send connector by entering the following command in EMS:
New-SendConnector -Name "To_Internet" -Internet -AddressSpaces "*" -DNSRoutingEnabled:$TRUE
-SourceTransportServers "AMS-EXCH01","AMS-EXCH02" -FrontendProxyEnabled:$TRUE
This command will create a new send connector that’s used to send messages to the Internet. It will use DNS to find the SMTP servers to deliver these messages to instead of using a smart host. The Transport servers in the Exchange 2013 environment are AMS-EXCH01 and AMS-EXCH02, and the last parameter will make sure the Exchange 2013 Client Access servers are used as an SMTP proxy.
New in Exchange 2013 SP1 is the (re)introduction of the Edge Transport server role. When an Exchange 2013 Edge Transport server is introduced in the Exchange 2013 environment, it sends messages to the Internet and receives messages from the Internet. The Edge Transport server is communicating directly with the Transport service on the Mailbox server, bypassing FETS on the Client Access server.
The Exchange 2013 Edge Transport server role will be discussed in more detail as part of message hygiene in Chapter 9.
The Receive Connectors
Receive connectors in Exchange 2013 are responsible for accepting SMTP messages from other messaging servers. These messaging servers can be internal Exchange servers or external SMTP servers.
By default, an Exchange 2013 Client Access server has three receive connectors:
· Default front end <<server name>> The default front-end receive connector is used to receive SMTP messages from external servers—that is, from the Internet. This receive connector is listening on port 25.
· Client front end <<server name>> The client front-end receive connector is used for sending SMTP messages by clients—that is, users needing an SMTP host to send messages. These users are authenticated before they are able to send messages. The client front-end receive connector uses port 587 to receive messages.
· Outbound proxy front end <<server name>> The outbound proxy front-end receive connector is used by the Client Access server to receive messages from the Mailbox server that are proxied to external hosts—for example, on the Internet. The outbound proxy front-end server uses port 717 to receive messages.
When the Exchange 2013 Client Access server is installed, all receive connectors are automatically created and configured properly, so with out-of-the-box installations there's no need to configure them manually.
Anti-Spam Features
In Exchange 2013, anti-spam features are configured on the Mailbox server and not on the Client Access server. Therefore, all SMTP messages including spam messages are accepted at the Client Access server and are proxied to the Mailbox server, where anti-spam processing takes place. The following anti-spam features are available:
· Sender filtering
· Recipient filtering
· Sender ID filtering
· Content filtering
· Sender reputation filtering
Unfortunately, connection filtering is not available on the Exchange 2013 Transport server. This is only available on the Exchange 2013 Edge Transport server.
Note Since anti-spam features are running on the Mailbox server as part the Transport service, they will be discussed in more detail in Chapter 5. The anti-spam features of the Exchange 2013 Edge Transport server will be discussed in detail in Chapter 6.
Load-Balancing SMTP
It is obvious by now that a hardware load balancer is strongly recommended in front of the Exchange 2013 Client Access servers. This is true not only for handling client protocols like HTTPS, POP3, and IMAP4 but also for SMTP. Keep in mind that SMTP can also use multiple MX records for load-balancing purposes.
The load balancer can be used for inbound SMTP traffic from other SMTP hosts from the Internet on port 25, or for client SMTP submissions on port 587. The load balancer can be a simple layer-4 solution whereby the connections are directly sent to the Client Access server.
Publishing Exchange
An Exchange 2013 Client Access server needs to be connected to the Internet to have external clients connect to it. There are a few of possibilities:
· Direct connection
· Using TMG 2010 (and UAG 2010 to some extend)
· Using IIS/ARR
· Windows 2012 Web Proxy
· Load balancer reverse proxy
These options are explained in more detail next.
Direct Connection
A direct connection is one of my personal preferences. It is a configuration whereby the Exchange 2013 Client Access server has two network interfaces:
· NIC1 is connected to the internal network.
· NIC2 is connected to the external network.
The external network in this configuration can be the Internet, but of course in combination with a solid firewall solution where only the following ports are opened:
· Port 25 for SMTP
· Port 80 for HTTP
· Port 443 for HTTPS
· Port 587 for SMTP submission
· Ports 110 and 143 for POP3 and IMAP4
· Ports 993 and 995 for Secure POP3 and Secure IMAP4.
It depends on your own requirements which ports need to be opened.
Frequently, security officers in an organization have problems with a configuration like this. But remember that Windows Server is designed with the Internet threats in mind and is secure by default. Most issues still come from a bad configuration and sysadmin misinterpretation, and not from Windows. Also, Exchange 2013 is “hardened” by default.
Sure, you don’t have pre-authentication in a configuration like this, and you don’t have any deep content inspection of inbound traffic, although a decent firewall can do this when needed. But a direct connection is a fully supported scenario and there’s nothing wrong with it.
TMG 2010
Microsoft ForeFront Threat Management Gateway (TMG) 2010 is used a lot by customers to publish Exchange servers to the Internet. It can do some load balancing, firewalling, content inspection, reverse proxy, or URL rewriting. And it doesn’t cost too much, which is a big advantage for most customers.
The downside of TMG 2010 is that it’s no longer available and support for TMG is being stopped by Microsoft. Mainstream support for TMG 2010 will end on April 14, 2015, and extended support will end on April 14, 2020.
The good thing is that although TMG 2010 is no longer available, it still works with Exchange 2013 and still is a fully supported scenario. The Microsoft Exchange product team has published an extensive blog on how to configure this, and you can find this blog post onhttp://bit.ly/Ex2013TMG.
But since TMG 2010 is no longer officially available, it’s time to look for alternatives and the following are available:
· Application Request Routing (ARR), which is an add-on for Internet Information server.
· Web Application Proxy (WAP), which is part of Windows Server 2012 R2.
· Third- party solutions like Load Balancer Reverse Proxy.
These solutions offer very similar solutions, although they don’t have as many options as TMG 2010 had. Of these three solutions, WAP is the strategic choice.
Note When Microsoft announced the end of life for TMG 2010, the official alternative was ForeFront Unified Application Gateway (UAG), but UAG’s end of life has been officially announced as well.
IIS/ARR
Application Request Routing (ARR) is an IIS extension that allows IIS to act as a reverse proxy as well as a load balancer, free of charge! The only prerequisite for running IIS/ARR is that you have a Windows Server 2008 or later with IIS 7.0 (or later) on it. Furthermore, there’s no need for this Windows server to be domain joined, so you can install it in your network’s DMZ as well.
As shown in Figure 3-16, IIS/ARR consists of two parts. The URL rewrite module acts as the reverse proxy and the web farm. In the web farm properties, you can configure a load balancer when multiple Exchange 2013 Client Access servers are used.
Figure 3-16. Functional overview of IIS/ARR
Besides load balancing, IIS/ARR can perform health checking, SSL offloading, and server affinity, and it can use both layer-4 and layer-7 routing. As explained earlier in this chapter, you can use IIS/ARR with a single namespace or with multiple namespaces, and you can use per-protocol health check. The only thing that IIS/ARR lacks is pre-authentication for clients.
Note IIS/ARR also works with Exchange Server 2007 and Exchange Server 2010.
You can download the ARR module for IIS from the IIS.NET website at http://bit.ly/ARRDownload.
Windows 2012 R2 Web Application Proxy
The Microsoft strategic solution when it comes to a TMG 2010 replacement is the Web Application Proxy (WAP), which is part of the remote access role in Windows Server 2012 R2. As such, you need a Windows 2012 R2 ADFS installation in your environment. The WAP server itself acts as an ADFS proxy and is designed to be installed in the network’s DMZ, as shown in Figure 3-17.
Figure 3-17. Network topology when using a WAP infrastructure
WAP is a fully supported solution for use with Exchange Server 2013, and all protocols are supported for proxying via the WAP server:
· OWA/ECP
· ActiveSync
· Outlook Anywhere
· MapiHttp
· Exchange Web Services
· Offline Address Book
· Autodiscover
WAP offers pre-authentication as well, but only for OWA and ECP, not for other protocols or clients. New in Exchange 2013 SP1 and WAP is support for ADFS authentication based on SAML 2.0 (claims-based authentication). One issue here is that it’s not possible to mix different authentication mechanisms. Authentication is either ADFS or it’s any other form of authentication, like Forms Based, NTLM, Basic, and so on. It also only works against a pure Exchange 2013 SP1 environment; any coexistence scenario, even with Exchange 2013 RTM, is not supported and will not work.
ADFS authentication is becoming more and more important (driven by Office 365) and developments in this area occur extremely fast. More information regarding the implementation of ADFS, including detailed installation steps, can be found in the article “Using AD FS Claims-based Authentication with Outlook Web App and EAC,” at http://bit.ly/ADFS-Ex2013.
Load Balancer Reverse Proxy
Another solution for reverse proxy and pre-authentication is coming from load balancer vendors like Kemp Technologies or F5 Networks.
Load balancer vendors typically work closely with Microsoft on developing these kinds of solutions, so this should be fully supported as well. However, keep in mind that these are supported by the load balancer vendor, not Microsoft.
Kemp Technologies, and to a lesser degree F5 Networks, is working closely with the Exchange community to position its solutions. This means a lot of information can be found in Exchange user groups, webinars, articles, and blog posts. When you already have a (hardware) load balancer, this is certainly an area to examine.
Summary
The Exchange Server 2013’s Client Access server role is an interesting and important one. It is a building block of Exchange 2013, as all clients always connect to the Client Access server. In Exchange 2013, there are no more clients connecting directly to the Mailbox server.
Changes with respect to previous versions of Exchange server include that the traditional MAPI (RPC over TCP) is no longer supported in Exchange 2013 and that all Outlook connectivity is via Outlook Anywhere (RPC over HTTP). New in Exchange 2013 SP1 is a protocol called MapiHttp, whereby Outlook is using native HTTP to communicate with the Exchange 2013 SP1 Client Access server, without the RPC encapsulation layer.
From an infrastructure point of view, the Exchange 2013 Client Access server is a “thin” one. It only accepts incoming requests, authenticates them, and proxies them to the Mailbox server where the mailbox is located. The only exception is SIP requests. These are authenticated and then redirected to the correct Mailbox server instead of proxying them to the correct Mailbox server. Connections between the clients and the Exchange 2013 Client Access server are stateless. The service that’s responsible for this is the Client Access Front End service, or CAFE.
Important for an Exchange 2013 server is to configure your Client Access servers appropriately. Namespaces, virtual directories, SSL certificates, and Autodiscover need to be in good condition. If you fail to configure these properly, you will see strange things happen in client communications, ranging from an inability to set out-of-office messages to not being able to connect to the Client Access server at all.
All business logic in Exchange 2013 is removed from the Client Access server and transferred to the Mailbox server, and this includes Autodiscover.
The SMTP Front-End Transport service (FETS) is an SMTP proxy in the Exchange 2013 Client Access server. All inbound SMTP traffic is delivered on the Client Access server and proxied directly to the Exchange 2013 Mailbox server.
When it comes to publishing your Exchange 2013 Client Access server to the Internet, you should be aware that TMG 2010 is no longer available (but still supported). Viable alternatives are IIS/ARR and WAP (the latter being Microsoft’s strategic alternative) or using a third-party hardware load balancer. WAP is emerging technology and difficult to understand, but this situation will change in the upcoming months, when more organizations start deploying WAP and more information is available.
From a management perspective, the Exchange 2013 Client Access server is not too challenging. Once you get it set up correctly, your management tasks may be monthly IIS log file archiving or yearly SSL certificate renewal. More configuration and management is required in the Exchange 2013 Mailbox server, which is the subject of the next chapter.