Tento článek patří do série, která vychází z mých poznámek při migraci Exchange organizace z verze 2010 na 2016. Nejde o kompletní postup, ale o popis hlavních bodů a oblastí. Příklady se týkají určitého daného designu, ale většinou se dají zobecnit. Stejně tak, i když jde o popis migrace, tak se informace hodí i pro novou instalaci či správu.

Starší verzi DAGu jsem popisoval v článku Exchange 2010 CAS Array a DAG mezi Sites.

Plánování topologie a instalace DAG

Dříve než si začneme popisovat, co to je Database Availability Group, jak funguje a konfiguruje se, tak navážeme na předchozí díly a nakreslíme si ukázkovou topologii. Při plánování adres služeb (Namespaces) v prvním díle jsme si vytvářeli tabulky a schémata pro plánované nasazení. Pokud se rozhodneme využít DAG, tak bychom měli doplnit další sítě a adresy. Případně také naplánovat databáze a kde budou primárně aktivní.

Obecný postup nasazení

• připravíme jednotlivé servery, většinou asi půjde o VM, a nastavíme síťové adresy
• na servery nainstalujeme Exchange Mailbox role a provedeme základní konfiguraci
• vytvoříme DAG (Database Availability Group)
• jednotlivé Mailbox servery zařadíme do DAGu (jako uzly Nodes - Member Servers)
• (volitelně) zrušíme staré databáze a vytvoříme nové databáze schránek
• k databázím přídáme DB kopie na dalších serverech

DAG - Database Availability Group

Dokumentace Database availability groups, Manage database availability groups, Plan for high availability and site resilience

DAG zajišťuje vysokou dostupnost Mailbox DB tím, že vytváří kopie (Mailbox Database Copies) na dalších serverech (členech DAGu) a ty udržuje aktuální pomocí replikací (Continuous Replication). Jedna kopie (na jednom serveru) je aktivní (Active Mounted) a ostatní jsou neaktivní (Passive). V případě problémů na serveru se aktivuje DB kopie na jiném, tedy dojde k automatickému failover. Ruční přepnutí (aktivování) databáze se nazývá switchover. Monitoring a přepínání řeší komponenta Active Manager (součást služby Exchange Replication). DAG je skupina až 16 Mailbox serverů, všechny musí mít stejnou verzi Exchange (tedy nejde 2016 a 2010 dohromady) a být ve stejné doméně. Pokud dojde k switchover nebo failover, tak jsou klienti téměř okamžitě přesměrováni k nové DB.

Od Exchange 2013 SP1 CU4 (minimálně na Windows Server 2012 R2) můžeme vytvořit DAG bez IP adresy, jinak řečeno bez cluster administrative access point (CAAP). Pak se nepřiřazuje IP adresa, nevytváří síťové jméno ani DNS, nevytváří se Cluster Name Object (CNO) v AD DS. Celkově to zjednodušuje řešení clusteru. Ale cluster se pak nedá spravovat pomocí Failover Cluster Management nástroje, ale pouze pomocí Exchange Management Shell.

Velký dopad je pro zálohování, kdy některé nástroje využívají CAAP a bez něj nedokáží DAG zazálohovat. Proto je nejprve třeba zkontrolovat zálohovací SW. Microsoft SCDPM 2012 R2 UR9 podporuje zálohování Exchange 2016, včetně DAGu bez IP adresy. DPM can now backup Exchange 2016

MS doporučuje použít DAG bez administrative access point (pro Exchange 2016 nebo 2019 na minimálně Windows Server 2012 R2). Pouze pokud používáme nějaký 3rd party aplikaci, která se připojuje na cluster/DAG (pro normální provoz to není třeba).

Fungování DAGu

DAG používá nepřetržité replikace (Continuous Replication - block mode nebo file mode) a část technologie Windows Failover Clustering k zajištění vysoké dostupnosti (High Availability) a odolnosti lokalit (Site Resilience).

DAG využívá Windows Failover Cluster, ten využívá princip kvóra (quorum). Pokud jsou servery ve více lokalitách a dojde k výpadku spojení, tak se zajistí, aby běžela pouze jedna strana. Na základě souhlasu (konsenzu) voličů je pouze jedna skupina členů clusteru aktivní. Pokud má DAG sudý počet členů, tak je třeba Quorum Witness Resource, aby se zabránilo split brain syndrome. Členové DAGu komunikují s Witness Server a mohou zamknout soubor witness.log pomocí SMB. Člen DAGu, který zamknul Witness Server, označuje se Locking Node, má hlas navíc a členové, kteří s ním komunikují, mají většinu.

Podle počtu členů clusteru (node) se využívá Quorum Model:

• Node Majority - lichý počet
• Node and File Share Majority - sudý počet

Vytvoření DAGu

Musíme si připravit Witness server, kde bude sdílená složka (případně se může použít i druhý (záložní) Witness server). Sice, když máme 3 Mailbox servery, tak se Witness nebude používat, ale nastavit při konfiguraci jej musíme (kdyby se změnil počet členů DAGu). Na Witness serveru musíme do skupiny lokálních administrátorů zařadit doménovou skupinu Exchange Trusted Subsystem.

Pozn.: Na Exchange 2016 je možno vše okolo DAGu spravovat pomocí Exchange Management Shell, ale hodně věcí lze provést i v Exchange Admin Center. V článku si často uvádíme pouze jednu možnost.

Vytvoříme DAG bez IP adresy. Vždy je důležité unikátní jméno pro DAG. Založení je jednoduché.

• EAC - Exchange Admin Center
• Servers - Database Availability Groups
• klikneme na plus - New
• zadáme jméno, adresu serveru a složku pro Witness, nezadáme žádnou IP adresu

Pozn.: Standardně využívá DAG, pro síťový provoz mezi subnety, šifrování a kompresi. V nastavení DAGu můžeme změnit. Exchange servery mezi sebou využívají Kerberos autentizaci.

Přidání serveru do DAGu

Postupně přidáme první, a pak další členy DAGu, tedy jednotlivé Mailbox servery.

• EAC - Exchange Admin Center
• Servers - Database Availability Groups
• zvolíme náš DAG a klikneme na ikonu počítače s ozubeným kolečkem - Manage DAG membership
• v novém okně klikneme na plus - Add
• přidáme server a potvrdíme Save

Při přidání prvního serveru se provede

• instalace komponenty Windows Failover Clustering (pokud již nemáme nainstalovanou)
• vytvoří se Failover Cluster pro DAG se zadaným jménem
• server se přidá do DAG objektu v AD DS
• cluster database se aktualizuje údaji o databázích, které jsou mount na přidaném serveru

Protože máme DAG bez IP, tak se neprovede

• nevytvoří se Cluster Name Object (CNO) v default Computers kontejneru AD DS
• registrace jména DAG/cluster v DNS
• nepřiřadí se jméno sítě ke clusteru

Pozn.: Než přidáme druhý server do DAGu, tak musím počkat na proběhnutí replikací AD

Při přidání druhého serveru do DAGu provede

• přidání serveru do Failover Cluster
• vytvoří se witness directory and share
• server se přidá do DAG objektu v AD DS
• cluster database se aktualizuje údaji o databázích, které jsou mount na přidaném serveru

Kontrola DAGu

Po přidání serveru do DAGu je třeba provést kontrolu, protože se může zdát vše v pořádku, ale server se nepřidá správně a není aktivní. Pro hlavní kontrolu může použít Exchange Management Shell, Failover Cluster PowerShell nebo Failover Cluster řádkový příkaz.

[PS] C:\>Get-DatabaseAvailabilityGroup -Identity MailDAG -Status

Name             Member Servers          Operational Servers
----             --------------          -------------------
MailDAG          {MAIL2, MAIL1, MAIL3}   {MAIL1, MAIL2, MAIL3}

[PS] C:\>Get-Cluster

Name
----
MailDAG

[PS] C:\>Get-ClusterNode

Name            ID    State
----            --    -----
mail1           1     Up
mail2           2     Up
mail3           3     Up

[PS] C:\>cluster node
Listing status for all available nodes:

Node           Node ID Status
-------------- ------- ---------------------
mail1                1 Up
mail3                2 Up
mail2                3 Up

Musíme ověřit, že jsou jednotlivé členské servery (member / node) nahoře (up) a v provozním stavu (Operational). Tento stav vidíme i v Exchange Admin Center, pokud zvolíme editaci DAGu. V PowerShellu si můžeme zobrazit více detailů.

Get-DatabaseAvailabilityGroup -Identity MailDAG -Status | FL *

Také můžeme spustit test celkového zdraví DAGu.

Test-ReplicationHealth

Pozn.: Jeden server mi nešel přidat do DAGu, buď při přidání vrátil chybu, nebo po úspěšném přidání nefungoval. Dlouho jsem to ladil a nakonec vytvořil nový virtuál a nově instalovat Exchange a od té doby bylo vše OK.

Podívat se můžeme na log o přidání člena DAGu v cestě C:\ExchangeSetupLogs\DagTasks. Pak můžeme použít Event Viewer, kde se logují Operational informace - Applications and Services Logs - Microsoft - Exchange - HighAvailability - Operational. Zjistil jsem, že problémy byly s vlastním Failover Cluster. Služba Cluster Service (ClusSvc) byla Disabled a nešla nastartovat. Registry HKEY_LOCAL_MACHINE\Cluster byly neúplné. Soubory jsou v C:\Windows\Cluster.

DAG Network - sítě

DAG network je soubor jednoho nebo více subnetů, které se používají pro replikaci nebo MAPI provoz. DAG musí mít jednu MAPI síť a může mít více replikačních sítí. Je podporováno použití jedné sítě (jednoho adaptéru) pro MAPI i replikaci dohromady. Doporučuje se minimálně dvě sítě a oddělit MAPI a replikace. Pro replikace může být více sítí.

Síť pro replikaci by neměla mít nastavenu default gateway a doporučuje se vypnout Client for Microsoft Networks, File and Printer Sharing for Microsoft Networks a Register this connection's addresses in DNS. Členové DAGu musí mít stejné síťové adaptéry, každý adaptér musí mít nastavenu IPv4 adresu (pokud má server více adaptérů, tak každý musí mít adresu z jiného subnetu). Pokud na MAPI síti vypneme replikace, tak zde stejně mohou probíhat, pokud bude nedostupná síť pro replikace.

MS přímo uvádí, že na Exchange 2010 se sítě často musely konfigurovat ručně. Nyní probíhá konfigurace automaticky systémem. Když si chceme vypsat sítě, tak můžeme použít následující cmdlet, ale pokud jsem jej spustil bez parametru, tak jsem dostal chybu.

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork

Could not load file or assembly 'Microsoft.Exchange.Data, Version=14.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
 or one of its dependencies. The system cannot find the file specified.

Řešení je zavolat s parametrem, kde zadáme jméno serveru Exchange 2016

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork -Server mail1

Identity                         ReplicationEnabled Subnets
--------                         ------------------ -------
MailDAG\MapiDagNetwork           True               {{10.0.0.0/24,Up}}
MailDAG\ReplicationDagNetwork01  True               {{192.168.0.0/24,Up}}

Systém asi většinou vytvoří (rozumně) sítě MapiDagNetwork a ReplicationDagNetwork01, pokud máme dva adaptéry. Na MapiDagNetwork zapne MAPI access i Replication, na ReplicationDagNetwork01 pouze Replication. Pokud chceme provést nějaké manuální změny sítí či ručně vytvořit sítě, tak musíme na DAGu zapnout možnost manuální konfigurace (lze i v EAC).

Set-DatabaseAvailabilityGroup MailDAG -ManualDagNetworkConfiguration $true

Patrně budeme chtít na MAPI síti vypnout replikace

Set-DatabaseAvailabilityGroupNetwork -Identity MailDAG\MapiDagNetwork -ReplicationEnabled:$false

Když do DAGu přidáme server z jiné Site, a tedy jiného subnetu pro MAPI, tak se označuje jako multi-subnet DAG. Na rozdíl od Exchange 2010, zvládne Exchange 2016 správně automaticky přidat subnety do sítí.

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork -Server mail1

Identity                         ReplicationEnabled Subnets
--------                         ------------------ -------
MailDAG\MapiDagNetwork           False              {{10.0.0.0/24,Up}, {10.10.0.0/24,Up}}
MailDAG\ReplicationDagNetwork01  True               {{192.168.0.0/24,Up}}

DAG Network můžeme nyní spravovat i z EAC.

• EAC - Exchange Admin Center
• Servers - Database Availability Groups
• přidání sítě - zvolíme náš DAG a klikneme na ikonu počítače s plus - New DAG network
• úprava existující - zvolíme náš DAG a vpravo vidíme DAG Network se seznamem a akcemi

Správa kopií databáze schránek

Dokumentace Manage mailbox database copies.

Když jsme vytvořili DAG a zařadili do něj členské servery, tak můžeme k existujícím databázím (Mailbox DB) vytvářet jejich synchronizované kopie a pracovat s nimi.

Vytvoření kopie databáze v rámci DAGu

Když vytvoříme kopii databáze, tak na zvoleném serveru vznikne pasivní kopie DB a aktivují se replikace (continuous replication). Databázové kopie mají přiřazen identifikátor ve formátu Databáze\Server, například DB1\MAIL1. Při vytváření kopie DB se použijí stejné cesty pro datové soubory i logy. Na serverech tedy musí existovat stejné (použité) disky. Aby se mohla vytvořit kopie DB, tak se nesmí používat Circular Logging (odmazávání logů).

• EAC - Exchange Admin Center
• Servers - Databases
• vybereme DB, klikneme na tři tečky - More - Add database copy
• zvolíme server, kam chceme kopii umístit
• případně můžeme upravit prioritu kopie - Activation preference number
• další volitelná možnost jsou zpožděné replikace - Replay lag time

Samozřejmě můžeme přidání kopie provést v Exchange Management Shell.

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MAIL1 -ActivationPreference 2

Kontrola stavu databázových kopií

Přímo v seznamu databází v EAC vidíme seznam a stav jednotlivých kopií.

• EAC - Exchange Admin Center
• Servers - Databases
• vybereme DB a vpravo vidíme údaje, včetně kopií
• pro kopii můžeme využít View Detail

Obdobně si můžeme vypsat v PowerShellu. Zde je vidět, že probíhá prvotní synchronizace po přidání na server MAIL3.

[PS] C:\>Get-MailboxDatabaseCopyStatus DB1

Name                Status          CopyQueue  ReplayQueue LastInspectedLogTime  ContentIndex
                                    Length     Length                            State
----                ------          ---------  ----------- --------------------  ------------
DB1\MAIL1           Mounted         0          0                                 Healthy
DB1\MAIL2           Healthy         0          0           15.11.2018 18:54:13   Healthy
DB1\MAIL3           Resynchronizing 28083      0                                 Suspended

Správa databázových kopií, přepínání

S databázovými kopiemi můžeme provádět různé operace. Nejčastější je asi manuální přepnutí na pasivní kopii, tedy aktivace kopie (Activate Database Copy), Microsoft to označuje jako Database switchovers (Switchovers and failovers). Aktivní kopie DB se odpojí (dismount) na jednom serveru a pasivní kopie se připojí (mounted) jako nová aktivní na jiném. Další možnosti jsou odstranění (Remove) DB kopie, pozastavení (Suspend) a obnova (Resume) a aktualizace (Seed, Update).

• EAC - Exchange Admin Center
• Servers - Databases
• vybereme DB, vpravo vidíme kopií a u nich dostupné příkazy

Aktivace DB kopie pomocí Exchange Management Shell nabízí různé přepínače a někdy je nutné je použít.

Move-ActiveMailboxDatabase DB1 -ActivateOnServer MAIL2 -SkipMoveSuppressionChecks 

Rozložení aktivních DB kopií na servery, DAG Failback

Když máme více Mailbox serverů a DAG, tak máme vyřešeno High Availability a Fault Tolerance, protože pokud dojde k nějaké chybě serveru, tak se aktivují data na druhém. Ale asi by bylo škoda využívat servery ve stylu Active-passive, kdy jeden vykonává všechnu práci a na ostatní se pouze synchronizují data. Proto můžeme využít Active-active (Load Balancing), kdy jsou všechny servery aktivní a obsluhují klienty. Toho dosáhneme tak, že vytvoříme více mailbox DB a nastavíme je aktivní na různých serverech (a využijeme Activation preference number).

Když se provádí plánované (switchover) nebo neplánované (failover) aktivace databázových kopií, tak je výsledkem nevyvážený stav rozložení aktivních DB kopií na servery (oproti úvodnímu stavu). Stejně, jako na Exchange 2010, můžeme využít skript RedistributeActiveDatabases.ps1, který aktivuje DB na serverech podle čísla Activation Preference. Ale od Exchange Server 2016 CU2 není třeba používat, protože balancování DB kopií probíhá automaticky každý zadaný čas (default 1 hodina) pro DAG PreferenceMoveFrequency (Get-DatabaseAvailabilityGroup | FT Name,PreferenceMoveFrequency).

Údržba serveru v DAGu

Než začneme provádět nějakou údržbu serveru nebo instalaci aktualizací, tak je doporučeno přepnout server do Maintenance Mode. Ten přesune aktivní databáze a funkce na ostatní servery. Podrobný popis Performing maintenance on DAG members. Můžeme využít skripty, které jsou součástí instalace Exchange serveru.

cd $ExScripts
.\StartDagServerMaintenance.ps1 -ServerName <ServerName>
.\StopDagServerMaintenance.ps1 -serverName <ServerName>

Server Switchover

Pomocí EAC můžeme jednoduše provést Server Switchover, který aktivuje kopie DB na jiném serveru.To se doporučuje provést před každým restartem Exchange serveru, který je členem DAGu.

• EAC - Exchange Admin Center
• Servers - Servers
• vybereme server, ze kterého chceme přesunout aktivní DB, vpravo klikneme na Server Switchover

Datacenter Activation Coordination (DAC) mode

Defaultně je vypnutý, ale MS jej doporučuje zapnout. Při startu serveru kontroluje, zda je možno aktivovat databázi, pokud máme více datových center a byla aktivována kopie v druhém datovém centru. Má zabránit Split Brain, tedy aby nám aktivně běžely dvě kopie stejné DB. Například, pokud v primárním DC dojde k výpadku proudu a všechny servery padnou. Aktivuje se nám záložní DC a zde kopie DB. V primárním centru se obnoví napájení, server nastartuje, ale nemá komunikaci se záložním. Pak standardně aktivuje DB. Více info Datacenter Activation Coordination mode.

Set-DatabaseAvailabilityGroup -Identity mailDAG -DatacenterActivationMode DagOnly

Pokud používáme DAC mode, tak můžeme využít příkazy pro přepnutí datových center.

Stop-DatabaseAvailabilityGroup
Restore-DatabaseAvailabilityGroup
Start-DatabaseAvailabilityGroup

Client Access Server (CAS) Array

Dříve se po vysokou dostupnost (High Availability) využíval DAG a CAS Array. Ještě byla otázka, jestli máme pouze jednu lokalitu/datové centrum/Site nebo více. Při výpadku lokality nefungovalo CAS Array pro automatické přepnutí. Exchange 2016 již CAS Array vůbec nepoužívá.

CAS Array sloužil pro MAPI/RPC připojení klienta Outlook na Client Access Server. Na Exchange 2016 se MAPI/RPC nepoužívá, místo toho buď MAPI/HTTP (MAPI over HTTP) nebo Outlook Anywhere (MAPI/RPC over HTTP).

Na databázích si můžeme vypsat údaj RpcClientAccessServer, kde je buď adresa serveru, nebo adresa CAS Array, pokud jsme jej používali. I po zrušení všech Exchange 2010 serverů zůstane tento atribut nastaven, ale to nevadí, protože se nepoužívá.

Get-MailboxDatabase | Select Name,RpcClientAccessServer

Odolnosti lokalit - Site Resilience

To znamená DAG přes více lokalit / datových center. Dokumentace Site resilience. Souvisí s popisem Namespaces v prvním článku série.

Exchange 2016 přináší změnu, že automaticky funguje přepnutí na servery v jiné lokalitě (datacentru/Site). Dříve se musel ručně měnit namespace. Klientská spojení jsou nyní pomocí HTTPS (i z Outlooku) a může být přiřazeno více IP adres, které se postupně zkouší. Přímé připojení přes MAPI již není povoleno. Na Exchange 2016 se klient může připojit k libovolnému Mailbox serveru a je zajištěn prostup požadavku na server, kde je aktivní databáze pro danou schránku. Můžeme využít DNS round robin, vytvoříme jeden DNS záznam, který bude obsahovat IP adresy všech serverů.

Řešení problémů a chyb

Oprava sítí DAG Network, odstranění neexistující

Sítě a subnety se přidávají samy, ale již se neodstraňují, když třeba odstraníme servery, které byly v jiné lokalitě. Je dobré občas spustit test a případně provést opravy. Úpravy se mohou dělat Exchange Management Shell i v EAC, kde je například jednodušší editace subnetu.

[PS] C:\>Test-ReplicationHealth

Server          Check                      Result     Error
------          -----                      ------     -----
MAIL1           ClusterService             Passed
MAIL1           ReplayService              Passed
MAIL1           ActiveManager              Passed
MAIL1           TasksRpcListener           Passed
MAIL1           TcpListener                Passed
MAIL1           ServerLocatorService       Passed
MAIL1           DagMembersUp               Passed
MAIL1           MonitoringService          Passed
MAIL1           ClusterNetwork             *FAILED*   Subnet '10.0.0.0/24' on network 'MapiDagNetwork' is not Up. 
  Current state is 'Misconfigured'.
                                                      Subnet '10.0.0.0/24' on network 'MapiDagNetwork' is not Up.
  Current state is 'Misconfigured'.
                                                      Subnet '10.10.0.0/24' on network 'MapiDagNetwork' is not Up.
  Current state is 'Misconfigured'.
                                                      Subnet '10.10.0.0/24' on network 'MapiDagNetwork' is not Up.
  Current state is 'Misconfigured'.
MAIL1           QuorumGroup                Passed
MAIL1           FileShareQuorum            Passed
MAIL1           DatabaseRedundancy         Passed
MAIL1           DatabaseAvailability       Passed
MAIL1           DBCopySuspended            Passed
MAIL1           DBCopyFailed               Passed
MAIL1           DBInitializing             Passed
MAIL1           DBDisconnected             Passed
MAIL1           DBLogCopyKeepingUp         Passed
MAIL1           DBLogReplayKeepingUp       Passed

Test ukazuje chybu na MAPI síti (píše dokonce, že není nahoře, ale ona v tuto chvíli normálně fungovala). Tak si vypíšeme DAG Network.

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork

Identity                         ReplicationEnabled Subnets
--------                         ------------------ -------
MailDAG\MapiDagNetwork           False              {{10.0.0.0/24,Misconfigured}, {10.10.0.0/24,Misconfigured}}
MailDAG\ReplicationDagNetwork01  True               {{192.168.0.0/24,Up}}
MailDAG\ReplicationDagNetwork02  False              {{fe80::/64,Misconfigured}}

U sítě MapiDagNetwork a ReplicationDagNetwork02 vidíme chybu, stav je Misconfigured. MAPI síť hlásí chybu, protože jediný server v druhé lokalitě (síť 10.10.0.0) byl zrušen. Je tedy potřeba editovat síť a odstranit nepoužívaný subnet.

• EAC - Exchange Admin Center
• Servers  - Database Availability Groups
• zvolíme náš DAG, vpravo vidíme DAG Network, kde najdeme požadovanou síť
• klikneme na View details
• zde vidíme přiřazené subnety, můžeme je editovat, odstraňovat i přidávat

Pozn.: Odstranění subnetu nebo sítě trvá delší dobu. Takže subnet/síť se přestane zobrazovat až po několika minutách.

Replikační síť 2 vznikla nějak automaticky pro nepoužívanou IPv6 adresu. Potřebujeme celou síť odstranit. Když to zkusíme, tak dostaneme chybu, že je třeba nejprve odstranit subnety.

[PS] C:\>Remove-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02

DatabaseAvailabilityGroupNetwork 'ReplicationDagNetwork02' can't be removed because it contains active subnets. To remove
 the network, all active subnets must first be assigned to other networks. If you want to disable the use of the network,
 consider using the Set-DatabaseAvailabilityGroupNetwork cmdlet with the -IgnoreNetwork or -ReplicationEnabled parameters.
  + CategoryInfo          : InvalidArgument: (:) [Remove-DatabaseAvailabilityGroupNetwork], DagNetworkManagementException
  + FullyQualifiedErrorId : [Server=MAIL1,RequestId=46104fdf-ef9f-4c67-b991-7dba758fe4f9,TimeStamp=19.02.2019 18:16:28]
 [FailureCategory=Cmdlet-DagNetworkManagementException] 7B8813CC,Microsoft.Exchange.Management.SystemConfigurationTasks.
RemoveDatabaseAvailabilityGroupNetwork
  + PSComputerName        : mail1.firma.local

[PS] C:\>Set-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02 -Subnets $none

Odstraníme všechny subnety, když si hned vypíšeme údaje o síti, tak v ní pořád subnety uvidíme. Musíme několik minut počkat a zkusit to znovu.

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02

Identity                        ReplicationEnabled Subnets
--------                        ------------------ -------
MailDAG\ReplicationDagNetwork02 False              {}

Pak již odstranění sítě proběhne

[PS] C:\>Remove-DatabaseAvailabilityGroupNetwork MailDAG\ReplicationDagNetwork02

Confirm
Are you sure you want to perform this action?
Removing database availability group network "MailDAG\ReplicationDagNetwork02".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Content index ve stavu Failed - DB kopie

Docela často se může stát, že když se podíváme (EMS nebo EAC) na stav pasivní kopie DB, tak je zde Content index state: Failed. V tu chvíli se nám nepovede přepnout tuto kopii na aktivní. Tato situace nastává například vždy po restartu některého serveru. Návod na opravu je popsán třeba v Repairing a Failed Content Index in Exchange Server 2016. Ale ukázalo se, že většinou stačí nějakou dobu počkat (třeba 15 minut) a tato chyba sama zmizí.

Problém s aktivací databázové kopie

Chtěl jsem udělat Database switchovers, tedy aktivovat DB kopii na jiném serveru. Operace proběhla, aniž by se zobrazila nějaká chyba. Ale když jsem se na databázi po chvilce podíval, tak byla znovu aktivní na původním serveru. Při dalším pokusu se zobrazila chyba, že je příliš mnoho logs to inspect and replay.

An Active Manager operation failed. Error: The database action failed. Error: An error occurred while trying to validate
 the specified database copy for possible activation. Error:

   mail1:
   Database copy 'DB2' on server 'mail1' has 124 logs to inspect and replay, which is higher than maximum allowed replay
 queue length of 10. If you need to activate this database copy, you can use the Move-ActiveMailboxDatabase cmdlet with
 the -SkipLagChecks and -MountDialOverride parameters to forcibly activate the database copy. If the database does not
 automatically mount after running Move-ActiveMailboxDatabase successfully, use the Mount-Database cmdlet to mount the
 database.

K tomu si můžeme zobrazit aktuální detaily o stavu DB kopií:

[PS] C:\>Get-MailboxDatabaseCopyStatus * | sort name | Select name, status, contentindexstate, ReplayQueueLength

Name         Status  ContentIndexState ReplayQueueLength
----         ------  ----------------- -----------------
DB2\MAIL1    Healthy            Failed                46
DB2\MAIL2    Mounted           Healthy                 0

Zde vidíme frontu logů (ReplayQueueLength) a také stav Content Index jako Failed. Když nějakou dobu počkáme, tak se fronta vyprázdní a stav vrátí na Healthy. Pak můžeme znovu přesunout (aktivovat) DB kopii, ale dopadne to stejně. Po několika pokusech se již aktivace kopie nepodaří a dostaneme chybu:

An Active Manager operation failed. Error: The database action failed. Error: Move for database 'DB2' was suppressed
 because too many moves have happened recently. 4 moves

Pokud chceme v tuto chvíli udělat přesun (aktivaci), tak musíme využít Exchange Management Shell a přidat atribut:

Move-ActiveMailboxDatabase DB2 -ActivateOnServer MAIL1 –SkipMoveSuppressionChecks

Ale stále se kopie neaktivuje na novém serveru. Při prohlížení aplikačního logu událostí na cílovém serveru jsem nalezl příčinu:

EventID 121 ExchangeStoreDB

At '23.02.2019 18:45:40' the Exchange store database 'DB2' copy on this server appears to have failed due to insufficient
 memory. For more details about the failure, consult the Event log on the server for other "ExchangeStoreDb" events.
 Recovery was not attempted.

Na serveru byl přihlášen uživatel (správce) a obsazoval asi 1,5 GB operační paměti. Po jeho odhlášení začalo vše fungovat.