Exchange 2016 DAG design

[Sven Martin]

I have an on-prem Exchange 2016 infrastructure consisting of an 8 server DAG stretched over 2 DCs using JBOD (RBOD) and AutoReseed, The DCs are linked by a 10GB data line so actually it is 1 logical (AD) site. Using the Exchange calculator I have deployed 96 DBs. Every DB has 6 copies, 2 of which are lagged (7 days). The first 3 copies of a database reside in 1 DC the last 3 copies in the other DC. The Exchange calculator scripts designated the database copies with activation preference 3 (AP3) and AP6 as being lagged, so each DC has a lagged copy. My question: During maintenance, the active databases (AP1) on a server are failed over to their respective copies with AP2 on another server in the same DC. Suppose a disk failure happens on an activated DB copy with AP2 - or the server has some kind of issue. It will then try to fail over to the copy with AP3 - which is a lagged copy. This is not something I would like to happen. Therefore, what is the best way to prevent this? - Configure AP3 and AP6 with DatabaseCopyAutoActivationPolicy:Blocked? I wonder if this will result in an error or continue and activate AP4. - Change AP3 to AP5 and vice versa? - Any other suggestions? Sven

[#2]

Hi Sven, run this command against any database copy that you do NOT want to automatically mount in a fail over scenario Suspend-MailboxDatabaseCopy –identity LAGDB\Server4 –ActivationOnly

Also consider raising the activation preference to be the highest.

[#3 · Accepted solution]

Lagged copies shouldn't be blocked, as the DAG can them promote them to regular copies should disk space require this (play down) or other circumstances like the lagged copy requiring page patching, or the number of copies falls below 3. This can be controlled using the DAG's ReplayLagManagerEnabled switch. Regarding (automatic) activation, using the best copy and server selection process, the activation preference is more of a tie-breaker rather than an indication of preference, as it is used when more than one copy is determined eligible  for activation. The whole process is described in detail here: https://technet.microsoft.com/en-us/library/dd776123(v=exchg.160).aspx. If there is really a need to block lagged copies for activation, blocking them on server level or copy level is a possible option; I had a customer who - for all their reasons - wanted dedicated servers with lagged copies, and they put the AP=5 and AP=6 copies on those, and blocked activation on the server level .

[#4]

That article is exactly what I was looking for. It turns out I don't have to change anything. I assumed AP was the only parameter used in the decision, but now I've learned it is not.

Thx!

Sven