derwowusste
Goto Top

Letztes Update für Exchange 2016 CU9 war in gewisser Weise destruktiv

Kurzer Erfahrungsbericht zu Exchange2016-KB4340731-x64

Der Exchangeserver hat wie gewöhnlich versucht, es in der Nacht automatisch zu installieren - abgesehen von diesem Update haben wir auf dem Exchange damit seit Jahr und Tag keine Probleme gehabt.
Die Installation schlug fehl - soll sie doch, macht ja nichts.

Allerdings wurden im Zuge der installation alle Exchangedienste gestoppt und auf deaktiviert gesetzt und dann beim Fehlschlagen der Installation nicht wieder aktiviert und daher auch nicht gestartet. Nichts ging mehr.
Heilige Sch... wer bei Euch denkt sich denn so einen Humbug aus, Microsoft?

Starte ich die Installation von Exchange2016-KB4340731-x64-en.msp manuell, schlägt diese ebenso fehl...aber das ist ein bereits bekanntes Problem dieses Updates... es fordert keine Elevation an und muss manuell elevated werden (Rechtsklick auf cmd.exe ->als Administrator ausführen ->dort dann Exchange2016-KB4340731-x64-en.msp starten) - dann installiert es sich auch fehlerfrei.

Also: etwas Vorsicht bei diesem Update ist geboten.

Content-Key: 383729

Url: https://administrator.de/contentid/383729

Ausgedruckt am: 19.03.2024 um 10:03 Uhr

Mitglied: Penny.Cilin
Penny.Cilin 17.08.2018 um 15:42:11 Uhr
Goto Top
Hallo @dww,

danke für die Information. Manchmal frage ich mich ehrlich, wo die Qualitätskontrolle (bei Microsoft) geblieben ist.

Gruss Penny
Mitglied: Spirit-of-Eli
Spirit-of-Eli 17.08.2018 um 15:52:45 Uhr
Goto Top
Wie immer das gleiche.

Hat man nur nen Wsus ohne SCCM heißt es wegducken und min drei Wochen warten bevor man es installiert
Mitglied: 117471
117471 17.08.2018 um 20:20:08 Uhr
Goto Top
Hallo,

tröste dich: Mit dem Update Rollup 23 für Exchange 2010 SP3 hatte ich nahezu gleiche Probleme.

Gruß,
Jörg
Mitglied: em-pie
em-pie 17.08.2018 um 23:02:01 Uhr
Goto Top
Moin,

Hatte ich vor einem Jahr oder so auch schon mal am 2010er. Weiß aber nicht mehr genau, welches Update es war. Kann sogar ein ServicePack gewesen sein.


@dww:
Danke für die Info/ Vorwarnung
Mitglied: UweGri
UweGri 17.08.2018 um 23:32:10 Uhr
Goto Top
OT

Heilige Sch... wer bei Euch denkt sich denn so einen Humbug aus, Microsoft?

Haste Mut? Schreibe das mal bei DrWindows rein! Das sind da gaaaaanz harte Fanboys, 0Tolleranz bei Kritik an MS! Uwe
Mitglied: Spirit-of-Eli
Spirit-of-Eli 17.08.2018, aktualisiert am 18.08.2018 um 00:10:04 Uhr
Goto Top
Zitat von @UweGri:

OT

Heilige Sch... wer bei Euch denkt sich denn so einen Humbug aus, Microsoft?

Haste Mut? Schreibe das mal bei DrWindows rein! Das sind da gaaaaanz harte Fanboys, 0Tolleranz bei Kritik an MS! Uwe

Das gehört zwar nicht zum Thema aber mir viel gerade ein "und bei Winfuture.de sind groupies anzutreffen" ;)
Mitglied: falscher-sperrstatus
falscher-sperrstatus 19.08.2018 aktualisiert um 19:51:37 Uhr
Goto Top
Zitat von @UweGri:

OT

Heilige Sch... wer bei Euch denkt sich denn so einen Humbug aus, Microsoft?

Haste Mut? Schreibe das mal bei DrWindows rein! Das sind da gaaaaanz harte Fanboys, 0Tolleranz bei Kritik an MS! Uwe

Wer installiert Exchange Updates automatisch? Und Server Updates... Ungesundes Gottvertrauen, übrigens auch unter Debian...

PS: meine Installationen ex 2010 bis 2016 liefen problemlos durch
Mitglied: MartinL
MartinL 20.08.2018 um 06:24:01 Uhr
Goto Top
Moin,

davon abgesehen das ich sie manuell installieren was aber jedem selbst überlassen ist setze ich grundsätzlich nach jedem Update alle "inaktiven" Dienste mittels Skript immer in den "activen" Status. Ich prüfe auch garnicht erst ob es "inaktive" gibt.

$ComponentStates = Get-ExchangeServer | Get-ServerComponentState | where {$_.Component -ne "ForwardSyncDaemon" -and $_.Component -ne "ProvisioningRps" -and $_.State -eq "Inactive"}  
foreach ($ComponentState in $ComponentStates)
 {
  $LocalStates = $ComponentState.LocalStates | where {$_.State -eq "Inactive"}  
  foreach ($LocalState in $LocalStates)
   {
    Set-ServerComponentState -Identity $ComponentState.Identity.Name -Component $LocalState.Component -State Active -Requester $LocalState.Requester
   }
 }
Quelle:frankysweb.de


Gruss Martin
Mitglied: Voiper
Voiper 20.08.2018 um 16:23:33 Uhr
Goto Top
Zitat von @MartinL:

Moin,

davon abgesehen das ich sie manuell installieren was aber jedem selbst überlassen ist setze ich grundsätzlich nach jedem Update alle "inaktiven" Dienste mittels Skript immer in den "activen" Status. Ich prüfe auch garnicht erst ob es "inaktive" gibt.

> $ComponentStates = Get-ExchangeServer | Get-ServerComponentState | where {$_.Component -ne "ForwardSyncDaemon" -and $_.Component -ne "ProvisioningRps" -and $_.State -eq "Inactive"}  
> foreach ($ComponentState in $ComponentStates)
>  {
>   $LocalStates = $ComponentState.LocalStates | where {$_.State -eq "Inactive"}  
>   foreach ($LocalState in $LocalStates)
>    {
>     Set-ServerComponentState -Identity $ComponentState.Identity.Name -Component $LocalState.Component -State Active -Requester $LocalState.Requester
>    }
>  }
> 
Quelle:frankysweb.de


Gruss Martin
Moin,

manch einer hat aber noch Altsoftware, deren Dienste evtl. nicht mehr laufen sollen. Dann wäre diese Vorgehensweise kontraproduktiv.

Gruß, V
Mitglied: emeriks
emeriks 04.09.2018 um 08:49:34 Uhr
Goto Top
Hi DWW,
Exchange Server Updates werden bei uns niemals automatisch installiert!

Allerdings wurden im Zuge der installation alle Exchangedienste gestoppt und auf deaktiviert gesetzt und dann beim Fehlschlagen der Installation nicht wieder aktiviert und daher auch nicht gestartet. Nichts ging mehr.
Das ist ein alter Bug des Exchange Setups, meines Wissens gab es dieses Szenario schon bei Exch 2003. Hilft Dir nur, weil Du es jetzt weißt. face-wink

Hinzu kommt, dass neuerdings bei diversen Exch CU mittendrin mit erforderlichen AD Schema Updates zu rechnen ist. Diese müssen jeweils vor der Installation des betreffenden CU erfolgt sein. Schon allein das ist ein Grund dafür, dass man Exchange Server Updates nicht per WSUS ausrollen sollte.

E.
Mitglied: falscher-sperrstatus
falscher-sperrstatus 04.09.2018 um 08:53:04 Uhr
Goto Top
Das ist kein Bug, was bringt einem ein System, in dem die Exchange Services versuchen dauerhaft in eine korrupte Update-Installation zu schreiben? Ich würde darauf tippen: noch stärkere Bauchschmerzen..

Aber grundsätzlich, Exchange Updates spielt man nicht automatisch ein. Würde sogar sagen, dass man Server Updates nicht nach schema one-Time Fire and forget per WSUS einspielt.
Mitglied: DerWoWusste
DerWoWusste 04.09.2018 aktualisiert um 08:55:00 Uhr
Goto Top
Moin.

Wir haben seit 11 Jahren alle CUs manuell installiert aber jedoch alle Patches automatisiert installiert. Dies war das erste Problem dabei - überlege bitte, wieviel Aufwand uns die automatisierte Installation gespart hat - das Gesparte übersteigt bei weitem den Trouble, den dieser kurze Ausfall ausgelöst hat.

Das ist ein alter Bug des Exchange Setups, meines Wissens gab es dieses Szenario schon bei Exch 2003
Glaube ich gerne. Microsoft ist sehr gut im Nichts-Dazulernen.
Mitglied: falscher-sperrstatus
falscher-sperrstatus 04.09.2018 um 08:59:13 Uhr
Goto Top
Wenn man das so sehen kann, ist das doch super.

Aber das MS nichts dazu lernt würd ich verneinen, fährst du gerne mit einem nicht fest verschraubten reifen los?
Mitglied: emeriks
emeriks 04.09.2018 um 09:03:32 Uhr
Goto Top
Zitat von @falscher-sperrstatus:
Aber das MS nichts dazu lernt würd ich verneinen, fährst du gerne mit einem nicht fest verschraubten reifen los?
Darum geht es doch gar nicht.
Es ist Fakt, dass der Exchange Setup kein sauberes (idiotensicheres) Rollback kann. Zum Rollback gehgört m.E. nicht nur das Wiederherstellen von Dateien im alten Zustand sondern auch die Wiederherstellung der Konfiguration. Und zu letzterem gehört nun mal auch der Zustand der Windows Dienste. A) welche Start-Parameter diese hatten und B) dass die Dienste in den ursprünglichen Zustand versetzt werden.
Komischerweise geht das beim SQL-Server ....
Mitglied: falscher-sperrstatus
falscher-sperrstatus 04.09.2018 um 09:25:14 Uhr
Goto Top
Würde behaupten, dass ein SQL auch nicht so tief "im System" (AD) sitzt, wie ein Exchange, liegt ggf. (auch) daran, oder an der Sichtweise auf die Sicherheit, kaum einer dürfte SQL Server so exponiert betreiben, wie es ein Exchange ist...würde es also nicht als platt "unfähig" bezeichnen, ohne die dahinterliegende Philosophie zu ergründen.
Mitglied: DerWoWusste
DerWoWusste 04.09.2018 aktualisiert um 09:35:59 Uhr
Goto Top
Das hat nun mit dem AD mal gar nichts zu tun, ob der Rollback funktioniert, wie man es erwarten sollte. Führe dir doch bitte mal vor Augen, warum die Dienste überhaupt deaktiviert (und nicht bloß gestoppt) werden - es gibt dafür nur einen Grund: MS will vorbeugen, dass die nicht von Kontrollskripten, welche von Administratioren etabliert wurden, wieder angeworfen werden, während das Update läuft - es gibt keinen anderen guten Grund dafür. Anstatt jetzt den Admins in der Packungsbeilage klar zu machen: Leute, die Dienste müssen aus bleiben, greift MS gleich zur Keule und hat aber die Recovery bei abgebrochener Patchinstallation (offenbar, siehe emeriks) seit Jahren nicht im Griff - darum geht es hier.

...ohne die dahinterliegende Philosophie zu ergründen.
Mensch, wir philosophieren hier doch nicht face-wink Lass mal gut sein, ich hatte es nur mitteilen wollen, da es mir neu war.
Mitglied: falscher-sperrstatus
falscher-sperrstatus 04.09.2018 um 09:55:54 Uhr
Goto Top
...och, dir ist schon klar, dass wir uns hier am Board tagtäglich mit solchen Admins herumschlagen, die nichtmal den Packungsumschlag richtig lesen, demnach mit der Packungsbeilage offensichtlich total überfordert wären? Klar macht das MS so. Würd ich vermutlich nicht anders, wie groß das Geschrei wohl wäre, würden Sie es nicht tun...face-wink
Mitglied: DerWoWusste
DerWoWusste 04.09.2018 aktualisiert um 10:13:10 Uhr
Goto Top
Warum sollte es da bitte Geschrei geben, wenn Sie das nicht tun würden? Dienste stoppen, Patch installieren, Dienste starten - fertig. Wenn Admins so dämlich sind und Dienste per Skriptüberwachung neu starten, die kontrolliert beendet wurden, dann machen Sie etwas falsch und haben kein recht zu schreien.

Da Microsoft aber selbst weiß, dass Ihre Exchangedienste gar nicht immer kontrolliert zu beenden sind, weil die Software murksig ist und mit Performanceproblemen nicht umgehen kann, machen sie es so: Dienst wird aufgefordert, sich zu beenden - reagiert er nicht in der Timeoutschwelle, wird er abgeschossen (taskkill) - ganz simpel. Da er jedoch vom Dienstemanager automatisch nach Abschuss neu gestartet würde, wird die Startart zuvor auf disabled gesetzt, was nun zu Problemen führt, wenn die Patchinstallation fehlschlägt, da MS unfähig ist, dies abzufangen.

Wir würde ich es machen an MS' Stelle? Diensterecoveryaction aufzeichnen, ändern auf "bei Absturz nichts unternehmen", Dienst auffordern zu stoppen, wenn Dienst nicht reagiert, Dienst abschießen, Patch installieren, Dienst wieder starten, Dienstrecoveryaction zurückschreiben, fertig. Und wenn der Patch bei der Installation abbricht, dann natürlich auch ordentlicher Rollback.

So und nun mal genug der Philosophie, ich habe zu arbeiten face-smile