HOTSPOT
Your company has two offices. The offices are configured as shown in the following table.
The offices connect to each other by using a WAN link that has a latency of more than 700 ms.
You plan to deploy an Exchange Server 2013 organization to meet the following requirements:
Ensure that users can access their mailbox if the WAN link fails.
Ensure that users can access their mailbox if a single server fails.
Ensure that users can access their mailbox if a single database fails.
You recommend deploying one or more database availability groups (DAGs) and mailbox database copies.
You need to identify which design meets the requirements for the planned deployment.
Which design should you identify?
To answer, select the appropriate design in the answer area.
Hot Area:
Answer: 
Explanation:
File Share Witness
The file share witness is used to establish a majority node set. This is done by create a share on a server that
gets a little file place into it automatically.
The server hosting the cluster resource (which in the DAG I think is the Primary Activation Manager server)
keeps an open file lock on this file.
The other servers see this open file lock and interpret this as meaning another cluster node is online, healthy,
and available.
A file share witness is used when the DAG contains an even number of servers within it.
When you initially create the DAG you must specify the server and file location that will act as the file share
witness regardless of how many servers are in the DAG (0 to start) to ensure that if you do add an even
number of DAG members the FSW will be properly used.
Database Availability Group
A database availability group (DAG) is a set of up to 16 Microsoft Exchange Server 2013 Mailbox servers that
provide automatic database-level recovery from a database, server, or network failure. When a Mailbox server
is added to a DAG, it works with the other servers in the DAG to provide automatic, database-level recovery
from database, server, and network failures.
DAGs use continuous replication and a subset of Windows failover clustering technologies to provide high
availability and site resilience.
Mailbox servers in a DAG monitor each other for failures. When a Mailbox server is added to a DAG, it works
with the other servers in the DAG to provide automatic, database-level recovery from database failures.When you create a DAG, it’s initially empty, and a directory object is created in Active Directory that represents
the DAG. The directory object is used to store relevant information about the DAG, such as server membership
information. When you add the first server to a DAG, a failover cluster is automatically created for the DAG. In
addition, the infrastructure that monitors the servers for network or server failures is initiated. The failover
cluster heartbeat mechanism and cluster database are then used to track and manage information about the
DAG that can change quickly, such as database mount status, replication status, and last mounted location.
Witness server and witness directory The witness server is a server outside the DAG that acts as a quorum
voter when the DAG contains an even number of members. The witness directory is a directory created and
shared on the witness server for use by the system in maintaining a quorum.
Lagged copy of a mailbox database
A Lagged Mailbox Database Copy is a mailbox database copy configured with a replay lag time value greater
than 0.
A lagged database copy is one that is not updated by replaying transactions as they become available.
Instead, the transaction logs are kept for a certain period and are then replayed.
The lagged database copy is therefore maintained at a certain remove to the active database and the other
non-lagged database copies. If you are planning to have more than two passive database copies of a database,
think about a lagged copy also as an additional protection against unpredicted situations Lagged copies aren’t
considered highly available copies. Instead, they are designed for disaster recovery purposes, to protect against
store logical corruption.
The greater the replay lag time set, the longer the database recovery process. Depending on the number of log
files that need to replayed during recovery, and the speed at which your hardware can replay them, it may take
several hours or more to recover a database.
The above configuration provides a symmetrical design. All four servers have the same four databases all
hosted on a single disk per server.
The key is that the number of copies of each database that you have should be equal to the number of
database copies per disk.
In the above example, there are four copies of each database: one active copy, two passive copies, and one
lagged copy. Because there are four copies of each database, the proper configuration is one that has four
copies per volume. In addition, activation preference is configured so that it’s balanced across the DAG andacross each server.
For example, the active copy will have an activation preference value of 1, the first passive copy will have an
activation preference value of 2, the second passive copy will have an activation preference value of 3, and the
lagged copy will have an activation preference value of 4.
Lagged mailbox database copy
A passive mailbox database copy that has a log replay lag time greater than zero.
Crossed Lines
DAG Replication 1 and 2
Circled Areas
Site 1 and Site 2 (or DataCenter1 and DataCenter2)
WAN LINK between Site1 and Site2
High Availability with Site Resiliency Exchange 2010 Example
http://jaworskiblog.com/2011/05/17/exchange-2010-design-principles-for-high-availability-and-site-resiliency/
FSW is the File Share Witness
ASIDE
Windows NLB is not supported across sites.
It is not recommended to use an HLB to load balance across sites.
PICTURE1 OFFERS THE BEST DESIGN IN ORDER TO MEET THE SPECIFIED CRITERIA.
MORE FAULTS WITH THE OTHERS.
PICTURE1 HOWEVER DOES NOT OFFER SITE RESILIENCY.
– Ensure that users can access their mailbox if the WAN link fails.
– Ensure that users can access their mailbox if a single server fails.
– Ensure that users can access their mailbox if a single database fails.
Picture1
The DAG is NOT extended across multiple data centers in a site resilience configuration.
The design offers high availability within each site.
However if a node fails or the wan link fails the respective file share witness for each DAG is still available
unlike the other 3 configurations.
Picture2
The DAG is extended across multiple data centers in a site resilience configuration.
No high availability within each site.
If the wan link is unavailable the file share witness for Site2 would be unavailable
This is a split brain scenario, both sites believe that they are the rightful owner of the database, and thus would
mount their respective DB’s. This would cause a divergence in data.
Email could be sent to either database leaving to a difference between the databases on the respective mailbox
servers.
Picture3
The DAG is extended across multiple data centers in a site resilience configuration.
FSW on Site2 in the event of a wan failure means that the servers cannot contact a FSW
Even number of nodes on the respective site with an inability to contact the FSW.
This is a split brain scenario, both sites believe that they are the rightful owner of the database, and thus would
mount their respective DB’s. This would cause a divergence in data.
Email could be sent to either database leaving to a difference between the databases on the respective mailboxservers.
A file share witness is used when the DAG contains an even number of servers within it.
A Node Majority quorum model is used for DAGs with an odd number of members.
A Node and File Share Majority quorum is used for DAGs with an even number of members.
The DAG needs to be able to make Quorum.
When 1 node fails in Site1 and the wan link is down,1 out of 2 nodes left is not a majority. Need to be able to
connect to the file share witness to obtain a majority.
Picture4
1 DAG across both sites provides site resiliency but FSW on Site1 in the event of a wan failure means that the
servers cannot contact a FSW A file share witness is used when the DAG contains an even number of servers
within it.
Even number of nodes on the respective site with an inability to contact the FSW.
This is a split brain scenario, both sites believe that they are the rightful owner of the database, and thus would
mount their respective DB’s. This would cause a divergence in data.
Email could be sent to either database leaving to a difference between the databases on the respective mailbox
servers.
A file share witness is used when the DAG contains an even number of servers within it.
A Node Majority quorum model is used for DAGs with an odd number of members.
A Node and File Share Majority quorum is used for DAGs with an even number of members.
