Bei der Ausführung eines Migrations-Batches kann es beim Verschieben eines Postfaches zu einem SourceMailboxAlreadyBeingMovedTransientException Fehler kommen.
Dieser Fehler tritt auf, wenn für ein Quell-Postfach bereits das InTransit-Flag gesetzt wurde und es während der Ausführung des Migrations-Batches zu Problemen kommt. Dieses Flag signalisiert, dass bereits eine Postfach-Verschiebung aktiv ist.
Dieses Flag ist ein sog. In-Memory-Flag und bleint auch u.U. gesetzt, wenn Sie den Migration-Batch abbrechen und löschen.
Das Flag lässt sich nur durch einen den Neustart des Exchange Informationsspeichers bzw- durch ein Fail-Over der Postfach-Datenbank des betroffenen Postfaches löschen.
Für den Neustart des Exchange Informationsspeichers führen Sie folgenden Befehl in einer administrativen PowerShell-Sitzung aus:
Restart-Server MSExchangeIS
Der Fehler kann tritt technisch unabhängig von der Postfachgröße auf. Jedoch sind große Postfächer naturgemäß, durch die zeitliche Dauer der Migration, anfälliger für Fehler durch Probleme bei der Netzwerkverbindung. Selbst wenn die standardmäßige TCP KeepAliveTime von Windows Server von 2 Stunden auf 5 Minuten angepasst wird, wie im Blog-Artikel von Brad Hughes beschrieben.
Ebenso tritt der Fehler bei Migration von On-Premises Exchange Server zu Exchange Online, wie auch bei lokalen Cross-Forest Migrationen auf.
Enjoy Exchange!
Und weiter einmal...
Die neue Version von .Net Framework wurde veröffentlicht und von Microsoft per Windows Update bereitgestellt. Das Exchange Team wiederum hat sich überlegt, die Version 4.7.2 nicht offiziell zu unterstützen. Das bedeutet, dass Sie .Net Framework 4.7.2 auf Exchange Server Systemen nicht installieren dürfen.
Da die Verteilung per Windows Update erfolgt, müssen Sie die Installation per Registrierungsschlüssel auf jedem Exchange Server blockieren.
Mit der folgenden BlockNetFramework472.reg Datei können Sie den Registrierungsschlüssel schnell und einfach setzen.
Weiterhin Viel Spaß mit Exchange Server!
Das Blog Cumulative Update für April 2018 (CU0418) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Office 365, Azure und Skype for Business des Monats April 2018 zusammen.
Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.
Sie denken über einen vollständigen Wechsel zu Office 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform.
Sie möchten mehr über Exchange Server 2016 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop.
Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu
Die Aktivierung der Kerberos Authentifizierung für Exchange Server 2013/2016 wird in diversen Artikeln im Internet beschrieben. In diesem Blogartikel geht es heute um ein Phänomen, das mir in einer Exchange Server 2013 Umgebung (8 Server DAG) begegnet ist.
Alle Outlook 2010 Clients verwenden OutlookAnywhere für den Exchange Server Zugriff aus dem internen Netz. MAPI over Http ist sowohl auf der Organisationsebene als auch auf Postfachebene deaktiviert, da noch ein Problem mit der Kompatibilität einer Drittanbietersoftware existiert.
Nach der Aktivierung der Kerberos Authentifizierung verwenden alle Outlook Clients weiterhin nur die NTLM Authentifizierung, um sich am OutlookAnywhere Endpunkt anzumelden. Und dies, obwohl die Schritt-für-Schritt Anleitung aus dem TechNet befolgt wurde. Kerberos war für die Outlook Clients kein Thema.
Ein Blick in die Übersicht des Outlook Verbindungsstatus (Strg + Rechter Mausklick auf des Outllok Symbol im System Tray) zeigt die Verwendung von NTLM.
Die Umstellung der Authentifizerung auf Kerberos für OutlookAnywhere erfolgt auf jedem CAS Server über das folgende PowerShell Cmdlet:
Get-OutlookAnywhere -Server CASSERVER | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
Alle acht Exchange 2013 Server boten auch nach gebotener Zeit keine Nego Authentifizierung an. Die Überprüfung der OutlookAnywhere Konfiguration mit Hilfe der PowerShell zeigte die korrekten Konfigurationswerte. Aber was nun?
Ein Kontrolle der Authentifizerungseinstellungen für das \Rpc virtuelle Verzeichnis der Front End Website in der IIS Management Console zeigte, dass das virtuelle Verzeichnis nur für NTLM konfiguriert war.
Mit Hilfe der IIS Management Console wurde der Negotiate Authentifizierungsanbieter hinzugefügt in der Reihenfolge der Anbieter an die erste Stelle gesetzt..
Nach Anpassung der Authentifizierungsanbieter in der Front End Wesbite können sich Outlook Clients mit Kerberos Authentifizerung an den OutlookAnywhere Endpunkt verbinden.
Im Normalfall sollte die IIS Management Console nicht für die Konfiguration der virtuellen Verzeichnisse einer Exchange Server INstallation verwendet werden. Die Anpassung der Konfigurationen mit Hilfe IIS MMC sollte nur im Troubleshooting-Fall verwendet werden, wenn einem unerklärliche Phänomene begegnen.
Die bevorzugte Methode zur Konfiguration von Exchange Server Einstellungen für virtuelle Verzeichnisse ist die Exchange Management Shell.
Weiterhin viel Spaß mit Exchange Server
Microsoft hat die Exchange Updates für das 4. Quartal 2016 veröffentlicht.
Für den Betrieb von Exchange Server 2016 auf Windows Server 2016 wurde ein Knowledge Base Artikel veröffentlicht. Bei einer Installation von Exchenge auf Windows Server 2016 ist die Installation des Fixes zwingend. Das Setup wird ohne die Installation des Fixes nicht fortfahren.
Der Einsatz von .NET Framework 4.6.2 ist für die Q4 2016 Cumulative Updates noch optional, jedoch dringend empfohlen. Für die kommenden Cumulative Updates wird das .NET Framework 4.6.2 allerdings verpflichtend sein.
Die einzelnen Updates für Exchange:
Bei einem Hybrid Betrieb mit Office 365 und Exchange Server 2013/2016 muss entweder das jeweils das aktuelle CU oder nur das vorherige CU installiert sein. Dies entspricht dem N-1 Ansatz.
Für einen reinen On-Premises Betrieb von Exchange Server 2013/2016 gilt N-2. Es wird jeweils das aktuelle CU und die beiden letzten Vorversionen unterstützt.