Exchange Guide 2013

1.Namespace Planning in Microsoft Exchange #

Namespace Planning in Exchange 2013

A series of articles.  The articles will span several topics, including namespace planning, load balancingclient connectivity coexistence, and certificate planning.  As the title suggests, this first article will cover namespace planning principles.

Namespace Planning

If you are like the vast majority of our customers, you already have some version(s) of Exchange deployed in your environment. Depending on the version, you may have different namespace requirements today.

Exchange 2007

In Exchange 2007 environments, at a minimum, you had two namespace scenarios:

  1. An Autodiscover namespace – autodiscover.contoso.com.
  2. One or more protocol-based namespaces – mail.contoso.com (for OWA, EAS, etc.); imap.contoso.com (for POP/IMAP clients); smtp.contoso.com (for SMTP client submissions, ad-hoc encryption or partner-to-partner encryption).

In addition, if you deployed in a multi-datacenter environment, you most likely had additional protocol-based namespaces for each region.

Exchange 2010

Like Exchange 2007, Exchange 2010 leverages the Autodiscover service for enabling client profile changes, so that namespace exists.

For customers that upgraded from Exchange 2007 (or Exchange 2003), a new namespace requirement was introduced for coexistence – the legacy namespace, legacy.contoso.com. Though it is important to note that the legacy namespace can be called anything you choose, alderaan.contoso.com for example.

Exchange 2010 introduced additional namespace requirements, which resulted in additional complexity around namespace planning, especially for site resilient solutions:

  1. Primary datacenter Internet protocol namespace (mail.contoso.com)
  2. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
  3. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
  4. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
  5. Transport namespace (smtp.contoso.com)
  6. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
  7. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

Out of these nine namespaces, seven of them were required on certificates. The RPC Client Access namespaces were not required on the certificate because they were accessed via RPC connectivity and not via an Internet-based protocol, like HTTP.

Exchange 2013

One of the benefits of the Exchange 2013 architecture is that the namespace model can be simplified, when compared to Exchange 2010.

An example of how it can be simplified can be seen when thinking about a site resilience scenario. If you have two datacenters participating in a site resilient architecture, by replacing the Exchange 2010 infrastructure with Exchange 2013, five namespaces could potentially be removed:

  1. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
  2. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
  3. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
  4. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
  5. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

There’s two reasons for this.

First, Exchange 2013 no longer leverages an RPC Client Access namespace. This is due to the architectural changes within the product – for a given mailbox, the protocol that services the request is always going to be the protocol instance on the Mailbox server that hosts the active copy of the database for the user’s mailbox. In other words, the RPC Client Access service is no longer decoupled from the store, like it was in Exchange 2010.

Second, as mentioned, CAS2013 proxies requests to the Mailbox server hosting the active database copy. This proxy logic is not limited to the Active Directory site boundary. Unlike Exchange 2010, Exchange 2013 does not require the client namespaces to move with the DAG during an activation event – a CAS2013 in one Active Directory site can proxy a session to a Mailbox server that is located in another Active Directory site. This means that unique namespaces are no longer required for each datacenter (mail.contoso.com and mail2.contoso.com); instead, only a single namespace is needed for the datacenter pair – mail.contoso.com. This also means failback namespaces are also not required during DAG activation scenarios, so mailpri.contoso.com and mailsec.contoso.com are removed.

Namespace Models

Depending on your architecture and infrastructure you have two choices:

  1. Deploy a unified namespace for the site resilient datacenter pair (unbound model).
  2. Deploy a dedicated namespace for each datacenter in the site resilient pair (bound model).

It’s also worth mentioning that these choices are also tied to the DAG architecture.

Unbound Model

In an unbound model, you have a single DAG deployed across the datacenter pair. This DAG has Mailbox servers in each datacenter – typically all Mailbox servers are active and host active database copies, however you could deploy all active copies in a single datacenter. Mailboxes for both datacenters are dispersed across the mailbox databases within this DAG. In this model, clients can connect to both datacenters in the event there is a WAN failure – neither datacenter’s connectivity is a boundary, hence the term unbound. It does not guarantee, however, the connectivity provides users an equal experience; meaning one connection may provide a better user experience because it has lower latency or more bandwidth.

In an unbound model, a single namespace is preferred because either datacenter can service the user request. This means that from a load balancing perspective, the CAS infrastructure in both datacenters participate in handling traffic, as seen in the following diagram:

Unbound Model
Figure 1: Single Namespace used across Site Resilient Datacenter Pair (Unbound Model)

As a result, for a given datacenter, the expectation is that 50% of the traffic will be proxied from the other datacenter.

Bound Model

As its name implies, in a bound model, users are associated (or bound) to a specific datacenter. In other words, there is preference to have the users operate out of one datacenter during normal operations and only have the users operate out of the second datacenter during failure events. There is also a possibility that users do not have equal connectivity to both datacenters. Typically, in a bound model, there are two DAGs deployed in the datacenter pair. Each DAG contains a set of mailbox databases for a particular datacenter; by controlling where the databases are mounted, you control connectivity.

In a bound model, multiple namespaces are preferred, two per datacenter (primary and failback namespaces), to prevent clients trying to connect to the datacenter where they may have no connectivity. Switchover to the other datacenter is a controlled event.

boundedmodel
Figure 2: Multiple Namespaces used across Site Resilient Datacenter Pair (bound Model)

Other Namespaces

Other namespaces are still required. Exchange 2013 takes advantage of the Autodiscover service for client profile manipulation; so the autodiscover.contoso.com namespace remains in place.

If you are planning to upgrade from Exchange 2007, a legacy namespace is required for connectivity. The legacy namespace provides connectivity for OWA, is the namespace returned in Autodiscover responses (e.g., Exchange Web Services URL), and provides access to Exchange 2007 mailboxes that exist in non-Internet facing Active Directory sites.

Internal vs. External Namespaces

Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces. A split-brain DNS infrastructure enables different IP addresses to be returned for a given namespace based on where the client resides – if the client is within the internal network, the IP address of the internal load balancer is returned; if the client is external, the IP address of the external gateway/firewall is returned.

This approach simplifies the end-user experience – users only have to know a single namespace (e.g., mail.contoso.com) to access their data, regardless of where they are connecting. A split-brain DNS infrastructure, also simplifies the configuration of Client Access server virtual directories, as the InternalURL and ExternalURL values within the environment can be the same value.

In the event that you do not deploy a split-brain DNS (also known as split-DNS) infrastructure, Exchange 2013 has introduced one improvement in this area – Outlook Anywhere now supports separate internal and external namespaces.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must utilize the same authentication value for both your internal and external Outlook Anywhere settings, or switch to use different names for Outlook Anywhere inside and out. Outlook gives priority to the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings.

Regional Namespaces

The concept of regional namespaces has existed since OWA debuted in 1997 (can you believe OWA is almost 17 years old!?!). A regional namespace is a way for clients to connect to the Client Access endpoint that is closest to the Mailbox servers hosting the data.

Use of a regional namespace does not necessarily mean you are restricted to a bound model, either. This is because depending on your infrastructure and network capabilities, you may choose to have a dedicated namespace for each datacenter pair. For example, your company may have a set of datacenters in North America and in Europe, and due to a desire to reduce cross-region network traffic, you deploy a dedicated namespace for each region (notice that within a region, the unbound model is used):

Regional Namespaces
Figure 3: Regional Namespaces

Conclusion

Exchange 2013 introduces significant flexibility in your namespace architecture, enabling deployment of a single unified namespace for a site resilient datacenter pair (or worldwide), or deployment of multiple namespaces.  As we delve into the intricacies surrounding load balancing principles, client connectivity, and certificate planning, you will understand (hopefully) how to choose the best namespace model.

2.Client Connectivity in an Exchange 2013 Coexistence Environment #

Part 3 Client Connectivity in an Exchange 2013 Coexistence Environment

This article is part 3 in a series that discusses namespace planningload balancing principles, client connectivity, and certificate planning.

Over the last several months, we have routinely fielded questions on how various clients connect to the infrastructure once Exchange 2013 is deployed. Our goal with this article is to articulate the various connectivity scenarios you may encounter in your designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2007 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2013.

Existing Environment

Pre-E15 Environment
Figure 1: Exchange 2007 & Exchange 2010 Multi-Site Architecture

As you can see from the above diagram, this environment contains three Active Directory sites:

  • Internet Facing AD Site (Site1) – This is the main AD site in the environment and has exposure to the Internet. This site also has a mix of Exchange 2007 and Exchange 2010 servers. There are three namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2010 infrastructure and legacy.contoso.com resolves to the CAS2007 infrastructure.
  • Regional Internet Facing AD Site (Site2) – This is an AD site that has exposure to the Internet. This site has Exchange 2010 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2010 infrastructure located within this AD site.
  • Non-Internet Facing AD Site (Site3) – This is an AD site that does not have exposure to the Internet. This site contains Exchange 2010 infrastructure.

Note: The term, Internet Facing AD Site, simply means any Active Directory site containing Client Access servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Client Access servers whose virtual directories do not have ExternalURL property populated.

To understand the client connectivity before we instantiate Exchange 2013 into the environment, let’s look at the four users.

Autodiscover

The Autodiscover namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2010 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2010 infrastructure and retrieve configuration settings based on their mailbox’s location. The Autodiscover service on Exchange 2010 can process Autodiscover requests for both Exchange 2007 and Exchange 2010 mailboxes.

Note: The recommended practice is to configure the 2007 and 2010 Client Access server’s AutoDiscoverServiceInternalUri value (which is the property value you use to set the SCP record) to point to autodiscover.contoso.com, assuming split-brain DNS is in place. If split-brain DNS is not configured, then set AutoDiscoverServiceInternalUri to a value that resolves to the load balanced VIP for the 2010 Client Access servers in your environment.

For more information on how Autodiscover requests are performed, see the whitepaper, Understanding the Exchange 2010 Autodiscover Service.

Internal Outlook Connectivity

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will connect to the Exchange 2010 RPC Client Access array endpoint (assuming one exists). Keep in mind the importance of configuring the RPC Client Access array endpoint correctly, as documented in Ambiguous URLs and their effect on Exchange 2010 to Exchange 2013 Migrations.

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox.

Outlook Anywhere

  1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server is located on an Exchange 2007 server, and proxy the Outlook RPC data to the target Exchange 2007 Mailbox server.
  3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2010 in Site1 will de-encapsulate the RPC data embedded within the HTTP packet, determine that the mailbox server hosting the mailbox is located in another AD site (in this case Site3) and proxy the Outlook RPC data to the target Exchange 2010 Client Access server.
  4. Orange User will connect to mail-region.contoso.com as his RPC proxy endpoint. CAS2010 in Site2 will de-encapsulate the RPC data embedded within the HTTP packet and since the target mailbox database is located within the local site, will retrieve the necessary data from the local Exchange 2010 Mailbox server.

Note: In addition to the mail and directory connections, Outlook Anywhere clients also utilize Exchange Web Services and an Offline Address Book, which are provided via the Autodiscover response.

Outlook Web App

For more information, see the article Upgrading Outlook Web App to Exchange 2010.

  1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to legacy.contoso.com. CAS2007 will then process the request and retrieve the necessary data from the Exchange 2007 Mailbox server.
  3. Blue User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2010 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  4. For the Orange User, there are three possible scenarios depending on what namespace the users enters and how the environment is configured:
    1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is not configured to do a cross-site silent redirection, therefore, the user is prompted to use the correct URL to access his mailbox data.
    3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2010 in Site1 is configured to do a cross-site silent redirection, therefore, CAS2010 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.

Exchange ActiveSync

For more information, see the article Upgrading Exchange ActiveSync to Exchange 2010.

  1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2010 proxies the request to CAS2007.
  3. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any EAS ExternalURLs. CAS2010 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  4. For the Orange User, there are two possible scenarios:
    1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2010 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and retrieve the necessary data from the Exchange 2010 Mailbox server.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2010 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an EAS ExternalURL. Assuming the device supports Autodiscover and is on a defined list of devices that supports the 451 redirect response, CAS2010 will issue a 451 response to the device, notifying the device it needs to use a new namespace, mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server. If the device is not on the supported list, then CAS2010 in Site1 will proxy the request to CAS2010 in Site2

Exchange Web Services

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site1 will service the request.
  2. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2010 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
  3. For the Purple User, Autodiscover will provide back the legacy.contoso.com namespace for the Exchange Web Service URL. CAS2007 in Site1 will service the request.
  4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2010 in Site2 will service the request.

Client Connectivity with Exchange 2013 in Site1

Exchange 2013 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. As a result, Outlook Anywhere has been enabled on all Client Access servers within the infrastructure and the mail.contoso.com and autodiscover.contoso.com namespaces have been moved to resolve to Exchange 2013 Client Access server infrastructure.

E15 Site1
Figure 2: Exchange 2013 Coexistence with Exchange 2007 & Exchange 2010 in a Multi-Site Architecture

To understand the client connectivity now that Exchange 2013 exists in the environment, let’s look at the four users.

Autodiscover

The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records resolve to the CAS2013 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the CAS2013 infrastructure and depending on the mailbox version, different behaviors occur:

  1. For mailboxes that exist on Exchange 2010, CAS2013 will proxy the request to an Exchange 2010 Client Access server that exists within the mailbox’s local site. This means that for Red User, this will be a local proxy to a CAS2010 in Site1. For Blue User and Orange User, this will be a cross-site proxy to a CAS2010 located in the user’s respective site. CAS2010 will then generate the Autodiscover response.
  2. For mailboxes that exist on Exchange 2007, CAS2013 will proxy the request to an Exchange 2013 Mailbox server in the local site, which will generate the Autodiscover response. This means for Purple User, the MBX2013 server in Site1 will generate the response.
  3. For mailboxes that exist on Exchange 2013, CAS2013 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Internal Outlook Connectivity

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2010, they will still connect to the Exchange 2010 RPC Client Access array endpoint.

For internal Outlook clients using RPC/TCP connectivity whose mailboxes exist on Exchange 2007, they will still connect directly to the Exchange 2007 Mailbox server instance hosting the mailbox.

When you have an Exchange 2013 mailbox you are using Outlook Anywhere, both within the corporate network and outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 mailboxes.

In Exchange 2007/2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013, you have both an internal host name and an external host name. Think of it as having two sets of Outlook Anywhere settings, one for when you are connected to the corporate domain, and another for when you are not. You will see this returned to the Outlook client in the Autodiscover response via what looks like a new provider, ExHTTP. However, ExHTTP isn’t an actual provider, it is a calculated set of values from the EXCH (internal Outlook Anywhere) and EXPR (External Outlook Anywhere) settings. To correctly use these settings, the Outlook client must be patched to the appropriate levels (see the Exchange 2013 System Requirements for more information). Outlook will process the ExHTTP in order – internal first and external second.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must utilize the same authentication value for both your internal and external Outlook Anywhere settings, or switch to use different names for Outlook Anywhere inside and out. Outlook gives priority to the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings.

The default Exchange 2013 internal Outlook Anywhere settings don’t require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads.

External Outlook Connectivity

In order to support access for Outlook Anywhere clients whose mailboxes are on legacy versions of Exchange, you will need to make some changes to your environment which are documented in the steps within the Exchange Deployment Assistant. Specifically, you will need to enable Outlook Anywhere on your legacy Client Access servers and enable NTLM in addition to basic authentication for the IIS Authentication Method.

The Exchange 2013 Client Access server’s RPC proxy component sees the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (legacy CAS or Exchange 2013 Mailbox server).

  1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013 will proxy the request to CAS2010 in Site1. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2007 and that the mailbox database hosting the user’s mailbox is located in the local site. CAS2013 will proxy the request to CAS2007 in Site1. CAS2007 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2007 Mailbox server.
  3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. CAS2013 will proxy the request to CAS2010 in Site3. CAS2010 will de-encapsulate the RPC from the HTTP packet and obtain the data from the Exchange 2010 Mailbox server.
  4. Orange User will continue to access his mailbox using the Exchange 2010 regional namespace, mail-region.contoso.com.

Outlook Web App

For Outlook Web App, the user experience will depend on the mailbox version and where the mailbox is located.

  1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site on an Exchange 2007 Mailbox server. CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to legacy.contoso.com. CAS2007 will then facilitate the request and retrieve the necessary data from the Exchange 2007 Mailbox server.
  3. Blue User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  4. For the Orange User, there are two possible scenarios:
    1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. In this case, CAS2013 is not involved in any fashion.
    2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2, which does contain an OWA ExternalURL. CAS2013 in Site1 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2010 in Site2 will then facilitate the request and retrieve the necessary data from the Exchange 2010 Mailbox server.

Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007 and the mailbox is located in Site3. CAS2013 will issue a single sign-on silent redirect to legacy.contoso.com. CAS2007 in Site1 will authenticate the user and proxy the request to the Exchange 2007 Client Access server infrastructure in Site3.

Exchange ActiveSync

For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2013 no longer supports the 451 redirect response – Exchange 2013 will always proxy ActiveSync requests.

  1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within the local AD site. CAS2013 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
  2. Purple User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007. CAS2013 will proxy the request to a local Exchange 2013 Mailbox server. The Exchange 2013 Mailbox server will send the request to an Exchange 2007 Client Access server that exists within the mailbox’s site (specifically, the InternalURL value of the Microsoft-Server-ActiveSync virtual directory on CAS2007), which will retrieve the data from the Exchange 2007 Mailbox server.
  3. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. CAS2013 in Site1 will issue a cross-site proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
  4. For the Orange User, there are two possible scenarios depending on how the device is configured:
    1. Orange User’s ActiveSync client is configured to connect to mail-region.contoso.com as the namespace endpoint. In this case, CAS2013 is not involved in any fashion. Note that any new device that is configured will automatically be configured to use mail-region.contoso.com.
    2. Orange User’s ActiveSync client is configured to connect to mail.contoso.com as the namespace endpoint. CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2010 and the mailbox is located within another AD site. CAS2013 will issue a cross-site proxy request to an Exchange 2010 Client Access server that resides in the same site as the mailbox.

Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, CAS2013 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox version is 2007 and the mailbox is located in Site3. CAS2013 will proxy the request to a local Exchange 2013 Mailbox server. The Exchange 2013 Mailbox server will send the request to an Exchange 2007 Client Access server that exists within the mailbox’s site, which will retrieve the data from the Exchange 2007 Mailbox server.

Exchange Web Services

Coexistence with Exchange Web Services is rather simple.

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 will then proxy the request to an Exchange 2010 Client Access server within the local site.
  2. For the Purple User, Autodiscover will return the legacy.contoso.com namespace for the Exchange Web Service URL.
  3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 will then proxy the request to an Exchange 2010 Client Access server located in Site3.
  4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL.

Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, the Autodiscover response will provide back the legacy.contoso.com namespace for the Exchange Service URL. CAS2007 in Site1 will proxy the request to an Exchange 2007 Client Access server that exists within the mailbox’s site, which will retrieve the data from the Exchange 2007 Mailbox server. This is why you cannot remove Exchange 2007 from the Internet-facing Active Directory site as long as Exchange 2007 exists in non-Internet facing Active Directory sites.

Offline Address Book

Like with Exchange Web Services, Autodiscover will provide the Offline Address Book URL.

  1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
  2. For the Purple User, Autodiscover will return the legacy.contoso.com namespace for the Offline Address Book URL.
  3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013 will then proxy the request to any Client Access server within the local site that is a web distribution point for the Offline Address Book in question.
  4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL.

Note: Let’s assume that Site3 contains Exchange 2007 servers as well. In this scenario, the Autodiscover response will provide back the legacy.contoso.com namespace for the Offline Address Book URL. This is why you cannot remove Exchange 2007 from the Internet-facing Active Directory site as long as Exchange 2007 exists in non-Internet facing Active Directory sites.

How CAS2013 Picks a Target Legacy Exchange Server

It’s important to understand that when CAS2013 proxies to a legacy Exchange Client Access server, it constructs a URL based on the server FQDN, not a load balanced namespace or the InternalURL value.But how does CAS2013 choose which legacy Client Access server to proxy the connection?

When a CAS2013 starts up, it connects to Active Directory and enumerates a topology map to understand all the Client Access servers that exist within the environment. Every 50 seconds, CAS2013 will send a lightweight request to each protocol end point to all the Client Access servers in the topology map; these requests have a user agent string of HttpProxy.ClientAccessServer2010Ping (yes, even Exchange 2007 servers are targeted with that user string). CAS2013 expects a response – a 200/300/400 response series indicates the target server is up for the protocol in question; a 502, 503, or 504 response indicates a failure. If a failure response occurs, CAS2013 immediately retries to determine if the error was a transient error. If this second attempt fails, CAS2013 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), CAS2013 will attempt to determine the health state of the down CAS to determine if it is available.

The IIS log on a legacy Client Access server will contain the ping events.  For example:

2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /ecp – 443 – 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping – – coe-e14-1.coe.lab 302 0 0 277 170 0
2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /PowerShell – 443 – 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping – – coe-e14-1.coe.lab 401 0 0 309 177 15
2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 HEAD /EWS – 443 – 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping – – coe-e14-1.coe.lab 401 0 0 245 170 0
2014-03-11 14:00:00 W3SVC1 DF-C14-02 157.54.7.76 GET /owa – 443 – 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping – – coe-e14-1.coe.lab 301 0 0 213 169 171
2014-03-11 14:00:01 W3SVC1 DF-C14-02 157.54.7.76 HEAD /Microsoft-Server-ActiveSync/default.eas – 443 – 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping – – coe-e14-1.coe.lab 401 2 5 293 194 31
2014-03-11 14:00:04 W3SVC1 DF-C14-02 157.54.7.76 HEAD /OAB – 443 – 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping – – coe-e14-1.coe.lab 401 2 5 261 170 171

If for some reason, you would like to ensure a particular CAS2010 is never considered a proxy endpoint (or want to remove it for maintenance activities), you can do so by executing the following cmdlet on Exchange 2010 (note that this feature does not exist on Exchange 2007):

Set-ClientAccessServer <server> -IsOutofService $True

IMAP & POP Coexistence

All this discussion about HTTP-based clients is great, but what about POP and IMAP clients? Like the HTTP-based client counterparts, IMAP and POP clients are also proxied from the Exchange 2013 Client Access server to a target server (whether that be an Exchange 2013 Mailbox server or a legacy Client Access server). However, there is one key difference, there is no health-checking on the target IMAP/POP services.

When the Exchange 2013 Client Access server receives a POP or IMAP request, it will authenticate the user and perform a service discovery.

  • If the target mailbox is E2010, CAS2013 will enumerate the POP or IMAP InternalConnectionSettings property value for each Exchange 2010 Client Access server within the mailbox’s site. Therefore, it is important to ensure that the InternalConnectionSettings maps to the server’s FQDN, and not a load-balanced namespace.
  • If the target mailbox is E2007, CAS2013 will enumerate each Exchange 2007 Client Access server’s server FQDN within the mailbox’s site.

CAS2013 will choose a server to proxy the request based on the incoming connection’s configuration. If the incoming connection is over an encrypted channel, CAS2013 will try to locate an SSL proxy target first, TLS next, plaintext lastly. If the incoming connection is over a plaintext channel, CAS2013 will try to locate a plaintext proxy target first, SSL next, TLS lastly.

Important: Exchange 2013 Client Access servers do not validate that the POP or IMAP services are actually running on the target Client Access servers. It’s important, therefore, to ensure that the services are running on every legacy Client Access server if you have POP or IMAP clients in your environment.

Conclusion

Hopefully this information dispels some of the myths around proxying and redirection logic for Exchange 2013 when coexisting with either Exchange 2007 or Exchange 2010. Please let us know if you have any questions.

 

3.Load Balancing in Exchange 2013 #

Load Balancing in Exchange 2013

This article is part 2 in a series that discusses namespace planning, load balancing principles, client connectivity, and certificate planning.

Load Balancing

Unlike previous versions of Exchange, Exchange 2013 no longer requires session affinity at the load balancing layer.

To understand this statement better, and see how this impacts your designs, we need to look at how CAS2013 functions. From a protocol perspective, the following will happen:

  1. A client resolves the namespace to a load balanced virtual IP address.
  2. The load balancer assigns the session to a CAS member in the load balanced pool.
  3. CAS authenticates the request and performs a service discovery by accessing Active Directory to retrieve the following information:
    1. Mailbox version (for this discussion, we will assume an Exchange 2013 mailbox)
    2. Mailbox location information (e.g., database information, ExternalURL values, etc.)
  4. CAS makes a decision on whether to proxy the request or redirect the request to another CAS infrastructure (within the same forest).
  5. CAS queries an Active Manager instance that is responsible for the database to determine which Mailbox server is hosting the active copy.
  6. CAS proxies the request to the Mailbox server hosting the active copy.

Step 5 is the fundamental change that enables the removal of session affinity at the load balancer. For a given protocol session, CAS now maintains a 1:1 relationship with the Mailbox server hosting the user’s data. In the event that the active database copy is moved to a different Mailbox server, CAS closes the sessions to the previous server and establishes sessions to the new server. This means that all sessions, regardless of their origination point (i.e., CAS members in the load balanced array), end up at the same place, the Mailbox server hosting the active database copy.This is vastly different from previous releases – in Exchange 2010, if all requests from a specific client did not go to the same endpoint, the user experience was negatively affected.

The protocol used in step 6 depends on the protocol used to connect to CAS. If the client leverages the HTTP protocol, then the protocol used between the Client Access server and Mailbox server is HTTP (secured via SSL using a self-signed certificate). If the protocol leveraged by the client is IMAP or POP, then the protocol used between the Client Access server and Mailbox server is IMAP or POP.

Telephony requests are unique, however. Instead of proxying the request at step 6, CAS will redirect the request to the Mailbox server hosting the active copy of the user’s database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging components on the Mailbox server.


Figure 1: Exchange 2013 Client Access Protocol Architecture

However, there is a concern with this architectural change. Since session affinity is not used by the load balancer, this means that the load balancer has no knowledge of the target URL or request content. All the load balancer uses is layer 4 information, the IP address and the protocol/port (TCP 443):

Layer 4 Load Balancing
Figure 2: Layer 4 Load Balancing

The load balancer can use a variety of means to select the target server from the load balanced pool, such as, round-robin (each inbound connection goes to the next target server in the circular list) or least-connection (load balancer sends each new connection to the server that has the fewest established connections at that time).

Health Probe Checking

Unfortunately, this lack of knowledge around target URL (or the content of the request), introduces complexities around health probes.

Exchange 2013 includes a built-in monitoring solution, known as Managed Availability. Managed Availability includes an offline responder. When the offline responder is invoked, the affected protocol (or server) is removed from service. To ensure that load balancers do not route traffic to a Client Access server that Managed Availability has marked as offline, load balancer health probes must be configured to check <virtualdirectory>/healthcheck.htm (e.g., https://mail.contoso.com/owa/healthcheck.htm). Note that healthcheck.htm does not actually exist within the virtual directories; it is generated in-memory based on the component state of the protocol in question.

If the load balancer health probe receives a 200 status response, then the protocol is up; if the load balancer receives a different status code, then Managed Availability has marked that protocol instance down on the Client Access server. As a result, the load balancer should also consider that end point down and remove the Client Access server from the applicable load balancing pool.

Administrators can also manually take a protocol offline for maintenance, thereby removing it from the applicable load balancing pool. For example, to take the OWA proxy protocol on a Client Access server out of rotation, you would execute the following command:

Set-ServerComponentState <Client Access Server> -Component OwaProxy –Requestor Maintenance –State Inactive

For more information on server component states, see the article Server Component States in Exchange 2013.

What if the load balancer health probe did not monitor healthcheck.htm?

If the load balancer did not utilize the healthcheck.htm in its health probe, then the load balancer would have no knowledge of Managed Availability’s removal of (or adding back) a server from the applicable load balancing pool. The end result is that the load balancer would have one view of the world, while Managed Availability would have another view of the world. In this situation, the load balancer could direct requests to a Client Access server that Managed Availability has marked down, which would result in a negative (or broken) user experience. This is why the recommendation exists to utilize healthcheck.htm in the load balancing health probes.

Namespace and Affinity Scenarios

Now that we understand how health checks are performed, let’s look at four scenarios:

  1. Single Namespace / Layer 4 (No Session Affinity)
  2. Single Namespace / Layer 7 (No Session Affinity)
  3. Single Namespace / Session Affinity
  4. Multiple Namespaces / No Session Affinity

Single Namespace / Layer 4 (No Session Affinity)

In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is operating at layer 4 and is not maintaining session affinity. The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; however, because this is a layer 4 solution, the load balancer is configured to check the health of only a single virtual directory (as it cannot distinguish OWA requests from RPC requests). Administrators will have to choose which virtual directory they want to target for the health probe; you will want to choose a virtual directory that is heavily used. For example, if the majority of your users utilize OWA, then targeting the OWA virtual directory in the health probe is appropriate.

1Namespace-NoAffinity-1
Figure 3: Single Namespace with No Session Affinity

As long as the OWA health probe response is healthy, the load balancer will keep the target CAS in the load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target CAS from the load balancing pool for all requests associated with that particular namespace. In other words, in this example, health from the perspective of the load balancer, is per-server, not per-protocol, for the given namespace. This means that if the health probe fails, all client requests will have to be directed to another server, regardless of protocol.

1Namespace-NoAffinity-2
Figure 4: Single Namespace with No Session Affinity – Health Probe Failure

Single Namespace / Layer 7 (No Session Affinity)

In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is configured to utilize layer 7, meaning SSL termination occurs and the load balancer knows the target URL. The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; in this case, a health probe is configured on each virtual directory.

As long as the OWA health probe response is healthy, the load balancer will keep the target CAS in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target CAS from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.

1Namespace-Affinity-1
Figure 5: Single Namespace with Layer 7 (No Session Affinity) – Health Probe Failure

Single Namespace / Session Affinity

In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is configured to maintain session affinity (layer 7), meaning SSL termination occurs and the load balancer knows the target URL. The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; in this case, the health probe is configured on each virtual directory.

As long as the OWA health probe response is healthy, the load balancer will keep the target CAS in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target CAS from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.

1Namespace-Affinity-1
Figure 6: Single Namespace with Session Affinity – Health Probe Failure

Note: By having session affinity enabled, the load balancer’s capacity and utilization are decreased because processing is used to maintain more involved affinity options, such as cookie-based load balancing or Secure Sockets Layer (SSL) session-ID. Check with your vendor on the impacts session affinity will have in your load balancing scalability.

Multiple Namespaces / No Session Affinity

This scenario combines the best of both worlds – provides per-protocol health checking, while not requiring complex load balancing logic.

In this scenario, a unique namespace is deployed for each HTTP protocol client; for example:

MNamespaces-NoAffinity-1
Figure 7: Multiple Namespaces with No Session Affinity

Note: As seen in the picture depicted above, ECP is provided its own namespace. ECP and OWA are intimately tied together, and thus, ECP does not necessarily require its own namespace. However, ECP does have its own application pool, is the endpoint for the Exchange Administration Center, and used by Outlook clients for certain configuration items. Therefore, you may want to provide a unique namespace for ECP.

The load balancer is configured to not maintain session affinity (layer 4). The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; in this case, the health probes are effectively configured to target the health of each virtual directory, as each virtual directory is defined with a unique namespace, and while the load balancer still has no idea what the URL is being accessed, the result is as if it does know.

As long as the OWA health probe response is healthy, the load balancer will keep the target CAS in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target CAS from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.

MNamespaces-NoAffinity-2
Figure 8: Multiple Namespaces with No Session Affinity – Health Probe Failure

The downside to this approach is that it introduces additional namespaces, additional VIPs (one per namespace), and increases the number of names added as subject alternative names on the certificate, which can be costly depending on your certificate provider. But, this does not introduce extra complexity to the end user – the only URL the user needs to know is the OWA URL. ActiveSync, Outlook, and Exchange Web Services clients will utilize Autodiscover to determine the correct URL.

Scenario Summary

The following table identifies the benefits and concerns with each approach:

  Benefits Concerns
Single Namespace / Layer 4 (No Session Affinity)
  • Single namespace
  • Reduced load balancer complexity
  • Session affinity maintained at CAS
  • Per-server health
Single Namespace / Layer 7 (No Session Affinity)
  • Single namespace
  • Per-protocol health
  • SSL offloading which may impact load balancer scalability
Single Namespace / Layer 7 (Session Affinity)
  • Single namespace
  • Per-protocol health
  • Session affinity maintained at load balancer
  • Increased load balancer complexity
  • Reduced load balancer scalability
Multiple Namespaces / No Session Affinity
  • Per-protocol health
  • Session affinity maintained at CAS
  • Users only have to know OWA URL
  • Multiple namespaces
  • Additional names on certificate
  • Increased rule set on load balancer
  • Multiple VIPs

Conclusion

Exchange 2013 introduces significant flexibility in your namespace and load balancing architecture. With load balancing, the decision ultimately comes down to balancing functionality vs. simplicity. The simplest solution lacks session affinity management and per-protocol health checking, but provides the capability to deploy a single namespace. At the other end of the spectrum, you can utilize session affinity management, per-protocol health checking with a single namespace, but at the cost of increased complexity. Or you could balance the functionality and simplicity spectrums, and deploy a load balancing solution that doesn’t leverage session affinity, but provides per-protocol health checking at the expense of requiring a unique namespace per protocol.

 

4.Load Balancing in Exchange 2016 #

Load Balancing in Exchange 2016

Like Exchange 2013, Exchange 2016 does not require session affinity at the load balancing layer.

To understand this statement better, and see how this impacts your designs, we need to look at how MBX2016 functions. From a protocol perspective, the following will happen:

  1. A client resolves the namespace to a load balanced virtual IP address.
  2. The load balancer assigns the session to a MBX server in the load balanced pool.
  3. The Client Access services located on the MBX server authenticates the request and performs a service discovery by accessing Active Directory to retrieve the following information:
    1. Mailbox version (for this discussion, we will assume an Exchange 2016 mailbox)
    2. Mailbox location information (e.g., database information, ExternalURL values, etc.)
  4. The Client Access services located on the MBX server makes a decision on whether to proxy the request or redirect the request to another MBX infrastructure (within the same forest).
  5. The Client Access services located on the MBX server queries an Active Manager instance that is responsible for the database to determine which Mailbox server is hosting the active copy.
  6. The Client Access services located on the MBX server proxies the request to the Mailbox server hosting the active copy.

Step 5 is the fundamental change that enables the removal of session affinity at the load balancer. For a given protocol session, the Client Access services located on the Mailbox server now maintains a 1:1 relationship with the Mailbox server hosting the user’s data. In the event that the active database copy is moved to a different Mailbox server, MBX closes the sessions to the previous server and establishes sessions to the new server. This means that all sessions, regardless of their origination point (i.e., MBX servers in the load balanced array), end up at the same place, the Mailbox server hosting the active database copy.This is vastly different in releases prior to Exchange 2013 – for example, in Exchange 2010, if all requests from a specific client did not go to the same endpoint, the user experience was negatively affected.

The protocol used in step 6 depends on the protocol used to connect to MBX. If the client leverages the HTTP protocol, then the protocol used between Mailbox servers is HTTP (secured via SSL using a self-signed certificate). If the protocol leveraged by the client is IMAP or POP, then the protocol used between the Mailbox servers is IMAP or POP.

Telephony requests are unique, however. Instead of proxying the request at step 6, MBX will redirect the request to the Mailbox server hosting the active copy of the user’s database, as the telephony devices support redirection and need to establish their SIP and RTP sessions directly with the Unified Messaging components on the Mailbox server.

lbfig1
Figure 1: Exchange 2016 Client Access Protocol Architecture

However, there is a concern with this architectural change. Since session affinity is not used by the load balancer, this means that the load balancer has no knowledge of the target URL or request content.All the load balancer uses is layer 4 information, the IP address and the protocol/port (TCP 443):

lbfig2
Figure 2: Layer 4 Load Balancing

The load balancer can use a variety of means to select the target server from the load balanced pool, such as, round-robin (each inbound connection goes to the next target server in the circular list) or least-connection (load balancer sends each new connection to the server that has the fewest established connections at that time).

Health Probe Checking

Unfortunately, this lack of knowledge around target URL (or the content of the request), introduces complexities around health probes.

Exchange 2016 includes a built-in monitoring solution, known as Managed Availability. Managed Availability includes an offline responder. When the offline responder is invoked, the affected protocol (or server) is removed from service. To ensure that load balancers do not route traffic to a Mailbox server that Managed Availability has marked as offline, load balancer health probes must be configured to check <virtualdirectory>/healthcheck.htm (e.g., https://mail.contoso.com/owa/healthcheck.htm). Note that healthcheck.htmdoes not actually exist within the virtual directories; it is generated in-memory based on the component state of the protocol in question.

If the load balancer health probe receives a 200 status response, then the protocol is up; if the load balancer receives a different status code, then Managed Availability has marked that protocol instance down on the Mailbox server. As a result, the load balancer should also consider that end point down and remove the Mailbox server from the applicable load balancing pool.

Administrators can also manually take a protocol offline for maintenance, thereby removing it from the applicable load balancing pool. For example, to take the OWA proxy protocol on a Mailbox server out of rotation, you would execute the following command:

Set-ServerComponentState <Mailbox Server> -Component OwaProxy –Requestor Maintenance –State Inactive

For more information on server component states, see the article Server Component States in Exchange 2013.

What if the load balancer health probe did not monitor healthcheck.htm?

If the load balancer did not utilize the healthcheck.htm in its health probe, then the load balancer would have no knowledge of Managed Availability’s removal of (or adding back) a server from the applicable load balancing pool. The end result is that the load balancer would have one view of the world, while Managed Availability would have another view of the world. In this situation, the load balancer could direct requests to a Mailbox server that Managed Availability has marked down, which would result in a negative (or broken) user experience. This is why the recommendation exists to utilize healthcheck.htm in the load balancing health probes.

Namespace and Affinity Scenarios

Now that we understand how health checks are performed, let’s look at four scenarios:

  1. Single Namespace / Layer 4 (No Session Affinity)
  2. Single Namespace / Layer 7 (No Session Affinity)
  3. Single Namespace / Session Affinity
  4. Multiple Namespaces / No Session Affinity

Single Namespace / Layer 4 (No Session Affinity)

In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is operating at layer 4 and is not maintaining session affinity. The load balancer is also configured to check the health of the target Mailbox servers in the load balancing pool; however, because this is a layer 4 solution, the load balancer is configured to check the health of only a single virtual directory (as it cannot distinguish OWA requests from RPC requests). Administrators will have to choose which virtual directory they want to target for the health probe; you will want to choose a virtual directory that is heavily used.For example, if the majority of your users utilize OWA, then targeting the OWA virtual directory in the health probe is appropriate.

lbfig3
Figure 3: Single Namespace with No Session Affinity

As long as the OWA health probe response is healthy, the load balancer will keep the target MBX in the load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target MBX from the load balancing pool for all requests associated with that particular namespace. In other words, in this example, health from the perspective of the load balancer, is per-server, not per-protocol, for the given namespace.This means that if the health probe fails, all client requests for that namespace will have to be directed to another server, regardless of protocol.

lbfig4
Figure 4: Single Namespace with No Session Affinity – Health Probe Failure

Single Namespace / Layer 7 (No Session Affinity)

In this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is configured to utilize layer 7, meaning SSL termination occurs and the load balancer knows the target URL. The load balancer is also configured to check the health of the target Mailbox servers in the load balancing pool; in this MBXe, a health probe is configured on each virtual directory.

As long as the OWA health probe response is healthy, the load balancer will keep the target MBX in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target MBX from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.

lbfig5
Figure 5: Single Namespace with Layer 7 (No Session Affinity) – Health Probe Failure

A single namespace utilizing layer 7 without session affinity is the recommended namespace and load balancer configuration for Exchange 2016.

Single Namespace / Layer 7 with Session Affinity

this scenario, a single namespace is deployed for all the HTTP protocol clients (mail.contoso.com). The load balancer is configured to maintain session affinity (layer 7), meaning SSL termination occurs and the load balancer knows the target URL. The load balancer is also configured to check the health of the target Mailbox servers in the load balancing pool; in this MBXe, the health probe is configured on each virtual directory.

As long as the OWA health probe response is healthy, the load balancer will keep the target MBX in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target MBX from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.

lbfig5
Figure 6: Single Namespace with Layer 7 with Session Affinity – Health Probe Failure

Note: By having session affinity enabled, the load balancer’s capacity and utilization are decreased because processing is used to maintain more involved affinity options, such as cookie-based load balancing or Secure Sockets Layer (SSL) session-ID. Check with your vendor on the impacts session affinity will have in your load balancing scalability.

Multiple Namespaces / No Session Affinity

This scenario combines the best of both worlds – provides per-protocol health checking, while not requiring complex load balancing logic.

In this scenario, a unique namespace is deployed for each HTTP protocol client; for example:

lbfig6
Figure 7: Multiple Namespaces with No Session Affinity

Note: As seen in the picture depicted above, ECP is provided its own namespace. ECP and OWA are intimately tied together, and thus, ECP does not necessarily require its own namespace. However, ECP does have its own application pool, is the endpoint for the Exchange Administration Center, and used by Outlook clients for certain configuration items. Therefore, you may want to provide a unique namespace for ECP.

The load balancer is configured to not maintain session affinity (layer 4). The load balancer is also configured to check the health of the target Mailbox servers in the load balancing pool; in this case, the health probes are effectively configured to target the health of each virtual directory, as each virtual directory is defined with a unique namespace, and while the load balancer still has no idea what the URL is being accessed, the result is as if it does know.

As long as the OWA health probe response is healthy, the load balancer will keep the target MBX in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target MBX from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.

lbfig7
Figure 8: Multiple Namespaces with No Session Affinity – Health Probe Failure

The downside to this approach is that it introduces additional namespaces, additional VIPs (one per namespace), and increases the number of names added as subject alternative names on the certificate, which can be costly depending on your certificate provider. But, this does not introduce extra complexity to the end user – the only URL the user needs to know is the OWA URL. ActiveSync, Outlook, and Exchange Web Services clients will utilize Autodiscover to determine the correct URL.

 

5.Certificate Planning in Exchange 2013 #

Certificate Planning in Exchange 2013

Now that we understand the load balancing and namespace planning principles and how clients connect in an Exchange 2013 environment that has Exchange 2007 and/or Exchange 2010 deployed, the proper certificates can be constructed and deployed as part of the upgrade process.

Of course it goes without saying that there are a few rules you should follow in crafting your certificates:

  1. Use as few certificates as possible.
  2. Use as few host names as possible.
  3. Utilize the Subject Alternative Name (SAN) attribute on the certificate.
  4. Use the Exchange Certificate Wizard within the Exchange Admin Center to request certificates.
  5. Deploy the same certificate across all CAS in the datacenter pair.
  6. Deploy Vista SP1 or later clients so that you do not have to worry about the certificate principal name value.

Wildcard certificates are an option as well. A wildcard certificate for *.contoso.com results in a certificate that will work for mail.contoso.com, legacy.contoso.com, and autodiscover.contoso.com namespaces.

To understand what host names should be included in the certificate request, three scenarios will be considered that leverage the architecture principles discussed in the prior articles.

Scenario 1

Contoso has offices in Redmond, WA and Portland, OR. Contoso’s users utilize Outlook Anywhere, ActiveSync, Outlook Web Access, and IMAP clients connecting to an Exchange 2007 platform deployed in both sites.

They have recently completed a network upgrade that increases the available bandwidth between datacenters and removed single points of failure for the end users, allowing the end users to connect to either datacenter in the event of a WAN failure. With respect to load balancing, Contoso will continue to terminate SSL at the load balancer.

As part of the upgrade to Exchange 2013, Contoso will deploy a site resilient Database Availability Group in an active/active configuration.

As a result of these choices, Contoso will require the following namespaces:

  1. autodiscover.contoso.com – necessary to support client configuration.
  2. legacy.contoso.com – necessary to support Exchange 2007 clients during coexistence.
  3. mail.contoso.com – the primary namespace for OWA, ActiveSync, and Outlook Anywhere.
  4. smtp.contoso.com – the namespace used by SMTP clients (e.g., IMAP clients).
  5. imap.contoso.com – the namespace used by IMAP clients.

Scenario 1
Figure 1: Scenario 1 – Layer 7 Load Balancing with Unbounded Model

Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS, SMTP and IMAP services.

Scenario 2

Contoso has offices in Redmond, WA and Bel Air, MD. Contoso’s users utilize Outlook Anywhere, ActiveSync, Outlook Web App, connecting to an Exchange 2010 platform deployed in both sites.

Contoso has sufficient bandwidth to replicate databases between datacenters; however, Contoso prefers that the users access their data out of their local datacenter, unless there is a failure event.

As part of the upgrade, Contoso decides to leverage the enhancements in Exchange 2013 by disabling SSL termination on the load balancers. As a result, Contoso recognizes they will need to deploy client specific namespaces so that they can manage the health correctly on the load balancers.

As a result of these choices, Contoso will require the following namespaces:

  1. autodiscover.contoso.com – necessary to support client configuration.
  2. mail-wa.contoso.com – the primary namespace for OWA in the Redmond, WA datacenter.
  3. mail-md.contoso.com – the primary namespace for OWA in the Bel Air, MD datacenter.
  4. mailfb-wa.contoso.com – the failback namespace for OWA in the Redmond, WA datacenter.
  5. mailfb-md.contoso.com – the failback namespace for OWA in the Bel Air, MD datacenter.
  6. eas-wa.contoso.com – the primary namespace for EAS in the Redmond, WA datacenter.
  7. eas-md.contoso.com – the primary namespace for EAS in the Bel Air, MD datacenter.
  8. oa-wa.contoso.com – the primary namespace for Outlook Anywhere in the Redmond, WA datacenter.
  9. oa-md.contoso.com – the primary namespace for Outlook Anywhere in the Bel Air, MD datacenter.
  10. ews-wa.contoso.com – the primary namespace for Exchange Web Services in the Redmond, WA datacenter.
  11. ews-md.contoso.com – the primary namespace for Exchange Web Services in the Bel Air, MD datacenter.
  12. oab-wa.contoso.com – the primary namespace for the Offline Address Book in the Redmond, WA datacenter.
  13. oab-md.contoso.com – the primary namespace for the Offline Address Book in the Bel Air, MD datacenter.

Scenario 2
Figure 2: Scenario 2 – Layer 4 Load Balancing with Bounded Model

Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS service.

Scenario 3

Contoso has offices in Redmond, WA and Portland, OR. Contoso’s users utilize Outlook Anywhere and Outlook Web App connecting to an Exchange 2007 platform deployed in both sites.

They have recently completed a network upgrade that increases the available bandwidth between datacenters and removed single points of failure for the end users, allowing the end users to connect to either datacenter in the event of a WAN failure. With respect to load balancing, Contoso has decided to not utilize SSL termination at the load balancer once the namespace is moved to Exchange 2013.

As part of the upgrade to Exchange 2013, Contoso will deploy a site resilient Database Availability Group in an active/active configuration.

As a result of these choices, Contoso will require the following namespaces:

  1. autodiscover.contoso.com – necessary to support client configuration.
  2. legacy.contoso.com – necessary to support Exchange 2007 clients during coexistence.
  3. mail.contoso.com – the primary namespace for OWA clients.
  4. oa.contoso.com – the namespace used by Outlook Anywhere clients.
  5. ews.contoso.com – the namespace used by EWS clients.
  6. oab.contoso.com – the namespace used for Offline Address Book downloads.

Scenario 3
Figure 3: Scenario 3 – Layer 4 Load Balancing with Unbounded Model

Contoso completes their planning and pre-deployment testing and deploys Exchange 2013 Client Access and Mailbox servers. The certificate wizard is used to craft the certificate request, including the namespaces identified above. Once the certificate is received from the certificate authority, Contoso utilizes the Certificate wizard to import the certificate across all Client Access servers in both datacenters and enables the certificate for the IIS service.

Conclusion

Hopefully this article ties together the namespace and load balancing principles with respect to certificate planning. As you can see from the above examples, the choices you make with respect to your load balancing, namespace model, and DAG architecture greatly affect the number of host names required on the certificate.

 

6.Exchange 2013 install #

Implementation: Exchange mail server 2013

Below has been written as personal notes.

The exchange mail server will be installed on the OS Windows server 2012 R2.

Minimum Requirements for exchange 2013 OS are: Windows 2012R2 rollup 1.

  • Installing on partition 160Gb.(100gb OS and Exchange+ 500MB language packs)
  • Installing OS. Set Ip Address, make a member server, update to latest updates.
  • IP : Static, Subnet, gateway, DNS.
  • Proper naming and description.
  • Check OS Event viewer, check applied default policies, and check correct OU.
  • Check assigned memory ( 24gb min) Check signed processors 4 treads min).
  • Be sure to be a member off : Domain Admin, Enterprise Admin and Schema Admin.
  • Run all checks if the replication from AD is working correct see commands in the AD. DCdiag en repadmin

·       Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

  • Install Enterprise edition.
  • Copy Exchange 2016 CU16 to the server and extract, Run Setup as (DA EA and Schema Admins)
  • Use recommended settings and install the client and mailbox role, (Include features anyway if required.)
  • Leave the default installation to program files.
  • Install-WindowsFeature RSAT-ADDS
  • Check or install NET Framework 4.6.2 or above.
  • Check or install Net 4.5.

Open powershell in administration mode and copy and paste below to install requirements.

  • Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, eWeb-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation

    Setup:

    Accept agreement, don’t check for updates. Choose mailbox and client access.

    Provide organization name.

    Get-OrganizationConfig | FL identity

 

7.Exchange 2013 2016 setup virtual directory #

Exchange 2010/13/2016 Setup all virtual directories

In this post I’ll list the necessary commands to setup all necessary virtual directories for an Exchange installation. Please note how I’m using the same FQDN for both internal and external addresses.

More information on how to deal with naming in a large envoirment please see section name bound model.

Setup Virtual Directories.

Please note: all the commands are written as being run from the Exchange server itself. It means the -identity I use does not contain the servername, but only the name of the virtul directory.

Replace mydomainname.com with your domain information, outlook is virtual naming , so your dns needs to have an A record setup pointing to outlook.mydomainname.com

Configuring :

  • Outlook Anywhere
  • MAPI
  • Outlook Web App
  • Exchange Control Panel
  • Exchange ActiveSync
  • Exchange Web Services
  • Offline Address Book
  • AutoDiscover

We will plan to stick to one namespace as it will be outlook.mydomainname.com. Offcourse replace the text with your virtual name and domain name.

We will configure each server seperate to keep control.

 

OWA (outlook Web App)

Get-OWAVirtualDirectory -server myservername | Select Server,ExternalURL,InternalURL | flSet-OwaVirtualDirectory


Set-OWAVirtualDirectory -Identity “myservername\OWA (Default Web Site)” -ExternalURL “https://outlook.mydomain.com/OWA”

Set-OWAVirtualDirectory -Identity “myservername\OWA (Default Web Site)” -InternalURL “https://outlook.mydomain.com/OWA”

 

OAB (offline adress book)

GetOABVirtualDirectory -server myservername | Select Server,ExternalURL,InternalURL | fl

Set-OABVirtualDirectory
Set-OABVirtualDirectory -Identity "myservername\OAB (Default Web Site)" -ExternalUrl "https://outlook.mydomain.com/OAB"
Set-OABVirtualDirectory -Identity "myservername\OAB (Default Web Site)" -InternalURL "https://outlook.mydomain.com/OAB"
 

ECP (exchange control panel)

Get-ECPVirtualDirectory -server myservername | Select Server,ExternalURL,InternalURL | fl

Set-ECPVirtualDirectory

Set-ECPVirtualDirectory -Identity “myservername\ECP (Default Web Site)” -ExternalURL “https://outlook.mydomain.com/ECP”
Set-ECPVirtualDirectory -Identity “myservername\ECP (Default Web Site)” -InternalURL “https://outlook.mydomain.com/ECP”

EWS (Exchange Web services)

Get-WebServicesVirtualDirectory -server myservername | Select Server,ExternalURL,InternalURL | fl

Set-WebServicesVirtualDirectory

Set-WebServicesVirtualDirectory –Identity “myservername\EWS (default web site)” -ExternalUrl “https://outlook.mydomainname.com/ews/exchange.asmx
Set-WebServicesVirtualDirectory –Identity “myservername\EWS (default web site)” -InternalUrl “
https://outlook.mydomainname.com/ews/exchange.asmx

ActiveSync (Exchange Active Sync)

Get-ActiveSyncVirtualDirectory -server myservername | Select Server,ExternalURL,InternalURL | fl

Set-ActiveSyncVirtualDirectory

Set-ActiveSyncVirtualDirectory –Identity “myservername\Microsoft-Server-ActiveSync (default web site)” -ExternalURL “https://outlook.mydomainname.com/Microsoft-Server-ActiveSync”
Set-ActiveSyncVirtualDirectory –Identity “myservername\Microsoft-Server-ActiveSync (default web site)” -InternalURL “https://outlook.mydomainname.com/Microsoft-Server-ActiveSync”

AutoDiscover ( Exchange XML auto configuration setup file)

Not enabled as default. please note that autodiscover must be set as an A-record in your DNS. Also note that autodiscover is not an Virtual directory but is has a URL pointing to it.

To get a list from all autodiscover servers use:

Get-ClientAccessServer | Select Name,AutoDiscoverServiceInternalURI

Set-AutodiscoverVirtualDirectory

Set-ClientAccessServer -Identity “myservername” -AutoDiscoverServiceInternalUri “https://autodiscover.mydomainname.com/autodiscover/autodiscover.xml”

 

Outlook anywhere (HTTP/RPC)

Get-OutlookAnywhere -Server myservername or Get-OutlookAnywhere -Identity “myservername\Rpc (Default Web Site)”

GetOutlookAnywhere | SetOutlookAnywhere ExternalHostname outlook.mydomainname.com InternalHostname outlook.mydomainname.com ExternalClientsRequireSsl $true InternalClientsRequireSsl $False DefaultAuthenticationMethod NTLM

 

MAPI/HTTP (New outlook Anywhere)

Not enabled as default. Requires Exchange 2013 SP1. Clients must be Outlook 2013 sp1 or newer or outlook 2010 with sp3. Fallback is OutlookAnywhere for older clients.

Get-MapiVirtualDirectory -Identity “mapi (Default Web Site)”

Get-MapiVirtualDirectory -Server myservername

Set_Mapi over HTTP

Set-MapiVirtualDirectory -Identity “myservername\mapi (Default Web Site)” -InternalUrl https://outlook.mydomain.com/mapi

Set-MapiVirtualDirectory -Identity “myservername\mapi (Default Web Site)” -ExternalURL https://outlook.mydomain.com/mapi

Set-OrganizationConfig -MapiHttpEnabled $true

Test-OutlookConnectivity -RunFromServerId mymailservername -ProbeIdentity OutlookMapiHttpSelfTestProbe

Get-MapiVirtualDirectory -Identity “mapi (Default Web Site)” -InternalUrl “https://outlook.mydomainname.com/mapi” -IISAuthenticationMethods NTLM,Negotiate

8.Checking Virtual Directory settings #

OWA
Get-OwaVirtualDirectory | Select Name, IsValid, Server, InternalUrl, ExternalUrl, BasicAuthentication, WindowsAuthentication, Formsauthentication, LogonFormat
Set-OwaVirtualDirectory

 

OAB
Get-OabVirtualDirectory | Select Name, IsValid, Server, Internal*, External*, *Authentication
Get-OabVirtualDirectory

 

ECP
Get-EcpVirtualDirectory | Select Name, IsValid, Server, InternalUrl, ExternalUrl, BasicAuthentication, WindowsAuthentication, Formsauthentication
Get-EcpVirtualDirectory

 

EWS
Get-WebServicesVirtualDirectory | Select Name,  IsValid, Server, InternalUrl, ExternalUrl, BasicAuthentication, WindowsAuthentication
Get-WebServicesVirtualDirectory

 

ActiveSync
Get-ActiveSyncVirtualDirectory | Select Name, Server,IsValid,BasicAuthEnabled,WindowsAuthEnabled,ExternalURL,InternalURL,WebSiteEnabled
Get-ActiveSyncVirtualDirectory

 

 

AutodiscoverVirtualDirectory
Get-AutodiscoverVirtualDirectory | Select Name, Server, IsValid, BasicAuthentication, WindowsAuthentication
Get-AutodiscoverVirtualDirectory

Lets read out all the above in one step:
#Store needed info in variables.
$owa = Get-OwaVirtualDirectory | Select Name, IsValid, Server, InternalUrl, ExternalUrl, BasicAuthentication, WindowsAuthentication, Formsauthentication, LogonFormat
$oab = Get-OabVirtualDirectory | Select Name, IsValid, Server, Internal*, External*, *Authentication
$ecp = Get-EcpVirtualDirectory | Select Name, IsValid, Server, InternalUrl, ExternalUrl, BasicAuthentication, WindowsAuthentication, Formsauthentication
$ews = Get-WebServicesVirtualDirectory | Select Name, IsValid, Server, InternalUrl, ExternalUrl, BasicAuthentication, WindowsAuthentication
$activesync = Get-ActiveSyncVirtualDirectory | Select Name, Server,IsValid,BasicAuthEnabled,WindowsAuthEnabled,ExternalURL,InternalURL,WebSiteEnabled
$autodisc = Get-AutodiscoverVirtualDirectory | Select Name, Server, IsValid, *Authentication
#Print out the variables on screen
$owa, $oab,$oab, $ecp, $ews,$activesync,$autodisc

 

9.Default Virtual Directory settings #

Autodiscover

[PS] C:\Windows\system32>get-autodiscovervirtualdirectory exch01\autodiscover* | fl name, internal*, external*, *authentication

Name                          : Autodiscover (Default Web Site)
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
InternalUrl                   :
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalUrl                   :
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : True
DigestAuthentication          : False
WindowsAuthentication         : True
OAuthAuthentication           : True
AdfsAuthentication            : False
 

IIS FE: Anonymous, Basic, Windows Authentication
IIS BE: Anonymous, Windows Authentication

ECP

[PS] C:\Windows\system32>Get-ecpvirtualDirectory exch01\ecp* | fl name, internal*, external*, *authentication

Name                          : ecp (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
InternalUrl                   : https://exch01.contoso.com/ecp
ExternalUrl                   :
ExternalAuthenticationMethods : {Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False

IIS FE: Anonymous, Basic
IIS BE: Anonymous, Basic

EWS

[PS] C:\Windows\system32>Get-WebServicesVirtualDirectory exch01\ews* | fl name, internal*, external*, *authentication

Name                          : EWS (Default Web Site)
InternalNLBBypassUrl          :
InternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
InternalUrl                   : https://exch01.contoso.com/EWS/Exchange.asmx
ExternalAuthenticationMethods : {Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalUrl                   :
CertificateAuthentication     :
LiveIdNegotiateAuthentication :
WSSecurityAuthentication      : True
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : True
OAuthAuthentication           : True
AdfsAuthentication            : False

IIS FE: Anonymous, Basic
IIS BE: Anonymous, Basic

Microsoft-Server-ActiveSync

 

[PS] C:\Windows\system32>Get-activesyncvirtualDirectory exch01\microsoft* | fl name, internal*, external*, *authentication

Name                          : Microsoft-Server-ActiveSync (Default Web Site)
InternalUrl                   : https://exch01.contoso.com/Microsoft-Server-ActiveSync
InternalAuthenticationMethods : {}
ExternalUrl                   :
ExternalAuthenticationMethods : {}
 

IIS FE: Basic
IIS FE: Basic

OAB

 

[PS] C:\Windows\system32>Get-oabVirtualDirectory exch01\oab* | fl name, internal*, external*, *authentication

Name                          : OAB (Default Web Site)
InternalUrl                   : https://exch01.contoso.com/OAB
InternalAuthenticationMethods : {WindowsIntegrated}
ExternalUrl                   :
ExternalAuthenticationMethods : {WindowsIntegrated}
BasicAuthentication           : False
WindowsAuthentication         : True
 

IIS FE: Windows Authentication
IIS FE: Windows Authentication

OWA

 

[PS] C:\Windows\system32>Get-OwaVirtualDirectory exch01\owa* | fl name, internal*, external*, *authentication

Name                          : owa (Default Web Site)
InternalAuthenticationMethods : {Basic, Fba}
InternalUrl                   : https://exch01.contoso.com/owa
ExternalUrl                   :
ExternalAuthenticationMethods : {Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False

IIS FE: Basic
IIS BE: Anonymous, Windows Authentication

PowerShell

 

[PS] C:\Windows\system32>Get-powershellvirtualDirectory exch01\powershell* | fl name, internal*, external*, *authentication

Name                          : PowerShell (Default Web Site)
InternalAuthenticationMethods : {}
InternalUrl                   : http://exch01.contoso.com/powershell
ExternalAuthenticationMethods : {}
ExternalUrl                   :
CertificateAuthentication     : True
LiveIdNegotiateAuthentication : False
WSSecurityAuthentication      : False
LiveIdBasicAuthentication     : False
BasicAuthentication           : False
DigestAuthentication          : False
WindowsAuthentication         : False
OAuthAuthentication           : False
AdfsAuthentication            : False
 

IIS FE: None
IIS BE: Windows Authentication

RPC

 

[PS] C:\>Get-outlookanywhere exch01\rpc* | fl name, internal*, external*, *authentication

Name                               : Rpc (Default Web Site)
InternalHostname                   : exch01.contoso.com
InternalClientAuthenticationMethod : Ntlm
InternalClientsRequireSsl          : False
ExternalHostname                   :
ExternalClientAuthenticationMethod : Negotiate
ExternalClientsRequireSsl          : False
 

IIS FE: Basic, Windows Authentication
IIS FE: Windows Authentication

10.Enable Mapi over Http #

Once you hace deployed Microsoft Exchange Server 2013 SP1 (or later), one of the more interesting features you can take advantage of is MAPI over HTTP (code-named alchemy). MAPI over HTTP provides the ability for Messaging API (MAPI) clients and servers to communicate across a HTTP connection without using remote procedure calls (RPCs). Ever since its debut back in 1996, Exchange and its clients have used RPCs. The elimination of the now-aged mechanism marks the conclusion of a modernization process that began more than a decade ago.

The Roots of RPC in Exchange

RPC has a long and noble history. In the early 1990s, Microsoft built on the work of the Open Software Foundation (OSF) to create RPC as an interprocess communications (IPC) mechanism that underpinned client-server applications such as Outlook and Exchange. Applications that use RPCs don’t have to worry about the details of communication across local and remote networks through different protocols because the RPC layer is responsible for this activity.

You can also check if you are using mapi over http in Exchange by running the command below:
Get-OrganizationConfig | fl *mapi*

Enable MAPI over HTTP.

  • First of all you need to install .NET frameworks 4.5.1 for optimal MAPI/HTTP performance.

After that we are good to go.

First let’s check the new virtual directory “MAPI”

Get-MapiVirtualDirectory | ft server, *url*

Like in the past with the other virtual directories we also need to change the URLs here – you should also set the ExternalUrl

Example : Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl https://mail.contoso.com/mapi

Example : Get-MapiVirtualDirectory -Server mailserver01 | Set-MapiVirtualDirectory -InternalUrl https://outlook.mydomainname.com/mapi -ExternalUrl https://outlook.mydomainname.com/mapi

Example : Get-MapiVirtualDirectory -Server mailserver02 | Set-MapiVirtualDirectory -InternalUrl https://outlook.mydomainname.com/mapi -ExternalUrl https://outlook.mydomainname.com/mapi

To set the authentcation for the virtual directory:

Set-MapiVirtualDirectory -Identity “Mailserver02\mapi (Default Web Site)” -IISAuthenticationMethods NTML,Negotiate

Then we need to activate MAPI/HTTP

Set-OrganizationConfig -MapiHttpEnabled $true

Now let’s take a look at the Outlook connection before

RPC/HTTP

In a few month Outlook will suppress the old “The Microsoft Exchange administrator….” when you enable this protocol. This will be in an update coming May 2014. Until then users will get this.

This prompt will soon be eliminated

Now let’s take a look at the protocol in Outlook after we have enabled MAPI over HTTP.

MAPI/HTTP

Along with this new protocol we also have got some new logs. They are placed here:

  • CAS: %ExchangeInstallPath%\Logging\HttpProxy\Mapi\
  • Mailbox: %ExchangeInstallPath%\Logging\MAPI Client Access\
  • Mailbox: %ExchangeInstallPath%\Logging\MAPI Address Book Service\

Troubleshooting and testing:

Test-OutlookConnectivity -RunFromServerId mailserver01 -ProbeIdentity OutlookMapiHttpSelfTestProbe

Test-OutlookConnectivity -RunFromServerId mailserver02 -ProbeIdentity OutlookMapiHttpSelfTestProbe

 

If you wan’t to check if you are able to connect to the MAPI over HTTP endpoint, simply go to this URL https://mail.contoso.com/mapi/emsmdb

Here you are also able to see which servers you are connected to. Cafe is the CAS front end server and Mailbox is the server where your mailbox is located.

Now if we add the flag ?Showdebug=yes things get even more interesting.

https://mail.contoso.com/mapi/emsmdb/?showdebug=yes

 

 

 

11.Change OWA Log on Options #

Exchange 2013/2016 Change OWA Log on Options

In Exchange 2013 and Exchange 2016 , by default the log on options for OWA are Domainname\Username, in Exchange 2010 we could change this in the ECP, this functionality is currently not in the Exchange 2013 ECP, so we must use power shell. In the example below we change it so OWA authentication is user name and password onlyand also so that a user can log into Exchange with their email address.These commands also apply to Exchange 2010.

Before

owa 2013 logon options

owa 2013 log-on options

Powershell to Change OWA Authentication to User Name

Set-OwaVirtualDirectory "owa (Default Web Site)" -LogonFormat Username -DefaultDomain dommainname.local
Run CMD in administrator mode and type: iisreset

With the command above we set Exchange 2013 or Exchange 2016 OWA to be user name only.Then restart IIS for the changes to be effective.

After

Exchange 2013 OWA Username only

Exchange 2013 OWA Username only

Powershell to Change OWA Authentication to Email Address

Set-OwaVirtualDirectory "owa (Default Web Site)" -LogonFormat PrincipalName
iisreset

In the example above we set Exchange 2013/2016 OWA to log in as Email Address (Principal Name ).Then restart IIS to enable the changes.

After

log into owa with email address

log into owa with email address

 Change OWA Authentication Exchange 2013 and Exchange 2016 in the ECP

This can also obviously be done via the Exchange 2013 ECP also . To do so open up the ECP and select Servers > Virtual Directories > OWA. Then select Edit and you will see the options as seen below.

change owa authenticiaton in ECP exchange 2013

12.Exchange 2013 TLS BPA #

Exchange 2013 TLS BPA.

Whether you are running Exchange on-premises, in the cloud, or somewhere in between, we know that security is a top priority. Microsoft is committed to giving you the information needed to make informed decisions on how to properly secure your environment.

It has been suggested by some external parties that customers need to disable TLS 1.0 support. One piece of guidance we are aware of suggests taking steps to prepare to disable TLS 1.0 in summer of 2016. Another piece of guidance suggests that TLS 1.0 should not be used with internal-only applications (we do not believe that Exchange is typically used in this manner, as it connects to the outside world via SMTP). While we believe the intentions of both proposals are good and will promote adoption of TLS 1.1 & 1.2, at this time, we do not yet recommend disabling TLS 1.0 on your Exchange Server(s).

Additionally, while TLS 1.1 & 1.2 are superior to TLS 1.0, the real world risks may be somewhat overstated at this point due to mitigations that have been taken across the industry. Of course, security is rarely a binary decision: disabling TLS 1.0 doesn’t suddenly turn something insecure into something secure. That said, we will continue to work towards the goal of making TLS 1.1 & 1.2 work fully with Exchange and a broad array of clients.

More importantly, many customers may not have taken initial steps towards following current best practices. We believe that the first step towards a more secure environment is to have a TLS organizational awareness. While disabling TLS 1.0 on Exchange is not advised at this time, there are definite steps which can be taken today. TLS 1.0 is not widely viewed as insecure when SSL 3.0 is disabled, machines are properly updated, and proper ciphers are used. The current recommendations, which will continue evolving, are as follows:

  • Deploy supported operating systems, clients, browsers, and Exchange versions
  • Test everything by disabling SSL 3.0 on Internet Explorer
  • Disable support for SSL 3.0 on the client
  • Disable support for SSL 3.0 on the server
  • Prioritize TLS 1.2 ciphers, and AES/3DES above others
  • Strongly consider disabling RC4 ciphers
  • Do NOT use MD5/MD2 certificate hashing anywhere in the chain
  • Use RSA-2048 when creating new certificate keys
  • When renewing or creating new requests, request SHA 256-bit or better
  • Know what your version of Exchange supports
  • Use tools to test and verify
  • Do NOT get confused by explicit TLS vs. implicit TLS
  • (For now) Wait to disable TLS 1.0 on the Exchange server

Let’s get started down the list!

Deploy supported operating systems, clients, browsers, and Exchange versions

Perhaps it goes without saying, but the first step to securing any environment is to make sure that all servers, devices, clients, applications, etc. are updated. Most issues that support sees after following recommendations on Exchange are easily fixed with updates already available from the vendor of the incompatible device (printers, firewalls, load balancers) or software (mailers, etc.).

For Exchange, this means test & apply your Windows & Exchange updates regularly. Two reasons for this – first, an environment is only as secure as the weakest link; second, older software typically won’t let you take advantage of the latest TLS versions and ciphers. Make sure firewalls, old Linux MTAs, load balancers, and mass mailer software are all updated. Make sure the multifunction printers have the latest firmware.

Test everything by disabling SSL 3.0 on Internet Explorer

Disabling SSL 3.0 in the browser is a good first step, because it insures that all your users remain safe, no matter where they may browse. Additionally, it easily allows you to test to make sure that websites and applications will continue to work or not. There’s still a small bit of the Internet that is still relying on SSL 3.0, but the time is overdue for it to be retired. To test your environment with Internet Explorer, follow KB3009008.

image

Disable support for SSL 3.0 on the client

After testing, you may also consider disabling it at the SCHANNEL layer for all clients. While you are viewing these settings, make sure that your clients have TLS 1.1 & 1.2 enabled. In most cases, the most recent version supported by both the client & server will be used. This is a good way to start moving towards a more secure environment. All supported versions of Windows have TLS 1.1 & 1.2 capabilities, but the older ones may not have them enabled by default.

Note that registry changes under SCHANNEL are only good for applications that use the SCHANNEL API. Some applications could utilize 3rd party or open source security APIs (like OpenSSL) which may not look at these registry keys. Also, note that changes do not take effect until reboot.

Disable support for SSL 3.0 on the server

The next recommendation is to disable SSL 3.0 on all servers, Exchange included. Do this by following all recommendations in the original security bulletin. Since servers can be both clients and servers, it is recommended to follow all applicable steps. As before, while you are viewing these settings, make sure that your servers have TLS 1.1 & 1.2 enabled.

image

Note: Any of these registry changes require a reboot to take effect!

You can do this with confidence because TLS 1.0 will be the minimum which you support. Exchange and Windows have both supported TLS 1.0 for over a decade. TLS 1.0 itself is not considered vulnerable when SSL 3.0 is disabled on clients and servers. In fact, most Exchange sessions already have been using TLS 1.0 or even later, for years. You are simply disabling the ability for the session to be downgraded to SSL 3.0. Disabling SSL 3.0 is typically not too impactful except for clients and devices that are older than (roughly) 10 years old.

These recommendations should have already been carried out in your organization with haste. Even so, the POODLE vulnerability itself does require someone to intercept the traffic and sit between the client and server during the initial session negotiation. While this is not super difficult to accomplish, it is also not trivial. It is a much more severe problem for users who travel and for mobile devices which use hotspots. As many customers do support remote access to email, this is something for Exchange administrators to worry about. Since some mobile device vendors have not released ways to disable SSL 3.0, you can at least keep your Exchange resources safe by disabling SSL 3.0 on the server side.

In addition, enabling support for TLS v1.1 and v1.2 are highly recommended. But leaving TLS 1.0 enabled is a good thing for now. Clients and applications should always prefer the most secure option, provided that Windows, the application, and the client all support it.

Note: If you terminate SSL at load balancers, you’ll want to disable SSL 3.0 there as well (and perform subsequent steps there in addition). Check with your vendor to get their guidance. Also, be sure to check all Exchange servers which may be sharing a single VIP or DNS record.

Office 365 completed these changes, and you will find that SSL 3.0 is not possible for any protocol.

Prioritize TLS 1.2 ciphers, and AES/3DES above others

The next step we recommend is based on a step we took in Office 365 to prioritize the latest ciphers which are considered much more resilient to brute force attack. The thing with ciphers is that it isn’t just about enabling the most secure one and disabling the rest. You want to offer several choices for clients to allow maximum compatibility. You typically want to disable the ones which are the least secure, but leave others to provide choice. The negotiation of a particular cipher depends on:

  1. The client passes an ordered list of ciphers which it supports
  2. The server replies with the best cipher which it has selected (server gets final say)

Changing the order on the server can minimize the use of a less secure cipher, but you may want to go further and disable it completely. Cipher changes are made through this registry key, explained here.

image

Strongly consider disabling RC4 ciphers

Of course, there is risk of some clients not continuing to work if you disable too many ciphers. That said, Microsoft has been recommending that disabling RC4-suite of ciphers is a good best practice. It is considered to be a weak cipher. Disabling RC4 should be done with some care as it can introduce incompatibilities with older servers and clients, though problems should be minimal as supported versions of Windows have supported 3DES and AES alternatives for years. The rollout of this in Office 365 is in progress and should be completed shortly.

Do NOT use MD5/MD2 certificate hashing anywhere in the chain

Ciphers depend on the certificate chain being used – you can introduce problems when connecting to a host which has an insecure signature algorithm used in their chain. For example, we have seen that Office 365 SMTP transport is no longer able to connect to hosts with MD5 and MD2 hashing because they do not support modern ciphers. This applies to the certificate and any certificates in the chain. We see this with SMTP because Exchange is acting as a client, and because there are many older SMTP systems and firewalls still out there.

Use RSA-2048 when creating new certificate keys

Some things to watch out for when you renew or reissue certificates. First is that when creating your requests, use 2048-bit RSA. Anything less is not considered secure anymore.

When renewing or creating new requests, request SHA 256-bit or better

Second, when you renew, you should consider moving the signature algorithm from SHA1 to SHA2 if you haven’t already done so. This isn’t considered something that you need to worry about until renewal time, unless your certificate happens to be good for another couple of years – in which case, go ahead and take care of it now.

You can check your Exchange certificates with a browser (or in Certificate Manager MMC):

image

This example certificate was generated with Exchange 2013 on Windows 2012 R2. It has an RSA 2048-bit key and has an RSA SHA256 (SHA-2) signature algorithm.

Know what your version of Exchange supports

Some applications sometimes need to be re-compiled and tested to take advantage of these new protocols. So, every part of Exchange and Windows-based clients need to be examined and tested thoroughly. Currently, for Exchange Server, we are aware of the following limitations:

  • SMTP – key piece of Exchange server infrastructure – support for TLS 1.1 and 1.2 were added in Exchange Server 2013 CU8 and Exchange Server 2010 SP3 RU9. This means if you want to add support for the latest ciphers and TLS versions, you may need to apply an update.

IMPORTANT: SMTP is the main protocol used when communicating outside of your organization, something which is a key purpose of email. If you disable TLS 1.0, SMTP would no longer be able to use Opportunistic TLS with any external party which doesn’t support TLS 1.1 or 1.2. Emails will then be sent/received in the clear, which is certainly significantly less secure than TLS 1.0. That said, we have enabled new logging in the Exchange SMTP protocol logs to allow you to audit the impact of future changes on SMTP.

Additional Note: SMTP is notably a protocol where Exchange acts as both a client and a server. Some older server implementations have been observed to incorrectly implement version negotiation.  In these cases, the remote servers terminate the connection when Exchange (acting as a client) offers a version newer than TLS 1.0.  This results in a complete stoppage of email to these systems. Fortunately, these situations are becoming rare as time passes, but this is pointed out because the effects often are more impactful than a mail client which cannot connect.

  • POP/IMAP – not used as frequently in all environments, but if you do, beware that we only currently support TLS 1.1 and 1.2 on-premises in the Exchange Server 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via proper channels so we can prioritize it. Office 365 already has this support.
  • HTTPS (OWA, Outlook, EWS, Remote PS, etc.) – The support for TLS 1.1 and 1.2 is based on the support in IIS itself. Windows 2008 R2 or later supports both TLS 1.1 and 1.2, though the specific version of Windows may have these disabled or enabled by default. There is another important caveat here: the HTTPS proxy between CAS and Mailbox requires TLS 1.0 in current versions of Exchange Server – so disabling TLS 1.0 between CAS and Mailbox causes the proxy to fail. This is also something we have addressed in the Exchange 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via Support. If you have dedicated roles, you can technically disable TLS 1.0 between the client & CAS, but we still are not recommending this. Office 365 already supports TLS 1.1 & 1.2, if the client supports them.
  • Clients – TLS 1.0 is universal, with near 100% support. Though TLS 1.1 and 1.2 are growing more common, many Exchange clients still do not work with anything but TLS 1.0. For example, at this time, we are tracking multiple issues with Outlook running on Windows 8.0 or older. We are hoping to address these issues soon, but with Windows 7 commonly running in most customer environments, this is a really good reason to not disable TLS 1.0 yet. Comprehensive testing of other clients running without TLS 1.0 has not been completed by Microsoft at this time.

Note: Windows Remote Desktop may also have challenges, depending on your version of Windows. For servers which are managed remotely, be sure to test this first.

Use tools to test and verify

There are several tools and websites you can go to for testing your server(s) and clients. It is highly recommended to do so. Some offer a grading/scoring system. Others offer pass/fail. We’re inclined to recommend one with a scoring system, since security is about risks and tradeoffs. Don’t be surprised if one or more of these tools doesn’t fully test for POODLE and just thinks TLS 1.0 is bad. Use your newfound knowledge to read the results for what they are.

We prefer tools that let you check specific things (like cipher order, or individual TLS/SSL versions) in addition to the blanket “vulnerability tests”. There is also one fantastic (non-Microsoft) website called SSLLabs which simulates multiple clients and can warn you of compatibility issues with the clients which it knows about. For example, here we see that disabling TLS 1.0 would likely cause issues with older versions of Android clients:

image

In addition, you can see how you compare with the rest of the Internet. This is great for HTTPS. Most certificate vendors have test tools available as well, though they have differing coverage of what is tested.

Other tools are available which test additional protocols. Here is a test being run against IMAP on port 993 (referred to as the “SSL binding”; see below for explanation):

image

As you can see, even on port 993, TLS 1.0 is used with AES256.

Do NOT get confused by explicit TLS vs. implicit TLS

In the course of human events, shortcuts are taken. One unfortunate shortcut occurred when TLS 1.0 added optional support for a per-protocol implementation of STARTTLS, also known as “explicit TLS”. Prior to “explicit TLS”, if a server application level protocol wanted to implement SSL/TLS in addition to a non-secure option, it had to take up a separate port on the machine for each. This is “implicit TLS”. See the following chart:

Protocol IANA port (Explicit TLS) Protocol IANA Port (Implicit TLS)
E-SMTP 25 SMTPS 465**
POP3 110 POPS 995
IMAP4 143 IMAPS 993
HTTP 80* HTTPS 443

* HTTP doesn’t implement explicit TLS, because it is stateless and the overhead would not be worth it.
** Exchange specifically does not support SMTPS (implicit TLS).

The first protocol which implemented this verb was ESMTP. By doing so, SMTP could support clients & servers on the same port, and could also easily implement “opportunistic” TLS/SSL. In fact, Exchange has never supported SMTPS (465), although we do reuse that port by default in Exchange 2013 for one of the three transport roles. For POP and IMAP, Exchange supports both the explicit option and the implicit option.

What can be confusing is that because STARTTLS didn’t come about until TLS 1.0 – some people started confusing explicit TLS with “TLS” and some mail applications started using the terminology interchangeably. So, disabling port 995 & 993 does not turn off SSL 3.0 (you are disabling implicit POPS & IMAPS, but not SSL) – nor is enabling port 110 & 143 (explicit TLS) required for TLS 1.x. The terminology is confusing, but the concepts are mostly unrelated. This unfortunate optimization was brought into Exchange:

image

However, tinkering with ports and implicit/explicit should not be necessary as you are NOT disabling SSL 3.0 by doing so. Securing Exchange Server shouldn’t mean changing any of these settings – just the SCHANNEL registry settings discussed above.

(For now) Wait to disable TLS 1.0 on the Exchange server

In summary, as of July 2015, Exchange currently supports TLS 1.0, but can also support TLS 1.1 & 1.2 with the following minimum requirements met:

Protocol TLS v1.1/1.2 Minimum Requirements
SMTP Exchange 2013 CU8 or Exchange 2010 SP3 RU9
POP/IMAP Exchange 2016 Preview
HTTP (server) Windows 2008 R2;
MAPI clients must run Windows 8.1 or later
HTTP (proxy to MBX) Exchange 2016 Preview

As you can see, since Exchange Server 2016 isn’t released yet as an in-market product (it is for lab use only at this time), and since Windows 7 is still the most prevalent Windows version, it is quite impractical to fully disable TLS 1.0. Not only will POP/IMAP break (for lack of TLS 1.1 and 1.2 support), but you cannot disable TLS 1.0 on any Exchange server running the mailbox server role. Most importantly, disabling TLS 1.0 will result in compatibility issues with some common mobile devices, clients, and possibly interrupt some Internet email.

Don’t panic – if you have disabled SSL 3.0 and decided on a cipher order that your organization can agree on, you are likely quite secure, and you are not vulnerable to the POODLE attack. Microsoft is committed to adding full support for TLS 1.1 and 1.2. TLS v1.3 is still in draft, but stay tuned for more on that. In the meantime, don’t panic.

image

On a test Exchange lab with Exchange 2013 on Windows Server 2012 R2, we were able to achieve a top rating by simply disabling SSL 3.0 and removing RC4 ciphers. This is nearly as good as one can achieve at the time of this posting on released versions of Exchange without impacting common clients.

image

Additionally, this configuration should be highly compatible with nearly all clients and devices from the past decade or more, while utilizing the latest security with clients which do support it. Of course, security requires a watchful eye as new threats and vulnerabilities are discovered from time to time. As always, stay tuned to Security Bulletins and updates.

13.What is and turn Archiving on #

Archiving in Exchange Server 2013: A New Take on Retention

Microsoft made a lot of its business users happy with the launch of Exchange Server 2010. The new flavor of nearly five years ago brought many new exciting features to the party. Among them were retention policies, database availability groups, and the personal archive. The personal archive or archive mailbox, was a welcomed feature because up until then, archiving only existed in the form of journaling – useful, but not a complete solution. In Exchange 2010, users gained the ability to keep their main mailbox free of clutter and archive old messages based on needs and company policies.

Technically, nothing much has changed about archiving from Exchange 2010 to 2013 other than the name. Formerly known as the Personal Archive, In-Place Archiving lets users keep historical messages in a separate mailbox, which can be assessed by the Outlook and Outlook Web apps many businesses use on a regular basis. Despite not necessarily bringing anything new to the table on its own, this feature still manages to help take retention to another level as part of a robust suite of data management and compliance tools.

Importance of Archiving in Business

Archiving is a method companies have been using for years to help meet compliance, eDiscovery, and general data management needs. In older versions of Exchange, the journal engine recorded copies of email messages and stored them in a separate mailbox on the server. Because Exchange data may consist of contacts, calendar, and task items, in addition to emails, companies often turned to third-party solutions to support their compliance and retention needs. Storage requirements have changed over the years, so Exchange’s approach to archiving had to change with it.

Getting Mailbox Items in the Archive

Rather than relying on PST files, which have their own history of troubles, organizations can use In-Place Archiving in Exchange 2013 as an efficient means of keeping old data tucked away for a rainy day. You can get your data to the archive box in three ways:

1. Manually move items. Mailbox users can migrate messages and other items from their primary inbox to the archive mailbox by moving or copying them.

2. Automated move.  Mailbox users can create rules in Outlook that automatically send messages to the archive folder from their mail client.

3. Assign retention policies. Administrators can set up retention rules that automatically move messages and data to the archive.

It’s also possible to import data stored in your .pst files to your archive mailboxes. Administrators can make import requests from the Exchange Management Shell, or use the PST Capture tool, which hunts down .pst files on your server and imports them to the archive. How you get your data there will probably be influenced by the dynamics of your data infrastructure.

Addressing Exchange Archive and Storage Concerns

Archiving can be a tremendous challenge from a storage standpoint. Exchange Server 2013 helps you manage storage in a couple of ways. First, archive mailboxes can be easily kept in low-cost storage containers on-premises or in the cloud. You can also manage their size by assigning quotas and enforcing restrictions. For instance, administrators can determine that users can’t send or receive messages once their archive mailbox exceeds a certain capacity. It’s important to give users the space they need, while keeping in mind that Exchange 2013 has a max archive size of 50 GB.

Exchange Archive Education

The archiving features in Exchange 2013 are pretty extensive, especially as they pertain to retention policies. These policies allow users to create retention tags that determine when certain items should be moved from their personal mailbox and into the archive mailbox. For example, depending on what business dictates, mailbox items can be configured to move after a year, or never. In the event that a mailbox has not been covered under a retention policy, a default policy is assigned, which rules that all items be automatically archived after two years.

Companies and administrators are advised to take some time to educate users on Exchange archiving policies. A good training program will make them familiar with how to use archiving on its own and in concert with the retention policies. They should also be reminded of how messages are automatically moved (to prevent freakouts) and know the best way to navigate to content sent to the archive. Wouldn’t be a bad idea to put together a knowledgebase or lighter documentation on how to get the most from archiving in Exchange.

With features such as In-Place Holds, Data Loss Prevention (DLP), and new retention policies, the latest incarnation of Exchange Server is ready to handle compliance in-house and limit reliance on third-party solutions in the process. New and improved archiving capabilities join these features in giving organizations a better handle of their mission-critical business data for however long they need it.

To set the archive policy, navigate to in the ECP to Compliance management and then Retentions policies.

  • Create a new retention policy or edit the default one.

  • To create a new retention tag to use in your retention policy navigate to retention tags.

A mailbox user does not have an archive by default, to turn on the archive for the user:

  • Navigate to recipients, find the user that needs an archive and in the right pane enable Archive.

 

14.Get-MobileDevice export to excel #

View mobile device information for users

Users can configure multiple mobile devices for synchronization with Microsoft Exchange Server 2013. You can use the EAC or the Shell to view a list of mobile devices that are associated with a specific user.

For additional management tasks related to mobile devices, see Exchange ActiveSync.

Use the EAC to view mobile device information for users

The EAC displays a list of mobile devices that are currently synchronizing with a user’s mailbox. You can view mobile devices by family, model, phone number, or status.

  1. In the EAC, click Recipients > Mailboxes and choose a mailbox.
  2. In the Details pane, scroll to Phone and Voice Features and click View details to display the Mobile Device Details screen.

Use the Shell to view mobile device information for users

You can use the Get-MobileDevice cmdlet to view a list of mobile devices for a specific user.

  1. Run the following command.

Get-MobileDevice -Mailbox useralias

To run a full report exported to an excel file with users and there mobile devices:

Get-ActiveSyncDevice | select-object DeviceModel,deviceaccessstate,deviceaccessstatereason,DeviceOS,UserDisplayName | sort-object devicemodel | Export-Csv -Path c:\mobusers.csv

 

15.Export Mailbox to PST file #

Learn to Export Mailbox From Offline Exchange Database

 

http://lettoknow.com/wp-content/uploads/2017/08/export-mailbox-from-offline-exchange-640x374.png

The MS Exchange Server is an email and calendaring server which is nowadays widely used in many organization including small as well as large-scale industries. Exchange Server is compatible with Outlook email client as it manages users mailbox which stores emails, messages, contacts, journals, tasks etc. All the data of Exchange is stored in EDB file format. EDB aka Exchange database file is the repository of Exchange Server, which is designed on single client-server architecture. The Exchange Server makes use of Extensible Storage Engine to access its data files. This EDB file is prone to corrupt, dismounted, or being offline.

How EDB File Become Offline/Dismounted?

There are several reasons why Exchange EDB file gets dismounted or become offline. Some of them are discussed below:

  • Due to some reasons or the situations the Exchange administrator needs to disconnect the mailboxes from the Exchange Server. Once the database gets disconnected it is known as Offline EDB file.
  • If there is no Exchange Server installed on the machine & you have an EDB file then it is also considered as an offline EDB file.
  • Another reason which makes EDB file offline is when Exchange mailbox gets corrupted & thus cannot be mounted back to the Server. The major reasons behind corruption are the virus infection, application malfunction, shut down, and much more.

Reasons to Export Offline Exchange Database to PST

  • Users can export data from Exchange mailboxes to PST for legal investigation & for documentation.
  • Users can restore mailbox database into Outlook PST as a backup for later use & can send this file to another user too.
  • If the user wants to migrate from one platform to the other then PST file is very useful for completing the task as MS Outlook is a popular email client to send & receive messages.

Export Mailbox from Offline Exchange Database Manually

You can use “MailboxExportRequest” command to export single or multiple mailboxes to another file format. Before starting the process, you can refer to some options while exporting mailbox data of Exchange Server.

  • Use IsArchive for migrating data from archive folder
  • Use ContentFilter for filtering out the messages
  • Use Include or Exclude Folder to specify folders
  • Use AssociatedMessagesCopyOption for transferring messages

Follow Below Mentioned Commands to Export-mailbox Database Offline

1. Run New-MailboxExportRequest.
2. Start the procedure to export data from primary mailboxes to Outlook
3. Try the command to export primary mailbox messages

http://lettoknow.com/wp-content/uploads/2017/08/f1.png

If you want to archive information of mailboxes file then you can use the following command:

http://lettoknow.com/wp-content/uploads/2017/08/f2.png

In the below section some more “MailboxExportRequest” cmd has been defined.

Bad or Corrupt Item Limit

Run Set-MailboxExportRequest Command. If the Export process gets failed then run “Set-MailboxExportRequest” which will help to repair failed export request. In case the export request is failed, then you can also define a maximum no. of bad items.

http://lettoknow.com/wp-content/uploads/2017/08/f3.png

Stop the Mailbox Database Migrating Process

Run Suspended-MailboxExportRequest Command. If you want to stop the export process after any time creating request then you can give the name of the suspended export request like this mentioned in the cmd.

http://lettoknow.com/wp-content/uploads/2017/08/f4.png

Suspend Export Request & Restart the Service

If you want to suspend the whole export request which is in progress then you can use “Get-MailboxExportRequest” cmd. Through this command, you can suspend all the export requests that are in progress status.

http://lettoknow.com/wp-content/uploads/2017/08/f5.png

Resume Suspended Export Process

Run Resume-MailboxExportRequest Command. Use this cmd to restart the suspended or failed procedure.

http://lettoknow.com/wp-content/uploads/2017/08/f6.png

Remove All the Exporting Request

http://lettoknow.com/wp-content/uploads/2017/08/f7.png

Get Detailed Progress Report of Export Request

Run Get-MailboxExportRequestStatistics Command. This cmd is used to get the complete detailed information about the export request.

http://lettoknow.com/wp-content/uploads/2017/08/f8.png

Store Report Of Export Mailbox in CSV file

If you want to save the export report then you can use the following command.

http://lettoknow.com/wp-content/uploads/2017/08/f9.png

Instant Solution to Export Mailbox from Offline Exchange Database

Through the above mentioned manual methods you can easily migrate mailboxes from offline Exchange database to PST. But these manual procedures are very lengthy & time-consuming. Even sometimes it does not give correct results. So, in this case, I would like to suggest you go with an automated solution i.e Exchange Recovery software which can easily migrate mailboxes from Offline EDB files to Outlook PST.

Salient Features

  • Supports Exchange Server 2016, 2013 & all below versions
  • Supports to recover deleted emails from Exchange mailboxes
  • Recover all data items from dismounted & offline EDB file
  • Maintains Folder Hierarchy
  • Save & loads scanned EDB file

Conclusion

The write-up which is discussed above will help you export mailbox from offline Exchange database. To overcome the limitations of these manual methods we can go for third party utility such as Exchange Recovery. This software supports the direct recovery from EDB files without any recovery database, it has the feature to efficiently migrate Exchange database to PST.

 

16.Enable and Configure Imap4 #

Enable and configure IMAP4 on an Exchange 2016/2013 server

Learn how to enable and configure IMAP4 on an Exchange 2016 server for access by IMAP4 clients.

By default, IMAP4 client connectivity isn’t enabled in Exchange. To enable IMAP4 client connectivity, you need to perform the following steps:

  1. Start the IMAP4 services, and configure the services to start automatically:
    • Microsoft Exchange IMAP4   This is the Client Access (frontend) service that IMAP4 clients connect to.
    • Microsoft Exchange IMAP4 Backend   IMAP4 client connections from the Client Access service are proxied to the backend service on the server that hold the active copy of the user’s mailbox. For more information, see Exchange 2016 architecture.
  2. Configure the IMAP4 settings for external clients.

By default, Exchange uses the following settings for internal IMAP4 connections:

    • IMAP4 server FQDN   <ServerFQDN>. For example, mailbox01.contoso.com.
    • TCP port and encryption method   993 for always TLS encrypted connections, and 143 for unencrypted connections, or for opportunistic TLS (STARTTLS) that results in an encrypted connection after the initial plain text protocol handshake.

To allow external IMAP4 clients to connect to mailboxes, you need to configure the IMAP4 server FQDN, TCP port, and encryption method for external connections. This step causes the external IMAP4 settings to be displayed in Outlook on the web (formerly known as Outlook Web App) at Settings > Options > Mail > Accounts > POP and IMAP.

IMAP settings in Outlook on the web

  1. Restart the IMAP4 services to save the changes.
  2. Configure the authenticated SMTP settings for internal and external clients. For more information, see Configure authenticated SMTP settings for POP3 and IMAP4 clients in Exchange 2016.

What do you need to know before you begin?

  • Estimated time to complete each procedure: 5 minutes.
  • Secure Sockets Layer (SSL) is being replaced by Transport Layer Security (TLS) as the protocol that’s used to encrypt data sent between computer systems. They’re so closely related that the terms “SSL” and “TLS” (without versions) are often used interchangeably. Because of this similarity, references to “SSL” in Exchange topics, the Exchange admin center, and the Exchange Management Shell have often been used to encompass both the SSL and TLS protocols. Typically, “SSL” refers to the actual SSL protocol only when a version is also provided (for example, SSL 3.0). To find out why you should disable the SSL protocol and switch to TLS, check out Protecting you against the SSL 3.0 vulnerability.
  • To learn how to open the Exchange Management Shell in your on-premises Exchange organization, see Open the Exchange Management Shell.
  • You need to be assigned permissions before you can perform this procedure or procedures. To see what permissions you need, see the “POP3 and IMAP4 Permissions” section in the Clients and mobile devices permissions topic.
  • For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.

How do you do this?

Step 1: Start the IMAP4 services, and configure the services to start automatically

You can perform this step by using the Windows Services console, or the Exchange Management Shell.

Use the Windows Services console to start the IMAP4 services, and configure the services to start automatically

  1. On the Exchange server, open the Windows Services console. For example:
    • Run the command services.msc from the Run dialog, a Command Prompt window, or the Exchange Management Shell.
    • Open Server Manager, and then click Tools > Services.
  2. In the list of services, select Microsoft Exchange IMAP4, and then click Action > Properties.
  3. The Microsoft Exchange IMAP4 Properties window opens. On the General tab, configure the following settings:
    • Startup type   Select Automatic.
    • Service status   Click Start.

When you are finished, click OK.

  1. In the list of services, select Microsoft Exchange IMAP4 Backend, and then click Action > Properties.
  2. The Microsoft Exchange IMAP4 Backend Properties window opens. On the General tab, configure the following settings:
    • Startup type   Select Automatic.
    • Service status   Click Start.

When you are finished, click OK.

Use the Exchange Management Shell to start the IMAP4 services, and configure the services to start automatically

  1. Run the following command to start the IMAP4 services:
  2. Start-Service MSExchangeIMAP4; Start-Service MSExchangeIMAP4BE
  3. Run the following command to configure the IMAP4 services to start automatically:
  4. Set-Service MSExchangeIMAP4 -StartupType Automatic; Set-Service MSExchangeIMAP4BE -StartupType Automatic

For more information about these cmdlets, see Start-Service and Set-Service.

How do you know this step worked?

To verify that you’ve successfully started the IMAP4 services, use either of the following procedures:

  • On the Exchange server, open Windows Task Manager. On the Services tab, verify that the Status value for the MSExchangeIMAP4 and MSExchangeIMAP4BE services is Running.
  • In the Exchange Management Shell, run the following command to verify that the IMAP4 services are running:
  • Get-Service MSExchangeIMAP4; Get-Service MSExchangeIMAP4BE

Step 2: Use the Exchange Management Shell to configure the IMAP4 settings for external clients

To configure the IMAP4 settings for external clients, use the following syntax:

Set-ImapSettings -ExternalConnectionSettings “<FQDN1>:<TCPPort1>:<SSL | TLS | blank>”, “<FQDN2>:<TCPPort2>:<SSL | TLS | blank>”… -X509CertificateName <FQDN> [-SSLBindings “<IPv4Orv6Address1>:<TCPPort1>”,”<IPv4Orv6Address2>:<TCPPort2>”…] [-UnencryptedOrTLSBindings “<IPv4Orv6Address1>:<TCPPort1>”,”<IPv4Orv6Address2>:<TCPPort2>”…]

This example allows configures the following settings for external IMAP4 connections:

  • IMAP4 server FQDN   mail.contoso.com
  • TCP port   993 for always TLS encrypted connections, and 143 for unencrypted connections or opportunistic TLS (STARTTLS) encrypted connections.
  • Internal Exchange server IP address and TCP port for always TLS encrypted connections   All available IPv4 and IPv6 addresses on the server on port 993 (we aren’t using the SSLBindings parameter, and the default value is [::]:993,0.0.0.0:993).
  • Internal Exchange server IP address and TCP port for unencrypted or opportunistic TLS (STARTTLS) encrypted connections   All available IPv4 and IPv6 addresses on the server on port 143 (we aren’t using the UnencryptedOrTLSBindings parameter, and the default value is [::]:143,0.0.0.0:143).
  • FQDN used for encryption   mail.contoso.com. This value identifies the certificate that matches or contains the IMAP4 server FQDN.

Set-ImapSettings -ExternalConnectionSettings “mail.contoso.com:993:SSL”,”mail.contoso.com:143:TLS” -X509CertificateName mail.contoso.com

Notes:

  • For detailed syntax and parameter information, see Set-ImapSettings.
  • The external IMAP4 server FQDN that you configure needs to have a corresponding record in your public DNS, and the TCP port (143 or 993) needs to be allowed through your firewall to the Exchange server.
  • The combination of encryption methods and TCP ports that you use for the ExternalConnectionSettings parameter need to match the corresponding TCP ports and encryption methods that you use for the SSLBindings or UnencryptedOrTLSBindings parameters.
  • Although you can use a separate certificate for IMAP4, we recommend that you use the same certificate as the other Exchange IIS (HTTP) services, which is likely a wildcard certificate or a subject alternative name (SAN) certificate from a commercial certification authority that’s automatically trusted by all clients. For more information, see Certificate requirements for Exchange services.
  • If you use a single subject certificate, or a SAN certificate, you also need to assign the certificate to the Exchange IMAP service. You don’t need to assign a wildcard certificate to the Exchange IMAP service. For more information, see Assign certificates to Exchange 2016 services.

How you do know this step worked?

To verify that you’ve successfully configured the IMAP4 settings for external clients, run the following command in the Exchange Management Shell and verify the settings:

Get-ImapSettings | Format-List *ConnectionSettings,*Bindings,X509CertificateName

For more information, see Get-IMAPSettings.

Step 3: Restart the IMAP4 services

After you enable and configure IMAP4, you need to restart the IMAP4 services on the server by using the Windows Services console, or the Exchange Management Shell.

Use the Windows Services console to restart the IMAP4 services

  1. On the Exchange server, open the Windows Services console.
  2. In the list of services, select Microsoft Exchange IMAP4, and then click Action > Restart.
  3. In the list of services, select Microsoft Exchange IMAP4 Backend, and then click Action > Restart.

Use the Exchange Management Shell to restart the IMAP4 services

Run the following command to restart the IMAP4 services.

Restart-Service MSExchangeIMAP4; Restart-Service MSExchangeIMAP4BE

For more information about this cmdlet, see Restart-Service.

To verify that you’ve successfully restarted the IMAP4 services, run the following command:

Get-Service MSExchangeIMAP4; Get-Service MSExchangeIMAP4BE

Step 4: Configure the authenticated SMTP settings for IMAP4 clients

Because IMAP4 isn’t used to send email messages, you need to configure the authenticated SMTP settings that are used by internal and external IMAP4 clients. For more information, see Configure authenticated SMTP settings for POP3 and IMAP4 clients in Exchange 2016.

How do you know this task worked?

To verify that you have enabled and configured IMAP4 on the Exchange server, perform the following procedures:

  1. Open a mailbox in Outlook on the web, and then click Settings > Options.

Options menu location in Outlook on the web

  1. Click Mail > Accounts > POP and IMAP and verify the correct IMAP4 settings are displayed.

IMAP settings in Outlook on the web

Note: If you configured 993/SSL and 143/TLS values for the ExternalConnectionSettings parameter on the Set-ImapSettings cmdlet, only the 993/SSL value is displayed in Outlook on the web. Also, if the external IMAP4 settings that you configured don’t appear as expected in Outlook on the web after you restart the IMAP4 services, run the command iisreset.exe /noforce to restart Internet Information Services (IIS).

  1. You can test IMAP4 client connectivity to the Exchange server by using the following methods:
    • Internal clients   Use the Test-ImapConnectivity cmdlet. For example, Test-ImapConnectivity -ClientAccessServer<ServerName> -Lightmode -MailboxCredential (Get-Credential). For more information, see Test-ImapConnectivity.

Note: The Lightmode switch tells the command test IMAP4 logons to the server. To test sending (SMTP) and receiving (IMAP4) a message, you need to configure the authenticated SMTP settings as described in Configure authenticated SMTP settings for POP3 and IMAP4 clients in Exchange 2016.

    • External clients   Use the Exchange Server > Imap Email test in the Microsoft Remote Connectivity Analyzer at http://go.microsoft.com/fwlink/p/?LinkID=313840.

Note: You can’t use IMAP4 to connect to the Administrator mailbox. This limitation was intentionally included in Exchange 2016 to enhance the security of the Administrator mailbox.

17.Exchange mailbox count #

Exchange mailbox count

 

To quickly count how many mailboxes there are in use in your Exchange envoirment.

Shared mailboxes

(Get-Recipient -RecipientTypeDetails sharedmailbox -ResultSize Unlimited).count

 

User Mailbxes

(Get-Recipient -RecipientTypeDetails usermailbox -ResultSize Unlimited).count

 

Room Mailboxes

(Get-Recipient -RecipientTypeDetails roommailbox -ResultSize Unlimited).count

 

Total

(Get-Mailbox -ResultSize Unlimited ).count

Help Guide Powered by Documentor
Suggest Edit