OwaURLIsOutOfDateException
Es gibt sie noch, die Exchange On-Premises Servers und bei einer Cross Forest-Migration bin ich auf den Fehler OwaURLIsOutOfDateException beim Zugriff per OWA gestoßen. Die Ursache ist schnell gefunden, wenn Sie die Meldung genau anschauen:
Fehlermeldung
Wir haben Postfächer von einem älteren Exchange 2010 Server zu einem neueren Exchange Server mit einem Remote Move Request verschoben. Das Benutzerkonto ist aber weiter im alten Forest verblieben und das Postfach im Zielforest wurde daher eine Linked Mailbox in einem Ressourceforest. Irgendwann später ist natürlich eine Migration der Anmeldekonten per ADMT -Active Directory Migration Toolkit geplant.
Der Benutzer hat sich nach der Migration erst mal wieder per OWA am alten Exchange Server angemeldet und wurde aber mit folgender Fehlermeldung konfrontiert.
Damit Google und Bing etwas finden, hier die Meldung noch mal als Text:
[OwaURLIsOutOfDateException] Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.GetOwaUrlForExternalMailbox(OWAMiniRecipient owaMiniRecipient) +510 Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.GetExchangePrincipal(OwaContext owaContext, ExchangePrincipal& exchangePrincipal) +311 Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.PrepareRequestWithoutSession(OwaContext owaContext, UserContextCookie userContextCookie) +251 Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.AcquireAndPreprocessUserContext(OwaContext owaContext, HttpRequest request) +786 Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.InternalDispatchRequest(OwaContext owaContext) +836 Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchRequest(OwaContext owaContext) +65 Microsoft.Exchange.Clients.Owa.Core.OwaRequestEventInspector.OnPostAuthorizeRequest(Object sender, EventArgs e) +285 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +171
Wichtig sind hier zwei String:
- Zeile 1: OwaURLIsOutOfDateException
Der CAS-Server versucht zum angemeldeten Benutzer einen neuen Exchange Server zu finden und das gelingt ihm nicht. Leider verrät er hier noch nicht Details - Zeile 2: GetOwaUrlForExternalMailbox
Dieser Fehler belegt aber schon einmal, dass der CAS/Frontend-Rolle verstanden hat, dass der Benutzer "extern" ist. Für mich bedeutet dies, dass er im MailUser das Feld "TargetAddress" gelesen und verstanden hat.
Damit startet die Analyse und Korrektur.
Analyse: Quelluser
Mittels "Get-Recipient" schaue ihr mich den Benutzer in der Quelle an. Dabei achte ich auf die Details und die Zieladresse.
[PS] C:\>Get-Recipient testuser1 | fl name,recipienttype*,ExternalEmailAddress Name : testuser1 RecipientType : MailUser RecipientTypeDetails : MailUser ExternalEmailAddress : testuser@ziel.msxfaq.de
Dieser Benutzer ist als Sicht des lokalen Exchange Servers nur noch ein "MailUser" ohne lokales Postfach und verweist den Client anhand der Routingdomäne ins Ziel. Das AD-Feld TargetAddress wird in der Exchange PowerShell als ExternalEmailAddress ausgegeben. Soweit ist alles richtig auf der Quelle
Analyse: AutoD Redirect
Nicht nur der Outlook Client wird durch die ExternalEmailAddress bei Autodiscover Redirect umgeleitet. Auch der Exchange Server nutzt bei OWA diese Funktion. In der Umgebung wurde aber keine "OrgRelationShip" eingerichtet, da die Benutzer alle zu einem Stichtag umgestellt werden sollten. Anhand der Zieladresse habe ich eine Namensauflösung auf Autodiscover geprüft:
[PS] C:\>nslookup autodiscover.ziel.msxfaq.de Server: dc1.quelle.msxfaq.de Address: 192.168.1.11 *** dc1.quelle.msxfaq.de can't find autodiscover.ziel.msxfaq.de: Non-existent domain
So hat der Exchange Server in der Quelle natürlich keine Chance. Diese Fehler ist nicht mal ungewöhnlich, dass Firmen mit zwei Forests die DNS-Auflösung nur partiell umsetzen. Die DNS-Dienste in der Quelle haben ihre eigenen Server aufgelöst und per Forwarder natürlich das Internet. Auf den Desktops wurde per DNS-Suchreihenfolge erreicht, dass die Clients beide Umgebungen auflösen aber wenn intern nur "private DNS-Domains" genutzt werden und die Routingdomäne nur im Innenverhältnis genutzt, wird, dann kann der Exchange Server auch über die öffentlichen DNS-Server keinen Weg dahin finden:
Die Lösung war schnell: Wir haben auf dem DNS-Server der Quelle eine neue Zone "autodiscover.ziel.msxfaq.de" mit einem Hosteintrag ohne Name angelegt, der auf die Exchange Server im Ziel verwiesen hat. Damit konnte wir dann sehen, dass der Client vom Quellserver auf den Zielserver umgelenkt wurde aber anmelden konnte er sich dann immer noch nicht.
Analyse: Zielpostfach
Das Zielobjekt wurde mit Prepare-Moverequest.ps1 im Ziel angelegt und dann mit einem Org2Org Exchange 2016-Move verschoben. Eine Analyse des Zielobjekts hat mehrere Dinge gezeigt:
- AD-Konto war deaktiviert
Das war zu erwarten, den es sollte ja nur ein Postfach sein, an welches sich dann aber das Anmeldekonto aus der Quell weiter anmeldet - Es war keine LinkedMailbox
Allerdings hat Prepare-Moverequest bei der Anlage "vergessen", das Postfach als LinkedMailbox anzulegen. Wobei Prepare-Moverequest hier einen Bug habe, wie ich auf Prepare-Moverequest.ps1:Parameter LinkedMailbox beschreibe. Also haben wir das Postfach schnell mit Set-User korrigiert.
Set-User testuser ` -LinkedMasterAccount quelle\testuser ` -LinkedDomainController dc1.quelle.msxfaq.de
Danach konnte sich der Testbenutzer per OWA schon mal mit seinem AD-Konto aus der Quelle auf dem Exchange Server im Ziel anmelden.
Nacharbeiten
Bei fast jeder Analyse finden sich weitere Einstellungen, die vielleicht nicht direkt schädlich sind, aber gleich mit korrigiert wurden, z.B.: wie
- Accepted Domains
Die primäre SMTP-Adresse der Quelle war auf dem Ziel-System noch gar nicht als "Accepted Domain" eingetragen. Das stört nicht, solange die Quelle die eingehenden Mails an die Routingdomain sendet. Aber wenn die Quell irgendwann abgeschaltet wird, sollte das eingehende Mailrouting ja zum Ziel gehen. Die Domain wurde als "Internal Relay" angelegt, da auch die andere Exchange Organisation ja noch Empfänger haben kann und ein kompletter Abgleich der gültigen Adressen nicht erfolgt. - Send-Connector
In dem Zuge wurde dann auch ein Send-Connector vom Ziel zur Quelle für die Domains in der Quelle gelegt, dass diese Kommunikation intern bleibt. - Empfängerrichtlinien
Prepare-Moverequest.ps1 Legt die Ziele mit der Option "-EmailAddressPolicyEnabled:$False" an. Aus meiner Sicht sollten alle Exchange Empfänger immer über die Empfängerrichtlinien konfigurierbar sein, damit ein "Update-Recipients" nichts kaputt macht. Update-Recipients wird ja gerne mal beim Provisioning oder Hybrid Configuration Wizard ausgelöst. - Ausgehender Spamfilter
Natürlich stand zwischen dem Exchange Server und dem Internet ein Antispam-Relay, welches auch ausgehend die Absender geprüft hat. Hier musste der Exchange Server mit dem ersten Absender der neuen SMTP-Domäne natürlich auch noch freigeschaltet werden.
Erfahrung
Auch wenn man schon viele Jahre Migrationen begleitet, gibt es immer wieder "Überraschungen". In diesem Fall hat Exchange mit der Fehlermeldung gut geholfen. Allerdings liefert ein Fehler selten die Lösung. Dass es hier zuerst an der fehlenden Autodiscover-Auflösung gefehlt hat, ist nur mit OWA aufgefallen. Outlook nutzt zusätzlich den Autodiscover und SCP, was aber hier nicht weitergeholfen hätte. Für den Exchange Server wäre auch eine "New-OrganizationRelationship" mit gültigen Werten für "TargetAutodiscoverEpr" und "TargetOwaURL" eine Option gewesen aber eine korrekte DNS-Auflösung mit "autodiscover.<zieldomain>" ist immer ratsam. Es gibt auch Clients, die nur diese Funktion nutzen, z.B. Skype for Business.
Ich hoffe, die Beschreibung dieser speziellen und eher seltenen Fehlersituation hat ihnen weitergeholfen, wenn Sie zufällig über die Suchbegriffe "OwaURLIsOutOfDateException" oder "GetOwaUrlForExternalMailbox" auf dieser Seite gelandet sind.
Weiter Links
- Linked Mailbox
- Ressourceforest
- Disabled Account
- ADMT -Active Directory Migration Toolkit
- Routingdomänen
- TargetAddress
- ForwardingSmtpAddress
- Prepare-Moverequest.ps1
- Autodiscover Redirect
- Org2Org Exchange 2016
- New-OrganizationRelationship
https://docs.microsoft.com/de-de/powershell/module/exchange/new-organizationrelationship