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.
Zdravím, díky za super článek! Jen dotaz zkoušel jste se připojit k Exchange 2016 účtu Outlookem 2016 např. mimo firmu pomocí Exchange ActiveSync? Díky za info :)
odpověď na [1]Solar: Nevím o tom, že by v Outlooku šel použít protokol Exchange ActiveSync. Ale z mobilních zařízení funguje a Outlook 2016 z internetu funguje také.
Uzasna série článků!
mám dotaz. neřešili jste při použití protokolu Mapi over HTTP vyskakujici přihlášovaci dialog u Outlooku,kdyz jsou mimo interní síť (nevidí na domácím controller)?
Zdravim Mistre.
Velice cenny zdroj informaci, obzvlaste v situaci, kdy je treba premigrovat jen 1 server v male a jednoduche domene, v jedne lokalite bez site. Neni nutne studovat x hodin dokumentaci a best to do scenare.
Jen bych se rad zeptal, v sekci o redirectu Autodiscover sluzby uvadite, ze na puvodnim serveru je treba provezt toto:
Set-ClientAccessServer MAILOLD -AutoDiscoverServiceInternalUri https://mail.firma.local/Autodiscover/Autodiscover.xml
Kde je ale urceno, ze se tim ma zabyvat novy server?
Predem dekuji.
odpověď na [4]Tom: Nevím, jestli úplně chápu otázku . AutoDiscover obsluhují všechny servery. Při migraci potřebujeme, aby klienti našli nějaký nový server (ten může odpovědět pro schránky na nových i starých serverech). Tímto příkazem se upraví SCP v doméně pro starý server.
Dekuji za odpoved, zrejme jsem to spatne pochopil, takze otazka nedava moc smysl.
Jde mi o to, ze pokud pobezi soubezne stary exchange a zaroven novy a nektere schranky budou jiz premigrovane, tak pokud se klient pripoji na stary exchange, tak ten ho nebude umet proxovat na ten novy, kde uz ma fyzicky schranku. Obracene to funguje. Takze mi jen slo to, jak zajistit, aby se klient vzdy dohrabal jen na ten novy exchange, ktery ho bud obslouzi primo, nebo nasmeruje na ten stary.
Dekuji.
odpověď na [6]Tom: Mělo by to nějak chodit v obou případech. Ale mě lépe fungovalo, když se klienti obrátili vždy na Exchange 2016. To zajistíme tím, když všechny metody, jak se Outlook ptá na AutoDiscover budou vést na nový server. Tedy upravíme DNS záznamy a pokud je klient v doméně, tak právě ten SCP (tím příkazem výše, kde zadáme URL na nový server).
Zdravím.
Mám dotaz ohledně logování Exchange. V jakém logu se dají najít záznamy o přihlášení uživatelů ke schránce?
Za odpověď předem děkuji
odpověď na [8]Jirka: Celkově je to s logy o přístupu uživatelů dost špatné.
Přihlašování uživatelů probíhá na doménovém řadiči, takže logy musíme hledat tam. Zdrojem je právě Exchange server.
Ale co se mi nikdy nepovedlo vyřešit. Mám podezřelé pokusy o přihlášení a potřeboval bych nalézt z jaké IP adresy pochází. Na DC je IP adresa Exchange serveru. A na Exchangi jsem nenašel žádný log, který by mi pomohl (v Access logu není nic).
Ano, tohle je další problém. Pokud se přihlašují v prohlížeči, je log o přihlášení/odhlášení v logách IIS. Pokud v outlooku, tak jedině sbírat logy ze stanic.