Automatisches Patchen von Servern mittels WSUS

[DerOlele 0]

Hallo zusammen,

 

machen mir gerade Gedanken wie wir unsere Server in dem Unternhemen, in dem ich arbeite, regelmäßig und sinnvoll patchen können.

 

Dazu folgende Infos damit man sich ein besseres Bild machen kann.

 

Ich arbeite in einem global agierenden Unternehmen das Niederlassungen in Deutschland, Ungarn, China, USA und Mexico hat.
An allen Standorten wird produziert, in 24 Stunden Schichten und zwar von Montag bis Sonntag um 6 Uhr morgens.
Sprich das einzige Zeitfenster um Server zu patchen ist der Sonntag.
Einfach unter der Woche geht nicht, da die Server für die Produktion benötigt werden.
Ich spreche hier auch von annähernd 450 Server weltweit - die allermeisten virtuell (basierend HyperV Träger/ Cluster). Das Gro der Server befindet sich jedoch am Hauptstandort in D.

Jedoch hat jede Niederlassung ein eigenes RZ. Die jüngeren Niederlassungen verfügen schon über geclusterte HyperV umgebungen - die älteren leider noch nicht.
Am Hauptstandort gibt es zwei gespiegelte Rechenzentren - mit aufgeteilten HyperV Clustern und einem NetApp MetroCluster als Storage-Unterbau :-)

 

Die Arbeitsplätze werden weltweit mittels FrontRange DSM AdvancedPatchManagement gepacht - das funktioniert auch ganz gut, insbesondere weil auch
Produkte von Drittanbietern wie Java, Adobe mitgepacht werden.

Jedoch werden die Server nur sehr unregelmäßig gepatcht. Meist nur wenn an einem Server eh etwas zu tun ist.
Zwei Mal pro Jahr hat die IT ein Wartunswochenende, wo wir nach Lust und Laune tun können was wir wollen.
Meist reicht aber gerade mal die Zeit die HyperV Träger zu patchen.....dann ist Schluss.
Ich möchte daher gerne aus Sicherheitsgründen zukünftig die Server (so weit wie möglich) automatisch mittels WSUS patchen lassen.

 

Hier mal meine Gedankengänge

1. automatisches Patchen der DC's - vier Wochen nach dem PatchDay von MS. Bis dahin sollten normalweise alle faulen Patche
bekannt sein. Es sind insgesamt 21 DC's. Alle von Hand zu machen geht nicht. Dazu fehlt die Zeit und das Personal.
2. Patchen aller Test-Systeme ebenfalls vier Wochen nach dem MS PatchDay

3. nach weiteren 4 Wochen Patchen der Produktiv-Server mit den verwendeten Patchen unter Punkt 3.

 

Grundsätzlich sollte immer ein zeitversatz von vier Wochen zwischen Erscheinen des Patches und der Installation des Patches bestehen.

Das wir hier dringend Handlungsbedarf haben ist uns selbst bewusst. Wir haben aber aktuell leider nicht die notwendigen Ressoucen (Zeit und Personal)

um uns händisch um so viele Server zu kümmern.
Oder wäre die bessere Alternative gar nicht zu patchen? Das glaube ich nicht ;-)

 

Wir wollen schließlich dadurch auch die Sicherheit erhöhen. Einen aktuellen Virenschutz bringt nur eingeschränkt etwas

wenn nicht auch die Sicherheitslücken im Betriebssystem gestopft werden.

 

Wie würdet ihr das machen?

Gibt es bei jemanden ähnliche Szenarien? Wie sind die Erfahrungen?

Vorschläge?

Über eine rege Diskussion zu diesem Thema wäre ich dankbar.

 

VG
Thorsten

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[Dukel 436]

Wenn Systeme 24h benötigt werden (99,9...% Verfügbarkeit?) dann sollten diese Systeme auch redundant installiert sein (VM Cluster reicht da nicht) und dann sollte es kein Problem sein, einen Knoten zu patchen und rebooten (mit verminderter Verfügbarkeit während der Zeit).

 

Ich würde mir erst Gedanken über das Vorgehen machen und danach ein Produkt oder Technik auswählen.

[DerOlele 0]

Um es nochmals zu verdeutlichen.
Mir geht es hier nicht um die Träger-Systeme. Diese wurden bisher besser behandelt als die VM's die darauf laufen.
Und ein Reboot eines Trägers tagsüber ist auch in aller Regel ohne weiteres möglich.
Es geht eher um die sehr vielen virtuellen Server die auf den Trägern wohnen - das sind ein paar hundert und die sollten auch mal gepatcht werden.
Dafür bleibt eben nur der Sonntag.....und mit der Hand am Arm wird das ne Aufgabe bis zur Rente

[Dukel 436]

Mir ging es auch um die Virtuellen Server.

 

Aber dann stimmt irgendwas an den Anforderungen nicht. Entweder hat man eine entsprechende Verfügbarkeit und die entsprechende Infrastruktur oder die Server sind doch nicht so wichtig.

Was passiert, wenn ein virtueller Server während des Betriebs abstürzt?

 

Ich würde die Entscheidung nach oben geben. Der Vorgesetzte soll entscheiden, was gemacht wird. Folgende Optionen hat er:

- Nicht Patchen -> Er muss aber dann das Risiko tragen

- Wartungsfenster ausmachen zum Patchen -> Die Mitarbeiter müssen diese dann eben abwarten

- Infrastruktur erweitern, dass auch während des Betriebs gepatcht werden kann

 

OT: Bitte nenne diese Systeme nicht "Träger".

[DerOlele 0]

OK, dann sinds halt HyperV Hosts.
Also nicht jede Anwendung die existiert kann hochverfügbar gemacht werden, nicht jede Applikation lässt sich clustern.
Es gibt Produktionsrelavante Anwendungen die maximal virtualisiert werden können - dass ist schon das höchste der Gefühle.

 

 

Nochmals zur verdeutlichung. Hier handelt es sich nicht um eine Versicherungsklitsche mit 0815 Rechner und ein paar Server.

Wir reden hier von einer Umgebung mit mehreren hundert Server und meheren tausend Clients die auf mehrere Kontinente,
in verschiedenen Zeitzonen leben.
Und einfach mal die Produktion lahmlegen geht nicht.
Beispielsweise kann ich die DC's nicht clustern. Ich kann pro Standort mehere DC's zur Verfügung stellen.
Sollte einer ausfallen, so suchen sich Rechner ab Win 7 automatisch den nächsten Verfügbaren DC um reibungslos

weiter arbeiten zu können.

Wenn aber noch ältere Betriebssystem vorhanden sind (WinXP) dann verliert der Rechner sozusagen die Verbindung.
Eine Neuanmeldung ist Notwendig.
Wie bereits beschrieben sind wir ein produzierende Unternhemen. Dort gibt es viele Produktionsmaschinen, in denen

sozusagen noch ein altes OS wie XP läuft. Manche Hersteller bieten nix neueres an (man glaubt es kaum) und andere
Produtkionmaschinen sind so zertifiziert und mit dem Stand des OS eingeforen und dürfen nicht verändert werden.

Bei Daimler wird sicherlich auch nicht einfach tagsüber gepacht....

 

Also wie gesagt, der Fokus liegt ganz klar auf Sonntag als Patch Day.

Wie das aber sinnvoll gestalten?




 

[Kuddel071089 9]

Wenn ihr ein Wartungfesnter am Sonntag habt, dann würde ich 4 Wochen nach erscheinen die Updates im WSUS manuell freigeben um sicher zu sein, dass die Patche auch wirklich erst dann ausgerollt werden.

 

Per GPO erhalten die Server dann die Einstellungen, dass sie stündlich suchen sollen und am besten, dass die Updates am Sonntag um 8 Uhr automatisch installiert werden, dann sollte alle Server die neuen Updates erhalten haben.

 

Dann noch einstellen, dass die Server automatischen booten sollen und schon sollte das automatische Updaten funktiuonieren.

 

Sollte man natürlich nach und nach testen

[NorbertFe 1.799]

Beispielsweise kann ich die DC's nicht clustern. Ich kann pro Standort mehere DC's zur Verfügung stellen.

Bl...es BEispiel. Denn AD ist ja nun so ziemlich das optimalste System was Service-Redundanz angeht. Ja mehrere DCs und man hat RUhe. Dann sollten die DCs aber auch nur das tun und nicht noch andere Aufgaben. ;)

 

Sollte einer ausfallen, so suchen sich Rechner ab Win 7 automatisch den nächsten Verfügbaren DC um reibungslos

weiter arbeiten zu können.

Stell dir vor, das ging sogar schon unter Windows 2000. ;)

 

Wenn aber noch ältere Betriebssystem vorhanden sind (WinXP) dann verliert der Rechner sozusagen die Verbindung.

Eine Neuanmeldung ist Notwendig.

Wäre mir neu. Abgesehen davon... XP ist alt und damit ja an sich schon ein Risiko.

 

Wie bereits beschrieben sind wir ein produzierende Unternhemen. Dort gibt es viele Produktionsmaschinen, in denen

sozusagen noch ein altes OS wie XP läuft. Manche Hersteller bieten nix neueres an (man glaubt es kaum) und andere

Produtkionmaschinen sind so zertifiziert und mit dem Stand des OS eingeforen und dürfen nicht verändert werden.

Bei Daimler wird sicherlich auch nicht einfach tagsüber gepacht....

Bleibt die Frage, warum man sowas dann im "Office" Netz eingeklinkt hat. ;)

 

 

Also wie gesagt, der Fokus liegt ganz klar auf Sonntag als Patch Day.

Ich hoffe, du bekommst das "sinnvoll" vergütet. Ich würd mich jedenfalls bedanken, wenn ich regelmässig meine Wochenenden mit sowas zubringen müßte.

 

Wie das aber sinnvoll gestalten?

Was genau? Die Sonntagsbeschäftigung? Wer soll dir das bei den Infos denn sagen können? Du hast unbekannte Applikationen, Produktionsmaschinen und weltweite Verteilung. Da is an anderen Standorten vielleicht nicht mal Sonntag.

 

Bye

Norbert

[Dukel 436]

Und wenn du Sonntags patcht ist es in anderen Kontinenten Montags und du legst dann auch die Produktion lahm.

Wenn du automatisch am Sonntag alles patcht und dann steht, durch ein Problem, alles hast du genauso ein Problem.

Bei Daimler gibt es auch Wartungsfenster tagsüber.

 

Deine Möglichkeiten habe ich dir oben genannt.

Du musst nicht alle Systeme gleich behandeln.

Ich würde die Systeme in Gruppen einteilen (kritikalität, Redundanz, Produktionmaschinen) und unterschiedliche Vorgehensweisen für diese Gruppen vorschlagen.

Geclusterte Systeme in einer Ruhigen Minute Patchen, Produktionsmaschinen gar nicht patchen, unkritische und Testsysteme mit Wartungsfenster.

Danach hast du nur eine Hand Voll kritische Systeme, die sich nicht clustern lassen. Die kannst du dann gern Sonntags patchen.

 

Ich würde dies aber mit dem Vorgesetzen / Geschäftsleitung abstimmen.

 

Wie schon von Norbert geschrieben: Das man bei einem Reboot eines DCs sich neu anmelden muss ist nicht normal.

[DerOlele 0]

Bl...es BEispiel. Denn AD ist ja nun so ziemlich das optimalste System was Service-Redundanz angeht. Ja mehrere DCs und man hat RUhe. Dann sollten die DCs aber auch nur das tun und nicht noch andere Aufgaben. ;)

Bei uns machen die DC's nur die AD Aufgaben. Sonst nix.

 

Stell dir vor, das ging sogar schon unter Windows 2000. ;)

 

 

Wäre mir neu. Abgesehen davon... XP ist alt und damit ja an sich schon ein Risiko.

 

Tja, aber wie bereits erwähnt sind wir halt nicht eine 0815 Office Klitsche die nur ein paar Rechner mit Office, ein paar Server wie DC's, FileServer etc. haben.

Die Rechner dürfen teilweise nicht mal mehr gepatcht werden, weil Sie so vom Kunden abgenommen wurden und nur mit diesem Stand bestimmte Produkte

produziert werden dürfen. Geh mal zu Bosch, Daimler oder ähnlichen Unternehmen. Auch die haben solche alten Rechner.

 

Bleibt die Frage, warum man sowas dann im "Office" Netz eingeklinkt hat. ;)

 

Die Rechner müssen im Netz sein, weil diese gesteuert werden müsse, mit anderen Produktionsapplikationen kommunizieren müssen, etc...

Diese werden zwar in anderen VLAN's gesteckt die anderst gesichert werden, benötigen aber trotzdem Kontakt zur diversen Server etc.

Beispielsweise gibt es Spritzgussmaschine...die müssen auch gesteuert werden und hängen deshalb am Netz.

 

Mich würde mal interssieren wie groß das Unternehme ist, in welchem du arbeitest und vor allem ob das auch produzierendes Gewerbe ist ;-)

 

 

 

 

 

Ich hoffe, du bekommst das "sinnvoll" vergütet. Ich würd mich jedenfalls bedanken, wenn ich regelmässig meine Wochenenden mit sowas zubringen müßte.

 

Kein Angst. Sofern Sonntags mal gearbeitet wird gibt es dann ordentliche Zuschläge. Aber wie gesagt soll das automatisch laufen, sond kann ich es gleich

so lassen wie es ist.

Was genau? Die Sonntagsbeschäftigung? Wer soll dir das bei den Infos denn sagen können? Du hast unbekannte Applikationen, Produktionsmaschinen und weltweite Verteilung. Da is an anderen Standorten vielleicht nicht mal Sonntag.

 

Bye

Norbert

[NorbertFe 1.799]

Tja, aber wie bereits erwähnt sind wir halt nicht eine 0815 Office Klitsche die nur ein paar Rechner mit Office, ein paar Server wie DC's, FileServer etc. haben.

Na so ein Glück für dich. Wieso meinst du, ich würde Produktionskunden nicht kennen? Keine Sorge. Nein ich arbeite als Dienstleister und habe relativ weit gestreute Kundschaft.

 

Die Rechner dürfen teilweise nicht mal mehr gepatcht werden, weil Sie so vom Kunden abgenommen wurden und nur mit diesem Stand bestimmte Produkte

produziert werden dürfen. Geh mal zu Bosch, Daimler oder ähnlichen Unternehmen. Auch die haben solche alten Rechner.

Mußt du mir nicht erzählen. Trotzdem kein Grund... Dann gibt's eben Ausnahmen.

 

 

 

Die Rechner müssen im Netz sein, weil diese gesteuert werden müsse, mit anderen Produktionsapplikationen kommunizieren müssen, etc...

Diese werden zwar in anderen VLAN's gesteckt die anderst gesichert werden, benötigen aber trotzdem Kontakt zur diversen Server etc.

Total "anderst"? Oder noch anderster?

 

 

Mich würde mal interssieren wie groß das Unternehme ist, in welchem du arbeitest und vor allem ob das auch produzierendes Gewerbe ist ;-)

Warum interessiert dich das? Weil du mir nicht glaubst?

 

 

Bye

Norbert

[matze-it 10]

Wenn dann mal eine Entscheidung getroffen ist gibt schau dir halt mal das System Center an. Ich patche damit in verschiedenen Wartungsfenstern und habe in meinem Fall Freitags und Montags damit Arbeit. Freitags freigeben, Montags prüfen.

[tesso 360]

Warum überhaupt den WSUS nutzen wo doch schon eine Patchinfrastruktur (Frontrange) vorhanden ist?

 

Und ja, ich kenne auch Unternehmen mit mehr als einem Server und auch produzierendes Gewerbe.

[Doso 77]

WSUS mit entsprechenden Reboot Zeitfenster Sonntag, xxx uhr. Mehrere OUs und dort die Server einsortieren, hier Zeiten definieren z.B. Sonntag 22 Uhr, 23 Uhr. Dann die Server sinnvoll aufteilen, z.B. sollte nicht alle Hyper-V Clustermitglieder gleichzeitig patchen. Dann einmal pro Monat hingehen Updates im WSUS freigeben, beim nächsten Sonntag wird dann durchgepatcht.

 

Bei der Anzahl der Server macht vermutlich auch ein eigene WSUS Gruppe Sinn. Also eine kleine Gruppe evtl. unwichtigerer Systeme, die ihr dann z.B. eine Woche vorab patcht um Probleme festzustellen.

[NorbertFe 1.799]

Wenns Hyper-V 2012 aufwärts ist gibt's für die Hyper-V Knoten keinen Grund für solche Planungen, denn die könnne clusteraware updating. ;)

 

Ansonsten wundert mich, dass man so große Umgebungen hat und sich keine Strukturierung überlegt hat, sondern hier jetzt Brainstorming betreibt. ;)

 

Bye

Norbert