Vorteile von Exchange 2000/2003 zu Exchange 5.x
Diese Seite hat sich seit Exchange 2007 überholt.
Auf dieser sehr umfangreichen Seite versuche die unterschiede bzw. Vorteile von Exchange 2000 an praktischen Fakten zu erläutern ohne allzu viel Marketing oder Schlagworte zu nutzen. Die Themen:
- Benutzer und Servermanagement
- Datenbankmanagement
- Messagerouting
- Internettauglichkeit
- EnterpriseUmfeld / Skalierbarkeit
- Programmierbarkeitplan
- Lizenzen, Support und Update
Dies ist natürlich nur ein Anfang und ersetzt keine detaillierte Auseinandersetzung mit dem Einsatzzweck und der Planung.
Benutzer und Servermanagement
Die Verwaltung von Benutzern und Servern sind bei Exchange 2000 fundamental unterschiedlich, so dass hier einige sehr erfreuliche Verbesserungen zu verzeichnen sind.
Postfach wurde irrtümlich gelöscht
Irren
ist menschlich und manchmal gibt es Dinge, die eigentlich nicht passieren
dürften, aber doch passieren, z.B. das Löschen eines Benutzerkontos oder
Postfachs, sei es durch unbedachtheit, einen Programmfehler beim Import oder bei
der fehlerhaft eingestellten Replikation mit dem Active Directory Connector.
Wird im Exchange
5.5 Administrator irrtümlich ein Benutzer gelöscht so wird der Eintrag in der
DIR.EDB gelöscht und nach einiger Zeit in alle anderen Standorte repliziert. Ein
Wiederherstellen ist nicht möglich, selbst wenn alle Informationen des Postfachs
noch in der Datenbank PRIV.EDB vorliegen Eine Wiederherstellung bedeutet daher
eine Neuanlage des Postfachs mit allen Gruppenzugehörigkeiten und die
Wiederherstellung der PRIV.EDB auf einem Recovery-Server mit nachfolgender
Migration der Daten (EXMERGE etc.).
Ein Deaktivieren der Exchange 2000 Mail Funktion bedeutet, dass im Active
Directory der Eintrag bei dem Benutzerobjekt entfernt wird. Die Mailbox bleibt
standardmäßig in Exchange 2000 weiterer 30 Tage bestehen. In dieser Zeit kann
der Administrator die nicht verknüpfte Mailbox jederzeit wieder mit dem
bestehenden Active Directory Konto oder einen anderen neuen Konto verbinden.
Wenn der gleiche Benutzer genutzt wird, bleibt er auch in den Windows 2000
Gruppen, welche gleichzeitig auch Exchange 2000 Verteiler sein können. Auch die
Rechte auf öffentliche Ordner bleiben dank der gleichen SID erhalten.
Wird der Benutzer in eine andere Domäne verschoben, kann das Postfach auch dorthin verbunden werden. (Vergleichbar der Änderung des primären NT-Kontos bei Exchange 5.5).
Benutzer in der Struktur verschieben
Oftmals verändert sich die
Struktur im unternehmen. Neue Abteilungen werden gebildet und umstrukturiert.
Als Administrator bedeutet das eine Anpassung der technischen Strukturen an die
neuen Gegebenheiten.
Das Verschieben von Anwendern
im Exchange 5.5 Verzeichnis von einem Empfängerkontainer in einen anderen
Empfängerkontainer ist nicht möglich. Einzige Lösung ist das Exportieren der
Postfachinhalte, das Löschen im Quellkontainer und Neuanlegen in dem
Zielkontainer mit darauf folgendem Import der Daten. Zusätzlich kommt eine nicht unerhebliche Replikation hinzu.
Es ist problemlos möglich, den
Benutzer innerhalb der gleichen Domäne zu verschieben. Dies ist eine
Basisfunktion des Active Directory. Auch ein Verschieben in andere Domänen ist
möglich, da der Benutzer mit ADMT in der Zieldomäne samt SID-History angelegt
werden kann. Die Exchange Eigenschaften können übernommen werden.
Dienstkonto Abhängigkeit
Sicherheit ist ein wichtiger
Aspekt bei der Betrachtung eines Nachrichtensystems und wenn ein System ein
Dienstkonto verwendet, können wir recht sicher sein, dass das Kennwort nur
selten bis gar nicht geändert wird und das Konto auch kaum ausgesperrt wird.
Solche Konten sind daher ideal für mögliche Angreifer.
Das bei der Installation
angegebene Dienstkonto wird genutzt, um die Dienste zu starten und den Zugriff
auf die Datenbank zu erlauben. Diese Dienstkonto hat in der Regel sehr
weitreichende Rechte innerhalb von Exchange und die Datenbank und kann z.B.:
alle Postfächer öffnen. Es wird auch gerne von Datensicherungen
(Bricklevelbackup) oder Virenscannern genutzt. Eine Änderung des Dienstkontos
z.B. Um Änderungen an der Domänenstruktur zu erlauben ist ein aufwändiger
Vorgang
Die Dienste von Exchange 2000
laufen als „LocalSystem“. Das Dienstkonto ist nicht mehr notwendig (nur Exchange
Nativ Mode) Zugriffe auf das Active Directory erfolgen mit dem Computerkonten
der Domäne und den zugeordneten Kerberos-Tickets. Insofern gibt es kein Konto,
mit dem sich ein Anwender anmelden könnte und Zugriff auf alle Postfächer
erlangt. Natürlich ist diese Funktionalität über geeignete Vergabe der Rechte
einstellbar. Auch Domänen Administratoren haben per Standardeinstellung ein
Verbot auf alle Postfächer zuzugreifen. Nur im gemischten Modus ist ein
Dienstkonto hinterlegt, damit eine Kommunikation mit den Exchange 5.5. MTA über
RPC möglich ist.
Gruppen und Verteiler
In jedem System gibt es
Gruppen, um Personen zusammenzufassen und einfacher Rechte zu vergeben oder
diese zu adressieren. Wie effektiv können diese gepflegt werden oder sind
überflüssige redundante Informationen zu verwalten und zu speichern
Exchange 5.5. pflegt
entsprechende Verteiler, welche sowohl für den Mailversand als auch für die
Berechtigung auf öffentliche Ordner verwendet werden. Diese sind aber ohne
Hilfsmittel nicht mit den Sicherheitsgruppen einer NT-Domäne verbunden. Oft
bedeutet dies den doppelten Pflegeaufwand um die Gruppen synchron zu halten und
das Risiko einer unstimmigkeit.
Sicherheitsgruppen im Active
Directory können „Exchange aktiviert“ werden und werden damit zu Verteiler für Exchange 2000. Die Mitgliedschaften müssen nur an einer Stelle gepflegt werden,
was Zeit erspart und eine Konsistenz der Daten sichert. Nebenbei erfolgt die
Verwaltung mit der Management Konsole für Benutzer und Gruppen. Der Ausführende
muss kein Exchange Systemadministrator sein.
Verteilte Administration
Sobald Firmen eine kritische
Grenze der Anwenderzahl überschreiten, wird der Administrator sehr schnell zum
Engpass, da er mit immer mehr Routinetätigkeiten belastet wird, z.B. ändern von
Namen, Anlegen und Löschen von Benutzern, ändern von Gruppenmitgliedschaften und
anderen Regeltätigkeiten, für die keine Administratorrechte notwendig ist.
Leider können frühere System wie Windows NT4 keine verteilte Administration, so
dass für bestimmte Aufgaben immer auch das Recht des Administrators gebraucht
wird. Dies ist mit Windows 2000 und Exchange 2000 anders geworden.
Der Administrator über den
Standort war zugleich Administration über alle Server und Benutzer in diesem
Standort. Eine Delegierung von Aufgaben oder die Trennung von Servern
verschiedener Abteilungen am gleichen Standort war nicht möglich bzw. nur sehr umständlich. Eigene Standorte bedeutete aber auch immer wieder zusätzliche
Replikation des Verzeichnisdienstes und zusätzliche Verbindungen.
Die Trennung der Server
Administration von der Konfiguration der Anwender erlaubt eine hohe Flexibilität
bei der Verteilung administrativer Rollen. So können Personen und Gruppen die
Informationen der Anwender im Verzeichnis (z.B. Mailadresse, Straße, Ort,
Gruppenzugehörigkeit) pflegen, ohne vollständigen Zugriff auf die
Postfachinhalte oder Konfiguration der Server und Verbindungen zu haben. Über
Organisationseinheiten und frei abgestuften Rechten im Active Directory ist es
möglich, das komplette Firmenteile oder Abteilungen eigenständig verwaltet
werden. Selbst eine Trennung der Server in verschiedene administrative Gruppen
erlauben ein effektives Routing der Nachrichten durch unabhängig Routinggruppen und die optimierte Replikation des Active Directory
Vorteile für den Anwender
Auch wenn Exchange 2000 sehr
viele Vorteile für den Administrator und den Betrieb bringt, sind einige
Funktionen interessant, da sie direkt oder Indirekt dem Anwender zugute kommen.
Exchange 5.5. ist mit Outlook
als Client und dem rudimentären Webzugriff und der eingeschränkten
Skriptfunktionalität nahezu ausgereizt.
Exchange 2000
liefert neben allen Vorteilen für den Administrator und den Betrieb, die sich
direkt in reduzierten Kosten und höherer Verfügbarkeit bemerkbar machen und
damit indirekt dem Benutzer helfen, auch direkte Vorteile für den Anwender. Die
nun verfügbare Volltextindizierung der Informationsspeicher erlaubt eine
schnelle und effektive Suche über die Dokumente und Nachrichten im Postfach des
Anwenders und öffentlichen Ordnern. Der neue Webzugriff bietet sehr
leistungsfähige Wege, Informationen zu verarbeiten.
Die Funktionalität des Clients hat sich mit Exchange 2000 direkt kaum geändert,
wodurch Schulungen für neue Funktionen und Veränderungen auf ein Mindestmaß
beschränkt bleiben. Insofern bleiben für die meisten Anwender die Veränderungen
im verborgenen und über eine gestiegene Zuverlässigkeit mit geringeren
Betriebskosten können sich alle freuen.
Datenbankmanagement
Exchange 4.x und 5.x wurden zu Zeiten geplant und entwickelt, zu denen Datenbanken mit mehreren Gigabyte eher untypisch waren. Entsprechend wurden Dinge vereinfacht, die bei der heutigen Datenmenge aber anders besser gelöst werden. Dem trägt Exchange 2000 Rechnung.
Unabhängigkeit von Verzeichnis und Datenbank
Es gibt Situationen, in denen
die Datenbank DIR.EDB korrupt ist oder gelöscht wird.
Jeder Exchange 5.5 Server hat
eine eigene DIR.EDB, ohne die er nicht startet und in folge dessen startet auch
der Informationsspeicher als abhängiger Dienst nicht mehr und die Benutzer können weder Postfächer noch öffentliche Ordner nutzen.
Durch die Ablage der
wesentlichen Konfigurationsdateien im Active Directory ist Exchange 2000 nicht
mehr von einer DIR.EDB abhängig. Bei entsprechender Planung des AD mit
ausreichend Domaincontrollern und globalen Katalogen und funktionierender
DNS-Auflösung ist Exchange 2000 in dieser Hinsicht sehr gut abgesichert. Bei
einem Totalausfall des AD ist nicht nur Exchange betroffen, sondern auch alle
Arbeitsstationen und Server würden eine Anmeldung der Anwender verweigern. Durch
Redundanzen und entsprechende Sicherheitskonzepte ist diese Risiko sehr gut zu
reduzieren.
PRIV.EDB oder PUB.EDB korrupt
Auch die eigentlichen
Maildatenbanken können korrupt werden oder verloren gehen. Besonders in großen Umgebungen, auf denen die Dateien über mehrere Festplatten verteilt sind, kann
der Ausfall eines Teils der Speichersubsysteme eine Teildatenbank unerreichbar
machen.
Aufgrund der engen Verbindung
von PRIV.EDB und PUB.EDB ein einem Store ist bei einem Ausfall nur einer der
Datenbanken auch die andere Datenbank betroffen. Der Informationsspeicher
startet nicht mehr, so dass die komplette Funktion ausfällt.
Durch die Trennung der
Datenbanken und die Nutzung verschiedener Speichergruppen ist eine Abhängigkeit
der einzelnen Datenbanken voneinander nicht mehr gegeben. Jede Datenbank kann
eigenständig gestoppt und gestartet werden. Insofern ist bei dem Ausfall einer
Datenbank nur dieser Teilbereich nicht mehr erreichbar. Hierzu zählt auch die
Möglichkeit über Speichergruppen (SG) auch mehrere Protokolldateien zu nutzen um
die Erreichbarkeit zu erhöhen.
Volltextsuche
Viele Informationen in einer
Datenbank sollten auch durchsuchbar sein.
Es gibt keine Volltextsuche.
Über Outlook können Nachrichten nach bestimmten Kriterien auf dem Server
durchsucht werden, aber umfangreichere Anfragen bedeuten, dass der Client durch
die Datenbestände sucht und damit Netzwerklast. Eine Indexfunktion ist nur mit
Zusatzprodukten möglich.
Die Datenbank enthält die
Möglichkeit, einen Volltextindex aufzubauen und zu pflegen. Damit kann mit
Outlook aber auch mit eine Browser eine sehr schnelle Volltextsuche durchgeführt
werden. Sogar Anlagen und Dokumente im Informationsspeicher sind durchsuchbar,
wenn entsprechende Dokumentfilter installiert wurden. Standardmäßig werden
Office Dokument und TIFF-Dateien (OCR-Scan) auch mit Inhalt verfügbar gemacht.
Message Routing
Auch das Übertragen von Nachrichten im System ist komplett geändert worden, so dass Exchange 2000 hier sehr viel schneller, besser und zuverlässiger funktioniert und Fehler bei Connectoren sehr schnell umgangen werden.
Connector „down“ = Leitwege ändern sich
Weitverkehrsverbindungen sind
nie 100% verfügbar. Daher ist es wichtig zu wissen, wie ein Nachrichtensystem
sich verhält, wenn eine Verbindung zeitweise nicht verfügbar ist. Werden die
Nachrichten zurückgesendet oder nehmen Sie einen alternativen Weg ? Werden diese
im Kreis bis zu unzustellbarkeit versendet und kosten Sie damit unnötig
Rechenleistung und Bandbreite ?
Exchange 5.5 nutzt ein
statisches Routing auf Basis der GWART. Der größte Nachteil ist, dass jeder
Server nur den Status seiner direkten Verbindungen kennt und nicht über
entfernte Verbindungen informiert ist. Beim Ausfall eines Konnectors werden
Nachrichten beim umleiten mehrfach übertragen und können schlimmstenfalls in
einer Schleife bis zur unzustellbarkeit enden. Jede Folgenachricht durchläuft
den gleichen Irrweg. Zudem ist die Übermittlung und Berechnung der Leitwege an
den Verzeichnisdienst gekoppelt und dementsprechend langsam.
(Schlagworte: Split Horizon)
Exchange 2000 nutzt eine neue
Technik zum Ermitteln der Leitwege. Dabei baut jeder Server eine komplette
Information aller Connectoren auf und pflegt dieser. Der Status von Verbindungen
wird über gesonderte Ports und SMTP Befehle an alle Server verbreitet. Nach sehr
kurzer Zeit haben alle Server den aktuellen Status aller Verbindungen und können
entsprechend die Leitwege optimiert berechnen. Ist ein Standort nicht mehr
erreichbar, verbleibt die Nachricht am letzten Server, bis die Leitwege wieder
einen erfolgreichen Weg aufweisen.
Fehlertoleranz Routinggruppen Konnectoren
Zur Fehlertoleranz werden
gerne mehrere Server installiert und verbunden. Allerdings bedeuten mehrere
Server auch aufwändigere Einstellungen. Wie einfach ist diese Konfiguration bzw.
wie viel administrativer Mehraufwand bedeutet eine Konfiguration mit mehreren
Konnectorservern
Es gibt keine
Routinggruppenconnectoren bei Exchange 5.5. Vergleichbar sind die
Standortverbindungskonnectoren (RPC), welche zwischen Standorten aufgebaut
werden und entsprechende eine funktionierende RPC Auflösung und Verbindung
benötigen. Aber Exchange 5.x hat die Schwäche, dass das Routing statisch ist und
der Ausfall einzelner Connectoren nicht oder nur sehr zögernd umgangen wird.
Routinggruppen werden mit
Konnectoren verbunden. Hierbei werden die jeweiligen Brückenkopfserver
definiert. Hierbei ist eine fehlertolerante Verbindung möglich, so dass zwischen
Routinggruppen mit einem Connector mehrere Verbindungen definiert werden. Dies
vereinfacht durch Übersichtlichkeit die Administration. Als Protokoll wird SMTP
genutzt, welches sehr viel toleranter ist.
Administrative Grenzen und Routinggrenzen
Oftmals sind Standorte
verteilt und meist ist nicht jeder Standort autark administriert. So wird es
Standorte geben, die aus der Ferne von einem Administrator mit verwaltet werden,
aber es kann auch Standorte geben, an denen zwei unabhängig Abteilungen
eigenständig die Administration ausführen. Kann das Nachrichtensystem diesen
Konstellationen Rechnungen tragen ?
Organisation und Standort sind
die einzigen Gliederungen einer Exchange 5.5. Umgebung. Dabei ist der Standort
(Site) zugleich sowohl administrative Grenze als auch für das Routing relevant.
Somit ist bei Exchange 5.5 diese Funktion nicht trennbar. Server an
verschiedenen Standorten sind auch administrativ getrennt.
erlaubt es durch den Einsatz von
Administrativen Gruppen (AG) und Routinggruppen (RG) diese Trennung zu lösen. In
administrativen Gruppen werden Server zusammengefasst, für die z.B. gleiche
Richtlinien gelten und von einem Administrator gesteuert werden. Andererseits können Server aus verschiedenen administrativen Gruppen durchaus in den gleichen
Routinggruppen sein und damit den Nachrichtenaustausch optimieren (?).
Zur Erinnerung: Die Konfiguration von Exchange 2000 liegt in der Konfigurationspartition des Active Directory und ist damit im gesamten Forrest repliziert. Durch die administrativen Gruppen können Rechte auf diese Active Directory Teilbereiche vergeben werden.
MTA Routing Engine
Nachrichten werden übertragen und müssen umgewandelt werden. Hierbei zählt, wie effektiv dieser Prozess
abläuft und welche Formate genutzt werden. Werden abgebrochene Verbindungen
wieder aufgenommen oder wird alles neu übertragen ? Werden parallele
Verbindungen genutzt oder verstopft eine große Nachricht die Leitung, so dass
kleinere Nachrichten warten müssen ?
Basierend auf der damals
existierenden Installation von großen Nachrichtensystemen auf Basis des
Standards X.400 wurde auch Exchange 4.0, 5.0 und 5.5 auf Basis von X.400
aufgesetzt. X.400 Adressen sind die wichtigen Adressen innerhalb von Exchange
zum Routen von Nachrichten.
Durch den Erfolg des Internets und die weltweite Nutzung von SMTP und MIME wurde auch die Exchange 2000
Nachrichtenübermittlung auf SMTP umgestellt. Die SMTP-Engine, welche Exchange
2000 nutzt ist sehr viel schnelle und robuster, als frühere Versionen und wird
auch vom Active Directory und anderen Diensten genutzt. Viele Funktionen von
SMTP (DNS Round Robin, parallele Verbindungen etc.) werden auch von Exchange
genutzt, so dass die Nachrichtenübermittlung schnell und sicher von statten
geht. Auch entfallen die umwandlungen von MIME in TNEF beim Übergang zwischen
den Servern und dem Internet. Dem trägt auch die Erweiterung der Datenbank um
die STM-Datei Rechnung.
SMTP sendet zudem parallel, so dass es immer mehrere gleichzeitige Verbindungen
geben kann und eine große Nachricht nicht die Warteschlange blockiert.
Internettauglichkeit
Internet ist die Welt, TCP/IP das Protokoll der Wahl und SMTP der Transport für Nachrichten. Zu Exchange 4.x Zeiten war die Entscheidung noch lange nicht so klar und X.400 ein wichtiger Standard für unternehmenssysteme. Aber das Internet hat so viel geändert und Exchange 2000 profitiert davon.
SMTP ist Standard
Das Internet ist das
Bindeglied zwischen allen Firmen und daher stellt sich die Frage, wie problemlos
sich der Server an die Standards hält und die effektiv dieser die Nachrichten
verarbeitet.
Die Basis ist ein X.400
ähnlicher MTA und ein 8-Bit Informationsspeicher mit dem Microsoft proprietären
TNEF Format. Jede Nachricht zum und vom Internet muss daher erst konvertiert
werden. Eben so jeder Zugriff auf den Informationsspeicher mit POP3, IMAP4 oder
OWA. Nur der reine Zugriff per Outlook belastet den Server weniger.
SMTP ist die Sprache des
Gesamtsystems. Exchange überträgt alle Nachrichten auch intern per SMTP. Sogar
das Active Directory repliziert sich wahlweise per SMTP. Die Datenbank kann
direkt MIME-Informationen speichern. Damit ist klar, dass Exchange 2000 sehr
viel effektiver mit dem Internet arbeiten kann, als Vorgängerversionen. Im
Betrieb werden die Daten für Outlook gewandelt, wenn diese angefragt werden.
OWA-Stabilität
Der Zugriff von überall ist
nicht nur Wunschtraum sondern Realität. Aber wenn viele Benutzer viele
Funktionen per Browser ausführen muss das Backend entsprechend robust und stabil und vor allem schnell sein.
Der Outlook
Webzugriff ist als eine Sammlung von ASP-Skripten für den Internet Information
Server realisiert. ASP-Skripte benötigen einiges an Performance und häufig ist
ein Restart des IIS notwendig um Speicher neu zu vergeben.
Exchange 2000 verzichtet
komplett auf ASP-Seiten, sondern realisiert die Umsetzung über einen
ISAPI-Filter und die generelle Fähigkeit des Informationsspeichers, per WebDAV
angesprochen zu werden. Damit ist nicht nur eine höhere Geschwindigkeit möglich,
sondern überhaupt eine stabilere Funktion.
OWA-Funktionalität
Standards im Internet werden
weiterentwickelt. WebDAV (Seit 1999 !)ist ein Beispiel dafür und entsprechende
Clients und Server können von diesen neuen Methoden profitieren, z.B. zur
Veränderung von Elementen im Informationsspeicher ohne die komplette Nachricht
zu übertragen.
Der Exchange 5.5 Zugang erlaubt
den einfachen Zugriff auf Mailelemente, Kalendereinträge, Kontakte und
öffentliche Ordner. Aber er unterstützt keine weitergehenden Funktionen, z.B.
Erinnerungen, Anzeige neuer Nachrichten oder weiter Formulare.
Der Exchange 2000 OWA nutzt die
Funktionen moderner Browser besser aus, indem einige Aktionen per WebDAV
durchgeführt werden. So ist es z.B. möglich, Elemente per Drag and Drop zwischen
Ordnern zu verschieben. Hierbei wird aber nicht die Nachricht übertragen sondern
quasi nur der Befehl zum Verschieben an den Server übertragen. ähnliches geht
auch um nur Teile einer Information zu verändern. Auch werden Erinnerungen und
neue Nachrichten automatisch angezeigt.
URL Adressierbarkeit
URLs wohin die Welt schaut.
Dateinamen, Laufwerksbuchstaben sind passé. Heute spricht die Welt in URLs um
die globale Verfügbarkeit und Adressierung von Informationen zu nutzen. Daher
ist es immer wichtiger, wenn jede Information, egal wo auch per URL erreichbar
wird. So wie schon ganze Dateiserver per URL erreichbar und durchsuchbar werden,
wird dies auch vom Nachrichtensystem erwartet. Dies erleichtert auch die
Integration in andere Webinhalte.
Die Elemente im
Informationsspeicher sind zwar per OWA erreichbar, aber die URLs sind nicht
aussagekräftig und auch schwer weiter zu verwenden. Insofern steht einer
Verknüpfung von Informationen im Informationsspeicher mit einer Intranetseite
oder Internetpräsenz einiges im Wege.
Jedes Element im
Informationsspeicher ist mit klaren und nachvollziehbaren URLs zu erreichen.
Daher ist es problemlos möglich, auch Verweise auf diese Elemente in anderen
Webseiten einzubauen. Auch die Funktionen wie „Neue Mail erstellen“ oder „Neues
Element im Ordner ablegen“ sind URLs (z.B.
http://servername/public/ordner1/?Cmd=new
oder um auf den Kalender eines Anwender (Rechte vorausgesetzt) zuzugreifen
reicht die URL http://server/exchange/Username/Kalender/?Cmd=contents .
Insofern ist die direkte Adressierbarkeit ein großer Fortschritt im Hinblick auf
die Integration von Datenbanken, Mailsystemen und Intranet in Knowledge
Managementsystem und Dokumentensystem a la SharePortal Server.
Instant Messaging
Neben Mail, Telefon und
Briefpost haben sich weitere Kommunikationsformen entwickelt. Dazu zählt auch
Instant Messaging, welches den Anwendern eine „Präsenzinformation“ über andere
Benutzer anbietet.
Es gibt keine IM-Funktion mit
Exchange 5.5.
Der zusätzlich installierte
IM-Server erlaubt die Integration von Echtzeitpräsenzinformationen mit Outlook und Exchange als zusätzlichen Kommunikationsweg im Intranet und Internet.
Allerdings wird diese Funktion im Nachfolger in einen eigenen Server
ausgelagert.
Konferenzfunktion
Mit der Zunahme von
videotauglichen Endgeräten und dem Preisverfall für digitale Videokameras
eröffnen sich neue Wege der Kommunikation. Über Programme wie
NetMeeting ist es
möglich, Daten, Audio und Video zu übertragen und gemeinsam an Dokumenten zu
arbeiten. Ein zentraler Server kann hier die Planung und Koordination der
Besprechungen übernehmen und die Datenpakete umsetzen (Stichwort Multicast).
.Es gibt keine Konferenzfunktion
mit Exchange 5.5.
Das Zusatzprodukt
Konferenzserver erlaubt die Nutzung von
NetMeeting und anderen kompatiblen
Programmen zur Bildung von virtuellen Konferenzen. Durch die Nutzung mit
Multicast im Intranet wird Bandbreite geschont.
EnterpriseUmfeld / Skalierbarkeit
Besonders interessant wird ein Nachrichtensystem wie Exchange, wenn es in größeren Umgebungen eingesetzt wird. Wenn es nicht nur um die Annahmen und Vorhaltung von neuen Nachrichten für POP3 Anwender geht, sondern um die Bereitstellung großer Datenmengen mit zugesagten Verfügbarkeiten geht.
Parallele Datensicherung
Datenmengen wachsen und die
Anwender senden und empfangen immer größere Nachrichten. Mittlerweile mit
Sprachnachrichten oder kompletten Videosequenzen. Parallel wachsen dazu die
Festplatten und Bandlaufwerkskapazitäten, aber solange der Zugriff sequentiell
erfolgt wird die Datensicherung nicht Schritt halten können.
Exchange 5.5 erlaubt über die
Backup API nur eine gleichzeitige Sicherung und Wiederherstellung der
Datenbanken. Besonders bei größeren Datenbanken ist dies ein großer Zeitbedarf,
der sich mit aktuellen Service Level Agreements nicht mehr vereinbaren lässt.
Durch den Einsatz mehrerer
Speichergruppen ist eine parallele Sicherung möglich. Jede Speichergruppe kann
separat gesichert werden. Durch den Einsatz mehrer Bandlaufwerke ist damit eine
sehr schnelle Sicherung möglich. Auch eine Wiederherstellung einzelner
Datenbanken ist möglich, ohne die anderen Datenbanken zu beeinträchtigen. Mit
mehreren Speichergruppen sind auch mehrere Restorevorgänge parallel möglich.
Trennung von Verzeichnis und Datenbank
Zu Verteilung von Lasten und
Sicherstellen der Verfügbarkeit ist es immer ein Ziel, Komponenten redundant und
mehrfach vorzuhalten.
Jeder Server hat genau eine
Verzeichnisdatenbank und einen Informationsspeicher mit einer festen Kopplung.
Muss ein Server sehr viel Adressen auflösen, dann kann er nicht einen Teil der
Last auf einen anderen Server verteilen. Fällt die DIR.EDB aus, ist der
komplette Server nicht funktionstüchtig.
Die Trennung von Verzeichnis und
Informationsspeicher und die Möglichkeit, mehrere Domaincontroller zu
installieren entspannt die Situation, dass beim Ausfall eines DCs Dienste nicht
mehr funktionieren würden. Mehrere DCs teilen sich zudem die Abfragen, so dass
hier eine höhere Skalierbarkeit und Fehlersicherheit erreicht wird.
Notbetrieb im Total Desaster Fall (alle EDB-Dateien weg)
Auch wenn nur wenige Server
wirklich „komplett ausfallen“ so ist es wichtig zu wissen, dass es Möglichkeiten
gibt, bei passende Planung sehr schnell wieder einen Notbetrieb fahren zu können. Gerade zeitkritische Umgebungen wie Bestellsysteme, Kliniken, Hotline,
Fernsehsender haben ein großes Interesse, möglichst schnell wieder „online“ zu
sein. Oftmals reicht es aus, Nachrichten senden und empfangen zu können und
frühere Informationen zu einem späteren Zeitpunkt wieder hinzufügen zu können.
Im dem Fall, dass der komplette
Server ausgefallen ist, steht eine komplette Installation mit Restauration der
Datenbanken an. Dies kann je nach Datenbestand einige Stunden dauern. In dieser
Zeit ist nicht mal ein Notbetrieb möglich.
Durch die Trennung von
Verzeichnis und Datenbank ist bei einem Ausfall des Exchangeservers das
Verzeichnis immer noch funktionsfähig. Dadurch sind „besondere“ Wege des
Recovery denkbar, z.B. die Installation eines Exchange 2000 Servers mit leere
Datenbank. Dies ist in kurzer Zeit erfolgt und die Anwender können mit einer
leeren Datenbank neue Nachrichten senden und empfangen. Die alten Daten können
nach einem Restore auf einem gesonderten Server z.B. nachts zusammengeführt
werden (EXMERGE).
Auch wenn dies ein etwas exotisches Beispiel ist, zeigt es doch um wie viel flexibler Exchange 2000 in der Handhabung und Administration ist.
Frontend/Backendstrukturen
Die Datenbank eines Messaging
Systems ist ein atomares Element, da diese meist nicht repliziert werden kann und daher auf einem Server steht. Daher wird das Ziel verfolgt, diese Komponente
hoch verfügbar zu halten, z.B.: indem andere Dienste ausgelagert werden oder ein
Cluster eingesetzt wird. Daher stellt sich die Grade, welche Funktionen auf
andere Server verlagert werden können.
Bei Exchange 5.5. können
OWA-Server vom eigentlichen Datenbankserver entfernt und auf eigenen Systemen
installiert werden. In gewissem Maße ist es möglich, eigene Server für Connectoren bereitzustellen. Wird ein Anwender von einem Server auf einen
anderen Server verlagert, so passt sich sein Outlook Profil dynamisch an.
Benutzer, die aber POP3/IMAP4/SMTP verwenden müssen aber ihre Konfiguration
meistens manuell anpassen.
Durch eigene Frontendserver kann
hier auch der Zugriff der Clients per POP3, IMAP4, SMTP und http vom Hauptserver
entfernt werden. Der Frontendserver kann dabei die Verschlüsselung (SSL)
übernehmen und so den Backendserver entlasten. Ein Frontendserver kann mehrere
Backendserver bedienen, so dass für den Anwender nur ein Server nach außen
bekannt wird. Mehrere Frontendserver können über Load Balancing verbunden
werden, um damit sowohl Leistung als auch Ausfallsicherheit zu steigern.
Nebenbei ist es durch den Einsatz von Frontend Servern kein Problem, Anwender
auf andere Server zu verschieben. Der Name der Servers bleibt für den Anwender
immer gleich.
Insofern ist Exchange 2000 gerade für ASP-Umfelder und große Installation ein deutlicher Gewinn.
Richtlinien und globale Konfiguration
Viele Server bedeutet auch
mehr Aufwand für Konfiguration. Änderungen an bestimmten Einstellungen müssen
meist an mehreren Servern vorgenommen werden. Interessant sind daher
Möglichkeiten, Einstellungen global oder auf bestimmte Servergruppen anzuwenden und damit den administrativen Aufwand zu reduzieren als auch die
Konfigurationssicherheit zu erhöhen
Viele Einstellungen werden
entweder pro Benutzer oder pro Server vorgenommen. Eine Zusammenfassung mehrere
Server in einer Gruppe um diese dann global zu konfigurieren ist bei Exchange
5.5. nicht vorgesehen. Einzig die Konfiguration einiger Protokolle auf der Ebene
des Standorts ist möglich.
Über Richtlinien, welche pro
administrativer Gruppe angelegt werden können sind viele Parameter einstellbar.
Werden die Server zur passenden Richtlinie zugeordnet, so wird diese
Konfiguration auf die entsprechenden Server angewendet. Neue Server müssen nur
der Richtlinie hinzugefügt werden, damit diese gleich eingestellt werden. So ist
einfach sicher zu stellen, dass Einstellungen über Server hinweg identisch sind.
Weiterhin sind Formateinstellungen für Internetdomänen, Adressbuchansichten etc. global zu konfigurieren. Einstellungen für SMTP Übermittlungen sind problemlos für mehrere Server in einem Aufwand zu konfigurieren.
Clustering
Wenn 99% Verfügbarkeit nicht
genug sind und auch die geplanten „Downzeiten“ durch Service Packs,
TreiberUpdates, Speichererweiterungen etc. reduziert werden sollen, dann
empfehlen sich Nonstop-Lösungen, d.h. technische und programmatische Lösungen, um Dienste gar nicht oder mit geringsten Ausfallzeiten funktionstüchtig zu
halten.
Der Enterprise Server unterstützt ein 2-Node Aktiv/Passiv Clustering, d.h. ein Knoten ist untätig und
wartet auf den Ausfall des ersten Knotens. Es findet keine Lastteilung statt.
Bis zu vier Knoten können in
einem Cluster zusammengefasst werden, wobei alle Knoten einen aktiven Exchange
Server betreiben können. Damit ist die Skalierbarkeit und der Nutzen der
Hardware höher. Es sind sowohl aktiv/aktiv als auch aktiv/passiv Konfigurationen
möglich.
Verfügbarkeit
Die Verfügbarkeit eines
Nachrichtensystems wird mehr uns mehr zu einem K.O.-Kriterium für die
Produktauswahl und den Betrieb. Während zu den Anfängen von Mail diese Medium
als nette Funktion eingestuft wurde, ist mittlerweile eine funktionierende
Messagingstruktur das Rückgrat vieler Firmen geworden und ein Arbeiten ohne
dieses nicht mehr denkbar.
Exchange 5.5.
ist ein sehr stabiles und robuste Produkt und hat seine Standfestigkeit und
Eignung in den letzten Jahren bewiesen. Aber es wurden auch Schwächen
offensichtlich, die im Design lagen und zur damaligen Projektierung so nicht
erkennbar gewesen sind. Zudem hat die Weiterentwicklung der Hardware und
Software neue Ansätze für eine hohe Verfügbarkeit gebracht, die Exchange 5.5
nicht nutzen kann.
Exchange 2000 ist eine komplette
Neuentwicklung und so konnten auch einige Designschwächen entfernt werden und
die Anforderungen von heute und der Zukunft mit berücksichtig werden. Dies kommt
speziell großen und verteilten unternehmen zu Gute, deren Anforderungen im Bezug
auf verteilte Administration, Skalierbarkeit und Verfügbarkeit höher sind, als
die Lösungen, die mit Exchange 5.5 heute realisierbar sind.
Programmierbarkeit
Kein System ist perfekt und oftmals sind es Kleinigkeiten, die mit einem ebenso kleinen Skript angepasst sind. Daher ist es wichtig zu wissen, welche Möglichkeiten
Event Scripting
Es sollte eine einfache
Möglichkeit geben, zusätzlich zu einem Regelmechanismus mit Skripten bestimmte
einfache Aufgaben zu erledigen. Diese sollten mit einem Client pflegbar sein.
Aber um alle Funktionen zu nutzen, sollte es auch für Programmierer moderne und
leistungsfähige Wege geben, um umfangreiche Lösungen zu realisieren.
Der eingebaute
Exchange Event Service unterstützt das asynchrone Abarbeiten von Skripte auf dem
Server. Die Skript werden mit VBScript oder Javaskript und Outlook erstellt.
Neben der eingeschränkten Geschwindigkeit sind die größten Probleme hierbei die
Verspätung der Ausführung. Auch können nur Skripte bei neuen oder geänderten
Elementen gestartet werden aber nicht beim Löschen
Auch hier gibt
es den Event Service, welcher zwecks Kompatibilität weiter erhalten wird.
Zusätzlich gibt es aber eine weitere Möglichkeit, sehr leistungsfähig Programme
zu verankern, welche die Nachrichten verändern können: Exchange 2000 unterstützt
Storeevents, Transportevents und Protokollevents. Hierbei sind auch synchrone
Events möglich, d.h. die Nachricht wird erst nach der Bearbeitung durch das
Skript an die nächste Instanz weitergegeben. Damit kann z.B.: durch ein Skript
das Löschen einer Nachricht verhindert werden. Ebenso können Nachrichten beim
Transport verändert werden, z.B. Anfügen eines Trailers oder löschen von Viren und Anlagen, oder auch einfach nur die Kompression der Nachrichten. Zuletzt
erlauben die Protokollsinks eine Erweiterung des SMTP-Service um eigene Befehle und Routinen, z.B. den Einbau eigener Authentifizierungsmethoden oder
zusätzlicher Prüfungen (ORDB.NET etc.)
Verzeichniszugriff ADSI
Eine Nachrichtensystem benutzt
eine Informationsquelle um die Anwender und deren Mailadressen zu speichern. Es
sollte einfach möglich sein, diese Informationen auch anderweitig zu nutzen als
auch per Skript zu verändern.
Der Exchange
Verzeichnisdienst zugleich LDAP-Provider und erlaubt einen Zugriff auf die
Exchange Verzeichnisdatenbank. Allerdings besteht keine direkte Verbindung zur
Domänendatenbank, so dass bei einem Zugriff und einer Änderung ein Einstellungen
in der Regeln beide Systeme angesprochen werden müssen.
Hier ist das
Active Directory der Verzeichnisdienst, welcher unter anderem auch die
Informationen über die Exchange Eigenschaften enthält. Es ist daher einfach
durch die Konfiguration in diesem einen Verzeichnis sowohl die Exchange
Informationen als auch die sonstigen Einstellungen anzupassen. Es entfällt die
doppelte Pflege von gemeinsamen Daten.
Zugriff per Storetreiber / WebDAV
Informationen, die in der
Datenbank liegen, sollten über mehre Wege erreichbar sein, einer der Wege ist
der Zugriff per http mit WebDAV oder per Dateisystem.
Kein direkter
einfacher Zugriff möglich.
Über einen auf
dem Server installierten IFS-Treiber ist ein direkte Zugriff auf die Datenbank
über einen Laufwerksbuchstaben möglich. Dies eröffnet für gewisse Zwecke einige
Möglichkeiten der Anwendung. Allerdings ist dieser Weg auch problematisch
bezüglich der Verwaltung der Rechte und sollte nicht durch Endanwender über eine
Freigabe genutzt werden.
Weiterhin ist es problemlos möglich, den Exchange Speicher per http zu
adressieren. Ebenso können die Inhalte per
XML genutzt werden.
Zugriff per ADO / EXOLE
Ein universeller Informationsspeicher ist um so leistungsfähiger, je umfangreicher
die Programmierschnittstellen sind. So ist es wichtig, sehr hoch angesiedelte
einfache Schnittstellen anzubieten, um mit wenig Code bestimmte Lösungen
schaffen zu können. Umgekehrt ist es auch wichtig, sehr schnelle Schnittstellen
anzubieten, bei denen der zu schreibende Code umfangreicher wird, aber alle
Möglichkeiten des Informationsspeichers genutzt werden können.
Keine
weiteren APIs nutzbar.
Zusätzlich zu
dem Zugriff per MAPI und CDO ist bei Exchange 2000 der Zugriff per ADO und EXOLE
möglich. Bei diesem Zugriff, der nur auf dem Server selbst möglich ist,
präsentiert sich die Exchange Datenbank vergleichbar eine SQL-Datenbank, bei der
die Nachrichten einfach Zeilen einer Tabelle sind und die Spalten aus dem
Betreff, dem Sender, dem Empfänger, der uhrzeit etc. bestehen. Damit steht eine
weitere sehr mächtige Schnittstelle zur Verfügung um eigene Anwendungen mit
Exchange 2000 zu installieren.
Lizenzen, Support und Update
Zuletzt kommt natürlich noch die Keule mit der Lizenz. Exchange 5.5 wird irgendwann sein Ende im Bezug auf Support, Updates, Fehlerkorrekturen erreichen und dies wird bald sein. Exchange 2000 ist schon seit Oktober 2000 auf dem Markt und damit lange eingeführt. Es gibt aber auch den Aspekt, dass immer weniger Zusatzsoftware für Exchange 5.x verfügbar sein wird und auch das Know-how der Mitarbeiter und Dienstleister immer geringer wird. Auch das ist sicher ein Grund, über ein Update nachzudenken.
Kann ich nicht auch mit NT4 und Exchange 5.5 starten ?
Diese Frage begegnet uns in Newsgroups auch immer wieder. Oftmals gibt es einen alten Server oder bestehende Lizenzen bzw. per ebay günstig ersteigert. Vielleicht hilft hier ein Vergleich:
Q: ... Und so kommt es das ein Kunde mit einer ersteigerten Exchange 5.5 zu mir kommt und mich fragt ob es sinn macht... 25 User von Outlook auf Exchange umzustellen...
A: Zu der Frage ist zuerst zu sagen, dass Sie genau genommen falsch gestellt ist. Sie können nicht von Outlook nach Exchange umstellen. Outlook ist der Client, Exchange ist der "Server". Aber wenn der Kunde bislang Outlook mit POP3/IMAP4 arbeitet und zur Ablage PST-Dateien nutzt, dann gibt es ein klares JA zu einer Migration nach Exchange. Exchange ist der beste Server hinter Outlook. Egal ob Version 5.5 oder 2000 oder 2003. Exchange 5.5 läuft wunderbar auf NT4 und Win2000, aber nicht mehr Windows 2003)
Q: Warum soll ich von NT4 und Exchange 5.5 umsteigen ?
A: Das gibt es keine pauschale Antwort. Fakt ist, dass in Windows 2003 einige Funktionen drin sind, die ich persönlich nicht mehr müssen möchte. Vergleichen wir es mal mit einem Auto: Vor vielen Jahren musste ein Auto erst einmal zuverlässig sein. Klimaanlage und Airbag waren aber noch "Luxus". Heute ist ein Airbag meist schon schon mehrfach "drin" und die Klimaanlage gehört sogar in ein Kleinwagen schon zum Standard. Deswegen sind die alten Autos ja nicht schlechter, aber es fehlt was. Da stellt sich dann nur die Frage: "kann Ich drauf verzichten" ? Es sind nicht die "großen Dinge", die ein neues Produkt erforderlich machen. Es sind die kleinen Dinge, auf die man aber nicht mehr verzichten kann. Oft sind es eben einige weniger Funktionen, die so wichtig bewertet werden, dass sich die Frage eigentlich nicht mehr stellt. Es ist auf jeden Fall teurer, wenn Sie eine alter Version nutzen und mit Nachrüstungen versuchen, einige Funktionen zu erhalten, die in der aktuellen Version einfach zum Standard gehören. Bei Exchange 2000/2003 ist dies eben z.B. Outlook Webzugriff, Pocket Outlook, RPC über Internet und andere Funktionen.
Weitere Links
- http://www.Microsoft.com/germany/produkte/features.asp?siteid=10571
- TechNet Exchange 2000 Update Series Kapitel 2