(0) exportieren Drucken
Alle erweitern

Bereitstellen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten

Exchange 2010
 

Gilt für: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Letztes Änderungsdatum des Themas: 2013-01-09

Wenn Sie in vorherigen Versionen von Exchange einen Postfachserver mit hoher Verfügbarkeit erstellen wollten, wurde Exchange auf einem Server installiert, der als Mitglied eines Microsoft Windows-Failoverclusters konfiguriert war. Damit für den Postfachserver eine hohe Verfügbarkeit erzielt werden konnte, mussten Sie den Cluster vor Ausführen des Exchange-Septupprogramms erstellen und konfigurieren. Das Exchange-Setupprogramm und weitere Exchange-Komponenten, wie der Exchange-Speicher und der Microsoft Exchange-Systemaufsichtsdienst, waren clusterabhängig und zeigten daher ein anderes Verhalten als auf einem eigenständigen Server. Falls Exchange bereits auf einem eigenständigen Windows-Server installiert war, konnte der Server nicht für hohe Verfügbarkeit konfiguriert werden. Dazu musste zuerst Exchange entfernt, ein Cluster erstellt und anschließend Exchange mit der clusterabhängigen Version des Setupprogramms erneut installiert werden.

Microsoft Exchange Server 2010 verwendet für die hohe Verfügbarkeit und die Ausfallsicherheit von Standorten das unter der Bezeichnung Inkrementelle Bereitstellung bekannte Konzept. Im Gegensatz zu vorherigen Versionen wird bei Exchange 2010 für die hohe Verfügbarkeit nicht mehr das Clusterressourcenmodell verwendet. Aufgrund der geänderten Architektur gibt es keine clusterabhängige Version des Setupprogramms mehr, und die hohe Verfügbarkeit wird nicht mehr beim Setup konfiguriert. Stattdessen werden alle Exchange 2010-Server als eigenständige Server installiert, und anschließend werden je nach Bedarf und inkrementell die hohe Verfügbarkeit sowie die Ausfallsicherheit von Standorten für Postfachserver und Postfachdatenbanken konfiguriert.

Der allgemeine Bereitstellungsvorgang von Exchange 2010 in einer Konfiguration mit hoher Verfügbarkeit und Ausfallsicherheit von Standorten ist im Grunde immer derselbe, auch wenn sich die tatsächlichen Schritte in den einzelnen Organisationen geringfügig unterscheiden. Nachdem Sie die notwendigen Planungs- und Entwicklungsaufgaben zum Erstellen und Bereitstellen einer Database Availability Group (DAG) ausgeführt und Postfachdatenbankkopien erstellt haben, gehen Sie wie folgt vor:

  1. Erstellen Sie eine DAG. Weitere Informationen finden Sie unter Erstellen einer Datenbankverfügbarkeitsgruppe.

  2. Führen Sie ggf. eine provisorische Bereitstellung des Clusternamenobjekts (CNO) durch. Die provisorische Bereitstellung des Clusternetzwerkobjekts ist erforderlich, wenn Sie eine DAG mit Postfachservern unter Windows Server 2012 bereitstellen. Die provisorische Bereitstellung ist außerdem in Umgebungen erforderlich, in denen die Erstellung von Computerkonten eingeschränkt ist oder in denen Computerkonten nicht im Standardcontainer für Computer, sondern in einem anderen Container erstellt werden. Weitere Informationen finden Sie unter Provisorische Bereitstellung des Clusternamenobjekts für eine Database Availability Group.

  3. Fügen Sie der DAG mindestens zwei Postfachserver hinzu. Weitere Informationen finden Sie unter Verwalten der Mitgliedschaft in einer Datenbankverfügbarkeitsgruppe.

  4. Konfigurieren Sie die Eigenschaften der DAG nach Bedarf:

    1. Konfigurieren Sie optional Verschlüsselung und Komprimierung, Replikationsport, IP-Adressen und sonstige Eigenschaften für die DAG. Weitere Informationen finden Sie unter Konfigurieren der Eigenschaften der Datenbankverfügbarkeitsgruppe.

    2. Enthält die DAG mindestens drei Postfachserver, die an mehreren Active Directory-Standorten bereitgestellt werden, sollte der Aktivierungsmodus des Datencenters (Datacenter Activation Coordination, DAC) aktiviert werden. Weitere Informationen finden Sie unter Grundlegendes zum Aktivierungsmodus des Datencenters.

    3. Genaue Anweisungen zum Erstellen eines Netzwerks mit DAGs finden Sie unter Erstellen eines DAG-Netzwerks. Informationen zum Verwalten eines Netzwerks mit DAGs finden Sie unter Konfigurieren der Eigenschaften von DAG-Netzwerken.

  5. Fügen Sie den Postfachservern in der DAG Postfachdatenbankkopien hinzu. Weitere Informationen finden Sie unter Hinzufügen einer Kopie einer Postfachdatenbank.

In diesem Beispiel wird erläutert, wie ein Unternehmen (Contoso, Ltd.) eine DAG mit vier Mitgliedern, die sich über zwei physische Standorte erstreckt, konfiguriert und bereitstellt: Bei den Standorten handelt es sich um das primäre Datencenter "Active Directory SITEA" und ein zweites Datencenter "Active Directory SITEB". SITEA befindet sich in Redmond, Washington/USA, SITEB in Dublin, Irland.

Jeder Standort verfügt über die Infrastrukturelemente, die zum Betrieb einer Messaginginfrastruktur auf Basis von Exchange 2010 erforderlich sind:

  • Verzeichnisdienste (Active Directory oder Active Directory-Domänendienste (Active Directory Domain Services, AD DS))

  • DNS-Namensauflösung (Domain Name System)

  • Mindestens ein Exchange 2010-Clientzugriffsserver

  • Mindestens ein Exchange 2010-Hub-Transport-Server

  • Mindestend ein Exchange 2010-Postfachserver

HinweisAnmerkung:
Die Clientzugriffs-, Hub-Transport- und Postfachserverrollen können gleichzeitig auf demselben Computer eingerichtet sein. In diesem Bereitstellungsbeispiel werden die Serverrollen auf separaten Computern installiert.

In der folgenden Abbildung wird die Contoso-Konfiguration dargestellt.

Database Availability Group über zwei Standorte

Datenbankverfügbarkeitsgruppe über zwei Standorte

Mit Ausnahme der Postfachserver wird auf allen Servern in der Contoso-Umgebung das Betriebssystem Windows Server 2008 R2 Standard ausgeführt. Die Postfachserver, die unter dem Aspekt von DAGs geplant wurden, werden unter Windows Server 2008 R2 Enterprise ausgeführt.

Neben den zuvor genannten Infrastrukturkomponenten gibt es an jedem Standort weitere Messagingelemente, beispielweise Edge-Transport- und Unified Messaging-Server.

Wie aus der obigen Abbildung hervorgeht, beinhaltet die Lösung mehrere Subnetze und mehrere Netzwerke. Jeder Postfachserver in der DAG verfügt über zwei Netzwerkkarten in separaten Subnetzen. Bei jedem Postfachserver wird der eine Netzwerkadapter für das MAPI-Netzwerk (192.168.x.x) und der andere für das Replikationsnetzwerk (10.0.x.x) verwendet. Die Verbindung zu Active Directory, DNS-Diensten sowie sonstigen Exchange-Servern und -Clients wird nur über das MAPI-Netzwerk hergestellt. Der Adapter, der bei jedem Mitglied der DAG für das Replikationsnetzwerk verwendet wird, stellt nur die Verbindung zu den Replikationsnetzwerkadaptern der anderen Mitglieder bereit.

Die Einstellungen für die einzelnen Netzwerkadapter in jedem Knoten gehen aus der folgenden Tabelle hervor.

 

Name IPv4-Adresse Subnetzmaske Standardgateway

MBX1A (MAPI)

192.168.1.4

255.255.255.0

192.168.1.1

MBX2A (MAPI)

192.168.1.5

255.255.255.0

192.168.1.1

MBX1B (MAPI)

192.168.2.4

255.255.255.0

192.168.2.1

MBX2B (MAPI)

192.168.2.5

255.255.255.0

192.168.2.1

MBX1A (Replikation)

10.0.1.4

255.255.0.0

Keine

MBX2A (Replikation)

10.0.1.5

255.255.0.0

Keine

MBX1B (Replikation)

10.0.2.4

255.255.0.0

Keine

MBX2B (Replikation)

10.0.2.5

255.255.0.0

Keine

Wie aus der obigen Tabelle hervorgeht, werden bei den für die Replikationsnetzwerke verwendeten Adaptern keine Standardgateways verwendet. Für die Netzwerkverbindung zwischen den einzelnen Replikationsnetzwerkadaptern verwendet Contoso ein dauerhaftes, statisches Routing, das mithilfe des Tools "Netsh.exe" konfiguriert wird. Sie können "Netsh.exe" verwenden, um auf Windows basierende Computer über eine Eingabeaufforderung zu konfigurieren und zu überwachen. Mithilfe von "Netsh.exe" können Sie die von Ihnen eingegebenen Kontextbefehle an das entsprechende Hilfsprogramm weiterleiten, das den Befehl anschließend ausführt. Ein Hilfsprogramm ist eine DLL-Datei (Dynamic Link Library), die die Funktionalität des Tools "Netsh.exe" erweitert und für einen oder mehrere Dienste, Dienstprogramme oder Protokolle Konfiguration, Überwachung und Unterstützung bereitstellt.

Für die Routingkonfiguration für die Replikationsnetzwerkadapter auf MBX1A und MBX2A wurde auf jedem Server der folgende Befehl ausgeführt.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Für die Routingkonfiguration für die Replikationsnetzwerkadapter auf MBX1B und MBX2B wurde auf jedem Server der folgende Befehl ausgeführt.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

Außerdem wurden die folgenden weiteren Netzwerkeinstellungen konfiguriert:

  • Das Kontrollkästchen Adressen dieser Verbindung in DNS registrieren wurde bei den MAPI-Netzwerkadaptern aller DAG-Mitglieder aktiviert und bei allen Replikationsnetzwerkadaptern deaktiviert.

  • Für jeden MAPI-Netzwerkadapter aller DAG-Mitglieder wurde mindestens eine DNS-Serveradresse konfiguriert. Für die Replikationsnetzwerkadapter wurde keine Adresse konfiguriert. Zu Redundanzzwecken verwendet Contoso für die MAPI-Netzwerkadapter mehrere DNS-Serveradressen.

  • IPv6 wird von Contoso nicht verwendet. Das Protokoll wurde auf den Servern deaktiviert.

  • Die Windows-Firewall wird von Contoso nicht verwendet. Sie wurde auf den Servern deaktiviert.

Nach der Konfiguration der Netzwerkadapter kann Contoso jetzt eine DAG erstellen und ihr Postfachserver hinzufügen.

Der Administrator hat sich für die Erstellung eines Windows PowerShell-Befehlszeilenskripts entschieden, mit dem mehrere Aufgaben ausgeführt werden:

Die folgenden Befehle werden im Skript verwendet:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer HUB-A -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

Mit dem obigen Befehl wird die DAG "DAG1" erstellt. "HUB-A" wird als Zeugenserver konfiguriert, und es wird ein spezielles Zeugenverzeichnis (C:\DAGWitness\DAG1.contoso.com) festgelegt. Für die DAG werden zwei IP-Adressen (eine für jedes Subnetz des MAPI-Netzwerks) konfiguriert.

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer HUB-B

Mit dem obigen Befehl wird die DAG "DAG1" für die Verwendung eines alternativen Zeugenservers "HUB-B" sowie eines alternativen Zeugenverzeichnisses auf HUB-B konfiguriert, und zwar unter Verwendung desselben Pfads, der für HUB-A konfiguriert wurde.

HinweisAnmerkung:
Es ist nicht unbedingt erforderlich, denselben Pfad zu verwenden; Contoso hat sich allerdings dafür entschieden, da die Konfiguration standardisiert werden sollte.
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1B
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2B

Mit den obigen Befehlen wird der DAG jeweils ein Postfachserver hinzugefügt. Mit diesen Befehlen wird auch die Failoverclusteringkomponente von Windows auf jedem Postfachserver installiert (falls noch nicht geschehen), ein Failovercluster erstellt und jeder Postfachserver mit dem neu erstellten Cluster verbunden.

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

Mit dem obigen Befehl wird für die DAG der DAC-Modus aktiviert.

Nachdem Contoso die DAG erstellt und ihr die Postfachserver hinzugefügt hat, wird die Erstellung der Postfachdatenbanken und Postfachdatenbankkopien vorbereitet. Damit die internen Kriterien für die Ausfallsicherheit erfüllt werden, plant Contoso, jede Postfachdatenbank mit drei unverzögerten Datenbankkopien und einer verzögerten Datenbankkopie zu konfigurieren. Für die verzögerte Kopie soll eine Protokollwiedergabeverzögerung von drei Tagen konfiguriert werden.

Mit dieser Konfiguration werden für jede Datenbank insgesamt vier Kopien (eine aktive, zwei unverzögerte passive und eine verzögerte passive Kopie) bereitgestellt. Contoso hat pro Server vier aktive Datenbanken vorgesehen. Mit den vier aktiven Datenbanken pro Server und den drei passiven Kopien pro Datenbank enthält die Contoso-Lösung insgesamt 16 Datenbankkopien.

Wie aus der folgenden Abbildung hervorgeht, hat sich Contoso hinsichtlich des Datenbanklayouts für einen ausgewogenen Ansatz entschieden.

Datenbankkopien – Layout für Contoso, Ltd

Datenbankkopie – Layout für Contoso, Ltd

Auf jedem Postfachserver befinden sich eine aktive Postfachdatenbankkopie, zwei unverzögerte passive Datenbankkopien und eine verzögerte passive Datenbankkopie. Die verzögerten Kopien der aktiven Postfachdatenbanken werden auf einem Postfachserver am anderen Standort gehostet.

Zum Erstellen dieser Konfiguration muss der Administrator mehrere Befehle ausführen.

Auf MBX1A:

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -SuspendComment "Seed from MBX2B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX1B -SourceServer MBX2B
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -ActivationOnly

Auf MBX2A:

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX2B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -SuspendComment "Seed from MBX1B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX2B -SourceServer MBX1B
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -ActivationOnly

Auf MBX1B:

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -SuspendComment "Seed from MBX2A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1A -SourceServer MBX2A
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -ActivationOnly

Auf MBX2B:

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -SuspendComment "Seed from MBX1A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2A -SourceServer MBX1A
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -ActivationOnly

Im obigen Beispiel wurde beim Cmdlet Add-MailboxDatabaseCopy der Parameter ActivationPreference nicht angegeben. Der Task inkrementiert automatisch bei jeder hinzugefügten Kopie die Aktivierungseinstellungsnummer. Die Originaldatenbank hat immer die Einstellungsnummer 1. Die erste mithilfe des Cmdlets Add-MailboxDatabaseCopy hinzugefügte Kopie erhält automatisch die Einstellungsnummer 2. Unter der Annahme, dass keine Kopien entfernt wurden, wird der nächsten hinzugefügten Kopie automatisch die Einstellungsnummer 3 zugeordnet usw. Daher hat in den obigen Beispielen die passive Kopie, die sich im selben Datencenter wie die aktive Kopie befindet, die Aktivierungseinstellungsnummer 2; die unverzögerte passive Kopie im Remotedatencenter hat die Aktivierungseinstellungsnummer 3 und die verzögerte passive Kopie im Remotedatencenter die Aktivierungseinstellungsnummer 4.

Obwohl es zwei Kopien von jeder aktiven Datenbank im WAN (Wide Area Network, Fernnetz) am anderen Standort gibt, erfolgte der Seedingvorgang nur einmal. Contoso nutzt nämlich die Möglichkeit von Exchange 2010, eine passive Datenbankkopie als Quelle für das Seeding zu verwenden. Mithilfe des Cmdlets Add-MailboxDatabaseCopy und des Parameters SeedingPostponed wird der Task daran gehindert, den Seedingvorgang für die neu erstellte Datenbankkopie automatisch auszuführen. Dann kann der Administrator die Kopie, für die kein Seeding erfolgt ist, anhalten und mithilfe des Cmdlets Update-MailboxDatabaseCopy und des Parameters SourceServer die lokale Kopie der Datenbank als Quelle für den Seedingvorgang angeben. Dadurch erfolgt der Seedingvorgang für die zweite Datenbankkopie, die jedem Standort hinzugefügt wird, lokal und nicht über das WAN.

HinweisAnmerkung:
Im obigen Beispiel erfolgt der Seedingvorgang für die unverzögerte Datenbankkopie über das WAN. Anschließend wird diese Kopie für das Seeding der verzögerten Kopie der Datenbank, die sich im selben Datencenter wie die unverzögerte Kopie befindet, verwendet.

Zum Schutz vor einer äußerst selten vorkommenden Beschädigung der Datenbanklogik, die katastrophale Folgen haben kann, hat Contoso eine passive Kopie jeder Postfachdatenbank als verzögerte Datenbankkopie konfiguriert. Daher konfiguriert der Administrator mithilfe des Cmdlets Suspend-MailboxDatabaseCopy und des Parameters ActivationOnly die verzögerten Kopien so, dass sie für eine Aktivierung gesperrt sind. Dadurch wird sichergestellt, dass die verzögerten Datenbankkopien bei einem Datenbank- oder Serverfailover nicht aktiviert werden.

Nach Bereitstellung und Konfiguration der Lösung führt der Administrator mehrere Aufgaben aus, anhand denen er die Lösung auf ihre Funktionsfähigkeit überprüft, bevor Produktionspostfächer in die Datenbanken in der DAG verschoben werden. Die Lösung sollte anhand mehrerer Methoden, einschließlich Fehlersimulationen, getestet und überprüft werden. Zum Überprüfen der Lösung führt der Administrator verschiedene Aufgaben aus.

Der Administrator führt das Cmdlet Test-ReplicationHealth aus, um den allgemeinen Status der DAG zu überprüfen. Mit diesem Cmdlet werden Replikations- und Wiedergabestatus unter verschiedenen Aspekten überprüft und Informationen zu jedem Postfachserver und jeder Datenbankkopie in der DAG bereitgestellt.

Zum Überprüfen von Replikations- und Wiedergabeaktivität führt der Administrator das Cmdlet Get-MailboxDatabaseCopyStatus aus. Dieses Cmdlet stellt Statusinformationen in Echtzeit zu einer bestimmten Postfachdatenbankkopie oder zu allen Postfachdatenbankkopien auf einem bestimmten Server bereit. Weitere Informationen zum Überwachen des Status replizierter Datenbanken in einer DAG finden Sie unter Überwachen von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

Zum Überprüfen, ob Switchover erwartungsgemäß funktionieren, führt der Administrator mithilfe des Cmdlets Move-ActiveMailboxDatabase eine Reihe von Datenbank- und Serverswitchovern durch. Nachdem diese Aufgaben erfolgreich durchgeführt wurden, verschiebt der Administrator mithilfe desselben Cmdlets die aktiven Datenbankkopien wieder an ihre ursprünglichen Speicherorte.

Zum Überprüfen des erwartungsgemäßen Verhaltens in verschiedenen Fehlerszenarien führt der Administrator mehrere Aufgaben aus, mit denen entweder Fehler simuliert oder tatsächlich verursacht werden. Der Administrator kann beispielsweise Folgendes tun:

  • MBX1A vom Stromnetz trennen (Stecker ziehen), wodurch ein Serverfailover ausgelöst wird. Der Administrator kann dann überprüfen, ob DB1 auf einem anderen Server (vorzugsweise MBX2A gemäß den Aktivierungseinstellungsnummern) aktiviert wird.

  • Den MAPI-Netzwerkadapter auf MBX2A vom Stromnetz trennen (Stecker ziehen), wodurch ein Serverfailover ausgelöst wird. Der Administrator kann dann überprüfen, ob DB2 auf einem anderen Server (vorzugsweise MBX1A gemäß den Aktivierungseinstellungsnummern) aktiviert wird.

  • Die von der aktiven Kopie von DB3 verwendete Festplatte offline schalten, wodurch ein Datenbankfailover ausgelöst wird. Der Administrator kann dann überprüfen, ob DB3 auf einem anderen Server (vorzugsweise MBX2B gemäß den Aktivierungseinstellungsnummern) aktiviert wird.

Je nach den geschäftlichen Anforderungen kann es noch weitere Fehlerszenarien geben, die in einer Organisation getestet werden. Nach der Simulation eines einzelnen Fehlers (z. B. Stecker ziehen) und der Überprüfung des Wiederherstellungsverhaltens der Lösung kann der Administrator die Lösung auf die ursprüngliche Konfiguration zurücksetzen. In einigen Fällen kann die Lösung auf mehrere gleichzeitige Fehler getestet werden. Letztlich gibt der Lösungsprüfplan vor, ob die Lösung nach jeder Fehlersimulation auf die ursprüngliche Konfiguration zurückgesetzt wird.

Außerdem kann der Administrator auch die Netzwerkverbindung zwischen den beiden Datencentern trennen und so den Ausfall eines Standorts simulieren. Ein Datencenterswitchover ist ein Prozess, der sehr viel mehr Überlegungen und Koordination verlangt; er wird jedoch empfohlen, wenn die bereitgestellte Lösung Ausfallsicherheit von Standorten für Messagingdienste und Daten bieten soll. Ausführliche Informationen zum Datencenterswitchover finden Sie unter Datencenterswitchover.

Nachdem die Lösung bereitgestellt wurde, kann sie über die inkrementelle Bereitstellung erweitert werden. An diesem Punkt erfolgt auch hinsichtlich der Verwaltung der Lösung eine Umstellung auf die Betriebsprozesse, bei denen die folgenden Aufgaben ausgeführt werden:

Weitere Informationen zum Verwalten der Lösung finden Sie unter Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft