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.

Oficiální dokumentace k Exchange Server 2016, hlavně kapitoly Client Access services,  Clients and mobile in Exchange Server, Client Access protocol architecture, Configure mail flow and client access on Exchange servers.

Komunikace klientů se serverem

Pro přístup klientů k serveru je k dispozici několik protokolů. Většinou dnes jde o HTTP (Hypertext Transfer Protocol) nebo zapouzdření jiného protokolu do HTTP. V praxi samozřejmě používáme vždy šifrované (TLS) HTTP, tedy HTTPS. To znamená zjednodušení prostupů, spojení, standardizaci protokolů, ale také potřebu správně řešit certifikáty. Klientské připojení je nyní bezstavové (není třeba session affinity). Protože zpracování probíhá na backendu Mailbox serveru, tak nezáleží, který server přijme klientský požadavek. Pro rozvažování můžeme využít třeba DNS Round Robin.

Outlook - MAPI

Microsoft Outlook využívá jako hlavní protokol MAPI (Messaging Application Programming Interface). Dříve se připojoval pomocí MAPI over RPC (MAPI/RPC), což způsobovalo různé komplikace. Dnes již připojení MAPI/RPC není povolené a používá se primárně MAPI over HTTP (MAPI/HTTP). Pokud jej klient nepodporuje, tak může použít Outlook Anywhere (MAPI over RPC over HTTP, tedy MAPI uvnitř RPC a to uvnitř HTTP, označuje se také jen RPC/HTTP), který se dříve používal na připojení z internetu.

Mobilní klienti - ActiveSync, OWA

Mobilní klienti využívají standardně protokol Exchange ActiveSync, který je založený na HTTP a XML. Pro přístup bez klienta máme k dispozici webové rozhraní Outlook on the web (dříve Outlook Web App - OWA), které zobrazíme pomocí webového prohlížeče.

POP a IMAP

Volitelně můžeme využít další klienty pro práci s elektronickou poštou, kteří využívají kombinaci protokolů POP3 nebo IMAP4 a autentizované SMTP. Defaultně jsou protokoly POP a IMAP zablokované. Pro klientské SMTP existuje defaultní Receive Connector.

IIS Virtual Directory

Na Exchange serveru běží ještě několik dalších klientských služeb, které jsou využívány pro doplňkové služby nebo speciální přístup. Služby, které využívají HTTP, nalezneme jako IIS Virtual Directory:

• Outlook Anywhere - složka Rpc
• MAPI over HTTP - složka mapi
• Outlook on the web (OWA) - složka owa
• Exchange ActiveSync (EAS) - složka Microsoft-Server-ActiveSync
• Exchange Web Services (EWS) - složka EWS, webové služby pro programátorský přístup na Exchange (aplikace třetích stran)
• Exchange Control Panel (ECP), nově Exchange Admin Center - složka ecp, webové rozhraní pro správu
• AutoDiscover - složka Autodiscover, automatická konfigurace uživatelského profilu
• Offline Address Book (OAB) - složka OAB, stažení offline adresáře
• PowerShell - složka PowerShell, vzdálený přístup na PowerShell (Exchange Management Shell) skrze HTTPS

Na IIS máme ještě speciální Virtual Directory API a aspnet_client. Protokoly POP3 a IMAP4 zde řešit nebudeme a protokolu SMTP se budeme věnovat v kapitole o Mail Flow. Níže je oficiální obrázek od Microsoftu, který ukazuje schéma služeb.

Konfigurace Client Access

V prvním díle, kdy jsme rozebírali adresy pro služby (Namespace), jsme došli k závěru, že pro všechny služby i servery využijeme stejné doménové jméno (adresu), jedno pro interní a jedno pro externí připojení (případně celkově jedno společné). To je jedna část konfigurace služeb pro klientský přístup - nastavení adres. Druhá část je nastavení požadovaného způsobu autentizace. Jakou použít autentizaci pro různé služby je (podle mne) docela složitá otázka a nikde jsem nenašel, že by byla rozebírána.

Po instalaci Exchange serveru má, na jednotlivých klientských službách, nastaveny interní URL s adresou daného serveru. Takže standardně změníme interní URL a přidáme externí URL. Obecně můžeme pro jednotlivé služby (Virtual Directory) nastavovat interní a externí URL a autentizační metody, další nastavení jsou specifická pro danou službu. Nikde jsem ovšem nenalezl rozumný popis, kdy se použijí externí hodnoty. Klient získá informace ze služby Autodiscover a pak si může zvolit, které údaje chce použít. Ale třeba pro OWA se v testech vždy použije interní autentizace a je jedno odkud se klient přihlašuje.

Na některých místech se uvádí, že použité URL záleží, zda je klientský počítač ve stejné Site jako server (podle IP adresy). Nebo zda je členem stejné AD DS domény/lesa. Třeba v QuickPost: What do Exchange Virtual Directories Do?. V mojí praxi ovšem klienti z jiné Site používají stále interní URL.

Microsoft má popis defaultních hodnot, ale tam neřeší externí vs. interní, ale IIS - Default settings for Exchange virtual directories. Jaké jsou výchozí nastavení autentizačních metod pro jednotlivé služby jsem nikde nenalezl.

Outlook Anywhere

Dokumentaci k Outlook Anywhere jsem nalezl pouze u Exchange 2013.

Konfigurace pomocí Exchange Admin Center se nachází na jiném místě, než všech ostatních služeb. Více vlastností nastavíme pomocí Exchange Management Shell.

• EAC - Exchange Admin Center
• Servers - Servers
• vybereme server a klikneme na tužku - Edit
• položka Outlook Anywhere
• Specify the external host name: mail.firma.cz
• Specify the internal host name: mail.firma.local
• uložíme Save

Pokud provádíme migraci z Exchange 2010, tak aby po dobu koexistence fungovalo proxování spojení z Exchange 2016 Outlook Anywhere na Exchange 2010, musíme změnit autentizační metodu z defaultní Negotiate na NTLM. Po zrušení serverů Exchange 2010 můžeme nastavit opět Negotiate. O tom se píše v Outlook Anywhere coexistence nebo Configure Outlook Anywhere, ale nepíše se, zda jde o externí (default je Negotiate) nebo interní (default je NTLM) autentizaci. V EAC nastavujeme pouze externí autentizaci.

Další možnost je, pokud pro externí připojení využíváme autentizaci na Firewallu, pak musíme nastavit požadovanou autentizaci na Exchange službě. V případě migrace je určitě dobré si uložit aktuální nastavení ze všech serverů. Případně nastavit nové servery stejně. To uděláme nejlépe pomocí Exchange Management Shell - Set-OutlookAnywhere, Get-OutlookAnywhere.

[PS] C:\>Get-OutlookAnywhere | fl servername,external*,internal*,iis*

ServerName                         : MAIL1
ExternalHostname                   : mail.firma.cz
ExternalClientAuthenticationMethod : Negotiate
ExternalClientsRequireSsl          : True
InternalHostname                   : mail.firma.local
InternalClientAuthenticationMethod : Ntlm
InternalClientsRequireSsl          : True
IISAuthenticationMethods           : {Basic, Ntlm, Negotiate}

Ostatní služby - Virtual Directories

Konfigurace ostatních služeb pro přístup klientů se v Exchange Admin Center nachází na stejném místě. Pokud používáme stejné externí doménové jméno pro všechny služby, tak můžeme použít i hromadné nastavení:

• EAC - Exchange Admin Center
• Servers - Virtual directories
• klikneme na ikonu klíče - Configure external access domain
• vybereme Exchange servery, které chceme nastavit, a zadáme doménové jméno
• nastavení se provede tlačítkem Save

Konfiguraci jednotlivých služeb provedeme:

• EAC - Exchange Admin Center
• Servers - Virtual directories
• můžeme vyfiltrovat určitý server nebo službu
• v seznamu vybereme službu a klikneme na ikonu tužky - Edit
• pro většinu služeb můžeme nastavit interní a externí URL a autentizaci

Pro rychlejší nastavení můžeme použít Exchange Management Shell a na internetu nalezneme i různé připravené skripty, například PowerShell Script to Configure Exchange Server Client Access URLs.

MAPI over HTTP

Dokumentace MAPI over HTTP in Exchange Server, Outlook Connectivity with MAPI over HTTP, Set-MapiVirtualDirectory, Get-MapiVirtualDirectory

Zjištění aktuálních nastavení

[PS] C:\>Get-MapiVirtualDirectory | FL Server,external*,internal*,iis*

Server                        : MAIL1
ExternalUrl                   : https://mail.firma.cz/mapi
ExternalAuthenticationMethods : {Basic, Ntlm, Negotiate}
InternalUrl                   : https://mail.firma.local/mapi
InternalAuthenticationMethods : {Basic, Ntlm, Negotiate}
IISAuthenticationMethods      : {Basic, Ntlm, Negotiate}

Kerberos autentizace

Ve chvíli, kdy máme více Exchange serverů a používáme společné doménové jméno pro služby, tedy máme rozvažované (Load Balanced) Mailbox servery, kde běží služba Client Access. A zároveň chceme použít Kerberos pro autentizaci, třeba služeb MAPI over HTTP či Outlook Anywhere. Tak musíme vytvořit speciální účet, který MS označuje Alternate Service Account (ASA), a k němu přiřadit společné jméno (Namespace) pomocí Service Principal Names (SPN). Plyne to logicky z principu Kerberos protokolu, ale v žádném návodu jsem o tom nenašel zmínku. Microsoft toto popisuje v článku Configure Kerberos authentication for load-balanced Client Access services.

Stručný postup za pomocí PowerShellu, většinu věcí bychom mohli nastavit v Active Directory Users and Computers (ADUC).

Vytvoříme počítačový účet, kterému později přiřadíme SPN.

New-ADComputer -Name EXCH2016ASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'mail.firma.local
 Kerberos Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2016ASA
Set-ADComputer EXCH2016ASA -add @{"msDS-SupportedEncryptionTypes"="28"}

Nastavíme ASA Credential na první Exchange server, pomocí existujícího skriptu.

Pozn.: Důležitá věc je spustit skript pod účtem, který má oprávnění na Exchange i změny v doméně. MS zdůrazňuje, že je třeba, aby skript změnil heslo na použitém účtu. K tomu ale potřebuje práva.

[PS] C:\>cd $ExScripts
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\RollAlternateServiceAccountPassword.ps1
 -ToSpecificServer mail1.firma.local -GenerateNewPasswordFor firma\EXCH2016ASA$

========== Starting at 03/22/2019 09:29:05 ==========
Destination servers that will be updated:

Name      PSComputerName
----      --------------
MAIL1 mail1.firma.local

Credentials that will be pushed to every server in the specified scope (recent first):

UserName                            Password
--------                            --------
firma\EXCH2016ASA$ System.Security.SecureString

Prior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the
 destination servers.
Pushing credentials to server MAIL1
Setting a new password on Alternate Serice Account in Active Directory

Password change
Do you want to change password for firma\EXCH2016ASA$ in Active Directory at this time?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): y
Preparing to update Active Directory with a new password for firma\EXCH2016ASA$ ...
Resetting a password in the Active Directory for firma\EXCH2016ASA$ ...
New password was successfully set to Active Directory.
Retrieving the current Alternate Service Account configuration from servers in scope
Alternate Service Account properties:

StructuralObjectClass QualifiedUserName  Last Pwd Update    SPNs
--------------------- -----------------  ---------------    ----
computer              firma\EXCH2016ASA$ 22.03.2019  9:17:20

Per-server Alternate Service Account configuration as of the time of script completion:

   Array: {mail.firma.local, mail.firma.cz}

Identity  AlternateServiceAccountConfiguration
--------   ------------------------------------
MAIL1 Latest: 22.03.2019 9:29:23, firma\EXCH2016ASA$
Previous: <Not set>

========== Finished at 03/22/2019 09:32:28 ==========

        THE SCRIPT HAS SUCCEEDED

Nastavíme ASA Credential na další Exchange servery, skript nyní kopíruje nastavení.

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer mail2.firma.local -CopyFrom mail1.firma.local

Kontrola, že proběhlo nastavení

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | FL Name, AlternateServiceAccountConfiguration

Určíme a nastavíme SPN na účet. Rozhodneme se, zda chceme použít pouze na interní URL nebo i externí (pokud to má smysl) a případně Autodiscover.

HTTP/mail.firma.local
HTTP/mail.firma.cz
HTTP/autodiscover.firma.cz

Nejprve je dobré zkontrolovat, že toto SPN již nemáme někde nastavené.

setspn -F -Q http/mail.firma.local

Vlastní nastavení SPN na speciální účet počítače.

setspn -S HTTP/mail.firma.local firma\EXCH2016ASA$
setspn -S HTTP/mail.firma.cz firma\EXCH2016ASA$
setspn -S HTTP/autodiscover.firma.cz firma\EXCH2016ASA$

Pro kontrolu si můžeme vypsat SPN na účtu.

setspn -L firma\EXCH2016ASA$

Případné odstranění pověření.

Set-ClientAccessServer mail2 -RemoveAlternateServiceAccountCredentials

Outlook on the web (OWA)

Dokumentace Outlook on the web in Exchange Server, Set-OwaVirtualDirectory, Get-OwaVirtualDirectory  

Zjištění aktuálních nastavení

[PS] C:\>Get-OwaVirtualDirectory -Server mail1 | FL ServerName,externalurl,internalurl,*auth*,LogonFormat

ServerName                    : MAIL1
ExternalUrl                   : https://mail.firma.cz/owa
InternalUrl                   : https://mail.firma.local/owa
ClientAuthCleanupLevel        : High
InternalAuthenticationMethods : {Basic, Fba}
BasicAuthentication           : True
WindowsAuthentication         : False
DigestAuthentication          : False
FormsAuthentication           : True
LiveIdAuthentication          : False
AdfsAuthentication            : False
OAuthAuthentication           : False
ExternalAuthenticationMethods : {Fba}
LogonFormat                   : FullDomain

V nastavení autentizace OWA máme k dispozici také speciální metodu Forms-based Authentication (FBA), tedy webový formulář, kam zadáme přihlašovací jméno (definujeme jeho formát) a heslo.

U nastavení v EAC se nemluví o tom, zda jde o interní nebo externí autentizační metodu. Po nastavení se změní hodnota atributu InternalAuthenticationMethods. Přišlo by mi logické, že si mohu pro interní klienty nastavit Kerberos (IWA) a pro externí formulář. Ale to v praxi nefunguje. Ať v prohlížeči použiji interní nebo externí URL, připojuji se z úplně jiné sítě, počítač není v doméně, tak stejně se vždy použije interní autentizační metoda.

Po změně autentizační metody se zobrazí, že je třeba provést restart IIS. Některé změny se projeví hned bez restartu, ale pro ty zásadnější je restart třeba. Můžeme využít příkaz iisreset nebo kombinaci (která restartuje pouze web služby)

net stop was /y
net start w3svc

Také se zobrazuje informace, že pro OWA a ECP máme používat stejnou autentizační metodu.

Exchange ActiveSync

Dokumentace Exchange ActiveSync, Set-ActiveSyncVirtualDirectory, Get-ActiveSyncVirtualDirectory  

Zjištění aktuálních nastavení

[PS] C:\>Get-ActiveSyncVirtualDirectory | FL Server,external*,internal*

Server                        : MAIL1
ExternalUrl                   : https://mail.firma.cz/Microsoft-Server-ActiveSync
ExternalAuthenticationMethods : {}
InternalUrl                   : https://mail.firma.local/Microsoft-Server-ActiveSync
InternalAuthenticationMethods : {}

Nastavení adres pro klientské služby

Pro nastavení interních i externích doménových jmen můžeme použít Exchange Management Shell a skupinu příkazů. Nastavíme jméno Exchange serveru (postupně můžeme zavolat pro další) a adresy zevnitř a zvenku.

$s = "mail1"
$urlI = "mail.firma.local"
$urlE = "mail.firma.local"

Get-OutlookAnywhere -Server $s | Set-OutlookAnywhere -InternalHostname $urlI -ExternalHostname $urlE

Get-MapiVirtualDirectory -Server $s | Set-MapiVirtualDirectory -InternalUrl https://$urlI/mapi -ExternalUrl https://$urlE/mapi
Get-OwaVirtualDirectory -Server $s | Set-OwaVirtualDirectory -InternalUrl https://$urlI/owa -ExternalUrl https://$urlE/owa
Get-ActiveSyncVirtualDirectory -Server $s | Set-ActiveSyncVirtualDirectory -InternalUrl https://$urlI/Microsoft-Server-ActiveSync -ExternalUrl https://$urlE/Microsoft-Server-ActiveSync

Get-EcpVirtualDirectory -Server $s | Set-EcpVirtualDirectory -InternalUrl https://$urlI/ecp -ExternalUrl https://$urlE/ecp
Get-WebServicesVirtualDirectory -Server $s | Set-WebServicesVirtualDirectory -InternalUrl https://$urlI/EWS/Exchange.asmx -ExternalUrl https://$urlE/EWS/Exchange.asmx
Get-OabVirtualDirectory -Server $s | Set-OabVirtualDirectory -InternalUrl https://$urlI/OAB -ExternalUrl https://$urlE/OAB
Get-PowerShellVirtualDirectory -Server $s | Set-PowerShellVirtualDirectory -InternalUrl https://$urlI/powershell -ExternalUrl https://$urlE/powershell

Služba Autodiscover

Dokumentace Autodiscover service in Exchange Server, Autodiscover for Exchange, Mastering Autodiscover

Autodiscover je důležitá služba, která poskytuje informace pro konfiguraci připojení klienta k poštovní schránce pomocí různých protokolů. Jedná se o XML dokument s řadou údajů. Ten sestavuje Exchange server, ke kterému se připojím, podle nastavení pro jednotlivé klientské služby daného uživatele. Adresa Autodiscover služby se zjišťuje na několika místech.

Pro Autodiscover se používá také Virtual Directory a můžeme si zobrazit nastavení. Zde nejsou URL, ta se nastavují na jiném místě.

[PS] C:\>Get-AutodiscoverVirtualDirectory | FL Server,*AuthenticationMethods

Server                        : MAIL1
InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}
ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity, OAuth}

[PS] C:\>Get-ClientAccessService | FL Name,AutoDiscoverServiceInternalUri,AutoDiscoverSiteScope

Name                           : MAIL1
AutoDiscoverServiceInternalUri : https://mail.firma.local/Autodiscover/Autodiscover.xml
AutoDiscoverSiteScope          : {Praha}

Service Connection Point (SCP) v AD DS

Pro klienty, kteří jsou členy domény, se nejprve hledá SCP záznam v AD DS. Využívají se Site. Zobrazení aktuálních údajů můžeme skriptem Retrieving Exchange Autodiscover SCP information from AD via PowerShell nebo využijeme třeba nástroj Active Directory Sites and Services a doklikáme se na Services - Microsoft Exchange - Firma - Administrative Groups - Exchange Administrative Group (FYDIBOHF23SPDLT) - Servers - MAIL1 - Protocols - Autodiscover - vlastnosti objektu MAIL1

• atribut serviceBindingInformation - obsahuje Autodiscover adresu
• atribut keywords - obsahuje GUID, podle kterého se tento objekt hledá, seznam Site, pro které se použije

Aktualizaci SCP objektu provedeme nastavením URL na CAS. Site nemusíme nastavovat.

Set-ClientAccessService mail1 -AutoDiscoverServiceInternalUri https://mail.firma.local/Autodiscover/Autodiscover.xml
Set-ClientAccessService mail1 -AutoDiscoverSiteScope Praha

Standardní URL

Další krok se hledají předefinované URL, které jsou založeny na doméně ze SMTP adresy

• https://<SMTP-address-domain>/autodiscover/autodiscover.xml
• https://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml

SRV záznam

V poslední fázi, pokud se nepovedly předchozí kroky, se nejprve zkusí neautentizovaný (nešifrovaný) dotaz na http://autodiscover.<smtp-address-domain>/autodiscover/autodiscover.xml.

Pak se hledá SRV záznam v DNS _autodiscover._tcp.<smtp-address-domain>. Při využití této varianty můžeme z internetu použít stejné URL pro ostatní služby i Autodiscover. A tedy mít certifikát pouze s jedním jménem.

Autodiscover při migraci

Pokud provádíme migraci z Exchange 2010 na 2016, tak je, před přesunem prvních schránek, dobré přesměrovat Autodiscover službu na nové Exchange servery. Protože pokud má klient schránku (mailbox) na serveru Exchange 2016 a připojí se pro získání Autodiscover informací na Exchange 2010, tak nedostane informace, ale pokyn přesměrování (redirect) na Exchange 2016 server. A to může někdy zlobit. Kdežto při připojení na Exchange 2016 je jedno, zda má klient schránku na 2010 nebo 2016, ale vždy dostane konfigurační soubor s údaji podle serveru, kde má schránku.

Než jsem provedl tuto změnu, tak se projevoval opakovaně problém. V řadě případů proběhlo přesměrování (Status 302) na Exchange 2016 a korektně se stáhnul Autodiscover (Status 200). Ale jednou za čas vrátil Exchange 2016 místo kódu 200 opět 302, nic se nestáhlo a Outlook zkoušel další možnosti pro nalezení Autodiscover.

Pokud chceme nastavit SCP adresu na Exchange 2010, tak to musíme provádět na něm příkazem

Set-ClientAccessServer MAILOLD -AutoDiscoverServiceInternalUri https://mail.firma.local/Autodiscover/Autodiscover.xml

Testy a ladění Autodiscover

Přímo z MS Outlook můžeme otestovat fungování Autodiscover a zobrazit si průběh nalezení informací.

• spustíme Outlook
• klikneme Ctrl + pravé tlačítko myši na ikonu Outlook v oznamovací oblasti (vedle hodin)

• máme zde volbu Connection Status, která ukáže mnoho informací o aktuálním připojení (můžeme vidět připojení na Exchange 2010 protokol RPC/TCP a na Exchange 2016 HTTP) Na Exchange 2010 jsme zde viděli pár spojení na různé služby. U Exchange 2016 zde patrně uvidíme mnoho spojení a často pro jiné emailové adresy, to je připojování ke sdíleným kalendářům

• druhá volba je Test E-mail AutoConfiguration, kde můžeme otestovat službu Autodiscover, log nám ukáže průběh nalezení URL a stažení XML, mezi výsledky je obsah konfiguračních dat

V Outlooku můžeme zapnout Debug, kde se dozvíme ještě více informací. Popis How to enable global and advanced logging for Microsoft Outlook

V registrech HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Mail vytvoříme DWORD položku EnableLogging s hodnotou 1. Zapneme Outlook. Ve složce %temp% se vytvoří řada logů. Outlook 2010 má krásný log Autodiscoveru v souboru olkdisc.log, ale Outlook 2016 asi nic takového nemá.

Problémy připojení klientů Outlook

U některých klientů se po přechodu na Exchange 2016 projevovaly různé problémy. Na internetu jsou často probírané a většinou je uvedené různé vyřešení. Obecně se mi podařilo problémy vyřešit, i když třeba občasný problém s připojením Outlooku se stále minimálně objevuje. Hlavní problémy u uživatelů:

• Public Folders - pomalé zobrazení položek ve veřejných složkách (čím větší velikost, tím pomalejší zobrazení)
• Public Folders - když si nějaké veřejné složky přidáme mezi oblíbené (Favorites), tak občas všechny zmizí a musíme je přidat znovu
• Outlook je občas Disconected, žádná operace nic nezmění (ani restart stanice), asi po 10 minutách se sám připojí

Maximum Allowed Sessions Per User

Když jsem pátral po problémech, tak jsem v  Application logu Exchange serveru narazil na pravidelně logovanou událost s Event ID 9646.

Mapi session /o=Firma/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user81faa068 with client type MoMT
 exceeded the maximum of 32 objects of type Session.

V logu nevidíme, o jakého uživatele se jedná, což můžeme zjistit příkazem:

[PS] C:\>Get-Mailbox "/o=Firma/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=user81faa068"

Name                Alias        ServerName  ProhibitSendQuota
----                -----        ----------  -----------------
Bouška Petr         bouska       mail2       Unlimited

Pokud chceme obecně limit na počet spojení zvednout, tak to můžeme provést v registrech HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem, kde vytvoříme hodnotu (DWORD 32) Maximum Allowed Sessions Per User a nastavíme třeba 500. Následně je třeba restart Microsoft Exchange Information Store service.

Tuto chybu lidé často řeší v souvislosti s veřejnými složkami, třeba Exchange 2016- EVENT ID 9646 - MoMT exceeded the maximum of 32 objects of type Session, Exchange16/ Outlook16 - client type MoMT exceeded the maximum of 32 objects of type Session.

Někde se uvádí, že problém s množstvím spojení (session) se objevuje, pokud máme Exchange Cached Mode. Nyní když se otevírají sdílené kalendáře, tak se vytváří spojení pro každý kalendář, který máme uložený. Doporučuje se vypnout Download shared folders (v nastavení účtu, záložka Advanced). Ale session pro kalendáře se vytváří stejně, takže to asi nemá vliv.

Na některých místech (Exchange 2016 MapiExceptionSessionLimit, Exchange 2016 Defaults) se mluví o zvýšení ještě dvou limitů pod klíčem MaxObjsPerMapiSession hodnoty objtFolder a objtFolderView.

Ale je otázka, jestli některé nastavení výše, mají vliv na popsané problémy. Problémy s Public Folders jsou vyřešeny v další kapitole. Připojení klientů pomohla úprava autentizačních metod a nastavení DNS překladu v interní síti, aby se veřejného jména Exchange překládala na interní adresy.

Public Folders - pomalé zobrazení každé zprávy

Pro vyřešení různých problémů s Outlookem se doporučuje jeho přepnutí do Online Exchange mode. Obecně se vedou různé diskuze, zda je lepší provozovat Cached vs. Online Exchange mode. Defaultně se použije Cached Exchange Mode (ale pouze s roční historií) a asi bude výhodnější. V Online módu se musí ze serveru stáhnout každá zpráva při každém přístupu.

Řešil jsem problém velmi pomalého zobrazování položek ve veřejných složkách, vlastní schránka fungovala dobře. Ale když jsem přepnul účet do Online módu, tak se stejným způsobem zpomalilo zobrazení položek ve schránce. Přístup přes webové rozhraní OWA fungoval bez problémů.

Při hledání člověk najde často odkazovaný článek Outlook in Online mode is slow connecting to Exchange 2013, kde se řeší úprava TCP potvrzování, což je dost drastická záležitost a ani jsem ji nezkoušel. Různé další zmínky vedou také na problémy v síti a třeba chybu ve VMware Tools Outlook Slow in Online Mode.

Já jsem zkusil jednodušší věc, spustit Outlook bez pluginů

Outlook /safe

A hopla, vše fungovalo bez problémů. Po pár pokusech s vypínáním pluginů se ukázalo, že problém je v Kaspersky Outlook Anti-Virus Addin. Pak jsem našel i článek a diskusi Exchange 2016 - Poor Outlook 2016 Performance - Troubleshooting, KES 11 - Slow outlook app after installing KES 11, kde je i rada na úpravu nastavení KES, aby se plugin nemusel vypnout.