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.
Pokud jsou poštovní schránky zakládány v cloudu, tak v rámci Office 365 je logika, která zajišťuje, aby nevznikaly duplicitní mailboxy v Office 365 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 Azure AD a Office 365 odpovědný proces synchronizace Azure Active Directory (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-27c168c1a28fKdyž 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-13b9da229c96V 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:
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 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 Azure Active Directory, ale tak, abychom minimalizovali případné škody.
Výhody tohoto postupu:
- Smazání účtu z Azure Active Directory 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 účtu v Azure Active Directory
- 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:
Get-mailbox jan.xxxx
On-Premises Exchange:
Get-mailbox jan.xxxx
Na portále Office 365 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í 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 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
Pokud je 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
TIP:
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ů.
INFO:
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.
Ř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
Komentáře jsou uzavřeny.