Skip to main content
TechNet

Fragen & Antworten zu Exchange

Installieren von Exchange 2003/2007 in einer Exchange 2010-Umgebung

Henrik Walther

Frage: Kann Exchange 2003 oder 2007 in einer reinen Exchange 2010-Organisation installiert werden?

Antwort: Handelt es sich um eine Exchange 2010 Greenfield-Umgebung (eine Exchange-Organisation, die nur aus Exchange 2010-Servern besteht und in der keine früheren Exchange-Versionen installiert sind), dann lautet die Antwort: Nein. Sollten Sie von Exchange 2007 auf Exchange 2010 übergegangen sein und der letzte Exchange 2007-Server wurde bereits außer Betrieb genommen, lautet die Antwort ebenfalls: Nein. Sie können Exchange 2007 nicht zu einem späteren Zeitpunkt in der Organisation installieren, da diese von nun an als reine Exchange 2010-Organisation angesehen wird.

Wenn Sie von Exchange 2003 auf Exchange 2010 übergehen wollen und bereits die Active Directory-Gesamtstruktur anhand des Exchange 2010-Setups vorbereitet haben, können Sie ebenfalls keinen Exchange 2007-Server in der Organisation installieren. Sie erhalten jedoch eine Warnung, aus der dies hervorgeht, sobald der erste Exchange 2010-Server in einer reinen Exchange 2003-Organisation installiert wird (siehe Abbildung 1).

 

Abbildung 1 Setup gibt die Warnung aus, dass Sie Exchange 2007 nicht in der Organisation installieren können, nachdem Sie sie mit dem Exchange 2010-Setup vorbereitet haben.

Sollten Sie also zu irgendeinem Zeitpunkt einen Exchange 2007-Server benötigen, sollten Sie einen Exchange 2007-Server nach dem Übergang von Exchange 2007 auf Exchange 2010 in der Organisation belassen. Wechseln Sie andererseits von Exchange 2003 auf Exchange 2010, sollten Sie einen Exchange 2007-Server in der Organisation bereitstellen, bevor Sie die AD-Gesamtstruktur anhand des Exchange 2010-Setups vorbereiten.


Frage: Wir verwenden im Moment Exchange 2007 als Messagingsystem in unserer Unternehmensumgebung. Nachdem wir alle Clientcomputer von Windows XP auf Windows 7 aktualisiert haben, haben wir nun Schwierigkeiten mit der Installation der Exchange 2007 (SP2)-Verwaltungstools auf den neuen Windows 7-Clients. Müssen wir bei der Installation der Exchange 2007-Verwaltungstools unter Windows 7 bestimmte Schritte berücksichtigen?

Antwort: Da Exchange Server 2007 vor Windows 7 entwickelt worden ist, werden die Exchange 2007-Verwaltungstools nicht von Windows 7 unterstützt. Die Exchange-Produktgruppe konzentrierte ihre Anstrengungen auf Exchange 2010, was natürlich Windows 7 unterstützt. 

Budget- und Ressourcenbeschränkungen bei der Softwareentwicklung spielten eine wichtige Rolle bei der Entscheidung der Exchange-Produktgruppe, ob die Installation der Exchange-Verwaltungstools unter Windows 7 unterstützt werden sollte. Bei dieser Entscheidung wurde die Tatsache berücksichtigt, dass noch ungefähr 65 % aller Exchange-Kunden Exchange 2003 verwenden. Jetzt mit der Veröffentlichung von Exhange 2010 werden die meisten dieser Kunden Exchange 2007 überspringen und direkt zu Exchange 2010 wechseln.

Dieses Problem kann gelöst werden, indem Exchange 2007 Service Pack 3 auf den Windows 7-Clients installiert wird. Ja, Sie haben richtig gehört. Auf Grundlage von Kundenfeedback hat die Exchange-Produktgruppe entschieden, Exchange 2007 SP3 in der zweiten Jahreshälfte 2010 zu veröffentlichen. Hierdurch wird die Installation der Exchange-Verwaltungstools auf Windows 7-Clients und von Exchange 2007 auf Windows Server 2008 R2-Servern unterstützt. Weitere Informationen zur Veröffentlichung von Exchange 2007 SP3 finden Sie hier: http://msexchangeteam.com/archive/2009/11/30/453327.aspx.

 

Frage: Ich habe als Vorbereitung auf eine geplante Migration von Exchange 2007 zu Exchange 2010 eine Testumgebung mit zwei separaten Active Directory-Gesamtstrukturen eingerichtet. Die Quell-AD-Gesamtstruktur enthält eine Exchange 2007-Organisation, und die Ziel-AD-Gesamtstruktur enthält eine Exchange 2010-Organisation.

Wenn ich mich recht erinnere, war es nicht unbedingt notwendig, dass bei meiner gesamtstrukturübergreifenden Migration von Exchange 2003 zu Exchange 2007 die Active Directory-Benutzerkonten bereits in die Ziel-AD-Gesamtstruktur migriert worden waren.

Bei dem Versuch, einige Exchange 2007-Postfächer gesamtstrukturübergreifend in eine Exchange 2010-Organisation zu verschieben, habe ich festgestellt, dass die gesamtstrukturübergreifende Postfachverschiebung auf Exchange 2010 von der entsprechenden Verschiebung auf 2007 abweicht.

Können Sie erklären, wie Postfächer gesamtstrukturübergreifend verschoben werden, wenn es sich bei dem Ziel um eine Exchange 2010-Organisation handelt?

Antwort: Sie haben recht. Die gesamtstrukturübergreifende Verschiebung von Postfächern in eine Exchange 2010-Organisation weicht von der Verschiebung auf Exchange 2007 ab.

Wie Sie bereits angegeben haben, erforderte das Exchange 2007 Move-Mailbox-Cmdlet nicht notwendigerweise, dass die AD-Konten vor der Verschiebung der entsprechenden Postfächer in die Ziel-AD-Gesamtstruktur migriert worden waren. Das Move-Mailbox-Cmdlet von Exchange 2007 suchte nach AD-Konten in der Ziel-AD-Gesamtstruktur, die mit beliebigen Proxyadressen (SMTP-Adressen), Quell-ObjectSID (masterAccountSID, objectSID und sidHistory) oder legacyExchangeDN (x500-Adresse des Benutzerobjekts) übereinstimmten. Wurde eine Übereinstimmung gefunden, wurde das entsprechende AD-Konto in der Ziel-AD-Gesamtstruktur E-Mail-aktiviert. Wurde keine Übereinstimmung gefunden, erstellte das Move-Mailbox-Cmdlet ein deaktiviertes postfachaktiviertes AD-Benutzerkonto.

Bei Exchange 2010 sieht es etwas anders aus. Zunächst wird das Move-Mailbox-Cmdlet nicht länger verwendet. Dieses Cmdlet wurde durch das völlig neue New-Move Request-Cmdlet ersetzt, was übrigens einige nette Verbesserungen aufweist. Darüber hinaus erwartet Exchange 2010 bei einer gesamtstrukturübergreifenden Postfachverschiebung anhand des New-Move Request-Cmdlets, dass gültige E-Mail-Benutzer vorhanden sind. Die Quellkonten werden bei diesem Vorgang unter Verwendung von msExchMailboxGUID einem Zielkonto zugeordnet. Im Gegensatz zu Exchange 2007 wird nicht versucht, Zielkonten anhand der obengenannten Attribute zu finden. Dies bedeutet, dass Sie vor einer gesamtstrukturübergreifenden Verschiebung mit Exchange 2010 E-Mail-Benutzer in der Ziel-AD-Gesamtstruktur bereitstellen müssen.

Im Gegensatz zu Exchange 2007 können Sie nun mit der Exchange 2010 Exchange-Verwaltungskonsole (siehe Abbildung 2) gesamtstrukturübergreifende Postfachverschiebungen vornehmen. Sie müssen lediglich zunächst die Exchange-Organisation aus der Ziel-AD-Gesamtstruktur der EMC hinzufügen.

 

Abbildung 2 Das neue Fenster für Verschiebungsanforderungen in Exchange 2010


Sie können E-Mail-Benutzer in der Ziel-Exchange 2010-Organisation mit dem PrepareMoveRequest.ps1-Skript erstellen. Dieser Vorgang wird näher in dieser Abschnitt auf Microsoft TechNet beschrieben. Oder Sie verwenden dazu entweder Identity Lifecycle Management (ILM) 2007 FP1 (mit den neuesten Hotfixes, die die Exchange 2010-Bereitstellung für ILM 2007 FP1 aktivieren) oder Forefront Identity Management (FIM 2010), was derzeit als Release Candidate 1 verfügbar ist und im 1. Quartal 2010 die Produktionsfreigabe (RTM) erhält.

Frage: Unsere Organisation verwendet im Moment Exchange 2007. Wir haben eine Lösung mit hoher Verfügbarkeit, die aus 4 Exchange 2007-Servern besteht – zwei Server mit den installierten Serverrollen Hub-Transport und Client Access und zwei Server, die als Postfach-Serverclusterknoten in einem Cluster mit fortlaufender Clusterreplikation (CCR) dienen. Die Exchange 2007-Server, auf denen die HT- und CAS-Serverrollen installiert sind, wurden mit Windows NLB konfiguriert, um Lasten auszugleichen und automatisches Failover für eingehende Client- und SMTP-Verbindungen bereitzustellen. Diese Lösung funktioniert zwar sehr gut, wir möchten jedoch jetzt, da Exchange 2010 veröffentlicht wurde, auf diese neueste Exchange-Version umsteigen. Es gibt nicht nur mehrere neue Funktionen, sondern wir haben auch gehört, dass die Anzahl der Exchange-Server auf zwei reduziert werden kann, ohne dass die HA-Funktionalität, die wir im Moment benutzen, verloren geht.

Gibt es bestimmte Dinge, die wir beachten müssen, bevor wir auf eine Exchange 2010 HA-Lösung mit nur zwei Servern umsteigen?

Antwort: Ja, um eine Exchange 2007-Messaginglösung mit hoher Verfügbarkeit und automatischem Failover ohne einzelne Fehlerquellen auf Hardware- oder Speicherebene zu erstellen, benötigen Sie insgesamt 4 Computer: zwei Server mit den installierten Serverrollen Hub-Transport und Client Access und zwei Server, die als Clusterknoten in einem Cluster mit fortlaufender Clusterreplikation (CCR) dienen.

Die Hub-Transport-Serverrolle hat einen integrierten Lastenausgleich mit Failover für die Intra-Site-Kommunikation, die Sie mithilfe von DNS-Roundrobin-Mechanismen redundant machen können. Da die CAS-Rolle jedoch keine Lastenausgleichsfunktionalität enthält, mussten Sie gewöhnlich diese beiden Computer als Knoten in einem Windows-Netzwerklastenausgleichscluster (WNLB) konfigurieren, um den Lastenausgleich und automatisches Failover für eingehende Verbindungen von Clients und Servern aus dem Internet und anderen externen Netzwerken bereitzustellen.

Die zwei Computer, die im CCR-Cluster als Clusterknoten dienen, hätten jeweils die aktive oder passive Mailbox-Serverrolle installiert haben müssen, damit der Mailbox-Clusterserver (CMS) auf beide Knoten wechseln oder einen Failover vornehmen kann. Und schließlich würden Sie einen der Front-End-Server als Dateifreigabenzeuge (dritte Stimme) im CCR-Cluster bereitstellen.

Wir Sie wahrscheinlich bereits wissen, wird CCR (und SCC, LCR und SCR) bei Exchange 2010 nicht mehr verwendet. Stattdessen führt Exchange 2010 ein neues Feature mit dem Namen Database Availability Groups (DAGs) ein. Dieses Feature verwendet die gleiche Synchronisierungstechnologie wie CCR und SCR zusammengenommen, verfügt jedoch gleichzeitig über weitaus mehr Funktionalität, die im Vergleich zu CCR und SCR wesentlich besser ist. Ein interessanter Aspekt von Exchange liegt in der Tatsache, dass andere Exchange 2010-Rollen (Hub-Transport, Client Access und selbst Unified Messaging) auf dem gleichen Server installiert sein können, auf dem die einem DAG hinzugefügte Mailbox-Serverrolle vorhanden ist. Dies bedeutet, dass nicht länger zwei Computer als Front-End-Server für die Hub-Transport- und Client Access-Serverrollen benötigt werden. Sie können einfach alle erforderlichen Exchange 2010-Rollen auf den Computern installieren und schon haben Sie eine vollständig redundante auf Exchange 2010 basierte Messaginglösung. Nun, fast jedenfalls. Das hörte sich ja nun wirklich einfach zu gut an, oder?

Da DAGs in gewisser Weise die Windows Failover Clustering-Komponente (WFC) verwenden (in erster Linie Takt und die Clusterdatenbank), können die beiden Server nicht als Knoten in einem Windows NLB konfiguriert werden, da die gemeinsame Verwendung von WFC und WNLB auf dem gleichen Server nicht unterstützt wird. Dies wird seit Windows NT 4.0 aufgrund möglicher Hardwarefreigabekonflikte zwischen dem Clusterdienst und WNLB nicht mehr unterstützt. Weitere Informationen finden Sie im KB-Artikel: http://support.microsoft.com/default.aspx?kbid=235305.

Dies bedeutet, dass Sie ein externes Lastenausgleichs-/Failovergerät wie z. B. ein hardwarebasiertes Lastenausgleichsmodul verwenden müssen. Da dieses Lastenausgleichsmodul redundant sein muss, benötigen Sie mindestens zwei Geräte.


Selbst wenn Sie WFC auch weiterhin verwenden werden und DAG ein Feature der Enterprise Edition ist, benötigen Sie nicht wirklich die Exchange 2010 Enterprise Edition, um DAG nutzen zu können. Im Gegensatz zu Exchange 2007 CCR ist DAG ebenfalls Teil der Standard Edition von Exchange 2010. Vergessen Sie jedoch nicht, dass Sie maximal 5 Datenbanken (einschließlich aktiver und passiver Datenbankkopien) in diesem Szenario verwenden können.

 Da Sie die CAS- und HT-Serverrollen auf dem gleichen Computer installieren, auf dem bereits die Mailbox-Serverrolle installiert ist und bei dem es sich um einen DAG-Mitgliedserver handelt, können Sie zwei Computer und zwei Windows 2008 und Exchange 2010 Standard Edition-Lizenzen einsparen. Sollten Sie noch kein externes Lastenausgleichsmodul in Ihrer Umgebung haben, können Sie entweder eine virtuelle Lastenausgleichsanwendung verwenden oder ein hardwarebasiertes Lastenausgleichsmodul kaufen. Sie benötigen natürlich ebenfalls einen Server, der als Zeugenserver dient. Dies muss jedoch nicht notwendigerweise ein Exchange-Server sein, auch wenn sich dies in der Praxis bewährt hat. Es kann sich hierbei um einen beliebigen Windows 2003-/2008-Dateiserver in Ihrer Umgebung handeln.

Henrik Walther ist ein Microsoft Certified Master: Exchange 2007 und Exchange MVP mit über 15 Jahren Erfahrung in der IT-Branche. Er ist als Technology Architect für Trifork Infrastructure Consulting (ein Microsoft Gold Certified Partner aus Dänemark) und als technischer Autor für Biblioso Corp. (eine in den USA ansässige Firma, die sich auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert hat) tätig.

Verwandter Inhalt