Exchange Fragen & AntwortenOutlook Anywhere und IPv6, der Remote Connectivity Analyzer und mehr

Henrik Walther

F: Wir haben die Bereitstellung von Exchange 2007 auf Windows Server 2008-basierten Servern in unserer Organisation beendet, und alles funktioniert – bis auf eine Ausnahme – sehr gut. Obwohl wir Outlook Anywhere (früher RPC-über-HTTP genannt) entsprechend dem Vorgehen in der Exchange 2007-Dokumentation auf Microsoft TechNet konfiguriert haben, können wir von einem Outlook 2007-Client im Internet keine Verbindung zu den Exchange 2007-Clientzugriffsservern herstellen, was immer wir auch versuchen. Wir haben sichergestellt, dass der Client dem SAN-Zertifikat vertraut und dass TCP-Port 443 der mit den Clientzugriffsservern verbundenen Firewall offen ist. Ist Ihnen dieses Problem bekannt?

A: Ja, das ist es. Sie haben erwähnt, dass Exchange 2007 auf Windows Server 2008-basierten Servern installiert wurde. Wenn ein Clientzugriffsserver auf einem Windows Server 2008-Server installiert wurde, muss beachtet werden, dass Outlook Anywhere nicht richtig funktioniert, wenn IPv6 auf dem Server aktiviert ist. Da IPv6 standardmäßig aktiviert ist, wenn Exchange 2007 SP1 auf Windows Server 2008 installiert ist, muss es deaktiviert werden. Mir sind mehrere Fälle bekannt, wo das Problem dadurch behoben wurde.

Weitere Informationen dazu, warum Outlook Anywhere und IPv6 unter Windows Server 2008 eine schlechte Kombination sind, und wie Sie IPv6 richtig auf Windows 2008-Servern deaktivieren können, ohne Exchange 2007 zu beeinträchtigen, finden Sie im Blogbeitrag des Exchange-Teams bei Microsoft unter msexchangeteam.com/archive/2008/06/20/449053.aspx. Dieses Problem sollte mit Exchange 2007 SP1 Rollup 4 behoben werden.

F: Ich implementiere derzeit Outlook Anywhere und Exchange ActiveSync in unserer Exchange 2007-basierten Messagingumgebung, und ich würde gerne wissen, ob irgendwie getestet werden kann, ob Outlook Anywhere auf der anderen Seite unseres Umkreisnetzwerks wie erwartet funktionieren wird. Außerdem möchte ich sichergehen, dass der AutoErmittlungsdienst in unserer Umgebung richtig konfiguriert wurde. Können Sie mir ein paar Hinweise geben?

A: Ja, es ist möglich zu testen, ob Outlook Anywhere ordnungsgemäß funktioniert. Zwei Microsoft-Mitarbeiter (Shawn McGrath aus der Exchange-Produktgruppe und Brad Hughes vom Produktsupport) haben ein webbasiertes Tool erstellt, das Exchange Server Remote Connectivity Analyzer (ExRCA) heißt. Das Tool (in Abbildung 1) sollte als Prototyp betrachtet werden, aber ich habe keine Fehler oder ungewöhnliches Verhalten feststellen können. Das Tool kann Outlook 2007-AutoErmittlung und RPC/HTTP-Konnektivitätstests durchführen. Zudem kann es testen, ob Exchange ActiveSync und der eingehende SMTP-E-Mail-Verkehr wie erwartet funktionieren. Obwohl ExRCA derzeit von Microsoft nicht unterstützt wird, empfehle ich das Tool für Tests der Remotekonnektivität bei Exchange 2007.

Abbildung 1 Startseite des Exchange Server Remote Connectivity Analyzer (zum Vergrößern auf das Bild klicken)

F: Unsere Organisation, die Exchange Server 2007 verwendet, befindet sich in der Planungsphase für die Bereitstellung der fortlaufenden Standbyreplikation (Standby Continuous Replication, SCR). Wir wünschen einen zweiten Datensatz für jede Postfachdatenbank, die auf unseren nicht gruppierten Exchange 2007 SP1-Postfachservern an einem anderen Standort erstellt wird. Wir haben viel über SCR in der Exchange 2007-Dokumentation auf Microsoft TechNet gelesen, haben aber immer noch eine Frage, die dort nicht beantwortet wird: Wenn wir ein SCR-Ziel aktivieren, hat dies dann dieselbe Wirkung wie MoveMailbox, wobei der –ConfigurationOnly-Parameter für alle Benutzerpostfächer in einer bestimmten Postfachdatenbank angegeben ist? Das heißt, es muss nur der Exchange-Serverstandort im Active Directory geändert werden.

A: Da Sie nicht gruppierte Postfachserver (die auch als eigenständige Postfachserver bezeichnet werden) als SCR-Quellserver verwenden, liegen Sie richtig. Da Sie die SCR-Kopie auf einem anderen Server aktivieren werden, wird Datenbankportabilität verwendet. Dies bedeutet, dass sich der Exchange-Serverstandort in Active Directory für die Benutzerpostfächer in der jeweiligen Postfachdatenbank ändern wird.

Wenn die SCR-Quellserver in Ihrer Exchange 2007-Umgebung entweder CCR- (clustered continuous replication, fortlaufende Clusterreplikation) oder SCC-basiert (single copy cluster, Einzelkopiecluster) sind und Sie einen passiven Knoten in einem Failovercluster als SCR-Ziel verwenden, würden Sie das SCR-Ziel gleichen Namens aktivieren, und der Exchange-Serverstandort in Active Directory würde sich nicht ändern.

F: Wir haben gerade die Bereitstellung von Exchange Server 2007 in unserer Unternehmensumgebung abgeschlossen und fragen uns, ob das Verschieben der sechs Exchange 2007-Sicherheitsgruppen, die vom Exchange 2007-Setup beim Vorbereiten der Gesamtstruktur und Domänen für die Installation von Exchange 2007 erstellt wurden, in eine andere Organisationseinheit anstelle der in der Stammdomäne erstellten Microsoft Exchange-Sicherheitsgruppen-Organisationseinheit unterstützt wird.

A: Im Unterschied zu Exchange 2000/2003, wo es nicht möglich war, die Exchange-Gruppen in eine andere Organisationseinheit innerhalb der Gesamtstruktur zu verschieben, wird dies von Exchange 2007 unterstützt. Sie sehen, dass die sechs Exchange 2007-Sicherheitsgruppen (siehe Abbildung 2), die bei der Vorbereitung der Gesamtstruktur für Exchange 2007 erstellt wurden, mit zwei eindeutigen Eigenschaften gestempelt sind. Bei der ersten handelt es sich um eine bekannte GUID und bei der zweiten um einen Distinguished Name, der sich ändern kann.

Abbildung 2 Exchange Server 2007-Sicherheitsgruppen (zum Vergrößern auf das Bild klicken)

Diese beiden Eigenschaften und die Tatsache, dass sie beim Ausführen des Setup dem OtherWellKnownObjects-Attribut der jeweiligen Gesamtstruktur hinzugefügt werden, stellen sicher, dass Exchange die Sicherheitsgruppen überall in der Gesamtstruktur finden kann. Sie können die Gruppen also nach Belieben verschieben – sogar in eine andere Domäne in der Gesamtstruktur! Zusätzliche Details sind in dem hervorragenden Artikel „Exchange 2007-Berechtigungen: Häufig gestellte Fragen“ von Ross Smith (technet.microsoft.com/bb310792) in der Exchange 2007-Dokumentation auf Microsoft TechNet enthalten.

F: Aufgrund einer Umstrukturierung in unserer Exchange 2007-basierten Messagingumgebung möchten wir den Dateifreigabenzeugen für alle unsere Exchange 2007-CCR-Postfachserver auf einen anderen Hubtransportserver verschieben. Gibt es Informationen dazu, wie dies unterstützt durchgeführt werden kann?

A: Das Verschieben des Dateifreigabenzeugen von einem Exchange 2007-Hubtransportserver auf einen anderen ist sehr einfach. Sie verwenden dabei einfach die Schritte, die Sie befolgt haben, als der Dateifreigabenzeuge anfänglich für Ihre Postfachclusterserver konfiguriert wurde. Der einzige Unterschied besteht in dem Pfad, der für den Server angegeben wird. Die entsprechenden Schritte sind im Abschnitt „Konfigurieren des Dateifreigabenzeugen“ in der Exchange 2007-Dokumentation auf Microsoft TechNet enthalten (siehe technet.microsoft.com/bb124922).

Sie sollten wissen, dass bei Verwendung eines CNAME-Datensatzes beim Verweisen auf Ihren Hubtransportserver, als der Dateifreigabenzeuge konfiguriert wurde, einfach nur der vollqualifizierte Domänennamen (fully qualified domain name, FQDN) des Zielhosts geändert werden muss, auf den der Alias des jeweiligen CNAME-Datensatzes verweist (siehe Abbildung 3).

Abbildung 3 CNAME-Datensatz, der auf einen Zielhost für einen Dateifreigabenzeugen verweist (zum Vergrößern auf das Bild klicken)

Bedenken Sie jedoch, dass sich bei Vorhandensein von Clusterknoten an verschiedenen Standorten die Standortsicherheitsanweisung der Exchange-Produktgruppe geändert hat (siehe msexchangeteam.com/archive/2008/04/03/448615.aspx). Grundsätzlich empfiehlt die Exchange-Produktgruppe nicht mehr die Verwendung von CNAME-Datensätzen in Exchange 2007-Geo-Cluster-Umgebungen.

F: Wir planen die Verbesserung der Sicherheitseinstellungen für die Exchange 2007-Messagingserver in unserer Organisation. Ein Teil unseres Sicherheitsoptimierungsplans besteht im Verschlüsseln der Volumes, auf denen sich die Exchange-Datenbanken befinden. Wir fragen uns, ob es empfehlenswert ist bzw. überhaupt unterstützt wird, Exchange-Datenbankdateien auf einem Volume zu speichern, das mithilfe des verschlüsselnden Dateisystems (Encrypting File System, EFS) verschlüsselt wurde.

A: Die Antwort ist ein klares Nein. Das Platzieren von Exchange 2007-Datenbanken auf einem EFS-basierten, verschlüsselten Volume wird von Microsoft nicht unterstützt. Es wird für .edb-, .log-, .stm- (Exchange 2000/2003), .dat-, .eml- und .chk-Dateien nicht unterstützt. Der Hauptgrund besteht darin, dass diese Art der Verschlüsselung zu zusätzlichem Aufwand führt, der sich entscheidend auf die Leistung auswirkt.

Um Ihre Exchange 2007-Dateien zusätzlich zu sichern, sollten Sie nicht autorisierten Zugriff auf den Exchange-Computer verhindern und das S/MIME-Nachrichtenformat zum Verschlüsseln der Nachrichtendaten verwenden. Wenn Sie Exchange 2007 unter Windows Server 2008 installieren, sollten Sie BitLocker zum Schützen der Volumes in Betracht ziehen.

F: Ich habe gerade Exchange 2007 SP1 auf einem Windows Server 2008-Server installiert, der gleichzeitig ein Domänencontroller ist. Da ich IPv6 in dieser Umgebung nicht verwende, habe ich es unter „Netzwerkverbindungen“ deaktiviert, nachdem Exchange 2007 SP1 installiert worden war, und dann den Server neu gestartet. Als er wieder online war, wurden die Exchange 2007-Dienste nicht mehr gestartet. Fehler 214, der im Anwendungsprotokoll protokolliert ist, enthält folgende Informationen:

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=1712). Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).

A: Ich kenne mehrere Berichte zu diesem Verhalten. Obwohl es keine gute Vorgehensweise ist, die Exchange 2007-Serverfunktionen auf einem Windows Server 2008-Server zu installieren, der auch als Domänencontroller dient, sollte die Ausführung einer oder mehrerer Exchange 2007-Serverfunktionen auf einem Domänencontroller bei deaktiviertem IPv6 funktionieren, zumal dies ein häufiges Szenario in Testumgebungen und anderswo ist. Die Lösung besteht derzeit darin, IPv6 auf dem Server wieder zu aktivieren. Angeblich soll Exchange 2007 SP1 Rollup 4 dieses Problem lösen.

Henrik Walther ist Microsoft Certified Master für Exchange 2007 und Exchange-MVP mit über 14 Jahren Erfahrung im IT-Bereich. Er arbeitet als Technologiearchitekt für Interprise Consulting (einen „Gold Partner“ von Microsoft für Infrastruktur mit Sitz in Dänemark) und als Autor technischer Artikel für Biblioso (ein Unternehmen mit Sitz in den USA, das auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert ist).