Im Hinblick auf das kommentde Support Ende von Exchange Server 2010 und das Ende des Mainstream-Supports von Exchange Server 2016 begegnen mir wieder vermehrt Fragen zur Migration von Öffentlichen Ordnern.
Die Fragen gliedern sich in die beiden Themenfelder Legacy Public Folder und Modern Public Folder. Von Legacy Public Foldern sprechen wir bei Öffentlichen Ordnern bis einschließlich Exchange Server 2010. Ab Exchange Server 2013 sprechen wir über Modern Public Folder.
Der Fokus dieses Artikels liegt bei den Öffentlichen Ordnern alter Bauart. Es scheint, dass noch zahlreiche Exchange Server 2007 und 2010 Organisationen mit Öffentlichen Ordnern in Betrieb sind und hier versucht wird, diese so schnell als möglich zu migrieren.
Hier liegt bereits der Denkfehler.
Bis einschließlich Exchange Server 2010 werden Öffentliche Ordner in einem separaten Datenbanktyp gespeichert, der sog. Public Folder Database. Diese Datenbank verfügt über einen eigenen Replikationsmechanismus, der völlig unabhängig von den Replikationsmechanismen für Postfachdatenbanken der unterschiedlichen Exchange Server Versionen läuft. Dieser Replikationsmechanismus ist seit der Erfindung der Öffentlichen Ordner nicht an die sich wandelnden Anforderungen hinsichtlich der zu replizierenden Datenmengen angepasst worden.
Ein weiterer Unterschied zu modernen Öffentlichen Ordnern liegt in der Verarbeitung der Public Folder Hierarchie und der Möglichkeit, Ordnerinhalte durch Repliken in mehreren Datenbanken zu speichern. Jeder Ordner verfügt immer über mindestens eine Replik. In einer Exchange Umgebung mit nur einer Datenbank für Öffentliche Ordner ist das der Normalfall und stellt uns noch nicht vor Herausforderungen.
Das folgende Diagramm zeigt das Replikationsdilemma der Legacy Public Folder. In diesem Beispiel gehören zur Exchange Organisation Exchange Server in Europa (EMEA) uund Asien (APAC). Die Hierarchie der Öffentlichen Ordner steht organisationsweit zur Verfügung. Die Ordner der Hierarchie sind mit ihren Repliken auf zwei Datenbanken verteilt.
Dieser Ansatz wurde gewählt, um Anwendern in Asien einen Zugriff mit möglichst niedriger Latenz zur Verfügung zu stellen. Dieses Modell lässt sich nun beliebig komplex ausweiten. Die häufigsten Gründe für die Nutzung mehrerer Public Folder Datenbanken sind:
Große Public Folder Datenbanken sind immer wieder der Grund für Replikationsprobleme und damit einhergehenden Datenverlusten. Ein weiterer Grund für Replikationsprobleme liegt in der Art der Replikation. Die Replikation erfolgt per SMTP-Nachrichten zwischen Exchange Serversystemen. Die Kommunikation besteht aus System- und Inhaltsnachrichten von fester Größe. Und hier ergeben sich die nächsten Herausforderungen für Replikation der Öffentlichen Ordner:
Diese Auflisting hat keinen Anspruch auf Vollständigkeit. Zu unterschiedlich sind die Betriebssituationen für Öffentliche Ordner. Dies bezieht sich nicht nur auf die Exchange Server Versionen, die im Einsatz sind, sondern auch auf das Alter und die Historie der Öffentlichen Ordner. Desto länger eine Öffentliche Ordner Hierarchie bereits in Betrieb ist, desto größer ist auch das Risiko von korrupten Altdaten. In der Vergangenheit und im täglichen Betrieb werden Sie höchstwahrscheinlich keine Probleme festgestellt haben. Für eine Migration jedoch, sich diese alten Daten ein Hindernis. Einer der häufigsten Gründe für Probleme mit alten Hierarchien sind verwaiste Einträge für die Zugriffsberechtigung (ACL). Hier kommt Ihnen PowerShell zur Hilfe.
Im Oktober erreicht Exchange Server 2010 das finale Supportende. Für Öffentliche Ordner alter Bauart gibt es dann keinen Support mehr. Wenn Sie auf Öffentliche Ordner nicht verzichten können, ist eine MIgration zu modernen Öffentlichen Ordner die einzige Alternative. Hier stehen Ihnen entweder Exchange Online oder Exchange Server 2016 zur Verfügung. Mit einer einzigen Public Folder Datenbank ist dies eine leichte und bestens dokumentierte Aufgabe.
Die große Herausforderung ist, wenn Ihre Öffentliche Ordner Hierarchie über mehr als eine Datenbank verteilt ist. Noch größer die Herausforderung, wenn sich diese Datenbanken auf Exchange Server 2007 und Exchange Server 2010 aufteilen. Ich empfehle Ihnen dringen, vor einer Migration zu modernen Öffentlichen Ordnern einen Versionsmix von 2010 und 2007 zu beseitigen.
Die Migration von Öffentlichen Ordnern und die damit einhergehenden Vorbereitungsarbeiten brauchen Zeit. Es ist nahezu unmöglich, solch eine MIgration zeitlich exakt vorauszuplanen. Auch mit einer guten Vorbereitung bleibt das Risiko von Fehlern, die erst bai der Ausführung der MIgration auftreten und damit die Migration verzögern.
Die notwendige Geduld und Ausdauer fehlt heutzutage meist. Ich kann an Sie nur appelieren, sich für die Migration ausreichend Zeit zu nehmen. Geben Sie jedem uneinsichtigen Projektmanager gerne meine Kontaktdaten.
Wenn sich in Ihrer Öffentlichen Ordner Hierarchie Repliken auf mehrere Datenbanken aufteilen, hilft der Public Folder Replication Report, um festzustellen, ob die Repliken über die gleiche Anzahl an Objekten verfügen.
Die wichtigsten Schritte für eine erfolgreiche Migration der Öffentlichen Ordner sind:
All diese Aktiviäten benötigen Zeit. Die Änderungen müssen zwischen Exchange Datenbanken repliziert werden. Ebenso dürfen Sie die Zeiten für Replikation von Änderungen im Active Directory nicht unterschätzen.
Durch die technischen Umstrukturieren bei Microsoft, insbesondere durch die Stilllegung der TechNet-Ressourcen, werden zahlreichen Quellen für Legacy Public Foldern in der Zukunft nicht mehr erreichbar sein. Ich empfehle Ihnen, sich die noch erreichbaren Quellen zu sichern, z.B. als Ausdruck in OneNote.
Hier sind einige Links zu weiteren Blogartikeln und anderen Ressourcen für Öffentliche Ordner
Viel Spaß mit Exchange!
In vielen Unternehmen werden noch Öffentliche Ordner alter Bauart, die sog. Legacy Public Folder, auf Exchange Server 2010 Systemen bereitgestellt. Oftmals sind die diese Ordnerstrukturen innerhalb der Öffentlichen Ordner Hierarchie über die Jahre unkontrolliert gewachsen. Dies nicht nur im Hinblick auf das Datenvolumen, sondern auch auf die Anzahl der Ordner und die Ordnertiefe in der Ordnerhierarchie. Aus diesen Gründen fürchten viele Unternehmen eine Migration der Öffentlichen Ordner zu einer modernen Version von Exchange Server oder zu Exchange Online.
Am 14. Januar 2020 ist das Support-Ende von Exchange Server 2010 erreicht. Bis zu diesem Termin sollten Sie vorhanden Öffentliche Ordner Hierarchien zu Modernen Öffentlichen Ordnern in Exchange Server 2016 oder zu Exchange Online migriert haben. Nach diesem Datum befinden sich Ihre Exchange Server 2010 Installationen in einem nicht unterstützten Betriebszustand und stellen ein Risiko für den sicheren Betrieb Ihrer IT-Plattform dar.
Vermeiden Sie die vollständige Migration aller Öffentlichen Ordner ohne eine Revision der Inhalte und Ordnerstrukturen. Die Migration hin zu modernen Öffentlichen Ordner in Exchange Online muss besonders vorbereitet werden.
Vermeiden Sie die vollständige Migration aller Öffentlichen Ordner ohne eine Revision der Inhalte und Ordnerstrukturen.
Die Migration hin zu modernen Öffentlichen Ordner in Exchange Online muss besonders vorbereitet werden.
Diese Vorbereitung der Öffentlichen Ordner muss folgenden Maßnahmen und Überlegungen berücksichtigen:
Mit einer Umstellung und Bereinigung der E-Mal-aktivierten Ordner stellen Sie eine sichere Zustellung der E-Mail-Nachrichten während der Migrations- und Finalisierungsphase der Öffentlichen Ordner sicher. Unabhängig davon, ob die die Öffentlichen Ordner zu Exchange Server 2016 oder zu Exchange Online migrieren, kommt es zu einem Pausieren der Zustellung. Nach der Fertigstellung werden wartende Nachrichten in die neue Betriebsumgebung der Öffentlichen Ordner umgeleitet und zugestellt. Dies ist für zeitkritische E-Mail-Nachrichten nicht akzeptabel.
Die Information über einen E-Mail-aktivierten Ordner wird nicht nur innerhalb der Öffentlichen Ordner-Hierarchie gespeichert. Zu einem E-Mail-aktivierten Ordner gehört auch ein entsprechendes AD-Objekt, das im MESO-Container gespeichert ist. Wenn die Berechtigung für Exchange Server auf diesen Container angepasst wurde wird das AD-Objekt nicht entfernt oder geändert. Bei einer Aufhebung der E-Mail-Aktivierung verbleibt das AD-Objekt im MESO-Container und sorgt bei einer Migration zu Exchange Online für Probleme. Dieser Fehler macht sich in einer reinen On-Premises-Umgebung nicht bemerkbar. Der Fehler schlummert im Untergrund und wartet darauf, entdeckt zu werden.
Die Bereinigung der Ordnerberechtigungen, hin zu Gruppen-basierten Berechtigungen führt zu einer Vereinheitlichung und Vereinfachung des Zugriffes. Bereits bei einem rein lokalen Betrieb der Öffentlichen Ordner profitieren Sie schon von dieser Umstellung. Wenn Sie jedoch eine Migration der Öffentlichen Ordner zu Exchange Online planen, ist diese Umstellung ein absolutes Muss. Eine Anpassung der Ordnerberechtigungen nach der Migration zu Exchange Online ist eine besondere Herausforderung. Solange die Ordnerhierarchie relativ flach ist und nur wenige Ordner enthält, werden Sie keine Probleme bei der rekursiven Anpassung von Ordnerberechtigungen haben.
Gerade in vertriebsorientierten Unternehmen sind den Jahren, seit Einführung der Öffentlichen Ordner, eigenständige Ordnerbäume gewachsen. Ich durfte mit einer Ordnerhierarchie, bestehend aus ~120.000 Ordner unterhalb eines Basisordners, nach der Migration zu Exchange Online besondere Erfahrungen machen.
Nachfolgend ein Beispiel für die Ordnerstruktur einer Vertriebsorganisation.
Wenn Sie in einer solchen Ordnerhierarchie die Berechtigungen per Remote PowerShell setzen möchten, werden Sie bei der Ausführung der Cmdlets in Probleme laufen.
Durch die besondere Betriebsart als SaaS-Angebot, gibt es klare Grenzen für die Verarbeitung von Cmdlets in einer Remote PowerShell-Session. Sie können maximal 120 destruktive Cmdlets je 60 Sekunden ausführen. Wenn Sie diesen Schwellenwert überschreiten, wird die Ausführung Ihrer Cmdlets durch sog. MicroDelays verzögert. Unter destruktiven Cmdlets versteht man Cmdlets, wie Einstellungen hinzufügen oder ändern, als Set-*, Remove-*, New-* oder Add-* Cmdlets.
Das Hinzufügen von Berechtigungen für Öffentliche Ordner erfolgt mit Hilfe des Cmdlets Add-PublicFolderClientPermission. Die Anpassung einer bestehenden Berechtigung besteht immer aus zwei Konfigurationsschritten, dem Entfernen der alten Berechtigung (Remove-PublicFolderClientPermission) und dem Hinzufügen der neuen Berechtigung.
Dieses Problem trifft Sie nicht nur bei Ausführung einer Remote-PowerShell-Sitzung, sondern auch bei der Anpassung der Berechtigungen über das Exchange Online Admin Center (EAC). Der Unterschied ist, dass das EAC Sie mit einer Success-Meldung in SIcherheit wiegt und Ihnen vorgaukelt, dass auf allen Ordnern die Berechtigungen gesetzt wurden. Die Realität hat gezeigt, dass die im Hintergrund ausgeführten PowerShell-Cmdlets in die Begrenzung laufen.
Alternativ können Sie die Berechtigungen auch mit Hilfe der Exchange Web Services (EWS) anpassen. Hierzu gibt es professionelle Lösungen am Markt. Jedoch greifen auch für den Zugriff per EWS Grenzwerte. Professionelle Programme versuchen durch Pausen bei der Ausführung das Erreichen der Grenzwerte zu vermeiden. Dies führt natürlich zu einer entsprechenden Laufzeit bei der Anpassung der Berechtigungen.
Daher ist meine Empfehlung, die Berechtigungen der Öffentlichen Ordner vor einer Migration zu Exchange Online zu bereinigen. Hierdurch stellen Sie sicher, dass Sie sich nur noch auf die Mitgliedschaft der Benutzerkonten in den entsprechenden Sicherheitsgruppen kümmern müssen.
Viel Spaß mit Öffentlichen Ordnern. Und vergessen Sie den Stichtag 14. Januar 2020 für das Support-Ende von Exchange Server 2010 nicht.
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.
Mit der Broschüre "Exchange Öffentliche Ordner - Migration verständlich erklärt" beginnt ein Reihe von Veröffentlichungen rund um das bevorstehende Supportende von Exchange Server 2010.
In dieser Broschüre erfahren Sie, wie Sie eine Öffentliche Ordner Hierarchie alter Bauart zu Exchange Server 2016 oder zu Exchange Online migrieren können.
Die Broschüre ist als gedrucktes kleines Handbuch oder als Kindle Version verfügbar.
Nicht vergessen Der Support für Exchange Server 2010 endet am 13. Oktober 2020.
Der IT-Arbeitsplatz und das Arbeitsumfeld von heute sind mit dem der Vergangenheit nicht mehr zu vergleichen. Auch ohne die starken Veränderungen der letzten Monate, die zu einer vermehrten Nutzung von Remote-Arbeit geführt haben, hat sich die tägliche Arbeit für IT-Administratoren stark verändert.
In der Vergangenheit gab es IT-Generalisten, die sich in zahlreichen Themenfelder gut auskannten, und IT-Spezialisten, die sich mit einem Produkt oder einer kleinen Produktgruppe sehr gut auskannten. Dies war in einer Zeit, in der Softwarelösungen nur in lokalen IT-Infrastrukturen betrieben wurden, vollkommen ausreichend.
Dies hat sich in den letzten 15 Jahren durch die Einführung und verstärkte Nutzung von Cloud-Diensten verändert. Diese Veränderung sorgt oft für einer persönliche Verunsicherung und schürt die Angst um den eigenen Arbeitsplatz.
Eine moderne IT-Infrastruktur besteht heute aus On-Premises und Cloud-Komponenten, die oftmals in einer komplexen Hybrid-Konfiguration miteinander verbunden sind. Anwender greifen mit unterschiedlichen Geräten von überall auf bereitgestellte Ressourcen des Unternehmens zu. Dieses breite Feld der Technologien und Zugriffswege erfordert ein umfassendes Wissen über die eingesetzten Komponenten. In der Zuständigkeit und Verwaltung dieser Komponenten verschwimmen die Grenzen immer mehr und haben besondere Anforderungen im Hinblick auf die fachliche Zertifizierung.
Vor zwei Jahren hat Microsoft einen neuen Zertifizierungsansatz eingeführt, um den rollenbasierten Bedürfnissen in einer modernen Arbeitswelt Rechnung zu tragen. Eine moderne Job-Rolle in der IT ist nicht mehr nur auf ein einzelnes Microsoft Produkt fokussiert, sondern erfordert Kenntnisse in einem Themenschwerpunkt und weiteren Produkten und Diensten.
Auf Microsoft Learn stehen Ihnen unterschiedliche Möglichkeiten zur Verfügung, um sich mit neuen Themen zu beschäftigen und neue Fertigkeiten zu erlernen. Ob Sie diese Materialen dazu nutzen, um sich auf eine Zertifizierungsprüfung vorzubereiten oder einfach nur etwas Neues erlernen möchten, ist Ihnen überlassen. Der entscheidende Vorteil ist, dass Sie das Lerntempo selbst festlegen.
Die Bezeichnungen der Microsoft Zertifizierungen haben schon immer einem Wandel unterlegen. Aber ganz unabhängig davon, welche Zertifizierung Sie erwerben, ab der ersten bestandenen Prüfung sind Sie MCP, ein Microsoft Certified Professional. Die erlangten Prüfungen geben dann Auskunft über die individuelle Qualifikation.
In den letzten Jahren gab es die Zertifizierung zum Microsoft Certified Solutions Administrator (MCSA) und die erweiterte Zertifizierung zum Microsoft Certified Solutions Engineer (MCSE).
Die aktuellen rollenbasierten Zertifizierungen basieren ebenfalls auf einer zweistufigen Qualifikation. In der ersten Stufe erlangen Sie die Zertifizierung im Associate-Level. Mit dieser Zertifizierung zeigen Sie, dass Sie sich in einem bestimmten Themenfeld, wie z.B. Microsoft 365 Messaging, sehr gut auskennen. Sie ist grob mit der Zertifizierung zum MCSA vergleichbar.
Das folgende Diagramm zeigt exemplarisch, für welche Themen Sie in der Prüfung MS-203 Ihr Wissen beweisen müssen. Mit bestandener Prüfung erhalten Sie die Zertifizierung zum Microsoft 365 Certified Messaging Administrator Associate.
Informationen zum Selbststudium finden Sie bei Microsoft Learn. Wenn Ihnen das Selbststudium nicht zusagt, haben Sie auch die Möglichkeit, einen Kurs bei einem zertifizierten Microsoft Learning Partner zu buchen.
Wenn Sie sich unsicher fühlen, solch eine Prüfung abzulegen, können Sie auch mit einer Basis-Zertifizierung (Fundamentals) starten, die allerdings nicht zur Erlangung einer Expert-Zertifizierung berechtigt. Solch eine Prüfung dient der persönlichen Prüfung von Basiswissen.
Nach dem Bestehen einer Associate-Prüfung können Sie durch das Ablegen weiterer Prüfungen die Expert-Zertifizierung erlangen. Solch eine Zertifizierung erfordert immer mehrere Prüfungen.
Das folgende Diagramm verdeutlich dies für die Zertifizierung zum Microsoft 365 Certified Enterprise Administrator Expert.
Um diese Zertifizierung zu erreichen, müssen Sie sowohl die beiden Expert-Prüfungen MS-100 und MS-101, als auch mindestens eine der Microsoft 365 Associate-Prüfungen bestehen. Ob Sie nun aufgrund Ihrer Rolle im täglichen Arbeiten sich für weitere Themen zertifizieren möchten, liegt bei Ihnen. Die Zertifizierung zum Microsoft 365 Certified Teams Administrator Associate (MS-700) ist thematisch eine sehr gute Ergänzung.
Aktuell gibt es folgende Expert-Zertifizierungen:
Das Certification Handbook bietet Ihnen immer eine aktuelle Übersicht der verfügbaren Basis-, Associate-, Expert und Speciality-Zertifizierungen.
Neben den bereits erwähnten Expert-Zertifizierungen gibt es noch Speciality-Zertifizierungen. Hier belegen Sie, dass Sie im jeweiligen Themenfeld ein absoluter Spezialist sind. Aktuell gibt es Speciality-Zertifizierungen für Azure for SAP Workloads und Azure IoT Developer.
Ob Sie einer Microsoft Zertifizierung erlangen möchten liegt ganz bei Ihnen. Die Wichtigkeit solcher Zertifizierungen hängt sehr stark von der Region ab, in der Sie leben und arbeiten. In manchen Regionen ist eine Microsoft Zertifizierung, zusätzlich zu einer allgemeinen IT-Berufsausbildung, verpflichtend, in anderen wiederum optional.
Neben den beruflichen Anforderungen hilft solch eine Zertifizierung auch, dass eigene Wissen zu überprüfen. Jede bestandene Prüfung stärkt das Selbstvertrauen und damit automatisch hilfreich für jedes Personalgespräch über die berufliche Zukunft.
Ich möchte Ihnen Empfehlungen für Microsoft Zertifizierungen geben, mit denen Sie für Ihre persönliche berufliche Zukunft gut gewappnet sind.
Mit Microsoft Learn steht Ihnen eine einheitliche Plattform zur Verfügung, um ganz im eigenen Tempo zu lernen. Nutzen Sie die Microsoft Leanr Plattform und die Produktdokumentationen auf Microsoft Docs, um Ihr Wissen über Microsoft Produkte und Dienste auf Stand zu halten.
Das Certification Poster bietet Ihnen einen Schnellüberblick über die verfügbaren Zertifizierungen.
Ob Sie sich dazu entscheiden, eine Zertifizierungsprüfung abzulegen, ist ganz Ihnen überlassen. Meine Empfehlung ist: lassen Sie sich zertifizieren.
Der virtualisierte Betrieb von Exchange Server ist seit der Einführung von Hypervisor-Plattformen immer wieder Thema für Diskussionen. Oftmals werden diese Diskussionen sehr emotional geführt und die richtigen Argumente für und gegen solch einen Betrieb finden selten Gehör. Das ist meist dann der Fall, wenn das Motto 100% Virtualisierung ausgerufen wurde.
Unabhängig von der Exchange Server Produktversion gibt es für die Planung und den Betrieb virtualisierter Exchange Server einen wichtigen Grundsatz:
Die Anforderungen an Prozessor, Arbeitsspeicher und Datendurchsatz der Festplatten für virtualisierte Exchange Server sind identisch zu den Anforderungen eines Betriebs auf physischen Servern.
Von diesem Grundsatz wird in der Realität immer wieder abgewichen. Abweichung von diesem Grundsatz haben aber automatisch Auswirkungen auf den stabilen und sicheren Betrieb von Exchange Server und erhöhen zusätzlich das Betriebsrisiko.
Mit Exchange Server 2019 haben sich empfohlenen Betriebsparameter für einen stabilen Betrieb, im Vergleich zu den Vorversionen, stark verändert.
Die empfohlene Prozessor-Konfiguration sieht weiterhin eine 2-Sockel-Architektur, allerdings mit insgesamt bis zu 48 Prozessorkernen (Cores) vor. Für den Betrieb eines Exchange Servers mit Postfach-Rolle ist eine Arbeitsspeichergröße von 128GB und für einen Server mit Edge Transport-Rolle eine Arbeitsspeichergröße von 64GB empfohlen.
Ob für Ihre Exchange Server 2019 Umgebung diese empfohlenen Betriebsparameter sinnvoll oder ob andere Betriebsparameter notwendig sind, finden Sie mit Hilfe des Exchange Server 2019 Sizing Calculator heraus. Der Calculator basiert auf einer Excel-Datei, die für Exchange Server 2019 ab dem Kumulativen Update 2 Bestandteil der Exchange Server 2019 ISO-Datei ist. Für Exchange Server 2016 können Sie die Excel-Datei direkt aus dem Microsoft Download Center herunterladen.
Die Virtualisierung von Exchange Server 2019 ist, wenn Sie sich nur an den Empfehlungen der Online Dokumentation orientieren, eine Herausforderung. Sie werden zu recht einwenden, dass niemand diesen Empfehlungen folgt, um Exchange Server 2019 produktiv zu betreiben. Meine Gegenfrage ist aber automatisch: Warum folgen Sie diesen Empfehlungen nicht? Die Empfehlungen basieren auf den jahrelangen Erfahrungen der Exchange Produktgruppe mit dem Betrieb von Exchange Server 2019 in großen und hochverfügbaren Umgebungen.
An dieser Stelle sei auch noch einmal darauf hingewiesen, was das Produkt Exchange Server ist:
Exchange Server ist eine Softwarelösung zur hochverfügbaren und sicheren Bereitstellung einer Massaging-Plattform für Clients und weitere Applikationen.
Vor dem Hintergrund der Empfehlungen für die Prozessor- und Arbeitsspeicherkonfiguration ist eine Virtualisierung von Exchange Server 2019 nicht immer sinnvoll. Wenn Sie eine Datenbankverfügbarkeitsgruppe (DAG) mit der Mindestanforderung von vier Mitgliedsservern konfigurieren, benötigen Sie auch mindestens vier Hypervisor-Host-Systeme. Der gleichzeitige produktive Betrieb von zwei Exchange Servern auf einem Host-System stellt ein beträchtliches Betriebsrisiko dar und ist im Regelbetrieb zu vermeiden.
Für den empfohlenen Betrieb des Exchange Server Gast-Systems müssen Sie in der Hypervisor-Plattform mit fest reservierten Ressourcen für Prozessor und Arbeitsspeicher arbeiten. Sie können bei der CPU-Ressourcenzuweisung zwar ein Verhältnis von 1:2 (pCore : vCore) konfigurieren, jedoch ist dies nur dann sinnvoll, wenn Sie sowohl die CPU-Auslastung des Gast-Systems, als auch des Host-Systems lückelos überwachen. Sobald auf dem Host-System weitere virtuelle Systeme betrieben werden, die eine hohe CPU-Last erzeugen, geht dies automatisch zu Lasten des Exchange Server-Systems.
Bedenken Sie bei der Konfiguration der Ressourcen immer, dass eine auf einem Windows Server betriebene Applikation immer genau die Ressourcen sieht, die das Betriebssystem meldet. Ist ein Server-System mit 24 vCores und 128GB Arbeitsspeicher konfiguriert, so nimmt die Applikation diese Ressourcen auch in Anspruch. Stehen diese Ressourcen bei einer dynamischen Zuweisung durch das Host-System nicht unmittelbar zur Verfügung, kommt es zu spürbaren Leistungsproblemen und zu Appkilationsfehlern.
Neben den Hypervisor-Herausforderungen für CPU-Cores und Arbeitsspeicher ergeben sich ebenso Herausforderungen für die Anbindung der notwendigen Speichermedien. Idealerweise verfügt das Gast-System für Exchange Server 2019 über nur ein, per Laufwerksbuchstaben eingebundenes Volume für das Betriebssystem und die Exchange Server Programmdateien. Alle weiteren Volumes zur Speicherung der Postfachdatenbanken und Protokolldateien werden über Mountpoints eingebunden. Je nach Anzahl der benötigten Volumes und der verwendeten Technologie zur Bereitstellung von Volumes in der Hypervisor-Plattform, stoßen Sie hier an Grenzen. Erschwert wird diese Situation noch dadurch, dass der hochverfügbare Betrieb einer DAG die Nutzung der AutoReseed-Funktion von Exchange Server vorsieht. Die AutoReseed-Funktion erfordert die Einbindung weiterer Volumes durch die Hypervisor-Plattform in das Gast-System.
Die Bereitstellung von leistungsstarkem Datenspeicher ist der neuralgische Punkt einer virtualisierten Exchange Server-Plattform. Für die Bereitstellung des erforderlichen Datenspeichers bieten Ihnen zahlreiche Hersteller die phantasievollsten Lösungen an. In den meisten Fällen handelt es sich um Lösungen, die eine Ersparnis des benötigten Gesamtvolumens für Exchange Server Postfachdatenbanken und Protokolldateien versprechen. Oftmals wird dies durch eine Form der Deduplizierung für die Postfachdatenbanken und Protkolldateien erreicht.
In solchen einem Fall muss Ihnen bewusst sein, dass Sie das Feld eines unterstützen Betriebes von Exchange Server 2019 verlassen. Sie nehmen Exchange Server eine der wichtigsten Funktionen für den Fall eines Desaster, die Datenbankportierbarkeit.
Jede weitere Technologieebene im Betrieb Ihrer Exchange Server-Plattform erhöht die Komplexität und die Zahl der möglichen Fehlerquellen. Hinzu kommt, dass Sie solch einen extern angebunden Datenspeicher immer redundant betreiben müssen, um das allgemeine Betriebsrisiko der Plattform zu minimieren. Bedenken Sie in diesem Zusammenhang auch, dass das Exchange Server Produktteam klassische HDD-Datenträger für die Speicherung von Datendateien empfiehlt, da SSD-Laufwerke nicht die notwendige Zuverlässigkeit und Robustheit aufweisen.
Mit Exchange Server 2019 wurde die Funktion der MetaCache-Datenbank (MCDB) eingeführt. Die Aufgabe der MCDB ist die Beschleunigung des Datenzugriffs auf häufig genutzte Postfachinformationen. Für den optionalen Betrieb einer DAG mit aktivierter MCDB-Funktion sind einige Voraussetzungen zu erfüllen:
Beim Betrieb einer Exchange Server Plattform mit physikalischen Servern verwenden Sie idealerweise passende M.2 SSD-Laufwerke, die direkt innerhalb des Servers verbaut sind. Auf diese Weise stehen Ihnen mehr Standardsteckplätze für die HDD-Laufwerke der Daten-Volumes zur Verfügung.
Aber wie können Sie von den Vorteilen der MCDB bei einem virtualisierten Betrieb von Exchange Server profitieren?
Wie bereits erwähnt, basiert die Nutzung der MCDB-Funktion auf SSD-Datenträgern. Bei einem Betrieb in einer Hypervisor-Plattform sind immer zusätzlichen Technologieebenen zwischen dem Betriebssystem und dem eigentlichen Datenspeicher, die den Geschwindigkeitsvorteilen einer direkten SSD-Anbindung in einem physikalischen Server entgegenstehen.
In einer Hypervisor-Plattform ist der Betrieb einer MCDB-Konfiguration nicht sinnvoll. Die zusätzlichen Laufwerke, insofern Sie als SSD-Laufwerke bereitgestellt werden können, erhöhen nochtmals die Komplexität der Plattform und erzeugen mit ihren Disk-I/O zusätzliche CPU-Last auf dem Host-System. Damit steigt das Risiko einer Verlangsamung des Datenzugriffs, sobald auf dem gleichen Host-System andere Applikationen mit hohen Systemanforderungen betrieben werden.
Daher ist meine Empfehlung, die MCDB-Funktion von Exchange Server 2019 nur beim Betrieb mit physikalischen Servern zu nutzen.
Der zu Exchange Server 2019 gehörende Role Requirements Calculator unterstützt Sie auch bei der Planung einer MCDB-Implementierung.
Wenn Sie einen virtualisierten Betrieb von Exchange Server 2019 planen, beachten Sie bitte immer die Empfehlungen der Exchange Server Produktgruppe in der Online Dokumentation. Diese Empfehlungen gründen auf den Erfahrungen im täglichen Betrieb von Exchange Server und den Exchange Server Supportfällen, basierend auf sehr individuellen Exchange Server Betriebsarten in Kundenumgebungen.
Achten Sie bei der Virtualisierung von Exchange Server 2019 auf eine möglichst einfache und standardisierte Implementierung. Jede zusätzliche Technologieebene erhöht nicht nur die Komplexität des Betriebs, sondern ist immer auch eine zusätzliche Fehlerdomäne. Vertrauen Sie nicht auf die Versprechen für vermeintlich leistungssteigernde Speicherlösungen für Ihre Exchange Server Systeme, die gerne von Systemhäusern als Allheilmittel angeboten werden.
Der Einsatz der MetaCache-Datenbank ist nur auf physikalischen Servern sinnvoll. Nur dort bietet die MCDB den gewünschten Geschwindigkeitsvorteil als Cache-Speicher zwischen Applikation und den Postfachdatenbanken.
Und vergessen Sie nicht, die Hochverfügbarkeit der Exchange Server 2019 erfolgt, wie bei allen modernen Exchange Server Versionen, auf Applikationsebene.
Und wenn Sie den Betrieb einer Einzelserverinstallation von Exchange Server 2019 planen, so möchte ich Ihnen den Wechsel zu Microsoft 365 und Exchange Online ans Herz legen.
Viel Spaß mit Exchange Server 2019.
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!