Exchange Hybrid Configuration Wizard

Úvod

V základu je konfigurace Exchange Hybrid docela jednoduchá, protože použijeme průvodce, který podle zadaných parametrů vše nastaví v On-Premises i v cloudu. Dopředu musíme splnit určité předpoklady. Musíme také naplánovat, jak budeme poštu provozovat a případně provést určité úpravy. Před začátkem je důležité (skoro nutné) se seznámit s fungováním Exchange Hybrid - tok pošty, konektory, domény. Doporučuji se seznámit i s informacemi v následujícím článku Exchange Hybrid - schránky a jejich umístění, příjemci, atributy a opravy chyb.

Zde budeme také řešit specifickou situaci, kdy v Azure AD máme uživatele, kteří již mají přiřazenu licenci na Exchange Online. V diskusích jsem dodatečně nalezl, že pokud ještě nemáme zprovozněn Exchange Hybrid, a nechceme využívat schránku v cloudu, tak bychom uživatelům neměli přiřazovat licenci (patrně je myšleno z licence Office 365/Microsoft 365 nepřidělovat službu Exchange Online). Ve chvíli, kdy se licence přidělí, tak se vytvoří schránka v cloudu (pokud není konfigurován Exchange Hybrid a správně synchronizovány údaje).

Vše jsem nejprve zkoušel v labu, kde se prostředí, se základním nastavením, průběžně budovalo. Přitom jsem narazil na různé problémy, které zmíním. V provozním prostředí se většina neprojevila.

Vycházíme ze stavu, že je lokálně instalovaný Exchange Server 2016 (CU18) nebo Exchange Server 2019 (CU7) s nejnovějším Cumulative Updates (CU). A korektně nám funguje Azure AD Connect i s volbami pro Hybrid Exchange.

Dokumentace

• Exchange Server hybrid deployments
• Create a hybrid deployment with the Hybrid Configuration wizard
• Hybrid Configuration wizard
• Hybrid deployment prerequisites
• Exchange/Office 365 Hybrid Configuration Wizard - step by step guide
• How to Migrate Exchange to Office 365: Step by Step - Part 1
• Office 365 Hybrid Configuration Wizard Step by Step

Hybrid Configuration Wizard (HCW)

Průvodce Microsoft Office 365 Hybrid Configuration Wizard můžeme spustit z různých míst. Doporučuje se kontrolovat, že jde o poslední verzi (momentálně 17.0.4544.0, v průběhu testů se objevila verze 17.0.5378.0). Ta by měla být dostupná na adrese https://aka.ms/HybridWizard. Jinak se dá spustit přímo z Exchange Admin Center (EAC) - Hybrid - tlačítko Configure. To je dostupné v On-Premises EAC i cloud EAC (zde by měla být vždy dostupná poslední verze).

Poprvé dojde k instalaci a příště je možno spustit ze Startu. Průvodce se dá spouštět opakovaně, když chceme provést změny nebo když vyjde nová verze. Například při přechodu z 16.x na 17.x je potřeba odinstalovat původní verzi a nainstalovat novou. Stará verze zobrazuje varování Hybrid Configuration Service may be limited.

Spuštění průvodce a problémy

Při prvním spuštění se provádí instalace aplikace, následně se již spouští nainstalovaná, ale asi vždy přistupuje na internet. Volá (stahuje) se od Microsoftu soubor Microsoft.Online.CSE.Hybrid.Client.application. Když dojde k nějakým problémům (průvodce se nespustí), tak se můžeme podívat do logu %appdata%\Microsoft\Exchange Hybrid Configuration. V tomto logu najdeme také detailní informace o průběhu konfigurace Exchange Hybrid. Hodí se po dokončení průvodce zkontrolovat a třeba zazálohovat. I v budoucnu zde nalezneme zajímavé informace, co vše a jak se nastavilo v interním prostředí i v cloudu.

Pokud se nedaří průvodce spustit, tak může být řešení přidat adresy https://outlook.office365.com a https://aka.ms, případně ještě https://shcwreleaseprod.blob.core.windows.net, mezi Trusted sites v IE. Také jsem se opakovaně setkával s problémem s novým spuštěním průvodce. Při spuštění z webu nebo startu jen něco probliklo a nic nenastartovalo. Dočasně se vyřešilo kliknutím pravým tlačítkem na stažený soubor Microsoft.Online.CSE.Hybrid.Client.application, volba Open with a ClickOnce Application Deployment Support Library. To sice vrátilo chybu, že je aplikace instalovaná z jiné lokality. Ale nyní již šla spustit ze startu nebo EAC.

Informace o Exchange organizacích

Průvodce detekuje optimální On-Premises Exchange server (Client Access Server dostupný z internetu) a hostování Exchange Online, nebo můžeme vybrat ručně. Provedou se kontroly serveru (například musí být zalicencovaný). Použije se (nastavujeme) přihlášení On-Premises Exchange Account (Exchange Administrator) a Office 365 Exchange Online Account (Tenant Administrator). Stáhne se konfigurace z On-Premises i Online.

Hybridní konfigurace

Hybrid Configuration Wizard options

Následně vybíráme několik zásadních voleb, podle kterých se provede nastavení.

Hybrid Features

• Minimal Hybrid Configuration - pouze základní vlastnosti
• Full Hybrid Configuration - plné vlastnosti

Hybrid Topology

• Exchange Classic Hybrid Topology - klasická topologie, vyžaduje důvěryhodný certifikát, plné komunikace z a do internetu
• Exchange Modern Hybrid Topology - využívá Microsoft Hybrid Agent

Volby pro integraci Teams

Pokud chceme využívat MS Teams integrovaný s On-Premises Exchange, tak musíme použít Exchange full Classic Hybrid deployment (Full Hybrid Configuration, Exchange Classic Hybrid Topology). Popsáno v How Exchange and Microsoft Teams interact.

EWS (Exchange Web Services)

V dalších krocích volíme Web Services Virtual Directory (EWS) dostupné z internetu (musí mít nastavené externí URL). V nastavení EWS se doporučuje (pro určité operace je povinné) zapnout MRS Proxy. Měl by to zapínat i průvodce, ale různě se uvádí, že je lepší předem nastavit.

Přenos a směrování pošty

Secure Mail Transport

Nastavuje se TLS šifrovaný a ověřený přenos zpráv mezi On-Premises and Online Exchange organizací. Volíme, jak chceme nastavit přenos pošty (standardně Client Access and Mailbox servers). Jaký se použije certifikát, na kterých serverech se má vytvořit Receive a Send Connector.

Centralized Mail Transport

Můžeme zapnout, pokud chceme, aby emaily do internetu, ze schránek v Exchange Online organizaci, odcházely z On-Premises serverů. Standardně jsou doručovány napřímo z online prostředí.

Organization FQDN

Zadáme veřejné doménové jméno, které používá On-Premises Exchange. Použije se pro konektory pro bezpečný přenos zpráv. Často se používá mail.firma.cz. Adresa se použije v Outbound konektoru v Exchange Online jako Smart Host pro naše domény (můžeme dodatečně změnit).

Dokončení a informace o konfiguraci

Průvodce nám, po provedení změn konfigurace, zobrazí informaci, zda vše proběhlo korektně, objevila se malá chyba, či nebylo možno nastavení provést.

Pro kontrolu můžeme také použít příkaz v Exchange Management Shell na On-Premises organizaci, který zobrazí údaje o hybridní konfiguraci (před hybridním nastavením nevrací žádné údaje). Ukázka části výstupu.

[PS] C:\>Get-HybridConfiguration

RunspaceId                : 0751c621-c940-4eae-88a1-b8c37a0c50e3
ClientAccessServers       : {}
EdgeTransportServers      : {}
ReceivingTransportServers : {AZURETEST}
SendingTransportServers   : {AZURETEST}
OnPremisesSmartHost       : mailtest.firma.cz
Domains                   : {firma.cz}
Features                  : {FreeBusy, MoveMailbox, Mailtips, MessageTracking, OwaRedirection, OnlineArchive, SecureMail,
                            Photos}
ExternalIPAddresses       : {}
TlsCertificateName        : <I>CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US<S>CN= mailtest.firma.cz
ServiceInstance           : 0
AdminDisplayName          :
ExchangeVersion           : 0.20 (15.0.0.0)
Name                      : Hybrid Configuration

Změny provedené průvodcem

Také se můžeme podívat (a zkontrolovat) na některé viditelné změny, které provedl průvodce (můžeme si uložit podrobné výstupy před spuštěním průvodce a poté porovnat). Bodově jde o následující:

• nastavila se nová akceptovaná doména firma.mail.onmicrosoft.com, Get-AcceptedDomain
• upravila se Email Address Policies, Get-EmailAddressPolicy
• vytvořily se nové Remote Domain, Get-RemoteDomain
• nastavil se vztah organizací, Get-OrganizationRelationship, Get-IntraOrganizationConnector
• vytvořil se nový Inbound a Outbound Connector v Exchange Online, Get-OutboundConnector, Get-InboundConnector
• vytvořil se nový Send Connector v On-Premises Exchange, Get-SendConnector
• upravil se Default Frontend Receive Connector v On-Premises Exchange, Get-ReceiveConnector
• buď se nastavila se federace Get-FederationTrust, vznikl nový certifikát Exchange Delegation Federation, Get-ExchangeCertificate, nebo (v nové verzi HCW primárně) se nastavil OAuth authentication relationship (Exchange federated sharing) Get-AuthServer

Default Frontend Receive Connector

Průvodce provede několik úprav Default Frontend Receive Connector. V oficiální dokumentaci jsem o tom nenašel žádné informace, ale změny jsou dost zásadní, takže nám může přestat fungovat třeba odesílání pošty z aplikačních serverů. Jaké změny průvodce provedl se dozvíme v logu Hybrid Configuration Wizard %appdata%\Microsoft\Exchange Hybrid Configuration\<datum>.log. Je zde i tabulka Receive Connector s aktuálním a očekáváným stavem.

Jedna změna je, že se z konektoru odstraní oprávnění pro skupinu Exchange Users, pokud jsme ji měli nastavenu (popisoval jsem v Exchange Server 2016 Mail Flow - směrování pošty a konektory). Skupinu můžeme jednoduše vrátit pomocí Exchange Admin Center (EAC). Nebo vytvořit speciální konektor pro aplikační servery, ty bychom ale museli vyjmenovat (nebo použít jiný port).

Problém se v praxi projeví následně. Pokud se z aplikačního serveru přihlašuje uživatel, který chce odeslat poštu, tak dostane chybu autentizace.

535 5.7.3 Authentication unsuccessful

V FrontEnd SmtpReceive logu na Exchange serveru nalezneme chybu.

Inbound authentication failed because the client FIRMA\jmeno doesn't have submit permission.

Při výpisu oprávnění na konektoru vidíme následující.

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

User                              ExtendedRights
----                              --------------
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Authoritative-Domain-Sender}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Any-Sender}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Submit}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-Accept-Headers-Routing}

Po vrácení Exchange users je původní stav.

User                              ExtendedRights                                   
----                              --------------                                   
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Authoritative-Domain-Sender}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Accept-Any-Sender}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-SMTP-Submit}
NT AUTHORITY\ANONYMOUS LOGON      {ms-Exch-Accept-Headers-Routing}
NT AUTHORITY\Authenticated Users  {ms-Exch-Bypass-Anti-Spam}
NT AUTHORITY\Authenticated Users  {ms-Exch-Accept-Headers-Routing}
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Submit}
NT AUTHORITY\Authenticated Users  {ms-Exch-SMTP-Accept-Any-Recipient}

Druhá změna je, že se na konektor nastaví certifikát, který jsme vybrali v průvodci. Pokud se Exchange Online (pomocí Outbound konektoru) připojuje na tento konektor, tak vyžaduje tento certifikát (provádí se ověření), takže bychom jej zde měli nechat. Pokud bychom chtěli nastavení z nějakého důvodu zrušit, tak pomůže následující příkaz.

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

Problémy po dokončení průvodce

Nefunkční EAC odkaz Office 365

Po dokončení Hybrid Configuration Wizard se při přihlášení do Exchange Admin Center (EAC) nahoře nachází dvě záložky Enterprise a Office 365. Ta druhá má (po přihlášení) vést do nastavení Exchange Online.  Místo toho může otevírat porovnání tarifů https://go.microsoft.com/fwlink/p/?LinkId=258351 (stav před použitím HCW). Microsoft má, pro praxi docela nesmyslný, článek Office 365 link in On-Premises EAC goes to product comparison, not Exchange admin center.

Na testu mi vše fungovalo, ale v produkci ne. Našel jsem radu provést restart IIS na Exchange serveru. Když jsem pak na tomto serveru otevřel stránku EAC, tak opravdu odkaz fungoval. Zvláštní ale je, že při volání z jiného počítače nefungoval. Znovu jsem zkusil po řadě dní (nevím, jestli mezi tím nedošlo k restartu serveru) a již fungovalo i ze sítě.

Kontrola federace a organizačního sdílení

O365 Hybrid - Exchange Federation Trust,  How to address Federation Trust issues in Hybrid Configuration Wizard (HCW)

Ve starších článcích se uvádělo, například při problémech s přístupem Teams do On-Premises kalendáře, že je potřeba kontrolovat funkčnost federace. Nakonec jsem se dočetl, že nová verze HCW 17.0 ve většině případů federaci nenastavuje (použije se pro nějaké staré verze Exchange), ale místo toho se používá OAuth, který je zásadní pro Teams. V oficiální dokumentaci Hybrid configuration options je zmínka:

The wizard checks to see if there is an existing OAuth authentication relationship or a federation trust with the Azure Active Directory authentication system for the on-premises organization. If not present, the wizard configures OAuth authentication or creates a federation trust for the on-premises organization with the Azure AD authentication system, depending on the type of on-premises Exchange configuration.

V každém případě se nastavuje organizační sdílení (Organizational Relationships/Sharing) pro obě organizace. To je důležité pro řadu funkcí, jako je sdílení Free/Busy, přesměrování Outlook on the web či MailTips.

Můžeme podívat v Exchange Admin Center (EAC) - Organization - Sharing. Pokud se podíváme v Exchange Online, tak zde uvidíme informace o nastaveném Organizational Sharing s naší interní organizací. Když se podíváme na On-Premises serveru, tak asi uvidíme následující.

Pokud bychom kliknuli na Enable, tak se zobrazí informace o Organizational Sharing.

Na vše se můžeme jednoduše podívat v PowerShellu a zkontrolovat, že je nastaveno.

[PS on-premises] C:\>Get-FederationTrust | select TokenIssuerUri | ft -AutoSize

TokenIssuerUri
--------------
urn:federation:MicrosoftOnline

[PS Online] C:\> Get-FederationTrust | select TokenIssuerUri | ft -AutoSize

TokenIssuerUri
--------------
uri:WindowsLiveID
urn:federation:MicrosoftOnline

[PS on-premises] C:\>Get-OrganizationRelationship | select Domainnames

DomainNames
-----------
{firma.mail.onmicrosoft.com}

[PS Online] C:\> Get-OrganizationRelationship | select Domainnames

DomainNames
-----------
{firma.cz}

Autentizace OAuth

Configure OAuth authentication between Exchange and Exchange Online organizations

Pro některé funkce je nutné, aby bylo nastavené a funkční ověřování pomocí OAuth. Vše by měl nastavit Hybrid Configuration Wizard (HCW). V testu jsem narazil na problém s Exchange Server 2019 CU 6 a poslední verzi HCW 17.0.5378.0. Průvodce na konci zobrazil varování

HCW8064 The HCW has completed, but was not able to perform the OAuth portion of your Hybrid configuration. If you need
 features that rely on OAuth, you can try running the HCW again or manually configure OAuth using these manual steps.

V logu %appdata%\Microsoft\Exchange Hybrid Configuration\<datum>.log se nacházela chyba

*ERROR* 10242 [Client=UX, Page=Configuring, fn=RunWorkflow, Workflow=Hybrid, Task=IntraOrganization, Phase=Configure, Thread
=20] 
Microsoft.Online.CSE.Hybrid.PowerShell.PowerShellInvokeException: PowerShell failed to invoke 'Set-AuthServer': A parameter
 cannot be found that matches parameter name 'DomainName'. ---> System.Management.Automation.RemoteException: A parameter
 cannot be found that matches parameter name 'DomainName'.

O tom je zmínka v článku Can't view Online user free/busy status in Exchange Server 2019 and 2016. Je potřeba nainstalovat poslední verzi Cumulative Update, která obsahuje nový parametr DomainName.

Problémy s přístupem Teams do On-Premises Exchange kalendáře

How Exchange and Microsoft Teams interact

Pro někoho může být hlavní motivací konfigurace Exchange Hybrid, aby mohl MS Teams přistupovat do kalendáře uživatelů, které jsou na interních Exchange serverech. Může se tu objevit řada problémů.

Hodně informací je v českém článku Exchange Hybrid a Microsoft Teams, další zajímavý je třeba Configuring Teams calendar access for Exchange on-premises mailboxes.

Z aplikace Teams můžeme uložit logy pomocí kombinace kláves CTRL+ALT+SHIFT+1 a prohlédnout soubor MSTeams Diagnostics Log mm_dd_yyyy__hh_mm_ss_XXXX.txt. Pokud nalezneme následující řádek, tak se nepovedlo přistoupit ke schránce.

UserAppsStore: Skipped calendar app with isFirstParty as true. isMailboxDiscoverable: false, isFreemiumTenant: false,
 enableFreemiumCalendar: true

Autodiscover test

Je mnoho věcí, které bychom měli zkontrolovat. Můžeme zkusit Autodiscover přístup k interní schránce přes Online.

https://outlook.office365.com/autodiscover/autodiscover.json?Email=bouska@firma.cz&Protocol=EWS&RedirectCount=5

Mělo by dojít k přesměrování na on-premises Autodiscover a v těle vrátit adresu EWS.

https://autodiscover.firma.cz/autodiscover/autodiscover.json?Email=bouska%40firma.cz&Protocol=EWS&RedirectCount=6

{"Protocol":"EWS","Url":"https://mail.firma.cz/EWS/Exchange.asmx"}

Také můžeme ověřit dostupnost REST API, vrátit by se mělo URL.

https://mail.firma.cz/autodiscover/autodiscover.json/v1.0/bouska@firma.cz?Protocol=Rest

{"Protocol":"Rest","Url":"https://mail.firma.cz/api"}

Service Principal Name (SPN) v Azure AD

Další rada je ověřit, že se v Azure AD dobře nastavila SPN. Musí zde být záznamy pro interní Autodiscover a EWS, jde o https://namespace, nikoliv 00000002-0000-0ff1-ce00-000000000000/namespace.

Install-Module -Name MSOnline
Connect-MsolService
Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames