Benutzer mit den meisten Antworten
Wartung von Exchange DAG und CAS-Array

Frage
-
Hallo Community,
bei uns steht ein Update der Exchangeserver an.
Wir betreiben 4 Server im DAG / CAS-Array mit NLB
Server 1 CAS / HUB
Server 2 CAS / HUB
Server 3 DAG Cluster
Server 4 DAG Cluster
In der Vergangeheit ist es immer wieder vorgekommen, dass Clients, die während des Updates verbunden waren, danach Probleme mit dem Zugriff auf das CAS-Array hatten.
Dies ging sogar soweit, dass Outlook Pofile neu eingerichtet werden mussten.
Clients = Outlook 2007
Durch 24/7 Betrieb haben wir leider kein dediziertes Wartungsfenster.
Kann man aktive Clients vor dem Update vom sauber CAS trennen z.B. durch beenden des RPC Client Access Service?
Wie würdet Ihr bei dem Update vorgehen?
Danke schon einmal für Eure Anregungen.
Antworten
-
Du kannst im NLB doch einen Knoten in "Wartung" setzen. Dann verbindet sich kein Client mehr mit dem CAS Server. Geht imho über das CMDlet Suspend-NLBClusterNode oder halt Stop-NLBClusterNode
Gruß
Jörg
- Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
- Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
-
Hallo T.Pustal,
wie Joerg geschrieben hat - fuer die CAS im NLB, die Knoten anhalten. Fuer die DAG Knoten solltest Du wie unter http://technet.microsoft.com/en-us/library/dd298065.aspx beschrieben, die StartDagServerMaintenance.ps1 und StopDagServerMaintenance.ps1 Skripte verwenden:
Installing Microsoft Exchange Server 2010 update rollups on a server that is a member of a database availability group (DAG) is a relatively straightforward process. When you install an update rollup on a server that's a member of a DAG, several services are stopped during the installation, including all Exchange services and the Cluster service. The general process for applying update rollups to a DAG member is as follows:
- Use the StartDagServerMaintenance.ps1 script to put the DAG member in maintenance mode.
- Install the update rollup.
- Use the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance mode and put it back into production.
- Use the RedistributeActiveDatabases.ps1 script to rebalance the active database copies across the DAG.
Viele Gruesse
Timo
- Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
- Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
Alle Antworten
-
Du kannst im NLB doch einen Knoten in "Wartung" setzen. Dann verbindet sich kein Client mehr mit dem CAS Server. Geht imho über das CMDlet Suspend-NLBClusterNode oder halt Stop-NLBClusterNode
Gruß
Jörg
- Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
- Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
-
Hallo T.Pustal,
wie Joerg geschrieben hat - fuer die CAS im NLB, die Knoten anhalten. Fuer die DAG Knoten solltest Du wie unter http://technet.microsoft.com/en-us/library/dd298065.aspx beschrieben, die StartDagServerMaintenance.ps1 und StopDagServerMaintenance.ps1 Skripte verwenden:
Installing Microsoft Exchange Server 2010 update rollups on a server that is a member of a database availability group (DAG) is a relatively straightforward process. When you install an update rollup on a server that's a member of a DAG, several services are stopped during the installation, including all Exchange services and the Cluster service. The general process for applying update rollups to a DAG member is as follows:
- Use the StartDagServerMaintenance.ps1 script to put the DAG member in maintenance mode.
- Install the update rollup.
- Use the StopDagServerMaintenance.ps1 script to take the DAG member out of maintenance mode and put it back into production.
- Use the RedistributeActiveDatabases.ps1 script to rebalance the active database copies across the DAG.
Viele Gruesse
Timo
- Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
- Als Antwort markiert T. Pustal Donnerstag, 20. September 2012 12:15
-
Hi,
ich kopier mal Roberts Anwort zu einem anderen Thread kurz rein:
Die Frage ist falsch: Was ist bei WNLB schlecht:
- Source-IP Affinität (also kein wirkliches LB)
- schlechtes Zusammenspiel mit Routern (eventueli Multi-Cast-Stürme)
- keine Erkennung von Diensten (z.B. musst Du bei RU-Installation manuell auf dem LB schwenken, weil der das Deaktivieren der Dienst nicht mitbekommt)
Viele Grüße
Christian- Als Antwort vorgeschlagen Alex Pitulice Mittwoch, 19. September 2012 10:49
-
Hallo T.Pustal,
Ist die Thematik abgeklärt?
Viele Grüße,
AlexAlex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.