Exchange Server 2013 High Availability Book

After a lot of work, I have finally released my first book: Microsoft Exchange Server 2013 High Availability!    :)

I now fully appreciate the work involved in the process of writing/releasing a book!

 

 

“This practical hands-on guide will provide you with a number of clear scenarios and examples that will explain the mechanics behind the working of Exchange 2013 High Availability and how maximum availability and resilience can be achieved through it.

 

Throughout this book, you will go through all the roles, components, and features that should be considered when addressing high availability. You will go through how to achieve high availability for the Client Access and Mailbox server roles, what’s new in load balancing, site resilience, the new public folders, and much more.

 

You will learn to successfully design, configure, and maintain a highly available Exchange 2013 environment by going through different examples and real-world scenarios, saving you and your company time and money, and eliminating errors.”

 

 

The book is available on Amazon.com, Amazon.co.uk, Packt Publishing, and soon in Google Play store, Apple books, Safari books online, Bookshout!, Kobo books, EBL, Vital Source and O'Reilly.

Any feedback appreciated! :)

Free/Busy Information Period (Exchange 2013-2007 Error)

Free/busy information requests to an Exchange 2007 organization from an Exchange 2013 organization may fail due to a mismatch in the requested free/busy information period. By default, Exchange 2007 accepts availability requests for 42 days of free/busy information and Exchange 2013 may request 62 days of free/busy information. If the request exceeds the default 42 limit imposed by Exchange 2007, the request will fail.

 

In order to prevent this failure, follow the steps below to configure your Exchange 2007 CAS servers to accept longer period free/busy information requests:

1. On all your Exchange 2007 CAS servers, open the following file with a text editor such as Notepad (remember to create a backup copy first!):
<Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config

2. Locate the appSettings section;

3. Add a new key “<add key="maximumQueryIntervalDays" value="62" />” and save the web.config file. The maximumQueryIntervalDays value is not present by default. When this value is not present, Exchange 2007 uses the default interval of 42 days.

4. Restart IIS on all the Exchange 2007 CAS servers.

Exchange 2013 DAG with Dynamic Quorum

Windows Server 2012 introduced a new quorum model called Failover Clustering Dynamic Quorum, which we can use with Exchange. When using Dynamic Quorum, the cluster dynamically manages the vote assignment to nodes based on the state of each node. When a node shuts down or crashes, it loses its quorum vote. When a node successfully re-joins the cluster, it regains its quorum vote. By dynamically adjusting the assignment of quorum votes, the cluster can increase or decrease the number of quorum votes that are required to keep it running. This enables the cluster to maintain availability during sequential node failures or shutdowns.

 

With a dynamic quorum, the cluster quorum majority is determined by the set of nodes that are active members of the cluster at any time. This is an important distinction from the cluster quorum in Windows Server 2008 R2 where the quorum majority is fixed, based on the initial cluster configuration.

 

The advantage this brings, is that it is now possible for a cluster to run even if the number of nodes remaining in the cluster is less than 50%! By dynamically adjusting the quorum majority requirement, the cluster can sustain sequential node shutdowns down to a single node and still keep running. It does not allow the cluster to sustain a simultaneous failure of a majority of voting members though. To continue running, the cluster must always have a quorum majority at the time of a node shutdown or failure.

 

 

The following picture shows a DAG still operational even though two out of three servers are offline:

 

 

To read more about this feature, including tests with an Exchange 2013 DAG, please check my Exchange 2013 DAGwith Dynamic Quorum article on MSExchange.org.

Hyper-V Replica with Exchange Supportability

If you are considering whether to use Hyper-V Replica with Exchange, remember that Exchange has its own disaster recovery and site awareness capabilities that should be used instead.

 

Hyper-V Replica is not needed and is not supported because of problems with Exchange roles being forced back in time in the event of an unplanned failover.

How to Determine Continuous Replication Mode (Block Mode or File Mode)?

In Exchange 2007 and 2010, Continuous Replication operates by shipping copies of the logs created by the active database copy to the passive database copies. With Exchange 2010 SP1, this is known as Continuous Replication - File Mode as the log file is only copied once it is full (1MB). But SP1 introduces a new form of continuous replication known as Continuous Replication - Block Mode. In block mode, when an update is written to the active database log file it is immediately copied to the passive mailbox copies, thus reducing the latency between the time a change is made on the active copy and the time that same change is replicated to a passive copy. This way, if a failure occurs on the active copy, the passive copies will have been updated with most or all of the latest updates.

However, Block Mode is only active when continuous replication is up-to-date in file mode. The Log Copier component monitors the copy and replay queue lengths of databases as transaction logs are generated and takes care of transitioning into and out of block mode automatically.

To determine if continuous replication is operating in block mode or file mode, use the following cmdlet:

Get-Counter -ComputerName <<DAG_Member_Name>> -Counter “\MSExchange Replication(*)\Continuous replication - block mode Active”

The output will be something similar to:

Timestamp                 CounterSamples

---------                 --------------

04/09/2012 11:39:46       \\MBX1\\msexchange replication(mdb31)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb32)\continuous replication - block mode active : 1

                          \\ MBX1\\msexchange replication(mdb33)\continuous replication - block mode active : 0

Here, the “1” means that block mode is active while a “0” means it is not. However, note that your active databases will always show “0”, we are just interested in the passive copies!

Suspend Multiple Database Copies

If you are doing maintenance on a server and want to suspend all passive database copies on that server it is very simple and all you have to do is run:

Get-MailboxDatabaseCopyStatus -Server "server_name" | Suspend-MailboxDatabaseCopy -Confirm:$False

Because we are not excluding the current mounted DBs (if any), the script will throw an error stating that “The suspend operation can't proceed because database "db_name" on Exchange Mailbox server "server_name" is the active mailbox database copy” - which is fine because it’s what we want.

If you want to suspend all passive copies of a particular database across all servers you can simply run:

Get-MailboxDatabaseCopyStatus "db_name" | Suspend-MailboxDatabaseCopy -Confirm:$False

But what if you are reducing the number of database copies in your environment and just want to suspend the 4th copy of all your DBs across all your servers? In this case, we will have to use the following script:

$dbs = Get-MailboxDatabase

ForEach ($db in $dbs) {
  ForEach ($dbCopy in $db.DatabaseCopies) {
    If ($dbCopy.ActivationPreference -eq 4) {
      Suspend-MailboxDatabaseCopy $dbCopy.Identity -Confirm:$False
    }
  }
}

Hope this helps!

Exchange Availability Service

For some Exchange Administrators, the Availability service is still a mystery or, at least, not quite well understood. So, let’s talk more about this new feature on Exchange 2007.

Basically, this service provides free and busy (f/b) information about Outlook 2007 users, used to determine users’ availability when scheduling meetings, in an up-to-date, reliable and secure way. Outlook obtains the URL of the Availability service by using the AutoDiscover service (maybe discussed in a future post!) which is responsible for providing to the client his display name, the location of his mailbox, the Outlook Anywhere server settings and the URLs for f/b information, Unified Messaging and the Offline Address Book (OAB).

Let’s go back a couple of years...In Exchange 2000 and 2003, and with clients older than Outlook 2007, a special public folder is used to store users' calendar f/b information. This folder is named SCHEDULE+ FREE BUSY and contains several subfolders for each administrative group.

Figure 1: The SCHEDULE+ FREE BUSY System Folder on Exchange Server 2003

What Outlook does is periodically publishing the calendar f/b information into this folder which then allows other users to query this information when scheduling a meeting. However, imagine a corruption on the public folder database, or how often the replication can cause a lag between the time a user updates his calendar and when the f/b information becomes available, giving origin to out-of-date f/b information.


Back to the present...
Besides providing Outlook Anywhere, Outlook Web Access, Active Sync and other non-MAPI forms of connectivity, the Client Access Server (CAS) also provides two very important and vital services for an Exchange 2007 infrastructure: the AutoDiscover and the Availability Web Services
With Exchange 2007, the f/b information is now obtained directly from the target mailbox rather than from the SCHEDULE+ FREE BUSY system folder. This is how f/b information is now retrieved in real-time.

Note: since this is a new functionality, Outlook 2007 clients running on Exchange Server 2003 mailboxes will use public folders for the f/b information. The same thing happens with the OAB distribution.


How does it work?
1. By using AutoDiscover, Outlook establishes a connection to the CAS server running the Availability service
2. The CAS server determines on which mailbox server the target mailbox is
3. The CAS server communicates with the mailbox server (via MAPI) and obtain the f/b information
4. The results are then returned back to the user

Scenario 1
In this case, both servers are in the same Active Directory (AD) site. If they were on different ones, the CAS server would make an HTTPS connection to the target CAS server located on the AD site of the target user which would obtain and return the information back to the original CAS server and then to the user.

Scenario 2
If the target user has his mailbox on a Exchange 2003 server, situation very common during migrations, the Availability service will have to obtain the f/b information from the SCHEDULE+ FREE BUSY system folder by making an HTTPS request to the /Public virtual directory on the mailbox server hosting that folder.

Scenario 3
What if the user was running Outlook 2003 for example? Well, in this case it doesn’t matter on which server, 2003 or 2007, the target mailbox is because Outlook 2003 will always attempt to gather and publish the f/b information from/to the SCHEDULE+ FREE BUSY system folder. How could it use the Availability service if it is a new functionality?

Scenario 4
What about when using Outlook Web Access (OWA)? In this situation, OWA works just like Outlook would.


Calendar Information
The Availability service also enables users to share their calendar information in a more granular way. For each target user/group, the user can choose one of four levels of sharing:
· Share nothing
· Share their Free-Busy information
· Share a little more detail including subject, location and timing
· Full calendar details.

Figure 2: Calendar Sharing Properties

Distribution Groups
While on previous versions of Exchange, the expansion of Distribution Groups (DGs) was made by a Global Catalog, now it is made by Exchange 2007. This allows the Availability service to provide consistent behavior for any Availability service user when expanding a DG. On Exchange 2003, for example, if the number of distribution group members was too large, the f/b data for the distribution group members would display as busy when expanded.



Configuring the Availability service
As I said before, it is crucial that the AutoDiscover service be configured for Outlook 2007 clients as it’s this service the responsible for allowing users to locate the Availability service. Most of its configuration is done automatically in a single-forest environment with no external Outlook access configured. However there are three situations where further configuration is necessary:
1. To provide external access to Exchange Web Services, like Outlook Anywhere
2. To access f/b data in a cross-forest topology
3. To access the Availability service when a Network Load Balancing array of CAS servers is in place

Since this post is already getting too big, I’m just going to give a simple example of how to do this when you are using NLB for your CAS servers without going into much detail:

1. In the Exchange Management Shell use the Get-WebServicesVirtualDirectory to check the ExternalURL in use, for example: Get-WebServicesVirtualDirectory –Identity “«CAS_Server»\EWS (Default Web Site)”
2. If necessary, modify this external URL using the Set-WebServicesVirtualDirectory cmdlet, for example: Get-WebServicesVirtualDirectory Set-WebServicesVirtualDirectory –ExternalUrl “https://«fully_qualified_domain_name»/EWS/Exchange.asmx” where «fully_qualified_domain_name» is the externally accessible DNS hostname of the CAS computer

Note that this cmdlet is also used to set the –InternalUrl parameter for a NLB cluster.



Troubleshooting the Availability service
If Outlook 2007 users can’t view calendar information for other Outlook 2007 users the problem might be a failure in either the Availability or the AutoDiscover service. So, my suggestion is to first take a look at the latter.

First, let’s see if the AutoDiscover service is unable to provide information to the clients by using Outlook 2007.
1. In Outlook 2007, log on to the mailbox of the user for whom you want to troubleshoot
2. On the Tools menu, click Options, click the Other tab, and then click Advanced Options
3. On the Advanced Options page, select Enable logging (troubleshooting), and then click OK
4. Restart Outlook and then try to view free/busy information for another user
5. Click Start, Run, and then type %temp%
6. In Windows Explorer, open the olkdisc.log file and locate the files in the olkas directory
7. The information that is contained in this directory can frequently provide information about which service is not functioning correctly

Secondly, let’s use Outlook 2007 to test the AutoConfiguration information that the AutoDiscover service provides. To test this, and while Outlook is running:
1. Hold down the CTRL key, right-click the Outlook icon in the notification area, and then select Test E-mail AutoConfiguration
2. Verify that the correct e-mail address is in the box next to E-mail Address
3. Clear the check boxes next to Use Guessmart and Secure Guessmart Authentication
4. On the Test E-mail AutoConfiguration page, verify that the check box next to Use AutoDiscover is selected, and then click the Test button

Take a look at the Results and Log tabs and check the information there for possible errors.

This was on the client side. On Exchange, there are also two ways to determine whether the Availability service is not functioning correctly.
The first one is by using the Application Event Log on the CAS server to check for events that are generated by the Availability service. For example, the events 4001, 4003, 4005 and 4011 or every event with an event source of “MSExchange Availability”.
The other way is to use the Test-OutlookWebServices cmdlet in the Exchange Management Shell to determine whether the Availability service is functioning correctly.

To diagnose the Availability service issues for an individual user:
Test-OutlookWebServices –Identity n.mota@letsexchange.com

To diagnose the Availability service issues for a CAS server:
Test-OutlookWebServices -ClientAccessServer EXCAS1

To diagnose the Availability service issues across different sites:
Test-OutlookWebServices -Identity n.mota@site1.letsexchange.com -TargetAddress j.smith@site2.microsoft.com

The resulting output will provide error details about the Availability service.

If you’re using the Availability service on a Cross-Forest scenario, please note that this service has a time limit when the it performs an AutoDiscover service request for cross-forest users in the AD directory service. By default, this is 10 seconds. If the AutoDiscover request does not finish in 10 seconds, the Availability service request for the cross-forest user may time out. This might be due to fact that the URL for the user is not cached, the AutoDiscover service is running slowly or it is experiencing network latencies.
If you want to increase this time-out value follow these steps (to increase it to 24 seconds):
1. Locate the Outlook Web Access Web.config file on the CAS server. The default location is in the following directory: C:\Program Files\Microsoft\ExchangeServer\ClientAccess\Owa
2. Make a backup copy of this file
3. Open the original file by using Notepad. Do not use IIS or WordPad to edit it
4. Add the following section directly under the Configuration node after the appSettings section:
5. Save the Web.config file.



If you have client computers running Outlook 2003 and earlier or Microsoft Entourage in your organization, they require a public folder database to support Schedule+ Free Busy functionality. Exchange 2007 is the first version of Exchange that gives you the option to not use public folders. However, until all your client computers are running Outlook 2007, you should continue to use public folders. This is why the Exchange 2007 Server Setup Wizard asks you whether Outlook 2003 or Entourage clients exist in your organization. Let’s see if in Exchange 14 we’ll still be able to work with pre-Outlook 2007 versions that still rely on public folders.