Posts mit dem Label DAG werden angezeigt. Alle Posts anzeigen
Posts mit dem Label DAG werden angezeigt. Alle Posts anzeigen

Freitag, 28. November 2014

Exchange 2013 / 2010 - Verteilen der Datenbanken anhand der Präferenz

DAG ist eine feine Sache. Nie war es einfacher seine Exchange Daten ausfallsicher zur Verfügung zu stellen. Doch nach einem Failover gibt es keinen automatischen Failback der Datenbanken, obwohl den Datenbanken Präferenzen vergeben werden können oder besser müssen.

Bei mangelndem Monitoring der Exchange Server kommt es sogar vor, dass ein geschehener Failover nicht einmal auffällt. Um dies zu überwachen nehme ich meist ein Script von Paul Cunningham welches mir immer dann ein Mail schreibt, wenn auf dem Exchange etwas nicht so ist wie ich mir das wünsche: Test-ExchangeServerHealth

Wenn ich nun also feststelle, dass meine Datenbanken nicht auf den dafür vorgesehenen Servern aktiv sind, bediene ich mich eines Scripts welches wir von Microsoft bei der Installation von Exchange 2013 oder 2010 erhalten haben: RedistributeActiveDatabases.ps1

Um die mitinstallierten Scripts verwenden zu können müssen wir in der Exchange Shell zuerst in das entsprechende Verzeichnis wechseln. Die geht am einfachsten mittels folgenden Cmdlet:

cd $exscripts

Exchange 2013 - Ins Script Verzeichnis wechseln

Folgendes Cmdlet platziert die Datenbanken gemäss den konfigurierten Präferenzen:

.\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference -Confirm:$false


Weitere Infos zum Script findet ihr hier: Managing mailbox database copies (im unteren Bereich)

Freitag, 17. Januar 2014

Exchange 2013 auf Server 2012: Probleme beim erstellen einer DAG

Wenn Exchange 2013 auf einem Server 2012 installiert ist, gibt es Probleme beim Bilden einer DAG. Die Erstellung der DAG ist möglich, doch wenn man versucht Mailbox Server zur DAG hinzuzufügen kommt eine Fehlermeldung.


Um das Problem zu beheben, muss der FQDN im AD Clusterobjekt von Hand hinzugefügt werden.

Wenn man das AD-Objekt anschaut, sieht man, dass das Feld "DNS-Name" leer ist:


Es ist aber nicht möglich, direkt in das Feld rein zu schreiben. Dies muss über die Registerkarte "Attribute Editor" gemacht werden. Das zu befüllende Attribut heisst "dNSHostName":


Dies alleine löst aber das Problem noch nicht. Die Berechtigungen auf dem Objekt stimmen auch noch nicht. Wenn man im jetzigen Zustand versucht Mailbox Server zur DAG hinzuzufügen, bekommt man eine Fehlermeldung die besagt, dass der Zugriff verweigert wurde. Um dies zu beheben, muss man unter der Registerkarte "Security" der Gruppe "Exchange Trusted Subsystems" noch "Full Access" geben:


Nachdem dies erledigt ist, ist das Problem aber noch immer nicht vollständig gelöst. Im letzten Schritt muss das Objekt auch noch deaktiviert werden. Nun klappt es auch mit dem Hinzufügen von Mailbox Servern zur DAG.

Ich finde es doch sehr verwunderlich, dass dies auch nach dem Erscheinen des CU3 noch nicht behoben wurde...

Freitag, 13. Dezember 2013

Exchange DAG Cluster Fehler 1196 (Source Microsoft-Windows-FailoverClustering)

Normalerweise muss der Failover Cluster Manager für die Verwaltung einer DAG nicht bemüht werden. Doch wenn ich mir eine Exchange Umgebung anschaue will ich natürlich auch immer wissen ob in den Clusterereignissen Fehler zu finden sind.

Häufig treffe ich dann auf folgenden Fehler:

Protokollname:             System
Quelle:                    Microsoft-Windows-FailoverClustering
Datum:                     13.12.2013 11:50:42
Ereignis-ID:               1196
Aufgabenkategorie:         Netzwerknamenressource
Ebene:                     Fehler
Schlüsselwörter:
Benutzer:                  SYSTEM
Computer:                  EXCLAB-MBX01.mydomain.ch


Beschreibung:
Die Cluster-Netzwerknamensressource "Clustername" konnte mindestens einen dazugehörigen DNS-Namen nicht registrieren. Ursache:
Der DNS-Vorgang wurde abgelehnt.

Freitag, 6. Dezember 2013

Exchange 2013 - DAG Netzwerke für Clients und Replikation trennen

Auch unter Exchange 2013 ist es für eine DAG möglich, die Netzwerke für den Clientzugriff und die DAG Replikation zu trennen. Wie dies eingerichtet wird, zeige ich in diesem Post.

Vorbereitung

Grundsätzlich müssen die MBX Server, die Mitglied der DAG sind mal zwei Netzwerkkarten haben, um die Netze trennen zu können. Ich habe mir dazu auf dem Hyper-V Host einen privaten virtuellen Switch erstellt. Unter Hyper-V bedeutet ein privater virtueller Switch, dass nur VM's die mit dem Switch verbunden sind, miteinander kommunizieren können. Auch der Hyper-V Host selbst kommt nicht an das Netzt ran. Also also ob man zwei Hardware Server über einem Switch miteinander verbindet.

Montag, 21. Oktober 2013

DB Mounten bei DAG Problemen

Bei Problemen mit der DAG unter Exchange 2010 oder 2013 kann es dazu kommen, dass sich die Mailbox-DBs nicht mehr mounten lassen, weil die DAG nicht funktionsfähig ist. Natürlich sollte das Problem der DAG analysiert und behoben werden. Doch es kann auch der Fall auftreten, dass die DBs so schnell wie möglich wieder gemountet werden müssen und man dann in Ruhe nach dem Problem der DAG suchen kann.
Dies geht aber nicht, weil jede DB einen Master hat. In Umgebungen ohne DAG ist dies der MBX Server auf welchem die DB läuft. Wenn eine DAG erstellt wurde, wird als Master der DB die DAG eingetragen. Darum lassen sich DBs nur mounten, wenn die DAG, welche der Master ist, auch funktionsfähig ist.