38873
10.02.2016
1779
10
0
Wie managed Ihr Windows Updates für Server
Ein fröhliches Hallo an alle 
Seit geraumer Zeit veröffentlicht M$ m.E. wahnsinnig viele Patches für seine Betriebssysteme. Im ersten Moment freut man sich, da man ja schließlich hofft, dass damit Bugs und Sicherheitslücken geschlossen werden. Wenn man aber 8 Standorte a 20 bis 25 virtuelle Server sowie 1 Hauptstandort mit ca. 100 VM´s hat, wird's mit der Zeit echt schwierig da noch hinterher zu kommen. Neben der Serverhardware, Storagehardware, USV´s, PDU´s, VMware vSphere, VEEAM B&R, Active Directory, PKI, Mailserver, Terminalserver, Monitoring und noch ein paar anderen wenigen Baustellen, rauben einem diese Windows Updates extrem viel Zeit. Da ich und mein Kollege im Bereich Server & Storage die einzigen sind, suchen wir aktuell nach einer besseren und für uns einfacheren Handhabe um dem ganzen weiterhin Herr zu bleiben.
Unsere aktuelle Vorgehensweise für WU @5116 Server sieht so aus:
1) Updates werden am WSUS pro Standort geladen sowie ein Auto Approval durchgeführt
2) Die Server werden über Updates benachrichtigt, jedoch wird nichts automatisch installiert
3) Je nach zeitlicher Lage/Möglichkeit werden im Rahmen einer geplanten Wartung die Updates durch mich und meinem Kollegen eingespielt. Prüfung der Updates erfolgt am Tag vor der Installation.
Das ist unser Standardprozedere für bsp. Server bei denen die Standardrollen von M$ installiert sind.
Bei speziellen, durch uns definierten Anwendungspaketen erfolgt die Installation von Patches auf den Punkt genau an den jeweiligen Systemen und deren abhängigen Komponenten. Beispiele hierfür wären z.B. Exchange, Terminalserver Farm, Datenbankserver usw. usf.
Diese Variante ist bis dato die für uns sicherste Variante bei der man Systemsicherheit & Systemstabilität am besten in Einklang bringt. Jedoch frisst das wahnsinnig viel Zeit. Und wie es so oft ist --> haben wir
A: nicht sehr viel zeit
B: wird die sowieso schon wenige Zeit, durch andere Projekte noch weniger
Aktuell sind wir dabei die Software Patchmanager von Solarwinds zu evaluieren. Den großen Mehrwert kann ich bis dato mit dieser Software noch nicht erkennen. Zumal der Patchmanager ein zu großes Monster ist, sofern man ihn mal "nebenbei" einrichten und betreuen will.
Mich würde interessieren wie ihr euer Patchmanagement gelöst habt. Ich freue mich auf eure Antworten.
Grüße
Seit geraumer Zeit veröffentlicht M$ m.E. wahnsinnig viele Patches für seine Betriebssysteme. Im ersten Moment freut man sich, da man ja schließlich hofft, dass damit Bugs und Sicherheitslücken geschlossen werden. Wenn man aber 8 Standorte a 20 bis 25 virtuelle Server sowie 1 Hauptstandort mit ca. 100 VM´s hat, wird's mit der Zeit echt schwierig da noch hinterher zu kommen. Neben der Serverhardware, Storagehardware, USV´s, PDU´s, VMware vSphere, VEEAM B&R, Active Directory, PKI, Mailserver, Terminalserver, Monitoring und noch ein paar anderen wenigen Baustellen, rauben einem diese Windows Updates extrem viel Zeit. Da ich und mein Kollege im Bereich Server & Storage die einzigen sind, suchen wir aktuell nach einer besseren und für uns einfacheren Handhabe um dem ganzen weiterhin Herr zu bleiben.
Unsere aktuelle Vorgehensweise für WU @5116 Server sieht so aus:
1) Updates werden am WSUS pro Standort geladen sowie ein Auto Approval durchgeführt
2) Die Server werden über Updates benachrichtigt, jedoch wird nichts automatisch installiert
3) Je nach zeitlicher Lage/Möglichkeit werden im Rahmen einer geplanten Wartung die Updates durch mich und meinem Kollegen eingespielt. Prüfung der Updates erfolgt am Tag vor der Installation.
Das ist unser Standardprozedere für bsp. Server bei denen die Standardrollen von M$ installiert sind.
Bei speziellen, durch uns definierten Anwendungspaketen erfolgt die Installation von Patches auf den Punkt genau an den jeweiligen Systemen und deren abhängigen Komponenten. Beispiele hierfür wären z.B. Exchange, Terminalserver Farm, Datenbankserver usw. usf.
Diese Variante ist bis dato die für uns sicherste Variante bei der man Systemsicherheit & Systemstabilität am besten in Einklang bringt. Jedoch frisst das wahnsinnig viel Zeit. Und wie es so oft ist --> haben wir
A: nicht sehr viel zeit
B: wird die sowieso schon wenige Zeit, durch andere Projekte noch weniger
Aktuell sind wir dabei die Software Patchmanager von Solarwinds zu evaluieren. Den großen Mehrwert kann ich bis dato mit dieser Software noch nicht erkennen. Zumal der Patchmanager ein zu großes Monster ist, sofern man ihn mal "nebenbei" einrichten und betreuen will.
Mich würde interessieren wie ihr euer Patchmanagement gelöst habt. Ich freue mich auf eure Antworten.
Grüße
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 295660
Url: https://administrator.de/forum/wie-managed-ihr-windows-updates-fuer-server-295660.html
Ausgedruckt am: 20.04.2025 um 21:04 Uhr
10 Kommentare
Neuester Kommentar
Hi
wir unterscheiden nach Einsatz vom Server, wenn der ausschließlich interne Aufgaben hat, wie z.B. Fileserver, ERP Server usw. werden Patches nur alle 3 Monate in einem festgelegten Wartungsfenster eingespielt, klar gibt es Ausnahmen wenn z.B. irgendetwas kritisches gefixt wird. Dann gibt es die anderen Server die nach draußen verfügbar sind, wie z.B. Exchange, Webserver, DirectAccess Server usw. die werden unmittelbar nach erfolgreichen Test der Patches auf den aktuellen Stand gebracht. Das gleiche gilt für Firewalls und anderen systemkritischen Elementen.
Ob man auf einem SQL Server jetzt SP1 oder SP2 hat und auch ohne das SP2 noch anstandslos läuft, wird das auch mal nach hinten verschoben, da solche Server nach einem Restart immer wieder Zeit brauchen bis der Index vollständig geladen usw.
Gruß
@clSchak
wir unterscheiden nach Einsatz vom Server, wenn der ausschließlich interne Aufgaben hat, wie z.B. Fileserver, ERP Server usw. werden Patches nur alle 3 Monate in einem festgelegten Wartungsfenster eingespielt, klar gibt es Ausnahmen wenn z.B. irgendetwas kritisches gefixt wird. Dann gibt es die anderen Server die nach draußen verfügbar sind, wie z.B. Exchange, Webserver, DirectAccess Server usw. die werden unmittelbar nach erfolgreichen Test der Patches auf den aktuellen Stand gebracht. Das gleiche gilt für Firewalls und anderen systemkritischen Elementen.
Ob man auf einem SQL Server jetzt SP1 oder SP2 hat und auch ohne das SP2 noch anstandslos läuft, wird das auch mal nach hinten verschoben, da solche Server nach einem Restart immer wieder Zeit brauchen bis der Index vollständig geladen usw.
Gruß
@clSchak
Moin,
hier besteht doch m.E. oft nur die Wahl zwischen Pest (evtl. nach Updates nicht mehr funktionierende Hard-/Software) oder Cholera (mögliche Sicherheitslücken)!
Ich teste infolge unserer homogenen Serverstruktur diese Updates zuerst an einem unwichtigen Server und wenn dort keine offenbaren Probleme ersichtlich sind, werden die anderen Server kurzfristig darauf upgedatet.
Bei Client-PCs konnte ich bislang alle monatlichen MS-Updates über den WSUS jeweils zeitnah nach Erscheinen installieren lassen.
Bei weiterer Software ( die Zusatzsoftware wie JRE u.ä. benötigt) muss ich evtl. halt mal riskieren, dass der dortige Anbieter noch ein weiteres Update seiner Software liefern muss.
Gruß
VGem-e
hier besteht doch m.E. oft nur die Wahl zwischen Pest (evtl. nach Updates nicht mehr funktionierende Hard-/Software) oder Cholera (mögliche Sicherheitslücken)!
Ich teste infolge unserer homogenen Serverstruktur diese Updates zuerst an einem unwichtigen Server und wenn dort keine offenbaren Probleme ersichtlich sind, werden die anderen Server kurzfristig darauf upgedatet.
Bei Client-PCs konnte ich bislang alle monatlichen MS-Updates über den WSUS jeweils zeitnah nach Erscheinen installieren lassen.
Bei weiterer Software ( die Zusatzsoftware wie JRE u.ä. benötigt) muss ich evtl. halt mal riskieren, dass der dortige Anbieter noch ein weiteres Update seiner Software liefern muss.
Gruß
VGem-e
wir unterscheiden nach Einsatz vom Server, wenn der ausschließlich interne Aufgaben hat, wie z.B. Fileserver, ERP Server usw. werden Patches nur alle 3 Monate in einem festgelegten Wartungsfenster eingespielt,
Ist das nicht ein bisschen viel Wartezeit? 3 Monate? Darf man fragen wieviel Systeme du/ihr betreut und wie viele Systembetreuer ihr seid?
klar gibt es Ausnahmen wenn z.B. irgendetwas kritisches gefixt wird. Dann gibt es die anderen Server die nach draußen verfügbar sind, wie z.B. Exchange, Webserver, DirectAccess Server usw. die werden unmittelbar nach erfolgreichen Test der Patches auf den aktuellen Stand gebracht. Das gleiche gilt für Firewalls und anderen systemkritischen Elementen.
Wie testet ihr eure datenbankabhängigen Dienste bei Patches? Man benötigt ja für einen richtigen Test, alle anderen Infrastrukturdienste die das betroffene und patchende System braucht, damit es überhaupt "testfähig" ist.
Nehmen wir nur mal das Beispiel Exchange. Angenommen es ist ein Multirole System. Alleine hier benötigt man für einen Test: Mindestens 1x ADDS, 1x Exchange, PKI (bzgl. Zertifikaten etc.) + eine Clientumgebung die auf dem exakt gleichen Stand ist wie die produktiven Clients. Und jetzt bin ich von einer ganz, ganz einfachen Variante ausgegangen. Kein LB, NLB, DAG oder sonstiges im Vorder- oder Hintergrund.
Ob man auf einem SQL Server jetzt SP1 oder SP2 hat und auch ohne das SP2 noch anstandslos läuft, wird das auch mal nach hinten verschoben, da solche Server nach einem Restart immer wieder Zeit brauchen bis der Index vollständig geladen usw.
Das sehe ich etwas anders. Die Installation eines SP´s wird eher wegen den vorhandenen Abhängigkeiten nach hinten verschoben. Hier gilt das Gleiche was das Testen von Patches oder SP´s angeht. Man muss eine riese LAB Umgebung betreiben um überhaupt im Ansatz entsprechende Tests durchführen zu können. Ob diese Tests dann auch wirklich aussagekräftig für einen produktiven Betrieb sind, sei hier mal dahingestellt....
Wir haben das Glück durchgehend virtuelle Systeme im Einsatz zu haben welche mittels VEEAM B&R gesichert werden. Hier können wir uns unsere entsprechenden LAB´s zusammenstellen und die betroffenen Systeme instant aus dem Backup booten und testen. Eine schöne und vor allem weniger aufwendige Sache.
Trotz dessen finde ich immer wieder die Aussagen von Microsoft oder MVP´s witzig, wenn sie zum Update Management sagen, dass man Patches vorher testen soll. Ich weiß ja nicht was andere Systembetreuer so zu tun haben. Wenn man aber genauso arbeiten würde, wie es "Best Practice" empfohlen wird, mache ich persönlich nichts anderes mehr als Patchmanagement. Und selbst dann, ist immer noch nicht sichergestellt, dass alles wirklich 100% funktioniert - nur weil ich das in einer LAB Umgebung getestet habe. Die Verzahnung der vielen verschiedenen Systeme macht es immer schwieriger hier wirklich eine Richtlinie zu etablieren, bei der man nach einem roten Faden durchgeht und hinterher sagen kann -> "Es wurde alles getestet und funktioniert zu 100%"
Auf mich machen die derzeitigen Patchwellen den Eindruck, dass man es Systembetreuern zunehmend immer schwerer machen will, Systeme OnSite im Kontext zur Datensicherheit zu betreiben.
Kann man WSUS eigentlich auch standortübergreifend realisieren?
Ich habe in meinem Testszenario 3 AD-Standorte mit eigenem Subnetz, die via OpenVPN / IPSec gekoppelt sind. Ich stelle mir das so vor, dass ich auf einem der Standorte einen zentralen WSUS-Server betreibe, der alle anderen Standorte bedient.
Kann es zu Problemen führen, wenn die Rechner / Server vorher autark waren?
Kann ich für die Freigabe von Updates Gruppen bilden? (z.B. "dieses Update nur für die Arbeitsplatzrechner", "dieses Update nur für Server aus dem Exchange-Cluster" usw.)?
Kann ich den Cache mit den Updates ebenfalls in die Subnetze spiegeln, um dort den Traffic klein zu halten?
Ich habe in meinem Testszenario 3 AD-Standorte mit eigenem Subnetz, die via OpenVPN / IPSec gekoppelt sind. Ich stelle mir das so vor, dass ich auf einem der Standorte einen zentralen WSUS-Server betreibe, der alle anderen Standorte bedient.
Kann es zu Problemen führen, wenn die Rechner / Server vorher autark waren?
Kann ich für die Freigabe von Updates Gruppen bilden? (z.B. "dieses Update nur für die Arbeitsplatzrechner", "dieses Update nur für Server aus dem Exchange-Cluster" usw.)?
Kann ich den Cache mit den Updates ebenfalls in die Subnetze spiegeln, um dort den Traffic klein zu halten?
Hallo FA-jka,
ich glaube für Deine Frage solltest du einen extra Thread öffnen. Vorher mal bei www.wsus.de vorbei schauen.
Wir haben uns diese standortübergreifenden Szenarien auch schon im Kopf durchgespielt. Sind jedoch bei einem WSUS Server pro Standort geblieben, weil es die für uns beste Lösung ist. Wo siehst du den Mehrwert bei dieser Variante?
ich glaube für Deine Frage solltest du einen extra Thread öffnen. Vorher mal bei www.wsus.de vorbei schauen.
Wir haben uns diese standortübergreifenden Szenarien auch schon im Kopf durchgespielt. Sind jedoch bei einem WSUS Server pro Standort geblieben, weil es die für uns beste Lösung ist. Wo siehst du den Mehrwert bei dieser Variante?
Hi
wir sind aktuell mit 2 Leuten bei ~ 120 Servern unterwegs, die "kritischen" Systeme sind alle in einer Testumgebung vorhanden (gleicher Patchstand, allerdings Leistungstechnisch in etwa 1/5 der primären Systeme). Das betrifft vor allem ERP mit der ECM Kopplung und andere Programme die an die ERP andocken, da reicht zum Teil schon .Net Update und irgend etwas funktioniert dann nicht usw.
Mit dem SP am SQL habe ich doch geschrieben, dass wir das auch mal auf die lange Bank schieben, auch aus den Gründen das diverse Programme sehr empfindlich auf so etwas reagieren. Bei den "internen" Systemen meine ich auch "intern" die können nicht ins Internet, Windows Update wird über WSUS verteilt und Patchmanagement der Applikationen wird über eine Appliance gemanaged.
Und bei den "08/15" Servern machen wir das wie du es geschildert hast über Veeam, dass geht im Regelfall recht zügig, wir haben nicht so viel Server die nach draußen verfügbar sind <10.
Und das nach einem "erfolgreichen" Test alles so funktioniert wie es soll im Produktiv-System, das steht auf einem anderen Blatt
Gruß
@clSchak
wir sind aktuell mit 2 Leuten bei ~ 120 Servern unterwegs, die "kritischen" Systeme sind alle in einer Testumgebung vorhanden (gleicher Patchstand, allerdings Leistungstechnisch in etwa 1/5 der primären Systeme). Das betrifft vor allem ERP mit der ECM Kopplung und andere Programme die an die ERP andocken, da reicht zum Teil schon .Net Update und irgend etwas funktioniert dann nicht usw.
Mit dem SP am SQL habe ich doch geschrieben, dass wir das auch mal auf die lange Bank schieben, auch aus den Gründen das diverse Programme sehr empfindlich auf so etwas reagieren. Bei den "internen" Systemen meine ich auch "intern" die können nicht ins Internet, Windows Update wird über WSUS verteilt und Patchmanagement der Applikationen wird über eine Appliance gemanaged.
Und bei den "08/15" Servern machen wir das wie du es geschildert hast über Veeam, dass geht im Regelfall recht zügig, wir haben nicht so viel Server die nach draußen verfügbar sind <10.
Und das nach einem "erfolgreichen" Test alles so funktioniert wie es soll im Produktiv-System, das steht auf einem anderen Blatt
Gruß
@clSchak
Servus,
@38873:
Genau dahin gehen auch meine Befürchtungen!
Irgendwann werden wohl die ganzen Server- und Client-OS nur noch als SaaS über eine wie auch immer geartete Cloud-Lösung angeboten, für die dann monatliche Gebühren fällig werden und der SysAdmin nicht mehr steuern kann, was im Hintergrund so abgeht...
Klar kommt dann wieder, dass dadurch personelle Resourcen für andere Zwecke frei werden oder sogar Personal eingespart werden kann.
Aber ob dadurch nicht alles für die User/Unternehmen alles teuerer wird??
Gruß
VGem-e
@38873:
Genau dahin gehen auch meine Befürchtungen!
Irgendwann werden wohl die ganzen Server- und Client-OS nur noch als SaaS über eine wie auch immer geartete Cloud-Lösung angeboten, für die dann monatliche Gebühren fällig werden und der SysAdmin nicht mehr steuern kann, was im Hintergrund so abgeht...
Klar kommt dann wieder, dass dadurch personelle Resourcen für andere Zwecke frei werden oder sogar Personal eingespart werden kann.
Aber ob dadurch nicht alles für die User/Unternehmen alles teuerer wird??
Gruß
VGem-e
@clSchak
Ach du meine Güte...hör mir bloß auf mit .net oder wcf Updates. da hatte ich vor kurzer erst eine Erfahrung machen müssen. Unglaublich was hier teilweise M$ für Dinge treibt.
@0815
Selbst bei größeren Bereitstellungen funktioniert die VEEAM LAB Lösung ganz gut. Allerdings...wie du schon sagtest -> Testen im LAB ist mit einem Produktivbetrieb natürlich überhaupt nicht vergleichbar. Dafür sorgt alleine schon Murphy...
Ach du meine Güte...hör mir bloß auf mit .net oder wcf Updates. da hatte ich vor kurzer erst eine Erfahrung machen müssen. Unglaublich was hier teilweise M$ für Dinge treibt.
@0815
Selbst bei größeren Bereitstellungen funktioniert die VEEAM LAB Lösung ganz gut. Allerdings...wie du schon sagtest -> Testen im LAB ist mit einem Produktivbetrieb natürlich überhaupt nicht vergleichbar. Dafür sorgt alleine schon Murphy...
Zitat von @VGem-e:
Servus,
@38873:
Genau dahin gehen auch meine Befürchtungen!
Irgendwann werden wohl die ganzen Server- und Client-OS nur noch als SaaS über eine wie auch immer geartete Cloud-Lösung angeboten, für die dann monatliche Gebühren fällig werden und der SysAdmin nicht mehr steuern kann, was im Hintergrund so abgeht...
Klar kommt dann wieder, dass dadurch personelle Resourcen für andere Zwecke frei werden oder sogar Personal eingespart werden kann.
Aber ob dadurch nicht alles für die User/Unternehmen alles teuerer wird??
Gruß
VGem-e
Servus,
@38873:
Genau dahin gehen auch meine Befürchtungen!
Irgendwann werden wohl die ganzen Server- und Client-OS nur noch als SaaS über eine wie auch immer geartete Cloud-Lösung angeboten, für die dann monatliche Gebühren fällig werden und der SysAdmin nicht mehr steuern kann, was im Hintergrund so abgeht...
Klar kommt dann wieder, dass dadurch personelle Resourcen für andere Zwecke frei werden oder sogar Personal eingespart werden kann.
Aber ob dadurch nicht alles für die User/Unternehmen alles teuerer wird??
Gruß
VGem-e
Grundlegend klingt die SAAS Variante wirklich nicht schlecht. Wenn ich alleine an die Herausforderungen denke, welche im Bereich Cybersicherheit, jedes IT-Biotop treffen werden. Das macht schon Ressourcen frei. Allerdings stellt sich dann schon die Frage --> Wie soll das mit all den verschiedenen Software Paketen funktionieren, welche auf den verschiedenen Windows Servern installiert sind?
Das einzige was ich mir in dem Kontext vorstellen könnte wäre, dass jeder Lösungsanbieter seine Software als SAAS zur Verfügung stellt und mit diversen Konnektoren an einem System wieder zusammenläuft und von dort zur Verfügung gestellt wird. Ob dass dann allerdings "einfacher" wird, wage ich zum jetzigen Zeitpunkt noch zu bezweifeln
.Sind jedoch bei einem WSUS Server pro Standort geblieben, weil es die für uns beste Lösung ist. Wo siehst du den Mehrwert bei dieser Variante?
Ich muss die Patches "nur" auf einem Server freigeben. Klingt jetzt zwar etwas doof (me culpa!), aber letztendlich ist es ein "ziemlich leidiges Thema" und da möchte man sich den Aufwand halt so gering wie möglich halten. Wenn man die Updates nur auf einem WSUS freigeben muss, steigt die Warscheinlichkeit, dass es "irgendwann auch mal jemand ab und zu tut"
