StartDagServerMaintenance tut nicht

1. offizieller Beitrag

    Moin,


    ich wollte gestern das RU10 installieren und den MBX in den Wartungsmodus setzen.
    Wenn ich das Script als Admin starte kommt folgende Meldung



    Supply values for the following parameters:


    serverName: SERVER


    The following objects are hosted by 'SERVER', before attempting to move them off: `n(Database='MailboxDatabase003', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase004', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase001', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase006', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase007', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase008', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase005', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase002', Reason='Copy is critical for redundancy according to Red Alert script') (Database='MailboxDatabase009', Reason='Copy is critical for redundancy according to Red Alert script'))


    Ähnlich wie hier, nur ohne Fehler -> https://support.microsoft.com/en-us/kb/2585649
    Meine Erwartung an der Stelle ist, dass zumindest die Exchange-Dienste down sind und die DBs verschoben werden.
    Es passiert gar nichts mehr danach.


    Wie kriege ich die Maschine wieder in den Wartungsmodus?
    Danke für Tipps!


    Wir betreiben eine DAG, 2 CAS, 2 MBX, Exchange 2010 SP3


    Gruss,
    Matthias

    Ok, war wohl auch mein Fehler... Ich habe den Befehl 2x ausgeführt und 2x StopDag... Wenn alle DBs bereits verschoben sind, ist das wohl offensichtlich kein Fehler sondern nur eine Info --> http://eightwone.com/2011/04/1…nge-2010-sp1-dag-members/ (unten in den Kommentaren).


    Bei StopDag... bekomme ich diese Meldung --> http://www.11hints.com/2014/04…ermaintenance-ps1-fehler/
    WARNING: [02:57:24.640 UTC] Call-ClusterExe: cluster.exe did not succeed, but 5058 was not a retry-able error code. Not attempting any other servers. This may be an expected error by the caller.



    Ok, wenn der Node nicht in Pause ist, kann ich das auch akzeptieren. Allerdings kann ich StartDag und StopDag 10x ausführen, ich bekomme neuerdings IMMER diese Meldung, nicht wie im Artikel beschrieben "einfach nochmal ausführen und dann ist die Meldung weg".
    Ist ja nicht mein erstes Update, bislang habe ich diese Meldungen nie bekommen. Machte mich nur etwas nervös :)



    Aber rein mal zum Verständnis: was macht StartDag... eigentlich genau? Ist das wirklich zwingend notwendig, wenn man die Maschine neu starten muss? Ist meine Annahme richtig, dass die Exchange-Dienste beendet werden und nach einem Neustart der Maschine auch nicht wieder starten?


    Wenn die DBs verschoben sind und alle DBs auf der Maschine passiv sind die ich neu starten will, genügt das nicht auch? MUSS ich den Wartungsmodus ausführen?
    Wenn mein Node nach "StartDag..." nicht in Pause ist, ist das ein Fehler? Offensichtlich hat "StopDag..." das ja erwartet.




    Sorry für so viele Fragen, aber ich hab bis 06.00h vorhin dieses RU10 installiert und meinen "Fehler" gesucht.
    Wenn ich gar keinen wirklichen Fehler habe, würde ich mir die Fehlersuche beim nächsten Update gerne schenken und einfach zu Bett gehen... :)
    Im Grunde war niemals eine DB nicht healthy oder nicht in einem Zustand, den ich nicht erwartet hätte. Bis auf diese Meldungen in der Powershell lief eigentlich alles trotz meiner Unwissenheit glatt.




    Würde mich freuen, wenn jemand eine Antwort auf irgendeine meiner Fragen hat!


    Gruss,
    Matthias

    • Offizieller Beitrag
    Zitat von kiezkicker

    Bei StopDag... bekomme ich diese Meldung --> 11hints.com/2014/04/14/exchang…ermaintenance-ps1-fehler/
    WARNING: [02:57:24.640 UTC] Call-ClusterExe: cluster.exe did not succeed, but 5058 was not a retry-able error code. Not attempting any other servers. This may be an expected error by the caller.

    Diese Meldung bedeutet, dass Du entweder kein lokaler Admin bist (das ist für cluster.exe erforderlich) oder sich der Cluster-Knoten gar nicht im Wartungsmodus befindet. Das Script schaut das nicht nach, sondern schaltet einfach stur ab.


    Zitat von kiezkicker

    Aber rein mal zum Verständnis: was macht StartDag... eigentlich genau? Ist das wirklich zwingend notwendig, wenn man die Maschine neu starten muss? Ist meine Annahme richtig, dass die Exchange-Dienste beendet werden und nach einem Neustart der Maschine auch nicht wieder starten?

    Wieso sollte man die Maschine neustarten müssen? Und Exchange-Dienste werden dadurch natürlich auch nicht beendet.


    Das Start-Script macht zwei Dinge:
    1. Es schiebt alle aktiven Kopien von diesem Knoten weg (nach der jeweiligen Aktivierungsreihenfolge auf andere Knoten)
    2. Es versetzt den Cluster in einen Wartungsmodus, damit wir er für Fail-Over-Vorgänge nicht mehr verwendet (das verhindert, das Kopien bei einem Fehler zurückwandern). Das passiert sowohl im Windows-Cluster, als auch auf den Datenbank-Kopien.


    Das Stop-Script macht genau eine Sache:
    1. Es schaltete den Wartungsmodus aus, sowohl auf dem Windows-Cluster als auch auf den Datenbank-Kopien.


    Mehr tut das Stop-Script nicht. Das Rückverteilen der Datenbank machst Du entweder selbst oder mit dem Redistribute-Script.


    BTW: Das Script ist übrigens Klartext, kannst Du Dir selbst anschauen.



    Zitat von kiezkicker

    Wenn die DBs verschoben sind und alle DBs auf der Maschine passiv sind die ich neu starten will, genügt das nicht auch? MUSS ich den Wartungsmodus ausführen?

    Wenn Du nur zwei Knoten hast, kannst Du die Datenbank auch manuell verschieben. Der Wartungsmodus ist erst ab 3 Knoten richtig sinnvoll.


    Das Script schadet aber nichts, wenn Du nur zwei hast. Und man gewöhnt sich halt unabhängig von der Anzahl der Knoten immer die gleiche Bedienung an.


    Zitat von kiezkicker

    Im Grunde war niemals eine DB nicht healthy oder nicht in einem Zustand, den ich nicht erwartet hätte. Bis auf diese Meldungen in der Powershell lief eigentlich alles trotz meiner Unwissenheit glatt.


    Früher hatte das Script einen Fehler und zeigte eine Fehlermeldung an, wenn die DB nur zwei Kopien hat, weil es an einer Stelle prüft, ob nach dem Verschieben eine aktive und ZWEI passive online sind. Keine Ahnung, ob das jemals korrigiert wurde.


    Ich habe bei mir noch eine weiteres Script auf dem Desktop verknüpft, das im wesentlich aus dieser Zeile besteht:


    Code
    Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus | Sort-Object Mailboxserver,Databasename | ft -GroupBy Mailboxserver

    Das rufe ich manuell auf, bzw. wird bei meinen Start/Stop-Scripten im Anschluss aufgerufen. Damit sehe ich dann auf einen Blick den Copy-Status.

    Zitat von RobertW

    Wieso sollte man die Maschine neustarten müssen? Und Exchange-Dienste werden dadurch natürlich auch nicht beendet.

    Muss man nicht, ich habe zusätzlich aber WindowsUpdates gemacht. Da musste ich zwischendurch mal neu starten.


    Zitat von RobertW

    Das Stop-Script macht genau eine Sache:
    1. Es schaltete den Wartungsmodus aus, sowohl auf dem Windows-Cluster als auch auf den Datenbank-Kopien.

    Wenn das Start-Script den Cluster nicht in den Wartungsmodus setzt, ist es quasi ein Fehler wenn ich das richtig verstanden habe.
    Das müsste ich dann mal untersuchen, warum das so ist...



    Vielen Dank für die ausführliche Antwort, Robert!


    Gruss,
    Matthias

    • Offizieller Beitrag
    Zitat von kiezkicker

    Wenn das Start-Script den Cluster nicht in den Wartungsmodus setzt, ist es quasi ein Fehler wenn ich das richtig verstanden habe.


    Das muss nicht sein. Wenn Du, wie gesagt, beim Ausführen kein lokaler Admin bist, dann kann das Script mit der cluster.exe den Wartungsmodus nicht setzen. Dann kann er auch nicht abgeschaltet werden.


    Und manchmal gibt es Fälle bei Windows Updates, da wird der Wartungsmodus durch das Update geändert und nach dem Reboot ist der Wartungsmodus raus.


    Wenn der Fall nur ab und zu auftritt, würde ich ihn ignorieren.