Exchange 2007 RUS

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

Wer MIIS,ILM, FIM einsetzt, sollte das Problem auch können
Exchange Provisioning using ILM 2007 and FIM 2010
http://technet.microsoft.com/en-us/magazine/ff472471.aspx

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:

• Performance
  Je größer die Organisation wird, desto mehr Empfänger sind zu verarbeiten. Dieser Prozess entspricht einem "Full Rebuild" unter Exchange 2003 und davor hat Microsoft bislang immer gewarnt. Der entsprechende DC hat ganzschön was zu tun. schlimmer wird dies noch, wenn mehrere Domains an unterschiedlichen Standorten dazu kommen.
• Zeitverzug
  Das Skript kann zwar jede Minute laufen, aber das wird kein Administrator wollen. Er muss also abwägen zwischen Belastung und Aktualität
• Nachvollziehbarkeit
  Leider schreiben all diese Programme kein Log, was Sie nun wirklich an den Empfängern verändert haben. nachvollziehbar ist dieser Prozess daher genauso wenig, wie das beim Exchange 2000/2003 RUS der Fall war, wenn man nicht mit Tools wie RUSMon nachgeholfen hat. Das ist bezüglich der ProxyAddresses wichtig, da Exchange 2007 hier die primäre Adresse immer anhand der Richtlinien setzt. (Anders als Exchange 200072003)

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.

• Benutzersprache
  Über den Parameter "- languages de-DE" kann man mit SET-Mailbox auch gleich die Sprache des Benutzers vorgeben. Intern setzt Exchange dabei das LDAP-Feld "msExchUserCulture" im Active Directory. Dieser Service erspart es dem Benutzer, die Sprache in OWA erst auswählen zu müssen.
• Quotas
  Interessant könnte auch die Anwendung von Postfachgrenzwerden abhängig von Firmen oder Gruppenzugehörigkeiten sein.
• Internet Settings (POP3, IMAP, OWA)
  Über das Commandelt "Set-CASMailbox" könnte der E2K7RUS für geänderte Benutzer auch gleich diese Parameter einstellen.

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 Commandlet 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:

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.

• Dienstkonto
  Das Skript muss mit einem berechtigten Benutzer gestartet werden. Das ist besonders wichtig, wenn E2K7RUS als geplanter Tasks aufgerufen werde soll.. Wir legen also einen Benutzer an, mit welchem später das Skript (MSXFAQ.DE - Taskplaner) gestartet wird.
• XML Konfiguration
  Da USNs von DC zu DC unterschiedlich sind, ist es wichtig, dass alle Aktionen immer gegen den gleichen DC gefahren werden. Der DC ist genauso wie die Domain in einer XML-Datei zu hinterlegen ist im Skript zu hinterlegen. Sollte dieser DC nicht mehr zur Verfügung stehen, dann kann ein anderer DC eingetragen werden. Dann muss aber die LastUSN im Hilfsbenutzer auf 0 gesetzt werden, damit ein voller Durchlauf sicher alle Objekte erwischt.
• Mehrere Domains
  Wenn Sie mehrere Domains mit Exchange Empfängern einsetzen, dann müssen Sie natürlich auch das Skript entsprechend anpassen, damit die richtige Domain bearbeitet wird. für jede Domain müssen Sie eigenständige Hilfsbenutzer und Skripte einsetzen.

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

• mode (config)
  Durch die Angabe von "confirm" zeigt E2K7 alle Objekte an, bei denen die Anwendung die Proxy Adressen verändert hat. Der Admin kann dann entscheiden, ob er weiter macht oder das Skript beendet.
• dc (servername)
  E2K7Rus muss immer den gleichen DC für die Domäne verwenden, da die USNs je DC unterschiedlich sind und sonst die Erkennung von neuen oder geänderten Objekten nicht funktioniert. Geben Sie hier den DNS-Namen des gewünschten DCs an
• domain (dc=e2k7,dc=msxfaq,dc=net)
  Geben Sie hier den DN der zu bearbeitenden Domäne an.
• lastusn (Startwert = 0)
  In diesem Feld speichert sich das Skript am Ende die höchste zuletzt verarbeitete USN ab, damit es beim nächsten Durchlauf einfach dort wieder aufsetzen kann.
• laststart / lastend
  Das Skript schreibt am Ende hier einen Zeitstempel des letzten Durchlaufs hinein. Sowohl die Startzeit als auch die Endezeit werden protokolliert. So können Sie nicht nur den letzten Durchlauf sondern auch den letzten Abschluss erkennen. Die Ausgabe wird aber nur bei erfolgreichem Ende des Skripts geschrieben.
• customscript
  Hiermit kann ich ein PowerShell Skript angeben, welches nach der Arbeit E2K7RUS zusätzlich aus geführt wird. Viele Firmen möchten andere Defaultwerte (z.B. ActiveSync deaktivieren, Quotas ändern etc.)

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. 

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. 

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

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.

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

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:

• Start-Transcript
  Dieser Befehl protokolliert alle Aktionen der PowerShell in die angegebene Textdatei. Diese kann daher sehr umfangreich sein und sollte später deaktiviert werden. Analog dazu ist der befehl "Stop-transcrip" am Ende zu entfernen
• $ErrorActionPreference, $verbosepreference, $DebugPreference
  Diese Variablen bestimmen die Reaktion der PowerShell bei den befehlen "Write-Verbose, Write-Error, Write-Debug" und das Verhalten bei einem Fehler. Meine Standarteinstellung im Skript gibt alles auf die Konsole aus. diese Variablen können folgende Werte annehmen: "SilentlyContinue", "Stop", "Continue", "Inquire". für den automatischen Betrieb ist "Inquire" nicht geeignet, da niemand die Eingaben beantworten kann.

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

• Funktion als Dienst
  Aktuell steht auf meiner Planung nur die Funktion als Dienst
• Eleganteres Logging
  Implementierung eines Debuglevel, um die Meldungen feiner abzustufen.
• Filterung der Empfänger, indem vorab die Exchange 2007 Server gesucht werden
• Erweiterungen um Policies
  Neben den Grundeinstellungen kann ein Exchange Postfach sehr viel umfangreicher konfiguriert werden, z.B. Sprache, Antispam Einstellungen oder auch Berechtigungen zum Einsatz von POP3, IMAP4 oder Einstellungen zu ActiveSync. All dies könnt das Skript noch nachholen, z.B.: anhand von Gruppenmitgliedschaften, wie ich dies bei Exchange 2003 mit Grp2ExInet umgesetzt habe.

Weitere Links

• Exchange RUS
• Update-Recipient -Exchange 2010 PowerShell Commandlet für Provisioning
• E2K7 Empfängermanagement
• Grp2ExInet
• MailboxGUID
• Fix-MailboxGuid
• CheckExObjects
• PowerShell
• Exchange 2007 objects are not stamped with ShowInAddressBook and never end up in the GAL after a gal sync
  http://blogs.msdn.com/dgoldman/archive/2007/05/24/exchange-2007-objects-are-not-stamped-with-showinaddressbook-and-never-end-up-in-the-gal-after-a-gal-sync.aspx
• Evan Dodds - Microsoft Exchange Server Blog ApplyMandatoryProperties
  http://blogs.technet.com/evand/archive/2007/02/28/applymandatoryproperties.aspx