34
Exchange DAG macht kein Switchover
Hallo zusammen,
ich habe gerade einen Switchover von Exchange1 auf Exchange2 durchgeführt und begonnen Exchange1auf die neueste CU upzudaten (Exchange 2016). Als die Installation begann, sieht man den Status, dass die Dienste von Exchange1 beendet werden, trotzdem bekommt Outlook keine Verbindung mehr. Das Webinterface (OWA und ECP) vom Exchange2 sind noch zu sehen, sobald man sich jedoch anmeldet, bleibt es bei einem weissen leeren Bildschirm. Die Dienste von Server2 sind jedoch alle noch gestartet.
Ich dachte Exchange2 sollte übernehmen?!? Wozu dann ein Switchover und eine DAG? Warum läuft das nicht redundant?
Danke Euch in Voraus and keep rockin
Der Mike
ich habe gerade einen Switchover von Exchange1 auf Exchange2 durchgeführt und begonnen Exchange1auf die neueste CU upzudaten (Exchange 2016). Als die Installation begann, sieht man den Status, dass die Dienste von Exchange1 beendet werden, trotzdem bekommt Outlook keine Verbindung mehr. Das Webinterface (OWA und ECP) vom Exchange2 sind noch zu sehen, sobald man sich jedoch anmeldet, bleibt es bei einem weissen leeren Bildschirm. Die Dienste von Server2 sind jedoch alle noch gestartet.
Ich dachte Exchange2 sollte übernehmen?!? Wozu dann ein Switchover und eine DAG? Warum läuft das nicht redundant?
Danke Euch in Voraus and keep rockin
Der Mike
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666176
Url: https://administrator.de/contentid/666176
Ausgedruckt am: 24.11.2024 um 19:11 Uhr
34 Kommentare
Neuester Kommentar
Guten Morgen,
hast du denn ein NLB davor oder wie steuerst du den Client Zugriff? Die DAG selbst hat ja kein NLB sondert dient ja nur zur Erstellung und Steuerung der Datenbankkopien (ganz einfach gesagt). Auf welchen Server zeigen deinen Urls vom owa, ecp etc? Hast du den A-Record vorher auf den verbleibenden geschwenkt?
Mit freundlichen Grüßen
Micha
hast du denn ein NLB davor oder wie steuerst du den Client Zugriff? Die DAG selbst hat ja kein NLB sondert dient ja nur zur Erstellung und Steuerung der Datenbankkopien (ganz einfach gesagt). Auf welchen Server zeigen deinen Urls vom owa, ecp etc? Hast du den A-Record vorher auf den verbleibenden geschwenkt?
Mit freundlichen Grüßen
Micha
Ich habe einen HA Proxy davor, der Transparent zum Server2 durchlässt, ich habe Server1 am HAproxy deaktiviert.
Ein Test mit https und Telnet Port 25 zeigt, dass alles schön zum Server2 durch geht. Ich kann auch Emails an Server2 über den HAproxy schicken. Nur die Clients mögen sich nicht mehr verbinden. Die URLs und DNS Records zeigen alle auf den HA Proxy. Das Zertifikat (über https) zeigt den Server2 an. Wie gesagt, auch ein direkter Aufruf auf https://server2.domain.intern/ecp bringt den Anmeldebildschirm vom Server2, Und eben nach der Anmeldung an dieser Seite kommt danach ein leerer weisser Browserinhalt. Also wird es nicht am HAproxy liegen. Server2 mag alleine einfach nicht mehr arbeiten bzw die Clients abservieren, aber Emails nimmt er noch an..
Ein Test mit https und Telnet Port 25 zeigt, dass alles schön zum Server2 durch geht. Ich kann auch Emails an Server2 über den HAproxy schicken. Nur die Clients mögen sich nicht mehr verbinden. Die URLs und DNS Records zeigen alle auf den HA Proxy. Das Zertifikat (über https) zeigt den Server2 an. Wie gesagt, auch ein direkter Aufruf auf https://server2.domain.intern/ecp bringt den Anmeldebildschirm vom Server2, Und eben nach der Anmeldung an dieser Seite kommt danach ein leerer weisser Browserinhalt. Also wird es nicht am HAproxy liegen. Server2 mag alleine einfach nicht mehr arbeiten bzw die Clients abservieren, aber Emails nimmt er noch an..
Hallo,
Sry erst mal für die vielen Fragen, aber man muss sich erst mal ein Bild der Umgebung machen
Wie hast du den Switchover durchgeführt? Ist der Witness der DAG noch vom Server2 aus erreichbar? Wie ist dort der Status?
Mit freundlichen Grüßen
Micha
Sry erst mal für die vielen Fragen, aber man muss sich erst mal ein Bild der Umgebung machen
Wie hast du den Switchover durchgeführt? Ist der Witness der DAG noch vom Server2 aus erreichbar? Wie ist dort der Status?
Mit freundlichen Grüßen
Micha
Um den Wittnes habe ich mich, ehrlich gesagt, gar nicht gekümmert. Jetzt kann ich den Status aber nicht mehr abfragen, die Installation ist beendet und alles ist wieder online. Ich kann den Test aber irgendwann machen, wenn ich einen Server zur Nachtzeit herunter fahren kann. Aber ja, der Witness ist ständig online gewesen und im gleichen Netz, wie die zwei Exchange Server. Das Zabbix Monitoring hat auch nicht gemeldet, dass der Wittnes Server offline wäre, also gehe ich davon aus, dass er alles mitbekommen hat.
Den Switchover habe ich im ECP bei den Datenbanken durchgeführt. Wie du schon sagtest, das hat scheinbar nichts mit dem Clientzugriff zu tun.
Stelle ruhig viele Fragen, ich lerne auch daraus, was jemand Anderes so von sich gibt :c)
Den Switchover habe ich im ECP bei den Datenbanken durchgeführt. Wie du schon sagtest, das hat scheinbar nichts mit dem Clientzugriff zu tun.
Stelle ruhig viele Fragen, ich lerne auch daraus, was jemand Anderes so von sich gibt :c)
Hallo,
Das klingt schonmal gut. Die Zertifikate stimmen hier aber auch alle oder ? Also auf beiden exchange ist ein Zertifikat installiert und an http gebunden welches die zugriffs url für owa und co enthällt ?
Also wenn du mit deinen clients zum exchange die Verbindung via „owa.domain.local“ aufbaust dann haben beide server sowie natürlich der ha proxy dieses Zertifikat installiert?
Weil eine Blank Page deutet manchmal auf ssl Probleme hin. Kannst du dir mal die iis logs anschauen wenn du die Verbindung aufbaust und die site leer ist, was kommt dort für ein Fehler?
Mit freundlichen Grüßen
Micha
Das klingt schonmal gut. Die Zertifikate stimmen hier aber auch alle oder ? Also auf beiden exchange ist ein Zertifikat installiert und an http gebunden welches die zugriffs url für owa und co enthällt ?
Also wenn du mit deinen clients zum exchange die Verbindung via „owa.domain.local“ aufbaust dann haben beide server sowie natürlich der ha proxy dieses Zertifikat installiert?
Weil eine Blank Page deutet manchmal auf ssl Probleme hin. Kannst du dir mal die iis logs anschauen wenn du die Verbindung aufbaust und die site leer ist, was kommt dort für ein Fehler?
Mit freundlichen Grüßen
Micha
ich habe gerade einen Switchover von Exchange1 auf Exchange2 durchgeführt und begonnen Exchange1auf die neueste CU upzudaten (Exchange 2016). Als die Installation begann, sieht man den Status, dass die Dienste von Exchange1 beendet werden, trotzdem bekommt Outlook keine Verbindung mehr. Das Webinterface (OWA und ECP) vom Exchange2 sind noch zu sehen, sobald man sich jedoch anmeldet, bleibt es bei einem weissen leeren Bildschirm. Die Dienste von Server2 sind jedoch alle noch gestartet.
Ich dachte Exchange2 sollte übernehmen?!? Wozu dann ein Switchover und eine DAG? Warum läuft das nicht redundant?
Ich dachte Exchange2 sollte übernehmen?!? Wozu dann ein Switchover und eine DAG? Warum läuft das nicht redundant?
Der DAG Knoten wurde auch in den Wartungsmodus gesetzt? Der vorgeschaltete LB bekommt das dann in der Regel auch mit und verteilt die Anfragen entsprechend.
@MichaelSch83
Ja, SSL und Zertifikate passen. Ein SSL Fehler kann es nicht sein, da beim Anmeldebildschirm das Zertifikat noch richtig angezeigt wird. Auf der weissen Seite dann übrigens auch :c)
@mbehrens
Das könnte der Knackpunkt sein. Ich habe wirklich nur den Switchover über ecp angetriggert.
Nur, wenn es notwendig ist diesen Wartungsmodus manuell einzustellen, dann funktioniert ja gar kein Failover, wenn ein Server unbeaufsichtigt stirbt ?!?
Danke an euch Beide fürs miträtseln...
Ja, SSL und Zertifikate passen. Ein SSL Fehler kann es nicht sein, da beim Anmeldebildschirm das Zertifikat noch richtig angezeigt wird. Auf der weissen Seite dann übrigens auch :c)
@mbehrens
Das könnte der Knackpunkt sein. Ich habe wirklich nur den Switchover über ecp angetriggert.
Nur, wenn es notwendig ist diesen Wartungsmodus manuell einzustellen, dann funktioniert ja gar kein Failover, wenn ein Server unbeaufsichtigt stirbt ?!?
Danke an euch Beide fürs miträtseln...
Das könnte der Knackpunkt sein. Ich habe wirklich nur den Switchover über ecp angetriggert.
Nur, wenn es notwendig ist diesen Wartungsmodus manuell einzustellen, dann funktioniert ja gar kein Failover, wenn ein Server unbeaufsichtigt stirbt ?!?
Nur, wenn es notwendig ist diesen Wartungsmodus manuell einzustellen, dann funktioniert ja gar kein Failover, wenn ein Server unbeaufsichtigt stirbt ?!?
Es besteht schon ein Unterschied, ob man das ganze geplant oder ungeplant macht.
Wird zum Beispiel den Servern und Clients mitgeteilt, sich jetzt wg. Wartung mit einem anderen System zu verbinden oder die Replikation einzustellen. Zusätzlich muss natürlich der LB auch über passende Mechanismen prüfen, ob die Dienste noch zur Verfügung stehen.
Welcher Unterschied wäre das? Hast du einen technische Beschreibung dazu?
Ich sehe das so: Die Clients müssen in der Lage sein im Fehlerfall den noch funktionierenden Server zu kontaktieren, egal, ob einer geplant oder ungeplant ausgefallen ist.
Der Loadbalancer wurde geplant auf Server 2 umgestellt, wobei der Loadbalancer das mit alive-Tests auch selbst feststellen hätte können (es ist ja kein Loadbalancer, sondern ein HA Proxy). Nach dieser Umstellung und vor der Installation wurde geprüft, ob die Clients sich noch verbinden. Der Kontakt zu Server2 ist bestätigt, die angezeigte Login Seite trägt das Zertifikat vom Server2. Whireshark sieht die Zugriffe auf Server2. Der LB hat seine Arbeit also gut verrichtet. Die Logs auf Server2 füllen sich mit Anfragen.
Server 2 hat seine Arbeit eingestellt, als das Setup auf Server1 die Exchange Dienste von Server1 beendet hat um Dateien zu kopieren. Seit dem kommt eben zwar noch die Anmeldeseite von Server2, aber nach dem Anmelden kein Inhalt mehr. Ich denke er sucht die Datenbank auf Server1 (dessen Dienste gestoppt sind) und hängt dabei.
Als die Installation auf Server1 fertig war, hat das Setup die Dienste von Server1 wieder gestartet, genau in diesem Moment hat Server2 wieder das OWA und ECP angezeigt, der Loadbalancer war nach wie vor noch immer auf Server2 eingestellt. Server 2 mag also ohne Server1 nicht - wobei er das, egal ob Server1 geplant oder ungeplant verschwunden ist, machen sollte :c)
Ich sehe das so: Die Clients müssen in der Lage sein im Fehlerfall den noch funktionierenden Server zu kontaktieren, egal, ob einer geplant oder ungeplant ausgefallen ist.
Der Loadbalancer wurde geplant auf Server 2 umgestellt, wobei der Loadbalancer das mit alive-Tests auch selbst feststellen hätte können (es ist ja kein Loadbalancer, sondern ein HA Proxy). Nach dieser Umstellung und vor der Installation wurde geprüft, ob die Clients sich noch verbinden. Der Kontakt zu Server2 ist bestätigt, die angezeigte Login Seite trägt das Zertifikat vom Server2. Whireshark sieht die Zugriffe auf Server2. Der LB hat seine Arbeit also gut verrichtet. Die Logs auf Server2 füllen sich mit Anfragen.
Server 2 hat seine Arbeit eingestellt, als das Setup auf Server1 die Exchange Dienste von Server1 beendet hat um Dateien zu kopieren. Seit dem kommt eben zwar noch die Anmeldeseite von Server2, aber nach dem Anmelden kein Inhalt mehr. Ich denke er sucht die Datenbank auf Server1 (dessen Dienste gestoppt sind) und hängt dabei.
Als die Installation auf Server1 fertig war, hat das Setup die Dienste von Server1 wieder gestartet, genau in diesem Moment hat Server2 wieder das OWA und ECP angezeigt, der Loadbalancer war nach wie vor noch immer auf Server2 eingestellt. Server 2 mag also ohne Server1 nicht - wobei er das, egal ob Server1 geplant oder ungeplant verschwunden ist, machen sollte :c)
Hallo,
Bei einer DAG kann jeder aktive Knoten den Clientzugriff realisieren .. unabhängig davon wo die Datenbank aktiv liegt. Wenn z.b. der Server1 die aktive DB hostet und der Client aber durch den HAProxy auf Server2 landet dann kann der Client sich ja auch verbinden. Sobald die Datenbank also durch deinen Switchover geschwenkt wurden (alles auf Server1) muss der Zugriff funktionieren.
Dein Argument das es bei einem richtigen Ausfall auch gehen muss stimmt, da dauert es nur etwas länger bis die DAG den Knoten als „offline“ erkennt und die DB schwenkt.
Die angesprochene Maintenance die man per Powershell aktiviert schwenkt unter anderem auch die Datenbanken (neben Knoten offline nehmen) . Du könntest es ja mal damit probieren .. aber ich denke das wird das gleiche Fehlerbild geben.
Siehe z.b hier: https://ehloexchange.com/exchange-maintenance-mode/ (gibt auch viele andere)
Hatte ich es richtig verstanden das jeder deiner Exchange ein eigenes Zertifikat hat, wobei bei jedem der öffentliche Name enthalten ist? Oder ist das ein Zertifikat wo alle Namen aller Server enthalten ist.
Kannst du mal folgendes auf jedem Server ausführen ausführen (nur oben den Namen anpassen) und den Output posten (gern auch per PN).
$servername = "Server1"
Get-OwaVirtualDirectory -Server $servername | fl internalurl, externalurl
Get-EcpVirtualDirectory -server $servername | fl internalurl, externalurl
Get-WebServicesVirtualDirectory -server $servername| fl internalurl, externalurl
Get-ActiveSyncVirtualDirectory -Server $servername | fl internalurl, externalurl
Get-OabVirtualDirectory -Server $servername | fl internalurl, externalurl
Get-MapiVirtualDirectory -Server $servername | fl externalurl, internalurl
Get-ClientAccessService $servername | fl AutoDiscoverServiceInternalUri
Get-Mailboxdatabase | fl Server,AdminDisplayName, rpc*
Mit freundlichen Grüßen
Micha
Bei einer DAG kann jeder aktive Knoten den Clientzugriff realisieren .. unabhängig davon wo die Datenbank aktiv liegt. Wenn z.b. der Server1 die aktive DB hostet und der Client aber durch den HAProxy auf Server2 landet dann kann der Client sich ja auch verbinden. Sobald die Datenbank also durch deinen Switchover geschwenkt wurden (alles auf Server1) muss der Zugriff funktionieren.
Dein Argument das es bei einem richtigen Ausfall auch gehen muss stimmt, da dauert es nur etwas länger bis die DAG den Knoten als „offline“ erkennt und die DB schwenkt.
Die angesprochene Maintenance die man per Powershell aktiviert schwenkt unter anderem auch die Datenbanken (neben Knoten offline nehmen) . Du könntest es ja mal damit probieren .. aber ich denke das wird das gleiche Fehlerbild geben.
Siehe z.b hier: https://ehloexchange.com/exchange-maintenance-mode/ (gibt auch viele andere)
Hatte ich es richtig verstanden das jeder deiner Exchange ein eigenes Zertifikat hat, wobei bei jedem der öffentliche Name enthalten ist? Oder ist das ein Zertifikat wo alle Namen aller Server enthalten ist.
Kannst du mal folgendes auf jedem Server ausführen ausführen (nur oben den Namen anpassen) und den Output posten (gern auch per PN).
$servername = "Server1"
Get-OwaVirtualDirectory -Server $servername | fl internalurl, externalurl
Get-EcpVirtualDirectory -server $servername | fl internalurl, externalurl
Get-WebServicesVirtualDirectory -server $servername| fl internalurl, externalurl
Get-ActiveSyncVirtualDirectory -Server $servername | fl internalurl, externalurl
Get-OabVirtualDirectory -Server $servername | fl internalurl, externalurl
Get-MapiVirtualDirectory -Server $servername | fl externalurl, internalurl
Get-ClientAccessService $servername | fl AutoDiscoverServiceInternalUri
Get-Mailboxdatabase | fl Server,AdminDisplayName, rpc*
Mit freundlichen Grüßen
Micha
Danke dir....
ExternalUrl : https://mail.domain.de/owa
ExternalUrl : https://mail.domain.de/ecp
Die anderen Adressen sind alle analog dazu ähnlich.
Der interne Pfad löst die IP Nummer des HA Proxys im lokalen Netz auf.
Der externe Pfad löst die externe IP der DSL Leitung auf.
Der HA Proxy kennt dann nur zwei Adressen, die als Ziel eingetragen sind:
server1.domain.intern
server2.domain.intern
Der Client stellt auch den Kontakt bis zum Server her, die OWA Anmeldeseite des Servers ist zu sehen. Von extern genau so wie von intern.
Server1 hat folgende Adressen im Zertifikat:
server1.domain.intern
mail.domain.intern
mail.domain.de
Server2 hat folgende Adressen im Zertifikat:
server2.domain.intern
mail.domain.intern
mail.domain.de
Get-OwaVirtualDirectory -Server $servername | fl internalurl, externalurl
InternalUrl : https://mail.domain.intern/owaExternalUrl : https://mail.domain.de/owa
Get-EcpVirtualDirectory -server $servername | fl internalurl, externalurl
InternalUrl : https://mail.domain.intern/ecpExternalUrl : https://mail.domain.de/ecp
Die anderen Adressen sind alle analog dazu ähnlich.
Der interne Pfad löst die IP Nummer des HA Proxys im lokalen Netz auf.
Der externe Pfad löst die externe IP der DSL Leitung auf.
Der HA Proxy kennt dann nur zwei Adressen, die als Ziel eingetragen sind:
server1.domain.intern
server2.domain.intern
Der Client stellt auch den Kontakt bis zum Server her, die OWA Anmeldeseite des Servers ist zu sehen. Von extern genau so wie von intern.
Server1 hat folgende Adressen im Zertifikat:
server1.domain.intern
mail.domain.intern
mail.domain.de
Server2 hat folgende Adressen im Zertifikat:
server2.domain.intern
mail.domain.intern
mail.domain.de
Moin NordicMike,
ich kann dich mehr oder weniger beruhigen... du bist nicht alleine.
Wir haben die von dir beschriebene Problematik auf allen DAGs, welche der Kombination Exchange 2016 und Outlook 2016 zu treffen. Allerdings bereits schon mit CU19 und dem letzten Sicherheitsupdate.
Nehmen wir anstatt Outlook 2016 ein Outlook 2010 auf einer Test VM funktioniert alles wie es soll. Outlook 2019 konnten wir bis dato noch nicht testen. Ist das bei dir auch so?
Unabhängig davon sehen wir bei einem Failover eines Knoten der DAG in Verbindungstatus deutlich mehr Einträge für ein Postfach wie im funktionieren Zustand. Als würde Outlook immer und immer wieder neue Verbindungen aufbauen wollen. Ist das bei dir auch so?
Gruß,
Dani
ich kann dich mehr oder weniger beruhigen... du bist nicht alleine.
Wir haben die von dir beschriebene Problematik auf allen DAGs, welche der Kombination Exchange 2016 und Outlook 2016 zu treffen. Allerdings bereits schon mit CU19 und dem letzten Sicherheitsupdate.
Nehmen wir anstatt Outlook 2016 ein Outlook 2010 auf einer Test VM funktioniert alles wie es soll. Outlook 2019 konnten wir bis dato noch nicht testen. Ist das bei dir auch so?
Unabhängig davon sehen wir bei einem Failover eines Knoten der DAG in Verbindungstatus deutlich mehr Einträge für ein Postfach wie im funktionieren Zustand. Als würde Outlook immer und immer wieder neue Verbindungen aufbauen wollen. Ist das bei dir auch so?
Aber ja, der Witness ist ständig online gewesen und im gleichen Netz, wie die zwei Exchange Server. Das Zabbix Monitoring hat auch nicht gemeldet, dass der Wittnes Server offline wäre, also gehe ich davon aus, dass er alles mitbekommen hat.
Wenn der Witness Server bzw. die Freigabe offline gewesen wäre, findet in der Regel die DAG nicht mehr von alleine zusammen. Dem entsprechend ist auch das Ereignisprotokoll voll mit Fehlern.Ich habe einen HA Proxy davor, der Transparent zum Server2 durchlässt, ich habe Server1 am HAproxy deaktiviert.
Sprich Layer 4, NAT oder SNAT?Gruß,
Dani
Hallo Dani,
es ist auch bei Outlook 2019 bei uns so, auch beim iPhone. Die Clients kommen ja auch alle bis zum noch laufenden Server auf die Anmeldeseite z.B. auf /owa oder /ecp. Der Knackpunkt ist wirklich, dass der noch laufende Serer ohne dem anderen Server zwar online war, jedoch einfach seine Inhalte nicht preis geben wollte, als ob er seine Datenbankkopie nicht aktiv stellen wollte.
Das mit den mehreren Verbindungen klingt plausibel, Outlook intern weiss ja durch SCPs welche Server vorhanden sein müssten, wenn die Verbindung zu einem scheitert oder hängt, versucht er es beim nächsten Server. Das wäre zumindest intern. Mein Problem ist intern wie auch extern.
es ist auch bei Outlook 2019 bei uns so, auch beim iPhone. Die Clients kommen ja auch alle bis zum noch laufenden Server auf die Anmeldeseite z.B. auf /owa oder /ecp. Der Knackpunkt ist wirklich, dass der noch laufende Serer ohne dem anderen Server zwar online war, jedoch einfach seine Inhalte nicht preis geben wollte, als ob er seine Datenbankkopie nicht aktiv stellen wollte.
Das mit den mehreren Verbindungen klingt plausibel, Outlook intern weiss ja durch SCPs welche Server vorhanden sein müssten, wenn die Verbindung zu einem scheitert oder hängt, versucht er es beim nächsten Server. Das wäre zumindest intern. Mein Problem ist intern wie auch extern.
Sprich Layer 4, NAT oder SNAT?
Ich kenne mich mit diesen OSI Layern nicht wirklich aus, dafür haben wir andere Jungs hier :c) Es macht auf jeden Fall kein NAT. Es ist einfach ein Man In The Middle, ein Proxy halt.
Nachdem das nächste Exchange Security Update bereits steht, habe ich mal eine ruhige Minute ausgenutzt um einen neuen Switchover zu versuchen.
Wenn ich Server1 update, läuft alles normal weiter.
Wenn ich Server2 update, hängt alles, obwohn der HA Proxy komplett auf Server1 gestellt ist.
Jetzt konnte ich mal ein paar Prüfungen machen:
Name Server Mounted
------ -------
Mailbox Database 1198545982 Server1 True
Mailbox Database Firma.de Server2
Die (eigentlich wichtige) Datenbank ist also auf dem Server1 nicht gemounted, wenn Server2 updatet. Klar, dass Server1 nur den Loginbildschirm bringt, aber nach dem Login hängt.
Im ECP ist jedoch zu sehen, dass die Datenbank auf beiden Servern vorhanden und synchron wäre.
Ich überlege gerade ob ich versuchen soll diese Datenbank zu mounten...
Wenn ich Server1 update, läuft alles normal weiter.
Wenn ich Server2 update, hängt alles, obwohn der HA Proxy komplett auf Server1 gestellt ist.
Jetzt konnte ich mal ein paar Prüfungen machen:
Name Server Mounted
------ -------
Mailbox Database 1198545982 Server1 True
Mailbox Database Firma.de Server2
Die (eigentlich wichtige) Datenbank ist also auf dem Server1 nicht gemounted, wenn Server2 updatet. Klar, dass Server1 nur den Loginbildschirm bringt, aber nach dem Login hängt.
Im ECP ist jedoch zu sehen, dass die Datenbank auf beiden Servern vorhanden und synchron wäre.
Ich überlege gerade ob ich versuchen soll diese Datenbank zu mounten...
Die Updates sind durch und beide Server sind wieder online.
Ich suche den Grund, warum die Datenbank auf Server1 im Offline Fall von Server2 nicht gemounted wurde.
ECP zeigt mir den Cluster mit beiden Membern an und beide sind online.
Powershell zeigt mit mit get-clusternode nur den Server1 an. Wenn ich versuche den Server2 mit "add-clusternode" hinzuzufügen, erhalte ich eine Fehlermeldung, dass dieser bereits zu einem Cluster gehört. Ich habe jedoch nur einen Cluster, in diesem zeigt mir die Powershell den Server2 nicht mit an.
Für mich ein nicht schlüssiges bzw fehlerhaftes System, wenn ECP und Powershell unterschiedliche Sachen anzeigen.
Ich suche den Grund, warum die Datenbank auf Server1 im Offline Fall von Server2 nicht gemounted wurde.
ECP zeigt mir den Cluster mit beiden Membern an und beide sind online.
Powershell zeigt mit mit get-clusternode nur den Server1 an. Wenn ich versuche den Server2 mit "add-clusternode" hinzuzufügen, erhalte ich eine Fehlermeldung, dass dieser bereits zu einem Cluster gehört. Ich habe jedoch nur einen Cluster, in diesem zeigt mir die Powershell den Server2 nicht mit an.
Für mich ein nicht schlüssiges bzw fehlerhaftes System, wenn ECP und Powershell unterschiedliche Sachen anzeigen.
Moin,
Hast du schon mal die Konfiguration geprüft bzw. prüfen lassen?
Überwachen von Datenbankverfügbarkeitsgruppen
Using Test-ReplicationHealth to Troubleshoot Database Availability Groups
Gruß,
Dani
Für mich ein nicht schlüssiges bzw fehlerhaftes System, wenn ECP und Powershell unterschiedliche Sachen anzeigen.
ich würde eher der Powerhell als em ECP glauben schenken.Hast du schon mal die Konfiguration geprüft bzw. prüfen lassen?
Überwachen von Datenbankverfügbarkeitsgruppen
Using Test-ReplicationHealth to Troubleshoot Database Availability Groups
Gruß,
Dani
Deine Links bringen mit schon weiter:
Get-MailboxDatabaseCopyStatus bringt:
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
------ --------- ----------- -------------------- ------------
Mailbox Database 1198545982\Server1 Healthy 0 0 14.05.2021 10:40:18 Healthy
Mailbox Database Firma.de\Server2 Mounted 0 0 Healthy
Soweit so gut. Jedoch:
Test-ReplicationHealth bringt:
Der Komponentenstatus (HighAvailability) der Serverkomponente "Server2" ist offline. Wenn Sie Datenbankkopien auf diesem Server aktivieren müssen, können Sie "Set-ServerComponentState -Component 'HighAvailability' -State 'Active'" verwenden und "Move-ActiveMailboxDatabase" erneut versuchen.
Set-ServerComponentState -Identity Server2 -Requester Maintenance -State Active
Führt er ohne Fehlermeldung aus, danach passiert jedoch nichts weiter und der Test-ReplicationHealth bringt immer noch den gleichen Fehler.
Move-ActiveMailboxDatabase
Bringt den Fehler, dass die Datenbank auf Server1 zu keiner Zeit eingebunden war.
Dann habe ich einen Bockmist gebaut. Ich habe die Datenbank auf Server1 gemountet. Das war ein Fehler. Jetzt ist sie auf beiden Servern gemountet, aber die Fehlermeldung kommt trotzdem. Zusätzlich melden die Clients nun, im Minutentakt abwechselnd, dass die Server erreichbar und nicht mehr erreichbar sind. Dabei habe ich unter Test-ReplicationHealth die Meldung, eines Split-Brain Syndromes, da die Datenbank auf beiden Servern aktiv ist.
Wie bekomme ich nun den Mount wieder weg? Mit dismount-database dismountet er es mir auf beiden Servern. Ein erneuter Mount mountet es mir wieder auf beiden Servern.
Get-MailboxDatabaseCopyStatus bringt:
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
------ --------- ----------- -------------------- ------------
Mailbox Database 1198545982\Server1 Healthy 0 0 14.05.2021 10:40:18 Healthy
Mailbox Database Firma.de\Server2 Mounted 0 0 Healthy
Soweit so gut. Jedoch:
Test-ReplicationHealth bringt:
Der Komponentenstatus (HighAvailability) der Serverkomponente "Server2" ist offline. Wenn Sie Datenbankkopien auf diesem Server aktivieren müssen, können Sie "Set-ServerComponentState -Component 'HighAvailability' -State 'Active'" verwenden und "Move-ActiveMailboxDatabase" erneut versuchen.
Set-ServerComponentState -Identity Server2 -Requester Maintenance -State Active
Führt er ohne Fehlermeldung aus, danach passiert jedoch nichts weiter und der Test-ReplicationHealth bringt immer noch den gleichen Fehler.
Move-ActiveMailboxDatabase
Bringt den Fehler, dass die Datenbank auf Server1 zu keiner Zeit eingebunden war.
Dann habe ich einen Bockmist gebaut. Ich habe die Datenbank auf Server1 gemountet. Das war ein Fehler. Jetzt ist sie auf beiden Servern gemountet, aber die Fehlermeldung kommt trotzdem. Zusätzlich melden die Clients nun, im Minutentakt abwechselnd, dass die Server erreichbar und nicht mehr erreichbar sind. Dabei habe ich unter Test-ReplicationHealth die Meldung, eines Split-Brain Syndromes, da die Datenbank auf beiden Servern aktiv ist.
Wie bekomme ich nun den Mount wieder weg? Mit dismount-database dismountet er es mir auf beiden Servern. Ein erneuter Mount mountet es mir wieder auf beiden Servern.
Moin,
Wenn das nicht klappt würde ich es über die Wartungstask versuchen:
https://www.der-windows-papst.de/2018/09/19/exchange-2016-wartungsmodus- ...
Gruß,
Dani
Dann habe ich einen Bockmist gebaut. Ich habe die Datenbank auf Server1 gemountet. Das war ein Fehler. Jetzt ist sie auf beiden Servern gemountet, aber die Fehlermeldung kommt trotzdem.
Mit welchen Befehl has du den Zustand erreicht?Wie bekomme ich nun den Mount wieder weg?
Ist der Witness Server online und das Share erreichbar? Denn sollte ein Neustart des Server1 ausreichend sein. Mit dismount-database dismountet er es mir auf beiden Servern. Ein erneuter Mount mountet es mir wieder auf beiden Servern.
Es geht meines Wissens nach nur in Kombination:Get-MailboxDatabase -Server SERVERNAME | Dismount-Database -Confirm:$FalseWenn das nicht klappt würde ich es über die Wartungstask versuchen:
https://www.der-windows-papst.de/2018/09/19/exchange-2016-wartungsmodus- ...
Gruß,
Dani
Danke dir. Ich habe in der Zwischenzeit die User auf eine neue Datenbank umgezogen und die alte Datenbank gelöscht.
Moin,
Gruß,
Dani
Danke dir. Ich habe in der Zwischenzeit die User auf eine neue Datenbank umgezogen und die alte Datenbank gelöscht.
Funktioniert die DAG nun? Ist das Authentifizierungsproblem damit auch gelöst?Gruß,
Dani
Ich bin noch nicht ganz fertig. Die neue Datenbank habe ich noch nicht repliziert. Ich muss einen ruhigen Fenstertag abwarten :c)
Die neue Datenbank habe ich noch nicht repliziert. Ich muss einen ruhigen Fenstertag abwarten :c)
Für die Replikation selbst brauchst du eigentlich nicht auf den Fenstertag warten. Das geschieht im Hintergrund ohne, dass der Nutzer etwas von bemerkt. Den geplanten Failover würde ich mir für den Fenstertag aufheben. Gruß,
Dani
Du hast ja Recht...
Ich habe sie jetzt mal geseeded.
Beide Server melden (server2 natürlich mit server2 in der ersten Spalte):
Auf server1 ausgeführt:
Aus server2 ausgeführt:
Also beide Server hätte ihre eigene Datenbank gemountet und die Datenbank anderen Servers kopiert und "heathy".
Kann ich noch was anderes prüfen, bevor ich umschalte?
Ich habe sie jetzt mal geseeded.
Beide Server melden (server2 natürlich mit server2 in der ersten Spalte):
[PS] C:\Windows\system32>Test-ReplicationHealth
Server Check Result Error
------ ----- ------ -----
server1 ClusterService Prüfung
bestanden
server1 ReplayService Prüfung
bestanden
server1 ActiveManager Prüfung
bestanden
server1 TasksRpcListener Prüfung
bestanden
server1 TcpListener Prüfung
bestanden
server1 ServerLocatorService Prüfung
bestanden
server1 DagMembersUp Prüfung
bestanden
server1 MonitoringService Prüfung
bestanden
server1 ClusterNetwork Prüfung
bestanden
server1 QuorumGroup Prüfung
bestanden
server1 DatabaseRedundancy Prüfung
bestanden
server1 DatabaseAvailability Prüfung
bestanden
server1 DBCopySuspended Prüfung
bestanden
server1 DBCopyFailed Prüfung
bestanden
server1 DBInitializing Prüfung
bestanden
server1 DBDisconnected Prüfung
bestanden
server1 DBLogCopyKeepingUp Prüfung
bestanden
server1 DBLogReplayKeepingUp Prüfung
bestandenAuf server1 ausgeführt:
[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
---- ------ --------- ----------- -------------------- ------------
leere datenbank\server1 Mounted 0 0 Healthy
Mailbox Database Firma.de.neu\server1 Healthy 0 0 17.05.2021 16:55:38 HealthyAus server2 ausgeführt:
[PS] C:\Windows\system32>Get-MailboxDatabaseCopyStatus
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
---- ------ --------- ----------- -------------------- ------------
Mailbox Database Firma.de.neu\server2 Mounted 0 0 Healthy
leere datenbank\server2 Healthy 0 0 17.05.2021 16:56:49 HealthyAlso beide Server hätte ihre eigene Datenbank gemountet und die Datenbank anderen Servers kopiert und "heathy".
Kann ich noch was anderes prüfen, bevor ich umschalte?
Moin,
Gruß,
Dani
Also beide Server hätte ihre eigene Datenbank gemountet und die Datenbank anderen Servers kopiert und "heathy".
Ist das Absicht /Lastverteilung oder nur temporär, da du die Database neu angelegt hast? Kann ich noch was anderes prüfen, bevor ich umschalte?
Ne, Prüfen kannst dies bezüglich nur die Konfiguration der DAG. Ich gehe davon aus, dass z.B. URLs für OWA, ECP, etc. korrekt ist. Sowie auch Sendeconntectoren für die Clients.Gruß,
Dani
Ein Exchange Server erzeugt immer eine leere Datenbank mit bei der Installation. Diese habe ich nie gelöscht. Ich habe sie einfach zur Übung mal vorab mit repliziert.
Sollte ich jetzt einfach mal:
testen?
Sollte ich jetzt einfach mal:
Move-ActiveMailboxDatabase -Server server2testen?
Moin,
wenn du dir sicher bist, dass alle Einstellungen passen und du keinen Brückentag abwarten möchtest, Ja.
Ich würde es auf nachmittags/abends planen. Damit wenn etwas schief geht, nicht all zu viele Leute betroffen sind.
Gruß,
Dani
wenn du dir sicher bist, dass alle Einstellungen passen und du keinen Brückentag abwarten möchtest, Ja.
Ich würde es auf nachmittags/abends planen. Damit wenn etwas schief geht, nicht all zu viele Leute betroffen sind.
Gruß,
Dani
Das bin ich mir eben nicht. Den Zustand hatte ich auch, bevor ich dann den Bockmist gebaut habe :c)
Ich trau dem Braten nicht mehr.
Ich trau dem Braten nicht mehr.
Gut, dass ich es nicht gemacht habe.
Mir kam eine weniger gefährliche Testmethode in den Kopf geschossen: Nachdem die produktive und aktive Datenbank auf server2 läuft, habe ich server1 herunter gefahren. Alle Postfächer sind noch erreichbar. Klar, die Clients greifen über den HA Proxy auf Server2 zu und die Datenbank liegt auf Server2.
Dann habe ich Server1 wieder hoch gefahren. Dieser hat ja noch eine leere Datenbank, die ich einfach mal so mit repliziert habe. Dann habe ich einen Testuser auf diese Datenbank umgezogen und Server1 wieder herunter gefahren. Zack, da ist das Problem wieder. Die User der produktiven Danbank können normal weiter arbeiten aber der User der Testdatenbank kann nichts mehr empfangen. Auch das OWA ist, wie anfangs beschrieben, die Anmeldeseite kommt noch, nach der Anmeldung des Testusers kommt eine Fehlermeldung, dass etwas nicht geklappt hat.
Auf Server2 ausgeführt:
Warum bleibt sie disconnected und connected nicht selbstständig?
Mir kam eine weniger gefährliche Testmethode in den Kopf geschossen: Nachdem die produktive und aktive Datenbank auf server2 läuft, habe ich server1 herunter gefahren. Alle Postfächer sind noch erreichbar. Klar, die Clients greifen über den HA Proxy auf Server2 zu und die Datenbank liegt auf Server2.
Dann habe ich Server1 wieder hoch gefahren. Dieser hat ja noch eine leere Datenbank, die ich einfach mal so mit repliziert habe. Dann habe ich einen Testuser auf diese Datenbank umgezogen und Server1 wieder herunter gefahren. Zack, da ist das Problem wieder. Die User der produktiven Danbank können normal weiter arbeiten aber der User der Testdatenbank kann nichts mehr empfangen. Auch das OWA ist, wie anfangs beschrieben, die Anmeldeseite kommt noch, nach der Anmeldung des Testusers kommt eine Fehlermeldung, dass etwas nicht geklappt hat.
Auf Server2 ausgeführt:
Get-MailboxDatabaseCopyStatus
Name Status CopyQueue ReplayQueue LastInspectedLogTime ContentIndex
Length Length State
---- ------ --------- ----------- -------------------- ------------
Mailbox Database Firma.de.neu\server2 Mounted 0 0 Healthy
leere datenbank\server2\Server2 DisconnectedAnd 0 0 19.05.2021 13:00:54 Healthy
HealthyWarum bleibt sie disconnected und connected nicht selbstständig?
Mal den Witness überprüft:
none in use? Stimmt das so?
Get-DatabaseAvailabilityGroup -Identity firmaDAG1 -Status | fl *wit*
WitnessServer : server3
WitnessDirectory : c:\witness
AlternateWitnessServer :
AlternateWitnessDirectory :
WitnessShareInUse : None
DxStoreWitnessServers :none in use? Stimmt das so?
Moin,
Vergleich deine Konfiguration mit den Blog Artikeln - sicher ist sicher:
https://www.frankysweb.de/exchange-2016-konfiguration-einer-dag-database ...
https://www.frankysweb.de/exchange-2019-database-availability-group-dag/
Lass parallel dazu noch den Befehl Test-ReplicationHealth | Format-List Check* laufen?
Gruß,
Dani
Das bin ich mir eben nicht. Den Zustand hatte ich auch, bevor ich dann den Bockmist gebaut habe :c)
Ich trau dem Braten nicht mehr.
Wer hat den die DAG eingerichtet, der Azubi im ersten Lehrjahr? Ich trau dem Braten nicht mehr.
Vergleich deine Konfiguration mit den Blog Artikeln - sicher ist sicher:
https://www.frankysweb.de/exchange-2016-konfiguration-einer-dag-database ...
https://www.frankysweb.de/exchange-2019-database-availability-group-dag/
Warum bleibt sie disconnected und connected nicht selbstständig?
Was sagt den das Ereignisprotokoll dazu?Lass parallel dazu noch den Befehl Test-ReplicationHealth | Format-List Check* laufen?
Mal den Witness überprüft:
Sieht gut aus. Wir nutzen bei WitnessServer den FQDN. Aber das sollte hier keine Rolle spielen. Die Berechtigungen für das Verzeichnis passen. Ansonsten würde der Befehl Test-ReplicationHealth | Format-List Check* entsprechend einen Fehler ausgegeben. Warum bleibt sie disconnected und connected nicht selbstständig?
Die Fehlermeldung ist leider abgeschnitten. Kannst du Sagen was in der Spalte "Status" hinter "DisconnectedAnd " steht?Gruß,
Dani
Wer hat den die DAG eingerichtet, der Azubi im ersten Lehrjahr?
Mea culpa. Der Lehrling bin ich, ich habe schon einige Exchange Server in Betrieb genommen, ich betreibe auch einen "privat", wenn auch nicht nötig. Aber ein Failover Problem hatte ich noch "nie", nicht einmal einen Fail. Ein einziges Mal musste ich mal eine Datenbank reparieren, selbst diese sind echt einfach und Schmerzlos. Die Biester laufen einfach, wenn die Hardware stimmt. Mein Chef kennt sich "nur" mit Linux aus und bekommt allergische Reaktionen und so komische Zuckungen und Sprachfehler, wenn das Wort mit einem Mi.. oder Wi.. beginnt.Die Fehlermeldung ist leider abgeschnitten. Kannst du Sagen was in der Spalte "Status" hinter "DisconnectedAnd " steht?
Die Formatierung hat es nach unten versetztDisconnectedAnd
Healthy
Wir nutzen bei WitnessServer den FQDN
Es ist auch ein FQDN bei mir. Ich habe nur die echten Servernamen aus dem Beitrag raus genommen.Ich verwende ebenfalls Frankys Anleitung für eine Einrichtung. Nur habe ich kein eigenes Replikationsnetzwerk eingerichtet.
In der Ereignisanzeige sind einen Haufen Fehler dazu gekommen, klar, der Server1 ist ja auch nicht mehr online gewesen. Aber diese zu interpretieren ob sie bei einem Ausfall normal sind oder der Grund für den fehlenden Failover sind, erfordert ein mehrjähriges Studium :c)
Beim nächsten Failover Test werde ich mal Test-ReplicationHealth ausführen, im Moment steht ja alles auf "Prüfung bestanden".
Danke für Deine unendliche Anteilnahme...
Moin,
Gruß,
Dani
In der Ereignisanzeige sind einen Haufen Fehler dazu gekommen, klar, der Server1 ist ja auch nicht mehr online gewesen. Aber diese zu interpretieren ob sie bei einem Ausfall normal sind oder der Grund für den fehlenden Failover sind, erfordert ein mehrjähriges Studium :c)
ich vermute, dass dort die Ursache zu finden sein wird. Daher empfehle ich dir ein Crash-Studium. Ansonsten darfst du gerne über Pastbin, die aus deiner Sicht relevanten Einträge, anonymsiert mir zu kommen lassen. Meine aktive SE Zeit ist allerdings schon fast zwei Jahre her, aber vllt. sehe ich was. Es ist auch ein FQDN bei mir. Ich habe nur die echten Servernamen aus dem Beitrag raus genommen.
Ok, passt.Die Formatierung hat es nach unten versetzt
DisconnectedAnd
Healthy
Ich würde erst einmal die leere Datenbank auflösen und jeweils löschen. Damit du alles aus dem Füßen hast, was evtl. stören könnte.DisconnectedAnd
Healthy
Beim nächsten Failover Test werde ich mal Test-ReplicationHealth ausführen, im Moment steht ja alles auf "Prüfung bestanden".
Nutzt du evtl Veeam? Dann könntest du über Instant Recovery und dedizierten vSwitches auf den Hosts eine Testumgebung aufbauen. Somit kannst du in Ruhe spielen ohne jedes Mal die Produktiv abhängig zu sein.Gruß,
Dani
Dann könntest du über Instant Recovery und dedizierten vSwitches auf den Hosts eine Testumgebung aufbauen.
Das ist eine gute Idee. Veeam wäre vorhanden, also müsste ich einen der zwei Domain Controller und beide Exchange Server und eine Client VM dahin ziehen. Vermutlich ist dann erst einmal das Domänenvertrauen und die Clustersynchronization im Eimer, da die VMs leicht zeitversetzt gesichert werden. Oder sollte ich die drei Server herunterfahren und dann klonen, damit sie synchron bleiben?
Moin,
Die größere Herausforderung sind vermutlich die Load Balancer?!
Gruß,
Dani
Veeam wäre vorhanden, also müsste ich einen der zwei Domain Controller und beide Exchange Server und eine Client VM dahin ziehen. Vermutlich ist dann erst einmal das Domänenvertrauen und die Clustersynchronization im Eimer, da die VMs leicht zeitversetzt gesichert werden. Oder sollte ich die drei Server herunterfahren und dann klonen, damit sie synchron bleiben?
Am Besten alle notwendigen Server aus Veeam über Instant Recovery starten. Wichtig ist, dass die Server sich zu keinem Zeitpunkt im produktiven Netzerk sehen dürfen (nicht mal eine Sekunde). Anderenfalls hast du den nächsten Totalschaden! Da musst du wirklich vorsichtig sind. Den Client installierst du kurzer Hand als Test Maschine mit Outlook hinzu.Die größere Herausforderung sind vermutlich die Load Balancer?!
Gruß,
Dani
