18
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.
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.
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: 383729
Url: https://administrator.de/contentid/383729
Ausgedruckt am: 24.11.2024 um 21:11 Uhr
18 Kommentare
Neuester Kommentar
Hallo @dww,
danke für die Information. Manchmal frage ich mich ehrlich, wo die Qualitätskontrolle (bei Microsoft) geblieben ist.
Gruss Penny
danke für die Information. Manchmal frage ich mich ehrlich, wo die Qualitätskontrolle (bei Microsoft) geblieben ist.
Gruss Penny
1
Wie immer das gleiche.
Hat man nur nen Wsus ohne SCCM heißt es wegducken und min drei Wochen warten bevor man es installiert
Hat man nur nen Wsus ohne SCCM heißt es wegducken und min drei Wochen warten bevor man es installiert
Hallo,
tröste dich: Mit dem Update Rollup 23 für Exchange 2010 SP3 hatte ich nahezu gleiche Probleme.
Gruß,
Jörg
tröste dich: Mit dem Update Rollup 23 für Exchange 2010 SP3 hatte ich nahezu gleiche Probleme.
Gruß,
Jörg
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
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
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
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
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
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" ;)
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
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
1
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.
Quelle:frankysweb.de
Gruss Martin
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
}
}Gruss Martin
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.
Quelle:frankysweb.de
Gruss Martin
Moin,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
> }
> }
> Gruss Martin
manch einer hat aber noch Altsoftware, deren Dienste evtl. nicht mehr laufen sollen. Dann wäre diese Vorgehensweise kontraproduktiv.
Gruß, V
Hi DWW,
Exchange Server Updates werden bei uns niemals automatisch installiert!
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.
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. 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.
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.
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.
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.
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.
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?
Aber das MS nichts dazu lernt würd ich verneinen, fährst du gerne mit einem nicht fest verschraubten reifen los?
Zitat von @certifiedit.net:
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.Aber das MS nichts dazu lernt würd ich verneinen, fährst du gerne mit einem nicht fest verschraubten reifen los?
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 ....
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.
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.
Lass mal gut sein, ich hatte es nur mitteilen wollen, da es mir neu war.
...ohne die dahinterliegende Philosophie zu ergründen.
Mensch, wir philosophieren hier doch nicht Lass mal gut sein, ich hatte es nur mitteilen wollen, da es mir neu war.
...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...
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
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
