Exchange Fragen & AntwortenAusrichten von Festplattenpartitionen, Planen für SCR und mehr

Henrik Walther

F: Ich plane derzeit eine Migration von Exchange Server 2003 zu einer neuen Exchange Server 2007-Organisation. Um öffentliche Ordner auf die neue Organisation zu replizieren, habe ich vor, das Microsoft® IORepl-Tool (Inter-Organization Replication) zu verwenden. Ich habe aber gehört, dass IORepl nicht mit einem Exchange 2007-Zielserver unterstützt wird und dass stattdessen der Ziel-Exchange-Organisation ein Exchange 2003-Server hinzugefügt werden muss.

A: Obwohl es Gerüchte gab, dass das Replizieren von freien/genutzten Daten oder öffentlichen Ordnern zwischen einer Exchange 2003-Organisation und einer reinen Exchange 2007-Organisation nicht unterstützt wird, ist dies nicht wahr. Tatsächlich wird die Verwendung von IORepl auf einem Server, auf dem die Exchange 2007-Verwaltungstools ohne andere Exchange 2007-Serverfunktionen installiert sind, vollständig unterstützt. Denken Sie aber daran, dass Sie den Microsoft Exchange Server-MAPI-Client (Messaging Application Programming Interface) und Datenobjekte für die Zusammenarbeit (Collaboration Data Objects, CDO) ebenfalls auf dem Server installieren müssen, da diese nicht mehr als Teil der Basisproduktinstallation bereitgestellt werden.

F: Ich arbeite an einem Exchange Server 2007-Entwurf für eine große Organisation mit 150.000 Arbeitsplätzen und muss die Anzahl der globalen Katalogserver berechnen, die von der Exchange 2007-Messaginginfrastruktur benötigt werden. Können Sie weiterhelfen?

A: Selbstverständlich! In dieser Rubrik sollen solche und ähnliche Fragen beantwortet werden. Zunächst einmal ist es wichtig zu verstehen, dass hier die Anzahl der erforderlichen globalen Katalogserver (oder um genauer zu sein, die Anzahl der Kerne, und hier sind nicht Prozessoren gemeint) aufgrund der geplanten Gesamtanzahl von Exchange 2007-Postfachserverkernen berechnet wird. Beachten Sie, dass Sie die Anzahl der Kerne des globalen Katalogservers nur aufgrund der Postfachserver berechnen. Sie beziehen die anderen Exchange 2007-Serverfunktionen wie „ClientAccess“, „Hub-Transport“, „UnifiedMessaging“ oder „Edge-Transport“ hier nicht ein. Obwohl die anderen Exchange 2007-Serverfunktionen die Anzahl der globalen Katalogserver beeinflussen, wirkt sich die Anzahl der eingesetzten Postfachserver auf die anderen Exchange 2007-Serverfunktionen aus. Das heißt, Sie können die erforderliche Zahl der globalen Katalogserver aufgrund der Anzahl der Postfachserver berechnen.

Außerdem hängt die Anzahl der globalen Katalogserver davon ab, ob Sie 32-Bit- oder 64-Bit-basierte Domänencontroller in der Active Directory®-Infrastruktur verwenden. Bei 32-Bit-Domänencontrollern verwenden Sie ein 4:1-Verhältnis. Das heißt, dass Sie 1 globalen Katalogkern für jeweils 4 Postfachserverkerne einplanen sollten. Bei 64-Bit-Domänencontrollern ist das Verhältnis 8:1. Wenn Sie z. B. Exchange 2007-Postfachserver mit 8 installierten Kernen bereitstellen und 64-Bit-Domänencontroller verwenden, benötigen Sie 1 globalen Katalogserver pro Exchange 2007-Postfachserver. Abschließend muss beim Verwenden von 64-Bit-Domänencontrollern sichergestellt werden, dass genügend Speicherplatz vorhanden ist, damit die gesamte Active Directory-Datenbank (NTDS.DIT-Datei) zwischengespeichert werden kann.

F: Die vorherige Antwort erläutert die Empfehlungen in Bezug auf die Anzahl der globalen Katalogserver pro Exchange 2007-Postfachserver. Wie komme ich auf die Anzahl von Exchange 2007-Hub-Transport- und ClientAccess-Serverfunktionen, die bereitgestellt werden müssen?

A: Wie in der vorherigen Antwort erläutert, ist die Anzahl der bereitzustellenden Exchange 2007-Clientzugriffsserver und der Hub-Transport-Server (oder genauer gesagt der Serverkerne) an die Anzahl der Postfachserverkerne gebunden. Es gibt keine definitive Regel, aber die Faustregel lautet 1 Clientzugriffsserverkern für 4 Postfachserverkerne (Verhältnis 4:1) und 1 Hub-Transport-Serverkern für 7 Postfachserverkerne (7:1). Letzteres gilt für Hub-Transport-Server, auf denen kein Antivirusprogramm installiert ist. Bei einem Antivirusprogramm, wie z. B. Forefront Security für Exchange, ist das Verhältnis gewöhnlich eher 1 Hub-Transport-Serverkern für 5 Postfachserverkerne (Verhältnis 5:1).

F: Ich habe gehört, dass die Installation von mehr als 8 Prozessorkernen auf einem Exchange 2007-Server nicht empfohlen wird. Trifft dies zu, und falls ja, weshalb?

A: Ja, das ist wahr. Obwohl die Installation von Mehrkernprozessoren für Exchange Server 2007 große Vorteile bietet, ist 8 die maximale Anzahl der auf einem Exchange 2007-Server zu installierenden Kerne. Um genauer zu sein: Es können nur 2 Exchange 2007-Serverfunktionen einen Vorteil aus der Verwendung zusätzlicher Kerne (bis zu 8) ziehen, und das sind die Hub-Transport- und die Mailbox-Serverfunktion. Auch das gilt nur für äußerst ausgelastete Exchange 2007-Server, die Millionen von Nachrichten pro Tag bearbeiten und viele Tausende von Postfächern speichern.

Die Exchange-Produktgruppe hat Tests mit 12 Prozessorenkernen durchgeführt, die auf einem Exchange 2007-Postfachserver installiert wurden. Die Ergebnisse hinsichtlich der Speicherleistung und Skalierbarkeit waren negativ. Außerdem wurde beobachtet, dass sich bei einer Erhöhung der Kerne von 8 auf 16 die durchschnittliche Latenz des Remoteprozeduraufrufs (Remote Procedure Call, RPC) verdoppelte.

Wenn Sie nicht außerordentlich ausgelastete Postfachserver erwarten, sind 4 Prozessorkerne in der Regel ausreichend. Weitere Informationen und Überlegungen zu Prozessoren für die anderen Exchange 2007-Serverfunktionen finden Sie unter technet.microsoft.com/aa998874.

A: Wir führen derzeit eine gesamtstrukturübergreifende Migration von einer Exchange 2000- und Exchange 2003-Organisation zu einer neuen Exchange 2007-Organisation durch. Wenn wir jedoch versuchen, mit dem Cmdlet „Move-Mailbox“ und dem Parameter „-SourceMailboxCleanupOptions DeleteSourceMailbox“ ein Postfach von der Quellgesamtstruktur in die Zielgesamtstruktur zu verschieben, wird der folgende Fehler angezeigt:

„Das Postfach wurde auf den Exchange-Zielserver verschoben und vom Exchange-Quellserver entfernt. Trotzdem Fehler beim Löschen von Postfachattributen des Quellpostfachbenutzers. Die Betriebssystemversion von Domänencontroller 'file01' ist 5.0 (2195) Service Pack 4. Die erforderliche Mindestversion ist 5.2 (3790) Service Pack 1.“

F: Der Windows Server® 2003-basierte Domänencontroller (der auch ein globaler Katalogserver ist) existiert in der Quellgesamtstruktur, aber es sieht nicht so aus, als ob angegeben werden kann, welcher Domänencontroller in der Quellgesamtstruktur verwendet werden soll, da der Parameter „–DomainController“ nur einen Domänencontroller oder globalen Katalogserver in der Zielgesamtstruktur angeben kann. Ist dies richtig? Falls ja, gibt es eine Problemumgehung?

A: Das ist richtig. Sie können keinen Domänencontroller oder globalen Katalogserver aus der Quellgesamtstruktur als Teil des Cmdlet „Move-Mailbox“ angeben. Der Domänencontroller (globaler Katalogserver) wird nach dem Zufallsprinzip ausgewählt. Es gibt einige Problemumgehungen, aber keine davon ist besonders praktisch. Als Erstes müssen alle Windows® 2000-basierten Domänencontroller aus der Quellgesamtstruktur außer Betrieb gesetzt werden, aber diese Option kommt oft nicht in Frage. Die zweite Problemumgehung könnte in Ihrer Situation nützlich sein. Das Cmdlet „Move-Mailbox“ muss einen Domänencontroller verwenden, der auch als globaler Katalogserver dient. Das heißt, dass Sie das Problem möglicherweise lösen können, indem Sie die globale Katalogserverfunktion aus allen Windows 2000-Servern in der Quellgesamtstruktur entfernen. Ich habe diese Methode in einigen Migrationsszenarios erfolgreich angewendet, sodass es auf alle Fälle einen Versuch wert ist.

F: Ist es möglich, einen Exchange 2007-Clientzugriffs-, Hub-Transport- oder Postfachserver an 1 Active Directory-Standort zu installieren, wie z. B. den USA, und den Server dann an einen anderen Active Directory-Standort, wie z. B. Dänemark, zu verschicken? Falls dies unterstützt wird, würde der Exchange 2007-Server dann die neue Active Directory-Standortmitgliedschaft automatisch feststellen, oder muss dies manuell durchgeführt werden?

A: Ja, dieses Szenario wird vollständig unterstützt und erfordert keinen manuellen Eingriff. Der Netzwerkanmeldungsdienst (Net­Logon) und der Microsoft Exchange Active Directory-Topologiedienst (MSExchangeADTopology) kümmern sich um die Standortmitgliedschaft für einen Exchange 2007-Server. Wenn der Server die Standortmitgliedschaft ändert, aktualisiert der MS­ExchangeADTopology-Dienst automatisch das Standortattribut des Servers, das als das msExchServerSite-Attribut bekannt ist. Wie in Abbildung 1 dargestellt, können Sie das msExchServerSite-Attribut durch die Verwendung eines Tools wie ADSIEdit anzeigen.

Abbildung 1 Anzeigen des msExchServerSite-Attributs (zum Vergrößern auf das Bild klicken)

Wenn Sie einen tieferen Einblick in die Beziehung der Exchange 2007- und Active Directory-Standorte wünschen, empfiehlt es sich sehr, dass Sie den Abschnitt der Exchange 2007-Dokumentation mit dem Titel „Informationen zum auf Active Directory-Standorten basierenden Routing“ unter technet.microsoft.com/aa 998825 lesen.

F: Kann auf einem Exchange 2007-Postfachserver, auf dem die fortlaufende lokale Replikation (Local Continuous Replication, LCR) für die Postfachdatenbanken aktiviert wurde, Microsoft Data Protection Manager 2007 (DPM 2007) zur Sicherung der Postfachdaten über die passive Postfachdatenbankkopie verwendet werden?

A: Obwohl Sie DPM 2007 verwenden können, um eine Sicherungskopie der Postfachdatenbanken über den passiven Knoten in einer Exchange 2007-CRR-Umgebung (Clustered Continuous Replication, fortlaufende Clusterreplikation) zu erstellen, wird dies für Postfachdatenbankkopien in einer Exchange 2007-LCR-Umgebung nicht unterstützt.

F: Eine Exchange Server 2007-CMS-Datenbank (Clustered Mailbox Server, Postfachclusterserver) kann auf einen eigenständigen Postfachserver portiert werden, aber ist es möglich, eine Remotedatenbank auf einem CCR- oder SCC-basierten (Single Copy Cluster, Einzelkopiecluster) Exchange 2007-CMS zu verwenden?

A: Da ein Exchange Server 2007-Informationsspeicher nicht erkennen kann, auf welcher Art von Server er sich befindet, wird die Verwendung einer Remotedatenbank auf einem CCR- oder SCC-basierten CMS vollständig unterstützt.

F: Laut einem Artikel, der unter technet.microsoft.com/bb508861 verfügbar ist, wird der Exchange Server-Kontingentmeldedienst (Quota Message Service, QMS) auf einem Exchange 2003-Clusterserver nicht unterstützt. Wird dieser Dienst in Zukunft für Exchange 2003- oder Exchange 2007-Clusterumgebungen unterstützt?

A: Das Exchange Server-QMS-Tool wird in Zukunft auf Exchange 2003-CMSs nicht unterstützt. Darüber hinaus wird das QMS-Tool für Cluster- (bzw. Nicht-Cluster-)Exchange 2007-Postfachserver nicht unterstützt. Wenn Sie aber Exchange 2007 in Ihrer Organisation verwenden, gibt es keinen Grund, das QMS-Tool zu installieren, da die gleiche Funktionalität standardmäßig in Exchange enthalten ist. Weitere Informationen zur Verwaltung von Kontingentmeldungen unter Exchange 2007 erhalten Sie unter technet.microsoft.com/bb232089.

F: Gibt es eine verfügbare Referenzdokumentation, die die Attribute auflistet, die für Active Directory-Benutzer und/oder -Gruppenobjekte eingestellt werden, wenn die Postfach- bzw. E-Mail-Aktivierung für diese Entitäten erfolgt?

A: Der Artikel „Referenz zu geteilten Berechtigungsmodellen“ in der Exchange 2007-Dokumentation listet diese Attribute auf. Sie finden diesen Artikel unter technet.microsoft.com/bb430782.

F: Gibt es eine Möglichkeit, einen Exchange 2007-Hub-Transport-Server als einen Bridgeheadserver für internen E-Mail-Verkehr in unserer Exchange 2007-Messaginginfrastruktur festzulegen? Dabei würden z. B. alle E-Mails, die vom Active Directory-Standort 1 an den Active Directory-Standort 2 gesendet werden, über den Hub-Transport-Server A (am Active Directory-Standort 1) zum Hub-Transport-Server B (am Active Directory-Standort 2) weitergeleitet werden und umgekehrt. Würde dies funktionieren?

A: Nein. Dafür müsste der Postfachserver an den Active Directory-Standorten wissen, ob die Empfänger sich an einem anderen Active Directory-Standort befinden. Die Exchange 2007-Mailbox-Serverfunktion enthält keine solche Methode.

Wenn der Hub-Transport-Server nicht lokal auf einem Postfachserver installiert ist, lädt der Postfachserver immer Ausgleichsverbindungen zwischen den Hub-Transport-Servern am gleichen Active Directory-Standort. (Falls die Hub-Transport-Serverfunktion auf dem Postfachserver installiert wird, ist es immer vorzuziehen, dass sich der Hub-Transport-Server im selben physischen Bereich wie der Postfachserver befindet.)

Exchange 2007 kann erst nach der Kategorisierung erkennen, wo sich das Postfach des Empfängers befindet. Sie erreichen dieses Ziel am ehesten, indem Sie den Parameter „SubmissionServerOverrideList“ mit dem Cmdlet „Set-MailboxServer“ verwenden, um eine statische Liste von Hub-Transport-Servern zu erstellen, die ein Postfachserver verwenden sollte, wie in Abbildung 2 dargestellt (siehe technet.microsoft.com/bb232193).

Abbildung 2 Postfachservereinstellungen (zum Vergrößern auf das Bild klicken)

Das heißt, wenn Sie entweder Hub-Transport-Server A oder B angeben, würde der Postfachserver immer diesen Hub-Transport-Server verwenden, und zwar nicht nur für Nachrichten, die an Empfänger an einem bestimmten Standort gesendet werden, sondern für alle Active Directory-Standorte sowie für die lokale Nachrichtenübermittlung. Da dies theoretisch eine einzelne Fehlerquelle erzeugen würde, wird von diesem Ansatz abgeraten.

F: Ich plane, Exchange Server 2007 SP1-Postfachserver unter Windows Server 2008 zu installieren, und mache mir über die Datenträgerausrichtung Gedanken. Ich weiß, dass sowohl für Exchange Server 2003 als auch Exchange Server 2007, installiert auf Servern unter Windows Server 2003, empfohlen wurde, mit dem DiskPart-Tool Partitionen zur Aufbewahrung der Transaktionsprotokolldateien und Postfachspeicher zu erstellen, um die Gesamtleistung zu verbessern. Außerdem wurde empfohlen, die Speicherpartition entsprechend den Anbieterempfehlungen auszurichten. Falls der Speicherhersteller keine Empfehlungen gibt, schlägt die bewährte Methode von Microsoft die Verwendung des Werts 64 KB vor.

Wie soll ich beim Installieren von Exchange 2007-Postfachservern unter Windows Server 2008 die Datenträgerausrichtungen konfigurieren? Gelten hier die gleichen Richtlinien?

A: Das wird Sie überraschen. Unter Windows Server 2008 müssen Sie die Datenträgerpartitionen, auf denen die Exchange Server 2007 SP1-Transaktionsprotokolldateien und -Postfachdatenbanken gespeichert werden, nicht mehr mit dem DiskPart-Tool ausrichten. Unter Windows Server 2008 wurden die Ausrichtungsprobleme bei Datenträgerpartitionen unter Windows Server 2003 korrigiert, wo eine Partition immer im 64. Sektor startete und dadurch die gesamte Partition beim Verwenden des Windows-Datenträgerverwaltungstools falsch ausrichtete.

Weitere Informationen zum Spurausrichtungsproblem finden Sie im Exchange-Teamblog unter msexchangeteam.com/archive/2005/08/10/408950.aspx. Außerdem richtet Windows Server 2008 eine Datenträgerpartition durch die Verwendung einer 1024 KB-Begrenzung aus. In der Exchange Server 2007-Dokumentation auf TechNet wird dies ebenfalls erwähnt, und zwar unter technet.microsoft.com/bb738145.

F: Wir befinden uns derzeit in der Planungsphase für die Implementierung der fortlaufenden Standbyreplikation (Standby Continuous Replication, SCR) in unserer Exchange Server 2007 SP1-basierten Messagingumgebung. Wir sind ein relativ kleiner Laden, und wir können es uns nicht leisten, mehr als einen physischen Computer mit installiertem Exchange 2007-Server bereitzustellen, der als SCR-Ziel an einem zweiten Standort dient.

Wir sind etwas unsicher, ob auch andere Serverfunktionen als die Mailbox-Serverfunktion am SCR-Ziel unterstützt werden.

A: Ja. Sowohl der Quell- als auch der Ziel-SCR-Exchange-Server können andere Exchange 2007 SP1-Serverfunktionen ausführen. Das heißt, dass der Server vollständig unterstützt wird, um z. B. Exchange 2007 SP1-Server mit installierten ClientAccess-, Hub-Transport- und Mailbox-Serverfunktionen bereitzustellen und diese als SCR-Ziele zu verwenden.

F: Unsere Organisation, die auf einer Windows Server 2003 Active Directory-Gesamtstruktur und einer Exchange 2007-Messaginginfrastruktur basiert, wird bald mit einer kürzlich erworbenen Organisation zusammengeführt. Eine der Anforderungen bei der Zusammenführung der beiden Organisationen besteht darin, die Exchange 2007-Adresslisten zu trennen, sodass die jeweiligen Benutzer einer Organisation nur die Adressliste mit den eigenen Benutzern anzeigen können.

Ich erinnere mich wage an einige Microsoft Knowledge Base-Artikel, die Schritt-für-Schritt-Anweisungen dafür enthielten, wie dies in einer Exchange 2003-Umgebung erreicht werden kann. Welches ist der Ansatz hinsichtlich der Trennung von Adresslisten in einer Exchange 2007-basierten Messagingumgebung?

A: Aus Platzgründen können die dazu notwendigen Schritte hier nicht aufgelistet werden. Erfreulicherweise hat Microsoft kürzlich ein technisches Whitepaper veröffentlicht, in dem erläutert wird, wie Sie vorgehen müssen, um virtuelle Organisationen zu konfigurieren und Adresslisten in Exchange 2007 zu trennen. Sie finden das Whitepaper unter technet.microsoft.com/bb936719. Außerdem wird empfohlen, dass Sie einige Minuten dem Lesen des Beitrags widmen, der sich auf dieses Whitepaper von Dave Goldman bezieht (siehe go.microsoft.com/fwlink/?LinkId=115499).

F: Erfordert Exchange Server 2007 den Windows Internet Naming Service (WINS), um richtig zu funktionieren?

A: Das Exchange Server 2007-Produkt selbst benötigt WINS nicht. WINS könnte aber erforderlich werden, je nachdem, welche Version von Microsoft Office Outlook® Sie in Ihrer Exchange Server 2007-Messagingumgebung verwenden. Wenn Ihre Messagingumgebung ausschließlich aus Exchange 2007-Servern und Outlook 2007- oder Outlook 2003-Clients besteht, ist WINS nicht erforderlich.

Es gibt allerdings eine seltene Situation, in der WINS von Outlook 2007 benötigt wird. Beim Migrieren eines Postfachs zu einer neuen Exchange-Gesamtstruktur versucht die RTM-Version von Outlook 2007, eine Verbindung zum Exchange-Postfachserver herzustellen, indem sie den NetBIOS-Namen und nicht wie erwartet den vollqualifizierten Domänennamen (fully qualified domain name, FQDN) verwendet. Dieses Problem wurde jedoch mit dem Post-SP1-Hotfixpaket für Outlook 2007 korrigiert, das im Januar 2008 veröffentlicht wurde (support.microsoft.com/?id=941275).

Wenn Ihre Endbenutzer Outlook 2002 verwenden, wird WINS immer erforderlich sein, da dieser Client auf die NetBIOS-Namensauflösung angewiesen ist. Ich erwähne ausdrücklich nicht die Outlook-Clients vor Outlook 2002, da sie unter Exchange 2007 nicht unterstützt werden, aber dasselbe würde auch hier gelten.

Henrik Walther ist ein Microsoft-zertifizierter Architekt: MVP für Messaging (Auszubildender) und Exchange mit über 14 Jahren Erfahrung im IT-Bereich. Er ist als Technologieentwickler für Interprise Consulting und als Autor technischer Artikel für Biblioso Corporation tätig.