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