Exchange Server 2013 uses Extensible Storage Engine (ESE) databases for mailbox storage. When you install a Mailbox server in an Exchange 2013 organization, this server’s information store has a single, default mailbox database. Mailbox databases have a single, dedicated log stream, which is represented by a series of sequentially named log files. Each log file is 1 megabyte (MB) in size. In addition to log files, databases have several other types of files associated with them, including one or more checkpoint files, a temporary working file, and one or more transaction log files. Depending on the state of Exchange Server, you might see other working files as well.

When you create a mailbox database, you can specify separate folder locations to use for database files and transaction logs. Each database has content-indexing files associated with it as well. These files are generated by the Exchange Search service, which is enabled by default and running on all Mailbox servers. Exchange Search indexes new mail items in the transport pipeline or immediately after the items are created and delivered to a mailbox.

You use Exchange databases to ease the administrative burden that comes with managing large installations. For example, instead of having a single 10-terabyte (TB) database for the entire organization, you can create ten 1-TB databases that you can manage more easily.

When you create a mailbox database, you specify the name for the database, and this name sets the name of the primary database file as well. For example, if you create a mailbox database called MarketingDept, the primary database file is set as MarketingDept.edb. With Exchange Server 2013, the default location for database files is the same as the log folder. If you want a database to be in a different location, you can specify the location you want to use. Separating database files and log files from the same database and putting them on different volumes backed by different physical disks can help you scale your organization while ensuring high performance and recoverability.

The many files associated with databases provide granular control over Exchange Server, and if you configure the data files properly, they can help you scale your Exchange organization efficiently while ensuring optimal performance. In a small implementation of Exchange, you might want to place all the data files on the same drive. As you scale from a small organization to a larger organization, you’ll generally want to organize data according to databases, placing all the data for each database on physically separate drives. You can’t always do this, however, in a small-to-medium sized organization with limited resources. For example, if you have ten 1-TB databases and only five data drives, you might want to have the five data drives configured as follows:

In a storage area network (SAN) implementation in which you are using logical unit numbers (LUNs) and don’t know about the underlying disk structure, placing the databases on separate LUNs should be sufficient. To protect the data, you might want to consider using hardware RAID (redundant array of inexpensive disks), which is likely already implemented if you are using a SAN. However, if you configure a database availability group with multiple member servers that each have one or more copies of mailbox databases, you likely don’t need to use any type of RAID, and you likely won’t need daily backups either. Just remember that Microsoft recommends having at least three database copies in addition to the active copy.

Exchange 2013 allows you to protect mailbox databases and the data they contain by configuring your mailbox databases for high availability automatically when you use database availability groups. Database availability groups allow you to group databases logically according to the servers that host a set of databases. Each Mailbox server can have multiple databases, and each database can have as many as 16 copies. A single database availability group can have up to 16 Mailbox servers that host databases and provide automatic database-level recovery from failures that affect individual databases. Any server in a database availability group can host a copy of a mailbox database from any other server in the database availability group.

Mailbox servers in a database availability group can also host the Client Access server role. Member servers must be in the same Active Directory domain.

Exchange 2013 integrates high availability and messaging resilience into the core architecture, providing a simple unified framework for both high availability and disaster recovery. This approach reduces the cost and complexity of deploying a highly available solution. How does this work? Exchange 2013 has enhanced continuous replication and has replaced clustering features in Exchange 2007 with a more robust solution that doesn’t require expensive hardware and also requires less maintenance.

In early versions, Exchange was a clustered application that used the cluster resource management model for high availability. In contrast, Exchange 2013 is not a clustered application and therefore does not use the cluster resource model for high availability. Instead, Exchange 2013 uses its own internal high-availability model. Although some components of Windows Failover Clustering are still used, these components are now managed exclusively by Exchange 2013.

To support continuous replication, early versions of Exchange offered several approaches, including Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), and Standby Continuous Replication (SCR). LCR was a single-server solution for asynchronous log shipping, replay, and recovery. CCR combined the asynchronous log shipping, replay, and recovery features with the failover and management features of the Cluster service, and it was designed for configurations in which you had clustered Mailbox servers with dedicated active and passive nodes. SCR was an extension of LCR and CCR that used the same log shipping, replay, and recovery features of LCR and CCR but was designed for configurations in which you used or enabled the use of standby recovery servers.

Exchange 2013 includes some aspects of the continuous replication technology previously found in CCR and SCR, but the technology has changed substantially. Because storage groups have been removed from Exchange 2013, continuous replication operates at the database level. Exchange 2013 still uses an Extensible Storage Engine (ESE) database that produces transaction logs that are replicated and replayed into copies of mailbox databases. Because each mailbox database can have as many as 16 copies, you can have one or more database copies on up to 16 different servers.

When a Mailbox server is added to DAG, the server works with other members of the DAG to provide automatic recovery from failures that affect mailbox databases, including disk failures, server failures, and other critical failures. When a failure affecting a database occurs and a new database becomes the active copy automatically, this process is known as a failover. When an administrator establishes a database copy as the active mailbox database, this process is known as a switchover.

Failover and switchover occur at the database level for individual databases and at the server level for all active databases hosted by a server. When either a switchover or failover occurs, other Exchange 2013 server roles become aware of the switchover almost immediately and redirect client and messaging traffic automatically as appropriate.

Although you can perform most management tasks for availability groups in the Exchange Admin Center, you have additional options when you work with the Exchange Management Shell. Table 2-1 provides an overview of commands you can use to manage availability groups and their various features.

As part of database availability group planning, keep in mind that you can create database copies only on Mailbox servers in the same database availability group that do not host the active copy of a database. An active copy differs from a passive copy in that it’s in use and being accessed by users rather than offline. You cannot create two copies of the same database on the same server. Other guidelines to keep in mind when working with database copies include the following:

The Microsoft Exchange Replication service is responsible for replicating databases. The replication service and components that run within the service, including Active Manager, the TCP listener, and the Volume Shadow Copy Service writer, write results to the event logs. In Event Viewer, you can find these logs by navigating to Applications and Services Logs > Microsoft > Exchange > High Availability. In these logs, you’ll find details on database actions, such as database mount operations, log truncation, and cluster action within DAGs. Events related to failures that affect replicated mailbox databases are written to the logs under Applications and Services Logs > Microsoft > Exchange >MailboxDatabaseFailureItems.

In Exchange 2013, Active Manager provides the resource model and failover management features previously provided by the Cluster service. When you create your first database availability group in an Exchange organization, Exchange creates a Windows Failover Cluster, but there are no cluster groups for Exchange and no storage resources in the cluster. Therefore, as shown in Figure 2-1, Failover Cluster Manager shows only basic information about the cluster, which includes the cluster name and networks, and the quorum configuration. Cluster nodes and networks will also exist, and their status can be checked in Failover Cluster Manager; however, Exchange manages all cluster resources, including nodes and networks. Exchange makes use of the cluster’s node and network management functions, and you can check the node and network status in Exchange Admin Center.

Figure 2-1. Check the status of clustering in Failover Cluster Manager.

Active Manager runs on all Mailbox servers as a subcomponent of the Microsoft Exchange Replication service. On Mailbox servers that aren’t part of a DAG, Active Manager operates as a Standalone Active Manager. On Mailbox servers that are members of a DAG, Active Manager operates as either a primary role holder or a standby secondary role holder with respect to a particular database. The primary role holder, referred to as the Primary Active Manager, decides which database copies will be active and which copies to activate. It also receives topology change notifications and reacts to server failures. Only one copy of a database can be active at any given time, and that copy can be mounted or dismounted.

The group member that holds the primary role is always the member that currently owns the cluster quorum resource and the default cluster group. If the server that owns the cluster quorum resource fails, the primary role automatically moves to another server in the group and that server takes ownership of the default cluster group. Before you take the server that hosts the cluster quorum resource offline for maintenance or an upgrade, you must first move the primary role to another server in the group.

Secondary role holders, referred to as Standby Active Managers, provide information about which server hosts the active copy of a mailbox database to other Exchange components. The secondary role holder detects failures of replicated, local databases and the local information store, and it issues failure notifications to the primary role holder and asks the primary role holder to initiate a failover. The secondary role holder does not determine which server takes over, nor does it update the database location state with the primary role holder. With respect to its local system, the primary role holder also performs the functions of the secondary role by detecting local database and local information store failures and issuing related notifications.

Active Manager determines which database copy should be activated by attempting to locate a mailbox database that has characteristics similar to the following:

If no database copy meets all of these criteria, Active Manager continues looking for the best choice by lowering the selection requirements through successive iterations. Active Manager uses the managed availability framework to perform health checks. After one or more copies have been selected, Active Manager attempts to copy any missing log files from the original source to a potential new active copy by using a process called attempt copy last logs (ACLL). After the ACLL process is complete, Active Manager compares the value of the AutoDatabaseMountDial property for Mailbox servers hosting copies of the database to the copy queue length of the database being activated. If the value of the AutoDatabaseMountDial property is greater than the number of missing log files, the Primary Active Manager tries to activate the next best copy (if one is available).

If the value of the AutoDatabaseMountDial property is equal to or less than the number of missing log files, the Primary Active Manager issues a mount request. At this point, either the database mounts and is made available to clients or the database doesn’t mount and the Primary Active Manager tries to activate the next best copy (if one is available).

In Exchange 2013, the active monitoring and high availability functions are integrated into a single architecture called managed availability, which is implemented on Mailbox servers and Client Access servers. Managed availability is a framework that includes a probe engine for taking measurements and collecting data, a monitor engine for determining the status of Exchange components, and a responder engine for taking recovery actions.

Managed availability is implemented by using:

During startup, the health manager worker process reads XML configuration files and initializes the probes, monitors, and responders used by the managed availability framework. The worker process stores runtime data in the registry and writes results to the event logs as well. In Event Viewer, you can find these logs by navigating to Applications and Services Logs > Microsoft > Exchange > ManagedAvailability.

As discussed further in Chapter 9 in the Tracking server health section, you can check the state and health of Exchange resources by using Get-HealthReport and Get-ServerHealth. Each tracked resource has customized sets of probes, monitors, and responders that help to ensure its availability. Probe definitions identify the Exchange resource to track and the time interval in which the resource is checked. Monitor definitions identify the specific state of the resource based on the collected data. In Event Viewer, you can find definitions and results for probes, monitors, and responders under Applications and Services Logs > Microsoft > Exchange > ActiveMonitoring.

Exchange tracks the transition state internally by using the TargetHealthState property associated with a responder, where

When a resource transitions from one state to another is determined by the monitor definition. As soon as the monitor engine detects an unhealthy or degraded state for a responder, the transition state of that resource is shown as Unhealthy or Degraded respectively, which will trigger a recovery action. Whether a resource is shown as Unhealthy or Degraded depends on the data collected. For example, if a resource is unavailable, the resource might be listed as Unhealthy. If a resource is available but is slow to respond due to high latency or a high level of activity, the resource might be listed as Degraded.

Once in an Unhealthy state, the health manager might transition the resource to another state. For example, after 30 seconds in an unhealthy state, the resource may be transitioned to an Unhealthy1 state. After 300 seconds in an unhealthy state, the resource may be transitioned to an Unhealthy2 state. After 3000 seconds in an unhealthy state, the resource may be transitioned to an Unrecoverable state. Once in an Unrecoverable state, the health manager may transition the resource through the related Unrecoverable, Unrecoverable1, and Unrecoverable2 states.

Responder definitions detail the specific recovery actions to take based on the transition state of the Exchange resource. The exact response to an unhealthy state depends on the affected resource. Although the initial response to an unhealthy state might be to restart the related service or application pool, a subsequent response might be to restart the server, and a final response might be to take the server offline so that it no longer accepts traffic.

A database availability group defines a set of servers that provide automatic database-level recovery from database failures. Only members of the Organization Management group or the Database Availability Groups Role can create database availability groups. Only members of the Organization Management group or the Database Copies Role can manage mailbox database copies.

When you create a database availability group, you can specify a witness server or let Exchange choose one for you. The witness server’s role is to help maintain the state of the group. It does this by maintaining the quorum when there is an even number of members in the group. On the witness server, you can designate a directory, called the witness directory, for use by the database availability group, or you can let Exchange create a default directory for you. By default, the witness directory is created as a subdirectory of %SystemDrive%DAGFileShareWitnesses with the name set the same as the fully qualified domain name of the DAG.

Exchange creates and secures the witness directory automatically as part of configuring the witness server for use. The witness directory should not be used for any purpose other than for the database availability group witness server. The requirements for the witness server are as follows:

To be sure that Exchange administrators are aware of the availability of the witness server and that the server remains under the control of an Exchange administrator, Microsoft recommends using an Exchange 2013 server to host the witness directory. Using an Exchange 2013 server as the witness also ensures that Exchange has sufficient permissions to remotely create and share the witness directory. The preferred witness server is a Client Access server in the same Active Directory site as the majority of the members of the database availability group.

A single server can serve as a witness for multiple database availability groups; however, every database availability group must have a separate witness directory.

The witness directory doesn’t need to be fault tolerant and doesn’t require any other special considerations. If you need to reset permissions on the witness directory or recreate the witness directory in its original location, you can use Set-Database-AvailabilityGroup as long as the cluster quorum is intact.

To set up the database availability group, Exchange creates an msExchMDB-AvailabilityGroup object and related objects in Active Directory Domain Services (AD DS). These objects represent the database availability group, its members, networks, and attributes. The msExchMDBAvailabilityGroup directory object is used to store information about the database availability group, such as server membership information. Information about the included databases is stored in the cluster database. When you add the first server to a database availability group, a failover cluster is automatically created for the database availability group and failover monitoring is initiated. The failover cluster heartbeat mechanism and cluster database are then used to track and manage information about the database availability group.

After a database availability group has been created, you can add servers to or remove existing servers from the database availability group. When the first Mailbox server is added to a database availability group, the following occurs:

When you add the second and subsequent servers to the DAG, the following occurs:

When a database availability group has a single member server, the failover cluster initially uses the Node Majority quorum mode. When you add the second Mailbox server to the database availability group, Exchange changes the cluster quorum to the Node and File Share Majority quorum model and begins by using the Universal Naming Convention (UNC) path and directory for the cluster quorum. If the witness directory does not exist, Exchange automatically creates it at this point and configures its security with full control permissions for local administrators and the cluster network computer account for the database availability group.

Before you create a database availability group, you should pre-stage and prepare the cluster name object. Although these preparations aren’t required with Windows Server 2008 R2 (unless account creation is restricted or computer accounts are creating in a container other than the default Computers container), these preparations are required with Windows Server 2012 RTM and Windows Server 2012 R2. You pre-stage the cluster name object by creating a computer account that will be used as the cluster’s name resource. The name resource is a Kerberos-enabled object that acts as the cluster’s identity and provides the cluster’s security context.

To pre-stage the cluster name object, complete the following steps:

If the witness server isn’t running Exchange 2013 or Exchange 2010, you must add the Exchange Trusted Subsystem group to the local Administrators group on the witness server prior to creating the DAG. Adding this group ensures that Exchange 2013 can create and share the witness directory. To add the Exchange Trusted Subsystem group to the local Administrators group, follow these steps:

You prepare the cluster name object by completing the following steps:

Once you’ve pre-staged and prepared the cluster name object, you can create the database availability group by completing the following steps:

In the Exchange Management Shell, you can create database availability groups by using the New-DatabaseAvailabilityGroup cmdlet. New-DatabaseAvailabilityGroup cmdlet syntax and usage provides the syntax and usage. Set the -Name parameter to the name of the pre-staged computer object. Set the -DatabaseAvailabilityGroupIpAddresses parameter to the static IP address or addresses that the DAG should use. Alternatively, if the DAG should use dynamically assigned IP addresses, enter 0.0.0.0 as the IP address to use.

Syntax
New-DatabaseAvailabilityGroup -Name DAGName
[-DatabaseAvailabilityGroupIpAddresses IPAddress1, IPAddress2, IPAddressN]
[–WitnessServer ServerName]
[–WitnessDirectory LocalDirOnWitnessServer]
[-DomainController FullyQualifiedName]
[-ThirdPartyReplication <Disabled | Enabled>]

Usage
New-DatabaseAvailabilityGroup -Name "EastCampusDAG1"
-WitnessServer "CAServer19"
-WitnessDirectory "C:EastCampusDAG1"
New-DatabaseAvailabilityGroup -Name "WestCampusDAG1"
-WitnessServer "CAServer19"
-WitnessDirectory "C:WestCampusDAG1"
-DatabaseAvailabilityGroupIpAddresses 192.168.10.52,192.168.11.18
New-DatabaseAvailabilityGroup -Name "NorthCampusDAG1"
-DatabaseAvailabilityGroupIpAddresses 0.0.0.0

When you add a server to a database availability group, the server works with the other servers in the group to provide automatic, database-level recovery from database, server, and network failures. When member servers have only one network adapter card, the DAG uses the same network for both messaging and replication traffic. When member servers have two network cards, the DAG uses one network card primarily for messaging traffic and the other network card is typically dedicated to replication traffic. If you add more than two network cards to member servers, these additional network cards can be configured for replication, giving the DAG additional replication networks to handle increased workloads.

Keep the following in mind when planning database availability group membership:

You can add a Mailbox server to or remove a Mailbox server from a database availability group by completing the following steps:

In the Exchange Management Shell, you can list database availability groups by using Get-DatabaseAvailabilityGroup. If you enter Get-DatabaseAvailabilityGroup without additional parameters, you’ll see a list of all availability groups in the current Active Directory forest and in the member servers and operational servers for those groups, as shown in the following example and sample output:

Get-DatabaseAvailabilityGroup
Name            Member Servers               Operational Servers
----            --------------               -------------------
EastCampusDAG1  MailServer42, MailServer21   MailServer42, MailServer21
WestCampusDAG1  MailServer44, MailServer18   MailServer44, MailServer18

Use the –Identity parameter to specify the name of the database availability group to query. Add –Status to any query to include real-time status information.

You add or remove group members by using Add-DatabaseAvailabilityGroupServer and Remove-DatabaseAvailabilityGroupServer. Add-DatabaseAvailabilityGroupServer cmdlet syntax and usage and Remove-DatabaseAvailabilityGroupServer cmdlet syntax and usage provide the syntax and usage.

Syntax
Add-DatabaseAvailabilityGroupServer -Identity DAGName
–MailboxServer ServerToAdd [-DomainController FullyQualifiedName]
[-SkipDagValidation {$true | $false}]

Usage
Add-DatabaseAvailabilityGroupServer –Identity "EastCampusDAG1"
-MailboxServer "MailServer62"

Syntax
Remove-DatabaseAvailabilityGroupServer -Identity DAGName
–MailboxServer ServerToRemove [-ConfigurationOnly <$true | $false>]
[-DomainController FullyQualifiedName] [-SkipDagValidation {$true|$false}]

Usage
Remove-DatabaseAvailabilityGroupServer –Identity "EastCampusDAG1"
-MailboxServer "MailServer62"

Each database availability group should have a minimum of two networks: one for replication traffic, referred to as the group’s replication network, and one for MAPI and other traffic, referred to as the group’s messaging network. Although a DAG can have only one messaging network, you can create additional replication networks in a database availability group and configure them by using the Exchange Management tools. Having multiple replication networks helps scale the DAG to meet increasing requirements.

By default, Exchange 2013 automatically creates DAG networks based on the configuration of network adapter cards installed on member servers. If a DAG member has multiple network cards and those cards are configured on separate networks, Exchange normally will configure the DAG members with one messaging network and one or more dedicated replication networks automatically. You can manually configure DAG networks as well but must first disable automatic network configuration.

You can enable manual network configuration for a DAG by completing the following steps:

After you enable manual network configuration, you can manually create and manage network settings for the DAG. Each database availability group network must have a unique name of up to 128 characters, one or more subnet associations, and an optional description of up to 256 characters. When you configure a network, you can dedicate the network to replication traffic or dedicate the network to MAPI traffic.

NetworkNumber/# of bits in the network ID

You can create a network for a database availability group by completing the following steps:

When the DAG is selected in Exchange Admin Center, the details pane lists the networks associated with the DAG. If manual configuration of networks is enabled, you’ll see options for managing each network in the details pane, as shown in Figure 2-7, and these options include:

Figure 2-7. View the networks configured for a DAG.

The properties dialog box for a DAG network also shows the status of subnets and network interfaces. Subnets and interfaces listed as Up are active. Subnets and interfaces listed as Down are inactive.

In the Exchange Management Shell, you can list availability DAG networks and their status by using Get-DatabaseAvailabilityGroupNetwork. If you enter Get-DatabaseAvailabilityGroupNetwork without additional parameters, you see a list of all configured networks for all availability groups. Use the –Identity parameter to specify the name of the network to query. Use the –Server parameter to obtain health information for the network from a specific Mailbox server. This example lists detailed information for all the networks associated with EastCampusDAG1:

Get-DatabaseAvailabilityGroupNetwork -Identity EastCampusDAG1 | fl

The following example lists detailed information for network associated with EastCampusDAG1 that have names starting with Repl:

Get-DatabaseAvailabilityGroupNetwork -Identity EastCampusDAG1Repl* | fl

The detailed information is helpful as it lists the status of associated subnets and interfaces as shown in the following sample:

Name               : Repl Network EastCampusDAG1
Description        :
Subnets            : {{10.0.0.0/24,Up}}
Interfaces         : {{MailServer21,Up,10.0.0.50},
                     {MAILSERVER42,Up,10.0.0.60}}
MapiAccessEnabled  : True
ReplicationEnabled : True
IgnoreNetwork      : False
Identity           : EastCampusDAG1Repl Network EastCampusDAG1
IsValid            : True

You create or remove group networks by using New-DatabaseAvailabilityGroupNetwork and Remove-DatabaseAvailabilityGroupNetwork. New-DatabaseAvailabilityGroupNetwork cmdlet syntax and usage and Remove-DatabaseAvailabilityGroupNetwork cmdlet syntax and usage provide the syntax and usage.

Syntax
New-DatabaseAvailabilityGroupNetwork -Name NetworkName
-DatabaseAvailabilityGroup DAGName
[-Description Description] [-DomainController FullyQualifiedName]
[-IgnoreNetwork <$true | $false>] [-ReplicationEnabled <$true | $false>]
[-Subnets SubnetIds]

Usage
New-DatabaseAvailabilityGroupNetwork –DatabaseAvailabilityGroup
"EastCampusDAG1" -Name "Primary DAG Network" -Description ""
-Subnets "{192.168.10.0/24, 192.168.15.0/24}" -ReplicationEnabled $true

Syntax
Remove-DatabaseAvailabilityGroupNetwork -Identity NetworkName
[-DomainController FullyQualifiedName]

Usage
Remove-DatabaseAvailabilityGroupNetwork
–Identity "EastCampusDAG1Primary DAG Network"

Database availability group networks have several properties that you can configure, including the network name, description, associated subnets, and replication status. The replication status determines whether the network is used as the replication network for the group or the messaging network for the group. When replication is enabled, the network is used as the replication network for the group. When replication is disabled, the network is used as the messaging network for the group.

When manual network configuration is enabled, you can manage the settings for a group network by completing the following steps:

You can use Set-DatabaseAvailabilityGroupNetwork to configure basic settings for Set-DatabaseAvailabilityGroupNetwork. Set-DatabaseAvailabilityGroupNetwork cmdlet syntax and usage provides the syntax and usage.

Syntax
Set-DatabaseAvailabilityGroupNetwork -Identity NetworkName
[-Description Description] [-DomainController FullyQualifiedName]
[-IgnoreNetwork <$true | $false>] [-Name NewName]
[-ReplicationEnabled <$true | $false>] [-Subnets Subnets]

Usage
Set-DatabaseAvailabilityGroupNetwork
–Identity "EastCampusDAG1Primary DAG Network"
-ReplicationEnabled $False

Advanced options for the networks associated with availability groups are set at the group level. Advanced options you can configure include encryption, compression, and the TCP port used for replication. Database availability groups support data encryption by using the built-in encryption capabilities of the Windows Server operating system. When you enable encryption, database availability groups use Kerberos authentication between Exchange servers to encrypt and decrypt messages. Encryption helps maintain the integrity of the data. Network encryption is a property of the database availability group and not a property of a database availability group network.

You can configure database availability group network encryption by using the –NetworkEncryption parameter of the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. The possible encryption settings are as follows:

Database availability groups also support built-in compression. You configure network compression by using the –NetworkCompression parameter of the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. The possible compression settings are as follows:

You can specify the TCP port to use for replication by using the –ReplicationPort parameter of the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell.

You can use the Exchange Admin Center or the Exchange Management Shell to configure the properties of a database availability group, including the witness server and witness directory used by the database availability group. By using the Exchange Management Shell, you can configure additional properties, such as encryption and compression settings, network discovery, the TCP port used for replication, alternate file share witness settings, and data center activation coordination mode.

To view or modify the properties of an availability group, complete the following steps:

In the Exchange Management Shell, you can configure properties of database availability groups by using the Set-DatabaseAvailabilityGroup cmdlet. Set-DatabaseAvailabilityGroup cmdlet syntax and usage provides the syntax and usage.

Syntax
Set-DatabaseAvailabilityGroup -Identity DAGName
[-DatabaseAvailabilityGroupIpAddresses IPAddresses]
[-DatacenterActivationMode {"Off"|"DagOnly"}]
[-DiscoverNetworks] [-DomainController FullyQualifiedName]
[-NetworkCompression {"Disabled"|"Enabled"|"InterSubnetOnly"|"SeedOnly"}
[-NetworkEncryption {"Disabled"|"Enabled"|"InterSubnetOnly"|"SeedOnly"}
[-ReplicationPort TCPPort] [-AlternateWitnessServer ServerName]
[-AlternateWitnessServerDirectory DirectoryPath]
[-WitnessServer ServerName] [-WitnessServerDirectory DirectoryPath]

Usage
Set-DatabaseAvailability –Identity "EastCampusDAG1"
-NetworkCompression "Enabled" -NetworkEncryption "Enabled"
-ReplicationPort 33898 –DatacenterActivationMode "Off"

Options for working with encryption, compression, and replication ports were discussed previously in “Changing availability group network settings.” Options that weren’t discussed include the datacenter activation coordinator mode, the alternate witness server, and alternate witness server directory. These options can be used as part of a datacenter switchover process. The alternate witness server must not be a part of the database availability group.

The data-center coordinator mode should be set for all database availability groups with three or more members that are extended to two or more physical locations. This mode cannot be enabled for groups with less than three members. When the datacenter coordinator is enabled, you can start, stop, and restore member servers in an availability group individually or collectively by using the following:

Before you can remove a server from a database availability group, you must also remove all database copies from the server. To remove member servers from a DAG, select the DAG you want to manage, and then select the Manage DAG Membership button. In the Manage Database Availability Group Membership dialog box, select a server on the list of current members, and then select the Remove button. Repeat as necessary to remove members. Tap or click Save to apply the changes. If an error occurs during these tasks, you will need to take the appropriate corrective action. Otherwise, tap or click Close when these tasks have completed successfully.

After you remove the member servers, you can remove the database availability group by selecting it and selecting the Delete button. When prompted to confirm, tap or click Yes.

You can remove a database availability group only if it has no member servers. Therefore, before you can remove a database availability group, you must first remove any member servers from the group.

You can remove an empty availability group by completing the following steps:

In the Exchange Management Shell, you can remove database availability groups by using the Remove-DatabaseAvailabilityGroup cmdlet. Remove-DatabaseAvailabilityGroup cmdlet syntax and usage provides the syntax and usage.

Syntax
Remove-DatabaseAvailabilityGroup -Identity DAGName
[-DomainController FullyQualifiedName]

Usage
Remove-DatabaseAvailabilityGroup –Identity "EastCampusDAG1"

Failover and switchover occur at the database level for individual databases and at the server level for all active databases hosted by a server. When either a switchover or failover occurs, other Exchange 2013 server roles become aware of the switchover almost immediately and redirect client and messaging traffic automatically as appropriate.

You can switch over all active databases on a server by completing the following steps:

You can perform a switchover of an individual database by completing the following steps:

When you are working with the Exchange Management Shell, you can initiate switchover by using Move-ActiveMailboxDatabase. Move-ActiveMailboxDatabase cmdlet syntax and usage shows the syntax and usage.

Syntax
Move-ActiveMailboxDatabase -Identity DatabaseName
[-SkipClientExperienceChecks <$true | $false>] [-SkipHealthChecks
<$true | $false>] [-SkipLagChecks <$true | $false>] {AddtlParams}
Move-ActiveMailboxDatabase -Server ServerName {AddtlParams}
{AddtlParams}
[-ActivateOnServer ServerOnWhichToActivate] [-MountDialOverride
{"Lossless" | "GoodAvailability" | "BestAvailability"
"BestEffort" | "None"} [-DomainController FullyQualifiedName]
[-MoveComment Comment] [-SkipActiveCopyChecks <$true | $false>]
[-SkipClientExperienceChecks <$true | $false>]
[-SkipHealthChecks <$true | $false>] [-SkipLagChecks <$true | $false>]
[-TerminateOnWarning <$true | $false>]

Usage
Move-ActiveMailboxDatabase –Identity "Engineering Primary Database"
-ActivateOnServer "MailServer86" -MountDialOverride "Lossless"

The –MountDailOverride parameter of the Move-ActiveMailboxDatabase cmdlet controls the way databases mount on switchover or failover. Every Mailbox server has a database automount setting and the default is Best Availability. Values you can select to control the database mount behavior include:

You can use Test-ReplicationHealth to monitor continuous replication and determine the health and status of the underlying cluster service, quorum, and network components. By default, Test-ReplicationHealth performs the following tests:

Test-ReplicationHealth cmdlet syntax and usage shows the syntax and usage for Test-ReplicationHealth. If you want to include monitoring events and performance counters in the results, set the -MonitoringContext parameter to $true. Use -OutputObjects to output an array of results.

Syntax
Test-ReplicationHealth [-Identity MailboxServerToCheck]
[-ActiveDirectoryTimeout Timeout] [-DomainController DCName]
[-MonitoringContext <$true | $false>] [-OutputObjects]
[-TransientEventSuppressionWindow Timeout]

Usage
Test-ReplicationHealth –Identity MailServer15 -ActiveDirectoryTimeout 30
-OutputObjects

If a Mailbox server has failed and cannot be recovered, you can recover operations in one of two ways:

Before you can remove the configuration settings for a Mailbox server, you’ll need to remove any mailbox database copies that the server hosted. You can list mailbox database copies by using Get-MailboxDatabaseCopyStatus and then remove the copies by using Remove-Mailbox-DatabaseCopy. Next, remove the configuration settings for the Mailbox server from the database availability group by using the Remove-DatabaseAvailabilityGroupServer cmdlet. After you remove the configuration settings, all settings associated with the Mailbox server are gone.

To install a new server and then restore the roles and settings of the original server, complete the following steps: