Exchange 2007 RUS

Achtung:
Seit Exchange 2010 gibt es das Commandlet Update-Recipient, welche in Verbindung mit Get-USNChanges flexibler kombiniert werden kann.

Wie sie auf Exchange RUS und E2K7 Empfängermanagement sicher schon gelesen haben, gibt es seit Exchange 2007 keinen RUS mehr. Während Sie also früher einfach per LDAP ein paar Felder gefüllt haben (z.B. Mailnickname, HomeMDB und Mail) und der RUS auf dem Server dann die restlichen Felder nach einiger Zeit ergänzt hat, so müssen Sie bei Exchange 2007 nu komplett selbst dafür sorgen, die Felder alle richtig zu setzen. Natürlich helfen ihnen dabei die Powershell Commandlets zu Exchange und auch die Exchange 2007 Management Shell macht alles richtig, aber was ist mit all den anderen Tools ?

Achtung:
Beim ersten Durchlauf verarbeitet alle Benutzer auf Exchange 2007. Das ist eigentlich kein Problem., da die Durchsetzung der Richtlinien schon erfolgt ist. Es kann aber trotzdem sein, dass die Proxy-Adressen der Personen wieder "korrigiert" werden.
Lösung: Entweder die Adressen sichern oder E2K7RUS im "Single Step"-Mode laufen lassen. Hierbei stoppt das Skript, wenn es eine Änderung der Proxy-Adressen erkannt hat. Sie können dann Abbrechen, die Konfiguration anpassen und die Einstellung wieder zurück setzen. Oder die Adressen vorher exportieren (153028 XADM: How to Export Multiple (Secondary) E-Mail Addresses und 922258 How to use a VBScript to write proxy addresses to an Ldifde.exe-compatible import file in Exchange Server 2003)

Das Problem

Wenn Sie heute z.B. eine Provisioning Anwendung haben, die ohne Rücksicht auf Exchange 2007 einfach per LDAP die Felder beschreibt, dann kann das zu ernsthaften Problemen führen. Auch die Konfiguration von Empfängern über die Exchange 2003 Snapins der MMC hinterlassen manchmal unvollständige Objekte. Nutzen sie doch einfach mal CheckExObjects um "defekte" oder unvollständige Objekte zu finden. Sie werden erstaunt sein.

Bislang war die Antwort von Microsoft hier recht einfach: Der Administrator sollte einfach folgendes Befehle immer mal wieder ausführen:

Get-EmailAddressPolicy | Update-EmailAddressPolicy
Get-AddressList | Update-AddressList
Get-GlobalAddressList | Update-GlobalAddressList

Diese Commandlets holen sich nacheinander alle Adresslisten, Empfängerrichtlinien und globale Adresslisten und starten einen vollständigen Durchlauf der Empfängerprüfung und Korrektur. Diese Verfahren mag funktionieren, aber hat doch einige Einschränkungen. die drei größten Probleme sind:

Mit Exchange 2007 SP1 hat Microsoft aber das "SET-MAILBOX"- Commandlet erweitert. Denn in gemischten Umgebungen passiert es gerne, dass ein Administrator ein Konto mit den Exchange 2003 MMC Tools auf Exchange 2007 anlegt und das Postfach ein "Legacy Postfach" ist anstelle eines Benutzerpostfachs (User Mailbox). Hier kann man manuell mit folgenden Zeilen sich behelfen:

get-mailbox | set-mailbox -applymandantoryproperties

Aber auch das ist natürlich keine dauerhafte Lösung.

Allerdings werden somit nur die Konten bearbeitet, die wirklich auch auf Exchange 2007 sind. In einer gemischten Umgebung muss der Exchange 2000/2003 RUS also weiter aktiv bleiben. E2K/RUS kann also den Exchange 2000/2003 RUS nicht komplett ersetzen.

Eine weitere Fragestellung kann mit E2K7RUS gleich mit erschlagen werden. Viele Firmen hätten gerne nach dem Anlegen eines Benutzers gleich einige weitere Parameter gesetzt. Über einen einfachen SET-MAILBOX können diese Änderungen ebenfalls anwenden z.B.

Sie können an dieser Stelle quasi alle eigenen Erweiterungen addieren, um Benutzer korrekt zu konfigurieren, selbst wenn ein Operator den Benutzer mit den alten MMC-Tools oder Drittprodukten anlegt. Allerdings sind diese Funktionen noch nicht im Code vorhanden und müssten entsprechend entwickelt bzw. eingebunden werden.

Die Lösung und die Funktionsweise

Das Comandet "SET-MAILBOX" hat mit Exchange 2007 SP1 den neuen Parameter "-ApplyMandatoryProperties" bekommen. Damit kann der Administrator eine einzelne Mailbox gezielt "updaten". Das Problem hierbei ist nur, dass auch dieses Comandlet keine Ahnung hat, welche Objekte nun neu oder geändert wurden. Das gleiche gilt auch für Verteiler, Kontakte und andere Exchange Objekte

Genau diese Logik liefert nun E2K7RUS.PS1 mit. An der Endung erkennen Sie schon, dass es sich um ein Powershell Skript handelt, welches man z.B. auf einem Server mit den Exchange 2007 Management Tools in der Exchange Laufzeitumgebung starten muss. Grob lässt sich folgendes Bild als Flussdiagramm zeichnen:

Flussdiagramm 

Die Funktion ist als ganz einfach umschrieben: Das Skript selbst wird aktuell per Windows Taskplaner regelmäßig mit einem Konto gestartet, welches die notwendigen Exchange Berechtigungen (Mitglied von "Exchange Recipient Administrator") hat und aus der Konfigurationsdatei auch die USN des zuletzt bearbeiteten Objekts ausliest.

Fehlerverarbeitung
Das Skript E2K7RUS bleibt im Gegensatz zum Exchange 2000/2003 RUS nicht bei Fehlern am Objekt hängen. Fehler werden im Eventlog protokolliert und Sie müssen sich selbst darum kümmern. E2K7RUS verarbeitet diese Objekte erst wieder, wenn sich die USN erneut geändert hat.

Wenn Sie daher Exchange 2007 im Einsatz haben und mit einer fremden Anwendung die Exchange Empfänger in ihrer Organisation pflegen, dann reicht für die Neuanlage eines neuen Benutzers das Füllen der folgenden Werte:

  1. AD-Benutzer per LDAP, MMC o.ä. anlegen
    Die benötigen immer erst einen Active Directory Benutzer, um daran dann die Postfachdaten abzulegen.
  2. ExchangeHomeServer mit dem DN des Postfachservers füllen
    Diese Feld benennt den Server, auf dem das Postfach des Anwenders liegt.
  3. HomeMDB mit dem DN der Datenbank füllen
    Dieses Feld teilt allen Exchange Diensten mit, wo sie das Postfach suchen müssen-
  4. MailNickname entsprechend der Namenskonvention anlegen
    Der Alias ist ein Schlüsselfeld, damit Exchange den Benutzer überhaupt als gültig erkennt
  5. ExchangeMailboxGUID mit einer zufälligen GUID füllen
    Das Feld wurde bei Exchange 2000/2003 beim ersten Zugriff des Users durch den Store gefüllt.

Der erste Durchlauf von "SET-MAILBOX -ApplyMandatoryProperties" erledigt dann den Rest, um einen vollwertigen Benutzer daraus zu machen. Natürlich können Sie auch weitere Einstellungen (POP3, OWA, Quota etc.) vornehmen. Auch für die anderen Objekte (Verteiler, Kontakte, öffentliche Ordner) muss das Skript die entsprechenden Daten anpassen.

Download und Konfiguration

E2K7RUS ist ein Skript, welches nur in ganz speziellen Umgebungen sinnvoll eingesetzt werden kann. Es ist kein Skript für jede Umgebung und kann auch großen Schaden anrichten. Daher überzeuge ich mich lieber selbst von dem geplanten Einsatzzweck.
Informationen, warum diese Skripte nicht öffentlich sind, finden Sie auf nicht public.

Analog zum Exchange 2000/2003 RUS muss natürlich auch ein Skript, welches einen RUS nachbildet, konfiguriert werden. Leider sind die in Exchange 2000/2003 vorhandenen Konfigurationscontainer in einer reinen Exchange 2007 Umgebung nicht mehr vorhanden. Aber irgendwo muss das Skript die Einstellungen speichern. Hier bietet sich natürlich eine XML-Datei an.

XML Konfiguration

Die Konfiguration erfolgt über eine XML-Datei, die als Parameter in der Kommandozeile mit angegeben werden muss

<e2k7rus>
	<mode>confirm</mode>
	<dc>e2007</dc>
	<domain>dc=e2k7,dc=msxfaq,dc=net</domain>
	<lastusn>0</lastusn>
	<laststart></laststart>
	<lastend></lastend>
	<customscript></customscript>
</e2k7rus>

Die Parameter bedeuten im einzelnen

Sie können also problemlos mehrere XML-Dateien anlegen und mit eigenen Zeitplänen aufrufen. Die XML-Datei muss unbedingt als voll deklarierte Datei mit Pfad angegeben werden, damit diese am Ende auch gespeichert werden kann.

Aufruf: Einmal Update bitte

Das Skript muss unbedingt in einer Powershell MIT Exchange Erweiterungen gestartet werden.

Der Aufruf muss dann mit einem Benutzer erfolgen, der zumindest "Exchange recipient Admin" ist. Er muss zudem auf die Exchange Server zugreifen können, da auch Exchange 2007 immer noch auf den MSExchangeAL auf dem Server zugreift.

Hier sieht man den Aufruf von E2K7RUS auf meiner Testumgebung, bei der der Benutzer "Test" anscheinend eine nicht konforme Proxy-Adresse hat. Das Skript liest zuerst die USN des letzten Durchlaufs aus und sucht dann alle neueren Objekte. Für diese Objekte startet es den "SET-MAILBOX" um die Daten zu aktualisieren. 

E2K7 Rus Durchlauf

Das Skript wurde "interaktiv" in der Betriebsart "confirm" aufgerufen. Daher gibt es mir die alten ProxyAddresses und die neuen Adressen untereinander aus und fragt mich, ab es mit den anderen Benutzern weiter machen darf.

Den aktuelle Benutzer hat SET-MAILBOX aber schon geändert. Wen dies also "falsch" wäre, dann müsste ich nun inne halten und die Änderungen manuell wieder Rückgängig machen. Leider gibt "SET-MAILBOX -WhatIf" nicht aus, was es tun würde. man muss also SET-MAILBOX erst wirken lassen und danach die Änderungen vergleichen. Denkbar wäre aber, dass man die Änderungen natürlich gleich wieder zurückschreibt.

In der Betriebsart "confirm" kann der Administrator beim ersten Lauf Benutzer für Benutzer durchgehen und bekommt für Benutzer, die geändert werden (also vorher nicht mit den Richtlinien konform waren) die Rückfrage und kann eingreifen.

Protokollierung

Natürlich protokolliert E2K7RUS jede Aktion, die er tut. Über die Funktion "Start-Transcript" wird jede Aktion, die auf der Console landet, zusätzlich in eine Datei abgespeichert. 

Verzeichnisinhalt

Interessanter ist aber die Funktion des "Changelog", in dem E2K7RUS die Objekte protokolliert, welche beim Verarbeiten auch geändert wurden

Changelog

Im Skript selbst ist der Name der Datei als Konstante hinterlegt. Es ist also problemlos möglich, alles in eine Datei zu schreiben. Mit wenig Aufwand könnte man diese Meldungen sogar per SYSLOG an ein Meldungssystem senden.

Überwachung und Monitoring - Eventlog

Programme und Skripte im Hintergrund werden schnell vergessen. Daher hat es sich unter Windows eingebürgert, dass solche Programme Fehler und Warnungen aber auch Erfolgsmeldungen einfach im Eventlog hinterlassen. Mit der Powershell ist dies sehr einfach möglich, wobei im Gegensatz zu VBScript sogar die Quelle selbst definiert werden kann. Entsprechend schreibt das Skript abhängig von den Debug-Level den Fortschritt in das Eventlog, so dass eine zentrale Überwachung möglich ist.

Eventlog Einträge

Folgende EventIDs kommen dabei zum Einsatz (Source ist immer E2K7RUS, Category ist immer "keine")

Typ ID Text Beschreibung
Information 0 E2K7RUS gestartet Zeigt den Start des Skripts an. Das Fehlen des Events kann z.B.: überwacht werden.
Information 1 E2K7RUS beendet Zeigt das Ende des Skripts an.
Error 2 XML not loaded Konnte XML-Datei nicht laden
Error 3 XML not saved Konnte XML-Datei mit letztem USN nicht speichern
Information 102 LastUSN=$lastUSN Zeigt an, welche LastUSN genutzt wird.
Information 103 Search done. Objects found $total Suche hat angegebene Anzahl neuer Objekte zurück gegeben.
Information 200 Processing Object:$adspath Anzeige des aktuell in Bearbeitung befindliches Objekt
Information 201 Skip System Mailbox Bestimmte Objekte werden nicht von E2K7RUS bearbeitet, wie z.B. die SystemMailboxen.
Error 202 Corrupt Item Prüfpunkt vor dem Aufruf von "Set-Mailbox"
Information 203 Start set-mailbox with: $nickname Prüfpunkt vor dem Aufruf von "Set-Mailbox"
Error 204 Error bei set-mailbox User: $nickname Error:$error Set-mailbox hat einen Fehler zurück gemeldet. Dies ist "normal", wenn es sich um eine Systemmailbox handelt. Ansonsten sollten Sie die Eventlog Meldung prüfen.
Information 205 set-mailbox executed with no error Aktualisierung des Objekts ist anscheinend ohne Fehler durchgelaufen
Information 206 New ProxyAddress $proxy2 Ausgabe der neu vergebenen ProxyAdressen
Information 207 MailboxGUID Fixed Ausgabe der Ergänzten MailboxGUID auf Postfächern. Siehe auch Fix-MailboxGuid und MailboxGUID
Information 300 Confirmation requested Wenn die Betriebsart "confirm" aktiv ist, dann zeigt dieser Eintrag an, dass der Administrator gefragt wurde, ob die Änderungen OK sind
Error 301 Confirmation rejected. - Stop processing Der Administrator hat die Verarbeitung abgebrochen
Information 302 Confirmation acceptet - continue processing Der Administrator hat die Verarbeitung fortgesetzt.

So können Sie die Funktion von E2K7RUS einfach mit handelsüblichen Überwachungsprogrammen (z.B.: MOM2005 etc. überprüfen.

Debugging

Wer noch mehr Debugging möchte, kann in der Powershell weitere Steuerungen einstellen. Per Default sind alle Debugoptionen aktiv. Suchen Sie nach folgenden Zeilen im Powershell Skript:

Start-Transcript -Path e2k7rus-$starttime.log -Append

$ErrorActionPreference = "Continue"
$verbosepreference = "Continue"
$DebugPreference = "Continue"

Stop-Transcript

Diese Zeilen sind nach der Prüfung an die örtlichen Gegebenheiten anzupassen:

E2K7RUS und USNs

Mangels Quellcode weiß ich nicht wie der Exchange 2000/2003 folgende Problematik löst, aber sie führt dazu, dass E2K7RUS beim folgenden Durchlauf die beim letzten Durchlauf bearbeiteten Objekte zumindest noch einmal überprüft.

Ausgangssituation: Höchste USN im AD ist "1001" . Wird nun E2K7RUS gestartet, dann sucht er natürlich alle Objekte, deren USN höher als 0 oder der zuletzt gespeicherte Wert ist. Die ADO-Abfrage liefert also alle Elemente inklusive das Objekt mit der USN 1001. Während E2K7 RUS nun die Objekte abarbeitet (nicht zwingend in der Reihenfolge der USNs !) kann es aber passieren, dass Sie einen weiteren Benutzer anlegen und für Exchange aktivieren. Er könnte dann die USN 1002 bekommen. Aber auch E2K7RUS ändert Objekte, so dass ein geändertes Objekt z.B. die USN 1003 bekommt. Am Ende des Durchlaufs speichert E2K7RUS die höchste USN der verarbeiteten Objekte. Wenn ich nun die 1001 speicher, die zum Startzeitpunkt die höchste USN war, dann werden beim nächsten Aufruf die beim letzten lauf geänderten Objekte noch mal bearbeitet. Würde E2K7RUS sich aber die höchste USN seiner eigenen Änderungen merken (also die 1003) dann würde beim nächsten Durchlauf die 1002 nicht mehr "gesehen".

Um die Bearbeitung aller Objekte sicher zu stellen, könnte E2K7RUS natürlich am Ende noch einmal die zwischenzeitlich neuen Objekte abfragen und nachbearbeiten. Zur Einfachheit und Übersichtlichkeit des Codes nehme ich aber in Kauf, dass ein geändertes Objekt ein zweites Mal geprüft wird. Änderungen sollte dabei keine mehr passieren.

Bei der Evaluierung dieses "Irrwegs" ist mir aufgefallen, dass Powershell das Feld "uSNChanged" nicht direkt lesen kann, das es ein "LongInteger" ist . Siehe auch "Dealing iADSLargeInteger in Powershell " http://bsonposh.com/archives/226

ESM2003 mit Exchange 2007

Wenn ich nun schon den RUS nachbilden kann, dann stellt sich natürlich auch die Frage, ob man dann nicht auch in einer Exchange 2007 Umgebung weiter die Exchange 2003 Management Tools verwenden könnte. Im Prinzip ist das auch möglich, wenn gleich von Microsoft nicht offiziell unterstützt. Aber die Setuproutine von Exchange 2003 stoppt, wenn das Schema zu neu ist. Aber wenn man die notwendigen DLLs kenn, kann die Karteikarten auch manuell installieren. Die Haupt-DLL ist dabei MAILDSMX.DLL, die einige weitere DLLs verwendet. Ein Blick mit "Depends" zeigt die Abhängigkeiten:

Ich habe alle DLLs einfach von einem Exchange 2003 Server in ein leeres Verzeichnis auf dem Zielsystem kopiert, wo sie auch bei Exchange 2003 lagen und mit mit folgendem  Aufruf registriert.

REGSVR MAILDSMX.DLL

Allerdings scheint es nicht auf allen Systemen auszureichen, die DLLs so zu registrieren. Die genauen Abhängigkeiten muss ich zu späterem Zeitpunkt noch ermitteln.

Zukünftige Planungen

Weitere Links

Keywords:E2K7 RUS Set-Mailbox ApplyMandantoryProperties