Dag PDF

Qus.
What is DAG
Ans. DAG is group of mailboxes servers that provide high availability of mailbox database in
exchange organization. It support 16 copes.
Qus. What is active manager.
Ans. Active Manager, which runs on every servers in a DAG, manages switchovers and
failovers.
Qus. What is CNO. (cluster name object)
Ans. it is a computer Active Directory object. It is used for assign cluster name and IP
addresses.
Qus. What is quorum
Ans. it is Quorum is a shared volume among cluster member that store all configuration of
Cluster and communicate among cluster members.
qus. How many type quorum use DAG
ans. Majority Node Set [MNS] is a Windows Clustering model used since early versions of
Exchange. This model requires 50% of the voters (servers and/or one file share witness) to be up
and running
Node and File Share Majority quorum mode :- when we use even number of members use the
failover cluster's (DAG) than uses an external witness server that acts as a tie-breaker (DAG
member).
1. The cluster quorum data is stored by default on the system disk of each member of the
DAG. A file on the witness server (thus the name File Share) is used to keep track of
which member has the most updated copy of the data - the witness server does not have a
copy of the cluster quorum data.
2. When the witness server is needed for quorum, any member of the DAG that can
communicate with the witness server can place a Server Message Block [SMB] lock on
the witness server's witness.log file. The DAG member that locks the witness server (the
locking node) retains an additional vote for quorum purposes. The DAG members in
contact with the locking node are in the majority and maintain quorum.
Consider a DAG with four members. Because this DAG has an even number of members, an
external witness server is used to provide one of the cluster members with a fifth, To maintain a
majority of voters (and therefore quorum), at least three voters must be able to communicate with
each other. At any time, a maximum of two voters can be offline without disrupting service and
data access. If three or more voters are offline, the DAG loses quorum and all databases are
dismounted.
Figure 1.1: Database Availability Group with an Even Number of Members
The following formula helps administrators calculate how many nodes in a cluster have to be
available before the cluster is brought offline: (n / 2) + 1 where n is the number of DAG nodes
within the DAG (note that n/2 is always rounded down). So, in this example, we have: (5/2)+1 =
2+1 = 3.
Node Majority:- when we use odd number of members than we use Node Majority quorum
mode. In this mode, each member local system disk is used to store the cluster quorum data. If
the configuration of the DAG changes, that change is reflected across the different disks. The
change is only considered to have been committed and made persistent if that change is made to
the disks on half the members (rounding down) plus one. For example, in a three-member DAG,
the change must be made on one plus one members, or two members in total. In this scenario,
and using the formula above, only one server can be down at one time. If a second server is also
offline, the entire cluster will be brought offline.
Figure 1.2: Database Availability Group with an Odd Number of Members
Dynamic Quorum:- when we use Dynamic Quorum it automatically (dynamically) adjust the
assignment of quorum votes, the cluster can increase or decrease the number of quorum votes
that are required to keep it running
Using a Database Availability Group for High Availability

DAG extended across two Active Directory sites
In this example, a passive copy of each active database in the Redmond datacenter is configured
on EX6 in the Dublin datacenter. However, there are many other examples of DAG
configurations that provide site resilience. For example:
 Instead of hosting only passive database copies, EX6 could host all active copies, or it
could host a mixture of active and passive copies.
 In addition to EX6, multiple DAG members could be deployed in the Dublin datacenter,
providing protection against additional failures. This configuration also provides
additional capacity, so that if the Redmond datacenter fails, the Dublin datacenter can
support a much larger user population.

failovers.
Active Manager runs as a role on all Mailbox servers. On Mailbox servers that are not configured for high
availability, we can say it Standalone Active Manager.
When we use DAG. ), there are two Active Manager roles: Primary Active Manager (PAM) and Standby
Active Manager (SAM).
Primary Active Manager (PAM):- it decides which copies will be active and passive. and perform
switchover and failover.
Standby Active Manager :- The SAM detects failures of local databases and the local Information Store.
It respond to PAM to initiate a failover (if the database is replicated). A SAM doesn't determine the
target of failover, nor does it
The SAM provides information on which server hosts the active copy of a mailbox database to Client
Access service or Hub Transport server
Active Manager Best Copy Selection
When a failure occurs that affects a replicated mailbox database, Active Manager takes several
steps to recover from the failure by selecting the best possible copy of the failed database to
activate. The general process occurs in the following order:
1. Active Manager detects the failure.
2. The PAM runs an internal algorithm called best copy selection (BCS).
3. A process called attempt copy last logs (ACLL) occurs, which tries to copy any missing log files
from the server that hosted the active database copy prior to the failover.
4. Once the ACLL process has completed, the PAM issues a mount request to the Microsoft
Exchange Information Store via remote procedure call (RPC). At this point, either:
1. The database mounts and is made available to clients; or
2. The database does not mount, and PAM performs steps 3 and 4 on the next best copy (if
one is available).
Qus. What is Datacenter Activation Coordination Mode
Ans. Datacenter Activation Coordination (DAC) mode is a property setting of database

availability group (DAG). It controle mounting databases and split brain (divided) in DAG.
DAC mode is designed to prevent split brain by Datacenter Activation Coordination Protocol
(DACP).
DACP tackle this issue. Active Manager stores a bit in memory (either a 0 or a 1) When a DAG
is running in DAC mode (which would be any DAG with three or more members), each time
Active Manager starts up the bit is set to 0, meaning it isn't allowed to mount databases. If
another server responds that its bit is set to 1, it means servers are allowed to mount databases, so
the server starting up sets its bit to 1 and mounts its databases.
For example, consider (think) a scenario where the first datacenter contains two DAG members
and the witness server, and the second datacenter contains two other DAG members. If the first
datacenter loses power and you activate the DAG in the second datacenter (for example, by
activating the alternate witness server in the second datacenter), if the first datacenter is
restored without network connectivity to the second datacenter, the active databases within
the DAG may enter a split brain condition.
But when you recover from a primary datacenter power outage where the servers are
recovered but WAN connectivity has not been restored, all of the DAG members in the primary
datacenter will have a DACP bit value of 0; and therefore none of the servers starting back up in
the recovered primary datacenter will mount databases, because none of them can
communicate with a DAG member that has a DACP bit value of 1.
qus. what is Member servers
ans. it is a server external to the DAG and it is used as a quorum voter (node majority) for the
DAG when the DAG contains an even number of members.
qus. what is Witness Directory
ans. it is a directory it is used to store quorum data on the witness server.
qus. what is Alternate Witness Server ans. it is a server external to the DAG and it is used as a
quorum voter (node majority) for the DAG. it is used as a replacement for the witness server in a
datacenter switchover.
qus. what is alternate Witness Directory
ans. it is a directory it is used to store quorum data on alternate witness server.
qus. what is Replay Lag Time

ans. it is amount of time, (in minutes) it delay log replay for the database copy. The replay lag
timer starts when a log file has been replicated to the passive copy.
Note:- By which you have the capability to recover the database to a specific point in time in
the past. A mailbox database copy configured with a replay lag time greater than 0 is referred
to as a lagged mailbox database copy, or simply, a lagged copy.
Qus. what is Truncation Lag Time.

Ans. amount of time, in minutes, to delay log deletion for the database copy after the log file has been
replayed into the database copy.
Note:- The truncation lag timer starts when a log file has been replicated to the passive copy, and
successfully passed inspection, and has been successfully replayed into the copy of the database.
Qus. What is Database Activation Policy.
Ans. it is set of configuration by which you may want to create a mailbox database copy and
prevent the system from automatically activating that copy in the event of a failure. For example:
 If you deploy one or more mailbox database copies to a second or standby data center.
 If you configure a database copy as a lagged copy for recovery purposes.
 If you are performing maintenance or an upgrade of a server.
Qus. what is Activation preference number
Ans. The activation preference number is used as part of Active Manager's best copy selection
process and to redistribute active mailbox databases throughout the DAG
Qus. what is Copy queue length (logs)
ans. it Indicates the number of log files waiting to be copied and inspected.
Qus. Replay queue length (logs)
Ans. it Indicates the number of log files waiting to be replayed into this copy of the database.
1. Use the Status tab to view additional details about the health and status of replication for
the database copy.
o Seeding Indicates whether a seeding operation is currently in progress.
o Messages If any failures have occurred, the View button is made available.
Click this button to view messages about conditions that triggered the failure.
o Latest available log time The time associated with the latest available log
generated by the active database copy. This log is available to be copied.
o Last inspected log time The modification time of the last log that was
successfully validated by the Mailbox server hosting the database copy.
o Last copied log time The modification time of the last log that was successfully
copied.
Last replayed log time The modification time of the last log that was successfully replayed by
the Mailbox server hosting the database copy.
DAG
Lab environment:-
1. There are three servers such as DC01 EX01 and EX02. DC01 is DC and DNS server and
EX01 and EX02 is exchange server that running exchange server 2010 with hub transport
role mailbox role and clients access role.
2. EX01 and EX02 is member of same AD
3. Ex01 and ex02 is have two lan card each one is for MAPI second is for replication you
can see in figure
Note:- you can not install window failover and window network load balancing one same server
Qus. What is DAG component?
Ans.
1. DAG name should not above 15 character

2. Witness server:- if a DAG has an even number of mailbox server. A witness
server will be used for maintain cluster quorum, a hub transport server is typically
choose as the witness server, our lab a server is outside of DAG that is DC we
will use a DC as witness server a hub transport server being automatically
selected, provided that it is located in the same AD site and not also running
mailbox role.
3. A witness directory:- this a simple a folder that store information about DAG on
witness server.
4. One or more ip address:- a DAG can contain one or more ip address. If you want
to span a DAG multiple site. You will require additional ip address from each site.
Network configuration:-
If your DAG members contain two network cards. One network cards factions as MAPI network.
By which all DAG member will communicate each other, while second network cards functions
as a replication network. This is used for transaction log shipping and database reseeding.
In previous versions of exchange which used clustering techniques for high availability the
network were referred as public and private.
Note:- if you use two network cards one is for MAPI and other is replication. If replication
network is fail. It will use MAPI network for replication. If use redundancy of replication
network cards these will use until none are available and then fail back to using the MAPI
network
Qus. What should be MAPI and replication network settings:-
Ans.
Feature MAPI Replication

Network Network
Setting Setting
Client for Microsoft Networks Enabled Disabled
QoS Packet Scheduler Optionally Optionally
Enabled Enabled
File and Printer Sharing for Microsoft Networks Enabled Disabled
IPv6 Optionally Optionally
Enabled Enabled
IPv4 Enabled Enabled
Link-Layer Topology Discovery Mapper I/O Enabled Enabled
Driver
Link-Layer Topology Discovery Responder Enabled Enabled
Table 1: Network Configuration
Note:- Be aware that IPv6 has been disabled by de selecting the check box in networking
interface properties. It should also be disabled within the server registry.
Figure 2: MAPI Network Configuration
Figure 3: Replication Network Configuration
Qus. What is network configuration before create DAG
Ans.
1. Ensure that the default gateway is assigned only on the MAPI network interface and not, therefore, on
the replication network interface.
2. Ensure that there are no DNS server addresses configured on the replication network interface; these
should only be configured on the MAPI network interface.
3. It is also important to ensure that the Register this connection’s addresses in DNS option is not
selected on the replication network interface. To clear this option on the replication network interface,
perform these steps:
a. With the replication network properties screen open, as shown in Figure 3, select the Internet
Protocol Version 4 (TCP/IPv4) option and then click the Properties button
b. In the resulting window, called Internet Protocol Version 4 (TCP/IPv4) Properties, click the
Advanced button
c. In the Advanced TCP/IP Settings window, click the DNS tab
d. In the final resulting window, clear the Register this connection’s addresses in DNS check
box, as shown in Figure 4
Figure 4: Disabling DNS Registration
4. Set the network binding order so that the MAPI network is at the top of the list. To do this, follow these
steps:
a. With the Network Connections window open, press the Alt key to bring up the menu option.
b. With the menu displayed, click Advanced and then Advanced Settings...
c. In the resulting Advanced Settings window, ensure that the MAPI network is at the top of the
connection order, as shown in Figure 5.
Figure 5: Network Connection Order
Qus. How to configure a witness server
Ans. A witness server should be outside of DAG in this lab our DC01 is outside of DAG. Before be witness
server to DC we will have to assign permission to exchange server so that it can create witness directory
structure so we need to add exchange trusted subsystem universal security group to local administrators group
on the D. it can found in the Microsoft exchange security groups OU.
Qus. How to create DAG.
Ans.
New-DatabaseAvailabilityGroup –Name HeadOffice –WitnessServer DC01 –

WitnessDirectory “C:\Program Files\Microsoft\Exchange
Server\V14\HeadOfficeWitness” -DatabaseAvailabilityGroupIPAddresses 192.168.50.53
The parameters used are:
 Name:
This is simply the name of the DAG, which will become the name of the failover cluster, as mentioned
earlier. In this example, the DAG name is HeadOffice.
 WitnessServer:
This is the name of the server that will house the file share witness.
 WitnessDirectory:
The WitnessDirectory parameter is the name of the folder or directory that will house the file share
witness information
 DatabaseAvailabilityGroupIPAddresses:
This parameter is a comma separated list of IP addresses assigned to the DAG. In this example, the
DAG has just a single IP address: 192.168.50.53. If the DAG was to contain mailbox servers in
different Active Directory sites then it would require an additional IP address, and the list would read:
192.168.50.53,172.16.1.10
The results of running this cmdlet are shown in Figure 7; note the warning that the witness server is not an
Exchange server or a member of the Exchange Servers security group:
Figure 7: The New-DatabaseAvailabilityGroup Cmdlet
Running this cmdlet simply creates the DAG object in Active Directory; you can see from Figure 7 that the
Member Servers field is currently blank, as there are no Exchange 2010 Mailbox servers currently
configured as part of this new DAG.
Qus. How to check a DAG object in ADSI Edit tools
Using ADSIEdit, it is possible to view the configuration contents of the newly created DAG by first connecting to
the configuration naming context, and then drilling down to find the DAG object as shown in Figure 8. This
object has a class of msExchMDBAvailabilityGroup.
Figure 8: The DAG Viewed With ADSIEdit

By right-clicking the DAG object and bringing up its properties, a window similar to the one shown in Figure 9
will be seen, where it is possible to confirm that the correct parameters, as stated in the cmdlet, have been
used to create the DAG. For example, it can be clearly seen from Figure 9 that the correct DAG name and
witness server information has been used.
Figure 9: DAG Properties
Qus. How to check log after create DAG
Ans. navigate to the C:\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}

Figure 1: Contents of a Dagtask Log File
Adding Mailbox Servers to the DAG

Qus. What should you check before add mailbox server in DAG
 Ans. 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-DatabaseAvailabilityGroupServer cmdlet.
 Once the Windows Failover Cluster components have been installed, the Add-
DatabaseAvailabilityGroupServer cmdlet 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 server EX01 is added to the DAG
Qus. How to add first mailbox server in DAG
Ans. Add-DatabaseAvailabilityGroupServer –Identity HeadOffice –MailboxServer EX01
Figure 2: Installation of the Windows Failover Clustering Components
Qus. How to add second mailbox server in DAG

Ans. Add-DatabaseAvailabilityGroupServer –Identity HeadOffice –MailboxServer EX02
Qus. How to check how many server in DAG
ANS. Get-DatabaseAvailabilityGroup HeadOffice | fl servers
Mailbox Database Copies

Before creating the DAG and adding the mailbox servers to it 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 “n” is a random 10-digit number; for example, the default mailbox database on server EX02 is called
Mailbox Database 1796634876 database names must be unique across the Exchange organization. You
change database name (with EDB) to Mailbox Database 001 and Mailbox Database 002 on servers EX01 and
EX02
a DAG has been created and both mailbox servers are members of this DAG, there still exists only a single
copy of each mailbox database by default. To create a highly available mailbox database configuration, it is
now necessary to ensure that a copy of Mailbox Database 001 exists on server EX02 and a copy of Mailbox
Database 002 exists on server EX01. 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
Qus. How to add mailbox data copy in DAG
Ans. Add-MailboxDatabaseCopy –Identity “Mailbox Database 001” –MailboxServer EX02`

–ActivationPreference 2
The results of running the Add-MailboxDatabaseCopy cmdlet are shown in Figure 9:
Figure 9: Adding a Mailbox Database Copy
Then it‟s just a question of re-running the Add-MailboxDatabaseCopy cmdlet for Mailbox Database 002, but
this time specifying a target server of EX01. Once this cmdlet has completed, both databases have a copy that
exist on the alternate mailbox server:
Figure 10: Checking „Mailbox Database 001‟ Database Copie
Note:- activation preference parameter is ueed to determine which database is active database and which
database is passive database value 1 is refer active copy and 2 passive copy.
Note:- mounted copy is active copy and healthy copy is passive copy.
Additional DAG Parameters
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 - It‟s 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 the AlternateWitnessServer
parameter 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 ReplicationPort parameter, 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 traffic by
up to 30%, and so it‟s 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 the
NetworkCompression parameter, in that it has the same four settings, namely Enabled, Disabled,
InterSubnetOnly or SeedOnly, 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 of InterSubnetOnly to 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:
Figure 5: Enabling DAG Network Compression
Qus. How to check DAG parameter is enabled or disabled
Ans. Get-databaseavailabilitygroup headoffice | FL *compression*
Qus. How to change network name
Ans. 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

Figure 8: DAG Networks in the Exchange Management Console
Qus. What is DAG
Ans. DAG is group of mailboxes servers that provide high availability of mailbox database in
exchange organization. It support 16 copes.
failovers.
Qus. What is CNO.
Ans. a cluster name object (CNO) is created in Active Directory. The name, IP addresses and
CNO for the cluster are used only internally by the system to secure the DAG.
Qus. What is quorum
Ans. Quorum is a shared volume among cluster member that store all configuration of Cluster
and communicate among cluster members.
Qus. How many kind quorum mode is used by DAG
Ans. Node Majority (bulk,mass) quorum mode:- DAGs with an odd number of members use the
failover cluster's Node Majority quorum mode. In this mode, each member's local system disk is
used to store the cluster quorum data. If the configuration of the DAG changes, that change is
reflected across the different disks. change is made to the disks on half the members (rounding
down) plus one. For example, in a five-member DAG, the change must be made on two plus one
members, or three members total.
File Share Majority:- File Share Majority quorum mode, which employs (use, take up )an
external witness server that acts as a tie-breaker. In this quorum mode, each DAG member gets a
vote.
Qus. What is Datacenter Activation Coordination Mode
Ans. Datacenter Activation Coordination (DAC) mode is a property setting of database

availability group (DAG). It controle mounting databases and split brain (divided) in DAG.
DAC mode is designed to prevent split brain by Datacenter Activation Coordination Protocol
(DACP).
DACP tackle this issue. Active Manager stores a bit in memory (either a 0 or a 1) When a DAG
is running in DAC mode (which would be any DAG with three or more members), each time
Active Manager starts up the bit is set to 0, meaning it isn't allowed to mount databases. If
another server responds that its bit is set to 1, it means servers are allowed to mount databases, so
the server starting up sets its bit to 1 and mounts its databases.
For example, consider (think) a scenario where the first datacenter contains two DAG members
and the witness server, and the second datacenter contains two other DAG members. If the first
datacenter loses power and you activate the DAG in the second datacenter (for example, by
activating the alternate witness server in the second datacenter), if the first datacenter is
restored without network connectivity to the second datacenter, the active databases within
the DAG may enter a split brain condition.
But when you recover from a primary datacenter power outage where the servers are
recovered but WAN connectivity has not been restored, all of the DAG members in the primary
datacenter will have a DACP bit value of 0; and therefore none of the servers starting back up in
the recovered primary datacenter will mount databases, because none of them can
communicate with a DAG member that has a DACP bit value of 1.
A database availability group (DAG) is a set of up to 16 Microsoft Exchange Server 2010
Mailbox servers that provide automatic database-level recovery from a database, server, or
network failure.
When creating a DAG, you provide a unique name for the DAG of up to 15 characters. In
addition to providing a name for the DAG, you must also assign one or more IP addresses (either
IPv4 or both IPv4 and IPv6) to the DAG.
If your system is configured to use IPv6, the task will also attempt to automatically assign the
DAG one or more IPv6 addresses.
Optionally, you can also specify a witness server and witness directory. If you do specify a
witness server, we recommend that you use a Hub Transport server. This allows an Exchange
administrator to be aware of the availability of the witness.
The following combinations of options and behaviors (activity action performance) are available:
1. You can specify only a name for the DAG and leave the Witness Server and Witness
Directory check boxes cleared. In this scenario, the wizard will search for a Hub
Transport server that doesn't have the Mailbox server role installed. It will automatically
create the default directory and share on that Hub Transport server and use that server as
the witness server.
2. 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.
3. You can specify a name for the DAG and the witness server that you want to use, and
leave the Witness Directory check box cleared. In this scenario, the wizard will create
the default directory on the specified witness server.
4. You can specify a name for the DAG, leave the Witness Server check box cleared, and
specify the directory you want created and shared on the witness server. In this scenario,
the wizard will search for a Hub Transport server that doesn't have the Mailbox server
role installed, and it will automatically create the specified directory on that server, share
the directory, and use that Hub Transport server as the witness server.
Important:
If the witness server you specify isn't an Exchange 2010 server, you must add the Exchange
Trusted Subsystem universal security group to the local Administrators group on the witness
server. These security permissions are necessary to ensure that Exchange can create a directory
and share on the witness server as needed. If the proper permissions aren't configured, the
following error is returned:
Error: An error occurred during discovery of the database availability group topology. Error:
An error occurred while attempting a cluster operation. Error: Cluster API "AddClusterNode()
(MaxPercentage=12) failed with 0x80070005. Error: Access is denied."
Qus. How to create a database availability group EMC
Ans.
1. In the console tree, navigate to Organization Configuration > Mailbox.
2. In the action pane, click New Database Availability Group.

3. On the New Database Availability Group page, provide the following information for
the new DAG:
o Database availability group name Use this box to type a valid and unique
name for the DAG of up to 15 characters. The name is equivalent to a computer
name, and a corresponding Cluster Network Object (CNO) will be created in
Active Directory with the name of the DAG. The name of the DAG isn't used by
end users or administrators. It is used only by the system for internal
communication and to secure the DAG.
o Witness Server Select this check box and use the corresponding text box to
specify a witness server for the DAG. If you don't select this check box, the
system will attempt to automatically select a Hub Transport server that doesn't
have the Mailbox server role installed to be used as the witness server.
Note:
If you specify a witness server, you must use either a host name or a fully-qualified domain name
(FQDN). Using an IP address or a wildcard name isn't supported. In addition, the witness server
cannot be a member of the DAG.
o Witness Directory Select this check box and use the corresponding text box to
type the path to a directory that will be used to store witness data. If the directory
doesn't exist, the system will create it for you on the witness server. If you don't
select this check box, the default directory will be created on the witness server.
4. Click New to create the database availability group.
5. On the Completion page, review the following, and then click Finish to close the wizard:
o A status of Completed indicates that the wizard completed the task successfully.
o A status of Failed indicates that the task wasn't completed. If the task fails,
review the summary for an explanation, and then click Back to make any
configuration changes.
Click Finish to close the wizard.
Note:- After you create a DAG, it will be configured to use DHCP. If you don't want the DAG to
use DHCP, you can use the Set-DatabaseAvailabilityGroup cmdlet to configure one or more IP
addresses for the DAG.
Note:- you can not assign ip address to DAG by EMC You can by EMS.
Qus. How to create a database availability group EMS

New-databaseAvailabilityGroup –name testdag –witnessServer DCO1 –WitnessDirectory
c:\testdag –databaseAvailabiltyGroupAddresses 10.0.0.8
Configure Database Availability Group Properties
You can use the Exchange Management Console (EMC) or the Exchange Management Shell to
configure the properties of a database availability group (DAG), including the witness server and
directory used by the DAG. The Shell enables you to configure DAG properties that are not
available in EMC, such as the IP addresses assigned to the DAG, network discovery, the TCP
port used for replication, and datacenter activation coordination (DAC) mode.
DAG property values are stored in both Active Directory and the cluster database. However,
some properties are stored on in the cluster database. As a result, the underlying cluster for the
DAG must be up and running and have quorum in order to set the properties for:
 ReplicationPort
 NetworkCompression
 NetworkEncryption
 DiscoverNetworks
Qus. How to configure database availability group properties EMC
ans.
2. In the result pane, click the Database Availability Group tab, right-click the DAG you
want to configure, and then click Properties.
3. Use the General tab to view DAG membership, configure the DAG's witness server, and
to configure network encryption and compression for the DAG networks.
o Modified This read-only field displays the date and time at which the DAG's
properties were last changed.
o Member servers This read-only field displays the Mailbox servers that are
members of the DAG.
o Witness Server This box displays the host name or fully-qualified domain name
(FQDN) of a server that's external to the DAG and is used as a quorum voter (also
known as a witness server) for the DAG when the DAG contains an even number
of members.
o Witness Directory This box displays the full name and path of the directory
used to store quorum data on the witness server.
o Alternate Witness Server This box displays the host name or FQDN of a server
that's external to the DAG and is used as a replacement for the witness server in a
datacenter switchover.
o Alternate Witness Directory This box displays the name of the directory used
to store quorum data on the alternate witness server.
4. Use the IP Addresses tab to view and modify the IP addresses assigned to the DAG.
o Add Click this button to add a static IPv4 address to the DAG.
o Edit Select an existing IPv4 address and then click this button to modify it.
o Select one or more existing IPv4 addresses and then click this button to
remove them from them DAG.
5. Use the Operational Servers tab to view the list of DAG members that are currently
operational.
Qus. How to configure witness directory
Ans. Set-DatabaseAvailabilityGroup -Identity DAG1 -WitnessDirectory C:\DAG1DIR
Qus. How to set alternate witness directory and witness server
Ans. Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory

C:\DAGFileShareWitnesses\DAG1.contoso.com -AlternateWitnessServer EXHUB3
Qus. How to configure ip address to DAG by DHCP
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatabaseAvailabilityGroupIPAddresses 0.0.0.0
Qus. How to set static IP address to DAG
Ans. Set-DatabaseAvailabilityGroup -Identity DAG1 -DatabaseAvailabilityGroupIPAddresses

10.0.0.8
Qus. How to set multiple ip address to DAG
ANS. Set-DatabaseAvailabilityGroup -Identity DAG1 -DatabaseAvailabilityGroupIPAddresses

10.0.0.8,10.0.1.8
Qus. How to activate datacenter activation coordination mode
Ans. Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

Qus. How to change replication port numbers
Ans. Set-DatabaseAvailabilityGroup -Identity DAG1 -ReplicationPort 63132
Note:- After changing the default replication port for a DAG, you must manually modify the
Windows Firewall exceptions on each member of the DAG to allow communication to occur
over the specified port.
Manage Database Availability Group Membership
When you add a server to a database availability group (DAG), it works with the other servers in
the DAG to provide automatic, database-level recovery from database, server, or network
failures.
DAGs use Windows Failover Clustering (WFC) technologies. Each Mailbox server that is a
member of a DAG is also a node in the underlying cluster that is used by the DAG. As a result,
at any given time, a Mailbox server can be a member of only one DAG.
Qus. What is prerequisites of DAG member
Ans.
 A DAG has been created.
 Because DAGs use WFC technology, all servers added to a DAG must be running either
Windows Server 2008 Service Pack 2 (SP2) Enterprise Edition or Windows Server 2008
R2 Enterprise Edition.
 All servers in a DAG must be running the same operating system. You can't have DAG
members that are running Windows Server 2008 SP2 and others that are running
Windows Server 2008 R2.
 You must remove all replicated database copies from the server before you can remove it
from a DAG
Qus. How to manage database availability group membership EMC
Ans.
2. In the result pane, click the Database Availability Group tab, right-click the DAG you
want to manage, and then click Manage Database Availability Group Membership.
3. On the Manage Database Availability Group Membership page, you can perform the
following tasks.
o To add a local server to the DAG, click Add and then use the Select Mailbox
Server dialog box to select the server you want.
o To remove a local server from the DAG, select a server from the list of members,
and the click .
4. Click Manage to perform the configured management action (adding or removing a

server).
Qus. How to manage database availability group membership EMS
Ans. Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Qus. How to remove DAG membership by EMS
Ans. Remove-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Qus. How to remove DAG membership configuration only by EMS
Ans. Remove-DatabaseAvailabilityGroupServer -Identity DAG2 -MailboxServer MBX4 –

ConfigurationOnly
Recover a Database Availability Group Member Server
If a Mailbox server that's a member of a database availability group (DAG) is lost or otherwise
fails and is unrecoverable and needs replacement, you can perform a server recovery operation.
Microsoft Exchange Server 2010 Setup includes the switch /m:RecoverServer that can be used
to perform the server recovery operation. Running Setup with the /m:RecoverServer switch
causes Setup to read the server's configuration information from Active Directory for a server
with the same name as the server from which you're running Setup. After the server's
configuration information is gathered from Active Directory, the original Exchange files and
services are then installed on the server, and the roles and settings that were stored in Active
Directory are then applied to the server:-
1. Retrieve any replay lag or truncation lag settings for any mailbox database copies that
exist on the server being recovered by using the Get-MailboxDatabase cmdlet.
Get-MailboxDatabase DB1 | Format-List *lag*
2. Remove any mailbox database copies that exist on the server being recovered by using
the Remove-MailboxDatabaseCopy cmdlet.
Remove-MailboxDatabaseCopy DB1\MBX1
3. Remove the failed server's configuration from the DAG by using the Remove-
DatabaseAvailabilityGroupServer cmdlet.
Remove-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Note:
If the DAG member being removed is offline and cannot be brought
online, you must add the ConfigurationOnly parameter to the above
command.
1. Reset the server's computer account in Active Directory. For detailed steps, see Reset a
Computer Account.
2. Open a Command Prompt window. Using the original Setup media, run the following
command.
Setup /m:RecoverServer
3. When the Setup recovery process is complete, add the recovered server to the DAG by
using the Add-DatabaseAvailabilityGroupServer cmdlet.
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
4. After the server has been added back to the DAG, you can reconfigure mailbox database
copies by using the Add-MailboxDatabaseCopy cmdlet. If any of the database copies
being added previously had replay lag or truncation lag times greater than 0, you can use
the ReplayLagTime and TruncationLagTime parameters of the Add-
MailboxDatabaseCopy cmdlet to reconfigure those settings.
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1 -ReplayLagTime 3.00:00:00
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1 -ReplayLagTime 3.00:00:00 -
TruncationLagTime 3.00:00:00
Create a Database Availability Group Network
You can create multiple networks in a database availability group (DAG) and dedicate them for
client access or for replication purposes.
Qus. How to create a database availability group network EMC
2. In the result pane, click the Database Availability Group tab.
3. Right-click the DAG for which you want to create the new network, and then click New
Database Availability Group Network. You can also select the DAG and then click
New Database Availability Group Network in the action pane.
4. On the New Database Availability Group Network page, provide the following
configuration information for the new DAG network.
o Network name Provide a unique name for the DAG network (a name that
doesn't conflict with the name of any other DAG network). The limit is 128
characters.
o Network description Provide an optional description for the DAG network. The
limit is 256 characters.
o Database Availability Group network subnets Click Add to add each network
subnet to the DAG network. Subnets should be entered using a format of IP
address/bitmask (for example, 192.168.1.0/24 for IPv4 subnets;
2001:DB8:0:C000::/54 for IPv6 subnets). If you add a subnet that's currently
associated with another DAG network, the subnet will be removed from the other
DAG network and associated with the network being created.
o Enable replication Select this check box to enable the DAG network for use by
replication. When a DAG network is enabled for replication, MAPI traffic is
restricted on that network. Clear this check box to prevent replication from using
the DAG network and to enable MAPI traffic on that network.
5. Click New to create the DAG network.
7. Click Finish to close the wizard.
Qus. How to create a database availability group network EMS
Ans. New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup DAG1 -Name

DagNet1 -Description "Replication network 1" -Subnets 10.0.0.0/8 -ReplicationEnabled:$True
Qus. How to rename network by EMS
Ans. Set-DatabaseAvailabilityGroupNetwork -Name DAGNET1 -Identity

DAG1\DAGNetwork01
Qus. How to add subnet mask in network
Ans. Set-DatabaseAvailabilityGroupNetwork -Subnets 10.0.0.0/8 -Identity DAG1\DAGNET1
Remove a Database Availability Group
Before you can remove a database availability group (DAG), the DAG must be empty. If the
DAG you want to remove contains any Mailbox servers, you must first remove the servers from
the DAG.
Qus. How to remove a database availability group by EMC
2. In the result pane, on the Database Availability Group tab, right-click the DAG you
want to remove, and then click Remove.
3. Click Yes to confirm the action and remove the DAG.
Qus. Qus. How to remove a database availability group by EMS
Ans. Remove-DatabaseAvailabilityGroup -Identity DAG1 -Confirm:$False
Managing Mailbox Database Copies
Storage groups have been removed from Exchange 2010, continuous replication now operates at
the database level. In Exchange 2010, transaction logs are replicated to one or more Mailbox
servers, and replayed into one or more copies of a mailbox database stored on those servers.
Several concepts used in Exchange Server 2007 continuous replication remain in Exchange
2010.
After multiple copies of a database are created, you can use the Exchange Management Console
(EMC) and the Exchange Management Shell to monitor the health and status of each copy and to
perform other management tasks associated with database copies. Some of the management tasks
such as suspending (hung up, delay postpone) or resuming (start again restart) a database copy,
seeding (start, starting point )a database copy, monitoring database copies, configuring database
copy settings, and removing a database copy.
Suspending and Resuming Database Copies

For a variety of (various) reasons, such as performing planned maintenance, it may be necessary
to suspend and resume continuous replication activity for a database copy. In addition, some
administrative tasks, such as seeding, require you to first suspend a database copy. We also
recommend that all replication activity be suspended when the path for the database or its log
files is being changed.
Note:- Log truncation doesn't occur on the active mailbox database copy when one or more
passive copies are suspended.
Note:- prevent the log drive from filling up with transaction logs, you can remove the affected
passive database copy instead of suspending it. When the planned maintenance is completed, you
can re-add the passive database copy.
Seeding a Database Copy

Seeding, also known as updating. seeding can be an automatic process or a manual process that
you initiate (start kick off). When a database copy is added, the copy will be automatically
seeded. If you want to manually seed a database copy and don't want automatic seeding to occur
when creating the copy, you can use the SeedingPostponed parameter when running the Add-
MailboxDatabaseCopy cmdlet.
Choosing What to Seed

When performing a seed operation, you can choose to seed the mailbox database copy, the
content index catalog for the mailbox database copy, or both. If you want to seed both the
mailbox database copy and the content index catalog copy. To seed just the mailbox database
copy without seeding the content index catalog, use the DatabaseOnly parameter when running
the Update-MailboxDatabaseCopy cmdlet. To seed just the content index catalog copy, use the
CatalogOnly parameter when running the Update-MailboxDatabaseCopy cmdlet.
Selecting the Seeding Source
In Exchange 2007, continuous replication could only seed a database copy by active copy of the
database. In Exchange 2010, any healthy database copy can be used as source for an additional
copy of that database. This is particularly useful when you have a DAG that has been extended
across multiple physical locations.
For example, consider a four-member DAG deployment, where two members (MBX1 and
MBX2) are located in Portland and two members (MBX3 and MBX4) are located in New York,
A mailbox database named DB1 is active on MBX1 and there are passive copies of DB1 on
MBX2 and MBX3. When adding a copy of DB1 to MBX4, you have the option of using the
copy on MBX3 as the source for seeding you avoid seeding over the wide area network (WAN)
link between Portland and New York.
How to specific copy as a source for seeding when adding a new database copy, you would do
the following:
 Use the SeedingPostponed parameter when running the Add-MailboxDatabaseCopy

cmdlet to add the database copy. If the SeedingPostponed parameter isn't used. the
database copy will be using the active copy of the database as the source.
 Use the SourceServer parameter when running the Update-MailboxDatabaseCopy cmdlet

and specify the desired source server for seeding. In the preceding example, you would
specify MBX3 as the source server. If the SourceServer parameter isn't used, the database
copy will be using the active copy of the database as the source.
Seeding and Networks
You selecting a specific source server for seeding a mailbox database copy, you can also specify
which DAG networks to use for seeding, use the Network parameter when running the Update-
MailboxDatabaseCopy cmdlet and specify the DAG networks that you want to use. If you don't
use the Network parameter, the system uses the following default behavior for selecting a
network to use for the seeding operation:-
 If the source server and target server are on the same subnet the replication network
will be used.
 If the source server and target server are on different subnets, the client (MAPI)
network will be used for seeding.
 If the source server and target server are in different datacenters, the client (MAPI)
network will be used for seeding.
The default settings are to use encryption and compression only for communications on
different subnets. you can override these values by using the NetworkCompressionOverride and
NetworkEncryptionOverride parameters, respectively, when running the Update-
MailboxDatabaseCopy cmdlet.
Seeding Process
1. Database properties from Active Directory are read to validate the specified database
and servers, and to verify that the source and target servers are running Exchange 2010,
they are both members of the same DAG, and that the specified database isn't a
recovery database. The database file paths are also read.
2. Preparations occur for reseed checks from the Microsoft Exchange Replication service
on the target server.
3. The Microsoft Exchange Replication service on the target server checks for the presence
of database and transaction log files in the file directories read by the Active Directory
checks in step 1.
4. The Microsoft Exchange Replication service returns the status information from the
target server to the administrative interface from where the cmdlet was run.
5. If all preliminary checks have passed, you are prompted to confirm the operation before
continuing. If you confirm the operation, the process continues. If an error is
encountered during the preliminary checks, the error is reported and the operation fails.
6. The seed operation is started from the Microsoft Exchange Replication service on the
target server.
7. The Microsoft Exchange Replication service suspends database replication for the active
database copy.
8. The state information for the database is updated by the Microsoft Exchange
Replication service to reflect a status of Seeding.
9. If the target server doesn't already have the directories for the target database and log
files, they are created.
10. A request to seed the database is passed from the Microsoft Exchange Replication
service on the target server to the Microsoft Exchange Replication service on the source
server using TCP. This request and the subsequent communications for seeding the
database occur on a DAG network that has been configured as a replication network.
11. The Microsoft Exchange Replication service on the source server initiates an Extensible
Storage Engine (ESE) streaming backup via the Microsoft Exchange Information Store
service interface.
12. The Microsoft Exchange Information Store service streams the database data to the
Microsoft Exchange Replication service.
13. The database data is moved from the source server's Microsoft Exchange Replication
service to the target server's Microsoft Exchange Replication service.
14. The Microsoft Exchange Replication service on the target server writes the database
copy to a temporary directory located in the main database directory called temp-
seeding.
15. The streaming backup operation on the source server ends when the end of the
database is reached.
16. The write operation on the target server completes and the database is moved from the
temp-seeding directory to the final location. The temp-seeding directory is deleted.
17. On the target server, the Microsoft Exchange Replication service proxies a request to
the Microsoft Exchange Search service to mount the content index catalog for the
database copy, if it exists. If there are existing out-of-date catalog files from a previous
instance of the database copy, the mount operation fails, which triggers the need to
replicate the catalog from the source server. Likewise, if the catalog doesn't exist, and it
doesn't on a new instance of the database copy on the target server, a copy of the
catalog is required. The Microsoft Exchange Replication service directs the Microsoft
Exchange Search service to suspend indexing for the database copy while a new catalog
is copied from the source.
18. The Microsoft Exchange Replication service on the target server sends a seed catalog
request to the Microsoft Exchange Replication service on the source server.
19. On the source server, the Microsoft Exchange Replication service requests the directory
information from the Microsoft Exchange Search service and requests that indexing be
suspended.
20. The Microsoft Exchange Search service on the source server returns the search catalog
directory information to the Microsoft Exchange Replication service.
21. The Microsoft Exchange Replication service on the source server reads the catalog files
from the directory.
22. The Microsoft Exchange Replication service on the source server moves the catalog data
to the Microsoft Exchange Replication service on the target server using a connection
across the replication network. After the read is complete, the Microsoft Exchange
Replication service sends a request to the Microsoft Exchange Search service to resume
indexing of the source database.
23. If there are any existing catalog files on the target server in the directory, the Microsoft
Exchange Replication service on the target server deletes them.
24. The Microsoft Exchange Replication service on the target server writes the catalog data
to a temporary directory called CiSeed.Temp until the data is completely transferred.
25. The Microsoft Exchange Replication service moves the complete catalog data to the final
location.
26. The Microsoft Exchange Replication service on the target server resumes search
indexing on the target database.
27. The Microsoft Exchange Replication service on the target server returns a completion
status.
28. The final result of the operation is passed to the administrative interface from which the
cmdlet was called.
Replay Lag Time

It is time limit to start log replication to passive copy. After specific time over log replication will
again start to replicate to passive copy.
Replay lag time is a property of a mailbox database copy that specifies the amount of time, in
minutes, to delay log replay for the database copy. The replay lag timer starts when a log file
has been replicated to the passive copy. By which you have the capability to recover the
database to a specific point in time in the past. A mailbox database copy configured with a
replay lag time greater than 0 is referred to as a lagged mailbox database copy, or simply, a
lagged copy.
Truncation Lag Time

It is time limit after specific time over replication log automatically will delete .
Truncation lag time is a property of a mailbox database copy that specifies the amount of time, in
minutes, to delay log deletion for the database copy after the log file has been replayed into the
database copy. The truncation lag timer starts when a log file has been replicated to the passive
copy, and successfully passed inspection, and has been successfully replayed into the copy of the
database. By delaying the truncation of log files from the database copy, you have the capability
to recover from failures that affect the log files for the active copy of the database.
Database Activation Policy
There are scenarios in which you may want to create a mailbox database copy and prevent the
system from automatically activating that copy in the event of a failure. For example:
 If you deploy one or more mailbox database copies to a second or standby data center.
 If you configure a database copy as a lagged copy for recovery purposes.
 If you are performing maintenance or an upgrade of a server.

Add a Mailbox Database Copy
When you add a copy of a mailbox database, continuous replication is automatically enabled
between the existing database and the database copy. Database copies are automatically
assigned an identity in the format of <DatabaseName>\<HostMailboxServerName>. For
example, a copy of a database named DB1 that's hosted on a server named MBX3 would be
named DB1\MBX3
Prerequisites
 The active copy of the mailbox database must be mounted.
 The specified database must be a mailbox database. You can't use continuous replication
for public folder databases. For public folder database availability, we recommend
deploying multiple public folder databases and using public folder replication. For more
information, see Understanding Public Folder Replication.
 The specified Mailbox server must not already host a copy of the specified mailbox
database.
 The path for the specified mailbox database and its log files must be available on the
specified Mailbox server.
 The server hosting the specified database and the server that will host the database copy
must both be in the same database availability group (DAG). The DAG must also have
quorum and be healthy.
Circular logging must not be enabled for the specified mailbox database. If circular logging
is enabled, you must first disable it. After the mailbox database copy has been added, circular
logging can be enabled. For information about how to enable and disable circular logging
Qus. How to add a mailbox database copy EMC
Ans.
2. In the result pane, on the Database Management tab, right-click the mailbox database
that you want to copy, and then click Add Mailbox Database Copy.
3. On the Add Mailbox Database Copy page, complete the following fields.
o Mailbox database name This read-only box displays the name of the database
for which you are going to make a copy.
o Server name Click Browse to open the Select Mailbox Server dialog box. Use
this dialog box to select the Mailbox server that will host the copy of the mailbox
database, and then click OK.
Note:
The Select Mailbox Server dialog displays all Mailbox servers. You must select a Mailbox
server that it is in the same DAG as the Mailbox server hosting the active copy.
o Activation preference number Use this box to specify the activation preference
number for the database copy. The activation preference number is used as part of
Active Manager's best copy selection process and to redistribute active mailbox
databases throughout the DAG when using the RedistributeActiveDatabases.ps1
script. The value for the activation preference is a number equal to or greater than
1, where 1 is at the top of the preference order. The position number cannot be
larger than the number of copies of the mailbox database.
4. Click Add to add the copy of the mailbox database.
Click Finish to close the wizard.
Qus. How to add a mailbox database copy by EMS
Ans. Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ActivationPreference 2
Qus. How to seed postpone
Ans. Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX4 -ActivationPreference

5 –SeedingPostponed
Qus. How to set replay lag time (3 days)
Ans. Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX5 -ReplayLagTime

3.00:00:00 -ActivationPreference 4
Qus. How to configure mailbox database copy properties
Ans.
3. In the result pane, on the Database Management tab, select the database with the copy
whose status you want to check.
4. In the work pane, on the Database Copies tab, right-click the database copy whose status
you want to view, and then click Properties.
5. Use the General tab to view status about the mailbox database copy, and to configure for
replay lag and truncation lag, and the activation preference number.
o Database This is a read-only field that displays the name of the selected
database.
o Mailbox server This is a read-only field that displays the name of the mailbox
server that currently hosts the active copy of the mailbox database.
o Status This is a read-only field that displays the current status of the selected
database or database copy.
o Copy queue length (logs) Indicates the number of log files waiting to be copied
and inspected.
o Replay queue length (logs) Indicates the number of log files waiting to be
replayed into this copy of the database.
o Activation preference number The activation preference number is used as

part of Active Manager's best copy selection process and to redistribute active
mailbox databases throughout the DAG when using the
RedistributeActiveDatabases.ps1 script. The value for activation preference is a
number equal to or greater than 1, where 1 is at the top of the preference order.
The number cannot be larger than the number of database copies of the mailbox
database.
6. Use the Status tab to view additional details about the health and status of replication for
the database copy.
o Seeding Indicates whether a seeding operation is currently in progress.
o Messages If any failures have occurred, the View button is made available.
Click this button to view messages about conditions that triggered the failure.
o Latest available log time The time associated with the latest available log
generated by the active database copy. This log is available to be copied.
o Last inspected log time The modification time of the last log that was
successfully validated by the Mailbox server hosting the database copy.
o Last copied log time The modification time of the last log that was successfully
copied.
Last replayed log time The modification time of the last log that was successfully replayed by
the Mailbox server hosting the database copy.
Qus. How to set activation preference
Ans. Set-MailboxDatabaseCopy -Identity DB3\EX3 -ActivationPreference 3
Qus. How to set truncation lag time (days)
Ans. Set-MailboxDatabaseCopy -Identity DB1\Server1 -ReplayLagTime 1.0:0:0 -

TruncationLagTime 1.0:0:0 -ActivationPreference 2
qus. How to get health status of database copy
ans. Get-MailboxDatabaseCopyStatus DB3\EX3
Get-MailboxDatabaseCopyStatus DB7\EX5 | Format-List
This example returns status and Hub Transport shadow redundancy information for a database
named DB2. The status results are displayed in a list format.
Get-MailboxDatabaseCopyStatus -Identity DB2 -DumpsterStatistics

| Format-List
This example returns the status and Hub Transport shadow redundancy information for all
database copies on a Mailbox server named MBX2. The status results are also displayed in a list
format.
Get-MailboxDatabaseCopyStatus -Server MBX2 -DumpsterStatistics |

Format-List
Qus. How to Move the Mailbox Database Path for a Mailbox Database Copy
After a mailbox database is created, you can move it to another volume, folder, location, or path
by using either the EMC or the Shell. For step-by-step instructions about how to move a mailbox
database path, see Move the Database Path. That topic provides information about how to move
a non-replicated mailbox database to another path.
If the mailbox database being moved is replicated to one or more mailbox database copies, you
must follow the procedure in this topic to move the mailbox database path. All copies of a
mailbox database must be located in the same path on each server that hosts a copy. For
example, if database DB1 is located at C:\mountpoints\DB1 on server EX1, copies of DB1 on
servers EX2, EX3, and so on, must also be located at C:\mountpoints\DB1. Prerequisites
 To perform the move operation, the database must be temporarily dismounted, making it
inaccessible to all users. If the database is currently dismounted, it isn't remounted upon
completion.
 To perform the move operation, replication for the database must be disabled for all
copies. It's not enough to suspend replication; you must disable it by using the Remove-
MailboxDatabaseCopy cmdlet to remove the database copies.
How to move a replicated mailbox database to a new path
Note:
You can't use the EMC to move a replicated mailbox database to a new path.
1. Note any replay lag or truncation lag settings for all copies of the mailbox database being
moved. You can obtain this information by using the Get-MailboxDatabase cmdlet, as
shown in this example.
Get-MailboxDatabase DB1 | fl *lag*
2. If circular logging is enabled for the database, it must be disabled before proceeding. You
can disable circular logging for a mailbox database by using the Set-MailboxDatabase
cmdlet, as shown in this example.
Set-MailboxDatabase DB1 -CircularLoggingEnabled $false
3. Remove all mailbox database copies for the database being moved. For detailed steps, see
Remove a Mailbox Database Copy. After all copies are removed, preserve the database
and transaction log files from each server from which the database copy is being removed
by moving them to another location. These files are being be preserved so the database
copies to not require re-seeding after they have been re-added.
4. Move the mailbox database path to the new location. For detailed steps, see Move the
Database Path.
Important:
During the move operation, the database being moved must be dismounted. Until the move is
complete, this process will cause an interruption in service and an outage for all users with
mailboxes on the database being moved. After the move operation completes, the database is
automatically mounted.
5. Create the necessary folder structure on each Mailbox server that previously contained a
passive copy of the moved mailbox database. For example, if you moved the database to
C:\mountpoints\DB1, you must create this same path on each Mailbox server that will
host a mailbox database copy.
6. After creating the folder structure, move the passive copy of the mailbox database and its
log stream to the new location. These are the files that were left from and preserved after
Step 3. Repeat this process for each database copy that was removed in Step 3.
7. Add all of the database copies that were removed in Step 3. For detailed steps, see Add a
Mailbox Database Copy.
8. On each server that contains a copy of the mailbox database being moved, run the
following commands to stop and restart the content index services.
Net stop msftesql-Exchange

Net start MSExchangeSearch
9. Optionally, enable circular logging by using the Set-MailboxDatabase cmdlet, as shown

in this example.
Set-MailboxDatabase DB1 -CircularLoggingEnabled $true
10. Reconfigure any previously set values for replay lag time and truncation lag time by
using the Set-MailboxDatabaseCopy cmdlet, as shown in this example.
Set-MailboxDatabaseCopy DB1\MBX2 -ReplayLagTime 00:15:00
11. As each copy is added, we recommend that you verify the health and status of the copy
prior to adding the next copy. You can verify the health and status by:
1. Examining the event log for any error or warning events related to the database or
the database copy.
2. Using the Get-MailboxDatabaseCopyStatus cmdlet to check the health and status

of continuous replication for the database copy.
3. Using the Test-ReplicationHealth cmdlet to verify the health and status of the
database availability group and continuous replication.
Configure Activation Policy for a Mailbox Database Copy

Activation is the process of changing a mailbox database copy from a passive copy to an active
copy. Activation occurs automatically as part of a database or server failover operation, and it
can be performed manually as part of a database or server switchover operation. Blocking a
database for activation prevents it from becoming the active copy during a database or server
failover.
Use the Shell to suspend or resume a database for activation
Note:
You can't use the EMC to suspend or resume a database for activation.
This example blocks the copy of the database DB1 on the server MBX2 for activation.
Suspend-MailboxDatabaseCopy -Identity DB1\MBX2 -ActivationOnly
This example resumes the copy of the database DB1 on the server MBX2 for activation.
Resume-MailboxDatabaseCopy -Identity DB1\MBX2
Suspend or Resume a Mailbox Database Copy
These procedures show you how to suspend and resume continuous replication activity for a
mailbox database copy. You may need to suspend continuous replication for a database copy for
a variety of reasons, such as maintenance on the disk that contains a database copy.
Note:
After a database copy has been resumed, the Summary Copy Status for the database copy will
display a status of Initializing until a log file has been generated by the active copy of the
database.
Looking for other management tasks related to mailbox database copies? Check out Managing
Mailbox Database Copies.
Use the EMC to suspend a mailbox database copy
You need to be assigned permissions before you can perform this procedure. To see what
permissions you need, see the "mailbox database copies" entry in the High Availability
Permissions topic.

2. In the result pane, on the Database Management tab, select the database whose copy
you want to suspend.
3. In the work pane, on the Database Copies tab, right-click the database for which you
want to suspend continuous replication, and then click Suspend Database Copy.
4. Add an optional comment of up to 430 characters in the Comment field.
5. Click Yes to suspend continuous replication.
Use the EMC to resume a mailbox database copy
Permissions topic.
2. In the result pane, on the Database Management tab, select the database whose copy
you want to resume.
3. In the work pane, on the Database Copies tab, right-click the database for which you
want to resume continuous replication, and then click Resume Database Copy.
4. Optionally review any comments in the read-only Comment field.
5. Click Yes to resume continuous replication.
Use the Shell to suspend a mailbox database copy
Permissions topic.
This example suspends continuous replication for a copy of a database named DB1 that is hosted
on a server named MBX3. An optional comment has also been specified.
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -SuspendComment

"Maintenance on EXMBX3" -Confirm:$False
Use the Shell to resume a mailbox database copy

Permissions topic.
This example resumes a copy of a database named DB1 on a server named MBX3.
Resume-MailboxDatabaseCopy -Identity DB1\MBX3
This example resumes a copy of a database named DB1 on a server named EX1 for replication
only.
Resume-MailboxDatabaseCopy -Identity DB1\EX1 -ReplicationOnly
Update a Mailbox Database Copy
Updating, also known as seeding, is the process in which a copy of a mailbox database is added
to another Mailbox server. This becomes the baseline database for the copy. Seeding is required
under the following conditions:
 When a new passive copy of a database is created. Seeding can be postponed for a new
mailbox database copy, but eventually, each passive database copy must be seeded in
order to function as a redundant database copy.
 After a failover occurs in which data is lost as a result of the passive database copy
having become diverged and unrecoverable.
 When the system has detected a corrupted log file that cannot be replayed into the passive
copy of the database.
 After an offline defragmentation of any copy of the database occurs.
 After the log generation sequence for the database has been reset back to 1.
You can perform seeding by using the following methods:
 Automatic seeding An automatic seed produces a copy of the active database on the
target mailbox server. Automatic seeding only occurs during the creation of a new
database.
 Seeding using the Update-MailboxDatabaseCopy cmdlet You can use the Update-
MailboxDatabaseCopy cmdlet in the Exchange Management Shell to seed a database
copy at any time.
 Seeding using the Update Database Copy wizard You can use the Update Database
Copy wizard in the Exchange Management Console (EMC) to seed a database copy at
any time.
 Manually copying the offline database You can dismount the active copy of the
database and copy the database file to the same location on another mailbox server in the
same database availability group. If you use this method, there will be an interruption in
service because the procedure requires you to dismount the database.
Updating a database copy can take a very long time, especially if the database being copied is
very large, or if there is high network latency or low network bandwidth. Once the seeding
process has started, don't close the EMC or the Shell until the process has completed. If you do,
the seeding operation will be terminated.
A database copy can be seeded using either the active copy or an up-to-date passive copy as the
source for the seed. When seeding from a passive copy, be aware that the seed operation will
terminate with a network communication error under the following circumstances:
 If the status of the seeding source copy changes to Failed or FailedAndSuspended.
 If the database fails over to another copy.
Multiple database copies can be seeded simultaneously. However, when seeding multiple copies
simultaneously, you must seed only the database file, and omit the content index catalog. You
can do this by using the DatabaseOnly parameter with the Update-MailboxDatabaseCopy
cmdlet.
Note:
If you do not use the DatabaseOnly parameter when seeding multiple targets from the same
source, the task will fail with SeedInProgressException error FE1C6491.
Prerequisites
 The mailbox database copy must be suspended. For detailed steps, see Suspend or
Resume a Mailbox Database Copy.
 The Remote Registry service must be running on the server hosting the passive database
copy you're updating.
Use the EMC to update a mailbox database copy

permissions you need, see the"Mailbox database copies" entry in the High Availability
Permissions topic.
2. In the result pane, click the Database Management tab.
3. In the work pane, on the Database Copies tab, right-click the database copy you want to
update, and then select Update Database Copy.
4. On the Update Database Copy page, configure the available options for updating a
database copy:
o By default, the active copy of the database is used as the source database for
seeding. If you prefer to use a passive copy of the database for seeding, check the
Select a source server for seeding checkbox, and then click Browse to select the
server containing the passive copy you want to use for the source.
o Configure the task's behavior if files exist in the path of the database copy being
seeded. If any existing files are in the database path, you can either select Delete
them and continue to update process to remove all existing files and proceed
with the seeding operation, or you can select Cancel the update process to
terminate the task.
o By default, once seeding has completed, continuous replication will automatically

resume for the database. If you don't want replication to automatically resume,
select Leave the database copy suspended. I will manually resume replication
later.
o Optionally specify a DAG network to be used for seeding. Click Browse to select
the DAG network you want to use.
5. Once you have configured the available options, click Update to update the database
copy.
6. On the Completion page, the Summary states whether the operation was successful. The
summary also displays the Shell command that was used to perform this procedure.
7. Click Finish to exit the wizard.
Use the Shell to update a mailbox database copy
Permissions topic.
This example shows how to seed a copy of a database named DB1 on MBX1.
Update-MailboxDatabaseCopy -Identity DB1\MBX1
This example shows how to seed a copy of a database named DB1 on MBX1 using MBX2 as the
source Mailbox server for the seed.
Update-MailboxDatabaseCopy -Identity DB1\MBX1 -SourceServer MBX2
This example shows how to seed a copy of a database named DB1 on MBX1 without seeding the
content index catalog.
Update-MailboxDatabaseCopy -Identity DB1\MBX1 -DatabaseOnly
This example shows how to seed the content index catalog for the copy of a database named
DB1 on MBX1 without seeding the database file.
Update-MailboxDatabaseCopy -Identity DB1\MBX1 -CatalogOnly
Manually copy an offline database
Permissions topic.
1. If circular logging is enabled for the database, it must be disabled before proceeding. You
can disable circular logging for a mailbox database by using the Set-MailboxDatabase
cmdlet, as shown in this example.
Set-MailboxDatabase DB1 -CircularLoggingEnabled $false
2. Dismount the database. You can use the Dismount-Database cmdlet, as shown in this
example.
Dismount-Database DB1 -Confirm $false

3. Manually copy the database files (the database file and all log files) to a second location,
such as an external disk drive or a network share.
4. Mount the database. You can use the Mount-Database cmdlet, as shown in this example.
Mount-Database DB1
5. On the server that will host the copy, copy the database files from the external drive or
network share to the same path as the active database copy. For example, if the active
copy database path is D:\DB1\DB1.edb and log file path is D:\DB1, then you would copy
the database files to D:\DB1 on the server that will host the copy.
6. Add the mailbox database copy by using the Add-MailboxDatabaseCopy cmdlet with the
SeedingPostponed parameter, as shown in this example.
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -

SeedingPostponed
7. If circular logging is enabled for the database, enable it again by using the Set-
MailboxDatabase cmdlet, as shown in this example.
Set-MailboxDatabase DB1 -CircularLoggingEnabled $true
These procedures show you how to remove a copy of a mailbox database. You cannot use these
procedures to remove the last copy of a mailbox database. For detailed steps about how to
remove the last copy of a mailbox database, see Remove a Mailbox Database or Remove-
MailboxDatabase. Mailbox database copies can only be removed from a healthy database
availability group (DAG). If the DAG isn't healthy (for example, the DAG's underlying cluster is
down because quorum was lost), you won't be able to remove any mailbox database copies.
After removing a database copy, you must manually delete any database and transaction log files
from the server from which the database copy is being removed.
Use the EMC to remove a mailbox database copy
Permissions topic.
2. In the result pane, on the Database Management tab, select the mailbox database whose
copy you want to remove.
3. In the work pane, on the Database Copies tab, right-click the database copy that you
want to remove, and then click Remove.
4. Click Yes to remove the database copy.
Use the Shell to remove a mailbox database copy
Permissions topic.
This example removes a copy of a mailbox database named DB1 from a Mailbox server named
MBX3.
Remove-MailboxDatabaseCopy -Identity DB1\MBX3 -Confirm:$False
Move the Active Mailbox Database
Moving the active mailbox database is the process of designating a specific passive copy as the
new active copy of a mailbox database. This process is referred to as a database switchover. A
database switchover involves dismounting the current active database and mounting the database
copy on the specified server as the new active mailbox database copy. The database copy that
will become the active mailbox database must be healthy and current.
There are two ways you can use the EMC to move the active mailbox database.
You can use the Move Active Mailbox Database wizard or you can use the Activate
Database Copy option in the work pane.
permissions you need, see the "Mailbox database copies" entry in the High Availability
Permissions topic.
Use the Move Active Mailbox Database wizard
2. In the result pane, click the Database Management tab, and then right-click the mailbox
database whose copy you want to activate.
3. In the action pane, click Move Active Mailbox Database.
4. On the Move Active Mailbox Database page, click Browse to select the server you want
to host the active copy of the database.
5. Select the desired setting for the automatic database mount dial setting on the server
that you specified in the previous step.
6. In the Override automatic database mount dial setting on the target mailbox server
list, optionally override the database mount dial settings on target master by selecting a
value other than None. Possible values are:
o Lossless If you specify this value, the database doesn't automatically mount
until all logs that were generated on the active copy have been copied to the
passive copy.
o Good Availability If you specify this value, the database automatically mounts
immediately after a failover if the copy queue length is less than or equal to 6. If
the copy queue length is greater than 6, the database doesn't automatically
mount. When the copy queue length is less than or equal to 6, Exchange
attempts to replicate the remaining logs to the passive copy and then mounts
the database.
o Best Effort If you specify this value, the database automatically mounts
regardless of the size of the copy queue length. We recommend using caution
when using this setting. Because the database will mount with any amount of log
loss, using this value could result in a large amount of data loss.
o Best Availability 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
then mounts the database.
7. Click Move to move the active copy of the selected database to the specified server.
Use the work pane
2. In the result pane, click the Database Management tab, and then click the mailbox
database whose copy you want to activate
3. In the Database Copies work pane, right-click the passive mailbox database copy that
you want to activate, and then click Activate Database Copy.
4. In Activate Database Copy, you can use the Override mount dial list to optionally
override the database mount dial settings on target master by selecting a value other
than None. Possible values are:
o Lossless If you specify this value, the database doesn't automatically mount
until all logs that were generated on the active copy have been copied to the
passive copy.
o Good Availability If you specify this value, the database automatically mounts
immediately after a failover if the copy queue length is less than or equal to 6. If
the copy queue length is greater than 6, the database doesn't automatically
mount. When the copy queue length is less than or equal to 6, Exchange
attempts to replicate the remaining logs to the passive copy and then mounts
the database.
o Best Effort If you specify this value, the database automatically mounts
regardless of the size of the copy queue length. Because the database will mount
with any amount of log loss, using this value could result in a large amount of
data loss.
o Best Availability 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
then mounts the database.
5. Click OK to activate the passive copy. This action dismounts the current active mailbox
database and makes the selected passive copy the new active mailbox database.
Use the Shell to Move the Active Mailbox Database
permissions you need, see the "Mailbox database copies" entry in the High Availability
Permissions topic.
In this example, a copy of the database DB4 hosted on MBX3 is activated and mounted as the
new active mailbox database. This command makes DB4 the new active mailbox database and it
doesn't override the database mount dial settings on MBX3.
Move-ActiveMailboxDatabase DB4 -ActivateOnServer MBX3 -

MountDialOverride:None
This example performs a switchover of the database DB2 to the Mailbox server MBX1. When
the command completes, MBX1 hosts the active copy of DB2. Because the MountDialOverride
parameter is set to None, MBX1 mounts the database using its own defined database auto mount
dial settings.

MountDialOverride:None
parameter is specified with a value of Good Availability, MBX3 mounts the database using a
database auto mount dial setting of GoodAvailability.

MountDialOverride:GoodAvailability
parameter isn't specified, MBX4 mounts the database using a database auto mount dial setting of
Lossless.
Move-ActiveMailboxDatabase DB3 -ActivateOnServer MBX4
This example performs a server switchover for the Mailbox server MBX1. All active mailbox
database copies on MBX1 will be activated on one or more other Mailbox servers with healthy
copies of the active databases on MBX1.
Move-ActiveMailboxDatabase -Server MBX1
This example performs a switchover of the database DB4 to the Mailbox server MBX5. In this
example, the database copy on MBX5 has a replay queue greater than 6. As a result, the
SkipLagChecks parameter must be specified to activate the database copy on MBX5.
Move-ActiveMailboxDatabase DB4 MBX5 -SkipLagChecks
This example performs a switchover of the database DB5 to the Mailbox server MBX6. In this
example, the database copy on MBX6 has a ContentIndexState of Failed. As a result, the
SkipClientExperienceChecks parameter must be specified to activate the database copy on
MBX6.
Move-ActiveMailboxDatabase DB5 MBX6 -SkipClientExperienceChecks

Dag PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dag PDF

Uploaded by

Copyright:

Available Formats

Qus.

Qus. What is active manager.

Qus. What is CNO. (cluster name object)

Qus. What is quorum

qus. How many type quorum use DAG

Figure 1.1: Database Availability Group with an Even Number of Members

Using a Database Availability Group for High Availability

Qus. What is active manager.

Active Manager Best Copy Selection

1. Active Manager detects the failure.

1. The database mounts and is made available to clients; or

Qus. What is Datacenter Activation Coordination Mode

Ans. Datacenter Activation Coordination (DAC) mode is a property setting of database

qus. what is Member servers

qus. what is Witness Directory

ans. it is a directory it is used to store quorum data on the witness server.

qus. what is alternate Witness Directory

ans. it is a directory it is used to store quorum data on alternate witness server.

qus. what is Replay Lag Time

Qus. what is Truncation Lag Time.

Qus. What is Database Activation Policy.

 If you configure a database copy as a lagged copy for recovery purposes.

 If you are performing maintenance or an upgrade of a server.

Qus. what is Activation preference number

Qus. what is Copy queue length (logs)

Qus. Replay queue length (logs)

o Seeding Indicates whether a seeding operation is currently in progress.

Qus. What is DAG component?

1. DAG name should not above 15 character

Qus. What should be MAPI and replication network settings:-

Feature MAPI Replication

Table 1: Network Configuration

Qus. What is network configuration before create DAG

Qus. How to configure a witness server

New-DatabaseAvailabilityGroup –Name HeadOffice –WitnessServer DC01 –

The parameters used are:

Qus. How to check a DAG object in ADSI Edit tools

Figure 8: The DAG Viewed With ADSIEdit

Figure 9: DAG Properties

Qus. How to check log after create DAG

dagtask_{date and time}_{cmdlet}

Adding Mailbox Servers to the DAG

Finally, the mailbox server EX01 is added to the DAG

Qus. How to add first mailbox server in DAG

Ans. Add-DatabaseAvailabilityGroupServer –Identity HeadOffice –MailboxServer EX01

Figure 2: Installation of the Windows Failover Clustering Components

Qus. How to add second mailbox server in DAG

Qus. How to check how many server in DAG

ANS. Get-DatabaseAvailabilityGroup HeadOffice | fl servers

Mailbox Database Copies

Qus. How to add mailbox data copy in DAG

Ans. Add-MailboxDatabaseCopy –Identity “Mailbox Database 001” –MailboxServer EX02`

The results of running the Add-MailboxDatabaseCopy cmdlet are shown in Figure 9:

Figure 9: Adding a Mailbox Database Copy

Additional DAG Parameters

Set-DatabaseAvailabilityGroup HeadOffice –NetworkCompression Disabled

The result of running this command is shown in Figure 5:

Figure 5: Enabling DAG Network Compression

Qus. How to check DAG parameter is enabled or disabled

Ans. Get-databaseavailabilitygroup headoffice | FL *compression*

Qus. How to change network name

Set-DatabaseAvailabilityGroupNetwork –Identity HeadOffice\DAGNetwork01 –Name “MAPI Network

Qus. What is DAG

Ans. Get-databaseavailabilitygroup headoffice | FL compression