none
Exchange Security Update, Downzeit, Service down, Unterschied zu shutdown RRS feed

  • Frage

  • Hallo zusammen,

    wo liegt hier der Unterschied. Beim letzten Exchange Security Update wurden vom Update die EX Dienst gestoppt, jedoch wurden bei uns (2 Server DAG, DNS RoundRobin) glaube ich die DBs nicht geswitched und div. Benutzer konnten während dem Update länger nicht mit Outlook zugreifen.

    Wenn ich jedoch normal einen Server herunterfahren können sich die User mit Outlook neu starten sehr wohl anmelden und arbeiten, da die DBs gemoved werden.

    was ist bei einem Exchange Security Patch anders.

    PS: In der Regel Patchen wir immer außerhalb der Dienstzeiten. Updates werden aber durchaus auch früher heruntergeladen aber nicht installiert. Da kamen einige Ausnahmen zusammen. Bisher gab es auch kaum Exchange Security Updates außer den CUs


    Chris

    Donnerstag, 28. Dezember 2017 13:55

Antworten

  • Moin,

    das ist eines der Problem bei Roundrobin-DNS: Der Server ist ja selbst noch erreichbar, z.b. per Ping, über WinRM, WMI oder Remoteregistry.

    Dazu kommt noch, dass ja einzelne Dienste früher beendet werden und auch zeitlich früher wieder online sind. Wenn der Client-Dienst läuft, aber an keine Datenbanken kommt, dann kann sich Outlook verbinden, bekommt aber kein Postfach.

    Roundrobin-DNS hängt immer am Client, dass der mitspielt. Darum würde ich das nur im absoluten Notfall nehmen.

    Das gleiche Problem gab es früher auch bei Windows NLB: Das wirkt erst, wenn der ganze Server aus ist, der Ausfall einzelner Dienste wird nicht bemerkt.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert -- Chris -- Donnerstag, 28. Dezember 2017 15:05
    Donnerstag, 28. Dezember 2017 15:03
  • Moin,

    auch wenn Robert im Grundsatz Recht hat (obgleich ich seine extreme Haltung gegenüber Round Robin DNS nicht teilen kann - man muss die Eigenarten halt kennen und entsprechend managen), hat das in diesem Thread beobachtete Phänomen vermutlich weniger mit dem Client Access als mit der Cluster-Logik hinter der DAG zu tun. Das saubere administrative Beenden des Information Store lõst auch in meiner Beobachtung in der Regel keinen Switch der aktiven Kopie aus - dies wäre also auch mit einem HLB nicht geheilt, da es während des Update gar keine aktive Kopie gab, auf die der CAS hätte zugreifen können!

    Kleiner Tipp: Mit Exchange 2016 wird wieder das offizielle DAG Maintenance-Skript ausgeliefert. Wenn man kein eigenes hat, kann man es durchaus verwenden.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    Freitag, 29. Dezember 2017 08:33

Alle Antworten

  • Moin,

    das ist eines der Problem bei Roundrobin-DNS: Der Server ist ja selbst noch erreichbar, z.b. per Ping, über WinRM, WMI oder Remoteregistry.

    Dazu kommt noch, dass ja einzelne Dienste früher beendet werden und auch zeitlich früher wieder online sind. Wenn der Client-Dienst läuft, aber an keine Datenbanken kommt, dann kann sich Outlook verbinden, bekommt aber kein Postfach.

    Roundrobin-DNS hängt immer am Client, dass der mitspielt. Darum würde ich das nur im absoluten Notfall nehmen.

    Das gleiche Problem gab es früher auch bei Windows NLB: Das wirkt erst, wenn der ganze Server aus ist, der Ausfall einzelner Dienste wird nicht bemerkt.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort markiert -- Chris -- Donnerstag, 28. Dezember 2017 15:05
    Donnerstag, 28. Dezember 2017 15:03
  • ja, klingt verständlich

    danke


    Chris

    Donnerstag, 28. Dezember 2017 15:05
  • Moin,

    auch wenn Robert im Grundsatz Recht hat (obgleich ich seine extreme Haltung gegenüber Round Robin DNS nicht teilen kann - man muss die Eigenarten halt kennen und entsprechend managen), hat das in diesem Thread beobachtete Phänomen vermutlich weniger mit dem Client Access als mit der Cluster-Logik hinter der DAG zu tun. Das saubere administrative Beenden des Information Store lõst auch in meiner Beobachtung in der Regel keinen Switch der aktiven Kopie aus - dies wäre also auch mit einem HLB nicht geheilt, da es während des Update gar keine aktive Kopie gab, auf die der CAS hätte zugreifen können!

    Kleiner Tipp: Mit Exchange 2016 wird wieder das offizielle DAG Maintenance-Skript ausgeliefert. Wenn man kein eigenes hat, kann man es durchaus verwenden.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> http://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    Freitag, 29. Dezember 2017 08:33
  • Moin Evgenij,

    meine Ablehnung gegen Roundrobin rührt einfach daher, dass ich das Failover Verhalten als Admin zentral in der Hand haben will. Jeder Mitarbeiter, der anruft, weil sein Outlook, Smartphone, Thunderbird etc. nicht mehr funktioniert, ist ein Mitarbeiter zu viel. Auch, wenn es am Ende nur ein Programm-Neustart ist, sollte das möglichst nicht passieren.

    Wir nutzen einen Kemp LB (den gibt es auch in kostenlos als VM!) und seit dem wir den einsetzen bekommt wirklich niemand mehr mit, wenn im Hintergrund ein Exchange geplant oder ungeplant aussteigt.

    Das mit dem sauberen Beenden des Information Store konnte ich unsauber gestern anders beobachten. Durch eine Umkonfiguration des Replikationsnetzwerks im Hyper-V konnten meine beiden Test-Server keine Replikationsverbindung mehr herstellen ("ServiceDown" Meldung beim Replication Check). Die Datenbanken waren schneller drüben, als ich einen der Knoten per Remote Desktop öffnen konnte.

    Zu den DAG Maintenance-Skripten: Die sind in 2016 nicht mehr notwendig, bzw. nicht mehr in der Form von vor 2016. 2016 schwenkt die Datenbanken von ganz alleine.

    Nach einem:

    Set-MailboxServer $Servername -DatabaseCopyActivationDisabledAndMoveNow $True

    wird gewartet, bis die Datenbank vom Server runter sind.

    Ich benutze ein eigenes Script, dass auf dem von Frank basiert:

    https://www.msxfaq.de/exchange/e2013/e2016_update_checkliste.htm

    Grundsätzlich kann ich aber Deine Empfehlung nach einem Wartungs-Script nur bestätigen. Das passende Script in Verbindung mit dem HLB führt dazu, dass ich alle Wartungsarbeiten (Windows Update und CU) bequem tagsüber durchführen kann.

    Das ist auch bei uns offiziell so geregelt. Sobald ein System hochverfügbar ausgelegt ist, sind alle Wartungsarbeiten, die keine Auswirkungen auf den Betrieb erwarten lassen, in der normalen Arbeitszeit erlaubt bzw. erwünscht.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Freitag, 29. Dezember 2017 09:13