14
WSUS - Sicherheitsupdates ohne Testlauf verteilen ?
Hallo,
bin dabei einen WSUS zu konzipieren und mich würden dritte Meinungen interessieren.
Frage:
Macht es Sinn Sicherheitsupdates (nur diese, keine Updates oder wichtigen Updates etc.) automatisch für Clients bzw. Server
genehmigen zu lassen OHNE diese vorher in einer Pilot-Gruppe testen zu lassen ? Wenn ja, was wäre die Begründung ? Ich tendiere momentan dazu dies so zu machen.
Hintergrund:
Würden Sicherheitsupdates sofort genehmigt werden, wären die Clients damit immer up2date versorgt und es würden keine Sicherheitsrisiken in dieser Hinsicht entstehen.
Greifen denn Sicherheitsupdates so tief ins System ein, dass ein vorheriger Testlauf absolut begründet wäre ?
Bin gespannt was Ihr so sagt.
VG,
Thorschten
bin dabei einen WSUS zu konzipieren und mich würden dritte Meinungen interessieren.
Frage:
Macht es Sinn Sicherheitsupdates (nur diese, keine Updates oder wichtigen Updates etc.) automatisch für Clients bzw. Server
genehmigen zu lassen OHNE diese vorher in einer Pilot-Gruppe testen zu lassen ? Wenn ja, was wäre die Begründung ? Ich tendiere momentan dazu dies so zu machen.
Hintergrund:
Würden Sicherheitsupdates sofort genehmigt werden, wären die Clients damit immer up2date versorgt und es würden keine Sicherheitsrisiken in dieser Hinsicht entstehen.
Greifen denn Sicherheitsupdates so tief ins System ein, dass ein vorheriger Testlauf absolut begründet wäre ?
Bin gespannt was Ihr so sagt.
VG,
Thorschten
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 164953
Url: https://administrator.de/contentid/164953
Printed on: April 19, 2024 at 10:04 o'clock
14 Comments
Latest comment
Hi Thorsten,
schon alleine der Zeitaufwand um hinterher die möglichen Scherben zu beseitgen (natürlich abhängig von der Clientanzahl) wäre uns zu Schade.
Des Weiteren steht bei solchen Ausfällen meistens der Teamleiter auf der Matte und will wissen was los ist. Ich sag mal: 1x kann passieren, das 2. auch noch aber beim 3. Mal wirds peinlich.
Ist auch für den Ruf der IT-Abteilung(en) nicht förderlich.
Grüße,
Dani
schon alleine der Zeitaufwand um hinterher die möglichen Scherben zu beseitgen (natürlich abhängig von der Clientanzahl) wäre uns zu Schade.
Des Weiteren steht bei solchen Ausfällen meistens der Teamleiter auf der Matte und will wissen was los ist. Ich sag mal: 1x kann passieren, das 2. auch noch aber beim 3. Mal wirds peinlich.
Ist auch für den Ruf der IT-Abteilung(en) nicht förderlich.
Grüße,
Dani
Gab es denn schon mal in der Vergangenheit Sicherupdates welche die Produktivität von Clients beeinträchtigt haben ?
Bis jetzt konnte ich zu dieser Fragestellung nichts finden, auch nicht im englischen WSUS-Blog im Technet
Bis jetzt konnte ich zu dieser Fragestellung nichts finden, auch nicht im englischen WSUS-Blog im Technet
Hallo @thorschten,
ein aktueller Sicherheitspatch für MS Office PowerPoint 2003 nimmt zum Beispiel viele Präsentationen auseinander.
Das SP1 von Win7 kann unter Umständen zu einem endlosen Bootvorgang führen.
Verschiedene Vista-Patches enden auch in einer endlosen Boot-Restart-Schleife.
gruß
Snow
Gab es denn schon mal in der Vergangenheit Sicherupdates welche die Produktivität von Clients beeinträchtigt haben ?
Da gibts gerade genug!ein aktueller Sicherheitspatch für MS Office PowerPoint 2003 nimmt zum Beispiel viele Präsentationen auseinander.
Das SP1 von Win7 kann unter Umständen zu einem endlosen Bootvorgang führen.
Verschiedene Vista-Patches enden auch in einer endlosen Boot-Restart-Schleife.
gruß
Snow
Da gab/gibt es genug... ich glaub da kann hier fast jeder ein Lied singen.
Grüße,
Dani
- WindowsXP SP3 hat z.B. viele Seriennummern als ungültig abgestemmpelt obwohl es ein Volumekey war.
- Windows 7 SP1 in einer Domäne verursacht einen endlosen Bootvorgang.
Grüße,
Dani
Hi Thorsten,
wir haben mal 2 Jahren alle Sicherheits-Updates vor dem Rollout intensiv getestet und hatten kein einziges Problem.
Deswegen haben wir die Tests verringert:
Mittlerweile installieren wir die Updates auf 2-3 Testmaschinen (XP), gucken ob die booten und gut ist.
Bisher hat das gut geklappt.
Bei Servern updaten wir erst mal die unkritischen, bzw. die virtuellen die zuvor gesichert worden.
Klappt auch fast immer ganz gut.
Das fast:
Bei dem Server 2008 R2 SP1 Update ist von gut 30 Server ausgerechnet ein DC/Fileserver gekracht
Sonst liefen alle 100% auch 3 weitere DCs, dieses hätten wir auch bei Tests nicht gemerkt.
Also, ich persönlich muss Microsoft hier mal zugute halten, das zumindest die Sicherheitsupdates zu 99,9% funktionieren und wenn dann nur einzelne Rechner Probleme damit haben.
VG
Deepsys
wir haben mal 2 Jahren alle Sicherheits-Updates vor dem Rollout intensiv getestet und hatten kein einziges Problem.
Deswegen haben wir die Tests verringert:
Mittlerweile installieren wir die Updates auf 2-3 Testmaschinen (XP), gucken ob die booten und gut ist.
Bisher hat das gut geklappt.
Bei Servern updaten wir erst mal die unkritischen, bzw. die virtuellen die zuvor gesichert worden.
Klappt auch fast immer ganz gut.
Das fast:
Bei dem Server 2008 R2 SP1 Update ist von gut 30 Server ausgerechnet ein DC/Fileserver gekracht
Sonst liefen alle 100% auch 3 weitere DCs, dieses hätten wir auch bei Tests nicht gemerkt.
Also, ich persönlich muss Microsoft hier mal zugute halten, das zumindest die Sicherheitsupdates zu 99,9% funktionieren und wenn dann nur einzelne Rechner Probleme damit haben.
VG
Deepsys
Da kann nicht nicht zustimmen, bei uns ist das nicht aufgetreten.
Allerdings haben wir zwar >240 XP-Kisten, aber nur 10 Win 7 Kisten
Allerdings gebe ich euch Recht, ServicePacks, Rollup-Updates ... sollten man vorher besser wirklich gut testen.
Bei den monatlichen Sicherheitsupdates bin ich der Meinung reicht ein kurzer Test
VG
Deepsys
Danke für Eure Beiträge. Gibt es denn sowas wie eine Auflistung oder eine empfehlenswerte Website wo man solche dokumentierten Fälle finden kann ? Ich schaue bislang hauptsächlich bei heise security rein.
Es wäre für mich eine greifbare Basis für eine Begründung gegenüber Dritten Sicherheitsupdates nicht automatisch zu genehmigen
Es wäre für mich eine greifbare Basis für eine Begründung gegenüber Dritten Sicherheitsupdates nicht automatisch zu genehmigen
Moin,
ein relativ gutes Forum sich mal einige Erfahrungen anzusehen findet sich hier:
http://www.windows-7-forum.net/windows-7-updates-patches/
Gruß
Peter
ein relativ gutes Forum sich mal einige Erfahrungen anzusehen findet sich hier:
http://www.windows-7-forum.net/windows-7-updates-patches/
Gruß
Peter
Hi. Hier auch meine Erfahrungen von etwa 7 oder 8 Jahren WSUS:
Wir testen Patches immer auf den Adminrechnern und zwei weiteren Test-PCs und rollen sie dann eine Woche später aus.
So lange wir Windows 2000 fuhren, hatten wir in 4 Jahren bei 80 Systemen einen Totalschaden (bootet nicht) und ein, zweimal, dass MS Office kaputt gepatcht wurde. Ein weiteres Mal war ein Patch inkompatibel zu einer Fortran-Anwendung (Uralt-Software), abgesehen davon alles 1a, wir hatten schon überlegt, das Testen sein zu lassen - denn was sind bitte 3 oder 4 Fälle auf 80x12x4xca. 5 Patches - lächerlich. Man muss dazu noch sagen, dass die Probleme NIE reproduzierbar waren... den selben Patch auf der restaurierten Maschine erneut eingespielt - kein Problem dabei.
Dann kam Vista und die Probleme stiegen leicht an: etwa 1 Totalausfall pro Jahr, Probleme bei Office und weiterer MS Software blieben nahezu bei Null. Dann verschlüsselten wir nach 2 Jahren Vista mit PGP - und die Hölle brach herein.
Obwohl PGP für das OS transparent arbeitet und es theoretisch keinen Unterschied machen sollte, geht seitdem bei JEDEM Patchday irgendwas in die Hose (selbstverständlich ist PGP in der neuesten Version drauf und der Support sieht keinen Sinnzusammenhang) - hier ein Totalausfall, da ein Office platt, dort ein Dotnet vergurkt... es nervt.
Aber: nie auf den Testsystemen - noch nie! Weder vor, noch nach PGP. Was hat uns das Testen bislang gebracht? Gar nichts. Was hat es uns an Aufwand gekostet - fast nichts (nun ja, ich hab jede Woche auch bei Heise nach Warnmeldungen geschaut - nie hat uns eine betroffen, sofern überhaupt mal eine kam).
Deswegen mache ich es weiter.
Weitaus wichtiger für Dich sollte jedoch ein Konzept für den Fall der Fälle sein, zum Beispiel Images bereit zu halten, die schnell eingespielt werden können. Das möchte ich Dir ans Herz legen.
Wir testen Patches immer auf den Adminrechnern und zwei weiteren Test-PCs und rollen sie dann eine Woche später aus.
So lange wir Windows 2000 fuhren, hatten wir in 4 Jahren bei 80 Systemen einen Totalschaden (bootet nicht) und ein, zweimal, dass MS Office kaputt gepatcht wurde. Ein weiteres Mal war ein Patch inkompatibel zu einer Fortran-Anwendung (Uralt-Software), abgesehen davon alles 1a, wir hatten schon überlegt, das Testen sein zu lassen - denn was sind bitte 3 oder 4 Fälle auf 80x12x4xca. 5 Patches - lächerlich. Man muss dazu noch sagen, dass die Probleme NIE reproduzierbar waren... den selben Patch auf der restaurierten Maschine erneut eingespielt - kein Problem dabei.
Dann kam Vista und die Probleme stiegen leicht an: etwa 1 Totalausfall pro Jahr, Probleme bei Office und weiterer MS Software blieben nahezu bei Null. Dann verschlüsselten wir nach 2 Jahren Vista mit PGP - und die Hölle brach herein.
Obwohl PGP für das OS transparent arbeitet und es theoretisch keinen Unterschied machen sollte, geht seitdem bei JEDEM Patchday irgendwas in die Hose (selbstverständlich ist PGP in der neuesten Version drauf und der Support sieht keinen Sinnzusammenhang) - hier ein Totalausfall, da ein Office platt, dort ein Dotnet vergurkt... es nervt.
Aber: nie auf den Testsystemen - noch nie! Weder vor, noch nach PGP. Was hat uns das Testen bislang gebracht? Gar nichts. Was hat es uns an Aufwand gekostet - fast nichts (nun ja, ich hab jede Woche auch bei Heise nach Warnmeldungen geschaut - nie hat uns eine betroffen, sofern überhaupt mal eine kam).
Deswegen mache ich es weiter.
Weitaus wichtiger für Dich sollte jedoch ein Konzept für den Fall der Fälle sein, zum Beispiel Images bereit zu halten, die schnell eingespielt werden können. Das möchte ich Dir ans Herz legen.
@dww
Hi,
eine gute Seite mit Informationen zu Updates und Fehlern beim Updaten ist auch http://patch-info.de/categories/25-Windows-7
Gegen Vista hat Freudi allerdings was.
Gruß
Hi,
eine gute Seite mit Informationen zu Updates und Fehlern beim Updaten ist auch http://patch-info.de/categories/25-Windows-7
Gegen Vista hat Freudi allerdings was.
Gruß
Ja danke... nach 8 Jahren WSUS-Administration kenne ich diese Seite jedoch schon etwas länger.
"Was hat uns das Testen bislang gebracht? Gar nichts. Was hat es uns an Aufwand gekostet - fast nichts. "
Ich denke trifft es ganz gut um einen kompletten Testlauf zu untermauern.
Wie macht Ihr es mit Servern ? Updates herunterladen und dann per Hand installieren ? Ich habe in meiner Testumgebung die Erfahrung gemacht, dass die Server-Systeme neustarten obwohl es per Policy verboten war.
Ich kam dann aber drauf als ich die Beschreibung der Policy genauer las, da heißt es: ......"wenn niemand ANGEMELDET ist, neustart nach Updates unterdrücken"....und am Testserver war ja niemand angemeldet bzw. im gesperrten Zustand.
Somit würde es heißen, dass Server, wenn Updates zum automatischen Zeitpunkt installiert werden, der Neustarz nicht unterdrückt werden könnte.
Ich denke trifft es ganz gut um einen kompletten Testlauf zu untermauern.
Wie macht Ihr es mit Servern ? Updates herunterladen und dann per Hand installieren ? Ich habe in meiner Testumgebung die Erfahrung gemacht, dass die Server-Systeme neustarten obwohl es per Policy verboten war.
Ich kam dann aber drauf als ich die Beschreibung der Policy genauer las, da heißt es: ......"wenn niemand ANGEMELDET ist, neustart nach Updates unterdrücken"....und am Testserver war ja niemand angemeldet bzw. im gesperrten Zustand.
Somit würde es heißen, dass Server, wenn Updates zum automatischen Zeitpunkt installiert werden, der Neustarz nicht unterdrückt werden könnte.
Server werden nicht getestet. Bei werden aber auch die Backups wesentlich häufiger angefertigt und es ist fraglich, inwieweit die extra getestet werden müssten (z.B. das SP für Vista/Win7 und 2008/2008 R2 ist identisch). Hatte noch nie einen totgepatchten Server.
Wegen Neustarts - die Policies funktionieren wie sie sollen. Gesperrt heißt angemeldet - da darf nichts automatisch runterfahren, wenn anders eingestellt.
Normal wäre, die Server nachts neustarten zu lassen.
Wegen Neustarts - die Policies funktionieren wie sie sollen. Gesperrt heißt angemeldet - da darf nichts automatisch runterfahren, wenn anders eingestellt.
Normal wäre, die Server nachts neustarten zu lassen.
@thorschten,
Ganz einfach... wir machen vor einem SP/Patchday einen Snapshot über Netapp VIClient. Sollte etwas nicht passen wird einfach der Snapshot zurückgespielt und innerhalb 4 Minuten ist der Server wieder online. Das ist einer der Vorteile von Virtualisierung. Automatisch wird bei uns auf den Servern gar nichts installiert. Da die Applikationen auf den Server nicht immer so angetan von den Veränderungen am System sind.
Ganz einfach... wir machen vor einem SP/Patchday einen Snapshot über Netapp VIClient. Sollte etwas nicht passen wird einfach der Snapshot zurückgespielt und innerhalb 4 Minuten ist der Server wieder online. Das ist einer der Vorteile von Virtualisierung. Automatisch wird bei uns auf den Servern gar nichts installiert. Da die Applikationen auf den Server nicht immer so angetan von den Veränderungen am System sind.
