Date post: | 14-Apr-2018 |
Category: |
Documents |
Upload: | nikmarkovic |
View: | 220 times |
Download: | 0 times |
of 11
7/30/2019 Exchange 2010 DAG creation Part 2
1/11
Exchange 2010 DAG Creation and Configuration, Part 220 October 2010
byNeil Hobson
Now that you've created your first DAG in Exchange 2010, you'll need to be sure it's correctlyconfigured for failovers and switchovers, and you know how to troubleshoot. Fear not, for Neil
Hobson tells you what you need to know.
This is the second and final article of a two-part series explaining the process of creating and configuring a
simple two-node Database Availability Group (DAG) in Exchange 2010. Inpart one of this article, we covered
topics such as the lab environment used throughout this discussion, the components that comprise a DAG, the
overall network configuration requirements, and the process to actually create the DAG object using the
Exchange Management Shell. If you havent read part one of this article, I strongly recommend that you do so
before reading part two.
In this second article we will initially be examining the log f iles that are generated during the DAG creation andconfiguration processes, as these become invaluable when you are troubleshooting. Although we wont really
see deep examples of how to use these log files, this is still information youll be glad we covered. We will then
move on to the more practical matters of adding the two mailbox servers (EX01 and EX02) to the DAG using
the Exchange Management Shell, and also cover important DAG configuration parameters that can be adjusted
after the DAG itself has been created. Towards the end of the article, once we have our DAG configured to our
taste, Ill talk a bit more about the Failover Cluster, show you how to add mailbox database copies to the two
mailbox servers, and how to perform a process known as a database switchover.
As you can see, there is a lot of information to cover in this article, so lets get started by examining the log files
which are generated during the DAG creation process.
DagTask Logs
On the Exchange 2010 server where the New-DatabaseAvailabilityGroup cmdlet was executed, navigate to
theC:\ExchangeSetupLogs\DagTasks folder, which will contain log files relevant to DAG creation and
configuration tasks. Each log file name will be in the following format:
dagtask_{date and time}_{cmdlet}
In this format, {date and time} refers to the date and time that the DAG cmdlet was executed,
while {cmdlet} refers to the name of the DAG cmdlet that was executed. For example, the log file name shown
in Figure 1 below isdagtask_2010-02-02_20-02-18.305_newdatabaseavailabilitygroup. After the first DAG
cmdlet, such as New-DatabaseAvailabilityGroup, has been executed, there will naturally only be a single
dagtask log file in theC:\ExchangeSetupLogs\DagTasks folder. As further DAG tasks are run, such as those
involving the Set-DatabaseAvailabilityGroup cmdlet, additional dagtask log files will be created in the same
folder.
With this in mind, its worth nothing that the setup log file that is created at the same time as the DAG itself (i.e.
as a result of running the New-DatabaseAvailabilityGroup cmdlet for the first time) is worth investigating, and
Figure 1 shows an example of this dagtask log files contents. In this particular log file, important configuration
information is shown, such as the WitnessServer and WitnessDirectory cmdlet parameters, together with a clear
indication that the DAG creation process was successful. Examining the contents of this log file will prove useful
when troubleshooting DAG creation failures.
http://www.simple-talk.com/author/neil-hobson/http://www.simple-talk.com/author/neil-hobson/http://www.simple-talk.com/author/neil-hobson/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/sysadmin/exchange/exchange-2010-dag-creation-and-configuration-part-1/http://www.simple-talk.com/author/neil-hobson/7/30/2019 Exchange 2010 DAG creation Part 2
2/11
Figure 1: Contents of a Dagtask Log File
Adding Mailbox Servers to the DAG
Now, once the DAG has been created, the next step is to add the first mailbox server, EX01, to the DAG. To
accomplish this, the Add-DatabaseAvailabilityGroupServer cmdlet will be used, which requires two
parameters. They are the Identity parameter, which identifies which DAG is being configured, and the
MailboxServerparameter, which identifies which mailbox server is being added to the DAG. Therefore, the full
cmdlet to use is:
Add-DatabaseAvailabilityGroupServerIdentity HeadOffice MailboxServer EX01
The Add-DatabaseAvailabilityGroupServercmdlet performs the following tasks:
First, a check is performed to see if the server EX01 is already a member of a DAG, as a mailbox
server can only be a member of a single DAG.
Next, the Windows Failover Cluster components are installed on that mailbox server (if they are not
already present); this second task is being performed in Figure 2. Of course, if it is known when an
operating system is being deployed that it will be for a mailbox server which will also be part of a DAG,
then it is still perfectly acceptable to pre-install the Windows Failover Cluster components prior to
running the Add-DatabaseAvailabilityGroupServercmdlet.
Figure 2: Installation of the Windows Failover Clustering Components
Once the Windows Failover Cluster components have been installed, the Add-
DatabaseAvailabilityGroupServercmdlet creates the Windows Failover Cluster itself, which takes
its name from the name given to the DAG. Therefore, in the lab environment, the failover cluster name
is HeadOffice, as this is the name given to the DAG.
Finally, the mailbox serverEX01 is added to the DAG.
After the running of the Add-DatabaseAvailabilityGroupServercmdlet, an additional dagtask log file will havebeen created in the DagTasks log folder mentioned earlier. This new log file contains plenty of useful
7/30/2019 Exchange 2010 DAG creation Part 2
3/11
information, such as the progress of the cluster formation, and the progress of adding the mailbox server to the
DAG, as can be seen in Figure 3. Examining the contents of this log file will prove to be a useful exercise if you
have any issues when adding a mailbox server to the DAG.
Figure 3: Dagtask Log File for Add-DatabaseAvailabilityGroupServer
Now that the first mailbox server has been added to the DAG, the Add-
DatabaseAvailabilityGroupServer cmdlet needs to be repeated, specifying the second mailbox
serverEX02as the server to add to the DAG. Thus, the cmdlet to achieve this is:
Add-DatabaseAvailabilityGroupServerIdentity HeadOffice MailboxServer EX02
Once this cmdlet has completed, the properties of the DAG can be examined to confirm that both mailbox
servers are now members of the DAG. To do this, the Get-DatabaseAvailabilityGroup cmdlet can be used,
with the results of this cmdlet piped into the format-list (or fl for short) cmdlet. To reduce the amount of
information provided, we can filter the output to only show the serversparameter, and so the command toachieve all of this is:
Get-DatabaseAvailabilityGroup HeadOffice | fl servers
The result of running this cmdlet is shown in Figure 4, where it can be seen that both EX01 and EX02are
confirmed as members of this DAG:
7/30/2019 Exchange 2010 DAG creation Part 2
4/11
Figure 4: Confirming DAG Membership
Additional DAG Parameters
Now that youve got your Mailbox databases added to the DAG, the Set-DatabaseAvailabilityGroup cmdlet
can be used to configure additional DAG parameters after said DAG has been created. For example, if the
server hosting the witness directory fails, it is possible to change the witness server and witness directory using
the Set-DatabaseAvailabilityGroup cmdlet. Other key parameters that can be specified include:
AlternateWitnessServer- Its possible to specify an alternate witness server for the DAG to use with
regards to site resilience scenarios.
AlternateWitnessDirectory - This parameter is used in conjunction with
theAlternateWitnessServerparameter to form the full alternate witness location.
ReplicationPort - By default, Exchange 2010 uses the single Transmission Control Protocol (TCP)
port 64327 to perform log shipping and database seeding operations. If this port number needs to be
changed, this can be achieved via the ReplicationPortparameter, but be aware that if this port number
is changed, the Windows Firewall exceptions will also need to be manually changed, since these are
initially configured by the Exchange 2010 setup process.
NetworkCompression - This parameter determines whether network compression is enabled or
disabled on the DAG networks. Microsoft states that enabling this feature can reduce network trafficby up to 30%, and so its likely that enabling compression is worthwhile in most deployments. This
parameter has four different settings:
o Disabled network compression is disabled on all networks.
o Enabled network compression is enabled on all networks, including those on different
subnets when considering site resilience scenarios.
o InterSubnetOnly network compression will be enabled only for networks on the same
subnet. This is the default setting.
o SeedOnly network compression will only be enabled for database seeding processes.
NetworkEncryption - This parameter controls whether encryption is used on the DAG networks. In
Exchange 2010, DAGs support the encryption features of the Windows operating system, which could
prove useful for those environments that require increased security. This parameter is similar to
theNetworkCompression parameter, in that it has the same four settings,
namely Enabled, Disabled,InterSubnetOnlyorSeedOnly, and the default setting is InterSubnetOnly.
As an example of modifying one of the key parameters listed above, suppose that there is a requirement to
change the network compression setting from the default value ofInterSubnetOnlyto Disabled. In this example,
the following Exchange Management Shell command will be required:
Set-DatabaseAvailabilityGroup HeadOffice NetworkCompression Disabled
The result of running this command is shown in Figure 5:
7/30/2019 Exchange 2010 DAG creation Part 2
5/11
Figure 5: Enabling DAG Network Compression
The Failover Cluster
Now that you have your DAG customized to your taste, lets take a look at how we can manage it. Earlier in thisarticle, we saw that the Windows Failover Cluster components were installed onto each mailbox server when
theAdd-DatabaseAvailabilityGroup cmdlet was run. There are some worthwhile observations to make
regarding the role of the failover cluster in Exchange 2010, when compared to its counterpart in Exchange 2007.
For example, the red highlight box in Figure 6 shows the Failover Cluster Manager snap-in expanded out to
reveal that the name of the cluster is derived from the name of the DAG. From examining the blue highlight
boxes, it can also be seen that there are no Exchange-related cluster resources in the Services and
applications node, such as those seen in Exchange 2007.
Figure 6: The Failover Cluster Manager Snap-in
7/30/2019 Exchange 2010 DAG creation Part 2
6/11
What have been created, though, are cluster core resources for the DAG name, the DAG IP address and the
file share witness, as shown in Figure 7:
Figure 7: Cluster Core Resources
One ofMicrosofts design goals in Exchange 2010 was to ensure that an Exchange administrator can control a
DAG and its Windows Failover Cluster requirements equally well from within the Exchange Management
Console or the Exchange Management Shell, negating the need to perform any administrative duties within the
Failover Cluster Manager snap-in. To highlight this, Figure 8 shows the DAG networks presented within the
Exchange Management Console, whereas such objects were controlled within the Failover Cluster Manager
snap-in in Exchange 2007.
In fact, in Figure 8, you can see that two networks have been created with their default names set
to DAGNetwork01and DAGNetwork02respectively. The subnet information is also displayed and, as a result,
you can see that DAGNetwork01 is actually the MAPI network, since it represents the 192.168.50.0 network,
and that DAGNetwork02 is the Replication network, as it represents the 10.0.0.0 network.
7/30/2019 Exchange 2010 DAG creation Part 2
7/11
Figure 8: DAG Networks in the Exchange Management Console
If you have taken the time to rename your network connections on each mailbox server to differentiate between
the MAPI and Replication network interfaces, it makes sense to rename the networks that you can see in Figure
8 as well so that they match, if only to make troubleshooting easier.
With that in mind, to change the display name of DAGNetwork01 to MAPI Network, the command below can
be used. The same process can obviously be used to rename DAGNetwork02 to Replication Network:
Set-DatabaseAvailabilityGroupNetwork Identity HeadOffice\DAGNetwork01 Name MAPI
Network
Mailbox Database Copies
Before creating the DAG and adding the mailbox servers to it, the Exchange 2010 mailbox server role had
already been installed on both servers before the start of this demonstration. As a result, a default mailbox
database had already been created on each mailbox server and given the default name, which now has a format
of Mailbox Database n, where nis a random 10-digit number; for example, the default mailbox database on
server EX02 is called Mailbox Database 1796634876.
The reason for this default naming standard is that, in Exchange 2010, the mailbox database is now an
organization object and not tied to any particular mailbox server. As a result, database names must be unique
across the Exchange organization. As can be seen from the screen shots later in this article, the default
databases have already been renamed to Mailbox Database 001 and Mailbox Database 002 on
servers EX01 and EX02respectively.
Now, even though a DAG has been created and both mailbox servers are members of this DAG, there stillexists only a single copy of each mailbox database by default. To create a highly available mailbox database
7/30/2019 Exchange 2010 DAG creation Part 2
8/11
configuration, it is now necessary to ensure that a copy ofMailbox Database 001 exists on serverEX02and a
copy ofMailbox Database 002exists on serverEX01. In this configuration, each mailbox server will initially host
a single active database as well as a single passive copy of the active database hosted on the other server. To
create this configuration, the Add-MailboxDatabaseCopy cmdlet can be used and, in the lab environment, the
first command used is:
Add-MailboxDatabaseCopyIdentity Mailbox Database 001 MailboxServer EX02`
ActivationPreference 2
With this command, we can see that a copy ofMailbox Database 001 is being added to the mailbox serverEX02.
The ActivationPreference parameter is used to determine which database to activate if there are multiple
databases available that meet the activation criteria used by the Active Manager process. The Active Manager
process runs on each mailbox server in a DAG, and essentially decides which database copy to activate when
the need arises. If multiple databases meet all the criteria, the activation preference is consulted and the
database with the lowest value is activated. Since the primary copy of the database has an activation preference
of 1, a value of 2 has been chosen for the second copy of this database.
The results of running the Add-MailboxDatabaseCopy cmdlet are shown in Figure 9:
Figure 9: Adding a Mailbox Database Copy
To confirm that copies ofMailbox Database 001 now exist on both EX01 and EX02, it is possible to use the Get-
MailboxDatabase cmdlet to consult the DatabaseCopies and Servers parameters, as shown in Figure 10. Then
its just a question of re-running the Add-MailboxDatabaseCopy cmdlet for Mailbox Database 002, but this
time specifying a target server ofEX01. Once this cmdlet has completed, both databases have a copy that exist
on the alternate mailbox server:
Figure 10: Checking Mailbox Database 001 Database Copies
Database Failovers
Now that our 2-node DAG is essentially built and configured, all that remains is to prove that the databases can
be moved between the two mailbox server nodes. Before we do that though, lets briefly cover some key
terminology that Microsoft uses in this area: switchovers and failovers, collectively known as *overs (pronounced
star-overs).
7/30/2019 Exchange 2010 DAG creation Part 2
9/11
A switchoveris an action performed by an administrator to move either a single database or all the databases
on a mailbox server to an alternative mailbox server within the DAG. If the administrator moves all databases
from one server to another, then this process is known as a server switchover. The most obvious example of
when you might need to perform a server switchover is when applying an update rollup or service pack to an
Exchange 2010 mailbox server. On the other hand, in the example I will present shortly, we will be performing
a switchover of just a single database from server EX01 to serverEX02 - a process known as a database
switchover.
A failoveris an automatic action performed by the system in response to a problem with either a single database
or the entire mailbox server. Like switchovers, failovers can also apply to either a single mailbox database
(adatabase failover) or the entire server (a server failover). I wont be demonstrating a failover here, but I will
perform a database switchover using the Exchange Management Console, although the Exchange
Management Shell can also be used if you prefer.
Demonstrating a Switchover
The first thing to do is to obtain the status of the database copies. In Figure 11, you can see that the active copy
of the database named Mailbox Database 001 is currently residing on server EX01, since the Copy
Status column shows a value of Mounted for server EX01. Server EX02 contains a healthy copy of this
database, which you can tell by virtue of the fact that the Copy Status column shows a value of Healthy for
serverEX02. Likewise, Mailbox Database 002 is active on serverEX02and has a healthy database copy on
serverEX01.
Figure 11: The Database Copy Status
To make the copy ofMailbox Database 001 on serverEX02the active copy, the following process is used:
7/30/2019 Exchange 2010 DAG creation Part 2
10/11
1. In the bottom pane shown in Figure 11, right-click the healthy copy ofMailbox Database 001 located
on serverEX02, and choose the Activate Database Copy option from the context menu (as shown
in Figure 12):
Figure 12: Activating a Database Copy
2. Next, a window is presented that allows you to override theAutoDatabaseMountDialsetting for this
mailbox server. Shown in Figure 13, this setting essentially allows you to control whether or not the
database will mount, depending on how many transaction log files may be missing. More information
on theAutoDatabaseMountDialparameter can be found in the Exchange 2010 productdocumentation
on the Set-Mailbox cmdlet.
Figure 13: AutoDatabaseMountDial Override
3. The database copy on serverEX02is then activated and, if the procedure is successful, the Exchange
Management Console will now reflect this, as shown in Figure 14, where you can see that the Copy
Status column now indicates that the copy of the database on serverEX02is Mounted.
Figure 14: New Active Database Copy
To perform a complete server switchover, where all databases are moved from one mailbox server to another,
theSwitchover Server option can be selected from the action pane when the relevant mailbox server is
highlighted in the EMCsServer Configuration -> Mailboxview. I will leave you, the reader, to discover and test
out these processes in your own time.
http://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspxhttp://technet.microsoft.com/en-us/library/aa998651.aspx7/30/2019 Exchange 2010 DAG creation Part 2
11/11
Summary
That concludes the final article of this two-part series on creating and configuring a two-node DAG solution
using Exchange 2010. If you have followed both parts of this article, you will now have a solid understanding of
the steps required to construct a simple two-node DAG, as well as how to configure and use it.
Whilst there is no doubt that Microsoft has produced a compelling mailbox database high availability feature in
Exchange 2010, you should be fully aware that the DAG is only one aspect of a truly highly available messaging
infrastructure. Other key components, such as the Client Access Server role, the Hub Transport server role,
Active Directory, DNS, and so on, all have to be planned and implemented with Exchange 2010 high availability
in mind.