Wenn Sie versuchen, die Mitglieder einer E-Mail-aktivierten Sicherheitsgruppe im Exchange Admin Center bearbeiten und anschließend speichern möchten, kann es zu folgender Fehlermeldung kommen.
Eine E-Mail-aktivierte Sicherheitsgruppe erlaubt das selbständige Verlassen oder Beitreten durch Anwender nicht. Diese Funktion ist Verteilergruppen vorbehalten. Die Konfiguration dieser Einstellung ist im Exchange Admin Center für E-Mail-aktivierte Sicherheitsgruppen nicht möglich. Diese Einstellungen können nur per Exchange Management Shell durchgeführt werden.
Fragen Sie die Einstellungen der E-Mail-aktivierten Sicherheitsgruppe per PowerShell ab.
Get-Distributiongroup SECURITYGROUPNAME | FL Name, GroupType, RecipientTypeDetails,*Restriction
Wenn Sie dem Hinweis der Fehlermeldung folgen und nur einen der beiden Parameter zum Beitreten oder Verlassen einer E-Mail-aktivierten Sicherheitsgruppe per Exchange Management Shell auf Geschlossen (Closed) setzen, erhalten Sie ebenfalls eine Fehlermeldung.
Setzen Sie immer beide Parameter gleichzeitig.
Set-DistributionGroup SECURITYGROUPNAME -MemberJoinRestriction Closed -MemberDepartRestriction Closed
Nach dieser Anpassung der E-Mail-aktivierten Sicherheitsgruppe ist es wieder möglich, die Mitglieder der Sicherheitsgruppe über das Exchange Admin Center zu pflegen.
Dieser Fehler trat in einer Active Directory Umgebung auf, in der vorübergehend die Exchange Organisation in einer Split-Permission Konfiguration betrieben und wieder auf Shared-Permission zurückgestellt wurde.
Viel Spaß mit Exchange Server.
Manchmal ist es notwendig, das Offline Adressbuch (OAB) für den Outlook E-Mail Client manuell herunterzuladen.
Kommt es beim Herunterladen des OAB zu einem Fehler, in diesem Fall 0x80200051, wird durch den First-Line Support gerne zwischen dem Online- und dem Cached-Modus von Outlook hin und her gewechselt. Leider behebt dieses Vorgehen den Fehler nicht.
Nach dem erneuten Aktivieren des Cached-Modus, muss das OAB vollständig neu heruntergeladen werden. Leider ist im Outlook-Diaglog zum manuellen Download des OAB die Checkbox "Änderungen seit der letzten Übermittlung herunterladen" standardmäßig aktiv. Diese Option muss abgewählt werden, um einen vollständigen Download es OAB durchführen zu lassen.
Mit dieser Download-Einstellung kommt es nicht mehr zu einem Fehler.
Viel Spaß mit Outlook.
Wenn Sie Öffentliche Ordner alter Bauart (Legacy Public Folder) von Exchange Server 2010 zu modernen Öffentlichen Ordnern (Modern Public Folder) in Exchange Online migrieren, kann es bei der Synchronisation der Öffentlichen Ordner zu folgendem Fehler kommen:
Error: More than X mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important
Dieses Problem tritt in folgendem Szenario auf:
Ausgabe des Scripts Sync-MailPublicFolders.ps1 nach Deaktivierung aller E-Mail-aktivierten Öffentlichen Ordner:
Creating an Exchange Online remote session... Exchange Online remote session created successfully. Enumerating local mail enabled public folders... Mail public folders enumeration completed: 0 local folder(s) found. WARNUNG: You are about to remove ALL mail-enabled public folders from Exchange Online Active Directory. Only proceed if you do not have any users on Exchange Online already using mail-enabled public folders.
Das Script meldet zwar, dass bei der Synchronisation die Informationen über die inzwischen E-Mail-deaktivierten Ordner aus Exchange Online entfernt werden, dies ist jedoch nicht der Fall.
Prüfen Sie in der Exchange Online PowerShell, ob sich noch E-Mail-aktivierte Ordner in der Exchange Online Organisation befinden.
Get-MailPublicFolder -ResultSize Unlimited
Prüfen Sie, welche vermeintlich E-Mail-aktivierten Ordner inzwischen deaktiviert wurden und entfernen Sie diese Ordner aus der Exchange Online Organisation
# Löschung eines lokal nicht mehr E-Mail-aktivierten Ordners Get-MailPublicFolder 'Mail Public Folder' | Remove-SyncMailPublicFolder # Löschung alle E-Mail-aktivierten Ordner Informationen aus Exchange Online Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder
Nach der Löschung der Informationen aus Exchange Online wird die nächste inkrementelle Synchronisation des Migrationsbatches ohne Fehler durchlaufen.
Viel Spaß bei der MIgration von Öffentlichen Ordner zu Exchange Online!
Das Thema "ungünstiger Exchange Server Implementierungen" scheint in seiner Vielfalt unerschöpflich. Leider ist Exchange Server, auch in der aktuellen Version 2019, ein sehr tolerantes Produkt, wenn es um die Installation und den Erstbetrieb geht. Die eigentlichen Probleme und Fehler einer schlechten Exchange Server Implementierung treten erst nach einer gewissen Betriebszeit in Erscheinung. Ähnlich sieht es aus, wenn nach einer IT-Störung notwendige Wiederherstellungsschritte ausgelassen oder unbedacht ausgeführt werden.
Heute möchte ich mit Ihnen folgendes Beispiel teilen, bei dem einige Informationen auf Annahmen basieren, da von Kundenseite nicht alle Fragen beantwortet wurden bzw. beantwortet werden konnten.
In der lokal installierten Exchange Server Plattform treten Performance-Probleme mit der Nachrichtenzustellung im Outlook-Client auf. Nach Aussage des Kunden erfolgt die Zustellung eingehener Nachrichten mit einer bis zu 60-minütigen Verzögerung.
Diese Beschreibung erscheint auf den ersten Blick auf einen einfach zu lösenden Fehler hinzudeuten. Bei genauer Betrachtung zeigt sich aber, dass es sich um ein schwerwiegendes Problem innerhalb der Exchange Server-Plattform handelt.
Im Vorfeld wurde, so die Aussage des Kunden, die IT-Infrastruktur durch eine Krypto-Attacke kompromittiert. Im Rahmen der ausgeführten Wiederherstellungsmassnahmen wurde, so der Anschein, ein Domain Controller auf einen älteren Stand zurückgesetzt. Zu dieser Maßnahme fehlen leider detaillierte Informationen.
Laut Active Directory Konfigurationspartition besteht die Exchange Server Organisation aus insgesamt 11 Exchange Server Systemen, die sich wie folgt aufteilen:
In der Realität der Serverlandschaft in der lokalen IT-Infrastruktur sieht es allerdings anders aus:
Die Ressourcen der aktuell betriebenen beiden Exchange Server 2016 Systeme:
Weitere Fakten:
In der beschriebene Exchange Server Plattform kommen unterschiedliche Probleme zusammen. Das beschriebene Fehlerbild der verzögerten Nachrichtenzustellung hängt weniger mit der eklatante Fehlkonfiguration der Exchange Organisation zusammen, als mit dem schlechten Aufbau der IT-Hardware. Hier kommen mehrere Punkte zusammen:
Die Probleme hinsichtlich der Leistungsdefizite der beiden Exchange Server 2016 Systeme hätten bereits im Vorfeld mit einer einfachen Systemüberwachung des Betriebssystems erkannt werden können. Bei der Konfiguration des Arbeitsspeicher für die Systeme standen die Einschränkungen der Hypervisor-Hostsysteme im Vordergrund. Die realen Anforderungen von Betriebssystem, Exchange Server 2016, Endpunkt-Sicherheitslösung und anderer installierter Komponenten, fanden keinen Anwendung. Insbesondere wurden auch die internen Anforderungen von Exchange Server 2016 beim Betrieb einer DAG, in Kombination mit der Managed Availability, nicht berücksichtigt.
Mit dieser Hardware-Konfiguration kann der Programmcode von Exchange Server nicht korrekt arbeiten. Die im Verhältnis recht hohe Zahl an vorhandenen Prozessorkernen führt nicht zu einer Beschleunigung von Exchange Server. Da gleichzeitig nicht genug freier Arbeitsspeicher zur Verfügung steht und die Disk I/O-Leistung zu gering ist, kommt es zwangsläufig zu einer verzögerten Ausführung des Codes und damit automatisch zu einer verzögerten Verarbeitung von Nachrichten.
Für diese Hardware-Plattform sind zu viele iSCSI-Volumes in Betrieb und zu viele Postfachdatenbanken je Server eingebunden. Bei 40 Datenbanken mit je einer aktiven und einer passiven Kopie werden insgesamt 80 Datenbankkopien auf den iSCSI-Zielen betrieben. Trotz der starken Reduzierung der Disk I/O-Anforderungen in Exchange Server 2016, im Vergleich zu den Vorversionen, kann ein iSCSI-NAS die permanent erforderliche Leistung nicht liefern. Für ein Caching von Postfachinformationen steht nicht genug Arbeitsspeicher zur Verfügung. Exchange Server muss die Daten direkt auf Disk schreiben, um die Daten sicher zu persistieren.
Die fehlerhafte Konfiguration der Exchange Organisation im Active Directory trägt ihren ganz eigenen Teil zu den Problemen bei. Diese Konfiguration wird von allen Exchange Servern gelesen und für weitere Aktionen verwendet. Einige dieser Aktionen, die jeder einzelne, in Betrieb befindliche, Exchange Server durchführt, sind:
Exchange Server besteht aus viel mehr als nur der Verarbeitung von individuellen eingehende und ausgehenden Nachrichten. Die Funktion der Managed Availability nimmt einen nicht unerheblichen Teil des Leistungsbedarfs eines Exchange Servers in Anspruch. Exchange Server ist dafür ausgelegt, eine hochverfügbare Messaging-Plattform bereitzustellen. Hierzu dienen all die Funktionen, die unter der Haube ablaufen. Neben den Anforderungen an die Systemleistung von CPU und Arbeitsspeicher, schreiben alle Exchange Server Komponenten Protokolldateien auf Disk. Dies wird gerne ebenfalls vernachlässigt.
Die in der Active Directory Konfigurationspartition vorhandenen Exchange Server 2010 Systeme sind als Computerobjekte nicht mehr vorhanden. Dies deutet darauf hin, dass die Wiederherstellung der authoritativen AD-Datensicherung Ursache des Fehlers ist. Alternativ ist es auch möglich, dass diese Situation durch eine "Ad-Hoc-Deinstallation" von Exchange Server aus dem Active Directory eingetreten ist. Unter einer "Ad-Hoc-Deinstallation" versteht man das unmittelbare Löschen des AD-Computerobjektes eines Servers, auf dem Exchange Server installiert ist. Diese Art der "Deinstallation" von Exchange Server führt automatisch zu verwaisten Einträgen in der Konfigurationspartition und damit zu Folgeproblemen beim Betrieb der Exchange Organisation.
Führen Sie unter keinen Umständen eine "Ad-Hoc-Deinstallation" von Exchange Server durch.
Die Fehlersituation in der Exchange Server-Plattform bei diesem Kunden ist noch nicht abschließend gelöst. Die optimale Lösung erfordert zum einen die Bereinigung des Active Directory und zum anderen einen Umbau der Exchange Server Infrastruktur. Dies ist jedoch mit Investitionen verbunden.
Dieses Beispiel ist eine Ergänzung zu den in meinem Buch "Exchange Server 2019 - Das Handbuch für Administratoren" beschriebenen Beispielen ungünstiger Exchange Server Implementierungen.
Ich wünsche Ihnen viel Spaß und gute Laune mit Exchange Server.
Image by Pexels
Die Installation des Windows Features Active Directory Domains Services (AD DS) kann fehlschlagen.
Bei der Installation per PowerShell kommt es zu folgendem Fehler:
Install-WindowsFeature -Name AD-Domain-Services Install-WindowsFeature : The request to add or remove features on the specified server failed. The operation cannot be completed, because the server that you specified requires a restart. At line:1 char:1 + Install-WindowsFeature -Name AD-Domain-Services + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exce ption + FullyQualifiedErrorId : DISMAPI_Error__Failed_Reboot_Required,Microsoft.Windows.ServerManager.Commands.AddWindow sFeatureCommand Success Restart Needed Exit Code Feature Result ------- -------------- --------- -------------- False No Failed {}
Das ganze sieht erstmal danach aus, dass es sich um ein VMWare Problem handelt. "+ CategoryInfo: DeviceError: (@{Vhd=; Credent...Name=localhost}:PSObject) [Install-WindowsFeature], Exception" und das noch ein Reboot aussteht "because the server that you specified requires a restart."
Dem ist leider nicht so. Auch nach mehrfachem Neustart des Servers, bleibt es bei der gleichen Fehlermeldung.
Ein Blick ins EventLog zeigt, es gibt eine Abhängigkeit zwischen dem Dienst "DFS Namespace" und "Remote Registry".
Der "Remote Registry" Dienst konnte nicht gestartet werden, da dieser deaktiviert war.
Dieser Dienst war in der VM Vorlage deaktiviert.
Nach Umstellung auf Automatisch und einem Reboot ließ sich das Windows-Feature AD DS fehlerfrei installieren und der Server zum Domain Controller hochstufen.
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!
Mit Exchange Version 2013 wurden die sog. Modernen Öffentlichen Ordner (Modern Public Folder) eingeführt. In den vorherigen Produktversionen von Exchange Server erfolgte die Replikation der Öffentlichen Ordner mit einer eigenen Replikationstechnologie. Die öffentlichen Ordner bis einschließlich Exchange Server 2010 bezeichnet man als Legacy Public Folder oder als Öffentliche Ordner alter Bauart.
Im April 2017 habe ich bereits die Herausforderungen aufgezeigt, die bei der Migration von Öffentlichen Ordner innerhalb einer lokalen Exchange Organisation auftauchen. Dieser Blogartikel behandelt die Migration von Legacy Public Foldern zu Exchange Online.
Exchange Online unterstützt die direkte Migration von Legacy Public Foldern aus der lokalen Exchange Organisation zu Modern Public Foldern in Exchange Online. Da es sich hierbei technisch um eine Migration über Exchange Organisationsgrenzen hinweg (sog. Cross-Forest Migration) handelt, ergeben sich ganz eigene Herausforderungen.
Die Postfach-Migration aus einer lokalen Exchange Organisation hin zu Exchange Online erfordert immer die Konfiguration eines Migrationsendpunktes. Über diesen Endpunkt greift Exchange Online auf einen lokal installiert Exchange Server 2016 mit Hybrid Funktion zu.
Das nachfolgende Schaubild zeigt die Zugriffswege für die Migration von Postfächern und die Migration von Öffentlichen Ordnern von Exchange Server 2010 zu Exchange Online. Der Zugriffsweg zur die Migration von Exchange-Postfächern ist grün dargestellt, der für die Migration von Öffentlichen Ordner blau.
Exchange Server 2016 arbeitet bei der Migration von Postfächern als Proxy und nimmt in unserem Beispiel Verschiebeanforderungen von Exchange Online per Exchange Web Service (EWS) unter dem Hostnamen ews.varunagroup.de entgegen. Der Migrationsendpunkt für Exchange-Postfächer kann nicht für die Migration von Legacy Public Foldern verwendet werden. Die Migration der Legacy Public Foldern erfolgt über einen OutlookAnywhere Migrationsendpunkt vom Typ Public Folder. Ein Endpunkt dieses Typs kann im Exchange Admin Center nicht manuell erstellt werden. Die Erstellung erfolgt im Rahmen der Einrichtung des Migrationsbatchs mit Hilfe der Exchange Online Remote PowerShell. Für die Einrichtung des Migrationsendpunktes wird ein Benutzerkonto (Migrationskonto) im lokalen Active Directory benötigt, dass Organisationsadministrator ist.
Wenn Sie den externen OutlookAnywhere Zugriff auf Exchange Server 2010 bereits entfernt haben oder ihn noch nie in Betrieb hatten, so müssen Sie diesen Zugriff konfigurieren. Die externe Verfügbarkeit eines OutlookAnywhere Endpunktes ist für die Migration der Legacy Public Folder zu Exchange Online eine Voraussetzung.
Ein Wort zu E-Mail-aktivierten Öffentlichen Ordnern. E-Mail-aktivierte Öffentliche Ordner hatten in der Vergangenheit ihre Daseinsberechtigung, sind aber in der heutigen Zeit nicht mehr State-of-the-Art. Sie sollten darüber nachdenken, E-Mail-aktivierte Öffentliche Ordner durch eine zeitgemäße Lösung ersetzen. Wenn Sie die Öffentlichen Ordner Hierarchie zu Office 365 migrieren und anschließend zu etwas Neuem wechseln möchten, bringen Sie vielleicht die Funktionen von Microsoft Teams weiter.
Im Beispiel dieses Artikels gab es zu Beginn der Postfach-Migration in der Exchange Organisation E-Mail-aktivierte Öffentlichen Ordner, die mit Hilfe des Scripts Sync-MailPublicFolders.ps1 (Download) zu Office 365 manuell synchronisiert wurden. Dies war erforderlich, damit Anwender mit einem Postfach in Exchange Online E-Mail-Nachrichten an diese Öffentlichen Ordner senden konnten.
Als Teil der Vorbereitungen zur Migration der Öffentlichen Ordner zu Exchange Online wurden Funktionen der E-Mail-aktivierten Ordner in Freigegebene Postfächer migriert. Hierzu gehörte damit auch die Deaktivierung der E-Mail Funktionen der betroffenen Öffentlichen Ordner.
Der Ablauf einer Migration der Öffentlichen Ordner von Exchange Server 2010 zu Exchange Online ist im Grundsatz identisch zur Migration zu Exchange Server 2016 in einer lokalen Exchange Organisation. Der Hauptunterschied liegt in der Konfiguration des Migrationsendpunktes und des Remote-Migrationsbatches.
Die Schritte sind:
# Quota für die Migration ganz aufheben Set-OrganizationConfig -DefaultPublicFolderProhibitPostQuota Unlimited -DefaultPublicFolderIssueWarningQuota Unlimited
# Erste Public Folder Mailbox freigeben Set-Mailbox Mailbox1 -PublicFolder -IsExcludedFromServingHierarchy:$false # Default Public Folder Mailbox für Test-Benutzer setzen Set-Mailbox -Identity JohneDoe@varunagroup.de -DefaultPublicFolderMailbox Mailbox1
# Alle Public Folder Postfächer für den Hierarchie-Zugriff freigeben Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false # Öffentlichen Ordner Zugriff auf "local" setzen (aus Sicht der Office 365 E-Mail Postfächer) Set-OrganizationConfig -PublicFoldersEnabled Local
Wie bereits erwähnt, wurden alle E-Mail-aktivierten Ordner vor der Migration zu Exchange Online deaktiviert und das Skript zur Synchronisation der E-Mail-aktivierten Öffentlichen Ordner mit Office 365 ausgeführt. Leider führt das Skript nicht alle notwendigen Schritte aus, um die Informationen in Exchange Online korrekt zu entfernen.
Fehlermeldung im Migrationsbatch:
"Error: More than N mail public folders in Active Directory were not linked to any public folder during migration. Mail flow will stop working for these public folders after the migration is finalized. Please check whether these are important"
Sie müssen die nicht mehr vorhanden Ordner manuell mit Hilfe der Exchange Online Remote PowerShell löschen. Mit dem nachfolgenden Beispiel löschen Sie alle E-Mail aktivierten Öffentlichen Ordner, die mit Hilfe des Skriptes Sync-MailPublicFolders.ps1 in Exchange Online erstellt wurden.
# Löschung eines einzelnen ehemals E-Mail-aktivieren Öffentlichen Ordners in Exchange Online Get-MailPublicFolder 'My Mail Public Folder' | Remove-SyncMailPublicFolder # Löschung aller ehemals E-Mail-aktivierten Öffentlichen Ordner in Exchange Online Get-MailPublicFolder -ResultSize Unlimited | Remove-SyncMailPublicFolder
Die Migration von Legacy Public Foldern zu Exchange Online ist nicht schwer. Sie erfordert aber, dass die zu migrierende Hierarchie der Öffentlichen Ordner vorbereitet wird und Ordnernamen keinen unzulässigen Zeichen enthalten. Ebenso muss ein passender OutlookAnywhere Endpunkt aus dem Internet erreichbar sein. Ohne einen OutlookAnywhere Endpunkt und ohne ein berechtigtes Migrationskonto kann der Migrationsbatch von Exchange Online keine Daten kopieren.
Stellen Sie die E-Mail-Aktivierung von Öffentlichen Ordnern in Frage und suchen Sie modernere Lösungen. Eventuell notwendige Umzüge von E-Mail-Adressen müssen vor der Migration der Öffentlichen Ordner abgeschlossen sein.
Planen Sie für die Finalisierung der Migration genügend Zeit ein. Im direkten Vergleich zu lokale durchgeführten Modern Public Folder Migrationen benötigten Finalisierungen von Migrationen zu Exchange Online das Vierfache an Zeit. Bedenken Sie, dass nach einer Umstellung des Public Folder Zugriffes für die Postfachnutzer in Exchange Online es noch mehrere Stunden dauern kann, bis die Konfigurationsänderungen durch Outlook Clients genutzt werden.
Viel Spaß mit modernen Öffentlichen Ordnern.