ASDF - stock.adobe.com

Fehler in öffentlichen Ordnern in Microsoft Exchange beheben

Öffentliche Ordner sind seit Jahren ein wichtiges Instrument bei der Gruppenarbeit mit Exchange Server. Wir zeigen, wie Admins Fehler in öffentlichen Ordnern beheben.

Öffentliche Ordner sind seit Jahren in Microsoft Exchange Server ein fester Bestandteil. Auch in Exchange 2019 ist diese Form der Gruppenarbeit noch verfügbar. Wenn Unternehmen zu Office 365/Microsoft 365 migrieren, spielt die Stabilität der öffentlichen Ordner eine wichtige Rolle. Aus diesem Grund sollte vor einer Migration überprüft werden, ob die öffentlichen Ordner richtig funktionieren.

Microsoft stellt hierzu ein kostenloses PowerShell-Skript für die Exchange Management Shell zur Verfügung. Dieses kann für Exchange 2013/2016/2019 verwendet werden, um öffentliche Ordner und die dafür notwendige Infrastruktur zu überprüfen. Grundsätzlich ist das Tool ebenfalls mit Exchange 2010 einsetzbar, allerdings werden alle Tests erst ab Exchange 2013 durchgeführt. Das Skript testet in der aktuellen Version folgende Bereiche:

  • verwaiste ACLs

  • Zustand der MEPF-Objekte (Mail Enabled Public Folder)

  • Zustand der Dumpster-Ordner

  • Einhalten der Speichergrenzwerte

Das Skript behebt allerdings keine Fehler. Es werden nur Fehler und Tipps zur Fehlerbehebung angezeigt. Die Ausführung des Skriptes ist einfach, es ist weder eine Installation notwendig, noch müssen Anpassungen in Exchange vorgenommen werden. Das Skript wird in der Exchange Management Shell gestartet und listet Fehler in Protokolldateien auf.

Öffentliche Ordner in Exchange anlegen

Die Daten der öffentlichen Ordner werden in einem Postfach gespeichert, das für die öffentlichen Ordner extra angelegt werden muss. Das Postfach kann in Exchange 2016/2019 im Exchange Admin Center oder der Exchange Management Shell erstellt werden.

Im Exchange Admin Center ist der Bereich unter Öffentliche Ordner/Postfächer für öffentliche Ordner zu finden. Über das Plus-Symbol steht die Option Neues Postfach für öffentliche Ordner zur Verfügung. In der Exchange Management Shell wird New-Mailbox -PublicFolder -Name MasterHierarchy verwendet.

Wenn öffentliche Ordner umfassend genutzt werden, kommt es schnell zu fehlerhaften Konfigurationen, verwaisten Zugriffslisten und verschiedenen Einstellungen, die teilweise eine Migration zu einer neuen Exchange-Version oder zu Office 365/Microsoft 365 verhindern. Mit dem PowerShell-Skript Source Validation Script kann die Integrität der öffentlichen Ordner überprüft werden. Das Skript überprüft verwaiste Berechtigungen und fehlerhafte Daten bei der E-Mail-Aktivierung.

Öffentliche Ordner mit Source Validation Script überprüfen

Um das Skript in der eigenen Exchange-Organisation zu nutzen, muss man es zunächst herunterladen und auf einen Exchange Server in der Organisation kopieren. Das PowerShell-Skript muss in der Exchange Management Shell ausgeführt werden. Nach dem Start liest das Source Validation Script die Hierarchie der öffentlichen Ordner aus und speichert die Informationen in CSV-Dateien auf dem Datenträger.

Anschließend werden verschiedene Tests auf Basis der in den CSV-Dateien gespeicherten Informationen durchgeführt. Die Ergebnisse werden zusammen mit den auszuführenden Aktionen in einer Protokolldatei mit der Bezeichnung SourceSideValidations.[yyyyyMMdd_HHmm].log gespeichert.

Das Skript verwendet verschiedene, auch optionale Parameter zur Ausführung:

  • verifyMEPF – Überprüft E-Mail-aktivierte, öffentliche Ordner
  • checkLimits – Überprüft die Grenzwerte der öffentlichen Ordner
  • verifyDumpsterMapping – Überprüft die Dumpster-Ordner, die für die Wiederherstellung von Objekten aus öffentlichen Ordnern genutzt werden.
  • checkPermissions – Testet die Berechtigungen in den öffentlichen Ordnern
  • startAfresh – Gibt an, ob das Skript Informationen aus Dateien auf der Festplatte oder erneut aus der PF-Struktur lesen soll. Der Standardwert ist true. Das Skript liest die PF-Struktur und erstellt Protokolldateien auf der Festplatte. Geben Sie startAfresh:$false an, wenn die Skriptausführung unterbrochen wurde und an der Stelle wieder aufgenommen werden muss, an der das Skript unterbrochen wurde.

Um einen Standard-Test durchzuführen wird das Skript aus dem Pfad ohne Parameter gestartet:

.\SourceSideValidations.ps1

Abbildung 1: Öffentlichen Exchange-Ordner in einer Organisation überprüfen.
Abbildung 1: Öffentlichen Exchange-Ordner in einer Organisation überprüfen.

Durch Eingabe ohne weitere Paramter führt das Skript alle Tests durch. Sollen nur einzelne Tests durchgeführt werden, zum Beispiel die Überprüfung der Dumpster-Ordner, können die anderen Tests über die Parameter deaktiviert werden:

.\SourceSideValidations.ps1 -verifyMEPF $false -verifyDumpsterMapping $true -checkLimits $false -checkPermissions $false

Wurde das Skript abgebrochen oder ist es abgestürzt, kann man es an der Stelle fortführen, an der es abgestürzt ist:

.\SourceSideValidations.ps1 -startFresh:$false

Das muss bei der Ausführung des Skriptes beachtet werden

Die Skriptausführungszeit hängt von der Größe der bereitgestellten öffentlichen Ordner vor Ort ab. Bei größeren Bereitstellungen kann die Ausführung eines Skripts mehrere Stunden dauern. Aus diesem Grund sollte man im Rahmen der Migration von Exchange entsprechend Zeit einplanen.

Das Skript muss vom Quellserver in der lokalen Bereitstellung von öffentlichen Ordnern ausgeführt werden. Wenn öffentliche Ordner auf Exchange 2010 genutzt werden, muss man das Skript auf einem Server mit dieser Exchange-Version starten – auch wenn in der Umgebung Exchange 2013/2016-Server installiert sind.

Wenn die Umgebung öffentliche Ordner ab Exchange 2013 verwendet, kann das Skript problemlos auf Exchange 2013/2016/2019 ausgeführt werden. Die Skriptausgaben werden in eine Protokolldatei geschrieben, die im Ausführungsordner gespeichert wird. Der Name der Protokolldatei sieht zum Beispiel so aus:

SourceSideValidations.<Zeitstempel>.log

SourceSideValidations.20190923_08.log

Findet das Überprüfungsskript keine Fehler, wird das in der Protokolldatei entsprechend aufgeführt. Tauchen Fehler auf, sind diese ebenfalls in der Protokolldatei zu sehen und sollten vor einer Migration überprüft werden.

Fortsetzung des Inhalts unten

Erfahren Sie mehr über Collaboration-Software

ComputerWeekly.de

Close