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

Load Balancing

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

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

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

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

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

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

Figure 1: Exchange 2013 Client Access Protocol Architecture

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

Figure 2: Layer 4 Load Balancing

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

Health Probe Checking

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

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

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

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

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

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

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

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

Namespace and Affinity Scenarios

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

1. Single Namespace / No Session Affinity
2. Single Namespace / Session Affinity
3. 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 configured to not maintain session affinity (layer 4). The load balancer is also configured to check the health of the target Client Access servers in the load balancing pool; 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 CAS in the load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target CAS from the load balancing pool for all requests associated with that particular namespace. In other words, in this example, health from the perspective of the load balancer, is per-server, not per-protocol, for the given namespace. This means that if the health probe fails, all client requests will have to be directed to another server, regardless of protocol.

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

Single Namespace / Layer 7 (No Session Affinity)

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

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

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

Single Namespace / Session Affinity

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

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

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

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

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

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

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

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

Scenario Summary

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

Conclusion

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

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Whether you’re using the Exchange Server Role Requirements Calculator by Ross Smith IV or the Exchange Client Network Bandwidth Calculatorby Neil Johnson, you’ll need to provide statistics about your log file usage to determine bandwidth requirements.

Whenever I’ve done that previously, I’d pipe the directory content to a text file and then start working on it in Excel. That is quite tedious and laborious work, and to be honest; very few people would probably do it for more than one or two log sets if at all.

Then why not automate it? If it’s a question of finding files and a bit of string handling, PowerShell should be able to do it for you… And sure enough, writing the first lines of code in a Seattle hotel, the project started taking form.

The script, GetLogFileUsage.ps1, is controlled by command line inputs, if no arguments are given, the help screen will display:

By default the script will grab log files from the last 24 hours but can be set to use a specific date using the “-Date” parameter. You need to make sure that transaction log files have not been truncated by a backup in the set time window. Needless to say, this will not work with circular logging.

You can specify a single database using the “-Database <db name>” parameter, a specific server by using the “-Server <server name>” parameter, or simply just all servers in the Organization by using “-Server All”.

Important: To support the database and server parameters, the script must run in the Exchange Management Shell.

If you’re unable to run the script in EMS or you’re collecting statistics from legacy Exchange or even a non-Exchange server, you can use a path file to input servers and paths to the script. The format of the file is:

Using the path file as input will provide support for any transaction log based database, not just Exchange. So feel free to mess around with it, I’d be happy to hear how many third party products that are supported.

To use the default file “.\paths.txt”, just add the parameter “-File” or use it in combination with “-PathFile <file name>” to specify a file of your choice.

If you want to use another CSV file delimiter than semicolon, specify it on the command line using the “-Delimiter” parameter, or change it in the script if you want it to be permanent.

Depending on how many databases or servers you’ve selected, the script will run for a while until it shows the output displayed in the following screen:

This serves only as a means for you to check if the numbers look right. The “Percent” column is automatically placed in your clipboard for you to paste into Notepad (first line is blank so you need to remove it before pasting into Excel).

The pasted numbers will look like this in the Exchange Server Role Requirements Calculator (you have to select site resilient deployment to enter numbers into these cells):

And this is how it looks when used in the Exchange Client Network Bandwidth Calculator (found on the bottom far right of the “Client Mix” worksheet):

As an added bonus, a CSV file with all your log drive statistics is created for you to see if a better distribution of log files is needed to even out load on the drives.

I hope you will find this script useful and time saving when working with the calculators. Feedback and comments for improvement are more than welcome.

Karsten Palmvig
Principal Consultant, MCS Denmark

Microsoft Exchange Server 2003 entered the market on September 28, 2003 and continued the great messaging and collaboration experience that Microsoft Exchange Server had provided in previous releases. As we approach April 8, 2014, we want to inform users of Microsoft Exchange Server 2003 of the opportunities you have as we near the end of support for that version of Exchange.

We have been told by a variety of customers that some of the top concerns of businesses today involve data security, compliance, eDiscovery, mobile devices use / bring-your-own-device, and IT management. While Exchange 2003 was a leader in messaging space, its decade old capabilities may not meet the needs of a modern business. Exchange Online or Microsoft Exchange Server 2013 provide an updated, modern solution that address these top concerns and provide additional capabilities to meet your business needs. In comparing versions of Exchange Server, you will quickly see all of the benefits of moving to the current version of the platform.

The process to move from Exchange 2003 to Exchange 2013 on-premises is a two-step migration.  There is no native, direct migration path from Exchange Server 2003 to Exchange 2013 on premises; it must be done in stages.  For an Exchange Online migration, you can use the Migration dashboard in the Exchange Admin Center (EAC) to migrate mailboxes and mail content from an on-premises messaging system (including Exchange 2003) to Exchange Online and your Office 365 organization. You can migrate mailboxes and mailbox data from Exchange 2013, Exchange 2010, Exchange 2007 and Exchange 2003, or migrate mailbox data from an IMAP messaging system.

The migration plan should address immediate needs but should also focus directly on the future of your messaging platform. Please use the information and resources below to help you make a decision that meets all of your needs.

The Exchange 2003 Migration Tool Kit

Exchange Server Deployment Assistant:
http://technet.microsoft.com/en-us/library/ee681665(v=exchg.141).aspx

Exchange 2003 - Planning Roadmap for Upgrade and Coexistence
http://technet.microsoft.com/en-us/library/aa998186(v=exchg.141).aspx

*Many other migration references linked from this topic*

Depending on your choices in the Exchange Server Deployment Assistant you may elect to migrate to Exchange 2013 on-premises via Exchange 2010, or you may elect to migrate directly to our Office 365 hosted Exchange environment. The references linked at the end of this post provide more information on specific migration scenarios and coexistence with both Exchange 2010 and Exchange 2013.

Coexistence of Exchange 2013 and earlier versions of Exchange Server:

On-premises Exchange organization

Hybrid deployments can be configured for on-premises Exchange 2007-based organizations or later. For Exchange 2007 and Exchange 2010 organizations, at least one Exchange 2013 Client Access and one Exchange 2013 Mailbox server must be installed in the on-premises organization to run the Hybrid Configuration wizard and support Exchange 2013-based hybrid deployment functionality. We recommend combining the Exchange 2013 Client Access and Mailbox server roles on a single server when configuring hybrid deployments with Exchange 2007 and Exchange 2010 environments. All on-premises Exchange 2013 servers must have installed the latest CU or Service Pack (whichever is newer) for Exchange 2013 to support hybrid functionality with Office 365.

For a complete listing of Exchange Server and Office 365 for enterprises tenant hybrid deployment compatibility, see the requirements listed in the following table for Exchange 2013-based and Exchange 2010-based hybrid deployments.

Notes:

1 - Blocked in Exchange 2013 setup
2 - Tenant upgrade notification provided in Exchange Management Console
3 - Requires at least one on-premises Exchange 2010 SP2 server
4 - Requires at least one on-premises Exchange 2010 SP3 server
5 - Requires at least one on-premises Exchange 2013 CU1 or greater (recommended) server

Office 365 for Enterprises  

An Office 365 for enterprises tenant and administrator account and user licenses must be available on the tenant service to configure a hybrid deployment. The Office 365 tenant version must be 15.0.000.0 or greater to configure a hybrid deployment with Exchange 2013. Additionally, your Office 365 tenant status must not be transitioning between service versions. For a complete summary, see the preceding table. To verify your Office 365 tenant version and status, see Verify Office 365 tenant version and status here.

For Microsoft Premier customers who are interested in a more hands-on assisted approach, Microsoft has a workshop offering (EMRA – Exchange Migration Readiness Assessment).  We know that your company relies on Microsoft for reliable and secure business communication and collaboration. To ensure your users experience optimal levels of performance and availability during the migration period, Microsoft Services has created the Migrations Readiness Assessments.

Customized for your business, the Exchange Migration Readiness Assessment will provide an in-depth analysis of Active Directory and current Exchange environment for focus on readiness for a transition Exchange Server 2010 deployment.

A final report will be provided summarizing the key findings as well as key metrics collected from the environment, capturing the state of the current environment and its overall deployment readiness.

Focused on your IT needs, the Exchange Server 2010 Migration Readiness Assessments make up a 4 day on-site engagement that prepares both your data center and IT staff for a successful migration. We created the assessment to meet your specific needs focusing on the following areas:

• Proactive analysis of your on-premises messaging environment.
• Focused and tailored knowledge transfer to enable and prepare your IT staff.
• A detailed report of your current on-premises deployment.
• Key planning metrics to accelerate migration and deployment.
• Documented roadmap to enable worry free migration.
• Optional component to evaluate readiness to support Exchange Online features.
• Accelerate Migration and Maximize Adoption

Microsoft Services delivers a comprehensive assessment of your current environment in preparation for a smooth migration. Exchange Server 2010 Migrations Readiness Assessment significantly reduces your exposure to costly mistakes and delays that can impact your end users’ experience with Microsoft Exchange Server 2010.

For more information about consulting and support offerings from Microsoft, contact your Microsoft Services representative or visit www.microsoft.com/services.

References

Understanding Upgrade to Exchange 2010
http://technet.microsoft.com/en-us/library/aa998604(v=exchg.141).aspx

Understanding Upgrade from Exchange 2003 to Exchange 2010
http://technet.microsoft.com/en-us/library/ff805040(v=exchg.141).aspx

Understanding Upgrade from Exchange 2003 and Exchange 2007 to Exchange 2010
http://technet.microsoft.com/en-us/library/ff805036(v=exchg.141).aspx

Checklist: Upgrading from Exchange 2003 and Exchange 2007
http://technet.microsoft.com/en-us/library/ff805038(v=exchg.141).aspx

Upgrading Exchange Server 2003 to Exchange Server 2007
http://technet.microsoft.com/en-us/library/hh757966.aspx

Common Mistakes When Upgrading Exchange 2000/2003 To a Exchange 2007
http://support.microsoft.com/kb/555854

Upgrading Exchange ActiveSync to Exchange 2010
http://blogs.technet.com/b/exchange/archive/2009/12/08/upgrading-exchange-activesync-to-exchange-2010.aspx

MCS team blog:  Prepare client side environment to Upgrade from Exchange 2003/2007 to Exchange 2010
http://blogs.technet.com/b/meamcs/archive/2010/12/19/prepare-client-side-environment-to-upgrade-from-exchange-2003-to-exchange-2010.aspx

Upgrade from Exchange 2003 Mailbox
http://technet.microsoft.com/en-us/library/dd638113(v=exchg.141).aspx

How to Remove the Last Legacy Exchange Server from an Organization
http://technet.microsoft.com/en-us/library/bb288905.aspx

How to remove the first Exchange Server 2003 computer from the administrative group
http://support.microsoft.com/kb/822931

For SBS customers:  Guided Walk-Through of How to Remove the Last Legacy Exchange Server from an Organization in a SBS 2003 to SBS 2011 Migration
http://social.technet.microsoft.com/wiki/contents/articles/2263.remove-the-last-legacy-exchange-server.aspx

How to Uninstall Exchange Server 2003
http://technet.microsoft.com/en-us/library/bb125110(v=EXCHG.65).aspx

How to migrate mailbox data by using the Exchange Admin Center in Office 365
http://support.microsoft.com/kb/2798131/en-gb

Outlook.com Help | How to perform an Exchange 2003 cutover migration to the Office 365 Cloud
http://help.outlook.com/en-us/140/ms.exch.ecp.emailmigrationwizardexchangelearnmore.aspx

Outlook.com Help | How to perform an Exchange 2003  staged migration to the Office 365 Cloud
http://help.outlook.com/en-us/140/ff959224.aspx

Microsoft Product support lifecycle information by product family
http://support.microsoft.com/lifecycle/default.aspx?LN=en-us&c2=730&x=15&y=9

For all of the YouTube fans, there are numerous Exchange MVP and community contributors who have published hundreds of videos with guided walk-through for Exchange 2003 migration scenarios which may be helpful to review:  http://www.youtube.com/results?search_query=exchange+2003+migration+to+exchange+2010&sm=3

Chris Lineback, Ed Grant
Premier Field Engineers

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

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

Existing Environment

Figure 1: Exchange 2007 & Exchange 2010 Multi-Site Architecture

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

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

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

Autodiscover

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

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

Internal Outlook Connectivity

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

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

Outlook Anywhere

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

Outlook Web App

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

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

Exchange ActiveSync

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

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

Exchange Web Services

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

Client Connectivity with Exchange 2013 in Site1

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

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

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

Autodiscover

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

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

Internal Outlook Connectivity

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

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

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

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

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

External Outlook Connectivity

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

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

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

Outlook Web App

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

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

Exchange ActiveSync

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

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

Exchange Web Services

Coexistence with Exchange Web Services is rather simple.

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

Offline Address Book

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

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

How CAS2013 Picks a Target Legacy Exchange Server

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

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

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

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

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

Set-ClientAccessServer <server> -IsOutofService $True

Conclusion

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

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

Let’s say you are in process of removing the last copy of a mailbox database or uninstalling an Exchange server and run into the following error message:

“This mailbox database contains one or more mailboxes…”

You check again and again but can’t find a mailbox on the server being uninstalled or the database you are deleting, but the error continues haunting you!!

Sounds familiar? Ran into this before? Read on!

Let’s take the example of DB2, a database present on an Exchange Server 2013 that I am trying to remove and am getting the error:

As suggested by the error message, I verified for the presence of all sorts of possible mailboxes one can create, namely normal user mailboxes, arbitration mailboxes, public folder mailboxes and archive mailboxes.

Checking for regular mailboxes reveals nothing:

Checking for Archive mailboxes reveals nothing:

Checking for public folder mailboxes reveals, you guessed it, nothing:

Finally, checking for Arbitration mailboxes gives similar results:

Still, the removing mailbox database continues failing with same error. What to do? Do I need a flamethrower?

If you are using Exchange 2013, you can use the Remove-MailboxDatabase as it indicates the DN of the user that still has mailbox on the database, but only when -Verbose parameter is specified. Like so:

If you do not have Exchange Server 2013, don’t despair…

Another possibility is that the database you’re trying to remove is an Archive Database for a mailbox residing on a different mailbox database.

The following command helps you list mailboxes using a specific database as Archive Database:

Get-Mailbox | where {$_.ArchiveDatabase -eq "<databaseName>"}

Here’s the output from my example:

Aha! Mystery solved! So, I just moved the archive mailbox to another database:

…And the database could now be removed after the move was complete.

We realize that the experience here is not ideal and the relevant team is aware. In the meantime, hope this helps some of you.

Bhalchandra Atre

Just over a year ago on March 8, 2013 the first version of OffCAT was released. In the 12 months that followed, the OffCAT team released a new version (v1.1), published numerous rule file updates that included over 260 new detection rules and over 250 bug fixes/feature improvement. And now with over 100,000 customer downloads under our belts, we have released the very latest version (v1.2).

There are many new features, diagnostic rules, and fixes in OffCAT v1.2, and we hope you will quickly install v1.2 to see what has been added.

Symptoms-based issue report

To improve the usability of the report containing the list of detected issues, the default report view is now arranged by symptom. Every issue that could be detected by OffCAT was tagged with 1 or more symptoms so you can quickly find relevant issues.

If you want to just see the symptoms closest to those reported by your customer, click the Filter control to enable/disable the symptoms you want shown in the report.

To quickly turn off the filter, click the ‘undo’ Filter control.

Link to open the CalCheck.log file

If there are issues found by CalCheck during a scan, the scan report will contain an ‘Open CalCheck log’ link if the CalCheck.log file is found in the %Temp% folder. This will allow you to quickly review additional details on problem meetings found only in the CalCheck.log file.

Office Alerts

At the bottom of the Scan page is a new space dedicated to important news items all customers should see. This will help keep customer informed about updates, breaking news, support lifecycles, etc.

These alerts function just like issues shown in the OffCAT report – click on an alert to see an expanded description and a link to an article that provides more details.

KMS client activation toolbox

The Scan page also includes a ‘KMS client activation’ link that will take you to a new section of OffCAT that provides a large array of tools for troubleshooting KMS client activation issues.

This link takes you to the new KMS Client screen where you can solve just about every known KMS activation problem.

Why run Ospp.vbs when you can get the same information, and more, using the convenient UI provided by OffCAT.

Export to .zip

If you are reviewing OffCAT scans from other users you will probably want them to use this new export option as their OffCAT results may contain errors or warnings for issues found by CalCheck. These errors and warnings refer you to the CalCheck.log file and you will have this log file only if the user exported their OffCAT report using the .zip option.

Drag and drop support for importing scans

Don’t bother clicking ‘Import scan’ and then browsing for the .xml file you want to review, just drag and drop it onto the ‘View or Import Scan’s screen to see the report in seconds. We think this will be a time-saver for people that import scans on a regular basis.

Improved scan management

To help you keep a large list of scans manageable, the ‘View or Import Scan’s screen has added several new features: searchable scan list, one-click delete, and multi-select controls (to improve scan deletion).

• Searchable scan list

If you have a large list of scans on the View or Import Scans page, search for them using the search box to the left of the magnifying glass icon.

• One-click delete

Hover over any scan in the list on the View or Import Scans screen and then click the red ‘X’ on the far right to delete the scan with one click.

• Multi-select controls

In earlier versions of OffCAT your options for deleting scans were either one-by-one or ‘Delete all’. In OffCAT v1.2 you can select one or more scans in the list using the control to the left of each scan and then click ‘Delete selection’ to delete the selected items.

Updated list of resources for Office 365 users

Click the Office 365 Resources link in the left panel to see the updated list of most useful resources for troubleshooting Office 365 issues.

For complete details on all the new features, please check out the updated ReadMe file that is in the \Microsoft OffCAT folder or on the Download site.

Installing OffCAT v1.2

As in earlier versions of OffCAT, there are two ways to install v1.2 from the Microsoft Download site.

• OffCAT.msi
• OffCAT 1.1.zip

OffCAT.msi

Most people install OffCAT using the OffCAT.msi file from the Microsoft Download site. If you installed OffCAT v1.0 or v1.1 this way, here is the quickest way to install OffCAT v1.2:

1. Start your currently installed version of OffCAT.

2. When you see the following prompt (assuming you have ‘Check for updates on startup’ enabled), select the ‘Update the tool in place’ option.

If you do not see this prompt, click OffCAT Updates in the left panel of OffCAT and then click ‘Check for updates now’.

The OffCAT.msi file from the Microsoft Download site will be downloaded and launched, ready for you to complete the installation.

The setup process for OffCAT v1.2 automatically removes earlier versions of OffCAT, so there’s no need to remove OffCAT before updating to v1.2.

3. Then, after the update is finished, launch OffCAT from the shortcut on the Start menu/screen.

OffCAT.zip

If you ‘installed’ an earlier version of OffCAT by extracting the files included in the .zip file download, you can use the following steps to get OffCAT v1.2 onto your computer.

1. Locate and delete the folder containing the OffCAT files extracted from the earlier version .zip file.

2. Go to the OffCAT download page and then select OffCAT.zip when prompted to select your download file(s).

3. Extract the files from OffCAT.zip into a new folder.

4. Launch OffCAT v1.2 using OffCAT.exe in this new folder.

Command-line version of OffCAT

If you do not want users to manually run OffCAT you still to have the option to scan their computers by running the command-line version of OffCAT (OffCATcmd.exe).

All of the command-line switches for OffCATcmd.exe are fully documented (with examples) in the ReadMe_OffCATv1.2.docx file.

Group policies for OffCAT

OffCAT v1.2 continues support for group policy management over the features most people want to control in a company setting. If you are already using the group policy template from OffCAT v1.1, you do not need to make any changes. However, if you are using the group policy template from OffCAT v1.0 or you are not currently using OffCAT polices, please download OffCATv12.adm from the OffCAT page on the Microsoft Download Center.

All of the policies available for OffCAT are fully documented in the ReadMe_OffCATv1.2.docx file.

OffCAT v1.2 documentation

The Microsoft Download site also provides a download for a complete user's guide on OffCAT tool. It is highly recommended you read this document before installing and using the OffCAT tool:

OffCAT ReadMe (ReadMe_OffCATv1.2.docx)

Note: You do not have to download the ReadMe from the Download site as it is included in the OffCAT.msi installation and the OffCAT.zip file. However, if you want to read the documentation before installing OffCAT, then you can download it.

Greg Mansius

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

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

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

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

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

Scenario 1

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

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

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

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

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

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

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

Scenario 2

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

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

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

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

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

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

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

Scenario 3

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

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

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

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

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

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

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

Conclusion

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

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

When you're migrating on-premises mailboxes to Office365, there are a lot of factors that can impact overall mailbox migration speed and performance. This post will help you investigate and correct the possible causes by using the AnalyzeMoveRequestStats.ps1 script to analyze the performance of a batch of move requests to identify reasons for slower performance.

The AnalyzeMoveRequestStats script provides important performance statistics from a given set of move request statistics. It also generates two files - one for the failure list, and one for individual move statistics.

Step 1: Download the script and import using the following syntax

> . .\AnalyzeMoveRequestStats.ps1

Step 2: Select the move requests that you want to analyze

In this example, we’re retrieving all currently executing requests that are not in a queued state.

> $moves = Get-MoveRequest | ?{$_.Status -ne 'queued'}

Step 3: Get the move reports for each of the move requests you want to analyze

Note: This make take a few minutes, especially if you’re analyzing a large number of moves

> $stats = $moves | Get-MoveRequestStatistics –IncludeReport

Step 4: Run the ProcessStats function to generate the statistics

> ProcessStats -stats $stats -name ProcessedStats1

The output should look similar to the following:

StartTime:    2/18/2014 19:57
EndTime:    3/3/2014 17:15
MigrationDuration:    12 day(s) 19:10:55
MailboxCount:    50
TotalGBTransferred:    2.42
PercentComplete:    95
MaxPerMoveTransferRateGBPerHour:    1.11
MinPerMoveTransferRateGBPerHour:    0.43
AvgPerMoveTransferRateGBPerHour:    0.66
MoveEfficiencyPercent:    86.36
AverageSourceLatency:    123.55
AverageDestinationLatency:   
IdleDuration:    1.16%
SourceSideDuration:    78.93%
DestinationSideDuration:    19.30%
WordBreakingDuration:    9.63%
TransientFailureDurations:    0.00%
OverallStallDurations:    4.55%
ContentIndexingStalls:    1.23%
HighAvailabilityStalls:    0.00%
TargetCPUStalls:    3.32%
SourceCPUStalls:    0.00%
MailboxLockedStall:    0.00%
ProxyUnknownStall:    0.00%

How to read the results

The first step in understanding the results are to understand the definitions of the report items:

Next, you need to identify which side of the migration components is slower by looking at the SourceSideDuration and DestinationSideDuration values.

Note: The SourceSideDuration value + DestinationSideDuration value is usually, but not always, equal to 100%.

If you see that the SourceSideDuration value is greater than the normal range of 60-80%, this means the source side is the bottleneck. If the DestinationSideDuration value is greater than the normal 20-40%, this means the destination side of the migration is the bottleneck

Causes of source side slowness in onboarding scenarios

There are several possible reasons the source side of the migration in an onboarding scenario may be causing slower than normal performance.

High transient failures

Most common reason for transient failures is the connectivity issue to the on-premises MRSProxy web service on your Mailbox servers. Check the TransientFailureDurations and MailboxLockedStall values in the output and also check the failure log generated by this script to verify any failures. The source mailbox may also get locked when a transient failure occurs and this will lower migration performance.

Misconfigured network load balancers

Another common reason for connectivity issues are misconfigured load balancers. If you're load balancing your servers, the load balancer needs to be configured so that all calls for a migration specific request is directed to the same server hosting the MRSProxy service instances.

Some load balancers use the ExchangeCookie to associate all the migration requests to the same Mailbox server where the MRSProxy service is hosted.

If your load balancers are not configured correctly, migration calls may be directed to the “wrong” MRSProxy service instance and will fail. This causes the source mailbox to be locked for some time and lowers migration performance.

High network latency

The Office 365 MRSProxy service makes periodic dummy web service calls to the on-premises MRSProxy service and collects statistics from these calls. The AverageSourceLatency value represents the average duration of these calls. If you see high values for this parameter (greater than 100ms), it can be caused by:

Network latency between the Office 365 and on-premises MRSProxy services is high

In this case, you can try to reduce the network latency by

1. Migrate mailboxes from servers closer to Office 365 datacenters. This is usually not feasible, but can be preferred if the migration project is time critical.
2. Delete empty mailbox folders or consolidate mailbox folders. High network latency affects the move rate more if there are too many folders.
3. Increase the export buffer size. This reduces the number of migration calls, especially for larger mailboxes and reduces the time spent in network latency. You can increase the export buffer size by modifying the ExportBufferSizeOverrideKB parameter in the MSExchangeMailboxReplication.exe.config file

Example: ExportBufferSizeOverrideKB="7500"

Important: You need to have Exchange 2013 SP1 installed on your Client Access server to increase the export buffer size. This will also disable cross forest downgrade moves between Exchange 2013 and Exchange 2010 servers.

Source servers are too busy and not very responsive to the web service calls

In this care you can try to release some of the system resources (CPU, Memory, Disk IO etc.) on the Mailbox and Client Access servers.

Scale issues

The resource consumption on the on-premises Mailbox or Client Access servers may be high if you're not load balancing the migration requests or you're running other services on the same servers. You can try distributing the source mailboxes to multiple Mailbox servers and moving mailboxes to different databases located on separate physical hard drives.

Causes of destination side slowness in onboarding scenarios

There are several possible reasons the destination side of the migration in an onboarding scenario may be causing slower than normal performance. Since the destination side of the migration is Office 365, there are limited options for you to try to resolve bottlenecks. The best solution is to remove the migration requests and re-insert them so that migration requests are assigned to less busy Office 365 servers.

Office 365 system resources: This is likely due to insufficient system resources in Office 365. Office 365 destination servers may be too busy with handling other requests associated with normal support of services for your organization.

Stalls due to word breaking: Any mailbox content that is migrated to Office365 is separated into individual words so that it can be indexed later on. This is performed by the Office 365 search service and coordinated by the MRS service. Check the WordBreakingDuration values to see how much time is spent in this process. If it's more than 15%, it usually indicates that the content indexing service running on the Office 365 target server is busy.

Stall due to Content Indexing: Content indexing service on the Office 365 servers is too busy.

Stall due to High Availability: High availability service that is responsible to copy the data to multiple Office 365 servers is too busy.

Stall due to CPU: The Office 365 server's CPU consumption is too high.

Karahan Celikel and the Migration Team

Greetings from downtown Austin, where Microsoft Exchange Conference (MEC) 2014 is now underway. Since attendees started rolling into town on Saturday, local bars and restaurants have been full of the sounds of Exchange: conversations about load balancing, debates EAC vs. PowerShell, and tales of MEC legends and lore.

This year’s MEC follows our tried and true recipe: find a great host city, bring tons of people from the product team, and add customers, partners, and MVPs. Mix them all together, add beverage and music, and all involved can savor the strange concoction that results.

This morning Julia White hosted our keynote session, which featured top engineering leaders discussing the future of Exchange. Jeff Teper explained how we are transforming Office and Exchange by leveraging the power of the cloud, enterprise social, mobile and big data. Kristian Andaker talked about how we are extending compliance and security capabilities across the Office suite. Harv Bhela showed off the ways that email is becoming more social, intelligent, and mobile-focused. Perry Clarke wrapped things up by answering questions about our new software release process and giving us his predictions for the future.

During the keynote we announced and demonstrated several new features including codename "Clutter," new methods of document collaboration, and OWA for Android phone. You can read all about the features we unveiled in this blog post about the evolution of email.

If you couldn’t make it to MEC in person this time, you haven’t completely missed out. We’ll post recordings of the keynote and breakout sessions for public viewing in about a month. In the meantime, you can follow the action on Twitter at #iammec, and enjoy these short video clips from today’s keynote:

Innovation Lab - Greg Taylor and David Espinoza show us the research facility where the Exchange team cooks up new features:

Ex Ed - As social concepts come to email, some users may have questions. This educational film is designed to help them understand their changing world:

Secret Switch - When an Exchange admin moves his company’s email servers to Office 365, will end users notice?

Jon Orton

This week at MEC, we’ve been talking a lot about the power of the Office graph, and how it helps us deliver personalized and proactive experiences for email users. As part of that journey, we’re excited to announce an advanced predictive email assistance feature coming to Exchange. This exciting technology leverages big-data and machine-learning capabilities to enable users to create routine emails and responses more efficiently.

Research has shown that most business emails in an organization follow identifiable patterns. In a law office, for example, an attorney may write dozens of routine follow-up emails to similar questions from his clients. Convention requires that every email be created from scratch. Now, Exchange will begin to recognize the type of email he is creating and offer assistance completing it.

The new virtual intelligence engine examines a user’s individual emailing patterns, and uses machine learning to detect when a received message resembles a set of emails that have been previously sent.

To unlock the power of this technology for users, we’ve also created a friendly in-product persona that will appear and offer a pre-written email based on the accumulated learnings from previous emails and information based on ranked keywords from the email chain.

Developed under the code name “Green”, email network virtual intelligence (ENVI) is a key part of our vision for a smarter, more tailored inbox experience.

Let’s take a closer look at how ENVI works. Back in our attorney’s office, the attorney begins to respond to a client’s question about a specific rule in that state’s building wastewater disposal statutes. ENVI leverages the Office Graph and the Microsoft Clustering algorithm to recognize that the email the attorney is starting meets the parameters of similar emails he has sent in the past. The friendly envelope character appears onscreen and offers a completed email borrowing from prose the attorney has written repeatedly in similar responses. Our attorney quickly and easily accepts ENVI’s draft and hits send, saving him valuable minutes of his day.

Preliminary testing of this feature in our Early Adopter Program has been phenomenally successful. With more than 2000 participants involved, ENVI reports showed an average email auto-generation success rate of 86.357%. This translates to nearly 17 minutes per day (or 6205 minutes per year) for each user.

We will begin rolling out the ENVI update to on-premises Exchange customers this afternoon. Office 365 customers will be able to download the update later this year for $.99 (Canadian version of dollars) per email per user per month. Initially ENVI will only be available in English and Australian with all other languages and Wingdings* being available early next year.

*Wingdings 3 not supported in Texas or space. Happy April 1^st

The Exchange Team

The bands are silent, the booths are dismantled, the R/C racecars are quiet, and Squeaky Lobster has left the building. Microsoft Exchange Conference 2014 is officially done. As we head home stuffed with Exchange knowledge and barbeque brisket, we thought we’d give you a brief photo sampling of the fun, selected from the full gallery at iammec.com.

The Exchange museum included a must-see documentary about the past, present, and future of Exchange, along with plenty of original artifacts and exhibits:

(click for larger version)

We took over historic Rainey Street, an eclectic collection of homes converted to bars in downtown Austin, for an old-fashioned block party.

And, of course, we made new friends and had intense discussions about Exchange in between sessions, at MAPI hour, and all week long.

For those who couldn’t make it to Austin, you can search #iammec on Twitter to see what you missed, and follow the #iammec community conversation all year round. Session recordings and decks will be posted for everyone in about a month, and the Office Garage series from the MEC show floor will be out soon.

Jon Orton

With the release of Exchange 2013 SP1, it’s time to revise our sizing guidance given feedback from customers, observations from our own large-scale deployments, and requirements associated with new and changed components in SP1. In addition to this brief article, I’ve also updated the original blog post with updated formulas and tables to reflect the changes described here.

There are two specific changes that need to be highlighted:

CAS Processor Sizing

With the introduction of the MAPI/HTTP protocol, our existing sizing guidance for CAS processor utilization needs to be changed. Usage of MAPI/HTTP has a fairly dramatic increase in rate of requests handled by the CAS role, when compared to requests generated by clients using RPC/HTTP. As each connection has a measurable amount of processing overhead, this results in an overall increase to our CPU requirements on CAS, moving from a 1:4 ratio of CAS to Mailbox processor cores, to a 3:8 ratio (a 50% increase). It’s important to call out that MAPI/HTTP is disabled by default, as we expect that customers will want to carefully evaluate the deployment requirements and impact of MAPI/HTTP before enabling it. Because it is disabled by default, existing Exchange 2013 deployments do not need to immediately add more CPU resources at the CAS layer. Instead, we expect that additional capacity will be considered as part of the evaluation and deployment process for MAPI/HTTP. We do anticipate that over time it will become the standard method of connectivity for Outlook clients so it’s important to include these requirements in our sizing guidance as early as possible.

It’s also critical to deploy .NET Framework 4.5.1 if you intend to use MAPI/HTTP, as it contains an important fix that impacts the performance and scalability of MAPI/HTTP at the CAS layer.

Ross has updated the Exchange Server 2013 Server Role Requirements Calculator to take into account this guidance change in version 6.3.

Pagefile Sizing

As memory requirements have increased for Exchange, our historical guidance for sizing the pagefile has become more and more challenging from a deployment perspective. Previously, our guidance was to set a fixed pagefile size equal to the size of RAM + 10MB. On servers that are commonly deployed with 128GB of RAM or more, requiring a pagefile sized to RAM+10MB results in a large amount of space consumed (typically on the system drive) with questionable benefit. In our large-scale internal deployments, we have been running with a cap on pagefile size for quite some time, and as a result we are comfortable recommending that all of our on-premises customers follow that same guidance. Moving forward with Exchange 2013, we recommend a fixed pagefile of the smaller of RAM size + 10MB or 32,778 MB (which is 32GB + 10MB). Hopefully this will free up some needed space on your servers.

As we continue to learn more from customer feedback and monitoring of our own deployments, we will keep updating this guidance via posts to the blog.

Jeff Mealiffe
Principal Program Manager Lead
Exchange Customer Experience

Do your users want to share their calendar with anonymous users? Here's a tip related to sharing your calendar via a web link for anonymous users (users outside of your organization). Users can publish their calendar for anonymous viewers using OWA. Organization administrators can also publish a user's calendar. Here we will share both of those ways.

Note: Publishing your calendar for anonymous users allows anyone with the link to the calendar to view it without having to log-on.

Publish your calendar using OWA

1. Publishing your calendar: Log on to OWA and go to Calendar. Right click the calendar you want to share and choose permissions:

   Change the permissions drop-down from “Not Shared” (Default) to “Availability only” (or whichever permission you intend to grant) and press Save:

2. Retrieve the link to share it with users outside of your organization: Right click Calendarpermissions> and then View Calendar. This will bring up a browser window with the sharing link (URL). You can also right click on the View Calendar link and then select Copy Shortcut to get copy the link. You can send the link to users outside your organization to allow them to view your calendar

Publish a user's calendar (as an organization administrator):

If you're an organization admin, here's how you can publish the calendar of a user or a resource/room using PowerShell.

1. Run Set-MailboxCalendarFolder <Username>:\Calendar -PublishEnabled $true
2. Run Get-MailboxCalendarFolder <Username>:\Calendar |fl or Get-MailboxCalendarFolder <Username>:\calendar |fl publishedcalendarurl. This will output the published calendar html (and ics) urls. Others can use this url to view the publisher’s calendar.

Example:

PS C:\Windows\system32> set-MailboxCalendarFolder calroom1:\calendar -PublishEnabled:$true
PS C:\Windows\system32> Get-MailboxCalendarFolder calroom1:\calendar
RunspaceId           : 0f40e5da-5712-4043-8bbc-fb11049c0307
Identity             : calroom1:\calendar
PublishEnabled       : True
PublishDateRangeFrom : ThreeMonths
PublishDateRangeTo   : ThreeMonths
DetailLevel          : AvailabilityOnly
SearchableUrlEnabled : False
PublishedCalendarUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com
/5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.html
PublishedICalUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com
/5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.ics
IsValid              : True
ObjectState          : Unchanged

For more on other calendar sharing options in Exchange Online, please look at thispage.

Sathish Venkat Rangam

Updates

• 4/15/2014: Added section about sharing policies.

We’re happy to announce updates to the Exchange Server Deployment Assistant! These updates offer you more deployment options and outline new features that make deployments more flexible and easier to configure.

We’ve updated the Deployment Assistant to include the following:

• Support for the Exchange 2013 Edge Transport server role in all on-premises and hybrid deployment scenarios
• Support for the new, automated process for requesting an Exchange 2013 or Exchange 2010 Hybrid Edition product key

New in Exchange 2013 SP1, Edge Transport servers minimize the attack surface by handling all Internet-facing mail flow, which provides SMTP relay and smart host services for your Exchange organization, including connection filtering, attachment filtering and address rewriting. For more information, see Edge Transport Servers.

Also newly released, you can now use the new product key wizard to submit your request to Microsoft Support to obtain an Exchange 2013 or Exchange 2010 product key for use in hybrid deployments. The request process is quick and easy and you’ll have your product key in minutes!

You can request a Hybrid Edition product key if all the following conditions apply to you:

• You have an existing, non-trial, Office 365 Enterprise subscription
• You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 servers in your on-premises organization
• You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the Hybrid Edition product key

And, there’s even more on the way!

We’re working hard on testing and adding new deployment scenarios to support configuring hybrid deployments with an Office 365 tenant and multi-forest on-premises Exchange organizations. We’ll start by supporting scenarios for multi-forest Exchange 2010 organizations that add Exchange 2013 SP1 servers for hybrid support, and then follow with scenarios supporting for native multi-forest Exchange 2013 and Exchange 2007 organizations. Keep checking back here for release announcements.

In case you're not familiar with it, the Exchange Server Deployment Assistant is a free web-based tool that helps you deploy Exchange 2013 or Exchange 2010 in your on-premises organization, configure a hybrid deployment between your on-premises organization and Office 365, or migrate completely to Office 365.

The tool asks you a small set of simple questions and then, based on your answers, creates a customized checklist with instructions to deploy or configure Exchange Server. Instead of trying to find what you need in the Exchange library, the Deployment Assistant gives you exactly the right information you need to complete your task. Supported on most major browsers, the Deployment Assistant is your one-stop shop for deploying Exchange.

Do you have a deployment success story about the Deployment Assistant? Do you have suggestions on how to improve the tool? We would love your feedback and comments! Feel free to leave a comment here, or send an email to edafdbk@microsoft.com directly or via the 'Feedback' link located in the header of every page of the Deployment Assistant.

Happy deploying!

The Deployment Assistant Team

During my session at the recent Microsoft Exchange Conference (MEC), I revealed Microsoft’s preferred architecture (PA) for Exchange Server 2013. The PA is the Exchange Engineering Team’s prescriptive approach to what we believe is the optimum deployment architecture for Exchange 2013, and one that is very similar to what we deploy in Office 365.

The PA is designed with several business requirements in mind. For example, requirements 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 an architecture different from that shown here. 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 where possible, 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.

Before I delve into the PA, I think it is important that you understand a concept that is the cornerstone for this architecture – simplicity.

Simplicity

Failure happens. There is no technology that can change this. Disks, servers, racks, network appliances, cables, power substations, generators, operating systems, applications (like Exchange), drivers, and other services – there is simply no part of an IT services offering that is not subject to failure.

One way to mitigate failure is to build in redundancy. Where one entity is likely to fail, two or more entities are used. This pattern can be observed in Web server arrays, disk arrays, and the like. But redundancy by itself can be prohibitively expensive (simple multiplication of cost). For example, the cost and complexity of the SAN based storage system that was at the heart of Exchange until the 2007 release, drove the Exchange Team to step up its investment in the storage stack and to evolve the Exchange application to integrate the important elements of storage directly into its architecture. We recognized that every SAN system would ultimately fail, and that implementing a highly redundant system using SAN technology would be cost-prohibitive. In response, Exchange has evolved from requiring expensive, scaled-up, high-performance SAN storage and related peripherals, to now being able to run on cheap, scaled-out servers with commodity, low-performance SAS/SATA drives in a JBOD configuration with commodity disk controllers. This architecture enables Exchange to be resilient to any storage related failure, while enabling you to deploy large mailboxes at a reasonable cost.

By building the replication architecture into Exchange and optimizing Exchange for commodity storage, the failure mode is predictable from a storage perspective. This approach does not stop at the storage layer; redundant NICs, power supplies, etc., can also be removed from the server hardware. Whether it is a disk, controller, or motherboard that fails, the end result should be the same, another database copy is activated and takes over.

The more complex the hardware or software architecture, the more unpredictable failure events can be. Managing failure at any scale is all about making recovery predictable, which drives the necessity to having predictable failure modes. Examples of complex redundancy are active/passive network appliance pairs, aggregation points on the network with complex routing configurations, network teaming, RAID, multiple fiber pathways, etc. Removing complex redundancy seems unintuitive on its face – how can removing redundancy increase availability? Moving away from complex redundancy models to a software-based redundancy model, creates a predictable failure mode.

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 2013. From a namespace perspective, 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 unbound model, deploying a single 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

Figure 1: Namespace Design

Each namespace is load balanced across both datacenters in a 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 DNS round-robin, geo-DNS, or other similar solution you may have at your disposal. Though from our perspective, the simpler solution is the least complex and easier to manage, so our recommendation is to leverage DNS round-robin.

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 pair 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.

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 having 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, multi-role servers. Physical hardware is deployed rather than virtualized hardware for two reasons:

1. The servers are scaled to utilize eighty percent 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, as Exchange provides equivalent functionality out of the box.

By deploying multi-role servers, the architecture is simplified as all servers have the same hardware, installation process, and configuration options. Consistency across servers also simplifies administration. Multi-role servers provide more efficient use of server resources by distributing the Client Access and Mailbox resources across a larger pool of servers. Client Access and Database Availability Group (DAG) resiliency is also increased, as there are more servers available for the load-balanced pool and for the DAG.

Commodity server platforms (e.g., 2U servers that hold 12 large form-factor drive bays within the server chassis) are use in the PA. 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). Bitlocker is used to encrypt each disk, thereby providing data encryption at rest and mitigating concerns around data theft via 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 (calculated in the Exchange 2013 Server Role Requirements Calculator) ensures that there is no more than a single copy activated per-disk.

Figure 2: Server Design

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 provides two benefits:

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

Each datacenter is symmetrical, with an equal number of member servers within a DAG residing in each datacenter. This means that each DAG contains an even number of servers and uses a witness server for quorum arbitration.

The DAG is the fundamental building block in Exchange 2013. 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) and only create new DAGs when scalability introduces concerns over the existing database copy layout.

DAG Network Design

Since the introduction of continuous replication in Exchange 2007, Exchange has recommended multiple replication networks for separating client traffic from replication traffic. Deploying two networks allows you to isolate certain traffic along different network pathways and ensure that during certain events (e.g., reseed events) the network interface is not saturated (which is an issue with 100Mb, and to a certain extent, 1Gb interfaces). However, for most customers, having two networks operating in this manner was only a logical separation, as the same copper fabric was used by both networks in the underlying network architecture.

With 10Gb networks becoming the standard, the PA moves away from the previous guidance of separating client traffic from replication traffic. A single network interface is all that is needed because ultimately our goal is to achieve a standard recovery model despite 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 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.

Figure 3: DAG (Three Datacenter) Design

If your organization does not have a third location, then 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) 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. This feature ensures that the lagged database copy can be automatically played down and made highly available in the following scenarios:

• When a low disk space threshold is reached
• When the lagged copy has physical corruption and needs to be page patched
• When there are fewer than three available healthy copies (active or passive) for more than 24 hours

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.

Summary

The PA takes advantage of the changes made in Exchange 2013 to 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

A few weeks ago we wrapped up MEC 2014 in Austin, TX with the farewell Austin post. Today we are happy to announce that the MEC 2014 keynote and breakout sessions are published on Channel 9. This includes the latest content on Exchange foundational topics and the latest features including groups, and many more. The conference provides content for both Exchange on-premises and Office 365 customers. If you missed the event in person, begin by watching the MEC 2014 keynote to get you up to speed on the latest initiatives the Exchange engineering team is working on plus a segment with Perry Clarke.

MEC isn’t just an event but also a community. Keep active in Twitter using the #IamMEC community hashtag and join us in the Office 365 IT Pro Network to engage in Exchange conversations in the Exchange IT Pro group. Enjoy the MEC 2014 sessions.

Brian Shiers
Technical Product Manager | Exchange

With the huge scale environment I currently work in my team has had some difficulty when it comes to validating customer transport changes, specifically when adding new send connectors or new smart hosts. The same goes for troubleshooting mail flow….you know…whip out good ole’ Telnet, check SMTP status manually and then go on from there. What happens when security bans Telnet? What happens when you have 40 transport servers that you need to validate against 20 - 30 smart hosts over multiple connectors? Or you have a gazillion address spaces over a gazillion send connectors….you need some way of automating the checks to help you with troubleshooting if you need to, or validate a transport change when you make changes to send connectors.

Well, let me introduce a very simple, yet efficient tool I branded PelNet…..yes, that’s my take on PowerShell Telnetting :-)

So, let’s see what this baby can do.

Before I get into the usages, let’s talk about the parameters the script accepts:

• AddressSpace: Which AddressSpace should the script look for in the Send Connectors?
• sendConnector: Specify if you want the scope to be a single Send Connector.
• SourceTransportServers: Accepts comma separated list of transport servers to test from.
• smartHost: The smarthost you want to test against. Accepts comma separated list value.
• mailSubmissionTest: Use this switch if you want the script to submit the mail to the mailbox. If you omit the parameter the script will skip the DATA portion of the SMTP verb.
• From: From address (test@fromdomain.com)
• Rcpt: Recipient Address (target@targetdomain.com)
• LogFolderPath: Log file and report location, default will be current path if not specified.
• Port: Default is 25, but you can specify a custom port if you need to.

Requirements

1. You need to run this from a machine that has the Exchange management tools installed. Certain parameter combinations don’t require EMS; however, the tool will automatically load the Exchange Server PowerShell snap-in, if it’s required.
2. Remote PowerShell needs to be configured so that the script is able to remote execute on the transport servers. See here.

The logic is simple: Depending on what parameters you specify, the script will validate accordingly and give you a nice CSV output that you can use to check the SMTP status codes for each server.

Script Execution Examples

Show the full help with examples

Get-help .\pelnet.ps1 –full

Let’s say you want to test your 50 transport servers against a new smarthost that needs to be added to a send connector soon.

.\PelNet.ps1 -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com

Test all source transport servers in all send connectors with a specific address space against a specific smarthost.

.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com

Test all send connectors with a specific address space against a multiple smarthosts on a custom port.

.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com –smarthost smarthost.domain.com –port 25070

Test every send connector with a specific address space against all the smarthosts in those send connectors.

.\PelNet.ps1 –addressSpace contoso.com -From test@domain.com -Rcpt user@contoso.com

Test all source transport servers against all smarthosts in a sendconnector.

.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –sendConnector Outbound_Contoso

Test a specific address space from all source transport servers to all smarthosts in all send connectors (bear in mind execution time here).

.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –addressSpace contoso.com

Test a specific address space from selected source transport servers to a smarthost and queue the mail for delivery.

.\PelNet.ps1 –From test@domain.com -Rcpt user@contoso.com –addressSpace contoso.com –sourceTransportServers EX15-01,EX15-02,EX15-03 -mailSubmissionTest

Script Output

Now that we covered the usage examples, let’s chat about the output.

The console output will look similar to the below screenshot. As you can see, this will show you on which transport server the tool is currently invoking the code.

The files that the tool will output is a log file and most importantly a comma separated value (.csv) file that contains the data you can use to get a holistic view of the situation you tested.

The csv file contains the following columns:

SmartHost,SendConnector,SMTPVerb,Status,TransportServer

Using the values in these columns you can determine if the server is accepting traffic or not.  Please note that the SendConnector column depends on the parameters you used.

End-To-End Example

Let’s take a look at an example. Let’s say I want to test connectivity to all smarthosts for the contoso.com address space in my organization (with a mail submission test).

.\PelNet.ps1 –From Michael.Hall@uclabz.com -Rcpt user@targetdomain.com –addressSpace Contoso.com -mailsubmissiontest

Within the BLUEbox you’ll notice the status responses and return string back from the server.

Within the REDbox, if a remote smarthost is not accepting traffic on the port you’re trying to connect to or not reachable, you‘ll get a status and ReturnString value of CONN_ERROR.

Finally in the GREEN box, the mailSubmissionTest switch was used so the tool tried to submit the test message for delivery. No response would be sent from the smarthost during the subject and content portion, thus the columns showing NULL.

It’s easy to filter on any of these columns and determine if you have a connectivity issue. You can also create a pivot table to get an overview of the results.

Summary

As you can see, this tool can be very powerful when you need to quickly test mail flow or validate a bunch of servers against a smart host or multiple smart hosts.

I hope this tool will help you, as always I’m open to any feedback or improvements.

Happy PelNetting….

Michael Hall
Service Engineer
Office 365

Among the many new features delivered in Exchange 2013 SP1 is a new method of connectivity to Outlook we refer to as MAPI over HTTP (or MAPI/HTTP for short). We’ve seen a lot of interest about this new connection method and today we’ll give you a full explanation of what it is, what it provides, where it will take us in the future, and finally some tips of how and where to get started enabling this for your users.

What is MAPI over HTTP?

MAPI over HTTP is a new transport used to connect Outlook and Exchange. MAPI/HTTP was first delivered with Exchange 2013 SP1 and Outlook 2013 SP1 and begins gradually rolling out in Office 365 in May. It is the long term replacement for RPC over HTTP connectivity (commonly referred to as Outlook Anywhere). MAPI/HTTP removes the complexity of Outlook Anywhere’s dependency on the legacy RPC technology. Let’s compare the architectures.

MAPI/HTTP moves connectivity to a true HTTP request/response pattern and no longer requires two long-lived TCP connections to be open for each session between Outlook and Exchange. Gone are the twin RPC_DATA_IN and RPC_DATA_OUT connections required in the past for each RPC/HTTP session. This change will reduce the number of concurrent TCP connections established between the client and server. MAPI/HTTP will generate a maximum of 2 current connections generating one long lived connection and an additional on-demand short-lived connection.

Outlook Anywhere also essentially double wrapped all of the communications with Exchange adding to the complexity. MAPI/HTTP removes the RPC encapsulation within HTTP packets sent across the network making MAPI/HTTP a more well understood and predictable HTTP payload.

An additional network level change is that MAPI/HTTP decouples the client/server session from the underlying network connection. With Outlook Anywhere connectivity, if a network connection was lost between client and server, the session was invalidated and had to be reestablished all over again, which is a time-consuming and expensive operation. In MAPI/HTTP when a network connection is lost the session itself is not reset for 15 minutes and the client can simply reconnect and continue where it left off before the network level interruption took place. This is extremely helpful for users who might be connecting from low quality networks. Additionally in the past, an unexpected server-side network blip would result in all client sessions being invalidated and a surge of reconnections being made to a mailbox server. Depending on the number of Outlook clients reconnecting, the re-establishing of so many RPC/HTTP connections might strain the resources of the mailbox server, and possibly extend the outage in scope (to Outlook clients connected to multiple servers) and time, caused by a single server-side network blip.

Why MAPI over HTTP?

You are probably asking yourself why the Exchange team would create a complete replacement for something so well-known and used. Let us explain.

The original Outlook Anywhere architecture wasn’t designed for today’s reality of clients connecting from a wide variety of network types – many of these are not as fast or reliable as what was originally expected when Outlook Anywhere was designed. Consider connections from cellular networks, home networks, or in-flight wireless networks as a few examples. The team determined the best way to meet current connection needs and also put Exchange in the position to innovate more quickly was to start with a new simplified architecture.

The primary goal of MAPI/HTTP is provide a better user experience across all types of connections by providing faster connection times to Exchange – yes, getting email to users faster. Additionally MAPI/HTTP will improve the connection resiliency when the network drops packets in transit. Let’s quantify a few of these improvements your users can expect. These results represent what we have seen in our own internal Microsoft user testing.

When starting Outlook users often see the message “Connecting to Outlook” in the Outlook Status bar. MAPI/HTTP can reduce the amount of time a user waits for this connection. In the scenario when a user first launches Outlook the time to start synchronization improved to 30 seconds vs. 90 seconds for Outlook Anywhere for 70% of the monitored clients.

Improvements are also delivered when clients are resuming from hibernation or simply re-connecting to a new network. Testing showed that 80% of the clients using MAPI/HTTP started syncing in less than 30 seconds vs. over 40 seconds for Outlook Anywhere clients when resuming from hibernation. This improvement was made possible as MAPI/HTTP implements a pause/resume feature enabling clients to resume using an existing connection rather than negotiating a new connection each time. Current sessions for MAPI/HTTP are valid for 15 minutes, but as we fine tune and expand this duration, these improvements will be even more noticeable.

Improvements aren’t limited to end users. IT administrators will gain greater protocol visibility allowing them to identify and remediate situations faster and with more confidence. Due to MAPI/HTTP moving to a more traditional HTTP protocol payload, the ability to utilize already known tools common to HTTP debugging is a reality. IIS and HttpProxy logs will now contain information similar to other HTTP based protocols like Outlook Web App and be able to pass information via headers. At times in the past, certain debug procedures for RPC/HTTP were only available via proprietary internal Microsoft tools. This move should put all customers on the same level playing field as far as what tools are available for debug purposes.

Exchange administrators also will find response returned by Autodiscover for MAPI/HTTP to Outlook is greatly simplified. The settings returned are just protocol version and endpoint URLs for Outlook to connect to Exchange mailbox and directory from inside or outside the customer’s corporate network. Outlook treats the URLs returned as opaque and uses as-is, minimizing the risk of connectivity breaking with future endpoint changes. Since MAPI/HTTP, like any other web protocol, simply sends an anonymous HTTP request to Exchange and gets back the authentication settings, there is no need for Autodiscover to advertise the authentication settings. This makes it easier to roll out changes in authentication settings for Outlook.

The future

MAPI/HTTP puts the Exchange team in position to innovate more quickly. It simplifies the architecture removing dependency on the RPC technologies which are no longer evolving as quickly as the customers demand. It provides the path for extensibility of the connection capabilities. A new capability that is on the roadmap for Outlook is to enable multi-factor authentication for users in Office 365. This capability is made possible with the use of MAPI/HTTP and is targeted to be delivered later this year. For a deeper look at this upcoming feature you can review the recent Multi-Factor Authentication for Office 365 blog post. This won’t stop with Office 365 MFA, but provides the extensibility foundation for 3^rdparty identity providers.

How does MAPI/HTTP work?

Let’s walk through the scenario of an Outlook 2013 SP1 client connecting to Exchange Server 2013 SP1 after MAPI/HTTP has been enabled.

1. The Outlook client begins with an Autodiscover POST request. In this request Outlook includes a new attribute that advertises the client is MAPI/HTTP capable with the attribute X-MapiHTTPCapability = 1.
2. The Exchange server sees the request is coming from a MAPI/HTTP capable client and responds with the MAPI/HTTP information including the settings on how to connect to the mailbox using MAPI/HTTP. This assumes the MAPI/HTTP has been configured and enabled on the server.
3. The Outlook client detects the new connection path and prompts the user to restart Outlook to switch to use the new connection. While the restart is pending Outlook will continue using Outlook Anywhere. We recommend you deploy the latest Office client updates to provide the best user experience. The updates remove the prompt and clients are allowed to make the transition at the next unprompted restart of Outlook.
4. After the restart, Outlook now uses MAPI/HTTP to communicate with Exchange.

What’s required?

So now we have a clear set of advantages you can offer users, let’s review the requirements to enable MAPI/HTTP.

Server Requirements: Use of MAPI/HTTP requires allExchange 2013 Client Access Servers to be updated to Exchange Server 2013 SP1 (or later). The feature is disabled by default in SP1 so you can get the servers updated without anyone noticing any changes. If you are an Office 365 Exchange Online customer you won’t have anything to worry about on the service side of deployment.

Client Requirements:Outlook clients must be updated to use MAPI/HTTP. Office 2013 SP1 or Office 365 ProPlus February update (SP1 equivalent for ProPlus) are required for MAPI/HTTP. It is recommend you deploy the May Office 2013 public update or the April update for Office 365 ProPlus to eliminate the restart prompt when MAPI/HTTP is enabled for users.

Prior version clients will continue to work as-is using Outlook Anywhere. Outlook Anywhere is the supported connection method for those clients. We do plan to add MAPI/HTTP support to Outlook 2010 in a future update. We will announce timing when we are closer to its availability.

How to get ready

Part one of getting ready is to get the required updates to your servers and clients as described in the prior section. Part two of getting ready is evaluating potential impacts MAPI/HTTP might have on your on-premises servers. Again if you an Office 365 customer you can ignore this bit.

When you implement MAPI/HTTP in your organization, it will have an impact on your Exchange server resources. Before you go any further you need to review the impacts to your server resources. The Exchange 2013 Server Role Requirements Calculatorhas been updated to factor in use of MAPI/HTTP. You need to use the most recent version of the calculator (v6.3 or later) before you proceed. MAPI/HTTP increases the CPU load in the Exchange Client Access Servers. This is a 50% increase over Exchange 2013 RTM, however it is still lower than Exchange 2010 requirements. As you plan be mindful that deploying in a multi-role configuration will minimize the impact to your sizing. Again use the calculator to review potential impacts this may have in your environment. This higher CPU use is due to the higher request rate with several short-lived connections, with each request taking care of authentication and proxying.

To provide the best MAPI/HTTP performance you need to install .NET 4.5.1 on your Exchange 2013 servers. Installing .NET 4.5.1 will avoid long wait times for users thanks to a fix to ensure the notification channel remains asynchronous to avoid queued requests.

The change in communication between Exchange and Outlook has a small impact on the bytes sent over the wire. The header content in MAPI/HTTP is responsible for an increase in bytes transferred. In a typical message communications we have observed an average packet size increase of 1.2% versus Outlook Anywhere for a 50 KB average packet. In scenarios of data transfers over 10 MB the increase in bytes over the wire is 5-10%. These increases assumes an ideal network where connections are not dropped or resumed. If you consider real world conditions you may actually find MAPI/HTTP data on the wire may be lower than Outlook Anywhere. Outlook Anywhere lacks the ability to resume connections and the cost of re-syncing items can quickly outweigh the increase from the MAPI/HTTP header information.

Now deploy MAPI/HTTP

Now that you have prepared your servers with SP1, updated your clients, and reviewed potential sizing impacts you are ready to get on with implementing MAPI/HTTP. It is disabled by default in SP1 and you must take explicit actions to configure and enable it. These steps are well covered in the MAPI over HTTPTechNet article.

A few important things to remember in your deployment.

• Namespace: MAPI/HTTP is a new endpoint on CAS and can utilize both an internal namespace and an external namespace. For more information on how to properly plan your namespace design, see Namespace Planning in Exchange 2013 and Load Balancing in Exchange 2013.
• Certificates: The certificate used in Exchange will need to include both the internal and external MAPI/HTTP virtual directories to avoid any user certificate prompts, thus consider if the names exist on your certificates. Refer to the certificate planning post for additional help planning.
• MAPI/HTTP Configuration: Enabling MAPI/HTTP is an organizational configuration in Exchange, you won’t have the ability configure this for a subset of servers. If you require more specific control you can control the client behavior with a registry key.

NOTE: If you require more specific control you can control the client behavior with a registry key on each client machine. This is not recommended or required but included if your situation demands this level of control. This registry entry prevents Outlook from sending the MAPI/HTTP capable flag to Exchange in the Autodiscover request. When you change the registry key on a client it will not take effect until the next time the client performs an Autodiscover query against Exchange.

To disallow MAPI/HTTP and force RPC/HTTP to be used.

HKEY_CURRENT_USER\Software\Microsoft\Exchange]
“MapiHttpDisabled”=dword:00000001

To allow MAPI/HTTP simply delete the MapiHttpDisabled DWORD, or set it to a value of 0 as below.

HKEY_CURRENT_USER\Software\Microsoft\Exchange]
“MapiHttpDisabled”=dword:00000000

• Connectivity: An important final consideration is to verify load balancers, reverse proxies, and firewalls are configured to allow access to the MAPI/HTTP virtual directories. At this time ForeFront Unified Access Gateway (UAG) 2010 SP4 is not compatible with MAPI/HTTP. The UAG team has committed to deliver support for MAPI/HTTP in a future update.

How do I know it is working?

There are a few quick ways to verify your configuration is working as expected.

1. Test with the Test-OutlookConnectivity cmdlet

Use this command to test MAPI/HTTP connectivity:

Test-OutlookConnectivity -RunFromServerId Contoso -ProbeIdentity OutlookMapiHttpSelfTestProbe

This test is detailed in the MAPI over HTTPTechNet Article.

2. Inspect MAPI/HTTP server logs

Administrators can review the following MAPI/HTTP log files to validate how the configuration is operating:

3. Check Outlook connection status on clients

You can also quickly verify that the client is connected using MAPI/HTTP. The Outlook Connection status dialog can be launch by CTRL-right clicking the Outlook icon in the notification area and selecting Connection Status. Here are the few key fields to quickly confirm the connection is using MAPI/HTTP.

Summary

MAPI/HTTP provides a simplified transport and resulting architecture for Outlook to connect with Exchange. It enables improved user experiences to allow them faster access to mail and improves the resilience of their Outlook connections. These investments are the foundation for future capabilities such as multi-factor authentication in Outlook. It also helps IT support and troubleshoot client connection issues using standard HTTP protocol tools.

As with all things new you must properly plan your implementation. Use the deployment guidanceavailable on TechNet and the updated sizing recommendations in the calculator before you start your deployment. With proper use it will guide you to a smooth deployment of MAPI/HTTP.

Special thanks to Brian Day and Abdel Bahgat for extensive contributions to this blog post.

Brian Shiers | Technical Product Manager

MAPI/HTTP FAQ

We collected a number of questions which frequently came up during the development, internal dogfooding, and customer TAPtesting of MAPI/HTTP. We hope these answer most of the questions you may have about MAPI/HTTP.

Can MAPI/HTTP be enabled/disabled on a per-server basis?

No, it is an organization-wide Exchange setting. The user experience mentioned during database failovers when one server is not yet MAPI/HTTP capable made the functionality to turn MAPI/HTTP on and off per server not a viable solution.

Can MAPI/HTTP be enabled/disabled on a per-mailbox basis?

No, there is not currently a Set-CasMailbox parameter to enable/disable MAPI/HTTP for a single mailbox.

I updated the registry key to disable MAPI/HTTP on a client but the connection didn’t change?

The registry entry simply controls what Outlook sends to Exchange about its MAPI/HTTP capability during an Autodiscover request. It does not immediately change the connection method Outlook is using nor will it change it with a simple restart of Outlook. Remember, the Autodiscover response Outlook gets only has MAPI/HTTP or RPC/HTTP settings in it so it has no way to immediately switch types. You must allow Outlook to perform its next Autodiscover request and get a response from Exchange after setting this registry entry before the change will take place. If you must attempt to speed along this process, there are two options.

1. Set the registry entry as you wish, close Outlook, delete the Outlook profile, and then restart Outlook and go through the profile wizard. This should result in an immediate switch, but any settings stored in the Outlook profile are lost.
2. Set the registry entry as you wish, close Outlook, delete the hidden Autodiscover response XML files in %LOCALAPPDATA%\Microsoft\Outlook, and restart Outlook.
3. Restart Outlook once more to complete the switch.

What happens if a user’s mailbox database is mounted on a MAPI/HTTP capable server and then a database failover happens to a non-MAPI/HTTP capable server?

E.g. When not all mailbox servers in a DAG are MAPI/HTTP capable and MAPI/HTTP has already been enabled in the organization, and then a mailbox failover takes place between the SP1 (or later) and pre-SP1 servers. Additionally this could happen if you move a mailbox from a MAPI/HTTP capable mailbox server to a server that is not MAPI/HTTP capable.

In the above example Outlook would fail to connect and when Autodiscover next ran the user would get an Outlook restart notification warning because MAPI/HTTP is no longer a viable connection method due to the mailbox being mounted on a pre-SP1 server. After the client restart the client profile would be back to utilizing RPC/HTTP.

Note: While a mix of MAPI/HTTP capable and non-capable mailbox Exchange servers in the same DAG are supported in an environment with MAPI/HTTP enabled, it is very strongly not recommended due to the possible user experience outlined above. It is suggested the entire organization be upgraded to SP1 or later before enabling MAPI/HTTP in the organization.

What if a user accesses additional mailboxes where MAPI/HTTP is not yet available?

Outlook profiles can continue access additional resources using non-MAPI/HTTP connectivity methods even if the user’s primary mailbox utilizes MAPI/HTTP. For example a user can continue to access Legacy Public Folders or Shared Mailboxes on other Exchange servers not utilizing MAPI/HTTP. During the Autodiscover process Exchange will determine and hand back to Outlook the proper connectivity method necessary for each resource being accessed.

If MAPI/HTTP becomes unreachable will a client fallback to RPC/HTTP?

No, a user’s profile will never attempt to use RPC/HTTP if MAPI/HTTP becomes unavailable because the original Autodiscover response only contained one connection method to use. There is no fallback from MAPI/HTTP to RPC/HTTP or vice versa. Normal high availability design considerations should ensure the MAPI/HTTP endpoint remain accessible in the event of server or service failures.

Is MAPI/HTTP replacing Exchange Web Services (EWS)?

No, MAPI/HTTP is not a replacement for EWS and there are no plans to move current EWS clients to MAPI/HTTP.

Is RPC/HTTP being deprecated as an available connection method?

Over time this may take place as non-MAPI/HTTP capable Outlook versions age out of their product support lifecycle, but there are no immediate plans to remove RPC/HTTP as a valid connection method.

What authentication methods does MAPI/HTTP support?

A huge architectural improvement by moving to MAPI/HTTP is that MAPI/HTTP is abstracted from authentication. In short authentication is done at the HTTP layer, so whatever HTTP can do, MAPI/HTTP can use.

Does moving the MAPI/HTTP negatively affect the Lync client at all?

No, the Lync client uses the same profile as configured by Outlook and will connect via whatever connectivity method is in use by Outlook.

Is there any kind of SDK/API for third party application usage of MAPI/HTTP?

The MAPI/HTTP protocol is publically documented (PDF download) and has the same level of documentation support as RPC/HTTP. There are no plans to update the MAPI CDO library for MAPI/HTTP and third party companies are still encouraged to utilize Exchange Web Services as the long-term protocol for interaction with Exchange as discussed in Exchange 2013 Client Access Server Rolearticle.

What are the client requirements for MAPI/HTTP?

Use of MAPI/HTTP requires Outlook 2013 clients to obtain Office 2013 Service Pack 1 or the February update for Office 365 ProPlus clients. MAPI/HTTP is planned to be ported to Outlook 2010 at a future date. At this time no other version of Windows Outlook supports MAPI/HTTP.

How does this affect publishing Exchange 2013 via ARR, WAP, TMG, UAG, B2M, ABC, BBD …

Publishing Exchange 2013 with MAPI/HTTP in use does not change very much. You will need to ensure devices in front of Exchange handling user access to CAS are allowing access to the Default Web Site’s /mapi/ virtual directory.

At this time UAG SP3 is not compatible with MAPI/HTTP even with all filtering options disabled. UAG plans to add support for MAPI/HTTP in a future update.

Learn More

Still want more information? Review the following sessions on this topic from Microsoft Exchange Conference 2014

Outlook Connectivity: Current and FutureOutlook Connectivity: Current and FutureOutlook Connectivity: Current and Future

What's New in Outlook 2013 and Beyond

What's New in Authentication for Outlook 2013

Cumulative Update 5 (CU5) for Exchange Server 2013 will be released soon^TM, but before that happens, I wanted to make you aware of a behavior change in the Offline Address Book that is shipping in CU5.  Hopefully this information will aid you in your planning, testing, and deployment of CU5.

The Offline Address Book in Previous Releases

In all previous major releases, the Offline Address Book (OAB) was generated by a particular server within your organization based on an administrator defined schedule. This architecture provided flexibility as it allowed you to deploy OAB generation servers based on the needs within your environment, and depending on how you deployed your OABs, could even enable users to download the OAB from the closest CAS available.

Let’s apply this information to an example. Contoso operates as a distributed messaging environment, with offices in Redmond and Portland. Each site has an OAB generated based on the Default Global Address List, allowing the local users to download the OAB without traversing an expensive (and possibly highly latent) WAN. If the users travel, they download the OAB changes across the WAN link.

Figure 1: Exchange 2010 OAB Contoso Architecture

While this model provided flexibility, it unfortunately had a single point of failure – if the server failed, OAB generation stopped. This also meant that high availability architectures in Exchange 2010 did not provide any benefit to the OAB.

The OAB in Exchange 2013

Exchange 2013 has introduced dramatic changes to the OAB. The OAB is no longer generated by a server; instead, the OAB is generated by a special type of arbitration mailbox, known as an organization mailbox. The generation is controlled by a time-based assistant, OABGeneratorAssistant, which works in conjunction with the workload management infrastructure to ensure that the system is not burdened by the OAB’s generation.

This new infrastructure can also take advantage of the high availability architecture of Exchange 2013. The OAB mailbox can be deployed on a mailbox database that has multiple copies, thereby mitigating a failure mode that occurred in previous releases.

From a connectivity perspective, Autodiscover provides back an OAB URL for the site in which the user’s mailbox is located. That URL resolves to a Client Access server which attempts to proxy the request to an OAB mailbox within the local site. If there is no OAB generation mailbox located within the local AD site, CAS picks one in another site with the lowest site connection cost. If there is more than one OAB generation mailbox with same lowest cost, CAS will pick one at random.

However, this new architecture introduces some deficiencies.

• Each OAB generation mailbox generates and stores all the OABs in the environment.

  Referring back to the previous example, now upgraded to Exchange 2013, Contoso’s administrator created an OAB generation mailbox in Portland, mirroring the Exchange 2010 architecture.  Both OAB generation mailboxes generate the Redmond and Portland OABs:

  
  Figure 2: Exchange 2013 OAB Contoso Architecture - Multiple OAB Generation Mailboxes

  If Contoso contained more locations, each hosting its own OAB, then the number of OABs generated by the OAB generation mailbox increases proportionally. Each OAB generated increases the compute cycles and capacity requirements on each Mailbox server hosting an OAB generation mailbox.

• Each OAB generation mailbox generates an OAB that is unique when compared to the same OAB generated by other OAB generation mailboxes.

  This tenet means that traveling users and single namespace designs are impacted. Referring back to Figure 2, with the environment now utilizing a single namespace across the two locations, there is a fifty percent chance that a user will hit CAS infrastructure that is not located within the same site as the user’s mailbox. CAS will utilize the local OAB instance vs. proxying between sites as the local site contains the closest OAB generation mailbox. As a result, users will download full OABs each time Outlook’s OAB synchronization request is processed in a different site when compared to the mailbox’s location.

  There’s another way this tenet can impact clients – deploying more than a single OAB generation mailbox in a site. For example, if the Redmond site had two OAB generation mailboxes, both OAB generation mailboxes would generate unique, separate instances of the Redmond OAB. Even if the Redmond users were always directed to the Redmond CAS infrastructure, because there are two OAB generation mailboxes, CAS could proxy to either mailbox. As a result, each time an Outlook client is directed to a different OAB download instance, a full OAB download is triggered. In other words, if there are two (or more) OAB generation mailboxes located within the same Active Directory site, a user could download either OAB, resulting in full OAB downloads each time the user accesses a different OAB generation mailbox’s OAB files.

  
  Figure 3: Exchange 2013 OAB Contoso Architecture - Multiple OAB Generation Mailboxes in a Single Site

These deficiencies led to the guidance of deploying only a single OAB generation mailbox per organization. While this guidance resolves the aforementioned issues, it is not practical in large distributed on-premises environments or in hosting environments because it forces the users to download the OAB over expensive (and often times, saturated) WAN links and it is a single point of failure – if connectivity to the site hosting the OAB generation mailbox is inaccessible, clients cannot retrieve updated OAB data.

Dedicated OAB Generation Mailboxes in Cumulative Update 5

CU5 moves away from the previous model where an OAB generation mailbox generates all the OABs in the organization. While an OAB generation mailbox can continue to generate multiple OABs (the default behavior when you deploy Exchange 2013), what’s new in CU5 is that an OAB can only be assigned to a single OAB generation mailbox.

This architectural change addresses the aforementioned deficiencies:

• By allowing administrators to define where an OAB is generated.
• By removing the capability to have multiple instances of the same OAB, mitigating the scenario where a client could hit a different OAB instance triggering a full OAB download. 

From a connectivity perspective, Autodiscover provides back an OAB URL for the site in which the user’s mailbox is located. That URL resolves to a Client Access server which proxies the request to the linked OAB generation mailbox that is responsible for generating the requested OAB.

As a result, Contoso can now deploy the following OAB architecture:

Figure 4: Exchange 2013 OAB Contoso Architecture

Redmond users will now only download the Redmond OAB from the Redmond AD site and Portland users will only download the Portland OAB from the Portland AD site.  Neither set of users will have an OAB full download as a result of traveling between locations because the users will always be referred back to the Mailbox server hosting the OAB generation mailbox that contains their OAB.

What happens to my existing OABs when I upgrade to CU5?

When you upgrade to CU5, all existing OABs are linked to the system arbitration mailbox, SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}, regardless of whether there are additional OAB generation mailboxes within the environment. This ensures that all OABs are still generated after CU5 is installed. This has two implications:

1. If you were not aware of our guidance of deploying only a single OAB generation mailbox per organization, and instead, deployed multiple OAB generation mailboxes, those mailboxes will no longer generate OABs after the servers hosting their databases are upgraded to CU5. This means that Outlook clients will perform a full OAB download (as they are now accessing a different OAB instance).
2. Once you dedicate an OAB to a specific OAB generation mailbox, this will be a new OAB instance and thus, will trigger a full download for the Outlook clients.

Note: Users will not experience full OAB downloads after CU5 is deployed if your deployment does not contain multiple OAB generation mailboxes.

How do I dedicate an existing OAB to specific OAB Generation Mailbox?

Once CU5 is deployed, you can dedicate existing OABs to specific OAB generation mailboxes by executing the following command, utilizing the GeneratingMailbox parameter:

Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox "CN=OAB Mailbox 1,CN=Users,DC=contoso,DC=com"

Important: If your OAB generation mailboxes are deployed in DAGs, upgrade all Mailbox servers to CU5 before dedicating an OAB to a specific OAB generation mailbox. If you do not, when the database hosting the OAB generation mailbox is activated on a server running an older version, the OAB assistant will generate all OABs.

The GeneratingMailbox parameter only accepts the distinguished name value of the OAB generation mailbox; other identity types (e.g., domain\account, UPN, alias, etc.) do not work. One way around this is to utilize the following process:

$mbx = get-mailbox oabmbx1 –arbitration
 
Set-OfflineAddressBook "Portland OAB" –GeneratingMailbox $mbx.Identity

Once you have linked the OAB to an OAB generation mailbox, you will need to execute Update-OfflineAddressBook:

Update-OfflineAddressBook "Portland OAB"

How do I create a new OAB and an OAB Generation Mailbox?

When creating new OABs you need to specify the GeneratingMailbox property:

New-Mailbox -Arbitration -Name "OAB Mailbox 3" -Database DB4 -UserPrincipalName oabmbx3@contoso.com –DisplayName "OAB Mailbox 3"
 
Set-Mailbox "OAB Mailbox 3" –Arbitration –OABGen $true
 
New-OfflineAddressBook -Name "Bel Air OAB" –GeneratingMailbox "CN=OAB Mailbox 3,CN=Users,DC=contoso,DC=com" –Address Lists "Default Global Address List"

Note: GeneratingMailbox is not a required parameter when creating an OAB. If the GeneratingMailbox parameter is not specified, the Exchange Management Shell will return the following warning: GeneratingMailbox is null; this OAB will not be generated until GeneratingMailbox is set to an arbitration mailbox with the OABGen capability.

Once you have created the OAB in your environment, you will need to execute Update-OfflineAddressBook:

Update-OfflineAddressBook "Bel Air OAB"

Summary

We have heard your feedback loud and clear that the Exchange 2013 OAB architecture does not meet the needs of distributed messaging environments. Dedicating OABs to specific OAB generation mailboxes is the first step in improving the capabilities of the OAB in the on-premises product. I won’t go into specifics at this early stage of development, but we are not finished with improving the OAB architecture. As the plans finalize, I will share more.

Ross Smith IV
Principal Program Manager
Office 365 Customer Experience

The Exchange team is announcing today the availability of Update Rollup 6 for Exchange Server 2010 Service Pack 3. Update Rollup 6 is the latest rollup of customer fixes available for Exchange Server 2010 Service Pack 3. The release contains fixes for customer reported issues and previously released security bulletins. Update Rollup 6 is not considered a security release as it contains no new previously unreleased security bulletins. A complete list of issues resolved in Exchange Server 2010 Service Pack 3 Update Rollup 6 may be found in KB2936871. Customers running any Service Pack 3 Update Rollup for Exchange Server 2010 can move to Update Rollup 6 directly.

The release is now available on the Microsoft Download Center. Update Rollup 6 will be available on Microsoft Update in early July.

Note: KB articles may not be fully available at the time of publishing of this post.

The Exchange Team