Creating the DAG via Exchange Management Shell
Many Exchange Server
administrators have embraced the Exchange Management Shell as the
preferred tool for configuration. Doing things via the shell has many
advantages. The primary advantage being that it is very easy to script
configuration and deployment which ensures that all systems are
configured correctly and that no human error occurs while following a
set of directions. To create a DAG via the Exchange Management Shell,
perform the following steps:
1. | Launch Exchange Management Shell.
|
2. | Type New-DatabaseAvailabilityGroup–Name
name–FileShareWitnessDirectory
DirectoryPath–FileShareWitnessShare
UNCPath–DomainController
DC.
For example, New-DatabaseAvailabilityGroup–Name
US-DAG-01–FileShareWitnessDirectory c:\FSW–FileShareWitnessShare
\\hotspace\FSW-DomainController Coldspare (see Figure 12).
|
Adding Nodes to the DAG via Exchange Management Shell
When the Database
Availability Group has been created via Exchange Management Shell, the
same shell can be used to add members to the DAG via the following
steps:
1. | Launch Exchange Management Shell.
|
2. | Type Add-DatabaseAvailabilityGroupServer–Identity
DAGName–MailboxServer
firstnode.
For example, Add-DatabaseAvailabilityGroupServer–Identity US-DAG-01–MailboxServer E2010 (see Figure 13).
|
3. | Add any additional nodes with the same command; simply replace the name of the node to be added.
|
Adding a Database Copy to a DAG via Exchange Management Shell
With the
Database Availability Group configured and functional, you can add
database copies to DAG members by following these steps:
1. | Launch Exchange Management Shell.
|
2. | Type Add-MailboxDatabaseCopy–Identity
DatabaseName–MailboxServer
ReplicaServer–ActivationPreference number.
For example, Add-MailboxDatabaseCopy–Identity Mailbox Database 2010A–MailboxServer E2010DR–ActivationPreference 2 (see Figure 14).
|
3. | The database will begin seeding.
|
4. | When the seeding is completed, the database replica will be in a suspended state. Resume the replication by typing Resume-MailboxDatabaseCopy–IdentityDatabaseName–MailboxServer
ServerToResume.
For example, Resume-MailboxDatabaseCopy–Identity Mailbox Database 2010A–MailboxServer E2010DR.
|
Monitoring the Health of DAG Replication
When a Database
Availability Group has been established and replicas added to it, it is
useful for administrators to be able to check on the health of the
replication. Should this replication fail for any reason, the sooner an
Administrator can be aware of it, the better their chance is to fix the
replication before a reseed becomes necessary.
The health of the
replication can be checked in two ways, through the GUI by using
Exchange Management Console or from the command line by using Exchange
Management Shell.
To check the health of a replica via the GUI, follow these steps:
1. | Launch Exchange Management Console.
|
2. | Expand Organization Configuration.
|
3. | Click mailbox.
|
4. | Click the Database Management tab.
|
5. | Highlight
the Database whose status you wish to check. If there are a large
number of databases in your environment, consider using the Filter
option to narrow your view.
|
Additional status
information is available by right-clicking the database copy and
choosing Properties. This will show the Copy and Replay queue lengths as
well as show the Replay and Truncation lag settings. The Status tab
will show log related information including the latest log file
available, the time a log was last inspected, the time a log was last
copied and the time a log was last replayed. This information can be
useful in determining the cause of replication problems.
To perform a similar task in Exchange Management Shell, perform the following steps:
1. | Launch Exchange Management Shell.
|
2. | Type Get-DatabaseCopyStatus–MailboxServer
ReplicaServer.
For example, Get-DatabaseCopyStatus–MailboxServer E2010DR (see Figure 15).
|
This shows the
current status of the replication and will show the Copy Queue Length
and the Replay Queue Length. This makes it easy to see if a copy is in
sync or if not, how far behind it is.
There are several
advantages to querying the replication status via the Management Shell.
For example, while at first the output from the command would seem to
suggest that there is less information available than what is shown by
the GUI, this is actually not the case. If one were to pipe the output
of Get-DatabaseCopyStatus to a formatted list, one would find that there
are 44 parameters that are tracked by this command.
Get-DatabaseCopyStatus–MailboxServer E2010DR | FL
This can be
exceptionally useful when one needs to query a large number of systems
for any errors. By querying all of your mailbox servers and filtering
out just ones where a particular parameter is returning a specific status, you can quickly find all servers matching those criteria.
For example, an
administrator might want to generate a real time report showing all
mailbox servers who have a database status of Failed = true. This can be
written fairly easily in Exchange Management Shell:
del c:\users\Administrator \Documents\FailedState.csv
$mailboxservers = Get-MailboxServer
Foreach ($server in $mailboxservers)
{
$var=Get-DatabaseCopyStatus -mailboxserver $server | where {$_.Failed -match "True"}
$status=$Var.Failed
$ID=$Var.Databasename
$log=$var.LastCopiedLogTime
Add-content c:\users\Administrator \Documents\FailedState.csv "$server,$ID, $Status, $Log"}
This will produce a
list showing replica servers who have one or more databases in a Failed
state. It will show specifically which databases are in that Failed
state and will show the timestamp of the last log which was shipped.
This type of a script could be scheduled to run hourly to allow for an
up-to-date view of replication across the whole environment.
