Exchange Hybrid deployment: jak opravit duplikované mailboxy

Miroslav Šraga — Mon, 13 Feb 2023 11:19:21 +0000

Jeden náš významný zákazník se na nás obrátil s žádostí o pomoc. Provozuje Microsoft Office 365 v hybridním režimu s Microsoft Exchange 2016. U několika uživatelů se objevil problém, že interní pošta je doručována bez problémů, ale pošta „z venku“ jim do schránky nechodí. Pošta není vidět ani v Outlooku, ani v Outlooku Online.

Po prověření situace jsme zjistili, že problém je v tom, že mailboxy uživatelů jsou založeny duplicitně v Exchange on-premises a zároveň v Office 365 (Exchange Online). Pošta, která byla zasílána z venku proto nebyla doručována do on-premises mailboxu, ale zůstávala v mailboxu, který byl v Exchange Online. Logicky pak uživatelé nemohli ve svém poštovním klientovi tyto zprávy najít.

Zdvojené poštovní schrány (duplicity mailboxů)

Pokud jsou poštovní schránky zakládány v cloudu, tak v rámci Microsoft 365 je logika, která zajišťuje, aby nevznikaly duplicitní mailboxy v Exchange Online a v Exchange on-premise. Asi si dokážete představit, jaký to je zmatek, když se zprávy z on-premise Exchange doručují zase jen do on-premisess Exchange a zprávy v rámci cloudu se doručují zase jen v rámci Exchange Online.

Pokud je ale poštovní schránka založena v Exchange on premises, je za synchronizaci atributů do služby Entra ID (Azure AD) odpovědný proces synchronizace Entra Connect (Azure AD Connect). Jedním z atributů, který se synchronizuje z on-premises do Azure AD je „ExchangeGUID„.

Tady je příklad, jak zjistit ExchangeGUID mailboxu v on-premise Exchange:

Get-Recipient jan.xxxxx| fl name,recipienttype,exchangeGuid

Name          : Jan Xxxx
RecipientType : UserMailbox
ExchangeGuid  : 6ec2eb5f-4a92-4f27-xxxx-27c168c1a28f

Když AAD Connect dokončí synchronizační cyklus, lze to ověřit na objektu poštovního uživatele v Exchange Online, kde by mělo být stejné ExchanegGUID. Každá poštovní schránka v on premise by měla být reprezentována objektem poštovního uživatele v online.

Get-Recipient jan.xxxxx| fl name,recipienttype,exchangeGuid


Name          : Jan Xxxxx
RecipientType : UserMailbox
ExchangeGuid  : da344687-715f-xxxx-880b-13b9da229c96

V tomto případě je ale vidět, že ExchangeGUID se liší, to znamená, že uživatel má schránku jak v Exchange on premise tak v Exchange Online. Toto lze ověřit také přes ECP.

Exchange Online:

Exchange on premises:

Věděli jste že účet v Active Directory můžete sloučit s existujícím účtem v Entra ID? Jak synchronizovat on-prem AD účty s existujícími účty v Entra ID

Náš zákazník má všechny schránky (z určitého důvodu) umístěny v Exchange on premise. Proto by v Enterprise ECP měla být u uživatele informace „mailbox type: Office 365“ a to není. Schránka tedy skutečně existuje na dvou místech.

Jak tuto situaci napravit? Jsou dvě metody

Smazat účet v Entra ID (Azure Active Directory)
Odebrat licenci Exchange Online

Obě metody mají svá pro a proti. V tomto případě jsme se rozhodli že půjdeme první cestou, tedy cestou smazání účtu v Entra ID (Azure Active Directory), ale tak, abychom minimalizovali případné škody.

Výhody tohoto postupu:

Smazání účtu je poměrně jednoduchý proces
Mailbox může být migrován z on-premise do cloudu a zpět hned, jakmile proběhne sychnoziace Azure AD Conenct
Exchange Online podporuje spojení mailboxů, takže uživatel nepřijde o zprávy. Zprávy z obou mailboxů by měly být zachovány

Je zde také pár potenciálních nevýhod tohoto řešení:

Jedná se o kompletní obnovu/reset cloudového účtu
Všechna oprávnění udělení tomuto účtu v rámci služby (vlastnictví webu v Sharepoint / OneDrive apod.) budou ztracena
Jakékoliv členství v cloudových distribučních seznamech bude ztraceno
Může dojít ke krátkému výpadku toku pošty u spravovaného účtu (z důvodu odstranění a znovu vytvoření objektu v Exchange Online)

Nejprve ověříme, že mailbox v Exchange Online existuje a shoduje se s účtem v on premise Exchange

Exchane Online Powershell:

Get-mailbox jan.xxxx

On-Premises Exchange PowerShell:

Get-mailbox jan.xxxx

V Microsoft 365 Admin centru ověříme, že je účet synchronizován z on-premises Active Directory

Tak, máme ověřeno, že se jedná o tentýž účet a že tento uživatel má mailbox v on-premises i v cloudu.

Abychom mohli zahájit nápravu, je třeba si na začátku zjistit a zapsat několik informací, hlavně ExchangeGUID mailboxu v Exchange Online:

Get-mailbox jan.xxxx | select-object ExchangeGUID

Je také dobré si uložit informace z parametru EmailAddresses na Exchange on-premises (viz dále problém 2 – chyba IMCEAEX)

Pomocí Entra ID (Azure Active Directory) PowerShell smažeme účet a odebereme z „koše“

Remove-MsolUser -UserPrincipalName jan.xxxxx@domena.cz -Force
Remove-MsolUser -UserPrincipalName jan.xxxxx@domena.cz -Force -RemoveFromRecycleBin

Výmaz si můžete ověřit pomocí powershell příkazu Get-MsolUser, kdy by uživatel neměl být nalezen mezi aktivními uživateli.

Příkaz by tedy měl vrátit chybu:

V Exchange Online si ověříme, že mailbox již neexistuje

Get-mailbox jan.xxxx

Mailbox by měl nyní být ve stavu „SoftDeleted„

Get-Mailbox jan.xxxx -SoftDeletedMailbox

Nyní jsme ve stavu, kdy vazba mezi účty v Online a v on premises byla „vyčištěna“. Nyní může proběhnout další kolo synchronizace Entra Connect (Azure Active Directory Connect). Objekt by měl být znovu načten z on-premises Active Directory (může to chvilku trvat – synchronizace probíhá každých 30 minut, jinak se dá aktuální nastavení zjistit pomocí příkazu „Get-ADSyncScheduler„)

Get-MsolUser -UserPrincipalName jan.xxxxx@domena.cz

Sloučení mailboxů

Pro sloučení schránek je potřeba, aby oba mailboxy byly přítomny v Exchange Online.

Pokud je tedy vše v pořádku, může být účet migrován z on-premise do Exchange Online. Toto není povinný krok, ale je vhodné toto provést v případě, kdy chceme propojit oba mailboxy.

Průběh migrace lze sledovat také přes powershell. Informaci o tom, že byla migrace dokončena tak získáte zpravidla dříve, než přes ECP rozhraní. Stačí použít příkaz:

Get-MigrationUserStatistics -Identity jan.xxxxx@domena.cz -IncludeReport | Format-List Status,Error,Report

Jakmile je migrace dokončena, v Exchange Online se objeví objekt (mailbox). Ve stavu „před sychnronizací“ mailbox neexistuje (viz obrázek níže)

Get-Mailbox jan.xxxx

Pro dokončení obnovy mailboxu (spojení mailboxů za účelem zachování e-mailových zpráv), bude potřeba znát ExchaneGUID migrovaného mailboxu.

Get-Mailbox jan.xxxx | Select-Object exchangeGUID

A také bude potřeba ExchangeGUID mailboxu, který je v režimu „SoftDeleted“ – toto GUID jsme si poznačili na začátku postupu.

V tuto chvíli přiřaďte uživateli zpět licenci Office 365 (aby měl zalicencovaný mailbox)

Pokud známe obě ID, můžeme zahájit proces spojení mailboxů:

New-MailboxRestoreRequest -SourceMailbox [ExchangeGUID které jsme si uložili] -TargetMailbox [ExchangeGUID mailboxu v Exchange Online] –AllowLegacyDNMismatch

Průběžně lze kontrolovat stav pomocí příkazu „get-mailboxRestoreRequest„, kdy sloupec status může obsahovat 3 stavy: Queued, InProgress a Completed nebo Failed

Upozornění Pokud příkaz skončí chybou, zkuste přidat parametr -TargetFolder „CilovaSlozka“ – zprávy ze Soft deleted mailboxu se obnoví do této složky. Pokud to nepomůže, podívejte se níže na řešení případných problémů.

Informace Pokud se Vám dlouho zobrazoval status „InProgress“ a nakonec restore zkočil „Failed“ – ověřte přímo v mailboxu, jestli zprávy náhodou nebyli obnoveny, setkal jsem se s případem, kdy takový restore skončil jako „Failed“, ale uživatel potvrdil, že zprávy má ve schránce jak z Office 365 tak s Exchange On-premise“

Pokud je vše v pořádku a příkaz doběhl do stavu Completed, máte téměř hotovo. Nyní již stačí jen provést migraci schránky zpět z Exchange Online do Exchange On-premises (pokud je to potřeba).

Řešení možných problémů

Problém #1: Příkaz New-MailboxRestoreRequest neustále končí chybou

Pokud zprávy ve schránce prostě nejsou, je třeba jít štěstí trochu naproti. S tímto problémem jsme se setkali a přímo jsme jej nevyřešili, ale našli jsme „obezličku“, která sice nemusí úplně všem vyhovovat, ale pro naše potřeby byla zcela dostačující.

E-maily obnovíme do sdíleného mailboxu, který vytvoříme příkazem:

$NameSharedMailbox = "jan_xxx_shared"

New-Mailbox -Shared -Name $NameSharedMailbox -DisplayName $NameSharedMailbox -Alias $NameSharedMailbox

Následně si do proměnné uložíme GUID tohoto mailboxu

$ShareMailboxGetGUID = Get-Mailbox -Identity $NameSharedMailbox

Provedeme restore Soft Deleted Mailboxu stejným způsobem, jako jsme se pokoušeli dříve, ale nyní restore provedeme do vytvořeného sdíleného mailboxu.

New-MailboxRestoreRequest -SourceMailbox  [ExchangeGUID které jsme si uložili]   -TargetMailbox $ShareMailboxGetGUID.PrimarySmtpAddress -AllowLegacyDNMismatch -Verbose

Obnova schránky by měla proběhnout bez problémů.

Nyní máte dvě možnosti
1) Připojit uživateli sdílený mailbox a zprávy přesunour ručně, nebo
2) Zkopírovat zprávy ze sdíleného mailboxu do mailboxu uživatele (do složky „Zaloha“)

Search-Mailbox jan_malat_shared@cspsd.cz  -TargetMailbox jan.xxxx@domena.cz -TargetFolder "Zaloha" -LogLevel Full

Problém #2: „Doručení těmto příjemcům nebo skupinám se nepodařilo“

Při pokusu o doručení zprávy příjemci v rámci domény se vrátí (ne)doručenka s chybou:

E-mailovou adresu, kterou jste zadali, se nepovedlo najít. Zkontrolujte si prosím e-mailovou adresu příjemce a zkuste zprávu poslat znovu. Pokud s tím budou dál problémy, kontaktujte prosím svého správce e-mailu. 

Diagnostické informace pro správce: Server pro generování: EXxxx.adds.xxxx.cz IMCEAEX-_o=XXXXXX_ou=Exchange+20Administrative+20Group+20+28FYDIBOHF23SPDLT+29_cn=Recipients_cn=7e7d3xxxxxxxxxxxxb702e7d69a663e-Jxxxxxxxx+20Xxxxxxxx@xxxxxxxx.cz Remote Server returned '550 5.1.11 RESOLVER.ADR.ExRecipNotFound; Recipient not found by Exchange Legacy encapsulated email address lookup'

Tato chyba se vyskytuje pouze v případě, kdy odesílatel zprávy použil aplikaci Microsoft Outlook a vybral adresáta z našeptávače. Zde je v cache uloženo tzv „LegacyExchangeDN„, které odkazuje na původní ID mailové schránky (slučovali jsme 2 schránky do jedné). Náprava je jednoduchá – do e-mailových adres u daného uživatele přidat (stávající nechat, nic neměnit) parametr X500, který bude obsahovat právě zmíněné původní LegacyExchangeDN (viz. informace z parametru EmailAddresses, které jste si uložili na začátku).

Více informací a postup je zpracován zde: https://support.microsoft.com/en-gb/help/2807779/imceaex-non-delivery-report-when-sending-emails-to-internal-users