Managing Database Availability Groups

 

Applies to: Exchange Server 2010 SP2, Exchange Server 2010 SP3

A database availability group (DAG) is a set of up to 16 Microsoft Exchange Server 2010 Mailbox servers that provides automatic, database-level recovery from a database, server, or network failure. DAGs use continuous replication and a subset of Windows failover clustering technologies to provide high availability and site resilience. Mailbox servers in a DAG monitor each other for failures. When a Mailbox server is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery from database failures.

When you create a DAG, it's initially empty, and a directory object is created in Active Directory that represents the DAG. The directory object is used to store relevant information about the DAG, such as server membership information. When you add the first server to a DAG, a failover cluster is automatically created for the DAG. In addition, the infrastructure that monitors the servers for network or server failures is initiated. The failover cluster heartbeat mechanism and cluster database are then used to track and manage information about the DAG that can change quickly, such as database mount status, replication status, and last mounted location.

Contents

Creating DAGs

DAG Membership

Configuring DAG Properties

DAG Networks

Configuring DAG Members

Performing Maintenance on DAG Members

Shutting Down DAG Members

Installing Update Rollups on DAG Members

Creating DAGs

A DAG can be created using the New Database Availability Group wizard in the Exchange Management Console (EMC), or by running the New-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. When creating a DAG, you provide a name for the DAG, and optional witness server and witness directory settings. In addition, one or more IP addresses are assigned to the DAG, either by using static IP addresses or by allowing the DAG to be automatically assigned the necessary IP addresses using Dynamic Host Configuration Protocol (DHCP). You can manually assign IP addresses to the DAG by using the DatabaseAvailabilityGroupIpAddresses parameter. If you omit this parameter, the DAG attempts to obtain an IP address by using a DHCP server on your network.

For detailed steps about how to create a DAG, see Create a Database Availability Group.

When you create a DAG, an empty object representing the DAG with the name you specified and an object class of msExchMDBAvailabilityGroup is created in Active Directory.

DAGs use a subset of Windows failover clustering technologies, such as the cluster heartbeat, cluster networks, and cluster database (for storing data that changes or can change quickly, such as database state changes from active to passive or the reverse, or from mounted to dismounted or the reverse). Because DAGs rely on Windows failover clustering, they can only be created on Exchange 2010 Mailbox servers running the Windows Server 2008 Enterprise operating system or Windows Server 2008 R2 Enterprise operating system.

DAG Witness Server and Witness Directory

When creating a DAG, you need to specify a name for the DAG no longer than 15 characters that's unique within the Active Directory forest. In addition, each DAG is configured with a witness server and witness directory. The witness server and its directory are used only for quorum purposes where there's an even number of members in the DAG. You don't need to create the witness directory in advance. Exchange automatically creates and secures the directory for you on the witness server. The directory shouldn't be used for any purpose other than for the DAG witness server.

The requirements for the witness server are as follows:

• The witness server can't be a member of the DAG.

• The witness server must be in the same Active Directory forest as the DAG.

• The witness server must be running Windows Server 2003 or later.

• A single server can serve as a witness for multiple DAGs. However, each DAG requires its own witness directory.

We recommend that you use an Exchange 2010 Hub Transport server in the Active Directory site containing the DAG. This allows the witness server and directory to remain under the control of an Exchange administrator. Regardless of what server is used as the witness server, if the Windows Firewall is enabled on the intended witness server, you must enable the Windows Firewall exception for File and Printer Sharing.

Neither the witness server nor the witness directory needs to be fault tolerant or use any form of redundancy or high availability. There's no need to use a clustered file server for the witness server or employ any other form of resiliency for the witness server. There are several reasons for this. With larger DAGs (for example, six members or more), several failures are required before the witness server is needed. Because a six-member DAG can tolerate as many as two voter failures without losing quorum, it would take as many as three voters failing before the witness server would be needed to maintain a quorum. Also, if there's a failure that affects your current witness server (for example, you lose the witness server because of a hardware failure), you can use the Set-DatabaseAvailabilityGroup cmdlet to configure a new witness server and witness directory (provided you have a quorum).

As a best practice, in an environment where a DAG is extended across multiple datacenters (and Active Directory sites) and configured for site resilience, we recommend that you use a witness server in your primary data center (the data center containing the majority of your user population). If each data center has a similar number of users, the data center you choose to host the witness server is considered to be the primary datacenter from the solution's perspective. If the witness server is in the datacenter with the majority of the client population, the majority of clients retain access after a failure.

If the datacenter is remote to large user populations, this may affect your decision. You would then need to determine if there's a requirement for the primary datacenter to remain healthy and active if there's a loss of wide are network (WAN) connectivity to the other two datacenters. In that event, the witness server should also be in the primary datacenter.

Although it's supported to use a witness server in a third datacenter, we don't recommend this scenario. From an Exchange perspective, this configuration doesn't provide you with greater availability. It's important that you examine the critical path factors if you use a witness server in a third datacenter. For example, if the WAN connection between the primary datacenter and the second and third datacenter fails, the solution in the primary datacenter becomes unavailable.

Specifying a Witness Server and Witness Directory During DAG Creation

When creating a DAG, you must provide a name for the DAG. You can optionally also specify a witness server and witness directory. If you specify a witness server, we recommend that you use a Hub Transport server, because this allows an Exchange administrator to be aware of the availability of the witness server.

When creating a DAG, the following combinations of options and behaviors are available:

• You can specify only a name for the DAG, and leave the Witness server and Witness directory fields blank. In this scenario, the wizard searches for a Hub Transport server that doesn't have the Mailbox server role installed, and it automatically creates the default directory (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN>) and default share (<DAGFQDN>) on that server and uses that Hub Transport server as the witness server. For example, consider a witness server named EXMBX3 on which the operating system has been installed onto drive C. A DAG named DAG1 in a domain named contoso.com would use a default witness directory of C:\DAGFileShareWitnesses\DAG1.contoso.com, which would be shared as \\EXMBX3\DAG1.contoso.com.

• You can specify a name for the DAG, the witness server that you want to use, and the directory you want created and shared on the witness server.

• You can specify a name for the DAG and the witness server that you want to use, and leave the Witness directory field blank. In this scenario, the wizard creates the default directory on the specified witness server.

• You can specify a name for the DAG, leave the Witness server field blank, and specify the directory you want created and shared on the witness server. In this scenario, the wizard searches for a Hub Transport server that doesn't have the Mailbox server role installed, and it automatically creates the specified DAG on that server, shares the directory, and uses that Hub Transport server as the witness server.

When a DAG is formed, it initially uses the Node Majority quorum model. When the second Mailbox server is added to the DAG, the quorum is automatically changed to a Node and File Share Majority quorum model. When this change occurs, the DAG begins using the witness server for maintaining a quorum. If the witness directory doesn't exist, Exchange automatically creates it, shares it, and provisions the share with full control permissions for the cluster name object (CNO) computer account for the DAG.

If Windows Firewall is enabled on the witness server before the DAG is created, it may block the creation of the DAG. Exchange uses Windows Management Instrumentation (WMI) to create the directory and file share on the witness server. If Windows Firewall is enabled on the witness server and there are no firewall exceptions configured for WMI, the New-DatabaseAvailabilityGroup cmdlet fails with an error. If you specify a witness server, but not a witness directory, you receive the following error message.

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

If you specify a witness server and witness directory, you receive the following warning message.

Unable to access file shares on witness server 'ServerName'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

If Windows Firewall is enabled on the witness server after the DAG is created but before servers are added, it may block the addition or removal of DAG members. If Windows Firewall is enabled on the witness server and there are no firewall exceptions configured for WMI, the Add-DatabaseAvailabilityGroupServer cmdlet displays the following warning message.

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server 'ServerName'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server 'ServerName': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

To resolve the preceding error and warnings, do one of the following:

• Manually create the witness directory and share on the witness server, and assign the CNO for the DAG full control for the directory and share.

• Enable the WMI exception in Windows Firewall.

• Disable Windows Firewall.

Return to top

DAG Membership

After a DAG has been created, you can add servers to or remove servers from the DAG using the Manage Database Availability Group wizard in the EMC, or using the Add-DatabaseAvailabilityGroupServer or Remove-DatabaseAvailabilityGroupServer cmdlets in the Shell. For detailed steps about how to manage DAG membership, see Manage Database Availability Group Membership.

If the Mailbox server being added to a DAG doesn't have the failover clustering component installed, the method used to add the server (for example, the Add-DatabaseAvailabilityGroupServer cmdlet or the Manage Database Availability Group wizard) installs the failover clustering feature.

When the first Mailbox server is added to a DAG, the following occurs:

• The Windows failover clustering component is installed, if it isn't already installed.

• A failover cluster is created using the name of the DAG. This failover cluster is used exclusively by the DAG, and the cluster must be dedicated to the DAG. Use of the cluster for any other purpose isn't supported.

• A CNO is created in the default computers container.

• The name and IP address of the DAG is registered as a Host (A) record in Domain Name System (DNS).

• The server is added to the DAG object in Active Directory.

• The cluster database is updated with information on the databases mounted on the added server.

In a large or multiple site environment, especially those in which the DAG is extended to multiple Active Directory sites, you must wait for Active Directory replication of the DAG object containing the first DAG member to complete. If this Active Directory object isn't replicated throughout your environment, adding the second server may cause a new cluster (and new CNO) to be created for the DAG. This is because the DAG object appears empty from the perspective of the second member being added, thereby causing the Add-DatabaseAvailabilityGroupServer cmdlet to create a cluster and CNO for the DAG, even though these objects already exist. To verify that the DAG object containing the first DAG server has been replicated, use the Get-DatabaseAvailabilityGroup cmdlet on the second server being added to verify that the first server you added is listed as a member of the DAG.

When the second and subsequent servers are added to the DAG, the following occurs:

• The server is joined to the Windows failover cluster for the DAG.

• The quorum model is automatically adjusted:

  • A Node Majority quorum model is used for DAGs with an odd number of members.

  • A Node and File Share Majority quorum model is used for DAGs with an even number of members.

• The witness directory and share are automatically created by Exchange when needed.

• The server is added to the DAG object in Active Directory.

• The cluster database is updated with information about mounted databases.

Pre-Staging the Cluster Name Object for a DAG

The CNO is a computer account created in Active Directory and associated with the cluster's Name resource. The cluster's Name resource is tied to the CNO, which is a Kerberos-enabled object that acts as the cluster's identity and provides the cluster's security context. In Exchange 2007, this Kerberos-enabled machine account was created in the domain using the security context of the user performing the tasks. This required the user's account to have permissions to create and enable machine accounts in the domain or that the computer account was properly pre-staged and provisioned.

The formation of the DAG's underlying cluster and the CNO for that cluster is performed when the first member is added to the DAG. When the first server is added to the DAG, Powershell contacts the Microsoft Exchange Replication service on the Mailbox server being added. The Microsoft Exchange Replication service installs the failover clustering feature (if it isn't already installed) and begins the cluster creation process. The Microsoft Exchange Replication service runs under the LOCAL SYSTEM security context, and it's under this context in which cluster creation is performed.

In environments where computer account creation is restricted, or where computer accounts are created in a container other than the default computers container, you can pre-stage and provision the CNO. You create and disable a computer account for the CNO, and then either:

• Assign full control of the computer account to the computer account of the first Mailbox server you're adding to the DAG.

• Assign full control of the computer account to the Exchange Trusted Subsystem USG.

Assigning full control of the computer account to the computer account of the first Mailbox server you're adding to the DAG ensures that the LOCAL SYSTEM security context will be able to manage the pre-staged computer account. Assigning full control of the computer account to the Exchange Trusted Subsystem USG can be used instead because the Exchange Trusted Subsystem USG contains the machine accounts of all Exchange servers in the domain.

For detailed steps about how to pre-stage and provision the CNO for a DAG, see Pre-stage the Cluster Name Object for a Database Availability Group.

Removing Servers from a DAG

Mailbox servers can be removed from a DAG by using the Manage Database Availability Group wizard in the EMC or the Remove-DatabaseAvailabilityGroupServer cmdlet in the Shell. Before a Mailbox server can be removed from a DAG, all replicated mailbox databases must first be removed from the server. If you attempt to remove a Mailbox server with replicated mailbox databases from a DAG, the task fails.

There are scenarios in which you must remove a Mailbox server from a DAG before performing certain operations. These scenarios include:

• Performing a server recovery operation   If a Mailbox server that's a member of a DAG is lost, or otherwise fails and is unrecoverable and needs replacement, you can perform a server recovery operation using the Setup /m:RecoverServer switch. However, before you can perform the recovery operation, you must first remove the server from the DAG using the Remove-DatabaseAvailabilityGroupServer cmdlet with the ConfigurationOnly parameter.

• Removing the database availability   There may be situations in which you need to remove a DAG (for example, when disabling third-party replication mode). If you need to remove a DAG, you must first remove all servers from the DAG. If you attempt to remove a DAG that contains one or more members, the task fails.

Return to top

Configuring DAG Properties

After servers have been added to the DAG, you can use the EMC or the Shell to configure the properties of a DAG, including the witness server and witness directory used by the DAG, and the IP addresses assigned to the DAG.

Configurable properties include:

• Witness server   The name of the server that you want to host the file share for the file share witness. We recommend that you specify a Hub Transport server outside the DAG as the witness server. This enables the system to automatically configure, secure, and use the share, as needed.

• Witness directory   The name of a directory that will be used to store file share witness data. This directory will automatically be created by the system on the specified witness server.

• Database availability group IP addresses   One or more IP addresses assigned to the DAG. These addresses can be configured using manually assigned static IP addresses, or they can be automatically assigned to the DAG using a DHCP server in your organization.

The Shell enables you to configure DAG properties that aren't available in the EMC, such as DAG IP addresses, network encryption and compression settings, network discovery, the TCP port used for replication, and alternate witness server and witness directory settings, and to enable Datacenter Activation Coordination mode.

For detailed steps about how to configure DAG properties, see Configure Database Availability Group Properties.

DAG Network Encryption

DAGs support the use of encryption by leveraging the encryption capabilities of the Windows Server operating system. DAGs use Kerberos authentication between Exchange servers. Microsoft Kerberos security support provider (SSP) EncryptMessage and DecryptMessage APIs handle encryption of DAG network traffic. Microsoft Kerberos SSP supports multiple encryption algorithms. (For the complete list, see section 3.1.5.2, "Encryption Types" of Kerberos Protocol Extensions). The Kerberos authentication handshake selects the strongest encryption protocol supported in the list: typically Advanced Encryption Standard (AES) 256-bit, potentially with a SHA Hash-based Message Authentication Code (HMAC) to maintain integrity of the data. For details, see HMAC.

Network encryption is a property of the DAG and not a DAG network. You can configure DAG network encryption using the Set-DatabaseAvailabilityGroup cmdlet in the Shell. The possible encryption settings for DAG network communications are shown in the following table.

DAG network communication encryption settings

Setting	Description
Disabled	Network encryption isn't used.
Enabled	Network encryption is used on all DAG networks for replication and seeding.
InterSubnetOnly	Network encryption is used on DAG networks when replicating across different subnets. This is the default setting.
SeedOnly	Network encryption is used on all DAG networks for seeding only.

DAG Network Compression

DAGs support built-in compression. When compression is enabled, DAG network communication uses XPRESS, which is the Microsoft implementation of the LZ77 algorithm. For details, see An Explanation of the Deflate Algorithm and section 3.1.7.2 "Compression Algorithm" of Wire Format Protocol Specification. This is the same type of compression used in many Microsoft protocols, in particular, MAPI RPC compression between Microsoft Outlook and Exchange.

As with network encryption, network compression is also a property of the DAG and not a DAG network. You configure DAG network compression by using the Set-DatabaseAvailabilityGroup cmdlet in the Shell. The possible compression settings for DAG network communications are shown in the following table.

DAG network communication compression settings

Setting	Description
Disabled	Network compression isn't used.
Enabled	Network compression is used on all DAG networks for replication and seeding.
InterSubnetOnly	Network compression is used on DAG networks when replicating across different subnets. This is the default setting.
SeedOnly	Network compression is used on all DAG networks for seeding only.

Return to top

DAG Networks

A DAG network is a collection of one or more subnets used for either replication traffic or MAPI traffic. Each DAG contains a maximum of one MAPI network and zero or more replication networks. In a single network adapter configuration, the network is used for both MAPI and replication traffic. Although a single network adapter and path is supported, we recommend that each DAG have a minimum of two DAG networks. In a two-network configuration, one network is typically dedicated for replication traffic, and the other network is used primarily for MAPI traffic. You can also add network adapters to each DAG member and configure additional DAG networks as replication networks.

You can use the New Database Availability Group Network wizard in the EMC or the New-DatabaseAvailabilityGroupNetwork cmdlet in the Shell to create a DAG network. For detailed steps about how to create a DAG network, see Create a Database Availability Group Network.

You can use the DAG network's Properties dialog box in the EMC or the Set-DatabaseAvailabilityGroupNetwork cmdlet in the Shell to configure DAG network properties. For detailed steps about how to configure DAG network properties, see Configure Database Availability Group Network Properties. Each DAG network has required and optional parameters to configure:

• Network name   A unique name for the DAG network of up to 128 characters.

• Network description   An optional description for the DAG network of up to 256 characters.

• Network subnets   One or more subnets entered using a format of IPAddress/Bitmask (for example, 192.168.1.0/24 for Internet Protocol version 4 (IPv4) subnets; 2001:DB8:0:C000::/64 for Internet Protocol version 6 (IPv6) subnets).

• Enable replication   In the EMC, select the check box to dedicate the DAG network to replication traffic, and block MAPI traffic. Clear the check box to prevent replication from using the DAG network, and to enable MAPI traffic. In the Shell, use the ReplicationEnabled parameter in the Set-DatabaseAvailabilityGroupNetwork cmdlet to enable and disable replication.

The initial DAG networks (for example, DAGNetwork01 and DAGNetwork02) created by the system are based on the subnets enumerated by the Cluster service. Each DAG member must have the same number of network adapters, and each network adapter must have an IPv4 address (and optionally, an IPv6 address as well) on a unique subnet. Multiple DAG members can have IPv4 addresses on the same subnet, but each network adapter and IP address pair in a specific DAG member must be on a unique subnet. In addition, only the adapter used for the MAPI network should be configured with a default gateway. Replication networks shouldn't be configured with a default gateway.

For example, consider DAG1, a two-member DAG where each member has two network adapters (one dedicated for the MAPI network and the other for a replication network). Example IP address configuration settings are shown in the following table.

Example network adapter settings

Server-network adapter	IP address/subnet mask	Default gateway
EX1-MAPI	192.168.1.15/24	192.168.1.1
EX1-Replication	10.0.0.15/24	Not applicable
EX2-MAPI	192.168.1.16	192.168.1.1
EX2-Replication	10.0.0.16	Not applicable

In the following configuration, there are two subnets configured in the DAG: 192.168.1.0 and 10.0.0.0. When EX1 and EX2 are added to the DAG, two subnets will be enumerated and two DAG networks will be created: DAGNetwork01 (192.168.1.0) and DAGNetwork02 (10.0.0.0). These networks will be configured as shown in the following table.

Enumerated DAG network settings for a single-subnet DAG

Name	Subnets	Interfaces	MAPI access enabled	Replication enabled
DAGNetwork01	192.168.1.0/24	EX1 (192.168.1.15) EX2 (192.168.1.16)	True	True
DAGNetwork02	10.0.0.0/24	EX1 (10.0.0.15) EX2 (10.0.0.16)	False	True

To complete the configuration of DAGNetwork02 as the dedicated replication network, disable replication for DAGNetwork01 by running the following command.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\DAGNetwork01 -ReplicationEnabled:$false

After replication is disabled for DAGNetwork01, the Microsoft Exchange Replication service uses DAGNetwork02 for continuous replication. If DAGNetwork02 experiences a failure, the Microsoft Exchange Replication service reverts to using DAGNetwork01 for continuous replication. This is done intentionally by the system to maintain high availability.

DAG Networks and Multiple Subnet Deployments

In the preceding example, even though there are two different subnets in use by the DAG (192.168.1.0 and 10.0.0.0), the DAG is considered a single-subnet DAG because each member uses the same subnet to form the MAPI network. When DAG members use different subnets for the MAPI network, the DAG is referred to as a multi-subnet DAG. In a multi-subnet DAG, additional configuration of the DAG networks must be performed to associate the proper subnets with each DAG network.

For example, consider DAG2, a two-member DAG where each member has two network adapters (one dedicated for the MAPI network and the other for a replication network), and each DAG member is located in a separate Active Directory site, with its MAPI network on a different subnet. Example IP address configuration settings are shown in the following table.

Example network adapter settings for a multi-subnet DAG

Server-network adapter	IP address/subnet mask	Default gateway
EX1-MAPI	192.168.0.15/24	192.168.0.1
EX1-Replication	10.0.0.15/24	Not applicable
EX2-MAPI	192.168.1.15	192.168.1.1
EX2-Replication	10.0.1.15	Not applicable

In the following configuration, there are four subnets configured in the DAG: 192.168.0.0, 192.168.1.0, 10.0.0.0, and 10.0.1.0. When EX1 and EX2 are added to the DAG, four subnets will be enumerated and two DAG networks will be created: DAGNetwork01 (192.168.0.0), DAGNetwork02 (10.0.0.0), DAGNetwork03 (192.168.1.0), and DAGNetwork04 (10.0.1.0). These networks will be configured as shown in the following table.

Enumerated DAG network settings for a multi-subnet DAG

Name	Subnets	Interfaces	MAPI access enabled	Replication enabled
DAGNetwork01	192.168.0.0/24	EX1 (192.168.0.15)	True	True
DAGNetwork02	10.0.0.0/24	EX1 (10.0.0.15)	False	True
DAGNetwork03	192.168.1.0/24	EX2 (192.168.1.15)	True	True
DAGNetwork04	10.0.1.0/24	EX2 (10.0.1.15)	False	True

To complete the necessary configuration, DAGNetwork03 and DAGNetwork04 should be collapsed into DAGNetwork01 and DAGNetwork02, respectively. This involves adding the subnet currently associated with DAGNetwork03 to DAGNetwork01, and adding the subnet currently associated with DAGNetwork04 to DAGNetwork02. This will remove the subnet associations from DAGNetwork03 and DAGNetwork04, leaving them as empty DAG networks that can then be removed. To collapse the subnets into two DAG networks and disable replication on the MAPI network, run the following commands.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork01 -Subnets 192.168.0.0,192.168.1.0 -ReplicationEnabled:$false
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -Subnets 10.0.0.0,10.0.1.0
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork03
Remove-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork04

DAG Networks and iSCSI Networks

By default, DAGs perform discovery of all networks detected and configured for use by the underlying cluster. This includes any Internet SCSI (iSCSI) networks in use as a result of using iSCSI storage for one or more DAG members. As a best practice, iSCSI storage should use dedicated networks and network adapters. These networks shouldn't be managed by the DAG or its cluster, or used as DAG networks (MAPI or replication). Instead, these networks should be manually disabled from use by the DAG, so they can be dedicated to iSCSI storage traffic. To disable iSCSI networks from being detected and used as DAG networks, configure the DAG to ignore any currently detected iSCSI networks using the Set-DatabaseAvailabilityGroupNetwork cmdlet, as shown in this example:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

This command will also disable the network for use by the cluster. Although the iSCSI networks will continue to appear as DAG networks, they will not be used for MAPI or replication traffic after running the above command.

Return to top

Configuring DAG Members

Mailbox servers that are members of a DAG have some properties specific to high availability that should be configured as described in the following sections:

• Automatic Database Mount Dial

• Database Copy Automatic Activation Policy

• Maximum Active Databases

Automatic Database Mount Dial

The AutoDatabaseMountDial parameter specifies the automatic database mount behavior after a database failover. You can use the Set-MailboxServer cmdlet to configure the AutoDatabaseMountDial parameter with any of the following values:

• BestAvailability   If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to 12. The copy queue length is the number of logs recognized by the passive copy that needs to be replicated. If the copy queue length is more than 12, the database doesn't automatically mount. When the copy queue length is less than or equal to 12, Exchange attempts to replicate the remaining logs to the passive copy and mounts the database.

• GoodAvailability   If you specify this value, the database automatically mounts immediately after a failover if the copy queue length is less than or equal to six. The copy queue length is the number of logs recognized by the passive copy that needs to be replicated. If the copy queue length is more than six, the database doesn't automatically mount. When the copy queue length is less than or equal to six, Exchange attempts to replicate the remaining logs to the passive copy and mounts the database.

• Lossless   If you specify this value, the database doesn't automatically mount until all logs generated on the active copy have been copied to the passive copy. This setting also causes the Active Manager best copy selection algorithm to sort potential candidates for activation based on the database copy's activation preference value and not its copy queue length.

The default value is GoodAvailability. If you specify either BestAvailability or GoodAvailability, and all the logs from the active copy can't be copied to the passive copy being activated, you may lose some mailbox data. However, the transport dumpster feature (which is enabled by default) helps protect against most data loss by resubmitting messages that are in the transport dumpster queue.

In addition to the preceding values, you can also configure the AutoDatabaseMountDial parameter with a custom value by using ADSI Edit or Ldp.exe to modify the attribute directly in Active Directory. The AutoDatabaseMountDial parameter is represented by the msExchDataLossForAutoDatabaseMount attribute of the Mailbox server object. The whole number numeric value for this attribute represents the maximum number of transaction log files you are willing to lose to mount a database without human intervention. If you configure the AutoDatabaseMountDial parameter with a custom value greater than 12, we recommend that you also increase the size of the transport dumpster to enable increased protection against a greater number of lost logs.

Example: Configuring Automatic Database Mount Dial

The following example configures a Mailbox server with an AutoDatabaseMountDial setting of GoodAvailability.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Database Copy Automatic Activation Policy

The DatabaseCopyAutoActivationPolicy parameter specifies the type of automatic activation available for mailbox database copies on the selected Mailbox servers. You can use the Set-MailboxServer cmdlet to configure the DatabaseCopyAutoActivationPolicy parameter with any of the following values:

• Blocked   If you specify this value, databases can't be automatically activated on the selected Mailbox servers.

• IntrasiteOnly   If you specify this value, the database copy is allowed to be activated on servers in the same Active Directory site. This prevents cross-site failover or activation. This property is for incoming mailbox database copies (for example, a passive copy being made an active copy). Databases can't be activated on this Mailbox server for database copies that are active in another Active Directory site.

• Unrestricted   If you specify this value, there are no special restrictions on activating mailbox database copies on the selected Mailbox servers.

Example: Configuring Database Copy Automatic Activation Policy

The following example configures a Mailbox server with a DatabaseCopyAutoActivationPolicy setting of Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Maximum Active Databases

The MaximumActiveDatabases parameter (also used with the Set-MailboxServer cmdlet) specifies the number of databases that can be mounted on a Mailbox server. You can configure Mailbox servers to meet your deployment requirements by ensuring that an individual Mailbox server doesn't become overloaded.

The MaximumActiveDatabases parameter is configured with a whole number numeric value. When the maximum number is reached, the database copies on the server won't be activated if a failover or switchover occurs. If the copies are already active on a server, the server won't allow databases to be mounted.

Example: Configuring Maximum Active Databases

The following example configures a Mailbox server to support a maximum of 20 active databases.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Return to top

Performing Maintenance on DAG Members

Before performing any type of software or hardware maintenance on a DAG member, you should first remove the DAG member from service by using the StartDagServerMaintenance.ps1 script. This script moves all the active databases off the server and blocks active databases from moving to that server. The script also ensures that all critical DAG support functionality that may be on the server (for example, the Primary Active Manager (PAM) role) is moved to another server and blocked from moving back to the server. Specifically, the StartDagServerMaintenance.ps1 script performs the following tasks:

• Runs Suspend-MailboxDatabaseCopy with the ActivationOnly parameter to suspend each database copy hosted on the DAG member for activation.

• Pauses the node in the cluster, which prevents the node from being and becoming the PAM.

• Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to Blocked.

• Moves all active databases currently hosted on the DAG member to other DAG members.

• If the DAG member currently owns the default cluster group, the script moves the default cluster group (and therefore the PAM role) to another DAG member.

If any of the preceding tasks fails, all operations, except for successful database moves, are undone.

After the maintenance is complete and the DAG member is ready to return to service, you can use the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance mode and put it back into production. Specifically, the StopDagServerMaintenance.ps1 script performs the following tasks:

• Runs the Resume-MailboxDatabaseCopy cmdlet for each database copy hosted on the DAG member.

• Resumes the node in the cluster, which enables full cluster functionality for the DAG member.

• Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to Unrestricted.

Both scripts accept the -ServerName parameter (which can be either the host name or the fully qualified domain name (FQDN) of the DAG member) and the -WhatIf parameter. Both scripts can be run locally or remotely. The server on which the scripts are executed must have the Windows Failover Cluster Management tools installed (RSAT-Clustering).

Return to top

Shutting Down DAG Members

The Exchange 2010 high availability solution is integrated with the Windows shutdown process. If an administrator or application initiates a shutdown of a Windows server in a DAG that has a mounted database that's replicated to one or more DAG members, the system attempts to activate another copy of the mounted database prior to allowing the shutdown process to complete.

However, this new behavior doesn't guarantee that all of the databases on the server being shut down will experience a lossless activation. As a result, it's a best practice to perform a server switchover prior to shutting down a server that's a member of a DAG. For detailed steps about how to perform a server switchover, see Perform a Server Switchover.

Return to top

Installing Update Rollups on DAG Members

Installing Microsoft Exchange Server 2010 update rollups on a server that is a member of a database availability group (DAG) is a relatively straightforward process. When you install an update rollup on a server that's a member of a DAG, several services are stopped during the installation, including all Exchange services and the Cluster service. The general process for applying update rollups to a DAG member is as follows:

1. Use the StartDagServerMaintenance.ps1 script to put the DAG member in maintenance mode.

2. Install the update rollup.

3. Use the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance mode and put it back into production.

4. Use the RedistributeActiveDatabases.ps1 script to rebalance the active database copies across the DAG.

You can download the latest update rollup for Exchange 2010 from the Microsoft Download Center. For detailed steps about how to install an update rollup on a DAG member, see Installing Update Rollups on Database Availability Group Members.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.