Der neue Hybrid Configuration Wizard ermöglicht es, heterogene Umgebungen mit lokal installierten Exchange-Servern und Office 365 einzurichten. Damit sich Organisationen mit Office 365 verbinden lassen, kann auch Exchange 2003/2007 im Einsatz sein. Bevor Sie den Assistenten verwenden, müssen Sie überprüfen, ob die für eine Zusammenarbeit notwendigen Voraussetzungen vorliegen. Der Assistent steht direkt im Aktionsbereich zur Verfügung, wenn Sie auf Organisationskonfiguration in der Exchange-Verwaltungskonsole klicken.
Allerdings muss in der Organisation mindestens ein Exchange 2010 SP2 Server vorhanden sein (Client-Access und Hub-Transport). Auf allen Servern muss das jeweils aktuelle Service Pack installiert sein, und das Unternehmen muss Office 365 Enterprise Edition einsetzen.
Mit dem Assistenten erstellen Sie notwendige Objekte im Active Directory und sammeln Konfigurationsdaten der Exchange-Umgebung und von Active Directory. Der Assistent erstellt eine neue akzeptierte Domäne, um E-Mail-Verkehr zwischen Office 365 und lokal installierten Exchange-Servern zu ermöglichen. Die Benutzer erhalten die neue Adresse als zweite E-Mail-Adresse automatisch zugeteilt. Über die Exchange-Verwaltungs-Shell lässt sich die Domäne mit
Get-AcceptedDomain | FL DomainName, IsCoexistenceDomain
anzeigen. Die Autodiscover-Konfiguration richtet ebenfalls der Assistent ein. Die entsprechende Protokolldatei befindet sich im Verzeichnis C:\Program Files\Microsoft\Exchange Server\V14\Logging\Update-HybridConfiguration.
Eine weitere Aufgabe des Assistenten ist es, die Verbundvertrauensstellung zwischen Office 365 und dem lokalen Active Directory zu überprüfen. Sind keine entsprechenden Konfigurationen vorhanden, erstellt der Assistent die Verbundvertrauensstellung. Frei/Gebucht-Zeiten synchronisieren die Server über den Assistenten ebenfalls. Ebenfalls wichtig für die Zusammenarbeit zwischen Office 365 und lokal installierten Servern sind gemeinsame Nachrichtenverfolgung, Mail-Tipps und Online-Archive. Für alle Anwender gibt es eine gemeinsame URL für Outlook Web App, egal wo die Postfächer gespeichert sind. Wenn der Assistent fehlerfrei durchgelaufen ist, lassen sich auch Postfächer zwischen den lokalen Exchange-Servern und Office 365 verschieben.
Da bei Office 365 Enterprise auch Forefront Online Protection for Exchange (FOPE) integriert ist, passt der Assistent die Sicherheitseinstellungen und Hub-Transport-Server für eine optimale Zusammenarbeit zwischen lokalen Servern, Office 365 und Forefront Online Protection for Exchange (FOPE) an. Dazu erstellt der Assistent zum Beispiel neue Sende- und Empfangs-Connectoren. So lässt sich beispielsweise festlegen, dass E-Mails von Benutzern in Office 365 entweder direkt zugestellt werden oder Office 365 die E-Mails erst zu den lokal betriebenen Hub-Transport-Servern sendet. Um den E-Mail-Fluss zwischen lokalen Servern und Office 365 zu sichern, lassen sich die Daten mit TLS verschlüsseln.
Address Book Policies - Adressbuchrichtlinien
Ebenfalls neu sind die Address Book Policies (ABP, Adressbuchlinien) im SP2 für Exchange 2010. Diese neuen Richtlinien lassen sich Postfächern zuordnen.
Address Book Policies legen fest, welche Postfächer aus der globalen Adressliste (GAL) für die Benutzer sichtbar sind, denen die ABP zugeordnet sind. Dazu müssen sich die Postfächer der Benutzer aber auf Servern mit Exchange 2010 SP2 befinden. Das heißt, Administratoren können auf diesem Weg verschiedene Ansichten der GAL für Benutzer erstellen.
Address Book Policies arbeiten nicht mit Office 365 zusammen. In Umgebungen mit lokal installierten Servern und Office 365 Enterprise sehen Benutzer in Office 365 immer das komplette globale Adressbuch.
Entsprechende Einstellungen nehmen Administratoren entweder in der Exchange-Verwaltungs-Shell über New-Mailbox oder Set-Mailbox und der neuen Option AddressBookPolicy vor oder in den Eigenschaften von Postfächern in der Exchange-Verwaltungskonsole. Auch beim Erstellen von neuen Postfächern ist ein Feld verfügbar, um vorhandene Richtlinien zu hinterlegen.
Adressbuchrichtlinien finden Sie über Organisationskonfiguration\Postfach auf der Registerkarte Adressbuchrichtlinien.
Cross-Site Silent Redirection for Outlook Web App
Mit Cross-Site Silent Redirection for Outlook Web App können Administratoren automatische Umleitungen zwischen Client-Zugriff-Servern erstellen. Greift ein Anwender auf einen solchen zu, kann der Server die Anfrage transparent zu einem besser geeigneten Server in einem anderen Active-Directory-Standort umleiten. Die Umleitung erfolgt auch mit Verwendung von Single-Sign-On. Anwender müssen sich also nur einmal anmelden.
Diese Umleitungen sind für Outlook Web App und Exchange ActiveSync geeignet. Der Einsatz ergibt aber nur dann Sinn, wenn im Unternehmen mehrere Active-Directory-Standorte im Einsatz sind. Bei Einrichten müssen Unternehmen darauf achten, dass jeder Client-Zugriff-Server auf den Anfragen von Benutzern umgeleitet werden können über eigene Zertifikate verfügen. Verwenden Sie keine selbst signierten Zertifikate, da Anwender dann beim Zugriff Zertifikatefehler erhalten können. Sie müssen für diese Funktion auf allen Client-Zugriff-Servern, die Sie verwenden, SSL konfigurieren. Nur dann ist eine fehlerfreie Weiterleitung möglich.
Wenn Sie vereinfachte URLs für den Zugriff auf Outlook Web App verwenden, müssen Sie bei der Konfiguration aufpassen, da Anwender ansonsten keinen Zugriff mehr auf OWA erhalten. Die Exchange-Entwickler gehen in ihrem Blog auf die Technik genauer ein
Outlook Web App Mini
Für Smartphones ohne Exchange-ActiveSync und Browser, die mit dem normalen Outlook Web App nicht optimal zusammenarbeiten, bietet Exchange 2010 SP2 nun die neue Mini-Version von Outlook Web App an.
Diese kennen Exchange-Administratoren schon aus der Outlook-Mobile-Access (OMA)-Funktion von Exchange Server 2003. Der Zugriff per neuer Version ist vor allem für Smartphones optimal, die keinen Exchange ActiveSync-Client nutzen und über schmalbandige Verbindungen zugreifen.
Outlook Web App Mini ermöglicht folgende Zugriffe ohne große Schnörkel und Grafiken:
• Zugriff auf E-Mail (inklusive Unterordner), Kalender, Kontakte, Aufgaben und die globale Adressliste
• Antworten und Weiterleiten von E-Mails
• Verwalten von Besprechungsanfragen und Abwesenheitsassistenten
Der Zugriff kann zum Beispiel direkt über den Link https://<Servername>/owa/oma erfolgen.
Mailbox Replication Service, Mailbox Replication Proxy und Multi-Valued Custom Attributes
Wenn ein Benutzer Vollzugriffsrechte für andere Postfächer hat, verbindet Outlook 2010 diese Postfächer automatisch. Dazu muss mindestens das SP1 für Exchange Server 2010 auf dem Server installiert sein. Diese Funktion ist zwar bequem, kann aber deutliche Leistungsprobleme verursachen, wenn ein Benutzer Vollzugriff auf sehr viele Postfächer hat. Aus diesem Grund lässt sich diese Funktion nach der Installation von SP2 für Exchange 2010 auch deaktivieren.
Dazu steht die neue Option Automapping mit dem Wert $false für das Add-MailboxPermission-Cmdlets zur Verfügung. Ein Beispiel für diesen Befehl sähe so aus:
Remove-MailboxPermission -Identity Joost -User 'Fynn Joos' -AccessRight FullAccess -InheritanceType All -Automapping $false
In der Exchange-Verwaltungskonsole können Sie diese Einstellungen nicht setzen.
Ebenfalls neu ist die Möglichkeit, Postfächern bis zu fünf selbst definierte Attribute zuzuweisen. Dazu gibt es die neuen Optionen ExtensionCustomAttribute1 bis ExtensionCustomAttribute5. Diese können bis zu 1.300 Werte einnehmen. Die Optionen stehen für folgende CMDlets zur Verfügung:
• Set-DistributionGroup
• Set-DynamicDistributionGroup
• Set-Mailbox
• Set-MailContact
• Set-MailPublicFolder
• Set-RemoteMailbox
Die Installation von SP2 deaktiviert die Funktion Mailbox Replication Proxy (MRSProxy). Damit ist kein Verschieben von Postfächern zwischen Organisationen mehr möglich. Sie können den Systemdienst nach der Installation aber jederzeit wieder aktivieren. Danach können Sie auch wieder Postfächer zwischen verschiedenen Exchange-Organisationen verschieben.
Litigation Hold
Nach der Installation von Exchange Server 2010 SP2 können Administrator Postfächer, die auf Litigation Hold gesetzt sind, weder deaktivieren noch löschen. Der Inhalt der Postfächer ist eingefroren, zum Beispiel für polizeiliche Ermittlungen oder Steuerprüfungen.
Die Einstellungen lassen sich mit der Option IgnoreLegalHold außer Kraft setzen, ohne Litigation Hold für ein Postfach zu deaktivieren. Die Option steht für folgende CMDlets zur Verfügung:
• Disable-Mailbox
• Remove-Mailbox
• Disable-RemoteMailbox
• Remove-RemoteMailbox
• Disable-MailUser
• Remove-MailUser
SP2 installieren - Schemaänderungen beachten
Die Installationsdatei des SP2 enthält alle verfügbaren Sprachen in einer einzelnen Installationsdatei. Das heißt, Administratoren müssen keine verschiedenen Sprachversionen für die Installation herunterladen. Außerdem enthält das SP2 auch alle Funktionen. die im Service Pack 1 enthalten sind. Die Patches bis zum Update Rollup 6 für SP1 sind ebenfalls enthalten. Administratoren müssen also nicht beide Service Packs installieren. Mit der Installationsdatei des SP2 lässt sich auch ein kompletter Exchange-Server installieren.
Das Service Pack 2 ändert auch einige Bereiche der rollenbasierten Berechtigungen (RBAC) ab. Es kann passieren, dass einige Warnungen erscheinen, wenn Sie RBAC benutzerdefiniert angepasst haben. In diesem Fall sollten Sie so schnell wie möglich alle Server in der Organisation auf SP2 aktualisieren.
Die Installation von SP2 für Exchange Server 2010 führt einige Änderungen am Active Directory-Schema durch. Welche Änderungen das sind, dokumentiert Microsoft in einem eigenen Dokument. Das Dokument enthält auch die generellen Änderungen, die Exchange Server 2010 im Active Directory-Schema durchführt. Sie können nach dem Entpacken der Installationsdateien des SP2 ebenso manuell das Schema aktualisieren. Dazu geben Sie den Befehl
setup /ps
ein. Der Befehl installiert kein SP2, sondern erweitert nur das Schema. Nach dem Abschluss können Sie mit
setup /p
noch das Active Directory vorbereiten.
Tipps zur Installation
Damit Sie das SP2 auf Client-Zugriff-Servern installieren können, müssen Sie zuvor einige Voraussetzungen installieren.
Dazu öffnen Sie in Windows Server 2008 R2 die PowerShell über das Kontextmenü mit Administratorrechten und verwenden das CMDlet Import-Module ServerManager. Anschließend installieren Sie die notwendigen Features mit
Add-WindowsFeature Web-WMI,Web-Asp-Net,Web-ISAPI-Filter,Web-Client-Auth,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Http-Redirect,Web-Http-Tracing,Web-Request-Monitor,Web-Static-Content
Sie können die Installationsdatei des SP2 auch so starten, dass Exchange die entsprechenden Voraussetzungen automatisch installiert. Dazu verwenden Sie den Befehl
Setup /Mode:Upgrade /InstallWindowsComponents
Wollen Sie einen komplett neuen Server mit Exchange Server 2010 SP2 installieren, starten Sie ebenfalls eine PowerShell über das Kontextmenü mit Administratorrechten und geben noch folgenden Befehl ein:
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart
Anschließend installieren Sie den kompletten Exchange-Server direkt mit den Installationsdateien des SP2.
Wenn Sie einen Server aktualisieren, sollten Sie den Exchange-Virenscanner, den Sie im Einsatz haben, deaktivieren. Zusätzlich sollten Sie überprüfen, ob der Scanner auch kompatibel zum SP2 ist. Die Datensicherung sowie die Überwachung durch andere Server sollten Sie während der Aktualisierung deaktivieren, um Fehler bei der Installation zu vermeiden.
Um die Installation zu überprüfen, verwenden Sie am besten die Exchange-Verwaltungs-Shell und geben den Befehl
get-exchangeserver |fl Name, AdminDisplayVersion
ein. Als AdminDisplayVersion wird Version 14.2 (Build 247.5) erscheinen. Beim Einsatz von Exchange Server 2010 SP1 erscheint Version 14.1 (Build 218.15).
Die Installationsroutine von Exchange Server 2010 führt eine eigene Logdatei, in der alle Informationen der Installation gespeichert sind. Diese Datei trägt die Bezeichnung ExchangeSetup.log und wird im Verzeichnis C:\ExchangeSetupLogs abgelegt. Hier speichert der Installationsassistent alle Informationen, die während der Installation anfallen. Wenn Sie den entsprechenden Fehler in einer Suchmaschine eingeben, finden Sie meist ausführliche Hilfen zum Problem.
Die Logdateien der Exchange Server 2010-Installation liegen im Textformat vor. Sie können diese Datei auch während der Installation aufrufen, wenn Sie das Gefühl haben die Installation einer Rolle dauert zu lange. Tritt ein Fehler während der Installation auf, wartet das Setup-Programm häufig nach verschiedenen Intervallen und hält den Fehler auch in der Logdatei fest. So können Sie bereits nach dem Fehler suchen, während Exchange noch versucht, den Server zu installieren. Entsprechende Fehler sehen Sie dann am Ende der Datei. (mje)