DumpRUSUser
DumpRUSUser ist ein Auswerteskripte, welches alle Exchange Empfänger im Active Directory bezüglich der konfigurierten Empfängerrichtlinien abgleicht. Das Ergebnis kann für folgende Zwecke heran gezogen werden.
- Aufräumen von "Inaktiven" Richtlinien
Es kann durchaus sein, dass es Richtlinien in ihrer Organisation gibt, die bei keinen Benutzer zur Anwendung kommen. Besonders nach einer Migration von Exchange 5.5, bei der für jeden Standort eine Richtlinie erstellt wird, ist dies der Fall. Eine inaktive Richtlinie können Sie gefahrlos löschen (Ausnahme: Konfiguration von autoritativen Domains) - Users ohne RUS
Weiterhin kann das Ergebnis helfen, all die Benutzer zu finden, die nicht mehr durch den RUS verarbeitet werden. - "Falsche primäre Adresse"
Sie können bei einem Objekt, welches durch den RUS verarbeitet wird, manuell die primäre Adresse ändern. Wenn Der RUS diese Objekt später erneut bearbeitet, dann wird die primäre Adresse aber wieder zurück gesetzt. Das ist insbesondere bei der Migration nach Exchange 2007 der Fall. Das Skript meldet, wenn primäre Adresse von den Einstellungen im RUS abweichen, da Exchange 2007 dies verändern würde ! - Orphane Richtlinien
Es kann sein, dass bei Objekten noch GUIDs von Richtlinien eingetragen sind, die es schon nicht mehr gibt. Dies "sollte" eigentlich nicht passieren aber ist ein Hinweis, dass Sie eine Richtlinie gelöscht haben aber der RUS diese Objekte noch nicht auf die nun gültige Richtlinien umgeschrieben hat. Ein "Rebuild Now" hilft hier meistens.
Alle Skripte sind Muster ohne jede Gewährleistung oder Funktionsgarantie. Für Schäden bin ich nicht verantwortlich. Achten Sie auf Zeilenumbrüche bei der Übernahme.
So funktioniert es
DumpRUSUser liest alle Empfänger im Forrest und die dazugehören Empfängerrichtlinien aus. Dann sucht DumpRUSUser die Übereinstellungen, da jedes Richtlinie eine GUID hat und umgekehrt bei jedem Empfänger die Richtlinien hinterlegt sind. Hier am Beispiel eines Benutzers.
Das Feld mxExchPoliciesIncluded enthält unter anderem die GUID {E1D7CFE9-8804-4259-BADB-8CFBE0C9D34C}. Genau hierzu passend gibt es eine Empfängerrichtlinie RUSTest mit dieser ObjectGUID:
Natürlich ist die binäre Schreibweise abweichend von der Schreibweise als String, aber doch auflösbar. Hier das Schema
Die Richtlinie mit der GUI {26491CFC-9E50-4857-861B-0CB8DF22B5D7} gibt es allerdings nicht, da Sie nur beschreibt, dass diese Objekt durch den RUS verwaltet wird. Es ist eine vordefinierte GUID und in allen Umgebungen vorhanden. Wenn diese GUID im Feld "msExchPolciesExluded enthalten ist, wird dieser Empfänger nicht mehr durch den RUS versorgt (Siehe auch Empfängerrichtlinien)
Und mit diesem Wissen ausgestattet prüft das Script die Konsistenz dieser Einträgt, d.h. es macht folgendes:
- Einlesen der User
Zuerst werden per ADO alle Objekte mit dem dem LDAP-Filter "mailnickname=*" eingelesen. Dieser Schritt kann sehr viel Speicher belegen ! Optional können Sie diese Daten mit in die XML-Datei schreiben lassen. Diese Funktion ist aber per Default deaktiviert, da die XML-Datei sehr groß werden kann (ca. 1 Megabyte/500 Objekte) - Aufzeichnen der beim Benutzer eingetragenen Richtlinien.
Dann werden die Einträge aus "msExchPoliciesIncluded" und "msExchPoliciesExcluded" ausgelesen und in einem Dictionaryobject gespeichert. Für jede GUID gibt es dann ein Eintrag dessen Wert die Anzahl der vorkommen sind. - Auslesen der konfigurierten Richtlinien
Dann werden alle Richtlinien aus der Exchange Konfiguration ausgelesen. - Abgleich mit den konfigurierten Richtlinien und Ausgabe
Nun werden aus dem Dictionary Objekt alle "gefundenen" GUIDs mit den gefunden Richtlinien verbunden und ausgegeben. Die nicht gefundenen Richtlinien werden als ORPHANED mit ausgeben.
Was so einfach ist liefert uns aber sehr hilfreiche Daten.
Diese Script ist aufgrund des für mich sehr hohen Nutzen
als Consultant nicht als kostenfreier Download erhältlich.
Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf
nicht public.
Konfiguration und Aufruf
Für aussagekräftige Ergebnisse müssen Sie alle Exchange Empfänger im Active Directory und zudem die Exchange Konfiguration lesen können.
Das Script benötigt nur sehr geringe Einstellungen vor dem Start, da es fast alle Daten dynamische ausliest. Die einzige Einstellung ist die Aktivierung oder Deaktivierung der Benutzerdetails. Für die Analyse werden von allen Benutzern umfangreiche Daten erhoben und in eine XML-Datei ausgegeben.
Wie so oft bei VBScript sollten Sie darauf achten, dass Sie dieses mit CSCRIPT aufrufen, da ansonsten jede normale Bildschirmausgabe mit "wscript.echo" als Messagebox zum Wegklicken erscheint. Das Skript prüft daher auch, ob der Aufruf mit CSCRIPT erfolgt ist und bricht ansonsten ab.
CSCRIPT DumpRUSUser.VBS
Sie können dann im Fenster sehr genau sehen, dass das StyleSheet als auch die XML und eine LOG-Datei mit dem Startzeitpunkt angelegt werden.
Die Laufzeit des Scripts hängt natürlich von der Performance ihres Clients, des Netzwerks und des Domänencontrollers ab. Eine Umgebung mit ca. 10.000 Usern dürfte aber in ca. 30 Minuten analysiert sein
Ausgabe
Das Script erzeugt wie viele andere Skripte eine XML-Datei samt passendem Stylesheet zur Anzeige im Internet Explorer:
Eine Weiterverarbeitung ist natürlich auch sehr einfach möglich.
Unklarheiten
Ich habe das Script nun schon bei mehreren Firmen eingesetzt aber einige Fragen sind dabei doch immer mal wieder "offen" geblieben. Vielleicht können Sie ja etwas licht ins Dunkel bringen:
- Orphaned Policies
Warum auch immer habe ich häufig Objekte, bei denen GUID im Feld "msExchPolicesIncluded" stehen, die es im gesamten Forrest nicht mehr gibt. Ich kann mir nur vorstellen, dass es sich mal um früher vorhandene Richtlinien handelt, die mittlerweile gelöscht wurden. Normalerweise erkennt der RUS dies und stempelt die betroffenen Objekte neu. Allerdings macht er das nicht, wenn die Objekte zwischenzeitlich vom RUS ausgeschlossen wurden. - Mehrfache Policies
Auch in dem Beispiel oben sieht man recht gut, dass die Richtlinie {E1D7CFE9-8804-4259-BADB-8CFBE0C9D34C} zweimal enthalten ist. Warum kann ich bislang nicht sagen. Im Ergebnis bedeutet dies aber, dass die ausgegebene Anzahl in der XML-Datei natürlich höher ist, da ich bislang solche doppelten Einträge nicht gesondert behandle.
Damit ist natürlich auch die Frage verbunden, warum die Felder zwei GUID durch Komma getrennt enthalten, wo das Feld doch auch so mehrfach vorkommen kann.
Insofern sind die Aussagen natürlich "unter Vorbehalt". Wenn natürlich eine Richtlinie keine Objekte mehr hat, dann ist Sie ganz sicher "überflüssig" für den aktuellen Betrieb.
