MS Exchange 2000 bis 2007

Es ist dem Active Directory (AD)zu verdanken, dass ich zum Microsoft Exchange Server eine “besondere” Beziehung habe, bzw. hatte.

Dort fanden, vor 15 Jahren, meine ersten “Hackereien” statt, die zwar alle sehr hilfreich waren, aber auch verdammt ins Augen hätten gehen können.

Die nicht-automatisierte Useradministration in einem größeren Unternehmen sah vor 15 Jahren so aus:

Ein paar Leute klicken den ganzen Tag lang durch die Windows Active Directory und Exchange UI-Masken um Benutzerdaten und Mailboxen so anzupassen, wie es von “den Kunden” verlangt wird.

Hat man ein paar tausend Mitarbeiter, die quer über den Kontinent verteilt sind, dann will jeden Tag jemand eine andere Berechtigung für eine Projektressource haben oder sperren und man ist mit Klickereien beschäftigt.

Und genau deshalb lernte ich die internen Details des AD und seines wichtigsten Partners, Microsoft Exchange, nach und nach kennen.

Denn die Powershell war damals noch am Zeichenbrett und hatte keine Anbindung an Exchange.

Exchange 2000/2003 Installation

Bevor sich das Exchange Setup ausführen ließ, musste man den IIS und ASP sowie den SMTP und NNTP Dienst unter Server 2000 oder 2003 installieren.

Danach integriert sich Exchange ins Active Directory LDAP Schema und erweitert es um seine Mail-spezifischen Attribute.

Kaum ist die Installation durchgelaufen, hat der System-Administrator Account eine Mailbox erhalten und diese lässt sich auch gleich über den damaligen Outlook Web Access (OWA) öffnen und zwar über http://exchange-host/exchange/

So schön sah OWA aber nur im Internet Explorer 6 bis 8 aus.
Für die damaligen Nicht-Microsoft-Browser (und darunter fällte auch der heutige Microsoft Edge), gab es eine primitivere unschönere Ansicht.

Schließlich musste man ja künstlich den Eindruck bestehen lassen, dass der IE alles besser macht.

Programmierung von Exchange 2003

Wer die Exchange-Admin-Tools installiert hatte, konnte mit CDOEXM (Collaboration Data Objects for Exchange Management … oder so) und VBScript zumindest ein paar Exchange Tasks automatisieren.
Viel besser klappte das im vollständigen Visual Basic 6, oder im damaligen dotNet Framework 1, welches über seine COM Brücke auch auf die Exchange Objekte zugreifen konnte.

 Set user = GetObject("LDAP://path,to,ad_user")
 Set ado = CreateObject("ADODB.Connection")
 ado.Provider = "ExOLEDB.DataSource"
 ado.Open
 Set person = CreateObject("CDO.Person")
 person.DataSource.Open user.ADsPath, ado, adModeReadWrite, adFailIfNotExists, adOpenSource
 Set recipient = person.GetInterface("IMailRecipient")
 recipient.CreateMailbox "LDAP://CN=Mailbox Store,CN=Storage Group,CN=InformationStore,CN=ExchangeServerName,CN=Servers,CN=Administrative Group,CN=Administrative Groups"
 person.DataSource.Save

Das interessante am klassischen Exchange damals war das Recipient Update Service (kurz RUS). Dieser Dienst scannte das AD nach Änderungen (z.B. neue User) und leitete die nötigen Schritte ein, um eine verknüpfte Mailbox automatisch anzulegen.

Um die richtigen LDAP-Pfade für die “versteckten” Exchange Objekte herauszufinden, installierte man einfach \support\tools\suptools.msi von der Server 2003 CD um das Tool ADSI-Edit zu erhalten. Dieses konnte man dann in der Microsoft Management Console mmc.exe manuell hinzufügen und sich damit zur Configuration Partition des Active Directory verbinden.
(User und Gruppen liegen in der Domain Partition und die wird mit dem AD Users und Groups Plugin schön angezeigt, doch für Configuration brauchte man eben ein natives LDAP Tool).

So erfuhr man, dass Mailboxen in einer Storage Group liegen, die auf einem Server liegen, der einer Administrative Group zugeordnet ist, die in einer Organisation liegt.
Das sieht hierarchisch so aus:

my-ad.domain.tld/Configuration/Services/Microsoft Exchange/MyOrganization/Administrative Groups/MyAdminGroup/Servers/MyMXServer/InformationStore/MyStorageGroup/MyMailboxStore

wobei die Token MyOrganization, MyAdminGroup, MyMXServer, MyStorageGroup und MyMailboxStore bei der Installation festgelegt oder auf einen Default gesetzt sind.

“In LDAP” wird das dann so ausgesprochen:

CN=MyMailboxStore,CN=MyStorageGroup,CN=InformationStore,CN=MyMXServer,CN=Servers,CN=MyAdminGroup,CN=Administrative Groups,CN=MyOrganization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=my-ad,DC=domain,DC=tld

Witzig ist, dass mit Exchange 2007 das Konzept mehrerer Administrative Groups aufgegeben wurde und bei einer Installation nur noch eine Gruppe mit dem Namen FYDIBOHF erstellt wird. Das ist ein Zeichenspiel, wo vom Token EXCHANGE einfach immer bei jedem Buchstaben der nachfolgende herangezogen wurde.

Fazit

Meine “Exchange-Zeit” endete programmiertechnisch etwa um 2007. Ich spielte noch etwas mit Exchange 2007 auf API-Ebene, doch mein Berufswechsel trug mich wieder davon weg.

Um 2011 durfte ich wieder ein Exchange 2010 System für eine Firma einrichten und seine Zusammenarbeit mit dem Data Protection Manager prüfen, aber auch das war nur ein “Sidequest”.

Leider kenne ich keine Alternativen zur Microsoft-Standard-Lösung, mit der man größere Organisationen verwalten kann und somit bleibt Exchange für mich ein “guter” Ansatz. (Obwohl es bestimmt gute Alternativen dazu gibt.)

Es war jedenfalls Mitte der 2000er ein besonderes Gefühl, wenn man mit ein paar Zeilen Code gleich mal 1000 User-Mailboxen verschieben oder nachbearbeiten konnte, während andere Admins Wochen damit zubrachten, bei 100 Kunden manuell bei jedem Mailaccount eine SMTP Adresse hinzuzufügen.

Daraus habe ich gelernt, wie unglaublich wichtig es ist, dass jedes Softwareprodukt einen Programmierschnittstelle braucht, über die man administrative Aufgaben automatisieren kann.