20
Window Server Update-Konzeptplan
Hallo zusammen,
wir sind gerade daran einen neuen Update-Konzeptplan zu erarbeiten für unserer Windows Server 2008-2016 Serverumgebungen.
Wie macht ihr das in eurer Umgebungen? Macht ihr wöchentlich an einem bestimmten Tag einen "Patchday", bei dem ihr Abends alle Server zusammen updatet?
Oder macht ihr das sukszessive Server für Server über die Woche verteilt?
Wie ist das mit Updates welche potentielle Fehler beeinhalten könnten oder die System durch das Updaten so beeinträchtigen könnten, sodass manche Anwendungen oder Dienste nicht mehr ordnungsgemäss funktioniert, testet ihr die Updates zuerst in einer Testumgebung bevor ihr die Serverupdates ausrollt?
Was wäre der beste Weg MS-Server Updates auszurollen ohne das man danach noch grossen Wartungsaufwand hat?
Danke und Gruss
staybb
wir sind gerade daran einen neuen Update-Konzeptplan zu erarbeiten für unserer Windows Server 2008-2016 Serverumgebungen.
Wie macht ihr das in eurer Umgebungen? Macht ihr wöchentlich an einem bestimmten Tag einen "Patchday", bei dem ihr Abends alle Server zusammen updatet?
Oder macht ihr das sukszessive Server für Server über die Woche verteilt?
Wie ist das mit Updates welche potentielle Fehler beeinhalten könnten oder die System durch das Updaten so beeinträchtigen könnten, sodass manche Anwendungen oder Dienste nicht mehr ordnungsgemäss funktioniert, testet ihr die Updates zuerst in einer Testumgebung bevor ihr die Serverupdates ausrollt?
Was wäre der beste Weg MS-Server Updates auszurollen ohne das man danach noch grossen Wartungsaufwand hat?
Danke und Gruss
staybb
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: 526047
Url: https://administrator.de/contentid/526047
Ausgedruckt am: 25.11.2024 um 18:11 Uhr
20 Kommentare
Neuester Kommentar
Reden wir von 10 oder 1000 Servern?
Hi,
"am Besten" gibts hier nicht. Das hängt allein von Euren konkreten Anforderungen ab. Welche Verfügbarkeiten müsst Ihr gewährleisten, welche Redundanzen gibt es bereits bei Euch, welche Techniken für Snapshot, Backup und Recovery setzt Ihr ein, usw. usw.
Auch hier gilt: Frag 10 Admins und Du bekommst 12 Meinungen.
Siehe auch wsus.de
E.
"am Besten" gibts hier nicht. Das hängt allein von Euren konkreten Anforderungen ab. Welche Verfügbarkeiten müsst Ihr gewährleisten, welche Redundanzen gibt es bereits bei Euch, welche Techniken für Snapshot, Backup und Recovery setzt Ihr ein, usw. usw.
Auch hier gilt: Frag 10 Admins und Du bekommst 12 Meinungen.
Siehe auch wsus.de
E.
Hier würde ich ja erstmal upgraden, Updates gibts da ja nur noch ein mal.
Und ansonsten in Wellen ausrollen, erst unwichtige Systeme und dann wichtige.
Thomas
üblicherweise einmal im jahr oder teils auch alle 4-6 jahre einmal....
Den Großteil der Server Patche ich mit dem SCCM. Bestimmte Systeme mit der Hand.
In abgeschotteten Netzen könnte man das so machen.
ca. 100 Server. Mir schwebt immer ein Patchday im Kopf rum, an dem man sagt man updated die Server komplett durch oder lieber doch sukzessive Server für Server an verschiedenen Tagen... Wie macht ihr das?
Es gibt div. Gründe warum sowas manchmal nötig ist - auch in nicht abgeschotteten Netzen... Stell dir mal ne Forschungsstation in der Arktis, die Raumstation oder einfach nur nen Schiff auf See vor. Was meinst - wenn morgen die IT des Weissen Hauses zu Donni-Boy geht und sagt "Sorry, die George H.W. Bush (Flugzeugträger aus 2009) muss leider zurück, es is nen Update schief gelaufen" - ob Trumpi sich dann selbst ne Twitter-Message schickt "you need to watch a movie with friends and chill a bit"?!? Oder wenn du morgen gemütlich deinen Cocktail auf nem Dampfer trinkst und der Captain sagt "Sorry liebe Gäste, wir müssen kurz zurück zur Werft und die Rechner neu installieren lassen" - ich weiss nich ob nen Gast da wirklich begeistert ist...
Moin,
finde ich, bei der Updatepolitik von MS, völlig daneben!
ich würde es in Wellen machen, erst unkritische Systeme dann kritische.
Sollten Fehler auftreten sind zuerst unkritische Systeme betroffen.
Außerdem könnten bei ca 100 Server, ich kenne eure Struktur nicht, wichtige Abhängigkeiten bestehen. Damit könntest du dir ins eigene Knie schießen...
Gruß
der jenni
finde ich, bei der Updatepolitik von MS, völlig daneben!
ich würde es in Wellen machen, erst unkritische Systeme dann kritische.
Sollten Fehler auftreten sind zuerst unkritische Systeme betroffen.
Außerdem könnten bei ca 100 Server, ich kenne eure Struktur nicht, wichtige Abhängigkeiten bestehen. Damit könntest du dir ins eigene Knie schießen...
Gruß
der jenni
Die 90er wollen ihr Dollarzeichen zurück.
1Zitat von @maretz:
Es gibt div. Gründe warum sowas manchmal nötig ist - auch in nicht abgeschotteten Netzen... Stell dir mal ne Forschungsstation in der Arktis, die Raumstation oder einfach nur nen Schiff auf See vor.
Nach meiner Einschätzung wären das klassische Fälle für Systeme, welche abzuschotten wären, bzw. sind.Es gibt div. Gründe warum sowas manchmal nötig ist - auch in nicht abgeschotteten Netzen... Stell dir mal ne Forschungsstation in der Arktis, die Raumstation oder einfach nur nen Schiff auf See vor.
Was meinst - wenn morgen die IT des Weissen Hauses zu Donni-Boy geht und sagt "Sorry, die George H.W. Bush (Flugzeugträger aus 2009) muss leider zurück, es is nen Update schief gelaufen" - ob Trumpi sich dann selbst ne Twitter-Message schickt "you need to watch a movie with friends and chill a bit"?!? Oder wenn du morgen gemütlich deinen Cocktail auf nem Dampfer trinkst und der Captain sagt "Sorry liebe Gäste, wir müssen kurz zurück zur Werft und die Rechner neu installieren lassen" - ich weiss nich ob nen Gast da wirklich begeistert ist...
Ja, natürlich läuft das so.
Stimmt - das wären eigentlich Systeme die man schliessen soll... Nur: Sage da mal den Mitarbeitern das die das Internet nicht für Anrufe zuhause oder den Film zum Feierabend nutzen dürfen. Klar - man muss nicht alles 100% offen lassen, aber man muss eben nen Mittelweg finden zwischen Sicherheit und der zufriedenheit der Mitarbeiter. Denn du kannst natürlich nen Netz zunageln - und im besten Fall hast du dann nur mal lokal nen Knopf zu drücken und der Mitarbeiter sagt nur "leck mich". Im dümmsten Fall hast du sogar Personen die dann absichtlich kaputt machen.
Von daher finde ich eben Fragen wie diese recht interessant - da es eben nicht "DIE" Lösung gibt sondern nur Lösungen die eben die Umgebung betreffen.
Von daher finde ich eben Fragen wie diese recht interessant - da es eben nicht "DIE" Lösung gibt sondern nur Lösungen die eben die Umgebung betreffen.
Stimmt - das wären eigentlich Systeme die man schliessen soll... Nur: Sage da mal den Mitarbeitern das die das Internet nicht für Anrufe zuhause oder den Film zum Feierabend nutzen dürfen.
Öhm? Das ist normal, dass das nicht geht...
Hallo,
naja... je nach Umgebung muss das schon möglich sein. Je nachdem von was für einer Server Infrastruktur wir hier reden...
und die Beispiele von @maretz waren ja:
brammer
Öhm? Das ist normal, dass das nicht geht...
naja... je nach Umgebung muss das schon möglich sein. Je nachdem von was für einer Server Infrastruktur wir hier reden...
und die Beispiele von @maretz waren ja:
Stell dir mal ne Forschungsstation in der Arktis, die Raumstation oder einfach nur nen Schiff auf See vor.
brammer
Dann sollte es dafür extra Netze geben und die Netze sollten sowieso immer getrennt von den Servernetzen sein.
Zitat von @brammer:
Hallo,
naja... je nach Umgebung muss das schon möglich sein. Je nachdem von was für einer Server Infrastruktur wir hier reden...
und die Beispiele von @maretz waren ja:
brammer
Hallo,
Öhm? Das ist normal, dass das nicht geht...
naja... je nach Umgebung muss das schon möglich sein. Je nachdem von was für einer Server Infrastruktur wir hier reden...
und die Beispiele von @maretz waren ja:
Stell dir mal ne Forschungsstation in der Arktis, die Raumstation oder einfach nur nen Schiff auf See vor.
brammer
Also zumindest bei der Forschungsstation und dem Schiff auf See kann ich dir sagen das dort nichts heruntergeladen wird und telefonieren nach Hause auch nur begrenzt funktioniert. Dort sind überall Gateways mit Beschränkungen davor und die manipuliert auch keiner wenn er denn seinen Lohn noch nach Hause schicken will. Die Crew wird nämlich ungehalten wenn da einer das bezahlte Volumen für sich alleine aufbraucht.
/Thomas
Sehe ich ähnlich und wer eine entspr. Begrenzung mit der dann aufkommenden Zerstörungswut begnegnet im Sinne von "deswegen aufmachen", der hat es wohl mit Asozialen zu tun.
Hallo,
Wir haben gut 200 Server und verteilen die Updates über WSUS. Nach Freigabe laden die Server die Updates zunächst nur herunter.
Die Installation wird über ein powershell-script zentral getriggert. Über eine Steuerdatei werden Updates in der dritten woche für Testsysteme getriggert. Wenn alles gut ist, dann findet in der vierten woche die Installation für Produktivsysteme statt. Über die Steuerdatei können wir den Installationstag und die Uhrzeit bestimmen, wann installiert wird. So können wir die "Last" verteilen.
Ein übel hat man an sich bei 2016. Die Fertigstellung der Installation kann je nach Performance lange (ne Stunde und mehr) dauer
Wir haben gut 200 Server und verteilen die Updates über WSUS. Nach Freigabe laden die Server die Updates zunächst nur herunter.
Die Installation wird über ein powershell-script zentral getriggert. Über eine Steuerdatei werden Updates in der dritten woche für Testsysteme getriggert. Wenn alles gut ist, dann findet in der vierten woche die Installation für Produktivsysteme statt. Über die Steuerdatei können wir den Installationstag und die Uhrzeit bestimmen, wann installiert wird. So können wir die "Last" verteilen.
Ein übel hat man an sich bei 2016. Die Fertigstellung der Installation kann je nach Performance lange (ne Stunde und mehr) dauer
Zitat von @jimbeam128:
Hallo,
Wir haben gut 200 Server und verteilen die Updates über WSUS. Nach Freigabe laden die Server die Updates zunächst nur herunter.
Die Installation wird über ein powershell-script zentral getriggert. Über eine Steuerdatei werden Updates in der dritten woche für Testsysteme getriggert. Wenn alles gut ist, dann findet in der vierten woche die Installation für Produktivsysteme statt. Über die Steuerdatei können wir den Installationstag und die Uhrzeit bestimmen, wann installiert wird. So können wir die "Last" verteilen.
Ein übel hat man an sich bei 2016. Die Fertigstellung der Installation kann je nach Performance lange (ne Stunde und mehr) dauer
Hallo,
Wir haben gut 200 Server und verteilen die Updates über WSUS. Nach Freigabe laden die Server die Updates zunächst nur herunter.
Die Installation wird über ein powershell-script zentral getriggert. Über eine Steuerdatei werden Updates in der dritten woche für Testsysteme getriggert. Wenn alles gut ist, dann findet in der vierten woche die Installation für Produktivsysteme statt. Über die Steuerdatei können wir den Installationstag und die Uhrzeit bestimmen, wann installiert wird. So können wir die "Last" verteilen.
Ein übel hat man an sich bei 2016. Die Fertigstellung der Installation kann je nach Performance lange (ne Stunde und mehr) dauer
Hallo,
danke für deine Vorgehensweise, das hört sich vom Konzept sehr gut an. Darf ich fragen wie das Powershellscript genau aussieht? Gibt es dafür vielleich eint Vorlage Template von MS?
Danke und Gruss
Nee, das hab ich selbst gebaut.
Da brauchste auch n paar Voraussetzungen für (z. B. Powershell Remoting auf den servern aktiviert) und mit powershell solltest du dich dann auch schon ganz gut auskennen.
Kann es dir ja mal als PN schicken
Da brauchste auch n paar Voraussetzungen für (z. B. Powershell Remoting auf den servern aktiviert) und mit powershell solltest du dich dann auch schon ganz gut auskennen.
Kann es dir ja mal als PN schicken
