Windows Updates auf 2008 R2 und 2012 R2
Hallo,
bin neu hier und möchte erstmal alle grüßen
Jetzt zu meiner Frage.
Hat jemand von euch eine Idee/Lösung, wie man einen Haufen 2008 R2 und einen Haufen 2012 R2 Terminalserver remote updaten kann?
Von einem der Terminalserver oder einem Mgmt Server z.B.
Wenn ein Microsoft Produkt oder ähnliches bekannt ist, wäre das natürlich die beste Lösung.
Als letzte Lösung würde ich auf auf eine Drittanbietersoftware zurückgreifen.
Wichtig wäre:
Wir haben einen Kunden, bei dem schon fast 70 Server upzudaten sind und kriegen das ganz knapp in einem 3h Wartungsfenster hin.
Somit müssen wir schaun wie wir das kontrolliert, automatisieren können.
Vielen Dank und lg
bin neu hier und möchte erstmal alle grüßen
Jetzt zu meiner Frage.
Hat jemand von euch eine Idee/Lösung, wie man einen Haufen 2008 R2 und einen Haufen 2012 R2 Terminalserver remote updaten kann?
Von einem der Terminalserver oder einem Mgmt Server z.B.
Wenn ein Microsoft Produkt oder ähnliches bekannt ist, wäre das natürlich die beste Lösung.
Als letzte Lösung würde ich auf auf eine Drittanbietersoftware zurückgreifen.
Wichtig wäre:
- eine Liste der Server
- Ein Balken, wie weit die Updates gerade sind
- Vielleicht auch welche Pakete er runterladet.
Wir haben einen Kunden, bei dem schon fast 70 Server upzudaten sind und kriegen das ganz knapp in einem 3h Wartungsfenster hin.
Somit müssen wir schaun wie wir das kontrolliert, automatisieren können.
Vielen Dank und lg
Kommentieren
Teilen
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: 380605
Url: https://administrator.de/forum/windows-updates-auf-2008-r2-und-2012-r2-380605.html
Ausgedruckt am: 19.05.2025 um 11:05 Uhr
6 Kommentare
Neuester Kommentar
Hi,
WSUS halt Ansonsten Client-Management á la OPSI einführen.
WSUS halt
Ansonsten Client-Management á la OPSI einführen.
Moin,
was hast du gegen nen WSUS Server und entsprechenden Updaterichtlinien?
Es macht nicht wirklich Sinn die Bandbreite des Kunden zu schreddern, wenn 70 Server die selben Daten runterladen.
Der WSUS lädt die Daten runter und zeigt Dir auch an wie weit er ist.
Gruß, V
was hast du gegen nen WSUS Server und entsprechenden Updaterichtlinien?
Es macht nicht wirklich Sinn die Bandbreite des Kunden zu schreddern, wenn 70 Server die selben Daten runterladen.
Der WSUS lädt die Daten runter und zeigt Dir auch an wie weit er ist.
Gruß, V
Wir haben einen WSUS im Einsatz.
Der WSUS stellt die Updates bereit.
Trotzdem muss jemand direkt auf den Servern kontrollieren ob z.B.:
Sorry, hab vergessen dazuzuschreiben, dass auch einige DC, DHCP, DB, usw usw Server dabei sind.
Es nicht NUR Terminalserver.
Generell suche ich nach einer Lösung wie ich das von einem Ort managen kann.
Ich wüsste nicht, dass der WSUS das kann.
Hoffe es ist irgendwie verständlich.
Der WSUS stellt die Updates bereit.
Trotzdem muss jemand direkt auf den Servern kontrollieren ob z.B.:
- in diesem Update vielleicht Patch ist, von dem man weis dass dieser Bugs verursacht.
- Exchange Updates sind, die man noch nicht installieren möchte
- SQL Updates sind, die man noch nicht installieren möchte.
- Server kontrolliert neustarten. (Nicht alle DC gleichzeitig, nicht die DB Server gleichzeitig, usw)
- usw
Sorry, hab vergessen dazuzuschreiben, dass auch einige DC, DHCP, DB, usw usw Server dabei sind.
Es nicht NUR Terminalserver.
Generell suche ich nach einer Lösung wie ich das von einem Ort managen kann.
Ich wüsste nicht, dass der WSUS das kann.
Hoffe es ist irgendwie verständlich.
Is doch ein Anfang
Ist es. Aber bitte erwarte nicht, dass irgendeine andere Software Dir das Denken abnimmt. Natürlich musst du per Hand entscheiden, welche Updates du freigeben willst. Dafür kann man die Server aber in OU und Gruppen einteilen, um DC und Exchange beispielsweise später zu updaten und erstmal nur die "unwichtigen" Systeme zu patchen.
Da steckt ein wenig Planung und Denksport hinter.
Gruß, V
Der WSUS stellt die Updates bereit.
So solls auch sein, bei der Menge an ServernTrotzdem muss jemand direkt auf den Servern kontrollieren ob z.B.:
Wer soll Dir das denken dafür denn abnehmen?* in diesem Update vielleicht Patch ist, von dem man weis dass dieser Bugs verursacht.
Das ist auch bei jedem anderen Update-Management so. Die Bugs macht der Hersteller. Die kennt die Software nicht.* Exchange Updates sind, die man noch nicht installieren möchte
Und das soll die Software automatisch woher wissen?- SQL Updates sind, die man noch nicht installieren möchte.
* Server kontrolliert neustarten. (Nicht alle DC gleichzeitig, nicht die DB Server gleichzeitig, usw)
Das kann man alles per Richtlinien und etwas Powershell steuern- usw
Sorry, hab vergessen dazuzuschreiben, dass auch einige DC, DHCP, DB, usw usw Server dabei sind.
Es nicht NUR Terminalserver.
Ja und?Es nicht NUR Terminalserver.
Generell suche ich nach einer Lösung wie ich das von einem Ort managen kann.
Es bleibt beim WSUSIch wüsste nicht, dass der WSUS das kann.
Warum sollte der das nicht können?Hoffe es ist irgendwie verständlich.
Ist es. Aber bitte erwarte nicht, dass irgendeine andere Software Dir das Denken abnimmt. Natürlich musst du per Hand entscheiden, welche Updates du freigeben willst. Dafür kann man die Server aber in OU und Gruppen einteilen, um DC und Exchange beispielsweise später zu updaten und erstmal nur die "unwichtigen" Systeme zu patchen.
Da steckt ein wenig Planung und Denksport hinter.
Gruß, V
1in diesem Update vielleicht Patch ist, von dem man weis dass dieser Bugs verursacht.
Das hat ja mit WSUS nichts zu tun. Dass man bei großen Unternehmen die Patches erstmal in einen Testlauf gibt, ist nichts unnormales, bzw. sollte selbstverständlich sein, um Bugs auszuschließen.Proaktiv kannst du einstellen, dass der WSUS nicht direkt am Patchday, sondern erst 8-10 Tage später syncen soll.
Exchange Updates sind, die man noch nicht installieren möchte
SQL Updates sind, die man noch nicht installieren möchte
Siehe oben, Updates verzögern und testen.SQL Updates sind, die man noch nicht installieren möchte
Server kontrolliert neustarten. (Nicht alle DC gleichzeitig, nicht die DB Server gleichzeitig, usw)
Das konfigurierst du via GPO.1
Hi
Was möchtest du ausgeben?
Einige deiner Anforderungen kann man mit der MS System Center Suite abdecken.
Im SCCM kannst du Wartungsfenster definieren wann die Updates installiert werden dürfen.
Mit Collections kannst du das auf einzelne Servergruppen anwenden.
Relativ zweitgenaues Logging wie weit sie Server sind oder ob Fehler aufgetreten sind.
Im Softwarecenter siehst du die Updates die verteilt werden.
Andere Softwarepakete kannst du damit dann auch gleich auf dem aktuellen Stand halten.
Server Bereitstellung mittels Tasksequence aus einheitlichem aktualisiertem Image ebenfalls.
Kostet dich halt die Server und Clientlizenzen und die Einarbeitung welche du nicht unterschätzen solltest.
Wenn du dann noch mehr Infos brauchst oder halt bessere Echtzeitüberwachung dann noch den
System Center Operations Manager SCOM einsetzen.
Ist alles eine Frage des Geldes.
Mit freundlichen Grüßen Nemesis
Was möchtest du ausgeben?
Einige deiner Anforderungen kann man mit der MS System Center Suite abdecken.
Im SCCM kannst du Wartungsfenster definieren wann die Updates installiert werden dürfen.
Mit Collections kannst du das auf einzelne Servergruppen anwenden.
Relativ zweitgenaues Logging wie weit sie Server sind oder ob Fehler aufgetreten sind.
Im Softwarecenter siehst du die Updates die verteilt werden.
Andere Softwarepakete kannst du damit dann auch gleich auf dem aktuellen Stand halten.
Server Bereitstellung mittels Tasksequence aus einheitlichem aktualisiertem Image ebenfalls.
Kostet dich halt die Server und Clientlizenzen und die Einarbeitung welche du nicht unterschätzen solltest.
Wenn du dann noch mehr Infos brauchst oder halt bessere Echtzeitüberwachung dann noch den
System Center Operations Manager SCOM einsetzen.
Ist alles eine Frage des Geldes.
Mit freundlichen Grüßen Nemesis
