Exchange 2010

Artikel
08/31/2016

Detaillierte Informationen

Henrik Walther

Die kürzlich veröffentlichte RTM-Version (Release To Manufacturing) von Microsoft Exchange 2010 verfügt wie die Vorgängerversionen über eine Fülle neuer Features und Verbesserungen gegenüber vorhandenen Versionen. In der Tat umfasst Exchange in dieser Version jetzt etwa 21 Millionen Quelltextzeilen.

Die Exchange-Entwickler hatten sich für Exchange 2010 fünf Hauptziele gesteckt: Organisationen darin zu unterstützen, einen neuen Grad an Zuverlässigkeit, höhere Leistungsfähigkeit, vereinfachte Verwaltung, verbesserten Schutz der Korrespondenz und optimierte geschäftliche Mobilität für Benutzer zu erreichen. Kurz gesagt: Vor dem Hintergrund der globalen Wirtschaftskrise wollten sie ein flexibleres und optimiertes Produkt entwickeln, das eine Kostenreduzierung im Betrieb einer Exchange 2010-Infrastruktur ermöglichte.

Seit April 2008 habe ich eine Menge Zeit damit verbracht, Betaversionen und Release Candidate-Builds von Exchange 2010 sowohl in meinen Testumgebungen als auch in den Umgebungen von zwei Unternehmenskunden zu testen. In diesem Artikel stelle ich Ihnen die interessantesten Änderungen und Verbesserungen dieser neuesten und zweifellos bislang besten Exchange-Version vor.

Verwaltungarchitektur

Mit Exchange 2007 führte Microsoft eine Verwaltungsarchitektur ein, die auf Windows PowerShell 1.0 und Microsoft .NET Framework 2.0 Runtime basierte. Nachdem die Exchange-Administratoren gelernt hatten, mit dieser Shell zu arbeiten, fanden sie schnell neue Möglichkeiten zur Optimierung des Betriebs. Es überrascht nicht, dass Microsoft auch in der Verwaltungsarchitektur von Exchange 2010 Windows PowerShell (2.0) und Microsoft .NET Framework (3.5) Runtime einsetzt. Von den Windows PowerShell 2.0-Verbesserungen wird in Exchange 2010 unter anderem das PowerShell-Remotingfeature verwendet. Dieses Feature nutzt die WS-Verwaltung, eine Windows-Komponente, welche die organisationsweite Verwaltung von Servern, Geräten und Anwendungen erleichtert.

Bei Exchange 2007 ermöglicht die Exchange-Verwaltungsshell Administratoren, alle Exchange 2007-Server von einem einzigen Verwaltungsserver aus zu verwalten. Die Cmdlets werden im Host/Prozess des Verwaltungsservers ausgeführt. Der Verwaltungsserver stellt dann RPC-Verbindungen mit den zu bearbeitenden Exchange-Servern her. Durch das Remotingfeature von Windows PowerShell 2.0 wird die Verwaltung weiter vereinfacht. Das Remotingfeature stellt Standardprotokolle zur Verwaltung von Exchange 2010-Server über Firewalls zur Verfügung und trennt explizit die client- und serverseitigen Anteile der Cmdlet-Verarbeitung. Darüber hinaus ermöglicht die WS-Verwaltung eine nahtlosere Integration in das Betriebssystem Windows als Windows PowerShell 1.0.

Gleichgültig, ob die lokalen Exchange-Verwaltungstools oder dedizierte Verwaltungsserver verwendet werden, wird beim Start der Exchange-Verwaltungskonsole bzw. der Exchange-Verwaltungsshell immer eine "Remoteverbindung" hergestellt. Exchange 2010 stellt eine Verbindung mit dem lokalen virtuellen Verzeichnis von Windows PowerShell her, das innerhalb der Standardwebsite von IIS-Manager angelegt wird, wenn die Exchange 2010-Verwaltungstools auf einem Computer installiert werden (siehe Abbildung 1).

Abbildung 1 Virtuelles Verzeichnis für Windows PowerShell 2.0 in IIS Manager

Wenn die Exchange-Verwaltungskonsole oder -shell eine Verbindung mit dem virtuellen Verzeichnis für Windows PowerShell herstellt, werden die notwenigen Cmdlets – genauer gesagt: die Verweise auf diese Cmdlets – von der Serverseite (Runspace) in die clientseitige Sitzung importiert. Nachdem die Cmdlet-Verweise importiert wurden, können Sie Exchange 2010 genauso verwalten, wie üblicherweise Exchange 2007-Server verwaltet werden.

Beim Einsatz der Exchange-Verwaltungsshell können Sie eine Windows PowerShell-Sitzung erstellen, die eine neue Verbindung mit einem externen Exchange 2010-Server herstellt. Daraufhin werden alle Befehle, die Sie von der Shell auf dem lokalen Server aufrufen, direkt auf dem externen Exchange 2010-Server ausgeführt, mit dem sie verbunden sind.

Weil die Exchange-Verwaltungskonsole auf der Verwaltungsshell basiert und im Hintergrund Windows PowerShell-Befehle ausführt, verhält sich die Verwaltungskonsole genauso wie die Shell. Sie können sogar über die Konsole eine Verbindung mit einem Exchange 2010-Server in einer anderen Exchange-Gesamtstruktur herstellen und diesen verwalten (siehe Abbildung 2).

In der Tat können Sie nicht nur weitere Exchange-Organisationen der Konsole hinzufügen, sondern auch Postfächern zwischen Exchange-Organisationen verschieben (siehe Abbildung 3).

Abbildung 2 Mehrere Exchange-Gesamtstrukturen in der Exchange-Verwaltungskonsole

Abbildung 3 Der neue Assistent für Verschiebungsanforderungen in Exchange 2010

Bereitschaft für das Cloud-Computing
Schlussendlich werden Sie in der Lage sein, von der Exchange-Verwaltungskonsole und der Exchange-Verwaltungsshell aus Exchange Online zu verwalten, eine der Software-plus-Services-Lösungen von Microsoft. Das wird möglich sein, sobald Microsoft die Aktualisierung von Exchange Online zu Exchange 2010 durchgeführt hat. Gegenwärtig basiert Exchange Online auf Exchange 2007. Organisationen erhalten damit die Möglichkeit, eine Vor-Ort-Lösung, einen gehosteten Dienst oder eine Mischung aus beiden zu wählen und sie nahtlos zu verwalten.

Microsoft hat dies bereits Bildungseinrichtungen ermöglicht, die am Microsoft Live@edu-Programm teilnehmen, sowie Microsoft-Mitarbeitern, die ihre eigene persönliche Domäne in Microsoft Exchange Labs hosten, die bereits mehr als 10 Millionen Postfächer umfassen.

Berechtigungsmodell

Exchange 2010 erweitert das auf Zugriffssteuerungseinträgen (ACE) basierende Berechtigungsmodell, das Microsoft mit Exchange 2007 einführte, um eine neue Autorisierungsebene mit rollenbasierter Zugriffssteuerung (RBAC). RBAC ermöglicht die Definition breiter oder präziser Berechtigungen, die auf den Rollen von Administratoren oder speziellen Endanwendern basieren. Das bedeutet, dass Sie Ihr Berechtigungsmodell in Exchange 2010 entsprechend dem Organisationsmodell definieren können, ohne die Komplexität zu erhöhen. Für die meisten Unternehmen sollten die Standardrollengruppen in Exchange 2010 ausreichen. Sie können jedoch bei Bedarf benutzerdefinierte Rollengruppen erstellen.

Anders ausgedrückt: RBAC steuert jetzt operative und verwaltungstechnische Aufgaben, spezielle Benutzeraufgaben und das Ausmaß, in dem Benutzer ihre Postfächer, Verteilergruppen usw. selbst verwalten können.

MAPI- und Verzeichniszugriff in der mittleren Schicht

In Exchange 2007 stellt der Clientzugriffsserver den Verbindungsendpunkt für alle Clients dar, ausgenommen Outlook (Messaging Application Programming Interface, kurz MAPI) und Entourage (Web-Based Distributed Authoring and Versioning, kurz WebDAV). Dadurch wurde eine beträchtliche Menge an Bearbeitungsaufgaben verlagert, die in früheren Exchange 2007-Versionen von Back-End-Postfächern bewältigt wurden.

In Exchange 2010 geht Microsoft mit der Einführung des RPC-Clientzugriffsdiensts einen Schritt weiter. Dieser Dienst verschiebt Verbindungen für den MAPI- und Verzeichniszugriff auf Clientzugriffsserver der mittleren Schicht. Deswegen stellen MAPI-Clients beim Öffnen eines Postfachs keine direkte Verbindung mit dem Postfachserver mehr hier. Stattdessen stellen sie eine Verbindung mit dem RPC-Clientzugriffsdienst her, der wiederum mit dem Active Directory- und dem Postfachserver kommuniziert. Für Verzeichnisinformationen kontaktiert Outlook einen NSPI-Endpunkt (Name Service Provider Interface) am Clientzugriffsserver, und NSPI kommuniziert über den Active Directory-Treiber mit Active Directory. Der NSPI-Endpunkt ersetzt die DSProxy-Komponente, die wir von Exchange 2007 her kennen.

Dies ist insofern anders als bei Outlook Anywhere- bzw. RPC-über-HTTP-Clients, die eine Verbindung mit einem Postfach in Exchange 2007 herstellen, als sich diese Clients mit der RPC-Proxykomponente am Clientzugriffsserver verknüpfen. Außerdem kommunizieren sie per MAPI über RPC direkt mit dem Postfachserver und mit dem NSPI-Endpunkt in Active Directory.

Der RPC-Clientzugriffsdienst hat einige Vorteile. Erstens verfügt Exchange nun, da MAPI- und Verzeichnisverbindungen in die Clientzugriffsserverrolle der mittleren Schicht verlagert wurden, über einen gemeinsamen Pfad für den Datenzugriff. Dies ermöglicht nicht nur eine konsistentere Anwendung von Geschäftslogik auf Clients, sondern sorgt auch für ein viel besseres Clientverhalten während eines Serverwechsels oder Failovers unter Verwendung des neuen Features DAG (Database Availability Group), auf das ich später näher eingehe. Verbindungsunterbrechungen zwischen Server und Outlook-Clients dauern möglicherweise 30 Sekunden statt der wenigen Minuten – in Wahrheit bis zu 30 Minuten –, die in komplexen Active Directory-Topologien mit fortlaufender Clusterreplikation (Cluster Continuous Replication, CCR) in Exchange 2007-Clustern üblich sind.

Schließlich lässt die Verwendung eines gemeinsamen Pfads für alle Datenzugriffsvorgänge mehr gleichzeitige Verbindungen und Postfächer pro Postfachserver zu. In Exchange 2007 konnte ein Postfachserver 64.000 Verbindungen verwalten. Dem gegenüber steht die RPC-Kontexthandlebeschränkung von 250.000 in Exchange 2010. Da Clientzugriffsserver in Exchange 2010 eine immer wichtigere Rolle spielen, müssen Clients in der Lage sein, im Fall geplanter oder ungeplanter Ausfallzeiten schnell von einem Clientzugriffsserver zu einem anderen zu wechseln und dort wieder eine Verbindung herzustellen. Hier kommt das neue Clientzugriffsarray von Exchange ins Spiel. Wie der Name schon sagt, handelt es sich hierbei um ein Array von Clientzugriffsservern. Genauer gesagt: Das Array umfasst alle Clientzugriffsserver des Active Directory-Standorts, für den es erstellt wurde. Statt über den vollqualifizierten Domänennamen (FQDN, Fully Qualified Domain Name) eine Verbindung mit dem betreffenden Clientzugriffsserver herzustellen, verbindet sich der Outlook-Client mit dem FQDN des Arrays (z. B. outlook.contoso.com). Damit wird sichergestellt, dass die Verbindung von Outlook-Clients, die über MAPI über RPC kommunizieren, ununterbrochen aufrechterhalten wird. Das Array ist auch in einem Attribut von Postfachserverdatenbanken am Active Directory-Standort enthalten. Auf diese Weise wird gewährleistet, dass das Array weiß, an welche Postfachserver und Datenbank ein Benutzer geleitet werden soll. Wenn Sie die Postfachdatenbanken mit dem neuen DAG-Feature schützen und eine Kopie einer solchen Datenbank an einem anderen Active Directory-Standort aktiviert wird, dann kommuniziert der Clientzugriffsserver über RPC direkt mit dem Postfachserver, auf dem die Datenbankkopie gespeichert wurde. Dies ist ein wichtiges Detail.

Der Windows-Netzwerklastenausgleich kann in Verbindung mit einem Clientzugriffsarray verwendet werden, sofern die Postfachserverrolle weder auf dem Server installiert wurde noch durch DAG geschützt wird. Natürlich kann ein Clientzugriffsarray in Verbindung mit einem externen Hardwaregerät zum Lastenausgleich eingesetzt werden. Denken Sie jedoch daran, dass das Array nur für Outlook-RPC-Clients geeignet ist. Bei Diensten, wie z. B. Outlook Web Access, AutoErmittlung, ActiveSync und die Verfügbarkeitsdienste, arbeiten Sie immer noch mit dem traditionellen Windows-Netzwerklastenausgleich oder einem externen Lastenausgleich.

Speicheroptimierung

Dank der 64-Bit-Architektur und der geringeren Anzahl von E/A-Vorgängen pro Sekunde (bis zu 70 Prozent), schuf Exchange 2007 eine viel effizientere Speicherumgebung als es mit den Vorgängerversionen möglich war. Bei Exchange 2010 konzentrierte Microsoft seine Anstrengungen zur Speicheroptimierung auf die Bereitstellung großer (+10 GB), schneller Postfächer und nutzte den billigen Speicher.

Aufgrund von Änderungen am ESE-Modul (Extensible Storage Engine), können Sie beim Einsatz von Exchange 2010 jetzt Datenträger mit einem mäßigen Leistungsverhalten verwenden, wie SATA-Festplatten (d. h. Tier-2-Datenträger). Ja, ich spreche von den 7200 SATA-Datenträgern, die denen in Ihrer Arbeitsstation ähneln. Wenn Sie das DAG-Feature für hohe Verfügbarkeit verwenden und drei oder mehr Datenbankkopien besitzen, dann können Sie beispielsweise eine 7200-RPM-Festplatte zum Speichern einer Datenbankkopie und der zugehörigen Protokolldaten benutzen. Mit anderen Worten, Sie müssen nicht mehr kleine und schnelle Festplatten in einem RAID konfigurieren. Stattdessen können Sie die Datenbanken auf großen und langsamen Datenträgern in einer JBOD-Konfiguration speichern.

Microsoft hat hauptsächlich durch eine wichtige Änderung im altbekannten Speicherschema bedeutende Verbesserungen in der Speicherleistung erreicht. Im Grunde genommen wollten die Exchange 2010-Entwickler von vielen, wahlfreien, kleinen E/A-Vorgängen hin zu einer kleineren Anzahl von sequenziellen, großen E/A-Vorgängen kommen. Die Umstellung von wahlfreien zu sequenziellen E/A-Vorgängen erforderte drastische Änderungen an der Speichertabellenarchitektur.

In Exchange 2007 und früheren Versionen enthielt jede Datenbank eine Postfachtabelle (mit allen in der Datenbank gespeicherten Postfächern), eine Ordnertabelle (mit den Postfachordnern der in der Datenbank enthaltenen Postfächer), eine Nachrichtentabelle (mit den gespeicherten Nachrichten), eine Anlagentabelle (mit den Anlagen für die Postfächer der Datenbank) und eine Nachrichten/Ordnertabelle (mit Ordneransichten für alle Postfächer der Datenbank). In dieser Architektur, die sich seit Exchange 4.0 kaum verändert hat, müssen eine Menge wahlfreier E/A-Vorgänge für die Datenbank ausgeführt werden. Ein Vorteil dieser Architektur besteht in der Einzelinstanz-Speicherung (Single-Instance Storage, SIS), bei der nur einen Kopie einer Nachricht gespeichert wird, und das war damals, als relativ kleine Datenträger gängig waren, ein großer Vorteil. Aber heute, da uns 500-GB-SAS-Datenträger und 2-TB-SATA-Datenträger zur Verfügung stehen, ist diese Architektur nicht mehr sinnvoll.

In Exchange 2010 werden alle in einem Postfach enthaltenen Daten eng zusammen liegend in Tabellen in der Datenbank gespeichert. Jedes Postfach verfügt über einen eigenen Ordner, Nachrichtenkopf, Nachrichtentext und Ansichtstabellen. Die Einzelinstanz-Speicherung wird in Exchange-Datenbanken also nicht mehr verwendet. Ein Nebeneffekt der Entfernung von SIS aus Exchange besteht in der Aufblähung der Datenbank um ca. 20 Prozent. Zur Lösung dieses Problems komprimierten die Exchange-Entwickler die Datenbanken (genauer gesagt, Nachrichtenköpfe und -text bzw. HTML-Nachrichtentexte). Da jedem Postfach ein eigener Tabellensatz zugeordnet wird, sind die für die Datenbank durchgeführten E/A-Vorgänge meist sequenziell.

Interessant sind auch die folgenden Änderungen: Datenbanken wird ein zusammenhängender Speicherbereich zugewiesen; der Datenbankzusammenhang wird aufrecht erhalten; die Datenbankseitengröße beträgt jetzt 32 KB, statt früher 8 KB; und die Funktion zum asynchronen Lesen wurde verbessert. Die Exchange-Produktgruppe steigerte auch die Effizienz der Zwischenspeicherung deutlich, indem bei Hochverfügbarkeitskonfigurationen die Prüfpunkttiefe in 100 MB geändert wurde, wobei Cachekomprimierung und Datenbankcacheprioritäten zum Einsatz kommen.

Infolge dieser Änderungen in Exchange 2010 können Sie bis zu 70 Prozent weniger E/A-Vorgänge gegenüber Exchange 2007 erwarten. Das ist wirklich eine ESE-Optimierung.

Entwicklung der fortlaufenden Replikation in Exchange

Vor Exchange 2007 bot Microsoft nur sehr eingeschränkte Features für hohe Verfügbarkeit und Notfallwiederherstellung. IT-Manager konnten Microsoft Cluster Server einsetzen, um auf der Hardwareebene für Redundanz zu sorgen, das Speichersubsystem bildete jedoch eine einzelne Fehlerquelle. Um Redundanz auf der Speicherebene zu erreichen, mussten Organisationen in Replikationsprodukte von Drittanbietern investieren.

Bei Exchange 2007 verbesserte Microsoft diese Situation durch eine Fülle von Features für hohe Verfügbarkeit Notfallwiederherstellung, darunter die äußerst erfolgreiche fortlaufende Clusterreplikation (, Continuous Cluster Replication, CCR). Bei dieser Clusterreplikationstechnologie wird asynchrone Replikationstechnologie mit Windows-Failoverclustering kombiniert, um Hardware- und Speicherredundanz, hohe Verfügbare und keine einzelne Fehlerquelle bereitzustellen.

Microsoft ging durch die Einführung der fortlaufenden Standbyreplikation (Standby Continuous Replication, SCR) in Exchange 2007 SP1 auf den Bedarf an standortübergreifender Flexibilität ein. SCR ermöglicht die Übermittlung von Protokolldateien zwischen gruppierten und nicht gruppierten Postfachservern. SCR ermöglicht es der IT-Abteilung, eine Wiedergabeverzögerung von bis zu sieben Tagen festzulegen, und das bedeutet, dass die meisten Datenbank-/Speicherprobleme behoben werden können, bevor sie sich auf das SCR-Ziel in einem anderen Rechenzentrum auswirken können.

Microsoft hat CCR und SCR in Exchange 2010 sogar noch weiter verbessert, indem diese beiden Features in der DAG kombiniert wurden, dem neuen Feature für fortlaufende Verfügbarkeit, das ich bereits oben erwähnte. Eine DAG ist wie die CCR noch von einem eingeschränkten Satz der Windows-Failoverclustering-Komponente abhängig, hauptsächlich der Clusterdatenbank, Dateifreigabenzeuge und Taktsignalfunktionalität. DAGs bieten Schutz auf der Datenbank, Server- und Standortebene und erleichtern die Bereitstellung einer standortbezogenen Lösung für hohe Verfügbarkeit und Notfallwiederherstellung erheblich gegenüber früheren Exchange-Versionen.

Die DAG arbeitet wie CCR und SCR mit der asynchronen Replikation. In einer DAG können bis zu 16 Kopien einer Postfachdatenbank erstellt werden. Zu einem gegebenen Zeitpunkt ist eine Kopie einer gegebenen Postbankdatenbank aktiv. Wenn diese Datenbank ausfällt, aktiviert eine DAG-Komponente namens Active Manager automatisch eine der anderen Kopien. Weil die Outlook-Clients jetzt Verbindungen mit den Clientzugriffsservern herstellen (direkt oder über ein Clientzugriffsarray), bemerken die Benutzer kaum einen Failovervorgang oder Wechsel zu einer anderen Datenbankkopie der DAG.

In Exchange 2010 sind die geschützten Datenbanken jetzt auf der Organisationsebene angesiedelt (siehe Abbildung 4).

Abbildung 4 Durch DAG auf der Organisationsebene geschützte Datenbanken

Das bedeutet, dass die Speichergruppen, die wir von Exchange 2007 und früheren Versionen her kennen, in Exchange 2010 keinen Platz haben. Jede Datenbank in Exchange 2010 verfügt jedoch über einen zugehörigen Satz an Protokolldateien, weil diese neue Version wie die Vorgängerversionen das ACID (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit)-Modell verwendet.

Bei Exchange 2010 hat Microsoft die Anzahl von Datenbanken auf einem Server mit Exchange 2010 Enterprise Edition auf 100 gegenüber 50 in Exchange 2007 erhöht. Erwähnenswert ist auch, dass für DAG-Mitglieder zwar Windows 2008 Enterprise Edition (wegen der Abhängigkeit von einigen Windows-Failoverclusteringfeatures) benötigt wird, hier aber sowohl Exchange 2010 Standard als auch Enterprise Editions in DAGs verwendet werden können. Denken Sie jedoch daran, dass die Standard Edition ist auf 5 Datenbanken pro Postfachserver beschränkt ist.

Eine DAG lässt sich viel einfacher bereitstellen und verwalten als ein CCR-Cluster, weil beispielsweise alle erforderlichen Schritte in der Exchange-Verwaltungskonsole oder Exchange-Verwaltungsshell ausgeführt werden können. Die Clusterbildung ist direkt in Exchange integriert und für den Administrator unmerklich. Sie können sich daher von den Clusteringfertigkeiten und den speziellen Verwaltungstools für Ihre ständig verfügbare Exchange-Lösung verabschieden. Sogar DAG-Szenarien mit mehreren Standorten sind einfacher bereitzustellen und zu verwalten, und Sie können jetzt, anders als bei CCR, DAG-Mitgliedsserver in verschiedenen Active Directory-Standorten lokalisieren. Das bedeutet, dass Sie den Active Directory-Standort nicht mehr über verschiedene physische Standorte ausdehnen müssen. Das war bei CCR-Clustern, die mehrere Standorte umfassten, in Exchange 2007 nicht möglich.

Verbesserungen hinsichtlich der Mobilität

Bei jeder neuen Exchange-Version konnte Microsoft mit interessanten Änderungen bei der Exchange-Mobilität aufwarten. Die Rede ist hier von Outlook Web App (OWA), vormals Outlook Web Access genannt, und Exchange ActiveSync. Exchange 2010 ist da keine Ausnahme.

Outlook Web App
Microsoft hat in der Tat so viele Änderungen an OWA vorgenommen, dass diese Technologie einen eigenen Artikel verdient. Dazu einige Beispiele:

Der Anwesenheitsstatus ist in OWA integriert (siehe Abbildung 5). Das bedeutet, dass Sie mit der Office Communications Server-Lösung Ihren Anwesenheitsstatus sehen und ändern und auch den Anwesenheitsstatus anderer Personen anzeigen können (Sie können auch Fremdanbieterlösungen integrieren). Benutzer können sogar von der OWA-Schnittstelle aus anderen Benutzer Sofortnachrichten senden. Die Benutzer können in OWA ihre Office Communicator-Kontaktliste verwalten, die im linken Bereich angezeigt werden kann.

Die erstklassige Browserunterstützung umfasst jetzt Mozilla Firefox 3+ und Safari 3+ für Mac sowie natürlich Internet Explorer (Version 7 und höher).
Die Benutzer können SMS (Short Message Service)-Nachrichten direkt in OWA (bzw. Outlook 2010) schreiben und empfangen, statt sie auf einem Mobilgerät eingeben zu müssen. OWA sendet die SMS über Ihr Mobilgerät, auf dem die Antworten eingehen. Sie können sogar SMS-Nachrichten mit Benutzerpostfächern synchronisieren, damit sie zentral gespeichert und gesichert werden.
In Exchange 2010 wurde eine neue Unterhaltungsansicht mit OWA (und Outlook 2010 und Windows Mobile mit der neuen Outlook Mobile-Version) eingeführt. Hinter der Unterhaltungsansicht steht die Absicht, die Informationsflut im Postfach eines Benutzers zu bändigen. Mit diesem Feature werden alle Nachrichten, die zu einer Unterhaltung gehören, zusammen in einer einfachen und logischen Ansicht dargstellt, sodass der Benutzer schnell ungelesene Nachrichten erkennen und die Antwortfolge der Unterhaltung ablesen kann. Die Unterhaltungsansicht bleibt auch dann intakt, wenn Nachrichten aus dem Posteingang in andere Ordner verschoben werden. Der Benutzer kann Unterhaltungen als Ganzes verwalten, ignorieren, verschieben und löschen, statt auf jede einzelne Nachricht reagieren zu müssen.
Eine Exchange-Systemsteuerung ersetzt die Seite Optionen, die wir aus früheren OWA-Versionen kennen (siehe Abbildung 6). Von dieser Systemsteuerung aus können die Benutzer herkömmliche OWA-Einstellungen verwalten, aber auch eigene Nachrichten verfolgen, mit den erforderlichen RBAC-Berechtigungen Verteilergruppen erstellen und moderieren und Ähnliches tun. Überdies können die Benutzer jetzt persönliche Active Directory-Daten, z. B. Name, Titel, Abteilung und Telefonnummer, aktualisieren.

Abbildung 5 Die Benutzeroberfläche von OWA 2010

Abbildung 6 OWA 2010 Exchange-Systemsteuerung

ActiveSync von Exchange
Exchange ActiveSync gilt als De-facto-Standard, der festlegt, wie mobile Geräte mit einem Postfach synchronisiert werden. Mit Exchange 2010 wurden einige interessante neue Features für auf ActiveSync basierende Clients eingeführt:

Exchange-Administratoren können Geräte jetzt nach Typ oder Benutzer genehmigen, nicht unterstützte Telefone blockieren und für unbekannte Telefone Quarantäne erzwingen. Blockierte Telefone können sich nicht mit dem Postfach synchronisieren. In Quarantäne versetzte Telefone können dagegen synchronisiert werden, sofern der Administrator dies genehmigt. Mit der neuen Outlook Mobile-Version, die zum Lieferumfang von Windows Mobile 6.5 gehört, können die Benutzer jetzt Frei-/Gebucht-Informationen abrufen. Wenn die Eigenschaftenseite eines Kontakts geöffnet wird, wird eine Zeitachse angezeigt, die der von OWA 2007 ähnelt. Diese Zeitachse ist sogar farbkodiert.
Exchange 2010 unterstützt auch den Spitznamen-Cache auf Windows Mobile-Geräten, da der Cache jetzt zentral im Postfach des Benutzers gespeichert wird.
Microsoft lässt raffinierterweise jetzt zu, dass Windows Mobile-Geräte, auf denen Windows Mobile 6.1 oder höher ausgeführt wird, den neuen Outlook Mobile-Client (der zum Lieferumfang von Windows Mobile 6.5 gehört) als CAB-Datei herunterladen. Wenn die Benutzer ihr Windows Mobile 6.1-Gerät zum ersten Mal mit ihrem Postfach synchronisieren, erhalten sie automatisch eine E-Mail-Nachricht mit einem Link zur neuen Outlook Mobile-Version. Auf diese Weise können die Benutzer in einem Unternehmen die neuen Exchange/Outlook Mobile-Features nutzen, die in Exchange 2010 eingeführt wurden, ohne in neue Windows Mobile 6.5-Geräte investieren zu müssen.

UnifiedMessaging

Obwohl die Architektur nicht verändert wurde, hat Microsoft das UnifiedMessaging in Exchange 2010 verbessert und erweitert. Zu den eindruckvollsten Investitionen gehören Mailbox-Vorschau, geschützte Mailbox, Anzeige wartender Nachrichten, Anrufbeantwortungsregeln und Unterstützung weiterer Sprachpakete.

Die Mailbox-Vorschau stellt dem Benutzer eine Textübersetzung von Mailbox-Sprachnachrichten in Outlook und OWA zur Verfügung. Folglich müssen die Benutzer keine traditionellen Mailbox-Nachrichten mehr abhören, was viele als mühsam empfinden. Stattdessen können sie die Sprachnachricht als Textnachricht in ihrem E-Mail-Client lesen. Beim Einsatz von Outlook 2010 wird der Text der Sprachnachricht sogar analysiert und in Aktionselemente gegliedert, sodass Namen, Kontakte und Telefonnummern erkannt werden und darauf geklickt werden kann. Die Mailbox-Vorschau ist auch auf Windows Mobile-Geräten möglich. In der Mailbox-Vorschau werden anfangs die Sprachen Englisch (USA), Englisch (Kanada), Französisch, Portugiesisch, Italienisch und Polnisch unterstützt. Wenn Exchange 2010 SP1 im nächsten Jahr auf den Markt kommt, werden weitere Sprachen unterstützt werden.
Bei einer geschützten Mailbox werden die Mailbox-Nachrichten mithilfe der Active Directory-Rechteverwaltungsdienste geschützt. Der Benutzer kann beispielsweise Mailbox-Nachrichten als private Nachrichten markieren, damit diese nicht an andere Empfänger weitergeleitet werden können. Die Benutzer können dies zwar selbst tun, allerdings kann diese Einstellung auch über eine Verwaltungsrichtlinie gesteuert werden.
Die Anzeige für wartende Nachricht benachrichtigt den Benutzer über das Vorliegen und die Anzahl neuer/ungelesener Mailbox-Nachrichten bei den unterstützten Schreibtischtelefonen. Mit diesem Feature können die Benutzer sogar eine Mailbox-Vorschau in Form von SMS-Nachrichten erhalten.
Anrufbeantwortungsregeln, ein weiteres, neues Feature von Exchange 2010, funktioniert ähnlich wie die traditionellen Posteingangsregeln für E-Mail-Nachrichten, gelten jedoch für eingehende Anrufe. Die Benutzer können eine Art persönlichen Anrufbeantworter definieren, der ein Menü zur Steuerung eingehender Anrufe beinhalten kann. Beispielsweise können die Benutzer Regeln definieren, die anhand von Kriterien wie Tageszeit, Anrufer-ID, dem eigenen Terminkalender usw. festlegen, wie Anrufe behandelt werden sollen. Mithilfe von Anrufbeantwortungsregeln können die Benutzer auch eigene Menüs für eingehende Anrufe erstellen.
Die Exchange 2010 RTM-Version bietet Unterstützung für 16 Sprachpakete, und weitere 10 Pakete werden bald erscheinen.

Archivierung und Aufbewahrung

In den letzten Jahren hat die Fähigkeit, Geschäftsdaten effizient aufbewahren zu können, zunehmend an Bedeutung gewonnen. Hierzu gehört insbesondere der E-Mail-Verkehr, der in den meisten Unternehmen die Hauptdatenquelle in behördlichen Ermittlungen und anderen Untersuchungen sind, die die Einhaltung behördlicher Bestimmungen betreffen.

Eine auf Compliance ausgerichtete Verwaltung von E-Mail-Nachrichten stellt lange ein Problem für Unternehmen dar, sogar als in Exchange 2007 verschiedene Schutz- und Compliance-Features eingeführt wurden, wie z. B. Messaging-Datensatzverwaltung, Transportregeln und Journalregeln. In Exchange 2010 wird das Konzept der so genannten Aufbewahrungsrichtlinien eingeführt. Aufbewahrungsrichtlinien sind Bestandteil der Messaging-Datensatzverwaltung von Exchange 2010 und ersetzen die verwalteten Ordner.

Exchange 2010 löst auch das Problem der Postfachgrößenbeschränkung, die Benutzer früherer Versionen zwingt, E-Mail-Nachrichten zur Archivierung in lokale PST-Dateien zu verschieben, wodurch das Compliance-Management für Administratoren zusätzlich erschwert wird.

Zur Lösung des PST-Problems bietet Exchange 2010 ein neues persönliches Archivierungsfeature. Der Exchange-Administrator kann jetzt Online-Archivpostfächer für Benutzer bereitstellen, sodass keine Offline-PST-Dateien mehr erforderlich sind. Das neue Onlinearchiv wird in Outlook 2010 und OWA 2010 angezeigt, und Outlook 2010 unterstützt sogar das Verschieben von PST-Inhalten in das Onlinearchiv per Drag & Drop. Exchange-Administratoren können auch Aufbewahrungsrichtlinien konfigurieren, damit Nachrichten automatisch in das Onlinearchiv verschoben werden, beispielsweise Nachrichten, die älter als ein Jahr sind.

Exchange 2010 enthält auch neue Funktionen, die es Benutzern aus Rechts- oder Compliance-Abteilungen ermöglichen, mehrere Postfächer gleichzeitig zu durchsuchen und Nachrichten sofort aus juristischen Gründen sicherzustellen, wodurch die sofortige Konservierung von gelöschten oder bearbeiteten Postfachelementen eines Benutzers ermöglicht.

Dank dieser neuen Features lassen sich Unternehmensdaten einfacher und flexibler kontrollieren als mit früheren Exchange-Implementierungen.

Neues Organisationsverbundmodell

Bei Exchange 2007 und früheren Versionen war es etwas unkomfortabel und mitunter kompliziert, mehrere Exchange-Gesamtstrukturen in einem Unternehmen oder in verschiedenen Unternehmen in einem Verbund zusammenzufassen. Um die Frei-/Gebucht-Informationen zwischen Exchange 2000/2003-Organisationen austauschen zu können, mussten zuerst alle gewünschten E-Mail-Benutzer von einer Organisation in denn anderen Organisationen als Kontaktobjekt repliziert werden. Hierzu wurde der GALSync Management Agent verwendet, der Bestandteil des Forefront Identity Manager (FIM) war, früher auch Microsoft Identity Integration Server und ILM genannt. Die Frei-/Gebucht-Informationen mussten mit einem Tool wie IOREPL (Inter-Organization Replication) über öffentliche Ordner repliziert werden. In Exchange 2007 war die Sache etwas einfacher. Hier können Frei-/Gebucht-Informationen mithilfe des Verfügbarkeitsdiensts zwischen Exchange 2007-Organisationen ausgetauscht werden. Genauer gesagt, Sie verwenden das Add-AvailabilityAddressSpace-Cmndlet, um die gemeinsame Nutzung von Frei-/Gebucht-Informationen zwischen Organisationen einzurichten. Leider wird zwischen den beteiligten Organisationen keine Vertrauensstellung definiert, und die gemeinsame Nutzung von Frei-/Gebucht-Informationen durch verschiedene Gesamtstrukturen ist nur beschränkt möglich.

Mit den neuen Verbundfeatures von Exchange 2010 können Frei-/Gebucht-Informationen, Kalender und Kontakte von verschiedenen Gesamtstrukturen gemeinsam genutzt werden. Denken Sie jedoch daran, dass die Verbundfeatures von Exchange 2010 voraussetzen, dass in allen beteiligten Organisationen Exchange 2010 bereitgestellt wurde. Es muss keine reine Exchange 2010-Organisation sein. Wegen einiger Proxyverbesserungen in Exchange 2007 SP2 können die Vorteile der neuen Verbundfeatures in Organisationen, die Exchange 2010 und 2007 SP2 verwenden, genutzt werden, sofern mindestens ein Exchange 2010-Clientzugriffsserver bereitgestellt wurde.

Das Verbundfeature von Exchange 2010 verwendet einen neuen auf Windows Live basierenden Dienst, der auch als Microsoft Federation Gateway (MFG) bezeichnet wird. Der MFG ist in der Cloud angesiedelt und fungiert im Grunde als Trust-Broker zwischen Exchange 2010-Organisationen, die Daten gemeinsam nutzen möchten (siehe Abbildung 7). Es muss betont werden, dass ein Microsoft-Gateway verwendet wird, um Verbundvertrauensstellungen zwischen Exchange 2010-Organisationen einzurichten. Es werden keine Daten der beteiligten Exchange-Organisationen an Microsoft weitergegeben. Organisationen verwenden einfach den MFG, um die Sicherheit zu gewährleisten, wenn sie Informationen über ihre Domäne veröffentlichen und den Domänenzugriff auf Daten ermöglichen.

Abbildung 7 Der neue Assistent für Verbundvertrauensstellungen in der Exchange 2010-Verwaltungskonsole

Die neuen Verbundfeatures erfordern weder eine Vertrauensstellung noch die Datenreplikation zwischen den beteiligten Organisationen. Um die Frei-/Gebucht-Informationen eines Benutzers aus einer anderen Organisation anzuzeigen, gibt ein Benutzer von Outlook 2010 oder OWA 2010 einfach die E-Mail-Adresse dieser Person in den Terminplanungs-Assistenten ein. (In Outlook 2007 müssen die E-Mail-Benutzer der anderen Organisation repliziert werden, damit sie in der lokalen globalen Adressliste angezeigt werden.) Die Features zur gemeinsamen Nutzung von Kalender und Kontakten erfordern OWA 2010 oder Outlook 2010.

Sie können mithilfe von Freigaberichtlinien genau festlegen, welche Daten und auf welcher Ebene diese Daten freigegeben werden sollen. Und mit der organisationsbezogenen Freigaberichtlinie können Sie eine Freigaberichtlinie erstellen. Hier können Sie angeben, wie viele Informationen und mit welchen Domänen die Benutzer Daten austauschen können sollen (siehe Abbildung 8).

Abbildung 8 Der neue Assistent für Beziehungen zwischen Organisationen in der Exchange 2010-Verwaltungskonsole

Verschiedene neue Features

Kurz gesagt, die folgenden anderen neuen Features sind in Exchange 2010 verfügbar:

Online-Postfach verschieben In Exchange 2010 wurde der Assistent zum Verschieben von Postfächern durch zwei Assistenten ersetzt, die Anforderungen nach einer lokalen Verschiebung bzw. einer Remoteverschiebung handhaben und verschiedene Vorteile mit sich bringen. Beispielsweise kann der Administrator jetzt Postfächer während der Geschäftszeiten verschieben, da das Postfach, das verschoben wird, während dieses Vorgangs nicht offline geschaltet wird. Die Benutzer können sogar E-Mail-Nachrichten senden und empfangen, auf die globale Adressliste (GAL) zugreifen, Sitzungen planen und Ähnliches tun, während das Postfach verschoben wird. Außerdem können mit der Exchange-Verwaltungskonsole Postfächer zwischen Exchange-Gesamtstrukturen verschoben werden.

E-Mail-Info E-Mail-Infos ermöglichen es dem Sender einer E-Mail-Nachricht, informative Nachrichten anzuzeigen, während er eine E-Mail-Nachricht in Outlook 2010 oder OWA 2010 verfasst. Microsoft hat verschiedene E-Mail-Infos erstellt, Sie können jedoch eigene E-Mail-Infos hinzufügen. Zu den Standard-E-Mail-Infos gehören ungültige interne Empfänger (wenn der Benutzer oder die Gruppe, die im Feld An: oder CC: angegeben wird, nicht in Active Directory vorhanden ist), Postfach voll (das Postfach des Empfängers ist voll), automatische Antworten (Abwesenheitsnotiz oder andere automatische Antworten), eingeschränkter Empfänger (basierend auf Richtlinie), Größenüberschreitungsmeldung (Nachricht ist größer als die Einstellung für Sende- oder Empfangsgröße, Nachrichtengröße oder Anforderungslänge) und große Zielgruppe (wenn Nachrichten an Gruppen mit mehr als 25 Mitgliedern gesendet werden).

Transportstabilität Auch Schattenredundanz (Shadow Redundancy) genannt, diese neue Funktionalität stellt sicher, dass Nachrichten nicht vom sendenden Hub-Transport-Server gelöscht werden, bevor der Ziel-Hub-Transport-Server die Nachrichtenübermittlung bestätigt. Bei Exchange 2007 gingen bei einem Ausfall der Datenbank mit der Nachrichtenwarteschlange die darin enthaltenen Nachrichten verloren. Dank dieses Redundanzfeatures kann dies in Exchange 2010 nicht passieren. Sie können also einen ausgefallenen Hub-Transport-Server einfach austauschen, indem Sie ihn aus der Produktionsumgebung entfernen, ohne die Warteschlangen zuvor leeren zu müssen. Außerdem ist damit keine Speicherhardwareredundanz mehr erforderlich, was sich unmittelbar auf die Kosten auswirkt.

Dynamische Signaturen Sie können jetzt (über Transportregeln) persönliche Signaturen, Firmensignaturen oder Haftungsausschlüsse bereitstellen, die HTML, bestimmte Schriftarten, Firmenlogos (sogar animierte GIFs) enthalten, und die Werte DisplayName, FirstName, LastName, Department und Company beim Erstellen von Active Directory-Benutzern verwenden.

Moderation von Verteilergruppen Es ist jetzt möglich, moderierte Verteilergruppen zu konfigurieren, bei denen ein Moderator eine Nachricht akzeptieren muss, bevor diese an die Gruppenmitglieder gesendet wird. Die Gruppenmitgliedschaft kann mit der neuen Exchange-Systemsteuerung in OWA 2010 verwaltet werden. Benutzern können Berechtigungen zugewiesen werden, sodass sie eigene Verteilergruppen in der Exchange-Systemsteuerung erstellen können.

Verwaltung von Massenvorgängen in der Exchange-Verwaltungskonsole Sie können jetzt in der Exchange-Verwaltungskonsole die Empfänger von Massenvorgängen verwalten. Beispielsweise können Sie jetzt in einem Massenvorgang Benutzerpostfächer verschieben, entfernen, deaktivieren und aktivieren. Sie können sogar die Empfängereigenschaften bearbeiten, wenn der gleiche Empfängertyp ausgewählt wurde.

Senden von E-Mail Wenn Outlook auf dem gleichen Computer wie die Exchange-Verwaltungstools installiert wurde, können Sie E-Mail-Nachrichten an ein Benutzerpostfach, einen Mail-Kontakt oder Verteilergruppen senden.

Verwalten von Ordnerberechtigungen Mit Exchange 2010 können Sie Outlook-Ordnerberechtigungen mit den neuen Cmdlets Add-MailboxFolderPermission, Get-MailboxFolderPermission und Remove-MailboxFolderPermission verwalten.

Exchange 2010 bietet viele neue und interessante Features und Verbesserungen gegenüber vorhandenen Versionen. Zweifellos ist Exchange 2010 eine umfassende, bestechende und flexible Messaginglösung für Unternehmen jeder Größe.

Freigeben über