Hybridkonfiguration lässt sich nicht einrichten auf Exchange 2019

[mwiederkehr 382]

Hallo zusammen

 

Ein Kunde mit drei Exchange 2016, einmal Edge, zweimal Postfach in einer DAG, hat auf Exchange Online migriert. Ich habe dazu auf einem Server die Hybridkonfiguration eingerichtet und danach die Postfächer nach und nach verschoben. Das hat alles geklappt, die Postfächer sind nun in der Cloud.

 

Lokal sollen keine Postfächer mehr betrieben werden, aber man möchte ein lokales Relay für Scan2Mail etc. und das ECP für die Verwaltung. Um auch gleich das unbeliebte Windows 2016 abzulösen, habe ich Exchange 2019 auf einem Server 2019 installiert. Der Server läuft, Relay funktioniert.

 

Nur der Assistent zur Hybridkonfiguration bringt bei der Prüfung der Konfiguration nach fünf Minuten den Fehler, er erreiche den lokalen MRS-Proxy nicht.

 

Der Hybrid Agent läuft (Dienst kann gestartet werden, keine Fehlermeldungen im Log).

 

Im Log des Assistenten steht Folgendes:

TestMigrationServerAvailabilityOutcome {ErrorDetail='Microsoft.Exchange.Migration.MigrationServerConnectionFailedException: Die Verbindung mit Server 'xxxxxxxx-a46a-40ed-xxxx-4976e83b5ec7.resource.mailboxmigration.his.msappproxy.net' konnte nicht hergestellt werden. ---> Microsoft.Exchange.MailboxReplicationService.MRSRemoteTransientException: Fehler beim Aufruf von "https://xxxxxxxx-a46a-40ed-xxxx-4976e83b5ec7.resource.mailboxmigration.his.msappproxy.net/EWS/mrsproxy.svc", da kein Dienst am angegebenen Endpunkt gelauscht hat. Fehlerdetails: There was no endpoint listening at https://xxxxxxxx-a46a-40ed-xxxx-4976e83b5ec7.resource.mailboxmigration.his.msappproxy.net/EWS/mrsproxy.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. --> The remote server returned an error: (404) Not Found.

 

Führe ich "Test-MigrationServerAvailability -ExchangeRemoteMove: $true -RemoteServer 'xxxxxxxx-a46a-40ed-xxxx-4976e83b5ec7.resource.mailboxmigration.his.msappproxy.net' -Credentials (Get-Credential -UserName domain\admin)" in der PowerShell aus, lautet die Meldung anders:

Microsoft.Exchange.Migration.MigrationServerConnectionFailedException: Die Verbindung mit Server
'xxxxxxxx-a46a-40ed-xxxx-4976e83b5ec7.resource.mailboxmigration.his.msappproxy.net' konnte nicht
hergestellt werden. ---> Microsoft.Exchange.MailboxReplicationService.RemoteTransientException:
Fehler beim Aufruf von "https://xxxxxxxx-a46a-40ed-xxxx-4976e83b5ec7.resource.mailboxmigration.his
.msappproxy.net/EWS/mrsproxy.svc". Fehlerdetails: Die HTTP-Anforderung wurde mit
Clientauthentifizierungsschema "Negotiate" nicht zugelassen. --> Der Remoteserver hat einen
Fehler zurückgegeben: (403) Unzulässig.. --->
Microsoft.Exchange.MailboxReplicationService.RemotePermanentException: Die HTTP-Anforderung wurde
mit Clientauthentifizierungsschema "Negotiate" nicht zugelassen.

 

Versuche ich den Zugriff per Browser, ist die Antwort HTTP 403, es erscheint kein Anmeldefenster.

 

Auf dem EWS-Verzeichnis ist der MRS-Proxy aktiviert. Deaktivieren, iisreset, Aktivieren, iisreset haben nicht geholfen. Standardauthentifizierung ist erlaubt auf dem EWS-Verzeichnis.

 

Kennt jemand das Problem?

 

Oder, vielleicht mal einen Schritt zurück: Wenn man lokal keine Postfächer mehr hat, ist die Hybridkonfiguration überhaupt den Aufwand wert? Free/Busy etc. wird dann ja nicht benötigt und die AD-Objekte werden über AADSync übertragen.

[testperson 1.713]

Hi,

 

was passiert, wenn du die Basic Auth aktivierst:

Get-WebServicesVirtualDirectory -Server $env:COMPUTERNAME | Set-WebServicesVirtualDirectory -MRSProxyEnabled:$true -BasicAuthentication:$true

 

Der Reverse Proxy / NAT zeigt auf den neuen Exchange und die EWS URLs sowie das Zertifikat passen am neuen Exchange auch?

 

Gruß

Jan

[mwiederkehr 382]

Basic Authentication ist erlaubt. Habe die Einstellungen gesetzt wie auf dem bestehenden Server.

 

Der neue Server ist von extern nicht erreichbar. So, wie ich die Dokumentation verstanden habe, ist das auch nicht nötig. (Ausser SMTP von Exchange Online her, falls lokale Postfächer vorhanden sind.) Habe ich da etwas missverstanden?

 

Das Zertifikat ist ein "offizielles" Wildcard-Zertifikat, welches auch auf den anderen Servern zum Einsatz kommt.

[mwiederkehr 382]

Problem gelöst: Das virtuelle EWS-Verzeichnis hatte nur eine interne URL eingetragen, die externe war leer. Intern war zwar die zum Zertifikat passende URL eingetragen. Habe diese auch extern gesetzt und dann hat es sofort funktioniert.

 

Der Fehler muss so blöde sein, dass ihn nicht einmal der Microsoft-Support mit den Diagnosescripts erkannt hat.

[NorbertFe 2.066]

vor 12 Minuten schrieb mwiederkehr:

Der Fehler muss so sein, dass ihn nicht einmal der blöde Microsoft-Support mit den Diagnosescripts erkannt hat.

Ich korrigier mal