Migrace Exchange Server 2016 na Subscription Edition (SE) část 3 Mail Flow, DB, DAG, cert

Pozn.: Prakticky jsem instaloval Exchange Server SE roli Mailbox server na Windows Server 2025. V prostředí s jinou interní a veřejnou DNS doménou a Split DNS (Split-Brain DNS). Do existující organizace Exchange 2016 s využitím DAG (Database Availability Group).

Mail Flow - tok pošty

• Exchange Server 2016 Mail Flow - směrování pošty a konektory - můj starší článek
• Mail flow and the transport pipeline
• Configure mail flow and client access on Exchange servers

Přenos pošty mezi servery v organizaci a mezi externími servery (internet) probíhá pomocí protokolu SMTP. Exchange Server využívá Transport Pipeline, což je soubor služeb, komponent a front. Důležité komponenty jsou Transport Service (transportní služby) a Connectors (konektory), kde nás zajímají Receive Connectors a Send Connectors.

Řada konfigurací je společná pro celou Exchange organizaci, takže již máme nastavené například Accepted Domains a Email Address Policies. Existují také Send Connectors, kde stačí přidat nový server jako zdrojový pro odesílání.

Receive Connectors - přijímací konektory

Při instalaci se na serveru automaticky vytvoří pět defaultních Receive Connectors pro SMTP příjem zpráv. Většinou potřebujeme upravit některá nastavení tak, jak je používáme na aktuálních serverech. Případně vytvořit nový speciální konektor. Věžně bychom měli mít konektory stejné na všech serverech.

• Default Frontend <ServerName>
• Client Frontend <ServerName>
• Default <ServerName>
• Client Proxy <ServerName>
• Outbound Proxy Frontend <ServerName>

Informace o konektorech

Konektory můžeme zkontrolovat a nastavit ručně pomocí EAC.

• EAC - Exchange Admin Center
• Mail Flow - Receive Connectors

Více informací zjistíme pomocí Exchange Management Shell (EMS), kde můžeme vypsat všechny konektory v organizaci, konektory na určitém serveru nebo detaily konkrétního konektoru. Některé hodnoty jsou zajímavější, protože se v praxi mění.

Get-ReceiveConnector -Server MAIL0
Get-ReceiveConnector -Identity "MAIL0\Default Frontend MAIL0" | FL *
Get-ReceiveConnector -Identity "MAIL0\Default Frontend MAIL0" | FL Server,*Message*,*Logging*,Bindings,Remote*,Tls*,AuthM*,*Groups

Můžeme využít různé skripty. Pokud vytváříme více nových serverů, tak je nejlepší připravit konfiguraci pomocí PowerShellu, kterou můžeme jednoduše spustit na dalších serverech.

Příklad skriptu pro zobrazení rozdílů dvou konektorů (na starém a novém serveru).

$con1 = Get-ReceiveConnector -Identity "MAIL0\Default Frontend MAIL0"
$con2 = Get-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1"
$props = ($con1 | Get-Member -MemberType Properties).Name |
 Where-Object { $_ -notin @('RunspaceId', 'Guid', 'DistinguishedName', 'IsValid', 'Id', 'PSComputerName', 'WhenChanged', 'WhenCreated', 'WhenChangedUTC', 'WhenCreatedUTC' , 'ObjectClass') }
$differences = foreach ($prop in $props) {
  $val1 = $con1.$prop
  $val2 = $con2.$prop
  if($val1 -ne $val2) {
    [PSCustomObject]@{
      Property = $prop
      Value1   = $val1
      Value2   = $val2
    }
  }
}
$differences | FT -AutoSize

Nastavení konektoru

Potřebné hodnoty pak můžeme nastavit pomocí EMS, řadu také pomocí EAC.

Set-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000
Set-ReceiveConnector -Identity "MAIL1\Client Proxy MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 `
 -ProtocolLoggingLevel Verbose -MessageRateLimit unlimited
Set-ReceiveConnector -Identity "MAIL1\Default MAIL1" -MaxMessageSize "40 MB" -ProtocolLoggingLevel Verbose
Set-ReceiveConnector -Identity "MAIL1\Outbound Proxy Frontend MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000
Set-ReceiveConnector -Identity "MAIL1\Client Frontend MAIL1" -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 `
 -ProtocolLoggingLevel Verbose

Vytvoření konektoru

Na internetu nalezneme i různé skripty na kopírování konektorů, například Copy-ReceiveConnector. Nebo rady Copy receive connector to another Exchange Server. Vytvořit nový konektor můžeme ručně v EAC nebo EMS.

New-ReceiveConnector -Name "Connector AS1 MAIL1" -Usage Custom -TransportRole Frontend -Bindings 0.0.0.0:25 `
 -RemoteIPRanges 10.10.0.50 -MaxMessageSize "40 MB" -MaxRecipientsPerMessage 1000 -ProtocolLoggingLevel Verbose

Oprávnění a autentizace

Pomocí EAC můžeme jednoduše nastavit bezpečnostní mechanismy pro autentizaci a oprávnění pomocí Permission Groups. Pokud nám skupiny nestačí, tak musíme konfigurovat přímo Permissions.

Výpis autentizačních mechanismů a skupin oprávnění

Get-ReceiveConnector -Server MAIL0 | Sort-Object Identity | FT Identity,AuthMechanism,PermissionGroups -AutoSize

Výpis oprávnění na konektoru

Get-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1" | Get-ADPermission |
 Where-Object {$_.IsInherited -eq $false -and $_.User -ilike "NT*"} | Sort-Object User |  FT User, ExtendedRights

Kopírovat oprávnění z jednoho konektoru na druhý

$sourcePermissions = Get-ReceiveConnector -Identity "MAIL0\Connector AS1 MAIL0" | Get-ADPermission |
 Where-Object {$_.IsInherited -eq $false -and $_.User -ilike "NT*"}
$sourcePermissions | ForEach-Object {
  Get-ReceiveConnector "MAIL1\Connector AS1 MAIL1" | Add-ADPermission -User $_.User -Deny:$_.Deny -AccessRights $_.AccessRights `
   -ExtendedRights $_.ExtendedRights
}

Kontrola limitu na počet odesílaných zpráv

Get-ReceiveConnector -Server MAIL1 | FT Name, MessageRateLimit

Send Connectors - odesílací konektory

Send Connectors slouží k SMTP odesílání zpráv mimo organizaci. Automaticky se nevytváří, ale v existující organizaci je již máme vytvořené. Stačí přidat nový server jako zdrojový pro odesílání (Source Server) do daného konektoru. Musíme mít alespoň jeden Send Connector pro odesílání do internetu. Pokud máme Exchange Hybrid, tak existuje další pro odesílání zpráv do Exchange Online.

• EAC - Exchange Admin Center
• Mail Flow - Send Connectors
• Edit - Scoping - Source server

Serverové certifikáty pro šifrování a autentizaci

• Digital certificates and encryption in Exchange Server

V prvním díle sme si popsali vystavení certifikátu od interní CA a nastavení pro služby Exchange serveru. Dnes doplníme další informace o certifikátech a použití certifikátu od veřejně důvěryhodné CA (komerční CA).

Defaultní certifikáty

Po instalaci Exchange Serveru se na něm nachází několik self-signed certifikátů. Žádný bychom neměli smazat. První dva vytvoří Exchange, další Windows pro IIS a Entra ID. Certifikáty, které vidíme v EAC (zobrazuje se jejich Friendly name):

• Microsoft Exchange - platnost 5 let, IMAP, POP, IIS, SMTP, důvěřují mu všechny Exchange servery v organizaci, šifruje interní komunikaci mezi Exchange servery, v rámci služeb serveru a pro klientská připojení, která jsou proxována z CAS na backend
• Microsoft Exchange Server Auth Certificate - platnost 5 let, SMTP, slouží pro autentizaci mezi servery a integraci pomocí OAuth, vytvoří se s prvním serverem v organizaci a na další se kopíruje, pokud skončí jeho platnost, tak musíme nově vystavit Exchange nefunkční přihlášení do OWA, konec platnosti OAuth certifikátu, MonitorExchangeAuthCertificate
• WMSVC-SHA2 - platnost 10 let, pro vzdálenou správu IIS (využívá jej Web Management service), nesmíme mazat, jinak tato služba nenastartuje a pak nejdou instalovat aktualizace Exchange
• MS-Organization-P2P-Access [2025] - platnost 1 den, pro zařízení připojené do Microsoft Entra ID, důvěra v rámci Tenantu

Certifikát od komerční CA

Certifikát potřebujeme pro

• šifrování komunikace při přístupu klientů (interních i externích) ke službám (HTTPS běžící na IIS)
• šifrování SMTP komunikace mezi Exchange serverem a externími servery
• pokud využíváme Exchange Hybrid a případně pro další služby jako POP a IMAP

Je doporučeno používat

• co nejméně certifikátů (ideálně jeden a využít SAN nebo wildcard)
• co nejméně názvů v certifikátu (adres / hostnames)
• stejný certifikát využít na všech Exchange serverech
• pro připojení klientů a externích serverů použít certifikáty od komerční certifikační autority

Pokud používáme Load Balancer, Reverse Proxy nebo Firewall, kde se ukončuje TLS, tak pro HTTPS nastavujeme certifikát tam. Pokud máme Edge Transport server nebo jinou SMTP bránu, tak nastavujeme certifikát pro SMTP tam.

Pokud máme na Exchange serveru primárně interní certifikát, tak stále můžeme potřebovat pro některé služby nastavit komerční certifikát (třeba pro Exchange Hybrid).

Import a přiřazení služeb

• certifikát získáme často jako PFX a pomocí certlm.msc importujeme do Windows
• pro lepší přehled je dobré nastavit Friendly Name

Přiřazení služeb, pokud primárně používáme interní certifikát, tak nastavíme pouze SMTP.

• EAC - Exchange Admin Center
• Servers - Certificates
• zvolíme nový Exchange server a označíme importovaný certifikát
• klikneme na tužku (Edit)
• záložce Services vybereme SMTP
• klikneme na Save
• na dotaz, zda chceme nahradit existující defaultní SMTP certifikát, odpovíme No (aby se nepřepsal certifikát pro interní komunikaci)

Pozn.: V některých případech (třeba změna certifikátu pro IIS Exchange Back End) je po výměně certifikátu potřeba restartovat IIS, třeba pomocí cmd iisreset.

Send and Receive Connectors

Na konektorech se standardně využívá defaultní SMTP certifikát. Pokud chceme nastavit jiný, nebo mít jistotu, který certifikát se použije, tak můžeme nastavit pomocí EMS.

Pro odesílání pošty využíváme Send Connectors, který je globální, takže již nastavený. Konfiguraci jsem popisoval v SMTP over TLS šifrování na MS Exchange a Cisco Email Security. Pokud máme Exchange Hybrid, tak máme i další odchozí konektor do Exchange Online.

$TLSCert = Get-ExchangeCertificate -Thumbprint AC445208321CCE5AA22588700D8864F0E8BCC052
$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"
Set-SendConnector -Identity Internet -TlsCertificateName $TLSCertName

Pro příjem pošty máme Receive Connectors. Pokud máme Exchange Hybrid, tak standardně pošta z Exchange Online (jeho Outbound konektoru) dorazí na Default Frontend Receive Connector a je potřeba, aby zde byl správný certifikát (provádí se ověření).

Set-ReceiveConnector -Identity "MAIL1\Default Frontend MAIL1" -TlsCertificateName $TLSCertName

Na nastavený certifikát pro Exchange Hybrid se můžeme podívat.

Get-HybridConfiguration | FL TlsCertificateName

Mailbox Databases - databáze schránek

• Manage mailbox databases in Exchange Server

Při instalaci Exchange serveru se nám vytvořila první databáze s názvem Mailbox Database <číslo>. Soubory databáze i transakčních logů jsou umístěny defaultně v cestě C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\. Je doporučeno mít datové soubory a logy umístěné každé na jiném disku (a to jinde, než je operační systém).

Přejmenování databáze

• EAC - Exchange Admin Center
• Servers - Databases
• zvolíme databázi a klikneme na tužku (Edit)
• změníme název a uložíme Save

Pomocí Exchange Management Shell (EMS):

Set-MailboxDatabase "Mailbox Database 0375312042" -Name "DBPraha"

Přesun databáze a logů

Protože bychom neměli mít soubory databáze a jejich transakčních logů na Cčku, tak přesuneme na samostatné disky. Musíme využít EMS. Při přesunu dojde k odpojení (dismount) DB.

Move-DatabasePath -Identity DBPraha -EdbFilePath D:\DBPraha\DBPraha.edb -LogFolderPath E:\DBPraha\

Vytvoření nové databáze

• EAC - Exchange Admin Center
• Servers - Databases
• klikneme na plus (New)
• Mailbox database - jméno databáze
• Server - na kterém serveru se má vytvořit
• Database file path - cesta k datovým souborům
• Log folder path - cesta k logům

Po vytvoření nové Mailbox DB je nutné provést restart služby Microsoft Exchange Information Store (kvůli cache). Buď přes services.msc nebo PowerShell.

Restart-Service MSExchangeIS

Problém s vytvořením databáze

Při vytváření databáze, přesněji jejím připojení (Mount), jsem opakovaně narážel na problém a zobrazovala se chyba:

Failed to mount database "DBPraha". Error: An Active Manager operation failed. Error: Couldn't find the specified mailbox
 database with GUID '3835a9b8-a055-45ca-8672-f2312b07bce9'. [Database: DBPraha, Server: mail1.firma.local]

Databáze se vytvořila (i když bylo potřeba kliknout na Cancel v dialogu vytváření). Její stav se zobrazoval Unknow, stačilo pár minut počkat, až se změnil na Dismounted. Pak šla DB připojit (Mount).

Limit na počet připojených databází

Při připojování databáze můžeme narazit ještě na chybu níže. Exchange Server Standard má limit na maximálně 5 připojených databází schránek. Další nedovolí připojit a zobrazí chybu:

Failed to mount database "DBPraha". Error: An Active Manager operation failed. Error: The database action failed. Error: An
 error occurred while trying to select a database copy for possible activation. Error: The database 'DBPraha' was not mounted
 because errors occurred either while validating database copies for possible activation, or while attempting to activate
 another copy. Detailed error(s): MAIL1: An Active Manager operation failed. Error: Operation failed with message:
 MapiExceptionTooManyMountedDatabases: Unable to mount database.

Parametry databáze

Pro každou novou databázi (včetně té výchozí) potřebujeme nastavit její parametry. Jde hlavně o limity (Limits) na velikost schránek, přiřazení Offline address book, případně pro testování (když DB nezálohujeme) zapnout Circular Logging (odmazávání transakčních logů, to nemůžeme použít, když chceme přidat DAG kopii).

• EAC - Exchange Admin Center
• Servers - Databases
• zvolíme databázi a klikneme na tužku (Edit)
• záložky maintenance, limits, client settings
• uložíme Save

Pomocí Exchange Management Shell (EMS):

Get-MailboxDatabase | FT Name,IssueWarningQuota,*SendQuota,*ReceiveQuota,*book

Set-MailboxDatabase DBPraha -IssueWarningQuota "3,5 GB" -ProhibitSendQuota "3,9 GB" -ProhibitSendReceiveQuota "4 GB" `
 -OfflineAddressBook "\Default Offline Address List (Ex2013)"

Database Availability Group (DAG)

• Exchange Server 2016 Database Availability Group - můj starší článek
• Database availability groups
• Managing high availability and site resilience in Exchange Server

Technologie DAG slouží k zajištění vysoké dostupnosti poštovních schránek. Databáze jsou replikovány mezi více servery, které jsou členy DAGu. Každá databáze má jednu aktivní kopii a jednu či více pasivních kopií, které slouží pro automatické převzetí při výpadku. V rámci DAGu může existovat více databází, přičemž každá může být aktivní na jiném serveru. Tím se rozkládá zátěž mezi servery a zároveň je zajištěna vysoká dostupnost.

Členy DAGu mohou být pouze servery se stejnou verzí Exchange Serveru. Při přechodu na novou verzi Exchange  je proto nutné vytvořit nový DAG a provést migraci schránek. Doporučuje se provozovat DAG bez IP adresy, tedy bez cluster administrative access point, cluster name object (CNO) v AD a DNS jména.

Pro DAG se vytváří objekt v AD třídy msExchMDBAvailabilityGroup. Podívat se na něj můžeme pomocí ADSI Edit v cestě Configuration - Services - Microsoft Exchange - organizace - Administrative Groups - Exchange Administrative Group (FYDIBOHF23SPDLT) - Database Availability Groups.

Vytvoření DAGu

Konfiguraci můžeme provádět pomocí EMS, ale většina věcí jde nastavit také v EAC, na které se zaměříme. Potřebujeme Witness server, kde Exchange vytvoří sdílenou složku (Quorum Witness Resource). Musí jít o Windows OS, kde do skupiny lokálních administrátorů zařadíme doménovou skupinu Exchange Trusted Subsystem.

• EAC - Exchange Admin Center
• Servers - Database Availability Groups
• klikneme na plus (New)
• zadáme unikátní jméno, adresu a složku Witness serveru, nepřidáme žádnou IP adresu

Přidání serveru do DAGu

• 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)
• klikneme na plus (Add) a přidáme náš server, uložíme tlačítkem Save

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

• instalace komponenty Windows Failover Clustering
• vytvoří se Failover Cluster pro DAG se zadaným jménem, do kterého se přidá server
• 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
• neprovede se (máme DAG bez IP) vytvoření CNO v default Computers kontejneru AD, registrace DNS záznamu pro jméno DAGu

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

• instalace komponenty Windows Failover Clustering
• přidání serveru do Failover Cluster
• server se přidá do DAG objektu v AD DS
• 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

Sítě DAG networks

DAG network je tvořena jedním nebo více subnety, které slouží pro MAPI provoz a replikaci databází. Každý DAG musí mít alespoň jednu MAPI síť a může mít více sítí pro replikaci. Můžeme využít společnou síť pro oba typy provozu, ale doporučuje se je oddělit.

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.

Výpis sítí pomocí EMS.

[PS] C:\>Get-DatabaseAvailabilityGroupNetwork

Identity                            ReplicationEnabled Subnets
--------                            ------------------ -------
MailDAG\MapiDagNetwork              False              {{10.20.0.0/24,Up}}
MailDAG\ReplicationDagNetwork01     True               {{10.100.0.0/24,Up}}
ExchangeDAG\MapiDagNetwork          True               {{10.20.0.0/24,Up}}
ExchangeDAG\ReplicationDagNetwork01 True               {{10.100.0.0/24,Up}}

Sítě DAG jsou automaticky konfigurovány systémem. Pokud máme dobře nastavené síťové adaptéry, tak se rozumně vytvoří DAG sítě. Ale replikace se zapne na všech. Pokud chceme provádět nějaké změny, tak musíme nejprve na DAGu povolit manuální konfiguraci.

• EAC - Exchange Admin Center
• Servers - Database Availability Groups
• zvolíme náš DAG a klikneme na ikonu tužky (Edit)
• zatrhneme Configure database availability group networks manualy, uložíme tlačítkem Save

Třeba nechceme na MAPI síti replikace. Po povolení manuálního nastavení můžeme sítě upravovat.

• EAC - Exchange Admin Center
• Servers - Database Availability Groups
• zvolíme náš DAG, vpravo vidíme DAG Network
• u jednotlivých sítí můžeme zvolit Disable Replication nebo View details

Přidání kopie databáze

• Manage mailbox database copies

Máme vytvořený DAG s několika Mailbox servery. Nyní můžeme k existujícím nebo nově vytvořeným databázím schránek (Mailbox DB) vytvořit kopie. Automaticky se nastaví nepřetržitá replikace (continuous replication) mezi stávající databází a její kopií. Na serverech musí existovat stejné disky, protože pro kopii se použijí stejné cesty pro datové soubory i logy. Nesmí být nastaven Circular Logging.

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

Opakovaně jsem narážel na následující chybu při přidání databázové kopie.

The seeding operation failed. Error: An error occurred while running prerequisite checks. Error: The specified database isn't
 configured for replication and therefore cannot be used to perform seed operations. [Database: DBPraha, Server: mail1.firma.local]

Microsoft má článek Error when running Add-MailboxDatabaseCopy command: The seeding operation failed. Zde uvádí jako příčinu, že zdrojový a cílový server je připojen k jinému doménovému řadiči. V mém případě ale oba servery používali stejný DC.

Přestože se zobrazila chyba, tak po zavření okna (muselo se použít Cancel) byla kopie vytvořena. Ukazoval se u ní stav Passive Failed and Suspended. Stačilo zvolit Update, vybrat zdrojový server a spustit Seeding (pokud se zobrazilo varování, tak nechat provést úklid).

Kontrola stavu serveru

Pomocí cmdletu můžeme zobrazit stav serveru v DAGu a zkontrolovat replikace.

[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             Passed
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

Logy Exchange serveru

Na Exchange Serveru se stále vytváří ohromné množství logů, řada z nich se nijak automaticky neodmazává (nerotuje). Jde hlavně o dva typy logů (umístění):

• IIS logy v cestě C:\inetpub\logs\LogFiles
• logy Exchange serveru v cestě C:\Program Files\Microsoft\Exchange Server\V15\Logging
• nějaké logy ještě nalezneme v C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs, ale ty se patrně odmazávají

Nesmíme tedy zapomenout na pravidelně spouštěný skript, který bude staré logy mazat.

Message Tracking - logování toku pošty

• Exchange Server 2016 DSN, Message Tracking a analýza posílání zpráv - můj starší článek
• Transport logs in Exchange Server

Další logy na Exchange serveru jsou transportní logy (co se děje v Transport Pipeline), mezi které patří Message Tracking log pro sledování toku pošty. Standardní cesta k logům:

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\MessageTracking

Ve výchozím nastavení se používá rotování logů (circular logging), kdy se odmazávají logy starší než 30 dní nebo když složka logů dosáhne velikosti 1 GB. V praxi můžeme chtít hodnoty navýšit.

Get-TransportService | FL Name, MessageTracking*

Set-TransportService -Identity MAIL1 -MessageTrackingLogMaxAge 60 -MessageTrackingLogMaxDirectorySize 4GB

Protocol Logging - logování SMTP konverzací

• Protocol logging in Exchange Server

Podobně máme detailní protokolové logy (SMTP logy), kde se loguje komunikace na konektorech. Defaultně je logování zapnuto pouze na vybraných konektorech, ale hodí se zapnout všude. Logy se ukládají do různých složek podle služby a typu konektoru.

• Front End Transport service
  • Receive connectors: %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive
  • Send connectors: %ExchangeInstallPath%TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpSend
• Transport service
  • Receive connectors: %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
  • Send connectors: %ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend
• Mailbox Transport Delivery service
  • Receive connectors: %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpReceive\Delivery
• Mailbox Transport Submission service
  • Send connectors: %ExchangeInstallPath%TransportRoles\Logs\Mailbox\ProtocolLog\SmtpSend\Submission

Pozn.: Běžně je %ExchangeInstallPath% = C:\Program Files\Microsoft\Exchange Server\V15\.

Ve výchozím nastavení se používá rotování logů (circular logging), kdy se odmazávají logy starší než 30 dní nebo když složka logů dosáhne velikosti 250 MB. V praxi můžeme chtít hodnoty navýšit pro vybrané služby.

Get-TransportService | FL Name, *ProtocolLog*
Get-FrontEndTransportService | FL Name, *ProtocolLog*

Set-TransportService -Identity MAIL1 -ReceiveProtocolLogMaxDirectorySize "1,5 GB" -SendProtocolLogMaxDirectorySize "1,5 GB"
Set-FrontEndTransportService -Identity MAIL1 -ReceiveProtocolLogMaxDirectorySize "1,5 GB" -SendProtocolLogMaxDirectorySize "1,5 GB"

Mail Queue - fronta pošty

• Queues and messages in queues in Exchange Server

Soubor mail.que nesouvisí s logy, ale může zabírat desítky GB na systémovém disku. Všechny zprávy zařazené do fronty se ukládají do souboru databáze fronty. Frontu můžeme přesunout na jiný disk. Standardní cesta je

C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue

Exchange Server Health Checker

Když dokončíme základní konfiguraci, tak je dobré použít skript Exchange Health Checker. Tento skript zjišťuje běžné problémy s konfigurací a kontroluje mnoho parametrů Exchange serveru. Upozorní nás na nastavení, která mohou ovlivnit výkon i bezpečnost organizace. Je vhodné vždy stáhnout poslední verzi a používat jej pravidelně.

.\HealthChecker.ps1
.\HealthChecker.ps1 -BuildHtmlServersReport

Automatické aktualizace Windows

Osobně si myslím, že pokud máme Exchange cluster (DAG), tak není dobré používat automatické aktualizace. Nedojde k přepnutí serveru do Maintenance Mode, takže se vše zachová jako by došlo k pádu serveru. Exchange se s tím umí vypořádat, ale lepší je provést přepnutí a ruční instalaci aktualizací.

Přepnout Windows Update do manuálního režimu můžeme třeba pomocí Server Configuration tool SConfig v příkazové řádce.