Ö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. Show 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:
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 anlegenDie 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üfenUm 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:
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.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 werdenDie 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.
Themenstarter 5. Mai 2020 11:40
Guten Tag allerseits, ich bin neu hier und möchte mich erst einmal herzlich bei Frank für diese tolle und informative Seite bedanken. Und dann gleich eine kurze Beschreibung meines akuten Problems und der Umgebung: Wir haben Ende letzten Jahres eine Firma mit ca. 25 Mitarbeitern von SBS 2011 mit Exchange 2010 auf Server 2019 unter Hyper-V und Exchange 2019 migriert. Die Exchange-Konten wurden inklusive der öffentlichen Ordner mit dem Code-Two Exchange Migration Tool migriert. Nach einigen Startschwierigkeiten nach der Migration (z.B. unterschiedliche Zertifikatsfehler bei der Anmeldung mit Outlook am Exchange, sowie teils sehr hartnäckige Probleme die Exchange-Konten in iPhones anzulegen), sieht jetzt soweit alles ganz gut aus, bis auf den für mich völlig neuen Fehler, dass bei einigen, aber längst nicht allen, Outlook-Clients immer wieder sporadisch die öffentliche Ordner aus Outlook verschwinden. Sie sind dann einfach nicht mehr sichtbar. Neustart von Server und Clients hilft nicht. Nur wenn ein neues Outlook-Profil eingerichtet wird sind sie sofort wieder da, bis das Spiel dann irgendwann von vorne beginnt. Aber auch dort kann ich kein System erkennen, manchmal passiert es nach einem Tag, manchmal erst nach Wochen. Unter OWA sind die ÖO die ganze Zeit zu sehen. Betroffen sind Clients von Outlook 2010 bis 2019. Bei der großen Mehrzahl der Clients tritt das Problem aber nicht auf. Suchen im Netz hat mich bisher nicht wirklich weitergebracht, ich finde leider so gar keinen Lösungsansatz. Die ÖO werden in dieser Firma sehr exzessiv als Ablage genutzt, die Datenbank hat gut 200GB. Hierzu noch ein Punkt, den ich nicht recht einordnen kann: Im Exchange Admin Center unter Postfachnutzung wird mit einem roten Balken angezeigt, dass das Postfach der ÖO 208,66GB von 2GB (?) verwendet, obwohl alle Paramter auf "unlimited" gesetzt sind. Über Hinweise und Tips würde ich mich sehr freuen. Danke und Gruß Tom
Hallo Tom, hast du denn mal geschaut, ob auf den Benutzern, die das Problem haben, die PF Mailbox hinterlegt ist? get-mailbox <user>|select *public*Wenn nein, dann setz die mal. Wenn bei Neuanlage der Wert gesetzt wird und er irgendwann "verschwindet", dann muss irgendwas bei euch die Objekte anfassen. Gibts da ggf nen BES Server oder ähnliches? Weiterhin kannst du schauen, ob bei solchen Usern auf dem AD Objekt die Vererbung unterbrochen ist. Das würde auf Mitgliedschaft in administrativen Gruppen hindeuten und dann greift die RBAC ein und kann ggf solche Seiteneffekte auslösen. Gruß, Ich komme aus einer Zeit, in der aus einer Cloud noch Regen kam!
Themenstarter 12. Mai 2020 10:14
Hallo Monthy, vielen Dank für Deine Antwort und die konkreten Tips, die hören sich sehr interessant an. Ich werde das prüfen und das Resultat hier posten. Nochmals danke und Gruß Tom
@tome Hallo, ich kenne die beiden Punkte, die Du angesprochen hast. Das mit dem roten Balken für das Postfach für öffentliche Ordner habe ich vor gut zwei Jahren gesehen; auch bei uns steht die Begrenzung auf unlimited. Trotzdem der rote Balken, kein CU hat dies bisher behoben.Das zeitweilige Verschwinden der ÖO kenne ich auch, bisher habe ich keine nachhaltige Lösung gefunden, bin daher auch an einer interessiert, da die betreffenden User davon genervt sind und dann mich damit nerven.Was hast Du denn seitdem noch rausfinden können? Danke. raynor
Themenstarter 1. Juli 2020 13:00
@raynor Hallo, das mit dem roten Balken scheint eher kosmetisch zu sein, es läuft soweit unauffällig bei uns, trotz dieser Anzeige. Mit den ÖO hat sich noch nichts getan. Ich muss aber auch gestehen, dass ich den Tip von Monthy noch nicht umgesetzt habe, es kam immer was dazwischen. Tatsächlich steht die ÖO-Mailbox bei einigen betroffenen Usern auf "false", muss ich jetzt endlich mal umstellen, und dann weiter beobachten. Sollte es da Erkenntnisse geben poste ich sie hier. Andererseits haben wir jetzt wieder schon länger eine Phase, in der die ÖO nicht verschwunden sind. Ich kann weiter so gar kein System darin erkennen, es passiert von OL 2010 bis OL 2019 nach Lust und Laune. Unsere User haben sich auch so halbwegs daran gewöhnt, einige richten sich dann das neue Profil schon selber wieder ein (mit Signatur, die ja dann erstmal nicht zugewiesen ist). Falls es wieder heftiger wird, hatte ich schon überlegt als Workaround ein Auto-IT-Script zu schreiben, welches diese paar Klicks dann automatisch per Doppelklick erledigt. Falls es dazu kommt stelle ich es hier zur Verfügung. Gruß Tom
@TomE ich hatte genau das gleiche Problem wie du. Die öffentlichen Ordner funktionierten bei einigen und bei anderen waren sie Anfangs ganz kurz da und verschwanden dann nach 10 Sekunden. Im OWA hatte man aber Zugriff. Das lässt schon darauf schließen, dass ein Problem zwischen Client PC und Server besteht. Ich hab dann mal alles geprüft und festgestellt, dass das Problem, wie bei vielen anderen auch, am Autodiscover lag. Ich hab dann Autodiscover Adresse über die Shell korrekt angepasst und das Exchange Konto neu am Client PC eingerichtet. Danach hat alles funktioniert. Vielleicht hilft das schon weiter. Diese r Beitrag wurde geändert Vor 2 Jahren 2 mal von sven
@monthy Hallo, ich habe zur Zeit das gleiche Problem, zumindest gehe ich erstmal davon aus. get-mailbox <user>|select *public* Als Ergebnis von diesem Befehl bekomme ich folgendes:  Muss ich da noch was setzen? Und wenn ja, was? Gruß Ben
Hi Ben, das sollte eher so aussehen. Sprich der Wert "DefaultPublicFolderMailbox" muss gepflegt sein. Monthy Ich komme aus einer Zeit, in der aus einer Cloud noch Regen kam!
@monthy Vielen Dank, für die schnelle Antwort. ? Den Befehl Set-Mailbox -Identity "sakro" -DefaultPublicFolderMailbox \PublicHabe ich gefunden, aber muss ich den jetzt echt für alle User tippen?! Gruß Ben
Hallo, ich habe das gleiche Problem und kann mit dem SET Befehl nichts anfangen, da ich nicht weiß was rein muss wo ihr was ausgegraut habt. Angenommen mein Konto heißt J.Klaus, was muss ich da wo einsetzen? MfG Thunderford
Das ist im allgemeinen auch überflüssig, da wenn kein Wert per Mailbox gesetzt ist der org-wert gilt.
Ich habe jetzt den Reg-Key HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\"Name des Outlook Profils" exportiert und führe diese per Aufgabenplanung täglich zusammen. Unterhalb dieses Schlüssels stehen Einträge zu den Postfächern, die dieses Profil anzeigen soll, unter anderem auch die Öffentlichen Ordner. |
Exchange 2022 Öffentliche Ordner werden nicht angezeigt
zusammenhängende Posts
Urheberrechte © © 2024 frojeostern Inc.
