Da MIIS (mittlerweile aufgegangen in ILM 2007) auch von unserem Team unterstützt wird, möchten wir auch dazu in loser Reihenfolge etwas erzählen. Derzeit sehen wir noch nicht den Bedarf für ein eigenes Blog, solltet Ihr da anderer Meinung sein, lasst es uns wissen. Selbstverständlich ist hier der Supportbedarf deutlich anders gelagert als bei den üblichen Active Directory Themen. Im Bereich MIIS gibt es immer auch das Umfeld zu betrachten, da Management Agenten zu vielfältigsten Directories vorhanden sind.

Eine der häufigsten Anwendungen für MIIS Projekte ist GALSync, daher ist hier auch ein eigener GALSync MA mit eingebunden. Wichtig ist hier die Beachtung der eingesetzten Versionen:

• Exchange 5.x => darauf gehe ich hier nicht weiter ein, die Anbindung von Exchange 5.x Umgebungen ist extrem komplex und nicht so nebenbei zu konfigurieren; wird auch nicht vom GALSync MA unterstützt
• Exchange 2000/2003 => hier ist eine tiefe AD Integration vorhanden, der GALSync MA ist für diese Versionen ausgelegt; im wesentlichen ist der GALSync MA sowieso nur ein normaler AD MA mit einem anderen Template als Grundlage. GALSync läuft mit IIFP 2003 (Ende der IIFP Entwicklung vermutlich bei SP2, keine weiteren Hotfixes zu erwarten) als auch MIIS 2003 bis hin zu ILM 2007 FP1
• Exchange 2007 => da wird es schwierig. Bisher war der RUS dafür zuständig das die entsprechenden User Attribute gefüllt wurden, da es den RUS bei Exchange 2007 nicht mehr gibt, muss das anders gelöst werden. Dafür sind nun die Cmdlets notwendig (siehe hierzu: „How to Deploy Exchange 2007 in a Cross-Forest Topology“, http://technet.microsoft.com/en-us/library/aa998597.aspx ). Man kann das also auch prinzipiell mit IIFP/MIIS 2003 erreichen, empfohlen und unterstützt ist jedoch der Einsatz von ILM 2007 FP1. Technisch ist ILM 2007 (hier rede ich immer von dem MIIS Teil in MIIS, niemals von CLM) identisch zu MIIS 2003 SP2. Das FP1 (Feature Pack 1) bringt im Wesentlichen die Exchange 2007 Unterstützung. Die besteht dann aus einer Checkbox, dass die Cmdlets dann automatisch ausgeführt werden.

Der GALSync MA ist sehr gut in den vorhandenen Dokumentationen erklärt, heraus zu heben sind „MIIS_2003_GAL_Synchronization.doc“ und „MIIS_2003_GAL_synchronization_Step_by_step.doc“ aus den verfügbaren Scenarien (http://www.microsoft.com/downloads/details.aspx?FamilyId=15032653-D78E-4D9D-9E48-6CF0AE0C369C&displaylang=en). Wer danach sein GALSync konfiguriert wird eine sehr gut funktionierende Lösung haben. Aber man muss da sehr gründlich sein, kleine Abweichungen oder Nachlässigkeiten führen sehr leicht zu Fehlern. Was bei GALSync immer wieder gewünscht wird ist eine Hierarchiestruktur bei der Erstellung der Contact Objekte. Dies ist leider nicht vorgesehen. Alle Contacts werden in einer OU abgelegt. Eine Anpassung ist natürlich möglich (der GALSync Sourcecode ist mitgeliefert), doch eine solche Änderung ist nicht einfach und erfordert ein sehr gutes Verständnis der komplexen GALSync Konfiguration.

Der zweite Punkt der immer wieder angesprochen wird sind die vielen X.500 Adressen die automatisch angelegt werden. Der GALSYNC MA wurde entwickelt um möglichst allgemein auf die normale Kundenumgebung und auch die Anforderungen zu passen. Dazu wird für jeden Forest für jeden Benutzer eine X.500 Adresse erstellt. Der Grund hierfür sind evtl. Verschiebungen der Benutzer. Wenn auf ein Email ein REPLY gemacht wird, und dieses Email von dem Benutzer VOR seinem Verschieben verschickt wurde, dann kann nun der ursprüngliche Absender nur über die zusätzlichen X.500 Adressen gefunden werden. Ohne diese zusätzlichen Adressen wird ein NDR (Non Delivery Receipt) verschickt. Im Extremfall hatte ich da schon mal einen Kunden mit 80 Forests, wo jeder User entsprechend 1 korrekte X.500 Adresse hatte und dann eigentlich noch 79 falsche X.500 Adressen, nur für die Eventualität dass dieser Benutzer einmal verschoben wird. Es ist leicht nachvollziehbar das man unter diesen Umständen ungern diese zusätzlichen X.500 Adressen anlegen möchte. Zusätzlich müssen durch diese Änderung ja immer die Objekte in allen Forests upgedated werden. Dies ist u.a. auch ein Grund dafür warum nur max. 30 GALSync MAs pro MIIS Instanz unterstützt werden. Und dazu ist schon Top Hardware nötig (Top Hardware, das sind z.B. 4-8 Xeon CPUs mit 8GB oder größer und jede Menge Spindles, also ein SuperSuperschnelles Raid). Doch wie kann man diese vielen zusätzlichen Adressen verhindern?

Da gibt es eigentlich zwei Möglichkeiten:

- KB929875, “The GAL Synchronization management agent adds X.500 proxy addresses to source objects when you use Identity Integration Server 2003 or Identity Integration Feature Pack for Active Directory to synchronize Exchange 2003 organizations”, http://support.microsoft.com/default.aspx?scid=kb;EN-US;929875

Dieser Artikel ist zwar absolut korrekt, doch finde ich diese Lösung nicht ganz einfach. Zumindest habe ich schon mehr als einen Fall gehabt wo bei der Umsetzung Fehler gemacht wurden und nachher nichts mehr ging. Daher finde ich die Alternative wesentlich smarter:

- Die Konfiguration so lassen wie sie ist und im GALSync Code direkt das Zurückschreiben der zusätzlichen Adressen verhindern:
In der GALMA.VB in der Routine:

Public Sub MapAttributesForImport

Das hier abändern:

Case "LegacyExchangeDNMapping"
             IAFLegacyExchangeDN(mventry)

in:

Case "LegacyExchangeDNMapping"
            Throw New DeclineMappingException

Wenn das nicht im Code sondern im Attribute Flow lt. KB Artikel geändert werden soll, so ist dies wesentlich komplexer und fehlerträchtiger als diese kleine Codeänderung. (Keine Gewehr, bitte zunächst in einer Testumgebung überprüfen)

Damit möchte ich unseren kleinen Ausflug nach MIIS und GALSync beenden. Da MIIS Themen erheblich seltener sind als allgemein AD Themen wird auch der Anteil von MIIS Themen in unserem Blog naturgemäß seltener sein. Solltet Ihr spezielle Themen wünschen, schreibt das gerne als Comment. Ich kann natürlich nichts versprechen, außer eins: wir bieten hier keine Lösungen oder gar Code nach Wunsch an.