Guten Morgen,
wir haben gestern begonnen, von EX2010 auf EX2016 zu migrieren und dafür gestern nachmittag einen neuen Win 2016-Server mit Exchange 2016 CU 17 aufgesetzt. Die Installation war "mit Standardeinstellungen" und lief problemlos durch. Danach war es auch kein Problem, sich mit dem Domänenadmin am EAC anzumelden, die Postfächer sowie die beiden Server wurden angezeigt, alles wie man es kennt.
Dann habe ich mit den ersten Konfigurationseinstellungen begonnen, tatsächlich nach Frankys Artikel "Migration von Exchange 2010 zu Exchange 2016". Ich habe das Skript genutzt, um internalUrl und externalUrl zu setzen, haben die Authentifizierungseinstellungen zw. 2010 und 2016 abgeglichen und haben anschließend noch das gleiche Zertifikat eingespielt, welches auf EX2010 hinterlegt ist. Dies ist allerdings ein Wildcard-Zert. für unsere externe Domain und ich habe es sowohl für SMTP wie auch IIS aktiviert. Als letztes habe ich das (Ex2013)-OAB für die neue Datenbank aktiviert.
Seitdem ich mich von der Sitzung abgemeldet habe, komme ich nicht mehr in die EAC. Ich bekomme nur die "berühmte" weiße Seite. Versuche ich einen anderen Browser (z.B. Vivaldi/Chrome), sagt er mir Error 503. Interessanterweise komme ich auf das Exchange 2010-OWA, wenn ich jetzt auf Neu laden der Webseite gehe! Kann wohl irgendetwas mit der Weiterleitung vom ECP defekt sein?
Ich lande auf https://stbr1ex2016.domaene.local/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2fstbr1ex2016.domaene.local%2fecp, wenn ich den Link nutze. Wenn ich mich dann angemeldet habe, springt der Browser auf https://localhost/owa/auth.owa um. Ist das überhaupt richtig so?
Ich habe schon versucht, die zahlreichen Themen, die man googeln kann, zu Zertifikatsproblemen zu befolgen, z.B.
https://www.ugg.li/exchange-2016-owaecp-leere-seite-nach-login/
https://insidemstech.com/2016/08/15/exchange-20132016-eacecp-and-owa-blank-page-after-login/
Neues Zerti erstellt und den Bindings zugeordnet, aber das scheint es nicht zu sein. Ich habe auch keine entsprechenden Fehler im Eventlog. Auch habe ich anschließend schon versucht, die Virtual Directories für OWA and ECP neu anzulegen, auch das hat nichts geändert - außer dass anschließend die Windows-Authentifizierung nicht mehr ging und ich sie wieder über Powershell aktivieren musste. Im IIS sieht sonst alles "normal" aus, Default Web Site wie auch Exchange Back End hat seine Apps wie man sie erwarten würde und die Bindungs für Ports 443/444 sehen plausibel aus. Alle Ports-Bindings haben inzwischen auch ein Zerti mit gleichem Hash (also das gleiche zugeordnet).
Dann habe ich gedacht, dass es vielleicht an meinem per Skript gesetzten internal/externalUrls liegt, weil ich diese fälschlicherweise erst auf owa.domaene.de gesetzt hatte, diese URL zeigt aber auch über unseren internen DNS-Server auf den alten Exchangeserver. Aber auch das zurück-ändern auf die interne FQDN des Exchange 2016-Server stbr1ex2016.domaene.local bringt mit das EAC nicht zurück.
Die einzigen Eventlog-Einträge, die mir als potentiell zusammenhängend erscheinen:
- MSExchange ADAccess / 4019 / Process w3wp.exe (ECP) (PID=16104). Failed to receive invalidation message from port 9050, exception got: Ein Blockierungsvorgang wurde durch einen Aufruf von WSACancelBlockingCall unterbrochen.
- MSExchange ActiveSync / 1033 / The setting SupportedIPMTypes in the Web.Config file was missing. Using default value of System.Collections.Generic.List`1[System.String].
- MSExchange ActiveSync / 1033 / The setting LiveIdBasicAuthModule.ApplicationName in the Web.Config file was missing. Using default value of .
- Microsoft-Windows-WAS / 5138 / Der Arbeitsprozess "8368" für Anwendungspool "MSExchangeRpcProxyFrontEndAppPool" konnte in der angegebenen Zeit keinen Listenerkanal für Protokoll "http" beenden. Das Datenfeld enthält die
Langsam gehen mir leider die Ideen aus, wo ich noch schauen soll. Habt Ihr noch gute Idee? Das war leider eine kurze Freude, dass es so problemlos los geht und ich sah mich heute eigentlich schon die ganzen Postfächer umziehen... :(
Vielen Dank schon mal!!
Ok, noch eine wahrscheinlich wichtige Sache, die die Ursache sein könnte: Wenn ich auf dem Ex2016-Server https://localhost/owa aufrufe, lande ich direkt (ohne Login!) auf dem Postfach des Domänenadmins, und zwar auf dem Ex2010-OWA! Die weiterleitung scheint also etwas falsches zu tun und mich auf den alten Server umzuleiten. Und vielleicht geht EAC auch noch, weil die Webseite versucht, das auf dem Ex2010-OWA aufzurufen?!
Irgendwo müsste also im VD von ecp und owa noch etwas falsch sein. Wir finden es nur nicht! ?
Ok, das mit dem Postfach in OWA ist ja verständlich, die Mailbox liegt ja noch auf dem Ex2010.
Aber jetzt wird es klein, bunt und komisch: Mein Kollege und ich haben eben nochmal die VDs für owa und ecp neu erstellt (mit der Exchange Shell). Jetzt kommen wir wieder in die EAC - aber nur, wenn wir den Browser auf InPrivate schalten! ? Das klappt mit dem MSIE wie auch mit Chrome-basierten Browsern. Gehe ich ohne "Geheimmodus" auf die EAC-Loginseite, kommt:
Wollte nur eben zurückmelden, dass ich es jetzt hinbekommen haben. Zum letzten geschilderten Verhalten genügte es, die Formbasierte Authentifizierung wieder einzuschalten für die 2016er Webseiten für ecp und owa, also
Set-owavirtualdirectory -identity “owa (Default Web site)” -FormsAuthentication:$true
Set-ecpvirtualdirectory -identity “ecp (Default Web site)” -FormsAuthentication:$true
Sodass die Optionen wieder gleich sind wie beim auch noch laufenden Exchange 2010. Jetzt klappt alles im EAC. Mache aber gleich noch einen neuen Faden auf... ?