2. Investigating DAG problems
All of the activities performed by DAG
maintenance operations are captured in log files stored in the
\ExchangeSetupLogs\Dagtasks directory. Each log file is named “DagTask”
plus the date and time when the task was performed, so it’s easy to find
the relevant file. Take a look at the following two extracts of example
DAG log files. The first reports the creation of a new DAG.
new-databaseavailabiltygroup started on machine EXSERVER1.
[2009-10-07T09:16:10] new-dag started
[2009-10-07T09:16:10] commandline: $scriptCmd = {& $wrappedCmd
@PSBoundParameters }
[2009-10-07T09:16:10] Option 'Name' = ''.
[2009-10-07T09:16:10] Option 'WitnessServer' = 'AD-SERVER12.CONTOSO.COM'.
[2009-10-07T09:16:10] Option 'WitnessDirectory' = 'c:\FSW\DublinDag'.
[2009-10-07T09:16:10] Option 'WhatIf' = ''.
[2009-10-07T09:16:21] New-DatabaseAvailabilityGroup passed the initial checks.
[2009-10-07T09:16:22] New-DatabaseAvailabilityGroup completed successfully.
new-databaseavailabiltygroup explicitly called CloseTempLogFile().
The second shows that
Exchange detected that Windows Failover Clustering was not installed on a
server when it was added to a DAG, so Exchange went ahead and installed
the component on the server.
[2009-10-07T09:57:49] Updated Progress 'Adding server 'EXSERVER1' to database
availability group 'DAG-Dublin'.' 6%.
[2009-10-07T09:57:49] Working
[2009-10-07T09:57:49] Updated Progress 'The task is installing the Windows
Failover Clustering component on the server EXSERVER1.' 8%.
[2009-10-07T09:57:49] Working
[2009-10-07T10:06:37] The following log entry comes from a different process,
run on machine EXSERVER1'. BEGIN
[2009-10-07T10:06:37] [2009-10-07T09:57:50] Updated Progress 'The task is
installing the Windows Failover Clustering component on the server
exserver1.' 2%.
[2009-10-07T09:57:50] Working
[2009-10-07T10:06:36] Updated Progress 'The task has installed the Windows
Failover Clustering component.' 4%.
The system event log is also a
useful source of information if you need to track down the source of a
problem and in particular, the crimson events logged for the
high-availability channel are often revealing about what happens in
terms of Active Manager . More detailed cluster-related logging is
captured in the Windows\Cluster\Reports directory. This information is
pretty verbose but could hold the key to some of the more esoteric
issues that occur from time to time. One way to limit the mass of data
in the logs that you have to review is to attempt to correlate it with
any event log entries that seem to be related to the problem.
3. Managing DAG properties
After the DAG is
created, you can alter its properties to meet operational requirements
using EMC or the shell. You need to be a member of the Organization
Management role group to be able to modify DAG properties, which are listed in Table 1.
Table 1. DAG properties
| Property | Use |
|---|
| FSW share (WitnessServer) | Path for the share used by the FSW |
| FSW directory (WitnessDirectory) | Name of the directory used by the FSW |
| Alternate FSW share (AlternateWitnessServer) | Path for an alternate FSW |
| Alternate FSW directory (AlternateWitnessDirectory) | Name of an alternate directory used by the FSW |
| Network encryption (NetworkEncryption) | Disabled: No encryption of data on the DAG network
Enabled: Encryption used for replication and seeding
InterSubnetOnly: Encryption used on DAG networks in the same subnet
SeedOnly: Encryption only used for database seeding |
| Network compression (NetworkCompression) | Disabled: No compression
Enabled: Compression used for replication and seeding
InterSubnetOnly: Compression used for DAG networks on the same subnet
SeedOnly: Compression only used for database seeding |
| Replication port (ReplicationPort) | TCP
port used for replication activity; if you change this value from the
default (64327), make sure that you also make the necessary change on
any firewall that is in place to allow replication traffic to pass
through the open port |
| IP addresses (DatabaseAvailabilityGroupIpAddresses) | IP addresses for the subnets used by the Windows failover cluster that underpins the DAG |
You can use the Set-DatabaseAvailabilityGroup cmdlet to update DAG properties
through EMS (only some of these properties are available through EMC).
For example, this command manipulates a number of DAG properties:
Set-DatabaseAvailabilityGroup -Identity 'DAG-Dublin' -WitnessServer
'ExHT1.contoso.com' -WitnessDirectory 'D:\DUBDAG' -AlternativeWitnessServer
'ExHT22.contoso.com' -AlternativeWitnessDirectory 'D:\DUBDAG'
-ReplicationPort 33998 -NetworkEncryption SeedOnly -NetworkCompression Disabled
-DatacenterActivationMode Disabled
Note that the two alternate
FSW properties are only required when a DAG extends across multiple
datacenters.
By default, DAG network traffic is not encrypted or compressed unless it is replicating across different subnets. The NetworkCompression and NetworkEncryption
properties of the DAG are therefore set to InterSubNetOnly. It’s easy
to change these values, as they are both properties of the DAG. As such,
the values that you assign apply to all traffic between all members and
cannot be altered for individual servers. Table 1 includes the available options that you can set for DAG encryption. For example, this command enables compression and encryption for all traffic within a DAG:
Set-DatabaseAvailabilityGroup -Identity 'DAG-Dublin' -NetworkCompression Enabled
-NetworkEncryption Enabled
Note:
Exchange doesn’t introduce any
new code to encrypt its intra-DAG communications. Instead, it uses the
facilities made available in Windows, specifically the Windows Kerberos security
support provider (SSP). This module contains routines that allow
applications to encrypt, decrypt, sign, and verify the data contained in
messages sent between application components such as DAG members. When
two DAG members communicate, they each act as an endpoint and begin the
connection with a handshake and key exchange. Once the connection is set
up, encrypted traffic flows across it that can be decrypted by both
members.
Exchange 2010 also supports compression for intra-DAG communications based on the LZ77 algorithm. Once again, a familiar algorithm is reused as LZ77 (otherwise known as XPRESS) is deployed to protect MAPI RPCs flowing between Outlook and Exchange.
You can use the Get-DatabaseAvailabilityGroup cmdlet to review the properties of a DAG. For example:
Get-DatabaseAvailabilityGroup -Identity 'DAG-Dublin' | Format-List
You might arrive at a situation where you want to change the location of the FSW.
Perhaps the server is unavailable for some reason or it is more
productive to relocate the FSW to another server. In this case, you can
use the Set-DatabaseAvailabilityGroup cmdlet to update the properties
for the FSW. This example command moves the FSW to a server called
ExServer22 (which cannot be a member of the DAG) and specifies a directory on that server to host the resource:
Set-DatabaseAvailabilityGroup -Identity 'DAG-Dublin' -WitnessServer
'ExServer22.contoso.com' -WitnessDirectory 'C:\FSW\DublinDAG'
Moving the FSW should only ever be attempted when the DAG is healthy and the FSW is not actively in use to maintain quorum.
