Exchange 2013: Rückmigration von Postfach Exchange 2013 auf 2007 schlägt fehl/funktioniert nicht

Problem:
Ich musste ein bereits migriertes Postfach vom Exchange 2013 auf den Exchange 2007 zurück verschieben.
Die Migrationsbatch wurde erzeugt, lief aber niemals los.

Lösung:
Aus mir leider nicht ganz verständlichen Gründen, muss man die erste Migration des Postfaches ZUM Exchange 2013 in der Migrationsübersicht löschen und danach ist eine Rückmigration problemlos möglich.
Sie können diese Löschen in der ECP-Website unter "Postfach" -> "Migration".
Hier die entsprechenden Batches des Postfaches suchen und alle löschen.
Nach der Löschung (kann etwas dauern - immer wieder aktualisieren) kann das Postfach auf den alten Exchange verschoben werden!

Exchange 2007 - 2013 Migration: Outlook verlangt ständig Anmeldedaten (Credential Popup) für Öffentliche Ordner

Problem:
Ich bin gerade bei einer Migration von Exchange 2007 auf Exchange 2013.
Da die Migration im laufenden Betrieb durchgeführt wird und Exchange 2013 nicht direkt auf die Öffentlichen Ordner von Exchange 2007 zugreifen kann, musste ich die Discovery-Mailbox-Variante wählen um den Zugriff der umgezogenen Clients zu ermöglichen (siehe Quelle unten).
Dabei ist aufgefallen, dass alle umgezogenen Benutzer auf Exchange 2013 mehrmals am Tag die Verbindung zum Öffentlichen Ordner auf Exchange 2007 verloren haben und sich ein Anmeldefenster dazu öffnet. Das war sehr lästig und ich habe viel an den IIS-Einstellungen vom alten und neuen Exchange versucht - alles erfolglos!
Daraufhin habe ich herausgefunden, dass ich Outlook über die Exchange-Proxy-Einstellungen zu einem TCP-Connect "zwingen" kann, indem ich dort den Haken "Bei schneller Verbindung zuerst über HTTP verbinden" entferne. Damit versucht Outlook erst eine TCP-Verbindung und dann eine HTTP-Verbindung. Das klappt super gut und die Verbindung zum alten Server geht über RPC/TCP und zum neuen über RPC/HTTP.
Das nächste Problem: Das Autodiscover überschreibt meine Einstellungen und setzt mir den Haken immer wieder neu!!!

Lösung:
Man kann mittels Registry eine Policy setzen, wodurch man die Einstellung dauerhaft festsetzen kann.
Hier die Policy, wie ich Sie aktuell für Outlook 2007 - 2013 erfolgreich einsetze:

Key : HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\office\xx.0\Outlook\RPC
Value Name : proxyserverflags
Value Type : REG_DWORD
Value : 39 (27h)


Wobei xx für die jeweilige Office-Version steht (12 = Office 2007, 14 = Office 2010, 15 = Office 2013, 16 = Office 2016)

Das ist zwar nicht die sauberste Lösung, da ich eigentlich das Problem am Exchange 2007 nicht gelöst habe doch will ich gerade nicht die Konfiguration des alten Servers so extrem abändern, dass mir etwas anderes "um die Ohren fliegt". Außerdem wird der alte Exchange-Server nach der Migration sowieso abgeschaltet und damit erledigt sich dann auch das Problem.

Quelle für Flags: getadmx.com: RPC/HTTP-Verbindungs-Flags

Quelle Discover Public Folder 2013: Technet: Konfigurieren älterer öffentlicher Ordner, wenn sich die Postfächer der Benutzer auf Exchange 2013-Servern befinden


Exchange 2013: 451 4.7.0 Temporary server error. PRX5

Problem:
Ab und zu gibt der Exchange 2013 folgenden Fehler beim Empfangen von Mails zurück:
451 4.7.0 Temporary server error. Please try again later. PRX5

Ursache:
Scheinbar gibt es hier DNS-Probleme, wenn der Server seine interne Struktur auflösen will.
Genau habe ich das Problem noch nicht vollständig analysieren können.

Lösung:
Hier gibt es zwei einfache Lösungsansätze:

1.)Anpassen des DNS-Lookups am Exchange
- Öffnen Sie die ECP-WEbsite und navigieren Sie zu "Server" -> "Server" -> "DNS-Lookups"
- Stellen Sie hier explizit die richtige Netzwerkkarte ein, über die der Exchange mit dem LAN verbunden ist (Default: Alle Netzwerkkarten)
- Tragen Sie hier Ihre internen DNS-Server vollständig ein


2.) Eintrag in HOSTS-Datei
- Öffnen Sie die HOSTS-Datei und tragen Sie hier den FQDN und NetBIOS-Namen Ihres Exchange-Servers mit der richtigne IP-Adresse ein


Nach den Änderungen müssen Sie folgende Exchange-Dienste neu starten:
- Microsoft Frontend Transport
- Microsoft Exchange Transport

Erste danach ziehen die neuen Einstellungen.
Ich konnte den Fehler so beheben (bis jetzt zumindest!)

Quelle: support.everycloudtech.com: 451 4.7.0 Temporary server error. Please try again later. PRX5

Exchange 2013: Koexistenz Exchnage 2007/2017 Proxy oder Redirect der Dienste?

Ich habe hier eine schöne Übersicht gefunden, welche Dienste (OWA, ECP, ActiveSync etc.) bei einer Koexistenz Exchange 2007/2010 mit einem Exchange 2013 wie behandelt wird (Proxy oder Redirect):


Quelle:
VANHYBRID.COM: Exchange 2013 interoperability with legacy Exchange versions


Exchange 2013: Powershell Error : FailureCategory=Cafe-SendFailure FullyQualifiedErrorId : -2144108477

Problem:
Szenario: Windows Server 2008 R2 aktuell gepatcht - Exchange 2013 CU14 installiert

Beim Versuch auf die Powershell zuzugreifen, wird folgender Fehler mehrfach ausgegeben:
VERBOSE: Connecting to exchange2013. New-PSSession : [exchange2013] Connecting to remote server exchange2013 failed with the following error message : [ClientAccessServer=exchange2013,BackEndServer=exchange2013,RequestId=fd9724cd-19fb-4842-b30d-c9c4b976119f,TimeStamp =2016-03-24 18:55:58] [FailureCategory=Cafe-SendFailure] For more information, see the about_Remote_Troubleshooting He lp topic. At line:1 char:1 + New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException + FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed


Lösung:
Nach etwas Recherche war mir klar, dass es mit dem SSL-Zertifikat von Exchange zu tun haben muss.

1. Lösungsansatz:
Bitte prüfen Sie im IIS-Manager ob sowohl bei der "Default Web Site" und der "Exchange Back End" unter "Bindungen" -> HTTPS das richtige (oder überhaupt ein gültiges) SSL-Zertifikat zugewiesen ist. Eventuell bei der Powershell-Website unter "Exchange Back End" auch mal bei den "SSL-Einstellungen" den Haken bei "SSL erforderlich" entfernen - somit wird das SSL-Zertifikat ignoriert und man kann prüfen, ob dann die Powershell-Verbindung funktioniert.

2. Lösungsansatz (Fehler bei mir):
Nachdem das Zertifikat in Ordnung war, musste ich nach einem anderem Fehler suchen.
Fündig würde ich im Ereignisprotokoll hier habe ich folgenden Eintrag gefunden:
Schannel - Event-ID: 36885
Bei der Nachfrage der Clientauthentifizierung sendet dieser Server eine Liste vertrauenswürdiger Zertifizierungsstellen an den Client. Der Client verwendet diese Liste, um ein Clientzertifikat auszuwählen, das für den Server vertrauenswürdig ist. Momentan vertraut dieser Server sehr vielen Zertifizierungsstellen, sodass die Liste zu lang ist. Die Liste wurde abgeschnitten. Der Administrator dieses Computer sollte die für Clientauthentifizierung vertrauenswürdigen Zertifizierungsstellen überprüfen und diejenigen entfernen, die nicht unbedingt als vertrauenswürdig eingestuft werden müssen.
Mit dieser Meldung habe ich mittels Zertifikats-MMC ein mal die "Vertrauenswürdigen Stammzertifikatsstellen überprüft" und hier 299(!!) Zertifikate gefunden, die Großteils mir überhaupt nicht bekannt waren. Eine weitere Suche im Netz hat folgenden Microsoft-Artikel hervorgebracht: Microsoft: SSL/TLS communication problems after you install KB931125
Hier wird beschrieben, dass so etwas auftreten kann, nach der Installation des Updates KB931125.
Die Lsöung im Artikel habe ich wie folgt durchgeführt:

1.) Öffnen Sie den Registry-Editor (regedit.exe)
2.) Navigieren Sie zu folgendem Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
3.) Exportieren Sie diesen Pfad sicherheitshalber und löschen Sie Ihn danach!

Danach hatte ich nur noch ca. 20 Zertifikate in den vertrauenswürdigen Stammzertifikatsstellen und meine Powershell und alle HTTPS-Seiten auf meinem Exchange 2013 liesen sich problemlos öffnen!

Quelle der Lösungsfindung:
blackseals.net: Liste der vertrauenswürdigen Stamm-Zertifizierungsstellen ist zu lang
Microsoft: SSL/TLS communication problems after you install KB931125

“Das Alzheimer-Gesetz der Programmierung: Wenn du einen von dir vor zwei Wochen geschriebenen Code ansiehst, kommt es dir vor als hättest du ihn noch nie gesehen.”
Dan Hurvitz – Software-Entwickler