Exchange 2007: Rollenspiele

01.01.2007 von Holger Kattner
Bereits bei Exchange Server 2003 gehörte es zur üblichen Vorgehensweise in einer Organisation, Server in verschiedenen Konfigurationen zu installieren, die unterschiedlichste Funktionen im System ausführen. Diese Rollensystematik wurde mit Exchange 2007 verfeinert. Exchange bietet nun fünf vorkonfigurierte Rollen zur Installation an.

Microsoft hatte sich nach eigenen Angaben eine Reihe von Zielen bei der Entwicklung von Exchange Server 2007 gesetzt:

Diese Punkte spiegeln sich insbesondere auch in dem neuen Rollenkonzept von Exchange Server 2007 wider. Auch in älteren Versionen war es bereits in begrenztem Maße möglich, Variationen in den Funktionen einzelner Server einer Organisation umzusetzen. Dies geschah aber im Wesentlichen mit Blick auf den einzelnen Server. Für einzelne Installationen konnte man sich überlegen, ob einzelnen Komponenten an der Stelle entbehrlich sind, und damit eine gewisse Rollenverteilung erreichen. In Exchange 2003 hat Microsoft dann angefangen, mit Frontend und Backend erste Ansätze von Rollen zu schaffen, die aber noch sehr serverzentriert waren.

Systemdesign

Mit Exchange 2007 kann das Systemdesign einen globaleren Blickwinkel einnehmen und Funktionen beliebig innerhalb der Organisation verteilen. MTAs (Mail Transport Agents) zur Nachrichtenverteilung können an den Schnittstellen positioniert werden, um den Transport nach außen zu gewährleisten und die internen Nachrichten zu transportieren. Nachrichtenspeicher werden im Inneren der Organisation installiert und Virenfilter außerhalb. Letztlich ist dies das Mehr an Flexibilität im Design, das Microsoft für die kommende Exchange-Generation erreichen wollte.

Das zweite Ziel war die bessere Skalierbarkeit. Durch die Serverrollen kann jede Rolle getrennt dimensioniert werden. Die Anzahl der Transportserver kann unabhängig von der Anzahl der Postfachserver gewählt werden. Bei Problemen mit der Nachrichtenübermittlung kann die Anzahl der Transportserver erhöht werden, bei Engpässen beim Zugriff auf gespeicherte Nachrichten die Zahl der Postfachspeicher. Das Gesamtsystem lässt sich auf diese Weise besser mit den sich ändernden individuellen Ansprüchen einer Organisation ausbauen.

Bild 1: Die verschiedenen Rollen im Überblick.

Die spezifische Anpassbarkeit macht sich auch im Hardwarebereich bemerkbar. Neben der 64- Bit-Unterstützung ist die Rollenfunktion eine weitere Maßnahme zur effizienteren Hardwarenutzung. Die Hardware der einzelnen Server kann nun besser an die Anforderungen der einzelnen Serverrollen angepasst werden, auch wenn die Hardwareempfehlungen seitens Microsoft sich für die einzelnen Rollen in großen Teilen ähneln. Einen wichtigen Beitrag leisten die neuen Rollen auch zur Wartbarkeit. Im realen Leben hat bisher die überschaubare Anzahl von Konfigurationen zu einer sukzessiven Feinanpassung der Serverkonfigurationen durch die Administratoren geführt. Diese wurden häufig schlecht dokumentiert und machte aufgrund mangelnder Vergleichbarkeit eine Fehlersuche oft sehr schwer. Durch die Rollen sollte sich nun die Notwendigkeit eines individuellen Feintunings reduzieren und der Wildwuchs von Konfigurationen etwas eingedämmt werden.

Optimierung auf große Installationen

Allerdings gibt es gerade im Bereich Skalierbarkeit und effiziente Hardwarenutzung auch Bemängelungen. Offensichtlich zielen alle diese Optimierungen auf große Installationen hin. Die Eignung von Exchange soll für große Installationen weiter gesteigert werden. Dabei wurde allerdings das untere Ende der Skala etwas vernachlässigt. Zwar lässt sich Exchange als Komplettinstallation auch weiterhin auf einem einzelnen Rechner installieren, aber in diesen Installationen muss der Viren-/Spam-Filter auf den Hub Transport verlegt werden, da der Edge Transport unbedingt getrennt installiert werden muss, was einen Kompromiss im Systemdesign erfordert.

Zudem wird heute die Leistungsfähigkeit einer Ein-Server-Installation gerne dadurch gesteigert, dass der Server als Cluster installiert wird. Diese Art der Installation wird für Exchange 2007 praktisch nicht mehr unterstützt, da sich einige Rollen nicht auf Clustern installieren lassen. Clusterinstallationen sind im Wesentlichen als zusätzliche Fehlertoleranz von Postfachservern gedacht. Ausfallsicherheit in anderen Rollen wird dagegen besser durch unabhängige Instanzen gewährleistet. Vorhandene Mehr-Rollen-Cluster müssen deshalb neu gestaltet werden, wozu in einigen Fällen auch mehr Hardware notwendig sein kann.

Rollenbeschreibung

Insgesamt hat Microsoft fünf unterschiedliche Rollen innerhalb des Exchange-Systems isoliert. Dies sind im Einzelnen die folgenden:

Die Serverrollen lassen sich nahezu beliebig kombinieren. Alle Rollen bis auf den Edge-Transport- Server lassen sich gemeinsam auf einem Server installieren, allerdings nur wenn auf Cluster verzichtet wird.

Postfach-Server

Die Postfach-Rolle beinhaltet im Wesentlichen die Exchange-Datenbank und die dazu gehörigen Funktionen. Als Schnittstelle zu den anderen Rollen besitzt sie nur die Windows-eigene Schnittstelle MAPI. Darauf kann mittels Remote Procedure Calls (RPCs) zugegriffen werden. Outlook ist der einzige Client, der diese Art des Zugriffs beherrscht und deshalb direkt auf den Postfach- Server zugreifen kann.

Daneben besitzt die E-Mail-Datenbank nur noch die auf einer niedrigeren Ebene liegenden Datenbankschnittstellen der Jet-Datenbank, die allerdings für den Endanwender weniger interessant ist. Vereinfacht kann die Postfach-Rolle deshalb als Nachrichtendatenbank mit MAPIServer- Schnittstelle gesehen werden.

Der Postfach-Server ist die Rolle, die besonders für den Betrieb als Cluster vorgesehen ist. Microsoft hat für diese Betriebsart den Begriff Cluster Continuous Replication (CCR) geprägt. In dieser Betriebsart ist die Postfach-Rolle nicht mit anderen Rollen kombinierbar. Zudem gilt jedenfalls für die Betaversionen die Empfehlung, dass der erste Server einer Organisation kein Cluster sein sollte, da es Probleme bei der Generierung der öffentlichen Ordner im CCR-Modus gibt. Damit sind der in der Praxis durchaus verbreiteten Ein-Cluster-Server-Organisation gleich zwei Steine in den Weg gelegt, die diese Art der Installation unter Version 2007 behindern.

Microsoft hatte bereits länger angekündigt, dass öffentliche Ordner als komplett optionale Komponente für Exchange 2007 gestaltet werden. Deshalb sollten die öffentlichen Ordner auch eigentlich in einer eigenen, sechsten Rolle implementiert werden, die dann nur noch auf Wunsch installiert werden müsste. Nun werden die öffentlichen Ordner allerdings doch im Rahmen des Postfach-Servers verwaltet und sind damit als Funktion weiterhin passiv vorhanden. Allerdings wird standardmäßig keine Datenbankdatei mehr für sie angelegt.

Die öffentlichen Ordner und die Postfächer verwenden praktisch die gleichen Softwarekomponenten, was die praktische Umsetzung einer logischen Trennung beider Funktionen wahrscheinlich erschwert hat. Da die meisten Kunden die Struktur ihrer öffentlichen Ordner beibehalten und die Komponente ohnehin verwenden werden, wurde das Vorhaben die öffentlichen Ordner aus dem Standardfunktionsumfang herauszulösen, erst einmal verschoben. Allerdings dürfte sich an der Absicht, öffentliche Ordner mittelfristig abzuschaffen, damit nichts geändert haben. Um die Anlage einer Datenbank für öffentliche Ordner verzichtbar zu machen, benötigt Exchange 2007 im Gegensatz zur Vorgängerversion keine öffentlichen Ordner für Systemfunktionen wie die Verteilung von Adressbüchern und Frei- Belegt-Informationen mehr. Diese Funktionen werden nur noch in Fällen der Koexistenz mit älteren Versionen des Produkts eingesetzt. Damit ist eine reine Exchange 2007-Installation ohne öffentliche Ordner lauffähig.

Hub Transport

Die Hub-Transport-Rolle ist im Grunde eine Kombination von dem, was früher einmal SMTP-Connector und MTA waren. Sie implementiert einen SMTP-Server, der auf der einen Seite Nachrichten annimmt und sie entweder über MAPI an ein Postfach sendet, oder sie an einen anderen SMTP-Server weiterroutet. Zudem werden ausgehende Nachrichten von lokalen Clients weitergeleitet und zugestellt.

Mit Exchange 2007 setzt Microsoft praktisch komplett auf SMTP als Grundlage für den Nachrichtentransfer. X.400 und Spezial-Connectoren wie der zu Groupwise wurden aufgegeben, da diese in der Praxis kaum noch benötigt werden. In fast allen Fällen lässt sich SMTP als Ersatz einsetzen.

Die Funktion des Hub Transport ist vergleichbar mit dem IIS-SMTP-Dienst, erweitert durch MAPI-Funktionen, die auf den Postfachspeicher zugreifen. In Exchange 2003 war dies auch so umgesetzt. Für Exchange 2007 hat Microsoft allerdings sämtliche SMTP-Funktionen neu implementiert und greift nun nicht mehr auf den weniger effizienten SMTP-Dienst von Windows Server zurück. Er muss (beziehungsweise sollte) deshalb auch nicht zusammen mit der Hub-Transport- Rolle installiert werden.

Da der Hub Transport als MTA auch für den Transport interner Mails verantwortlich ist, muss ein Server mit dieser Rolle auf jeden Fall installiert sein. Außer für den Postfachzugriff verwendet der Hub Transport praktisch nur SMTP. Externe Verbindungen zu Partner-Domänen und -Netzen können dabei mittels Transport Layer Security-Standard (TLS) verschlüsselt werden.

Um externe Nachrichten zu transportieren, muss für mindestens einen Hub Transport ein Empfangs- und Sendeconnector eingerichtet werden. Diese Connectoren, die nicht viel mit dem Connector-Begriff früherer Versionen zu tun haben, sind Verbindungen, über die Exchange 2007 seine Nachrichten weiterleitet.

Empfangs- und Sendeconnectoren sorgen für den Austausch von Nachrichten mit dem Internet, entweder direkt oder über einen Edge-Transport- Server. Sie sind außerdem für den Austausch von Nachrichten über Domänengrenzen innerhalb einer Organisation notwendig. Sie sind auch erforderlich, wenn Exchange 2007 mit älteren Versionen in einer Organisation koexistiert.

Keine Routing-Gruppen

Exchange 2007 kennt keine Routing-Gruppen mehr. Bei der Gestaltung der Netzwerktopologie verlässt sich die neue Version komplett auf die Active Directory-Domänenstruktur. Dies kostet zwar etwas an Flexibilität, erspart aber in den meisten Fällen Arbeit bei der Konzeption.

Bild 2: Connectoren steuern die Zustellung interner und externer Nachrichten.

Der Austausch zwischen den Domänen und Forests erfolgt über Connectoren auf den Hub-Transport- Servern. Einem Sendeconnector in einer Domäne steht jeweils ein Empfangsconnector in der nächsten Domäne gegenüber. Dabei muss nicht jede Domäne mit jeder anderen verknüpft sein, solange ein indirekter Weg existiert. Exchange berechnet aus den vorhandenen Verbindungsinformationen einen Weg.

Wenn beispielsweise eine E-Mail aus Domäne A an die nicht direkt verknüpfte Domäne C gesendet wird, aber beide Connectoren Kontakt mit der Domäne B haben, nimmt die Nachricht folgenden Weg:

Die Anbindung an Routing-Gruppen aus Exchange 2003 funktioniert praktisch analog. Auch hier müssen auf beiden Seiten Connectoren erstellt werden.

Client Access

Wie bereits gesagt, ist Outlook der einzige Client, der mittels MAPI direkt auf den Postfach-Server zugreifen kann. Bei der Verwendung jeglicher anderer Clients ist die Zwischenschaltung eines Client-Zugriffs-Servers notwendig. Die Client- Zugriff-Rolle löst damit die Frontend-Server unter Exchange 2003 ab. Sie beinhaltet Serverdienste für die gängigen Clientprotokolle. Im Einzelnen bietet die Client-Access-Rolle folgende Protokoll- Optionen:

Wie bei früheren Versionen auch werden die HTTP-basierten Protokolle für OWA, WebDAV und Active Sync über den Internet Information Server implementiert, der daher auf allen Servern mit Client-Zugriff-Rolle laufen muss.

Ein Protokoll, das früher ebenfalls über den IIS bereitgestellt wurde, ist NNTP, welches in Version 2007 nicht mehr unterstützt wird. Weder ist der Zugriff auf öffentliche Ordner damit möglich, noch können Usenet-Diskussionen in öffentlichen Ordnern repliziert werden. Falls in einer Organisation ein Usenet-Server betrieben werden soll, beispielsweise um Microsoft-Support-Gruppen vorzuhalten, muss zu diesem Zwecke entweder ein Exchange 2003-Server erhalten bleiben oder auf andere Lösungen ausgewichen werden.

Microsoft sieht augenscheinlich im Bereich Exchange vor allem den Einsatz von Outlook, OWA und Windows Mobile-basierten Clients. Die Verwaltung der Standardprotokolle POP3 und IMAP ist deshalb nicht mehr in der Management Console enthalten, sondern nur noch über die Management Shell möglich. Die Aktivierung dieser Protokolle wird einfach durch Starten der jeweiligen Dienste umgesetzt.

Unified Messaging

Die Integration von Telekommunikationsfunktionen wie Fax, VoIP oder Voice Mail ist die herausragende Erweiterung des Exchange Server bei dieser Versionsaktualisierung. Die Unified-Messaging- Rolle bildet das Bindeglied zwischen der notwendigen Telekommunikationshardware und der E-Mail-Infrastruktur. Als Basis dienen dabei die Protokollstandards für VoIP (Voice over IP). Anrufe und Fax aus VoIP- und regulären Netzen werden in Dateiformat gewandelt und als E-Mails verschickt und gespeichert. Spracherkennungsfunktionen dienen zudem zur Steuerung von Mehrwertdiensten, etwa zur Abfrage von E-Mails und Kontaktdaten oder der Verschiebung von Meetings.

Unified Messaging verfügt auf der einen Seite über eine VoIP-Schnittstelle und greift auf die anderen Exchange-Rollen über SMTP (over TLS) und MAPI zurück. Um eine Verbindung mit dem normalen Telefonsystem herzustellen, ist zusätzlich spezielle Gateway-Hardware erforderlich, die die Signale in VoIP-Verbindungen umsetzt.

Edge Transport

Der Edge-Transport-Server gleicht in vielerlei Hinsicht dem Hub Transport. Auch er ist im Wesentlichen ein SMTP-Server, der Nachrichten hin- und herschaufelt. Im Unterschied zum Hub Transport muss er allerdings außerhalb der Active Directory- Domäne installiert sein. Zudem laufen auf ihm die Filter, die ein- und ausgehende Nachrichten auf Viren-, Phishing- und Spam-Inhalte überprüfen. Der Nachrichtentransport erfolgt intern ebenfalls über SMTP-over-TLS. Extern werden allerdings standardmäßig auch unverschlüsselte Verbindungen angenommen.

Grundsätzlich ist es eine gute Idee, die Filterung fragwürdiger E-Mails außerhalb der Domänengrenzen durchzuführen. Eine Nachricht mit Schadcode, die eine ungepatchte Sicherheitslücke ausnützt, kann auf diese Weise nicht die Sicherheit in der internen IT-Umgebung kompromittieren. Sie erlaubt den Angreifern schlimmstenfalls den Zugriff auf das Perimeternetzwerk.

Allerdings wird dadurch der Hardware- und Lizenzbedarf erhöht. Für kleine und mittlere Betriebe sind Ein-Server-Installationen deshalb deutlich attraktiver. Um diesem Bedürfnis entgegenzukommen, können die Filterdienste teilweise auch auf normalen Hub-Transport-Servern ausgeführt werden. Damit verliert das Gesamtsystem etwas an Sicherheit, kostet aber weniger. Speziell werden die Anforderungen im Vergleich zur Vorgängerversion nicht zu drastisch erhöht.

Da der Edge-Transport-Server allerdings auch Informationen über Benutzer und interne E-Mail- Adressen benötigt, aber keinen direkten Zugriff auf das Active Directory besitzt, muss Exchange einige Daten aus der internen Domäne auf den Edge- Transport-Server kopieren. Hierzu dient ein Protokoll namens EdgeSync. Auf dem Edge-Transport- Server läuft zu diesem Zweck eine ADAM-Instanz, die LDAP-Verbindungen über den TCP-Anschluss 1369 entgegennimmt. Die Daten, die in ADAM abgelegt werden, sind dabei so knapp wie möglich gehalten, da die internen Daten ja gerade durch diese Konstruktion geschützt werden sollen.

Migration

Es wird empfohlen, die Migration nach Exchange 2007 in einer bestimmten Abfolge der Rollen durchzuführen. Zuerst sollten alle alten Frontend- Server durch die neue Client-Zugriffs-Rolle ersetzt werden. Danach kommen dann Hub- Transport-Server, in der Folge Mailbox- und schließlich eventuelle Unified Messaging-Server. Edge-Transport-Server lassen sich weitgehend unabhängig von diesem Plan installieren, da sie nicht Teil der internen Umgebung sind und nur sehr bedingt von dieser abhängen.

Der Zugriff über die Client-Zugriff-Rolle soll auf alte Postfach- Server problemlos möglich sein. Deshalb sollte mit dieser Rolle begonnen werden. Durch einen Programmfehler kam es allerdings in der Betaversion hier zu Problemen, wenn mehrere Rollen auf einem Rechner installiert wurden. Dieser Fehler sollte allerdings in der fertigen Version behoben sein.

Zusammenfassung

Abgesehen vom Manko der etwas verringerten Skalierbarkeit im mittleren und kleinen Bereich macht die Einführung von Rollen die Gestaltung gerade von großen Umgebungen deutlich flexibler. Zudem reduzieren die vorkonfigurierten Rollen die Notwendigkeit individueller Anpassungen.

Stattdessen können die mitgelieferten Rollen individuell im Unternehmensnetz verteilt werden. Dies erhöht die Vergleichbarkeit verschiedener Installationen und verringert damit den Support-Aufwand.