116480
Nov 21, 2014, updated at 14:17:55 (UTC)
7149
0
0
Exchange 2013 und DAG
Exchange DAG
Eine wesentliche Neuerung in Exchange 2013 ist der Wegfall der Speichergruppen (Storagegroups). Datenbanken sind nunmehr direkt einem Server zugeordnet und können auf andere Server verschoben werden. Die unterschiedlichen Varianten der Ausfallsicherheit, die mit Exchange 2007 eingeführt wurden, wie z.B. Local Continous Copy, CCR (Cluster Continous Replication), werden unter Exchange 2013 durch die Datenbankverfügbarkeitsgruppe (Database Availability Group = DAG) ersetzt.
In einer DAG können bis zu 16 Server aufgenommen werden, dabei können bis zu 14 Kopien jeder Datenbank auf den verschiedenen DAG Mitgliedsservern angelegt werden. Für die Replikation der Datenbanken kann eine separate Netzwerkverbindung verwendet werden. Für die Übertragung der Daten kann ein Netzwerkkompressionsverfahren aktiviert werden.
Voraussetzungen
Für die Einrichtung einer DAG werden mindestens 2 Exchange 2013 mit installierter Postfachserver-Rolle benötigt. Da für die DAG Windows Cluster Funktionen zum Einsatz kommen, muss für diese Server die Enterprise Version des Betriebssystems verwendet werden (Windows Server 2008 SP2, oder Windows Server 2008 R2). Am besten Server 2012 R2 verwenden. Bei einer geraden Anzahl Postfachserver wird ein weiterer Server als Witness Server benötigt. Der Witness Server hält das Quorum und muss folgende Voraussetzungen erfüllen:
•Kann ein Exchange Server sein, darf aber nicht die Postfachserver-Rolle installiert haben.
Wenn kein Exchange noch nicht ganz die Konfig klar (Ist meine alte 2010er Anleitung, angepasst. Werde das nachreichen !) Bei Exchange, da nur noch 2 Rollen, auch unklar, weil dann müsste er ja CAS sein. Da er nicht Postfahc sein darf !
•Wenn kein Exchange Server 2013 als Witness Server verwendet wird, muss die globale Sicherheits Gruppe Exchange Trusted Subsystem der lokalen Administratorengruppe hinzugefügt werden (Quelle: http://technet.microsoft.com/de-de/library/dd298065.aspx)
•Der Witness Server kann nicht Miglied der DAG sein
Anwendung
Für jede Postfachdatenbank können bis zu 14 Kopien auf den Mitgliedsservern der DAG angelegt werden, wobei jeder Server nur eine Kopie einer bestimmten Datenbank halten kann. Wichtig: Der Pfad der Datenbankkopie ist identisch mit dem Pfad des Originals, d.h. die verwendeten Pfade sollten auf den Mitgliedsservern der DAG identisch sein. Die Datenbankkopien können entweder über die Exchange Verwaltungskonsole oder auch durch Verwendung der Verwaltungsshell angelegt werden.
Intersite
Eine Stärke der DAG ist die Tatsache, dass die Mitgliedsserver einer DAG über mehrere Standorte bzw. Active Directory Sites verteilt sein können.
Das Kleingedruckte
Kopien können nur von Postfachdatenbanken angelegt werden. Datenbanken für öffentliche Ordner können nicht im Rahmen einer DAG auf verschiedene Server kopiert werden. Da die Public Folder aber von Hause aus die Replikation auf verschiedene Server unterstützen, sollte dies kein nennenswerter Nachteil sein
Maschinen die im DAG Cluster sind, bekommen über das ESXI 2 Netzkarten zugewiesen.
Es wird ein zusätzliches Netz für das DAG benötigt.
Auf Server Karte mit DAG kennzeichnen.
AG Netzwerkarte ohne Gateway definieren und ohne DNS.
Adressen dieser Verbindung nicht im DNS registrieren !
Organisation Configuration \ Mailbox
New Database Availibility Service
DAG wurde erstellt.
Nun müssen Member hinzugefügt werden.
Mitglieder hinzufügen
DER DAG Gruppe eine IP Zuweisen.
DAG ist erstellt
Ansicht in der MMC , welcher Server Aktiv .
Upgrade Server 2008 R2 Standard auf Enterprise
DAG kann nicht auf Server 2008 R2 Standard installiert werden.
Voraussetung Server 2008 R2 Enterprise oder Datacenter.
Nun gut, Enterprise License macht es möglich: Also Upgrade der bestehenden Maschine von Standard auf Enterprise. Wie?
Netterweise ist es leicht möglich, ein In-Place Upgrade (ohne Installationsmedium) durchzuführen, und zwar mit dem Tool DISM.exe.
DISM ist das “Deployment Image Servicing and Management Tool” für Windows Server 2008 und Windows 7, mehr dazu hier:
What Is Deployment Image Servicing and Management?
Achtung: Das In-Place Upgrade mit DISM funktioniert NICHT auf einem Domain Controller! Dieser muss zuvor mit dcpromo heruntergestuft werden, das Upgrade durchgeführt werden und dann wieder zum DC hinaufgestuft werden! Diese Situation werden aber wahrscheinlich wenige Admins haben, sonst funktioniert DISM eigentlich (fast) problemlos.
Die Kurzfassung des Upgrades: (siehe auch Upgrading Windows Server 2008 R2 without media):
• DISM /online /Get-CurrentEdition
liefert die aktuell verwendete Windows Edition
• DISM /online /Get-TargetEditions
liefert die möglichen Upgrade-Editionen
• DISM /online /Set-Edition:<edition ID> /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
führt das In-Place Upgrade auf eine bestimmte Edition durch
• Beispiel :
DISM /online /Set-Edition:ServerEnterprise /ProductKey:
Klingt einfach – ist es grundsätzlich auch – wenn da nicht ein kleiner Stolperstein wäre. Also starten wir mal:
DISM /online /Get-CurrentEdition
Ok, wir haben die Standard-Edition installiert.
DISM /online /Get-TargetEditions
Gut, wir können auf Enterprise upgraden. Tun wir´s (mit dem installierten Key).
Gut, wir können auf Enterprise upgraden. Tun wir´s (mit dem installierten Key).
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Gut, wir können auf Enterprise upgraden. Tun wir´s (mit dem installierten Key).
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Es folgt jedoch ein Fehler. Es klappt nicht:
Es gibt ein Problem mit dem Product Key. Obwohl dieser gültig ist (Windows ist aktiviert), funktioniert das Upgrade nicht.
Die Ursache liegt am Installationsmedium und dem verwendeten Product Key. Wenn es sich um eine Volume License (VL) handelt, so streikt DISM, wenn die Windows Version mit einem Multiple Activation Key (MAK) oder einem Key Management Service (KMS) Schlüssel installiert wurde! Siehe auch Informationen zur Produktaktivierung und zu Produktschlüsseln.
Die Lösung: Nach einigem Suchen habe ich sie in diesen Links gefunden:
• TechNet KMS Client Setup Keys
• Windows 2008 R2 KMS Licensing Issues
• Error Installing SP1 on Server 2008 R2
• In-place upgrade from Windows Server Standard to Enterprise or Datacenter
In diesem Satz in der TechNet KMS Seite liegt der Grund:
“By default, the Windows 7 and Windows Server 2008 R2 operating systems use KMS for activation. In volume installations, the setup key is installed by default, which makes the system a KMS client. If you are converting a computer from a KMS host, MAK, or retail edition of Windows to a KMS client, install the applicable setup key (GVLK) from Table 9 using slmgr /ipk <setup key>.”
In VL Installationen macht der hinterlegte Product Key das System zu einem KMS Client. Daher muss auch dieser für das Upgrade verwendet werden.
Nachdem auch ich die VL-Product Keys verwendet habe, ist die Lösung, das Upgrade auf Enterprise Edition mit DIESEM (KMS) Product Key durchzuführen:
DISM /online /Set-Edition:ServerEnterprise /ProductKey:
--->>> Bei Postfachserver bin ich mir nicht sicher , ob man damit die Mailbox Rolle meint. Ich meinte , ich hätte bei Exchange 2010 den DAG über 2 Mailboxserver erstellt !
Sollten aber 2 Mailbox Server reichen. http://exchangeserverpro.com/installing-an-exchange-server-2013-databas ... . Der Fileshare ist einfach ein Fileshare Server mit Fileserverrolle der explizit berechtigt ist.
Also sollte man den Share nicht gerade auf dem DAG haben !! CAS würde aber gehen !
Eine wesentliche Neuerung in Exchange 2013 ist der Wegfall der Speichergruppen (Storagegroups). Datenbanken sind nunmehr direkt einem Server zugeordnet und können auf andere Server verschoben werden. Die unterschiedlichen Varianten der Ausfallsicherheit, die mit Exchange 2007 eingeführt wurden, wie z.B. Local Continous Copy, CCR (Cluster Continous Replication), werden unter Exchange 2013 durch die Datenbankverfügbarkeitsgruppe (Database Availability Group = DAG) ersetzt.
In einer DAG können bis zu 16 Server aufgenommen werden, dabei können bis zu 14 Kopien jeder Datenbank auf den verschiedenen DAG Mitgliedsservern angelegt werden. Für die Replikation der Datenbanken kann eine separate Netzwerkverbindung verwendet werden. Für die Übertragung der Daten kann ein Netzwerkkompressionsverfahren aktiviert werden.
Voraussetzungen
Für die Einrichtung einer DAG werden mindestens 2 Exchange 2013 mit installierter Postfachserver-Rolle benötigt. Da für die DAG Windows Cluster Funktionen zum Einsatz kommen, muss für diese Server die Enterprise Version des Betriebssystems verwendet werden (Windows Server 2008 SP2, oder Windows Server 2008 R2). Am besten Server 2012 R2 verwenden. Bei einer geraden Anzahl Postfachserver wird ein weiterer Server als Witness Server benötigt. Der Witness Server hält das Quorum und muss folgende Voraussetzungen erfüllen:
•Kann ein Exchange Server sein, darf aber nicht die Postfachserver-Rolle installiert haben.
Wenn kein Exchange noch nicht ganz die Konfig klar (Ist meine alte 2010er Anleitung, angepasst. Werde das nachreichen !) Bei Exchange, da nur noch 2 Rollen, auch unklar, weil dann müsste er ja CAS sein. Da er nicht Postfahc sein darf !
•Wenn kein Exchange Server 2013 als Witness Server verwendet wird, muss die globale Sicherheits Gruppe Exchange Trusted Subsystem der lokalen Administratorengruppe hinzugefügt werden (Quelle: http://technet.microsoft.com/de-de/library/dd298065.aspx)
•Der Witness Server kann nicht Miglied der DAG sein
Anwendung
Für jede Postfachdatenbank können bis zu 14 Kopien auf den Mitgliedsservern der DAG angelegt werden, wobei jeder Server nur eine Kopie einer bestimmten Datenbank halten kann. Wichtig: Der Pfad der Datenbankkopie ist identisch mit dem Pfad des Originals, d.h. die verwendeten Pfade sollten auf den Mitgliedsservern der DAG identisch sein. Die Datenbankkopien können entweder über die Exchange Verwaltungskonsole oder auch durch Verwendung der Verwaltungsshell angelegt werden.
Intersite
Eine Stärke der DAG ist die Tatsache, dass die Mitgliedsserver einer DAG über mehrere Standorte bzw. Active Directory Sites verteilt sein können.
Das Kleingedruckte
Kopien können nur von Postfachdatenbanken angelegt werden. Datenbanken für öffentliche Ordner können nicht im Rahmen einer DAG auf verschiedene Server kopiert werden. Da die Public Folder aber von Hause aus die Replikation auf verschiedene Server unterstützen, sollte dies kein nennenswerter Nachteil sein
Maschinen die im DAG Cluster sind, bekommen über das ESXI 2 Netzkarten zugewiesen.
Es wird ein zusätzliches Netz für das DAG benötigt.
Auf Server Karte mit DAG kennzeichnen.
AG Netzwerkarte ohne Gateway definieren und ohne DNS.
Adressen dieser Verbindung nicht im DNS registrieren !
Organisation Configuration \ Mailbox
New Database Availibility Service
DAG wurde erstellt.
Nun müssen Member hinzugefügt werden.
Mitglieder hinzufügen
DER DAG Gruppe eine IP Zuweisen.
DAG ist erstellt
Ansicht in der MMC , welcher Server Aktiv .
Upgrade Server 2008 R2 Standard auf Enterprise
DAG kann nicht auf Server 2008 R2 Standard installiert werden.
Voraussetung Server 2008 R2 Enterprise oder Datacenter.
Nun gut, Enterprise License macht es möglich: Also Upgrade der bestehenden Maschine von Standard auf Enterprise. Wie?
Netterweise ist es leicht möglich, ein In-Place Upgrade (ohne Installationsmedium) durchzuführen, und zwar mit dem Tool DISM.exe.
DISM ist das “Deployment Image Servicing and Management Tool” für Windows Server 2008 und Windows 7, mehr dazu hier:
What Is Deployment Image Servicing and Management?
Achtung: Das In-Place Upgrade mit DISM funktioniert NICHT auf einem Domain Controller! Dieser muss zuvor mit dcpromo heruntergestuft werden, das Upgrade durchgeführt werden und dann wieder zum DC hinaufgestuft werden! Diese Situation werden aber wahrscheinlich wenige Admins haben, sonst funktioniert DISM eigentlich (fast) problemlos.
Die Kurzfassung des Upgrades: (siehe auch Upgrading Windows Server 2008 R2 without media):
• DISM /online /Get-CurrentEdition
liefert die aktuell verwendete Windows Edition
• DISM /online /Get-TargetEditions
liefert die möglichen Upgrade-Editionen
• DISM /online /Set-Edition:<edition ID> /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
führt das In-Place Upgrade auf eine bestimmte Edition durch
• Beispiel :
DISM /online /Set-Edition:ServerEnterprise /ProductKey:
Klingt einfach – ist es grundsätzlich auch – wenn da nicht ein kleiner Stolperstein wäre. Also starten wir mal:
DISM /online /Get-CurrentEdition
Ok, wir haben die Standard-Edition installiert.
DISM /online /Get-TargetEditions
Gut, wir können auf Enterprise upgraden. Tun wir´s (mit dem installierten Key).
Gut, wir können auf Enterprise upgraden. Tun wir´s (mit dem installierten Key).
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Gut, wir können auf Enterprise upgraden. Tun wir´s (mit dem installierten Key).
DISM /online /Set-Edition:ServerEnterprise /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
Es folgt jedoch ein Fehler. Es klappt nicht:
Es gibt ein Problem mit dem Product Key. Obwohl dieser gültig ist (Windows ist aktiviert), funktioniert das Upgrade nicht.
Die Ursache liegt am Installationsmedium und dem verwendeten Product Key. Wenn es sich um eine Volume License (VL) handelt, so streikt DISM, wenn die Windows Version mit einem Multiple Activation Key (MAK) oder einem Key Management Service (KMS) Schlüssel installiert wurde! Siehe auch Informationen zur Produktaktivierung und zu Produktschlüsseln.
Die Lösung: Nach einigem Suchen habe ich sie in diesen Links gefunden:
• TechNet KMS Client Setup Keys
• Windows 2008 R2 KMS Licensing Issues
• Error Installing SP1 on Server 2008 R2
• In-place upgrade from Windows Server Standard to Enterprise or Datacenter
In diesem Satz in der TechNet KMS Seite liegt der Grund:
“By default, the Windows 7 and Windows Server 2008 R2 operating systems use KMS for activation. In volume installations, the setup key is installed by default, which makes the system a KMS client. If you are converting a computer from a KMS host, MAK, or retail edition of Windows to a KMS client, install the applicable setup key (GVLK) from Table 9 using slmgr /ipk <setup key>.”
In VL Installationen macht der hinterlegte Product Key das System zu einem KMS Client. Daher muss auch dieser für das Upgrade verwendet werden.
Nachdem auch ich die VL-Product Keys verwendet habe, ist die Lösung, das Upgrade auf Enterprise Edition mit DIESEM (KMS) Product Key durchzuführen:
DISM /online /Set-Edition:ServerEnterprise /ProductKey:
--->>> Bei Postfachserver bin ich mir nicht sicher , ob man damit die Mailbox Rolle meint. Ich meinte , ich hätte bei Exchange 2010 den DAG über 2 Mailboxserver erstellt !
Sollten aber 2 Mailbox Server reichen. http://exchangeserverpro.com/installing-an-exchange-server-2013-databas ... . Der Fileshare ist einfach ein Fileshare Server mit Fileserverrolle der explizit berechtigt ist.
Also sollte man den Share nicht gerade auf dem DAG haben !! CAS würde aber gehen !
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 255533
Url: https://administrator.de/contentid/255533
Printed on: April 24, 2024 at 08:04 o'clock
