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