Running Exchange 2013 CU8 or higher? Download the new wizard!

The Exchange hybrid team has been working hard over the past year getting the 3^rd version of the Hybrid Configuration Wizard (HCW) ready. This new version is called the Microsoft Office 365 Hybrid Configuration Wizard. This article tells you what’s new and shows you how to run the wizard. We also explain the various issues that have been addressed with the new Wizard, and touch on some of the telemetry we pull with every run of the wizard. We think this new wizard has enough of the old to reduce the learning curve while adding plenty of enhancements to make your hybrid deployment as friction free as possible.

Microsoft Office 365 Hybrid Configuration Wizard Stand-Alone Application

This version of the HCW is a standalone application that is downloaded from the service. This is an important change because one of the bigger limitations of the previous versions of the HCW was that it was included with the on-premises product. This led to the following issues:

• Up-To-Date hybrid experience: When you ran the HCW you got the experience consistent with your on-premises version of Exchange Server. This meant that if you are running Exchange 2013 CU7 you got the CU7 experience. If you ran Exchange 2013 CU9 you got the CU9 experience in HCW. Each customer would have a different HCW experience.

Solution: The new HCW will download the latest version every time it is run, therefore providing the latest and improved experience. As soon as we make changes to, or fix any issues in the HCW, customers will see the benefits immediately.

• HCW not tied to Cumulative Updates: Since the previous versions of the HCW were part of the on-premises product they were updated per the regular Exchange Serviceability model. This means that the hybrid team had to wait for a new Cumulative Update (Rollup for Exchange 2010) every three months to deliver any enhancements or changes. For a component like hybrid that is a problem, we have to be agile enough to handle changes not just to on-premises, but also in the service.

Solution: Again, every time you attempt to run the HCW we will ensure you have the latest version. This version will of course go through its rounds of validation, but it is in no way tied to the releases of a CU. No more waiting months for fixes!

• Piloting Changes: As we move forward with this new HCW we will be making some aggressive changes. In the months ahead we want to add more capabilities to HCW. One of the most important changes in HCW will be the ability to roll out feature changes slowly and in a controlled manner.

Solution: We have built in the capability to allow customers who are on “first Release” and any other customers we specify (for example TAP customers) to see the latest version of the HCW. Often the latest release and the production release will be the same version, but we do have the ability to pilot versions of the HCW as needed.

Improvements to error handling

The HCW has a lot of dependencies and relies on various prerequisites for a successful completion. For example, you have to add an external TXT record for the HCW to create the Federation Trust, you have to have your certificates properly installed on your Exchange servers, and you have to have Internet access from your Exchange servers to name a few. I am not trying to scare you away from hybrid, in fact the wizard does walk you through most of the prerequisites. I am instead trying to point out that there are many failure points for the HCW to contend with.

Up till now the solution was to provide you an error message that included a stack trace. These error messages are extremely difficult to decipher and often the first reaction after a couple of failed Internet searches was to call into support. Figure 1 shows the old error Experience for those that may not be familiar with it.

Figure 1: Old error messages

Our goal is to allow you to successfully configure without an error, but we also want to make sure that we give you the information needed to get past any hurdles you may face. Figure 2 shows a sample of the new (much more informative) error experience. In the sample you can see the following major improvements to the error experience:

• Improved Title: We have added the ability to see what Phase and Task were being completed at the time of the failure. For instance, you can know if we failed at the prerequisite check or configuration phase. You will also immediately know if you failed to create the Organization Relationship or Outbound Connectors.
• Error code: We have added a new error code for all the possible error messages in the new wizard. You will now see all errors prepended with a code HCW8***. This change allows for our errors to be easily searched and it allows them to remain searchable even if we change the context of the errors.
• Humans can read the errors: One of the previous challenges was that we provided a stack trace as the error message instead of just a friendly actionable string. We now keep the stack trace in the logs for anyone who may want that information.
• New “More info” feature: We added the “More info…” option under the error message. We have recently associated a KB or TechNet article as the most likely solution to EVERY error message the HCW throws. Simply click the “More Info…” link and you will be taken to that solution
• Access to log Files: You can easily access the HCW log file by clicking on the link that says “Open Log File”. In addition, you will find the log file on the system were you ran the new wizard from by going to “%appdata%\Microsoft\Exchange Hybrid Configuration”. Keep in mind the old location for the logs in the Exchange install directory is not used.
• Coolest addition: When you run the HCW you will more than likely have the Exchange Admin Center already open, but there is a chance that if you run into an issue you will need to use either your on-premises or Exchange Online PowerShell. The new HCW error experience includes a link that will open the on-premises and/or Exchange Online PowerShell. We already have the credentials you entered into the wizard, so you can seamlessly open PowerShell by using those credentials. In addition, we open the Exchange Online PowerShell with a blue background and the Exchange on-premises PowerShell with a black background so you can easily differentiate the two.

Figure 2: Awesome error experience

Top issues solved by the new HCW

About a year ago we came out with a tool to assist you to troubleshoot your hybrid experience. This tool collects and parses the HCW log and provided a link to an article that gave a solution to your issue. The tool has been run thousands of times and has given us great insights into what the top failure points are for the HCW. This telemetry tells us what we need to focus on and allows us to see any failure trends, but in the end we were limited to the information gathered from folks that ran the HCW troubleshooter.

Because we want to be as helpful as possible, we now by default upload the HCW logs to the service when you run the new wizard. Gathering this data will allow us to serve you better by limiting the amount of time it takes for someone in support to find out more about your environment and it allows us to see any trending issues and failure points that we need to address. Even with the limited amount of logs we have collected from the troubleshooter, we have been able to identify the following issues and are addressing them in the new HCW. I think you will see why the log collection is so important to the hybrid team.

Note: If you want to opt out of uploading the Hybrid logs you can do that by using the registry key below on the machine were you are running the HCW from:
1. Navigate to the following location in the registry, create the path if needed:
Exchange 2016: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v16\Update-HybridConfiguration
Exchange 2013: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Update-HybridConfiguration
2. Create REG_DWORD “DisableUploadLogs” with value 1

TXT proof string issues

Any time you are required to add an DNS entry you are dealing with a potential for failure. HCW includes a step were you need to add a record to an external DNS to prove to the Azure Authorization Service (known as Microsoft Federation Gateway) that you own the domain. This step may seem trivial but it accounts for ~15% of our HCW failures.

Usually the TXT proof string get messed up in one of two ways:

• Incorrect string entered: when creating the DNS record to provide domain ownership we often see that the incorrect value was provided. This is in large part due to the way the HCW copied the value. In the previous version of the HCW, when you copied the TXT string, we prepended the words “Domain Proof” so it looked similar to “Domain Proof = t4jnhkjdesy78hrn…”.

Solution: While simple, moving forward we are only going to copy the part of the string that is needed from the “copy link” option in HCW, which should lead to less issues with incorrect TXT strings.

• Domain name lockouts: The point of providing this TXT string to the external DNS is so the service can validate that you own the domain and federation certificate. After a few failed attempts to validate a domain we lock you out from federating that domain for a few hours. The purpose of this lockout is to prevent a denial of service attack. Often this issue occurs because someone put the wrong value in DNS (see the first bullet), someone created the record and did not wait for replication of the record, or someone created the record in internal (not external) DNS.

Solution: To resolve this we created a new external endpoint in the service that will perform the DNS lookup for the TXT record and only try to federate the domain if the record is correct or if that new service endpoint cannot be found. The logic for this is as follows:

1. First we try to hit the new external service endpoint and see if the TXT record is resolvable externally and is correct in DNS. If so, we move forward with federating the domain.
2. If the record is either wrong or not resolvable, we inform you that you need to verify the record and wait for replication.
3. If the new external TXT validation service is not reachable, we will warn you that we could not verify the TXT record but allow you to continue anyway.

Figure 3 show the new TXT experience you will be getting with the Microsoft Office 365 Hybrid Configuration Wizard.

Figure 3: TXT records

Missing Certificate in Wizard

The HCW has a screen that asks you for the “Transport Certificate”. The HCW looks to ensure this certificate is installed on every server that you designated to be part of the Send and Receive Connector Configuration, as shown on the pages in Figure 4.

Figure 4: Send and Receive Connector

In order for the certificate to properly display you need to ensure that the following has been completed on all of the servers designated in the wizard pages shown in figure 4:

• The Certificate must be a third party trusted certificate.
• The proper names must be on the certificate such as mail.consoto.com or *.contoso.com.
• The SMTP service must be assigned to the certificate on each of the sending and receiving servers.
• The certificates must have a private key.

These requirements are nothing new, but if you have a large environment, getting all of this correct on a large number of servers can be a tough task. If even one server was missing any of the requirements, we would fail to show you the certificate. In previous versions of the HCW you were left with a blank screen (see figure 5) which offered no direction or solution.

Figure 5: Blank certificate

The Microsoft Office 365 Exchange Hybrid Configuration Wizard experience will not remove the certificate requirements, but it will help you solve the issue. The HCW will now show you a list of certificates that meet the requirements, and it will show you the servers that do not have a proper certificate installed (see figure 6). This will allow you to either remove those servers from the HCW receive and send connector pages, or you can properly install the certificate on those servers.

Figure 6: Better certificate error

A more efficient Hybrid experience

One of the things we tried to do with the HCW is ensure that we are performing the various configurations in the most efficient way possible (this is our on-going green effort). A good example of an inefficient task that the HCW previously performed was the Mailbox Replication Service (MRS) enablement process. In the HCW logs collected from the troubleshooter, we could see that this cmdlet was often taking an extremely long time to complete. What we do now, is enable the Migration endpoint on the servers in your environment so that you can start moving mailboxes when the HCW is complete without having to enable the endpoint. One of the cmdlets that we used in the previous version of HCW was get-WebServicesVirtualDirectory. In a larger often geographically dispersed environment this cmdlet could take over eight hours to run. In many cases you would end up getting the following error:

ERROR: Updating hybrid configuration failed with error 'Subtask Configure execution failed: Configuring organization relationship settings. Execution of the Set-WebServicesVirtualDirectory cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings. Unable to access the configuration system on the remote server. Make sure that the remote server allows remote configuration

Solution: We have resolved this issue in the new HCW using the -ADPropertiesOnly option with Get-WebServicesVirtualDirectory. This changes things so the HCW reads the MRS settings using a local directory call instead of waiting for a response from every server in the environment. This change along with a few others in this area, makes the process take around 15 minutes instead of 8 hours (your deployment times will vary) in these large environments. This is just one example of the type of cleanups we did in the HCW to improve the reliability and speed of the configuration tasks.

Autodiscover issues in HCW

The single most common failure point for the HCW is the inability to retrieve the Federation Information via the Autodiscover call initiated by the Get-FederationInformation cmdlet. The output of this cmdlet is needed in order to create the Organization Relationships so you can do things like free busy sharing. This accounts for nearly 30% of all HCW failures based on the logs collected from the troubleshooter (are you starting to see the importance of these log files?). When looking at the issue there are certain things the wizard cannot directly address. For instance, at times the issues are related to an improperly configured firewall, or someone doesn’t have a third-party certificate for IIS on the Exchange servers. However, a good portion of you have had things configured correctly and still we failed to complete the Get-FederationInformation cmdlet.

One of the things this cmdlet does is use DNS settings from the server you are connected to in order to resolve the Autodiscover endpoint and retrieve the federation information. Many customers do not have a DNS record created for Autodiscover internally since there is often no need for this. The internal Outlook client will use the Service Connection Point to find the Autodiscover endpoint so there is no need for this from an outlook standpoint, however the Get-FederationInformation cmdlet does not use the Service Connection Point. Therefore, if there is no forwarding configured for this zone in DNS the Get-FederationInformation cmdlet will be unable to resolve the autodiscover endpoint and the HCW will fail.

Solution: To resolve this issue, we have added a new method for checking for the federation information. We still try to use local DNS first and if it fails we then will try to hit an external service to see if we can get the federation information externally. This will ensure that if you have Autodiscover published properly externally the HCW will complete as expected. See figure 7 for details:

Figure 7: Get-FedInfo

OAuth Integration

Another common failure point is the OAuth portion of the HCW. The HCW today shows you an option to configure OAuth if you are Exchange 2013 native, but not if you coexist with previous versions of the Exchange. OAuth is required for some features today, such as cross premises discovery and automatic archive retention. Because of that, we want to ensure that OAuth is by default configured so all of the Hybrid features work when you complete the HCW.

One downside to this is that the current OAuth configuration experience previously had a high rate of failure. We have gone through and fixed a good portion of the experience and we have also added logic to the new HCW so that if the OAuth portion fails we will disable the OAUTH configuration by disabling the IntraOrganizationConnector and let you know we disabled it and give you remediation steps. This will ensure that a failed OAuth configuration does not prevent other hybrid features such as cross premises Free Busy from working.

Many more…

The above are just a few of the issues that have been addressed with the latest version of the HCW. There are many example that we could have used such as a couple of issues we addressed with mail flow, Multi-Forest deployments, and many more. In this latest version we strived for feature parity, while improvement the failure rate, and allowing for future innovation. We think we have hit the mark.

Running the HCW

Now that we have covered some of the new features and benefits of running the Microsoft Office 365 Exchange Hybrid Configuration Wizard, let’s take a guided tour. We are not going to go through each option in depth as most of them have not changed from Exchange 2013.

How to find the new HCW

We have not moved the location of the HCW in the Exchange Admin Center, the entry point look and feel is consistent with previous version of the Exchange 2013 HCW. The only difference is that instead of calling local code when you click “configure” or “modify” in the hybrid node of EAC, we now initiate the click once application. Figure 8 shows the entry point.

Figure 8: Entry Point

HCW Landing Page

The next screen you will see is the HCW landing page, which is a page that serves two purposes. The first and most important purpose is that we can redirect a small subset of customers (based on pre-defined criteria) to an alternate HCW experience. As discussed previously in this blog, this allows us to pilot new features without affecting the production HCW experience. The second benefit of this landing page is that it allows us to provide a proper error message if the browser version, popup blockers, etc. are not configured in a way that would support the HCW. When you are on the landing page you will select the “click here” option to download the HCW. See figure 9 for a view of the landing page.

Figure 9: Landing page

Welcome Screen

The Welcome screen (see figure 10) will provide you with a link that will inform you about what a Hybrid configuration is along with an additional link at the bottom that explains what the HCW application is going to do. The Second link is at the bottom-left of the screen and says What does this application do? On this screen you will simply click next to continue.

Figure 10: Welcome screen

Server Detection Page

The next screen allows you to choose which server you will use to perform your hybrid configuration. This is the machine that the HCW will remote PowerShell into in order to perform all of the hybrid configuration tasks.

The selected server must be running a version of Exchange that is within two releases of our currently released Cumulative update. This means at launch the new HCW will work if you are connecting to an Exchange 2013 CU8 or newer version of Exchange. However, when Exchange 2013 CU11 releases you will see that we will no longer allow you to run the new HCW from Exchange 2013 CU8 and will require a minimum of CU9. Keep in mind that even though the HCW will allow you to proceed if you are two versions older than the current release (n-2), we actually only support going one version back for Hybrid (n-1).

If for you were to select a server that is running an unsupported version, the HCW will provide you with an error stating that you are not running a supported version. In addition, the HCW will provide you with a list of servers that are running a supported version (if any exist).

Figure 11: Unsupported version

The HCW will try to select the best server to perform the configuration tasks from using the following logic:

1. First we look to see if the server we are on is running the latest supported version of Exchange in the organization.
2. Next we look to see if there is an existing Exchange server in the site running the latest supported version of Exchange.
3. Finally, we attempt to connect to an out of site Exchange server (typically in a different geographical location) running the latest supported version.

If you do not like the server selection the HCW made via the above mentioned detection logic you can manually specify the server name that you want to connect to. You can use the short name (ServerName) or the long name (ServerName.Contoso.com) in the provided box to select the appropriate server running the supported version of Exchange.

The last option on this page allows you to select the tenant location. For most the tenant location is simply “Microsoft Office 365” but if your Office 365 is operated by 21 Vianet, you can also use the “21 Vianet” option.

Figure 12: Server detection

Credentials page

The main improvement on this page is the fact that we do not force you to type in your on-premises credentials. However, if you are not signed in as the user with the Organization Management Role you can manually override this behavior and provide separate credentials.

Figure 13: Credentials page

Connection Status page

We will then show you the connection status window, which will let you know if improper credentials were provided on the previous step. Usually this is a pretty uneventful window and you just click next.

Figure 14: Connection status

Mail flow options page

The rest of the questions in the HCW from this page on are related to the mail flow options. The experience and windows you see from this point forward may vary depending on the options selected. For more information on the mail flow options you have please review this article.

Figure 15: Mail flow options

Receive and Send Connector Configuration

This page of the wizard allows you to select the Exchange 2013 and/or Exchange 2016 servers that you intend on configuring for sending and receiving mail for your on-premises environment. You can have a mix of 2013 and 2016 servers selected. We do not allow you to choose Exchange 2010 servers from these menus.

Figure 16: Receive Connector

Figure 17: Send Connector

Certificate selection page

We described the enhancements to this certificate selection page previously in the blog, we covered the experience you will get if a valid certificate cannot be found on any one of the Sending and Receiving servers selected on the previous page (figure 16 and figure 17). This certificate page is what you should expect to see when the certificates are installed properly on all servers. In this case you will get a list of certificates that are meeting all of the requirements and installed on all of the selected servers. In most cases the list includes only one certificate that meets the list of requirements.

Figure 18: Certificate

FQDN for Mail Flow

The final question in the wizard will allow the HCW to properly configure the smart host settings on the outbound connector in Exchange Online. You will usually provide the FQDN that matches your MX record in this window.

Figure 19: FQDN

Update page

Up to this point in the HCW there has been no modification made to your on-premises or Exchange Online environment. When you select the update option on this page we will start making the modification based on the answers to the questions you provided on the previous screen. Similar to the old version of the HCW we will store those answer in the local Active Directory in a configuration object known as your desired state. We will then read from that configuration object to make the modification.

Figure 20: Update

Wrapping this up

The Exchange hybrid configuration process is something that has evolved rapidly over the past few years. We have done a lot over that time to simplify these complex configurations. With this latest version we have continued that trend by adding flexibility for innovation, more HCW stability, better HCW performance, a cleaner configuration experience, and (if needed) a proper error experience. However, our tools and services are built for you so let us know what you think, when you try out the wizard send us feedback through the feedback widget in the HCW. Just look for the “give feedback” link on the bottom of the page in the wizard and please rate the experience.

The Exchange Hybrid Team

There’s been a fair amount of confusion amongst customers and partners lately about the right way to think about hyperthreading when virtualizing Exchange. Hopefully I can clear up that confusion very quickly.

We’ve had relatively strong guidance in recent versions of Exchange that hyperthreading should be disabled. This guidance is specific to physical server deployments, not virtualized deployments. The reasoning for strongly recommending that hyperthreading be disabled on physical deployments can really be summarized in 2 different points:

• The increase in logical processor count at the OS level due to enabling hyperthreading results in increased memory consumption (due to various algorithms that allocate memory heaps based on core count), and in some cases also results in increased CPU consumption or other scalability issues due to high thread counts and lock contention.
• The increased CPU throughput associated with hyperthreading is non-deterministic and difficult to measure, leading to capacity planning challenges.

The first point is really the largest concern, and in a virtual deployment, it is a non-issue with regard to configuration of hyperthreading. The guest VMs do not see the logical processors presented to the host, so they see no difference in processor count when hyperthreading is turned on or off. Where this concern can become an issue for guest VMs is in the number of virtual CPUs presented to the VM. Don’t allocate more virtual CPUs to your Exchange server VMs that are necessary based on sizing calculations. If you allocate extra virtual CPUs, you can run into the same class of issues associated with hyperthreading on physical deployments.

In summary:

• If you have a physical deployment, turn off hyperthreading.
• If you have a virtual deployment, you can enable hyperthreading (best to follow the recommendation of your hypervisor vendor), and:
  • Don’t allocate extra virtual CPUs to Exchange server guest VMs.
  • Don’t use the extra logical CPUs exposed to the host for sizing/capacity calculations (see the hyperthreading guidance at http://aka.ms/e2013sizing for further details on this).

Jeff Mealiffe
Principal PM Manager
Office 365 Customer Experience

The Exchange team is announcing today the availability of our latest quarterly update for Exchange Server 2013 and Exchange Server 2010 Service Pack 3 Update Rollup 11.

Cumulative Update 10 for Exchange Server 2013 and UM Language Packs are now available on the Microsoft Download Center. Cumulative Update 10 contains the latest set of fixes and builds upon Exchange Server 2013 Cumulative Update 9. The release includes fixes for customer reported issues, minor product enhancements and previously released security bulletins, including MS15-103. A complete list of customer reported issues resolved can be found in Knowledge Base Article KB3078678. Customers running any previous release of Exchange Server 2013 can move directly to Cumulative Update 10. Customers deploying Exchange Server 2013 for the first time may skip previous releases and start their deployment with Cumulative Update 10 directly.

Cumulative Update 10 does not include updates to Active Directory Schema, but does include additional RBAC definitions requiring PrepareAD to be executed prior to upgrading any servers to CU10. PrepareAD will run automatically during the first server upgrade if Setup detects this is required and the logged on user has sufficient permission.

Microsoft recommends all customers test the deployment of a cumulative update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate TechNet documentation.

Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings.

Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., CU10) or the prior (e.g., CU9) Cumulative Update release.

Also being released today is, Exchange Server 2010 Service Pack 3 Update Rollup 11 (KB3078674). This release provides an important fix for an Information Store crash when customers are upgrading their Lync server infrastructure to Skype for Business. Exchange Server 2010 is in extended support and will receive security and time zone fixes on-demand on a go-forward basis.

The updates released today are important pre-requisites for customers with existing Exchange deployments who will deploy Exchange Server 2016. Cumulative Update 10 is the minimum version of Exchange Server 2013 which will co-exist with Exchange Server 2016. Exchange Server 2010 Service Pack 3 Update Rollup 11, is the minimum version of Exchange Server 2010 which will be supported in a coexistence deployment with Exchange Server 2016. No earlier versions of Exchange will be supported co-existing with Exchange Server 2016. Exchange Server 2016 is anticipated to be released later this year. Customers who plan to deploy this new release of Exchange into their environment should be aware of these important prerequisites.

For the latest information and product announcements please read What’s New in Exchange Server 2013, Release Notes and product documentation available on TechNet.

Note: Documentation may not be fully available at the time this post was published.

The Exchange Team

The Exchange Public Folder team has been working on improving the Public Folder experience in OWA. Today we are announcing a new feature available in Exchange Server 2013 CU10, Exchange Server 2016, as well as Office 365 customers over the coming months.

OWA has long supported the ability to add Mail Public Folders (public folders that contain Mail and Post Items) into your Favorites collection from within OWA. In Exchange Server 2013 CU9, we added support for showing Public Folder Calendars and Public Contact Folders that have been added to your Favorites collection via Outlook. With Exchange Server 2013 CU10, and Exchange Server 2016, we are bringing you the ability to add those types of Public Folders to your Favorites collection within OWA directly.

In addition, we have redesigned the public folder picker to make it easier to navigate your organization’s public folder hierarchy, and select public folders to add to your favorites collection.

Opening the new public folder picker

Accessing the new public folder picker from the OWA Mail App is the same as accessing the existing one, you right-click on the “Folders” collection in the right, and select “Add public folder to Favorites”.

Opening the public folder picker from the OWA Mail App

New however, is the ability to open the public folder picker from the OWA Calendar App, and the OWA People App. To open the public folder picker from the OWA Calendar App, right-click on the “Other Calendars” section, and select the new “Add public folder to Favorites” option.

Opening the public folder picker from the OWA Calendar App

To open the public folder picker from the OWA People App, right-click on the “Other Contacts” section, and select the new “Add public folder to Favorites” option.

Opening the public folder picker from the OWA People App

Using the new Public Folder Picker

The new picker is larger, and has icons that allow you to identify which type of items are contained in the public folder.

The new public folder picker in OWA

Folders that can be added to your favorites collection are shown in bold, while folders that cannot be added (such as folders that contain Tasks or other item types) are greyed out.

After selecting any public folder, and clicking the “Add to Favorites” button, you will receive a confirmation message indicating that the folder was added to your collection successfully.

Example of adding a calendar folder to the Favorites collection.

It’s important to note that, when selecting a public folder and adding to favorites, it will be added to the favorites collection of the corresponding type. In other words, favorited Public Calendar Folders will appear in the “Other Calendars” section of the OWA Calendar App, and favorited Contact Public Folders will appear in the “Other Contacts” section of the OWA People App. This happens regardless of which App was open when you opened the new public folder picker.

Additionally, new favorited Public Folders added in OWA will show in your Outlook client as well.

Version Support

As of this writing, the new OWA Public Folder Picker, and associated menu options in OWA Calendar and OWA People apps, will only work when:

• Both the callers mailbox and the public folder mailboxes have been upgraded to Exchange 2013 CU10
• Both the callers mailbox and the public folder mailboxes have been upgraded to Exchange 2016.

There is a known issue where, even if the callers mailbox has been upgraded to Exchange 2016, and the public folder mailboxes have been upgraded to Exchange 2013 CU10, then the old picker will still show up. This is hopefully going to be addressed in an Exchange 2016 update.

Wrapping up

For organizations that have a large investment in Public Folders, we hope that you will find the new picker useful. We welcome your feedback.

Ben Spain

Exchange Server 2016 is here and available to download starting today! We’ve spent nearly three years iterating, polishing and refining Exchange since the release of Exchange 2013, and we are excited to put a shiny, new version of Exchange into your hands today. What sets this version of Exchange apart from the past, is that it was forged in the cloud. This release brings the Exchange bits that already power millions of Office 365 mailboxes to your on-premises environment.

Here is a quick video look at some of our favorite features.

Email remains the backbone of business communication and the one that workers consider the most essential tool for getting things done. Because of this, it’s vital to have a modern messaging infrastructure that meets today’s business expectations. With the volume of email and other communications continuing to grow, people need tools that help them focus on what’s most important in their inboxes, schedules and interactions with others at work. And as the quantity of email data grows, so do the demands on IT to manage, preserve and protect it.

To help you meet these challenges, we’ve deepened the integration between Exchange and other Office products, so your organization can be more productive and collaborate more effectively. We’ve made it easier to manage your email with new ways to focus on what’s important, work more efficiently, and accomplish more with your devices. We’ve simplified the Exchange architecture and introduced additional recovery features. We’ve also enhanced our built-in compliance tools for protecting and preserving data.

Exchange 2016 builds on and improves features introduced in Exchange 2013, including Data Loss Prevention, Managed Availability, automatic recovery from storage failures, and the web-based Exchange admin center. Here are a few of our favorite new capabilities:

• Better collaboration: Exchange 2016 includes a new approach to attachments that simplifies document sharing and eliminates version control headaches. In Outlook 2016 or Outlook on the web, you can now attach a document as a link to SharePoint 2016 (currently in preview) or OneDrive for Business instead of a traditional attachment, providing the benefits of coauthoring and version control.

• Improved Outlook web experience: Continuing our effort to provide you with a first class web experience across devices, we’ve made significant updates to Outlook on the web. New features include: Sweep, Pin, Undo, inline reply, a new single-line inbox view, improved HTML rendering, new themes, emojis, and more.

• Search: A lightning-fast search architecture delivers more accurate and complete results. Outlook 2016 is optimized to use the power of the Exchange 2016 back end to help you find things faster, across old mail and new. Search also gets more intelligent with Search suggestions, People suggestions, search refiners, and the ability to search for events in your Calendar.

• Greater extensibility:  An expanded Add-In model for Outlook desktop and Outlook on the web allows developers to build features right into the Outlook experience. Add-ins can now integrate with UI components in new ways: as highlighted text in the body of a message or meeting, in the right-hand task pane when composing or reading a message or meeting, and as a button or a dropdown option in the Outlook ribbon.

• eDiscovery: Exchange 2016 has a revamped eDiscovery pipeline that is significantly faster and more scalable. Reliability is improved due to a new search architecture that is asynchronous and distributes the work across multiple servers with better fault tolerance. You also have the ability to search, hold and export content from public folders.
• Simplified architecture: Exchange 2016’s architecture reflects the way we deploy Exchange in Office 365 and is an evolution and refinement of Exchange 2013. A combined mailbox and client access server role makes it easier to plan and scale your on-premises and hybrid deployments. Coexistence with Exchange 2013 is simplified, and namespace planning is easier.
• High availability: Automated repair improvements such as database divergence detection make Exchange easier than ever to run in a highly available way. Stability and performance enhancements from Office 365, many of which were so useful that we shipped them in Exchange 2013 Cumulative Updates, are also baked into the product.

That’s just quick list of highlights; we encourage you to get a full view of what’s new by reviewing the Exchange 2016 documentation on TechNet, and the Product Guide.  Or, if you are in the mood for something more bite-sized, check out these short demo videos in which a few members of the Exchange team show off their favorite features:

• Better Collaboration
• Outlook on the Go
• Architecture and Security/Compliance Improvements
• Smarter Inbox

Exchange 2016 will follow the same servicing rhythm as Exchange 2013, with Cumulative Updates (CUs) released approximately every three months that contain bug fixes, product refinements, and selected new investments from Office 365. The CUs will include features such as search indexing from passive that we decided needed additional refinement or validation before arriving on-premises. The first CU will arrive in the first quarter of 2016.

For those of you eager to get hands on with Exchange 2016, you can start right away by getting the bits from the Microsoft download center to evaluate the fully-functional product for 180 days. We know that you’re hungry for more in-depth info, so we’ll be publishing a series of deep dive blogs on Exchange 2016 here on the EHLO blog in the weeks ahead.

A big thanks to all those who participated in our Technology Adoption Program, downloaded the public Preview, and contributed feedback to help shape this release. One such participant was King Saud University; read about their experience with Exchange Server 2016.

Enjoy Exchange Server 2016!

Exchange Team

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 2010

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

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 seven namespaces, five 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 2016

One of the benefits of the Exchange 2016 architecture (first introduced in Exchange 2013) 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 2016, 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 2016 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, the Client Access services proxies requests to the Mailbox server hosting the active database copy.

Figure 1: Client Access services (on MBX Server 1) proxying traffic to the Mailbox server hosting the active database copy (on MBX Server 3)

This proxy logic is not limited to the Active Directory site boundary. Unlike Exchange 2010, Exchange 2016 does not require the client namespaces to move with the DAG during an activation event – a Mailbox server 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 Exchange 2016 Mailbox servers in both datacenters participate in handling traffic, as seen in the following diagram, where VIP (virtual IP address) is the load balanced IP address associated with the namespace:

Figure 2: 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.

Figure 3: Multiple Namespaces used across Site Resilient Datacenter Pair (Bound Model)

Autodiscover Namespace

Exchange 2016 takes advantage of the Autodiscover service for client profile configuration; so the autodiscover.contoso.com namespace remains in place.

Office Online Server Namespaces

The document collaboration features included in Outlook on the web require Office Online Server. In site resilient deployments, you want to deploy an Office Online Server farm in each datacenter that participates in the site resilient datacenter pair.This ensures that there is a local instance that can service the document collaboration requests for the local mailboxes and avoids cross-site proxy scenarios.

From a namespace perspective, this means that each datacenter in the site resilient datacenter pair requires a unique namespace for Office Online Server; in other words, the namespace model for Office Online Server is a bound model.The namespace model that is used by Office Online Server is mutually exclusive from the model used by Exchange, meaning that you can deploy Exchange using an unbound model, while utilizing a bound model for Office Online Server as seen in the following figure:

 
Figure 4: Office Online Server Namespaces (Bound Model) with an Exchange Unbound Model Namespace

As all the data serviced by Office Online Server is either stored in Exchange or SharePoint, during a datacenter outage, namespace manipulation steps are not required. For example, if we refer to the previous diagram – if the West datacenter fails, you don’t need to change the DNS record for the Office Online Server namespace in West and point it to the load balancer in East. This is due to the architecture of Exchange and Office Online Server. Any Exchange 2016 Mailbox server will always proxy the client’s request to the Mailbox server that hosts the user’s mailbox database. The Mailbox server hosting the user’s mailbox is responsible for generating the Office Online Server URL that is used by OWA. This URL is defined per-Mailbox server, thereby ensuring that any Office Online Server interactions are always local to the Mailbox server.

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 the Exchange 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 2016 does allow you to specify different namespaces for internal clients vs. external clients for all clients.

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 Namespace

The concept of regional namespaces has existed since OWA debuted in 1997. 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):

Figure 5: : Regional Namespaces coupled with Geo-DNS to Round-Robin between Datacenters within a Region

Namespaces and Active Directory Site Topologies

When planning your namespace architecture, it is important to understand that namespaces and authentication settings must be identical and/or consistent within an Active Directory site. For example, when Autodiscover generates a response to send to the client, it generates a list of internal URLs based on the virtual directory settings of the Mailbox servers located in the Active Directory where the mailbox is located. If you attempt to have multiple namespaces within a single Active Directory site, clients will be randomly directed to different namespaces. Likewise, setting different authentication settings within an Active Directory site will lead to different behaviors for the clients. In other words, you can only define different namespace and authentication settings between Active Directory sites, not within Active Directory sites.

Conclusion

Exchange 2016 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 and client connectivity, you will understand (hopefully) how to choose the best namespace model.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Recently reports of a new security vulnerability in OWA, a component of Microsoft Exchange Server, have been circulated throughout the internet. Microsoft considers the security of our products to be a top responsibility to our customers.

We have investigated these reports and believe that a properly deployed and secured Exchange Server is not susceptible to the attacks referenced in these posts. One of the reports in question skips over the important details of how an attacker might ‘gain a foothold into a highly strategic asset’ if a system is properly managed, secured, and up-to-date. The “attack” in question could only be initiated by an individual who had administrative access to a server’s file system and services, or who had permission to logon to an Exchange Server console with the rights to replace Exchange system files, and perform an Internet Information Server (IIS) reset.

Microsoft recommends that IT administrators use the latest products and services, in combination with industry best practices for IT management to avoid the condition outlined in these reports.

The Exchange Team

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.

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):

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.

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.

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.

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.

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:

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.

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.

Exchange Scenario Summary

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

Office Online Server Load Balancing

Exchange Server 2016 leverages Office Online Server to provide the rich document preview and editing capabilities for OWA. While this was a necessary change to ensure a homogenous experience across the Office Server suite, this does introduce additional complexity for environments that don’t have Office Online Server.

As discussed in the architecture and namespace planning articles, the Office Online Server infrastructure requires unique namespaces. The load balancer is configured to maintain layer 7 with session affinity (using cookie-based persistence) for each Office Online Server namespace, meaning SSL termination occurs and the load balancer knows the target URL.This ensures the client is always directed to the same Office Online Server while the user is utilizing the document collaboration capabilities within OWA.

Conclusion

Exchange 2016 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.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

What is this about

In both Exchange Server 2016 and Office 365, recovering a deleted Public Folder Mailbox presents the possibility for a recovered Secondary PF Mailbox to contain Public Folders that may no longer be resident on a newly-created Primary PF Mailbox.

Say what?

Public Folders reside in one or more Public Folder Mailboxes. The first Public Folder Mailbox is referred to as the “Primary” Public Folder Mailbox. All subsequent Public Folder Mailboxes are referred to as “Secondary” Public Folder Mailboxes. These Secondary PF Mailboxes retrieve Public Folder hierarchy updates from the Primary PF Mailbox. This process is referred to as Public Folder Hierarchy Sync. If you want to read up on related concepts, this might be a good place to start.

Public Folder Hierarchy Sync processes and reconciles any Public Folder creation, deletions, and modifications as performed by the users. Once Public Folder Hierarchy Sync completes, if there are any Public Folders on a Secondary mailbox that are not on the Primary, these are considered as “orphaned” Public Folders.

Example Scenario

Your friendly Office 365 Tenant Admin creates a Primary Public Folder Mailbox (let’s call it “PrimaryN1”) and a Secondary Public Folder Mailbox (we’ll name this one “SecondaryN1”). Being the wicked smart Admin that s/he is, they decide to host all the content on the Secondary Public Folder Mailbox, and let the Primary Public Folder Mailbox focus solely on mastering the PF hierarchy.

Next, when they initially created these Public Folders, they specified the target Public Folder Mailbox for this PF.

For example:

PS C:\pf> New-PublicFolder "Green Monster" -Mailbox SecondaryN1

In the example below, 10 Public Folders are being created on the SecondaryN1 Public Folder Mailbox:

PS C:\pf> 1..10 | %{New-PublicFolder -Name ("PublicFolder_{0:00}" -f $_) -Mailbox SecondaryN1}

Things are going smooth for some time, until they hire a new Admin (we’ll call him “Chuckie Sullivan”) who for whatever reason, decided to delete both of their Public Folder Mailboxes. Taking it a step further, he created a new Primary and named it “PrimaryN2.”

Once he realized the error of his ways, Chuckie recovered the former Secondary Public Folder Mailbox (SecondaryN1) to get the content back.

How do you recover a Public Folder Mailbox?

Undo-SoftDeletedMailbox -PublicFolder

In Office 365, when a Public Folder Mailbox is deleted, rather than permanently deleting it right away, PF mailboxes are now “Soft Deleted.” These soft deleted Public Folder mailboxes can be located using Get-Mailbox -PublicFolder -ShowSoftDeletedMailbox:

In Office 365, these Public Folder Mailboxes are now available for recovery using Undo-SoftDeletedMailbox -PublicFolder:

W00t! Now we have a Primary PF Mailbox (PrimaryN2), but it has no clue about all that glorious data that was recovered via Undo-SoftDeletedMailbox -PublicFolder. When Public Folder Hierarchy sync finds Public Folders that don’t exist on the Primary, it re-creates them under a special folder called “LOST_AND_FOUND.” This resides at the root of the NON_IPM_SUBTREE, so it is not shown to end users via Outlook Web App or Outlook.

Great. But how do we find these orphaned folders?

Get-PublicFolder -LostAndFound

In our example, the SecondaryN1 Public Folder Mailbox that was recovered contained 10 Public Folders (PublicFolder_01 – 10). Once Hierarchy Sync executed, it keenly noticed that these were not represented in the PF hierarchy on the Primary. Next, the PF hierarchy reconciliation process (initiated by the Public Folder Mailbox Assistant) created a new Folder on the Primary PF Mailbox under \NON_IPM_SUBTREE\LOST_AND_FOUND, and used the ExchangeGuid of the recovered mailbox as the name (e.g. 25e6e0a3-d601-403a-aca5-9144962ef54b). Finally, PF hierarchy reconciliation moved the formerly orphaned Public Folders (“PublicFolder_01-10”) from the recovered Secondary PF Mailbox to this new folder on the Primary:

PS C:\pf> Get-PublicFolder -LostAndFound | ft -a

For more information on the mechanics of Public Folder Hierarchy Sync, I encourage you to check out “The Latest on Modern Public Folders” as presented at Microsoft Ignite 2015 by Ladislau Conceicao, Brian Day, and Kanika Ramji. In the meantime, this simplified attempt at illustrating these concepts may help this scenario to be easier to understand.

There is a new property called LostAndFoundFolderOriginalPath that is added to each Public Folder to keep track of where the folder originated in the Public Folder hierarchy. Let’s say we wanted to find out where PublicFolder_02 originally lived:

This shows us that PublicFolder_02 originally lived at the root of the Public Folder hierarchy.

Now we can run Get-PublicFolder and Set-PublicFolder against these Public Folders like we normally would. For example, here is how to retrieve a Public Folder out of LOST_AND_FOUND and back into the regular Public Folder hierarchy for end users to use again:

Awwyeah! We have successfully rescued PublicFolder_02 from what would have previously been certain death for that Public Folder.

Here’s another example illustrating that the same steps are applicable for Subfolders of parent Public Folders. We have three Public Folders: "Fenway Park," "Right Field," and "Pesky Pole." The Public Folder hierarchy is illustrated below:

Fenway Park
     \Right Field
          \Pesky Pole

As seen from Powershell:

PS C:\pf> Get-PublicFolder

Name           Parent Path
----           -----------
Fenway Park           \
Right Field           \Fenway Park
Pesky Pole            \Fenway Park\Right Field

In this disaster recovery example, we have created a new Primary PF Mailbox, and recovered the former PF Mailbox which contained these Public Folders. As we can see with Get-PublicFolder -LostAndFound, here are the previously-orphaned Public Folders, now conveniently placed in the LOST_AND_FOUND Public Folder:

PS C:\pf> Get-PublicFolder -LostAndFound | ft -a

Name           Parent Path
----           -----------
Fenway Park           \NON_IPM_SUBTREE\LOST_AND_FOUND\5773ba6a-9926-4d64-97db-63a2bdd94a5b
Pesky Pole            \NON_IPM_SUBTREE\LOST_AND_FOUND\5773ba6a-9926-4d64-97db-63a2bdd94a5b
Right Field           \NON_IPM_SUBTREE\LOST_AND_FOUND\5773ba6a-9926-4d64-97db-63a2bdd94a5b

For sake of discussion, we only want to restore "Pesky Pole," so we'll re-create the top-level "Fenway Park," and its subfolder "Right Field."

PS C:\pf> New-PublicFolder "Fenway Park"
Name           Parent Path
----           -----------
Fenway Park           \

PS C:\pf> New-PublicFolder "Right Field" -Path "\Fenway Park"
Name           Parent Path
----           -----------
Right Field           \Fenway Park

Now let's put "Pesky Pole" back where it belongs: in Right Field.

PS C:\pf> Get-PublicFolder \NON_IPM_SUBTREE\LOST_AND_FOUND\5773ba6a-9926-4d64-97db-63a2bdd94a5b\"Pesky Pole" | Set-PublicFolder -Path "\Fenway Park\Right Field"

PS C:\pf> Get-PublicFolder “Fenway Park” -Recurse
Name           Parent Path
----           -----------
Fenway Park           \
Right Field           \Fenway Park
Pesky Pole            \Fenway Park\Right Field

Play ball!

Availability

Undo-SoftDeletedMailbox -PublicFolder is available to Office 365 customers only, as the Soft Deleted Objects functionality does not exist in our On-Premises Exchange Server offerings.

Get-PublicFolder -LostAndFound are available to our Office 365 customers and to our Exchange On-Premises customers in a forthcoming Cumulative Update for Exchange 2013 and Exchange 2016.

So, to recap…

Undo-SoftDeletedMailbox -PublicFolder allows Office 365 Tenant Administrators to recover deleted Public Folder Mailboxes. Note that if you are Exchange 2013 or Exchange 2016 On-Premises Administrator, you would recover a deleted Public Folder Mailbox using our published guidance.

Get-PublicFolder -LostAndFound allows both Office 365 Tenant Administrators as well as Exchange 2016 On-Premises Administrators the ability to locate any Public Folders that would have previously been orphaned (and lost!).

Finally, to avoid the need to use this functionality altogether, don’t delete Public Folder Mailboxes unless absolutely necessary. Yet should you need to recover, make sure you recover the Primary PF Mailbox first. Otherwise, recovering any Secondary PF Mailboxes “out of order” (e.g. before recovering the Primary PF Mailbox) will require you to utilize Get-PublicFolders -LostAndFound to locate any missing Public Folders.

Scott Oseychik

The Preferred Architecture (PA) is the Exchange Engineering Team’s best practice recommendation for what we believe is the optimum deployment architecture for Exchange 2016, and one that is very similar to what we deploy in Office 365.

While Exchange 2016 offers a wide variety of architectural choices for on-premises deployments, the architecture discussed below is our most scrutinized one ever. While there are other supported deployment architectures, they are not recommended.

The PA is designed with several business requirements in mind, such as the requirement that the architecture be able to:

• Include both high availability within the datacenter, and site resilience between datacenters
• Support multiple copies of each database, thereby allowing for quick activation
• Reduce the cost of the messaging infrastructure
• Increase availability by optimizing around failure domains and reducing complexity

The specific prescriptive nature of the PA means of course that not every customer will be able to deploy it (for example, customers without multiple datacenters). And some of our customers have different business requirements or other needs which necessitate a different architecture. If you fall into those categories, and you want to deploy Exchange on-premises, there are still advantages to adhering as closely as possible to the PA, and deviate only where your requirements widely differ. Alternatively, you can consider Office 365 where you can take advantage of the PA without having to deploy or manage servers.

The PA removes complexity and redundancy where necessary to drive the architecture to a predictable recovery model: when a failure occurs, another copy of the affected database is activated.

The PA is divided into four areas of focus:

1. Namespace design
2. Datacenter design
3. Server design
4. DAG design

Namespace Design

In the Namespace Planning and Load Balancing Principles articles, I outlined the various configuration choices that are available with Exchange 2016. For the namespace, the choices are to either deploy a bound namespace (having a preference for the users to operate out of a specific datacenter) or an unbound namespace (having the users connect to any datacenter without preference).

The recommended approach is to utilize the unbounded model, deploying a single Exchange namespace per client protocol for the site resilient datacenter pair (where each datacenter is assumed to represent its own Active Directory site - see more details on that below). For example:

• autodiscover.contoso.com
• For HTTP clients: mail.contoso.com
• For IMAP clients: imap.contoso.com
• For SMTP clients: smtp.contoso.com

Each Exchange namespace is load balanced across both datacenters in a layer 7 configuration that does not leverage session affinity, resulting in fifty percent of traffic being proxied between datacenters. Traffic is equally distributed across the datacenters in the site resilient pair, via round robin DNS, geo-DNS, or other similar solutions. From our perspective, the simpler solution is the least complex and easier to manage, so our recommendation is to leverage round robin DNS.

For the Office Online Server farm, a namespace is deployed per datacenter, with the load balancer utilizing layer 7, maintaining session affinity using cookie based persistence.

Figure 1: Namespace Design in the Preferred Architecture

In the event that you have multiple site resilient datacenter pairs in your environment, you will need to decide if you want to have a single worldwide namespace, or if you want to control the traffic to each specific datacenter by using regional namespaces. Ultimately your decision depends on your network topology and the associated cost with using an unbound model; for example, if you have datacenters located in North America and Europe, the network link between these regions might not only be costly, but it might also have high latency, which can introduce user pain and operational issues. In that case, it makes sense to deploy a bound model with a separate namespace for each region. However, options like geographical DNS offer you the ability to deploy a single unified namespace, even when you have costly network links; geo-DNS allows you to have your users directed to the closest datacenter based on their client’s IP address.

Figure 2: Geo-distributed Unbound Namespace

Site Resilient Datacenter Pair Design

To achieve a highly available and site resilient architecture, you must have two or more datacenters that are well-connected (ideally, you want a low round-trip network latency, otherwise replication and the client experience are adversely affected). In addition, the datacenters should be connected via redundant network paths supplied by different operating carriers.

While we support stretching an Active Directory site across multiple datacenters, for the PA we recommend that each datacenter be its own Active Directory site. There are two reasons:

1. Transport site resilience via Shadow Redundancy and Safety Net can only be achieved when the DAG has members located in more than one Active Directory site.
2. Active Directory has published guidance that states that subnets should be placed in different Active Directory sites when the round trip latency is greater than 10ms between the subnets.

Server Design

In the PA, all servers are physical servers. Physical hardware is deployed rather than virtualized hardware for two reasons:

1. The servers are scaled to use 80% of resources during the worst-failure mode.
2. Virtualization adds an additional layer of management and complexity, which introduces additional recovery modes that do not add value, particularly since Exchange provides that functionality.

Commodity server platforms are used in the PA. Commodity platforms are and include:

• 2U, dual socket servers (20-24 cores)
• up to 96GB of memory
• a battery-backed write cache controller
• 12 or more large form factor drive bays within the server chassis

Additional drive bays can be deployed per-server depending on the number of mailboxes, mailbox size, and the server’s scalability.

Each server houses a single RAID1 disk pair for the operating system, Exchange binaries, protocol/client logs, and transport database. The rest of the storage is configured as JBOD, using large capacity 7.2K RPM serially attached SCSI (SAS) disks (while SATA disks are also available, the SAS equivalent provides better IO and a lower annualized failure rate).

Each disk that houses an Exchange database is formatted with ReFS (with the integrity feature disabled) and the DAG is configured such that AutoReseed formats the disks with ReFS:

Set-DatabaseAvailabilityGroup <DAG> -FileSystem ReFS

BitLocker is used to encrypt each disk, thereby providing data encryption at rest and mitigating concerns around data theft or disk replacement.

To ensure that the capacity and IO of each disk is used as efficiently as possible, four database copies are deployed per-disk. The normal run-time copy layout ensures that there is no more than a single active copy per disk.

At least one disk in the disk pool is reserved as a hot spare. AutoReseed is enabled and quickly restores database redundancy after a disk failure by activating the hot spare and initiating database copy reseeds.

Database Availability Group Design

Within each site resilient datacenter pair you will have one or more DAGs.

DAG Configuration

As with the namespace model, each DAG within the site resilient datacenter pair operates in an unbound model with active copies distributed equally across all servers in the DAG. This model:

1. Ensures that each DAG member’s full stack of services (client connectivity, replication pipeline, transport, etc.) is being validated during normal operations.
2. Distributes the load across as many servers as possible during a failure scenario, thereby only incrementally increasing resource use across the remaining members within the DAG.

Each datacenter is symmetrical, with an equal number of DAG members in each datacenter. This means that each DAG has an even number of servers and uses a witness server for quorum maintenance.

The DAG is the fundamental building block in Exchange 2016. With respect to DAG size, a larger DAG provides more redundancy and resources. Within the PA, the goal is to deploy larger DAGs (typically starting out with an eight member DAG and increasing the number of servers as required to meet your requirements). You should only create new DAGs when scalability introduces concerns over the existing database copy layout.

DAG Network Design

The PA leverages a single, non-teamed network interface for both client connectivity and data replication. A single network interface is all that is needed because ultimately our goal is to achieve a standard recovery model regardless of the failure - whether a server failure occurs or a network failure occurs, the result is the same: a database copy is activated on another server within the DAG. This architectural change simplifies the network stack, and obviates the need to manually eliminate heartbeat cross-talk.

Witness Server Placement

Ultimately, the placement of the witness server determines whether the architecture can provide automatic datacenter failover capabilities or whether it will require a manual activation to enable service in the event of a site failure.

If your organization has a third location with a network infrastructure that is isolated from network failures that affect the site resilient datacenter pair in which the DAG is deployed, then the recommendation is to deploy the DAG’s witness server in that third location. This configuration gives the DAG the ability to automatically failover databases to the other datacenter in response to a datacenter-level failure event, regardless of which datacenter has the outage.

If your organization does not have a third location, consider placing the witness in Azure; alternatively, place the witness server in one of the datacenters within the site resilient datacenter pair. If you have multiple DAGs within the site resilient datacenter pair, then place the witness server for all DAGs in the same datacenter (typically the datacenter where the majority of the users are physically located). Also, make sure the Primary Active Manager (PAM) for each DAG is also located in the same datacenter.

Data Resiliency

Data resiliency is achieved by deploying multiple database copies. In the PA, database copies are distributed across the site resilient datacenter pair, thereby ensuring that mailbox data is protected from software, hardware and even datacenter failures.

Each database has four copies, with two copies in each datacenter, which means at a minimum, the PA requires four servers. Out of these four copies, three of them are configured as highly available. The fourth copy (the copy with the highest Activation Preference number) is configured as a lagged database copy. Due to the server design, each copy of a database is isolated from its other copies, thereby reducing failure domains and increasing the overall availability of the solution as discussed in DAG: Beyond the “A”.

The purpose of the lagged database copy is to provide a recovery mechanism for the rare event of system-wide, catastrophic logical corruption. It is not intended for individual mailbox recovery or mailbox item recovery.

The lagged database copy is configured with a seven day ReplayLagTime. In addition, the Replay Lag Manager is also enabled to provide dynamic log file play down for lagged copies when availability is compromised.

By using the lagged database copy in this manner, it is important to understand that the lagged database copy is not a guaranteed point-in-time backup. The lagged database copy will have an availability threshold, typically around 90%, due to periods where the disk containing a lagged copy is lost due to disk failure, the lagged copy becoming an HA copy (due to automatic play down), as well as, the periods where the lagged database copy is re-building the replay queue.

To protect against accidental (or malicious) item deletion, Single Item Recovery or In-Place Hold technologies are used, and the Deleted Item Retention window is set to a value that meets or exceeds any defined item-level recovery SLA.

With all of these technologies in play, traditional backups are unnecessary; as a result, the PA leverages Exchange Native Data Protection.

Office Online Server Design

At a minimum, you will want to deploy two Office Online Servers in each datacenter that hosts Exchange 2016 servers. Each Office Online Server should have 8 processor cores, 32GB of memory and at least 40GB of space dedicated for log files.

Note: The Office Online Server infrastructure does not need to be exclusive to Exchange. As such, the hardware guidance takes into account usage by SharePoint and Skype for Business. Be sure to work with any other teams using the Office Online Server infrastructure to ensure the servers are adequately sized for your specific deployment.

The Exchange servers within a particular datacenter are configured to use the local Office Online Server farm via the following cmdlet:

Set-MailboxServer <East MBX Server> –WACDiscoveryEndPoint https://oos-east.contoso.com/hosting/discovery

Summary

Exchange Server 2016 continues in the investments introduced in previous versions of Exchange by reducing the server role architecture complexity, aligning with the Preferred Architecture and Office 365 design principles, and improving coexistence with Exchange Server 2013.

These changes simplify your Exchange deployment, without decreasing the availability or the resiliency of the deployment. And in some scenarios, when compared to previous generations, the PA increases availability and resiliency of your deployment.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

v7.8 of the calculator introduces support for Exchange 2016! Yes, that’s right, you don’t need a separate calculator, v7.8 and later supports Exchange 2013 or Exchange 2016 deployments. Moving forward, the calculator is branded as the Exchange Server Role Requirements Calculator.

When you open the calculator you will find a new drop-down option in the Input tab that allows you to select the deployment version. Simply choose 2013 or 2016:

When you choose 2016, you will notice the Server Multi-Role Configuration option is disabled due to the fact that Exchange 2016 no longer provides the Client Access Server role.

As discussed in the Exchange 2016 Architecture and Preferred Architecture articles, the volume format best practice recommendation for Exchange data volumes has changed in Exchange 2016 as we now recommend ReFS (with the integrity feature disabled). By default, for Exchange 2016 deployments, the calculator scripts will default to ReFS (Exchange 2013 deployments will default to NTFS). This is exposed in the Export Mount Points File dialog:

The DiskPart.ps1 and CreateDag.ps1 scripts have been updated to support formatting the volume as ReFS (and disabling the integrity feature at the volume level) and enabling AutoReseed support for ReFS.

This release also improves the inputs of all dialogs for the distribution scripts by persisting values across the various dialogs (e.g., global catalog values).

For all the other improvements and bug fixes, please review the Release Notes, or download the update directly.

As always we welcome feedback and please report any issues you may encounter while using the calculator by emailing strgcalc AT microsoft DOT com.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Uh oh. You are probably thinking to yourself, here comes another one of those incredibly long blog posts about sizing. Thankfully, it’s not. If you want to fully understand the sizing process for Exchange 2016, you are certainly welcome to read the previous post that I did for Exchange 2013, as the overall process is effectively the same with one major caveat. Since we have eliminated the CAS role in Exchange 2016, you must follow the process for multi-role deployment sizing.

Overall, the inputs to our sizing formulas stay the same from Exchange 2013 to Exchange 2016. This means that our IOPS requirements, memory requirements, and all of the other values provided in the Exchange 2013 sizing guidance should continue to be used for Exchange 2016. We are changing one set of inputs, however.

Processor requirements

We are slightly increasing the processor requirements for Exchange 2016 (compared to Exchange 2013) as this is a very new release, and we are still learning how it performs in production. This slight increase in CPU provides some additional headroom for unanticipated issues, and may be changed in the future as we learn more from our internal deployments as well as customer feedback. The same SPECint_rate2006 baseline value described in the Exchange 2013 guidance should continue to be used (33.75 per-core).

These changes are reflected in v7.8 and later in the calculator.

System scalability

The previously released guidance on maximum recommended cores and maximum memory size for Exchange 2013 also applies to Exchange 2016. As we continue to evolve the hardware platform that we use for Exchange Online, we will update this guidance, but for now you should be planning deployments around these existing recommendations.

Summary

If you are at all familiar with the process for sizing the last couple of Exchange releases, you will be very comfortable with Exchange 2016. As with any new release, you should plan to roll-out in stages and monitor the health and performance of the solution carefully. We do expect that our performance and scalability guidance for Exchange 2016 will evolve over the lifespan of the product so watch the Exchange team blog for future updates.

Jeff Mealiffe
Principal PM Manager
Office 365 Customer Experience

The Exchange Preferred Architecture, for both Exchange Server 2013 and Exchange Server 2016, recommends enabling BitLocker on fixed data drives that store Exchange database files. Over the years, there have been a number of questions regarding how BitLocker should be enabled on servers.

However, before we discuss that, I think it is important to provide an overview of BitLocker, as I have found not many are familiar with the technology.

What is BitLocker?

BitLocker is the built-in Microsoft Windows solution for volume encryption that provides enhanced protection against data theft in form of stolen or lost computers or hard disks.

BitLocker was first introduced in Windows Vista and Windows Server 2008. Since the initial release, there have been several improvements made to BitLocker including, encrypting data volumes, encrypting only used disk space, and provisioning flexibility.

By default, BitLocker uses the AES encryption algorithm in cipher block chaining (CBC) mode with a 128-bit (default) or 256-bit key.

For more information, see the BitLocker Overview on Microsoft TechNet.

How can BitLocker be deployed?

There are multiple ways you can deploy BitLocker on Exchange servers.

1. Encrypt the operating system volume, as well as, the Exchange data volumes utilizing either network unlock, the Data Recovery Agent and PKI infrastructure, or via TPM (recommended approach).
2. Encrypt the Exchange data volumes only.

To use BitLocker in a FIPS-compliant manner, keep in mind:

• Trusted Platform Module (TPM) 1.2 is not FIPS-compliant and uses SHA1. You need to use a TPM 2.0 for FIPS compliance.
• To leverage the Network unlock feature, you need to take into account the core requirements.
• Microsoft BitLocker Administration and Monitoring (MBAM) cannot be used to manage BitLocker on server operating systems.
• If you are not using Windows Server 2012 R2 or later as the base operating system, then you cannot use recovery passwords for BitLocker. For more information, see What's New in BitLocker and KB 947249.

Volume Encryption Method

There are two methods for volume encryption:

1. Encrypt the entire volume. Use this option when you need to encrypt volumes that already contain existing messaging data. With a 3TB disk, it takes more than 8 hours to encrypt the entire disk.
2. Encrypt only the used space. Use this for new deployments or for new disks where the volumes have no existing data.

Be sure to place the servers in maintenance mode to prevent impact to end users prior to beginning the encryption of an entire volume. You can expect major performance degradation (~90% CPU utilization) and limited free OS volume space (less than ~2GB) while the volume is being encrypted. Also, be sure to deploy BitLocker one server at a time within a DAG to preserve availability.

OS Volume and Exchange Data Volume Encryption Scenario

BitLocker provides the most protection when used with a TPM. The TPM is a hardware component installed in the server and we recommend a TPM 2.0 chip. It works with BitLocker to help protect user data and to ensure that a server has not been tampered with while the system was offline.

Specifically, BitLocker can use a TPM to verify the integrity of early boot components and boot configuration data. This helps ensure that BitLocker makes the encrypted drive accessible only if those components have not been tampered with and the encrypted drive is located in the original server.

BitLocker helps ensure the integrity of the startup process by taking the following actions:

• Checks that the early boot file integrity has been maintained, and helps ensure that there has been no malicious modification of those files, such as with boot sector viruses or rootkits.
• Enhances protection to mitigate offline software-based attacks. Any alternative software that might start the system does not have access to the decryption keys for the Windows operating system drive.
• Locks the system when it is tampered with. If any monitored files have been modified, the system does not start. This alerts the administrator to the tampering, because the system fails to start as usual. In the event that system lockout occurs, follow the BitLocker recovery process which includes unlocking the system with a password or a USB key.

Important: A TPM can only be used in a physical server deployment. Virtualized servers are not capable of using a TPM. If you encrypt the guest operating system volume, a password or USB key must be used to allow the guest operating system to boot.

Setting up the Environment

The steps below assume the Exchange Server operating system is Windows Server 2012 R2 or later.

Important: When enabling BitLocker on existing Exchange servers, it is important to place the servers in maintenance mode to prevent the encryption process from affecting the end user experience.

1. Create an Organizational Unit to contain the Exchange servers, if one does not already exist.
   1. Open PowerShell with the appropriate Active Directory permissions.
   2. Execute New-ADOrganizationalUnit "Exchange Servers" -path "dc=contoso,dc=com".
   3. Execute $ExchangeOU = Get-ADOrganizationalUnit -Filter ‘Name -like "Exchange Servers"’.
   4. Execute Get-ADComputer "Exchange Server" | Move-ADObject -TargetPath $ExchangeOU.DistinguishedName.
2. Create group policy object and link it to the Exchange Servers OU.
   1. Open PowerShell with the appropriate Active Directory permissions.
   2. Execute Import-Module grouppolicy (requires RSAT tools to be installed).
   3. Execute New-GPO -Name "Exchange Server BitLocker Policy" -Domain contoso.com
   4. Execute New-GPLink -Name"Exchange Server BitLocker Policy" -Enforced "yes" -Target $ExchangeOU.DistinguishedName
3. Install the BitLocker module on the Exchange servers.
   1. Open PowerShell with local administrative privileges.
   2. Execute Install-WindowsFeature BitLocker -Restart.
   3. Reboot the server.
4. Enable TPM on the Exchange servers.
   1. Refer to your hardware vendor’s BIOS manual for details on how to enable/activate the TPM.
   2. Verify the TPM state by using the Trusted Platform Module Management tool (tpm.msc).
5. Allow TPM Recovery Information to be stored in Active Directory.
   1. Open the Exchange Management Shell with an account that has the necessary permissions in Active Directory to apply access control entries.
   2. Execute Add-ADPermission $ExchangeOU.DistinguishedName -User "NT AUTHORITY\SELF" -AccessRights ReadProperty,WriteProperty -Properties msTPM-OwnerInformation,msTPM-TpmInformationForComputer -InheritedObjectType Computer -InheritanceType Descendents.
6. Configure the Bitlocker GPO settings.
   1. Open the Group Policy Management Console (gpmc.msc).
   2. Navigate the hierarchy to the Exchange Servers OU.
   3. Right-click the Exchange Server BitLocker Policy and select Edit.
   4. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, and open BitLocker Drive Encryption.
      1. In the right pane, double-click Choose drive encryption method and cipher strength. Select the Enabled option. If you want to use AES 256-bit encryption, select it and click OK.

   5. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, open BitLocker Drive Encryption, and finally, open Operating System Drives.
      1. In the right pane, double-click Require additional authentication at startup. Select the Enabled option. If you want to disable or change any of the authentication methods, do so and click OK.

      2. In the right pane, double-click Choose how BitLocker-protected operating system drives can be recovered. Select the Enabled option. Select the Do not enable BitLocker until recovery information is stored to AD DS for operating system drives option. Click OK.

      3. In the right pane, double-click Enforce drive encryption type on operating system drives. Select the Enabled option. Select the Used Space Only encryption option for the encryption type. Click OK.

   6. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, open BitLocker Drive Encryption, and finally, open Fixed Data Drives
      1. In the right pane, double-click Choose how BitLocker-protected fixed drives can be recovered. Select the Enabled option. Select the Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives option. Click OK.

      2. In the right pane, double-click Enforce drive encryption type on fixed drives. Select the Enabled option. Select the Used Space Only encryption option for the encryption type. Click OK.

   7. Open Computer Configuration, open Policies, open Administrative Templates, open System, and open Trusted Platform Module Services.
      1. In the right pane, double-click Turn on TPM backup to Active Directory Domain Services. Select the Enabled option. Click OK.

7. Ensure the group policy is applied to the Exchange servers.
   1. Execute $Servers = Get-AdComputer -SearchBase $ExchangeOU.DistinguishedName -Filter.
   2. Execute Foreach ($Server in $Servers) {invoke-gpupdate -Computer $Servers.Name -Force -Target Computer}.
8. Enable OS encryption.
   1. Create a recovery key: manage-bde -protectors -add -RecoveryPassword C:
   2. Execute the following against the operating system drive: manage-bde -on C: –usedspaceonly
9. Enable data volume encryption (C:\ExchangeVolumes\ExVol1 defines the mount point for an Exchange data volume, replace as appropriate).
   1. Create a recovery key: manage-bde -protectors -add -RecoveryPassword "C:\ExchangeVolumes\ExVol1"
   2. Execute the following for each Exchange database volume: manage-bde -on "C:\ExchangeVolumes\ExVol1" –usedspaceonly
   3. Execute the following for each Exchange database volume to enable automatic unlock: Enable-BitLockerAutoUnlock -MountPoint "C:\ExchangeVolumes\ExVol1"

   Note: Bad disk sectors can result in BitLocker volume encryption failure. For more information, please see Event ID 24588.

Exchange Data Volume Encryption Scenario

In the situation where a TPM cannot be used (e.g., the server does not have a TPM, or it is virtualized), encrypting the OS volume requires the use of a password or USB key to allow the operating system to boot. As that can be detrimental for a service like Exchange, you could choose not to encrypt the OS volume. Instead, you only encrypt the fixed data volumes. Since the OS volume is not encrypted, the operating system cannot automatically unlock the encrypted volumes on boot. Therefore, one of two things must happen:

1. An administrator manually enters the recovery key and unlocks each drive after OS boot.
2. A scheduled task is invoked to unlock the encrypted volumes during OS boot.

The following steps outline how to setup the scheduled task and assume the Exchange Server operating system is Windows Server 2012 R2 or later.

Important: When enabling BitLocker on existing Exchange servers, it is important to place the servers in maintenance mode to prevent the encryption process from affecting the end user experience.

1. Create an Organizational Unit to contain the Exchange servers, if one does not already exist.
   1. Open PowerShell with the appropriate Active Directory permissions.
   2. Execute New-ADOrganizationalUnit "Exchange Servers" -path "dc=contoso,dc=com".
   3. Execute $ExchangeOU = Get-ADOrganizationalUnit "Exchange Servers".
   4. Execute Get-ADComputer "Exchange Server" | Move-ADObject -TargetPath $ExchangeOU.DistinguishedName.
2. Create group policy object and link it to the Exchange Servers OU.
   1. Open PowerShell with the appropriate Active Directory permissions.
   2. Execute Import-Module grouppolicy (requires RSAT tools to be installed).
   3. Execute New-GPO -Name "Exchange Server BitLocker Policy" -Domain contoso.com
   4. Execute New-GPLink -Name"Exchange Server BitLocker Policy" -Enforced "yes" -Target $ExchangeOU.DistinguishedName
3. Create BitLocker scheduled task service account (_bitlockersvc).
   1. Create a service account following your organization’s policy.
4. Create security group for BitLocker management, placing the security group in a protected container.
   1. Open PowerShell with the appropriate Active Directory permissions.
   2. Execute New-ADGroup -name "Exchange BitLocker Management" -groupscope Universal -path "cn=users,dc=coe,dc=local".
   3. Execute Add-ADGroupMember "Exchange BitLocker Management" -members "_bitlockersvc", "Organization Management".
5. Install the BitLocker module on the Exchange servers.
   1. Open PowerShell with local administrative privileges.
   2. Execute Install-WindowsFeature BitLocker.
   3. Reboot the server.
6. Add BitLocker security management group to local administrators group on the Exchange servers.
7. Grant the BitLocker security management group permissions to access the msFVE-RecoveryPassword AD object. This allows the accounts to access the recovery password.
   1. Open an elevated PowerShell session with Domain Administrator permissions.
   2. Execute $ExchangeOU = Get-OrganizationalUnit "Exchange Servers".
   3. Execute DSACLS $ExchangeOu.DistinguishedName /I:T /G "contoso\Exchange BitLocker Management:CA;msFVE-RecoveryPassword".
8. Configure the BitLocker GPO settings.
   1. Open the Group Policy Management Console (gpmc.msc).
   2. Navigate the hierarchy to the Exchange Servers OU.
   3. Right-click the Exchange Server BitLocker Policy and select Edit.
   4. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, and open BitLocker Drive Encryption.
      1. In the right pane, double-click Choose drive encryption method and cipher strength. Select the Enabled option. If you want to use AED 256-bit encryption, select it and click OK.
   5. Open Computer Configuration, open Policies, open Administrative Templates, open Windows Components, open BitLocker Drive Encryption, and finally, open Fixed Data Drives.
      1. In the right pane, double-click Choose how BitLocker-protected fixed drives can be recovered. Select the Enabled option. Select the Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives option. Click OK.
      2. In the right pane, double-click Enforce drive encryption type on fixed drives. Select the Enabled option. Select the Used Space Only encryption option for the encryption type. Click OK.
   6. Open Computer Configuration, open Policies, open Administrative Templates, open System, and open Trusted Platform Module Services.
      1. In the right pane, double-click Turn on TPM backup to Active Directory Domain Services. Select the Enabled option. Click OK.
9. Ensure the group policy is applied to the Exchange servers.
   1. Execute $Servers = Get-AdComputer -SearchBase $ExchangeOU.DistinguishedName -Filter.
   2. Execute Foreach ($Server in $Servers) {invoke-gpupdate -Computer $Servers.Name -Force -Target Computer}.
10. Enable data volume encryption (C:\ExchangeVolumes\ExVol1 defines the mount point for an Exchange data volume, replace as appropriate).
    1. Execute the following against each Exchange database volume: Manage-bde -on "C:\ExchangeVolumes\ExVol1" -rp -usedspaceonly.

       Note: Bad disk sectors can result in BitLocker volume encryption failure. For more information, please see Event ID 24588.

11. Validate recovery keys are stored in Active Directory.
    1. Download the BitLocker Drive Encryption Configuration Guide: Backing Up BitLocker and TPM Recovery Information to Active Directory.
    2. Execute Get-BitLockerRecoveryInfo.vbs.
    3. If script does not return any data, backup the recovery keys by downloading and executing BDEAdBackup.vbs.
12. Create the script that unlocks the volumes when the operating system boots.
    1. Save the below file to your script directory (e.g., c:\bitlocker).

       UnlockDrives.ps1
       $computer = Get-ADComputer $env:computername
       $RecoveryInformations = get-ADObject -ldapfilter "(msFVE-Recoverypassword=*)" -Searchbase $computer.distinguishedname -properties *
       $vols = gwmi win32_encryptablevolume -Namespace "Root\CIMV2\Security\MicrosoftVolumeEncryption"
       $lockedvols = $vols | ? {$_.GetLockStatus().LockStatus -eq 1}
       $vols[0].GetKeyProtectors().VolumeKeyProtectorID
       foreach($lockedvol in $lockedvols)
       {
       $RecoveryInformations | % {$lockedvol.UnlockWithNumericalPassword($_."msFVE-RecoveryPassword")}
       }

       Note: This is a basic script to get you started. You may need to extend the duties of this script to ensure that Microsoft Exchange Diagnostics, Microsoft Exchange Health Manager, and Microsoft Exchange Service Host services are restarted in the event they fail to start while the above script unlocks the data volumes.

13. Create the scheduled task to run at system start and unlock the volumes, replacing the bold items.
    1. Save the below file to your script directory.
    2. Execute schtasks /create /s $env:computername /ru contoso\_svcexbitlocker /rp <Password> /XML c:\Bitlocker\UnlockDrivesAtStart.xml /TN UnlockDrivesAtStart.

       <?xml version="1.0" encoding="UTF-16"?>
       <Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
       <RegistrationInfo>
       <Date>2015-04-16T12:07:14.9465954</Date>
       <Author>contoso\exadmin</</Author>
       <Description>Script unlocks Exchange data drives at OS startup</Description>
       </RegistrationInfo>
       <Triggers>
       <BootTrigger>
       <Enabled>true</Enabled>
       </BootTrigger>
       </Triggers>
       <Principals>
       <Principal id="Author">
       <UserId>contoso\_bitlockersvc</UserId>
       <LogonType>Password</LogonType>
       <RunLevel>HighestAvailable</RunLevel>
       </Principal>
       </Principals>
       <Settings>
       <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
       <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
       <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
       <AllowHardTerminate>true</AllowHardTerminate>
       <StartWhenAvailable>false</StartWhenAvailable>
       <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
       <IdleSettings>
       <StopOnIdleEnd>true</StopOnIdleEnd>
       <RestartOnIdle>false</RestartOnIdle>
       </IdleSettings>
       <AllowStartOnDemand>true</AllowStartOnDemand>
       <Enabled>true</Enabled>
       <Hidden>false</Hidden>
       <RunOnlyIfIdle>false</RunOnlyIfIdle>
       <WakeToRun>false</WakeToRun>
       <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
       <Priority>7</Priority>
       </Settings>
       <Actions Context="Author">
       <Exec>
       <Command>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Command>
       <Arguments>-Command .\UnlockDrives.ps1</Arguments>
       <WorkingDirectory>DIRECTORY_FOR_UNLOCKDRIVES.PS1</WorkingDirectory>
       </Exec>
       </Actions>
       </Task>

System Changes

It’s important to remember that any of the following system changes can cause an integrity check failure and prevent the TPM from releasing the BitLocker key to decrypt the protected volumes:

• Moving the BitLocker-protected drive into a new computer.
• Installing a new motherboard with a new TPM.
• Turning off, disabling, or clearing the TPM.
• Changing any boot configuration settings.
• Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early boot components or boot configuration data.
• Applying BIOS/UEFI firmware updates.

As part of your standard operating procedure, it is best to suspend BitLocker encryption (via the Suspend-BitLocker cmdlet) prior to introducing any changes to the server. In addition, be sure to test any hardware and software configuration changes in a lab environment (that has BitLocker enabled) prior to deploying in production.

Also, be sure to develop a standard operating procedure about how to recover in the event the BitLocker recovery must be performed. This will ensure that downtime is minimized. For more information, please see the BitLocker Recovery Guide.

Disk Maintenance Activities

During the server's lifecycle, disks will die. As part of your standard operating procedures, you need to ensure that when a disk is replaced the new volume is formatted and encrypted via BitLocker.

In the event you are using AutoReseed to recover from failed disks, you have two options: format and encrypt the disks prior to usage, or encrypt after failure.

Format and encrypt the disks prior to usage

In this scenario, your standard operating procedure will be to prevent Disk Reclaimer from formatting hot spare disks. Instead, you will format and encrypt all hot spare disks prior to usage.

1. Disable Disk Reclaimer on the DAG: Set-DatabaseAvailabilityGroup <DAGName> -AutoDagDiskReclaimerEnabled $false
2. Format and encrypt all hot spares. Do not assign mount points or drive letters.
3. As disks fail, AutoReseed will assign the hot spare volumes, replacing the failed volumes, and reseed the afflicted database copies.
4. Schedule a maintenance window. Replace the failed disks. Format and encrypt.

Encrypt after failure

In this scenario, your standard operating procedure will be to allow Disk Reclaimer to format hot spare disks (default behavior). After the spare is formatted and databases are reseeded, you will encrypt the disk.

1. As disks fail, AutoReseed allocates, remaps and formats a spare disk.
2. AutoReseed initiates reseed operations.
3. Using SCOM, or another operations management tool, you will monitor for events 1127 (initiated reseed of a database) and 826 (completed reseed of a database) that are located in the Microsoft-Exchange-HighAvailability/Seeding crimson channel.
4. Schedule a maintenance outage for the affected server and encrypt the new volume.

Conclusion

Hopefully this information helps understanding BitLocker encryption and configuring BitLocker for Exchange servers. As indicated, the recommended approach is to use a TPM for storing the recovery information and to allow the operating system to unlock volumes automatically during boot. However, if your servers do not have access to a TPM, you can consider encrypting only the data volumes and crafting a mechanism to ensure that the data volumes unlock at OS boot.

If you have any questions, please do not hesitate to ask.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

With the release of Exchange Server 2016, I thought it would be best to document our guidance around utilizing Kerberos authentication for MAPI clients. Like with the last two releases, the solution leverages deploying an Alternate Service Account (ASA) credential so that domain-joined and domain-connected Outlook clients, as well as other MAPI clients, can utilize Kerberos authentication.

Depending on your environment, you may utilize a single ASA or have multiple ASA accounts during the coexistence period.

Exchange 2016 Coexistence with Exchange 2010

Two ASA credentials will be utilized in this environment. One ASA credential will be assigned to Exchange 2010 and host the exchangeMDB, ExchangeRFR, and ExchangeAB SPNs, while a second ASA credential will be assigned to Exchange 2016 and host the http SPN records.

For more information, see the Exchange 2013 and Exchange 2010 Coexistence with Kerberos Authentication article.

Exchange 2016 Coexistence with Exchange 2013

A single ASA credential will be utilized and configured on all Exchange 2013 and Exchange 2016 servers.

For more information, see the Exchange 2013 Configuring Kerberos authentication for load-balanced Client Access servers article.

Note: The RollAlternateserviceAccountCredential.ps1 script included in Exchange 2016 scripts directory utilizes the new cmdlets, Get/Set-ClientAccessService. This cmdlet will not execute correctly on Exchange 2013 servers. Use the RollAlternateserviceAccountCredential.ps1 script included in Exchange 2013 scripts directory to deploy the ASA across Exchange servers.

Exchange 2016 Coexistence with both Exchange 2010 and Exchange 2013

Two ASA credentials will be utilized in this environment. One ASA credential will be assigned to Exchange 2010 and host the exchangeMDB, ExchangeRFR, and ExchangeAB SPNs, while a second ASA credential will be assigned to the Exchange 2013 and Exchange 2016 servers to host the http SPN records.

For more information, see the Exchange 2013 and Exchange 2010 Coexistence with Kerberos Authentication article.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Our goal with this article is to articulate the various client connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.

Existing Environment

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 has Exchange 2010 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2010 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 Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURL property populated.

To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the three 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.

Note: The recommended practice is to configure the 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.

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. 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.
3. OrangeUser 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, url’s for 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. 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.
3. 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. 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.
3. 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 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 2016 in Site1

Exchange 2016 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 2016 Client Access component infrastructure.

To understand the client connectivity now that Exchange 2016 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 MBX2016 infrastructure located in Site1. Outlook clients and ActiveSync clients (on initial configuration) will submit Autodiscover requests to the MBX2016 infrastructure and depending on the mailbox version, different behaviors occur:

1. For mailboxes that exist on Exchange 2010, MBX2016 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 2016 (Purple User), MBX2016 will proxy the request to the Exchange 2016 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.

When you have an Exchange 2016 mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2016 mailboxes.

Important: When you introduce Exchange 2016 into a native Exchange 2010 environment, MAPI/HTTP will be enabled by default. Prior to moving any mailboxes to Exchange 2016, ensure you have configured your load balancer and/or firewall rules to allow traffic on /mapi/* via TCP443.

In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2016, 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 Outlook Updates 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 use different names for Outlook Anywhere inside and out. Outlook will also prefer 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. By utilizing two namespaces for Outlook Anywhere, you can ensure that your internal clients can connect utilizing Kerberos authentication.

The default Exchange 2016 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.

In environments that are native Exchange 2010, when you introduce Exchange 2016, MAPI/HTTP will be enabled by default. As long as the client supports the protocol, once a mailbox is moved to Exchange 2016, the client will reconfigure itself to use MAPI/HTTP. Upon next boot of the client, MAPI/HTTP will be utilized. It is very important to ensure that you have the correct firewall and load balancer settings in place prior to moving mailboxes, otherwise client connectivity will fail.

External Outlook Anywhere & MAPI/HTTP 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 2016 Client Access component’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 (Exchange 2010 CAS or Exchange 2016 Mailbox server).

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. MBX2016 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. MBX2016 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. PurpleUser will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. MBX2016 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 on the web

For Outlook on the web, 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. MBX2016 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. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his namespace endpoint. MBX2016 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. MBX2016 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, MBX2016 is not involved in any fashion.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. MBX2016 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. MBX2016 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.

Exchange ActiveSync

For Exchange ActiveSync clients, the user experience will depend on the mailbox version and where the mailbox is located. In addition, Exchange 2016 no longer supports the 451 redirect response – Exchange 2016 will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. MBX2016 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. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. MBX2016 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, MBX2016 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. MBX2016 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. MBX2016 will issue a cross-site proxy request to an Exchange 2010 Client Access server that resides in the same site as the mailbox.

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. MBX2016 will then proxy the request to an Exchange 2010 Client Access server within the local site.
2. For the PurpleUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. MBX2016 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.

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. MBX2016 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 thePurple User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active copy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. MBX2016 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.

How MBX2016 Picks a Target Legacy Exchange Server

It’s important to understand that when MBX2016 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 MBX2016 choose which legacy Client Access server to proxy the connection?

When a MBX2016 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, MBX2016 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. MBX2016 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, MBX2016 immediately retries to determine if the error was a transient error. If this second attempt fails, MBX2016 marks the target CAS as down and excludes it from being a proxy target. At the next interval (50 seconds), MBX2016 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:

2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /ecp - 443 - 192.168.1.42 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 302 0 0 277 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /PowerShell - 443 - 192.168.1.27 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 309 177 15
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 HEAD /EWS - 443 - 192.168.1.134 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 0 0 245 170 0
2015-08-11 14:00:00 W3SVC1 DF-C14-02 192.168.1.76 GET /owa - 443 - 192.168.1.220 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 301 0 0 213 169 171
2015-08-11 14:00:01 W3SVC1 DF-C14-02 192.168.1.76 HEAD /Microsoft-Server-ActiveSync/default.eas - 443 - 192.168.1.29 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-1.coe.lab 401 2 5 293 194 31
2015-08-11 14:00:04 W3SVC1 DF-C14-02 192.168.1.76 HEAD /OAB - 443 - 10.166.18.213 HTTP/1.1 HttpProxy.ClientAccessServer2010Ping - - coe-e16-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:

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 2016 Client Access component to a target server (whether that be an Exchange 2016 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 2016 Client Access component receives a POP or IMAP request, it will authenticate the user and perform a service discovery.

If the target mailbox is E2010, MBX2016 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.

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

Important: Exchange 2016 Mailbox 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 2016 when coexisting with Exchange 2010. Please let us know if you have any questions.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Our goal with this article is to articulate the various connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2013 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.

Existing Environment

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 has Exchange 2013 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2013 infrastructure.
• Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2013 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2013 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 2013 infrastructure.

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

To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the three users.

Autodiscover

The Autodiscover 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 retrieve configuration settings based on their mailbox’s location.

Note: The recommended practice is to configure the 2013 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 internal load balanced VIP for the 2013 Client Access servers in your environment.

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

Outlook Anywhere & MAPI/HTTP Clients

When you have an Exchange 2013 or later mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 and later mailboxes.

In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013 (and Exchange 2016), 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 Outlook Updates 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 use different names for Outlook Anywhere inside and out. Outlook will also prefer 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. By utilizing two namespaces for Outlook Anywhere, you can ensure that your internal clients can connect utilizing Kerberos authentication.

The default Exchange 2013 (and Exchange 2016) 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.

For Outlook Anywhere clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will de-encapsulate the RPC from the HTTP packet and obtain the data.

For MAPI/HTTP clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will act on the MAPI ROPs embedded in the HTTP protocol and obtain the data.

1. Red User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. Blue User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
3. OrangeUser will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

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

Outlook Web App

For Outlook Web App clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

1. Red User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site 3.
3. 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   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 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. 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 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.

Exchange ActiveSync

For Exchange ActiveSync clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. CAS2013 in Site1 will proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data. In addition, Exchange 2013 and later no longer supports the 451 redirect response – Exchange 2013 and later will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).

1. Red User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
3. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   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. CAS2013 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

For Exchange Web Services clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
3. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Client Connectivity with Exchange 2016 in Site1

Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. Both Exchange 2013 Client Access servers and Exchange 2016 Mailbox servers participate in the load balanced namespace mail.contoso.com and autodiscover.contoso.com.

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

Autodiscover

Either CAS2013 or MBX2016 in Site1 will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located. CAS2013 or MBX2016 will proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Outlook Anywhere & MAPI/HTTP Connectivity

For Outlook Anywhere connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s RPC proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server).

For MAPI/HTTP connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s MAPI virtual directory proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server).

1. Red User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. PurpleUser will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. OrangeUser will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Outlook on the web

For Outlook on the web clients, either an Exchange 2013 Client Access server or an Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

1. Red User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. PurpleUser will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013/MBX2016 in Site1 will proxy the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site 3.
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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013/MBX2016 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 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.

Exchange ActiveSync

The Exchange 2013 Client Access server or Exchange 2016 Mailbox server receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server)

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. PurpleUser’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. For the Orange User, there are two possible scenarios:
   1. Orange User’s ActiveSync client will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User’s ActiveSync client will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013/MBX2016 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

Like with other protocols, Exchange Web Services follows the same methodology. Either an Exchange 2013 Client Access server or Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version or where the mailbox is located. The server will then proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
2. For the PurpleUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Offline Address Book

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

1. For the Red User, Purple User andBlue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active copy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox.
2. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Offline Address Book URL.

Conclusion

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

Our goal with this article is to articulate the various connectivity scenarios you may encounter in your Exchange 2016 designs. To that end, this article will begin with a walk through of a deployment that consists of Exchange 2013 and Exchange 2010 in a multi-site architecture and show how the connectivity changes with the introduction of Exchange 2016.

Existing Environment

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 has Exchange 2013 and Exchange 2010 servers. There are two namespaces associated with this location – mail.contoso.com and autodiscover.contoso.com resolve to the CAS2013 infrastructure.
• Regional Internet Facing AD Site (Site2) - This is an AD site that has exposure to the Internet. This site has Exchange 2013 servers. The primary namespace is mail-region.contoso.com and resolves to the CAS2013 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 Exchange servers whose virtual directories have the ExternalURL property populated. Similarly, the term, Non-Internet Facing AD Site, simply means any Active Directory site containing Exchange servers whose virtual directories do not have ExternalURLproperty populated.

To understand the client connectivity before we instantiate Exchange 2016 into the environment, let’s look at how each protocol works for each of the four users.

Autodiscover

The Autodiscover external namespace, autodiscover.contoso.com, as well as, the internal SCP records for all Client Access servers resolve to the CAS2013 infrastructure located in Site1. Outlook clients, ActiveSync clients (on initial configuration), and EWS clients 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 2013 (Purple User), 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.

Note: The recommended practice is to configure the 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 AutoDiscoverServiceInternalUrito a value that resolves to the internal load balanced VIP for the 2013 Client Access servers in your environment.

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

Outlook Anywhere & MAPI/HTTP Clients

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.

When you have an Exchange 2013 or later mailbox you are using Outlook Anywhere (RPC/HTTP) or MAPI/HTTP, either within the corporate network or outside of the corporate network; RPC/TCP connectivity no longer exists for Exchange 2013 and later mailboxes.

In Exchange 2010, the way Outlook Anywhere was implemented is that you had one namespace you could configure. In Exchange 2013 (and Exchange 2016), 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 OutlookUpdates 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 use different names for Outlook Anywhere inside and out. Outlook will also prefer 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. By utilizing two namespaces, you can ensure that your internal clients can connect utilizing Kerberos authentication.

The default Exchange 2013 (and Exchange 2016) 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.

For Outlook Anywhere clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

For MAPI/HTTP clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, and determine that the mailbox version is 2013 and where the mailbox is located. The Client Access server will then proxy the request to the Exchange 2013 Mailbox server that is hosting the active copy of the user’s mailbox which will act on the MAPI ROPs embedded in the HTTP protocol and obtain the data.

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. PurpleUser will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. OrangeUser will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

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

Outlook Web App

For Outlook Web App clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version, where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

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. PurpleUser will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013 in Site1 will proxy the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site 3.
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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   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 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. 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 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.

Exchange ActiveSync

For Exchange ActiveSync clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

Note: Exchange 2013 and later no longer supports the 451 redirect response – Exchange 2013 and later will always proxy ActiveSync requests (except in hybrid scenarios, where redirection is allowed).

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. PurpleUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. Blue User’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   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. CAS2013 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

For Exchange Web Services clients, an Exchange 2013 Client Access server will authenticate the user, do a service discovery, determine the mailbox version and where the mailbox is located. The Client Access server will then proxy the request as follows.

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 PurpleUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
4. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Client Connectivity with Exchange 2016 in Site1

Exchange 2016 has now been deployed in Site1 following the guidance documented within the Exchange Deployment Assistant. Both Exchange 2013 Client Access servers and Exchange 2016 Mailbox servers participate in the load balanced namespace mail.contoso.com and autodiscover.contoso.com.

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

Autodiscover

Either CAS2013 or MBX2016 in Site1 will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located. CAS2013 or MBX2016 will proxy the request as follows.

1. For mailboxes that exist on Exchange 2010, CAS2013/MBX2016 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 2013 (Purple User), CAS2013/MBX2016 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.
3. For mailboxes that exist on Exchange 2016 (Yellow User), CAS2013/MBX2016 will proxy the request to the Exchange 2016 Mailbox server that is hosting the active copy of the user’s mailbox which will generate the Autodiscover response.

Outlook Anywhere & MAPI/HTTP Connectivity

For Outlook Anywhere’s connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s RPC proxy component will receive the incoming connections, authenticate and choose which server to route the request to (regardless of version), and proxy the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server or Exchange 2016 Mailbox server).

For MAPI/HTTP connections, the Exchange 2013 Client Access server or Exchange 2016 Mailbox server’s MAPI virtual directory proxy component receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2013 or Exchange 2016 Mailbox server).

1. Red User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 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/MBX2016 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. PurpleUser will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. YellowUser will connect to mail.contoso.com as his RPC proxy or MAPI/HTTP endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User will connect to mail.contoso.com as his RPC proxy endpoint. CAS2013/MBX2016 in Site1 will determine the mailbox version is 2010 and that the mailbox database hosting the user’s mailbox is located in Site3. CAS2013/MBX2016 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.
5. OrangeUser will continue to access his mailbox using the Exchange 2013 regional namespace, mail-region.contoso.com. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Outlook on the web

For Outlook on the web clients, either an Exchange 2013 Client Access server or an Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version, and where the mailbox is located and either proxy or redirect depending on the OWA virtual directory configuration in the mailbox’s site.

1. Red User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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. MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. YellowUser will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will determine that the mailbox is located within Site3, which does not contain any OWA ExternalURLs. CAS2013/MBX2016 in Site1 will proxy the request to CAS2010 in Site3. CAS2010 in Site3 will retrieve the necessary data from the Exchange 2010 Mailbox server.
5. 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. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 in Site1 is configured to do a cross-site silent redirection (default behavior), therefore, CAS2013/MBX2016 will initiate a single sign-on silent redirect (assumes FBA is enabled on source and target) to mail-region.contoso.com. CAS2013 in Site2 will then facilitate the request and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   3. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 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/MBX2016 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.

Exchange ActiveSync

The Exchange 2013 Client Access server or Exchange 2016 Mailbox server will receives the incoming connections, authenticates and chooses which server to route the request to (regardless of version), proxying the HTTP session to the endpoint (Exchange 2010 Client Access server, Exchange 2013 Mailbox server, or Exchange 2016 Mailbox server).

1. Red User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 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/MBX2016 will proxy the request to an Exchange 2010 Client Access server which will retrieve the necessary data from the Exchange 2010 Mailbox server.
2. PurpleUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. YellowUser’s ActiveSync client will connect to mail.contoso.com as his endpoint. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. Blue User’s ActiveSync client will connect to mail.contoso.com as the namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site3. CAS2013/MBX2016 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.
5. For the Orange User, there are two possible scenarios:
   1. Orange User will connect to mail-region.contoso.com as his namespace endpoint. CAS2013 in Site2 will authenticate the user, do a service discovery, and determine that the mailbox is located within the local AD site and perform a local proxy to Mailbox 2013 server that hosts the active database copy in Site2.
   2. Orange User will connect to mail.contoso.com as his namespace endpoint. CAS2013/MBX2016 in Site1 will authenticate the user, do a service discovery, and determine that the mailbox is located within Site2. CAS2013/MBX2016 in Site1 performs a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

Exchange Web Services

Like with other protocols, Exchange Web Services follows the same methodology. Either an Exchange 2013 Client Access server or Exchange 2016 Mailbox server will authenticate the user, do a service discovery, determine the mailbox version or where the mailbox is located. The server will then proxy the request to the Mailbox server that is hosting the active copy of the user’s mailbox which will obtain the data.

1. For the Red User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 will then proxy the request to an Exchange 2010 Client Access server within the local site.
2. For the PurpleUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site1.
3. For the YellowUser, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a local proxy request, proxying the HTTP session to the Mailbox 2016 server that hosts the active database copy in Site1.
4. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Exchange Web Service URL. CAS2013/MBX2016 in Site1 will perform a cross-site proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site3.
5. For the Orange User, Autodiscover will return the mail-region.contoso.com namespace for the Exchange Web Service URL. CAS2013 in Site2 will perform a local proxy request, proxying the HTTP session to the Mailbox 2013 server that hosts the active database copy in Site2.

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/MBX2016 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 Yellow User andPurple User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 will then proxy the request to the Exchange 2013/2016 Mailbox server that is hosting the active copy of an OABGEN mailbox that contains a copy of OAB that is closest to the user’s mailbox.
3. For the Blue User, Autodiscover will return the mail.contoso.com namespace for the Offline Address Book URL. CAS2013/MBX2016 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.

Conclusion

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

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

When PowerShell was introduced back in Exchange 2007 it was a boon too all us Exchange administrators. It allowed us as admins to manage large numbers of objects quickly and seamlessly. We have come to rely on it for updating users, groups, and other sets of objects.

With Office 365 things have changed a bit. No longer do we have a local Exchange server to talk too for running our cmdlets, instead we have to communicate over the internet to a shared resource. This introduces a number of challenges for managing large numbers of objects that did not exist previously.

PowerShell Throttles

Office 365 introduces many throttles to ensure that one tenant or user can’t negatively impact large swaths of users by over utilizing resources. In PowerShell this shows up primarily as Micro Delays.

WARNING: Micro delay applied. Actual delayed: 21956 msecs, Enforced: True, Capped delay: 21956 msecs, Required: False,
Additional info: .;
PolicyDN: CN=[SERVER]-B2BUpgrade-2015-01-21T03:07:53.3317375Z,CN=Global
Settings,CN=Configuration,CN=company.onmicrosoft.com,CN=ConfigurationUnits,DC=FOREST,DC=prod,DC=outlook,DC=com;
Snapshot: Owner: Sid~EURPR05A003\a-ker531361849849165~PowerShell~false
BudgetType: PowerShell
ActiveRunspaces: 0/20
Balance: -1608289/2160000/-3000000
PowerShellCmdletsLeft: 384/400
ExchangeCmdletsLeft: 185/200
CmdletTimePeriod: 5
DestructiveCmdletsLeft: 120/120
DestructiveCmdletTimePeriod: 60
QueueDepth: 100
MaxRunspacesTimePeriod: 60
RunSpacesRemaining: 20/20
LastTimeFrameUpdate: 1/23/2015 10:39:08 AM
LastTimeFrameUpdateDestructiveCmdlets: 1/23/2015 10:38:48 AM
LastTimeFrameUpdateMaxRunspaces: 1/23/2015 10:38:48 AM
Locked: False
LockRemaining: 00:00:00

Throttles like this one in O365 can be thought of like a bucket. The service is always pouring more time into the top of the bucket and we as administrators are pulling time out of the bottom of the bucket. As long as the service is adding more time than we are using then we don’t run into any issues.

The problem is when we are running an intensive command like Get-MobileDeviceStatistics, Set-Clutter, or Get-MailboxFolderStatistics. These take a significant amount of time to run for each user and consume a fair bit of resources doing so. In this scenario we are pulling more out than the service is putting in so we end up getting throttled.

Another way to look at it is to examine the return and do the math to find out how much time we can spend running commands. If we examine the Micro Delay warning we can find our recharge rate here:

ActiveRunspaces: 0/20
Balance: -1608289/2160000/-3000000
PowerShellCmdletsLeft: 384/400

In this case mine is 2,160,000 milliseconds. So that is how many milliseconds I can spend per hour consuming resources. The value you see here will vary depending on the number of mailboxes in your tenant.

If we take our recharge rate and divide it by the number of milliseconds in one hour we get how much of each hour we can spend actively consuming resources in our session.

2,160,000 milliseconds recharge rate / 3,600,000 milliseconds per hour = 0.6

Or in other words 0.6 * 60 minutes = 36 minutes

Now when we are using the Shell for daily tasks we are never going to come anywhere close to this limit. Since it takes a bit of time for someone to type a command, plus most of us aren’t typing PowerShell command as fast as they can for hours at a time.

A quick solution if you are getting Micro Delayed is to introduce a sufficient pause between each command so that you don’t exceed your percent usage.

$(Get-Mailbox) | foreach { Get-MobileDeviceStatistics -mailbox $_.identity; Start-Sleep -milliseconds 500 }

Session stability

The next common issue I see is problems with Session Stability. Since we are connecting over the internet the stability of our session becomes a major concern. If we are going to have a script running Get-InboxRule against 180,000 users for four days, then the chance of us dropping the HTTPS session at some point in that time period is pretty high.

These session drops can be caused by any number of things

• Firewall dropping a long running session
• O365 CAS server getting upgraded or rebooted
• Upstream network issues

Most of the reasons for session drops we as admins have no control over. This issue will manifest itself as you coming back to a PowerShell window that is asking for your credentials.

Overcoming this one quickly isn’t easy. We would need to monitor the status of the connection and rebuild it if it encountered any errors. This can be done but it takes more than a few lines of code and could be a challenge to integrate every time we needed to use it.

Data return

Finally, we have the issue of data return. Before we can run a set command on a large number of mailboxes we must get an array of objects to execute against. Most of us do this with something similar to $mbx = Get-Mailbox -ResultSize Unlimited. But, if we are running this against thousands of mailboxes just the amount of data coming back from the server can take a significant amount of time.

This one we can easily get around but using two simple PowerShell tricks.

First we make use of Invoke-Command to run our get command on the remote server instead of on the local host. This means that we can send our command across the wire and have the O365 server execute it for us taking a good bit of the client out of the loop.

This is great since it puts the onus to do the work a lot closer to source of the data. But, it isn’t a perfect solution. This is because we are not able to run anything complex using a remote session and Invoke-Command. Instead we must restrict ourselves to fairly strait forward cmdets and simple filtering. Anything else will result in the server returning an error and rejecting our command.

This is where our second trick Select-Object comes in. By coupling Invoke-Command with Select-Object we can rapidly get our objects and only return a limited amount of data.

Invoke-Command -session (Get-Pssession) -scriptblock {Get-Mailbox -resultsize unlimited | select-object -property Displayname,Identity,PrimarySMTPAddress}

This command invokes a session on the server to run Get-Mailbox but uses Select-Object to only return the properties that I need to identify each object to operate on.

In my testing with 5000 Mail Contacts the invoke-command was on average 35% faster and returned significantly less data for my PowerShell client to deal with.

A scripted solution

Now that we know what challenges we face can we come up with a consistent, reusable solution to overcome them when we do have to run a cmdlet against a large collection of object.

To that end we have developed a highly generic wrapper script, Start-RobustCloudCommand.ps1, that will take your PowerShell command and execute it against the service in a robust manner that seeks to avoid throttles and actively deal with session issues. Couple this with Invoke-Command for quickly getting the list of objects to operate on and we can start getting back most of our pre service PowerShell functionality.

You can download the script here.

First, a key disclaimer. This script will NOT make your commands complete faster. If you are running a command that takes 5s per user and you have 7,200 users to run it against, it will still take at least 10 hours to complete. Using, this wrapper script will actually slow it down a bit. What it will do is try very hard to ensure that the PowerShell command is able to run uninterrupted, without failure, and without admin interaction for those 10+ hours.

How to use the script

Using the wrapper involves three steps

1. Build the PowerShell script block you want to run.
2. Collect the objects you want to run against.
3. Wrap your script block and execute.

Build the PowerShell Script Block

This is pretty much the same as building any PowerShell command. I like to build and test my commands against a single user before I try to use them in the Start-RobustCloudCommand.ps1.

Our first step is nice and easy, just write the PowerShell that we want against a single users data returned from Invoke-Command.

$mbx = invoke-command -session (get-pssession) -scriptblock {get-mailbox $mailboxstring | select-object -property DisplayName,Identity,PrimarySMTPAddress}
Get-MobileDeviceStatistics -mailbox $mbx.primarysmtpaddress.tostring() | select-object @{Name="DisplayName";Expression={$mbx.Displayname}},Status,DeviceOS,DeviceModel,LastSuccessSync,FirstSyncTime

Here I populated a variable $mbx with a single mailbox's information but I made sure to do it exactly like I am going to do when I gather the full data set. So I used Invoke-Command and Select-Object to only pull a minimum set of properties that I wanted for running Get-MobileDeviceStatistics.

Using invoke-command can at time result in unexpected data types in the results. This means when I send the resulting object into my command I can get errors where it is unable to deal with the data type presented. Most of these cases can be resolved by using .tostring() to convert the results into a string so that the cmdlet can understand them.

Next, I ran my Get-MobileDeviceStatistics command and again used Select-Object to get just the output information that I wanted. I also used the ability of Select-Object (Example 4 here) to allow me to create a property on the fly so that I could populate the Display Name of the mailbox in my output, something that isn't in the output of Get-MobileDeviceStatistics by default.

Now that I have my script working and giving me the data that I want I just need to make a minor alteration so that it will work in the script block potion of Start-RobustCloudCommand.ps1. The script block isn't able to read the $mbx variable since inside the script we are using local Invoke-Command -input to pass each object into the command one at a time. So to read the values of these objects we have to use the automatic variable $input.

Therefore, our command becomes the following:

Get-MobileDeviceStatistics -mailbox $input.primarysmtpaddress.tostring() | select-object @{Name="DisplayName";Expression={$input.Displayname}},Status,DeviceOS,DeviceModel,LastSuccessSync,FirstSyncTime

Easy to make the change but highly critical to the script functioning.

Collect the objects you want to run against.

Now that we have our command that we want to run we need to gather all of the objects that we want to run it against.

Here we use what we learned above to quickly and efficiently gather the objects that we are going to operate on.

Invoke-Command -Session (Get-PSSession) -ScriptBlock {Get-Mailbox -resultsize unlimited | select-object -property DisplayName,Identity,PrimarySMTPAddress} | Export-Csv c:\temp\users.csv
$mbx = Import-Csv c:\temp\users.csv

You will notice that I exported the output to a CSV file then imported it back into a variable. When I am operating on a large collection of objects I prefer this method because it gives me a written out collection of objects that I am working with. Later, if something beyond my control goes wrong, I can use the CSV file to restart the script with the objects that I have already run against removed from the file, giving me a manual "resume" functionality.

Wrap your script block and execute.

Finally, we put everything we have together and feed it into the wrapper script.

$cred = Get-Credential
.\Start-RobustCloudCommand.ps1 -Agree -LogFile c:\temp\10012015.log -Recipients $mbx -ScriptBlock { Get-MobileDeviceStatistics -Mailbox $input.primarysmtpaddress.tostring() | Select-Object @{Name="DisplayName";Expression={$input.Displayname}},Status,DeviceOS,DeviceModel,LastSuccessSync,FirstSyncTime } -Credential $cred

Here we can see the script iterating thru each of my test users, executing the command and sending the resulting output to the screen. Also we can see that the script is logging everything it is doing to the screen and to the log file that I specified.

Information to the screen is great for a demo but generally you would want this information in a file so that you could review it later. All we have to do is add | Export-Csv c:\temp\devices.csv -Append to the end of our script block and it will push the output of each command into our CSV. Remember that since this is basically a very complex foreach loop we have created you will need the -append otherwise it will overwrite itself for every user.

.\Start-RobustCloudCommand.ps1 -Agree -LogFile c:\temp\10012015.log -Recipients $mbx -ScriptBlock { Get-MobileDeviceStatistics -Mailbox $input.primarysmtpaddress.tostring() | Select-Object @{Name="DisplayName";Expression={$input.Displayname}},Status,DeviceOS,DeviceModel,LastSuccessSync,FirstSyncTime | Export-Csv c:\temp\devices.csv -Append } -Credential $cred

Conclusion

This solution is designed for customers who are having to run cmdlets against Large numbers of users in the service (>5000) and are running into issues. It is a bit complex to get working exactly how you want but it has been designed to be highly generic to allow it to handle most anything you throw at it.

Hopefully for our folks with large user sets they will be able to start utilizing this to make those changes across their tenant, or run reports easier.

Matthew Byrd

There is a new option that has been made available for our Office 365 customers that allows you to take advantage of integrating the OneDrive for Business attachment experience directly from your OWA and Outlook 2016 clients. The main point of this feature is to allow you to insert a link and properly permission a document that is stored in a OneDrive account. This will prevent you from having to send a traditional attachment to a set of users only to go through the painful tasks of merging all of the comments and changes. Instead, you can send the document via a OneDrive link that can all be edited from the same source location.

If you have an Office 365 mailbox and a OneDrive for Business account, you are all set, this functionality will just work.

However, what if you are in a Hybrid Configuration with some mailboxes still in the on-premises Exchange 2016 environment? For example, you may be an on-premises mailbox user who has a OneDrive for Business account in Office 365. In this case, you may want to use the modern attachment method to share a document stored in OneDrive for Business with multiple recipients. The location of the recipients are unknown, but in the end that will not matter, it needs to just work.

By following the steps outlined in the Configure document collaboration with OneDrive for Business and Exchange 2016 on-premises, the experience will go from this:

After the feature is enabled you will notice a change in your attachment behavior. Instead of seeing the legacy attachment window you will see the OneDrive for Business integration experience.

To see the new experience from OWA, you click on newto create a new Email message:

You then click on the Attachoption:

From there you can see we default to the OneDrive for Business view, but you still have access to add local files as well:

You will then get a choice to Share with OneDrive for Business or to use the traditional attachment experience:

Summary

You can now give your on-premises Exchange users the benefits of working with OneDrive for Business even if you do not intend to move their mailboxes to the cloud any time soon. This is a great way to allow you and your customers to see the value of our cloud services while being able to move at a pace that is right for you!

Other useful links

1. The OneDrive for Business Sync Client announcement
2. Hybrid OneDrive for Business – Overview
3. Exchange Hybrid Configuration Wizard Blog

Timothy Heeney
Supportability Program Manager

When installing a brand new Exchange server, there are several things that you should consider. One of them is that things will go smoother if you deploy a new currently supported version of Exchange server into a live production environment by leveraging an Active Directory (AD) deployment site design option.

When you install a new Exchange server, it adds Service Connection Points (SCP’s) in records within AD and depending on your environment configuration, that new server can start answering client requests. However, since the default self-signed certificate is not trusted by clients, Outlook might start presenting certificate errors to end users. Not the best experience, and easily preventable!

When there is a valid SCP to send Autodiscover requests, the process randomly selects a server in the AD site to get requests. You can control incoming web traffic via a Load Balancer, however, the servers that GET the requests are not guaranteed to be the same servers SENDING the responses, which can cause an Outlook certificate pop-up warning.

If you try to work around this by ‘nulling out’ the AutodiscoverServiceInternalUri value on the Exchange servers that do not contain a valid trusted certificate, realize that you are not necessarily preventing the server from replying to a client to use that server. Hence, there is still a possibility of certificate warning in Outlook.

How to avoid this situation

AD is smart enough to be ‘most restrictive’ when a site subnet is defined. If you have a 192.168.0.x/24 subnet defined to an AD Site and a more restricted subnet of 192.168.0.1/32 to a different AD Site, the most restricted value is defined for that AD Site. (Note: a /32 is a single IP address, which would be enough for a single server deployment.)

Some options exist that you can leverage:

• Keep reusing the same IP to deploy a server, and then change the IP of that server once the URL’s are configured and the certificate is installed.
• Change the subnet definition in AD Sites and Services for each server you build and its’ specific IP address.
• Use a small subnet with several IP’s available, like a /29 subnet, which has 6 IP addresses (192.168.0.128/29) (range: 192.168.0.128-192.168.0.134), and setup up to 6 new Exchange servers. Then once they are fully configured, just remove the /29 subnet from AD Sites and Services, bounce the Exchange servers, reset the AutoDiscoverSiteScope values, and then they’ll answer proper values to your clients.

What AD Site is the server in?

Before you install Exchange, check to see what AD site the server is in. In PowerShell on the local Exchange server:

nltest /dsgetsite

After you install Exchange, you can change the IP or change the AD Site subnet definition, restart the server, and update the AutoDiscoverSiteScope value. Check the server again to ensure it is in the correct AD Site and also check to see if the other Exchange servers think it is in the correct AD Site by running:

Get-ExchangeServer | FT Name,Site –Autosize

And to see the Exchange AutoDiscoverSiteScope values: (pre-2016 server)

Get-ClientAccessServer | FT Name,AutoDiscoverSiteScope –Autosize

Or 2016 and above:

Get-ClientAccessService | FT Name,AutoDiscoverSiteScope –Autosize

One last step after you’ve either changed the IP of the server, or removed the AD site, you need to update the AutoDiscoverSiteScope. In PowerShell:

Set-ClientAccessService <server name> –AutoDiscoverSiteScope <name of AD Site>

You can then re-run the Get cmdlet to confirm that the values are what you need for your environment. This will help ensure that you typed the correct AD Site information in the previous cmdlet.

Conclusion

This process helps to ensure that clients will not be getting annoying pop-ups while you are installing additional Exchange servers into your production environment. It is still best to follow your companies change process and inform end users of potential notifications, but this should eliminate any unexpected Outlook interruptions.

Mike O'Neill