6
Aufbau Patchmanagement
Hallo zusammen,
ich plane gerade den Aufbau einer neuen Umgebung, um Software und MS Patches auf ca. 600 Win7 Systemen auszurollen.
Primär geht es darum, die Windows Systeme regelmäßig und sauber zu patchen.
Es soll jedoch auch möglich sein, Software-Pakete zu verteilen.
Die MS Updates sollen dabei jedoch nicht automatisch installiert werden.
Stattdessen soll es in unregelmäßigen Abständen einen Patchday geben.
An diesem Tag erscheint auf allen Systemen ein Fenster, welches bestätigt werden muss, damit alle ausstehenden Updates installieren.
Im Idealfall werden die Pakte bereits zuvor von dem System heruntergeladen und liegen bereits lokal vor.
Ziel ist natürlich, nicht ständig die Windows Updates in SCCM neu paketieren zu müssen.
Ich hatte hierfür an eine 2012er Umgebung mit SCCM und WSUS gedacht.
Der WSUS hält die Updates und gibt nur die gewünschten Patches frei.
Der SCCM könnte sich dann um die Software-Pakete kümmern.
Am Patchday startet ein SCCM Paket, welches die Frage stellt und dann über wuauclt.exe die Windows Updates startet.
Da ich mit WSUS und SCCM 2012 nicht wirklich fit bin, muss ich mich erst noch in das Thema einarbeiten.
Meine Frage ist nun, ob diese Überlegung Sinn macht, oder ob es bessere Methoden gibt.
Danke.
ich plane gerade den Aufbau einer neuen Umgebung, um Software und MS Patches auf ca. 600 Win7 Systemen auszurollen.
Primär geht es darum, die Windows Systeme regelmäßig und sauber zu patchen.
Es soll jedoch auch möglich sein, Software-Pakete zu verteilen.
Die MS Updates sollen dabei jedoch nicht automatisch installiert werden.
Stattdessen soll es in unregelmäßigen Abständen einen Patchday geben.
An diesem Tag erscheint auf allen Systemen ein Fenster, welches bestätigt werden muss, damit alle ausstehenden Updates installieren.
Im Idealfall werden die Pakte bereits zuvor von dem System heruntergeladen und liegen bereits lokal vor.
Ziel ist natürlich, nicht ständig die Windows Updates in SCCM neu paketieren zu müssen.
Ich hatte hierfür an eine 2012er Umgebung mit SCCM und WSUS gedacht.
Der WSUS hält die Updates und gibt nur die gewünschten Patches frei.
Der SCCM könnte sich dann um die Software-Pakete kümmern.
Am Patchday startet ein SCCM Paket, welches die Frage stellt und dann über wuauclt.exe die Windows Updates startet.
Da ich mit WSUS und SCCM 2012 nicht wirklich fit bin, muss ich mich erst noch in das Thema einarbeiten.
Meine Frage ist nun, ob diese Überlegung Sinn macht, oder ob es bessere Methoden gibt.
Danke.
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: 258859
Url: https://administrator.de/contentid/258859
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
6 Kommentare
Neuester Kommentar
Moin.
Wieso neu paketieren?
Ob du nun in der SCCM-Console die Updates freigibst oder in der WSUS-Console ist doch gehüpft wie gesprungen.
Per SCCM kannst du wesentlich intelligenter steuern, wann welche Rechner welche Pakete bekommen und noch dazu, ob diese "required" oder "available" sind - du bist also mit SCCM schon auf dem richtigen Weg, zumal da ja noch deutlich mehr mit geht....
Cheers,
jsysde
P.S.:
Wie viele Standorte hast du denn?
Zitat von @quin83:
Im Idealfall werden die Pakte bereits zuvor von dem System heruntergeladen und liegen bereits lokal vor.
Ziel ist natürlich, nicht ständig die Windows Updates in SCCM neu paketieren zu müssen.
Im Idealfall werden die Pakte bereits zuvor von dem System heruntergeladen und liegen bereits lokal vor.
Ziel ist natürlich, nicht ständig die Windows Updates in SCCM neu paketieren zu müssen.
Wieso neu paketieren?
Ob du nun in der SCCM-Console die Updates freigibst oder in der WSUS-Console ist doch gehüpft wie gesprungen.
Per SCCM kannst du wesentlich intelligenter steuern, wann welche Rechner welche Pakete bekommen und noch dazu, ob diese "required" oder "available" sind - du bist also mit SCCM schon auf dem richtigen Weg, zumal da ja noch deutlich mehr mit geht....
Cheers,
jsysde
P.S.:
Wie viele Standorte hast du denn?
Hi,
Siehe z.B. http://www.heise.de/security/meldung/Microsoft-Neues-Zertifikats-Update ...
Man kann also entweder die Sicherheitslücke offen lassen, oder man bastelt ein Paket, das mit den Bugs in den Updates klar kommt.
Ich brauche nur eine Lösung, welche diese User-Interaktion ermöglicht, damit die Updates nur am Patchday und nur "unter Aufsicht" installieren.
Wieso neu paketieren?
Weil Microsoft Updates der letzte Crap sind. Besonders in letzter Zeit.Siehe z.B. http://www.heise.de/security/meldung/Microsoft-Neues-Zertifikats-Update ...
Man kann also entweder die Sicherheitslücke offen lassen, oder man bastelt ein Paket, das mit den Bugs in den Updates klar kommt.
Ob du nun in der SCCM-Console die Updates freigibst oder in der WSUS-Console ist doch gehüpft wie gesprungen.
Richtig, wo die Updates freigegeben werden, ist eigentlich egal.Ich brauche nur eine Lösung, welche diese User-Interaktion ermöglicht, damit die Updates nur am Patchday und nur "unter Aufsicht" installieren.
Per SCCM kannst du wesentlich intelligenter steuern, wann welche Rechner welche Pakete bekommen und noch dazu, ob diese
"required" oder "available" sind - du bist also mit SCCM schon auf dem richtigen Weg, zumal da ja noch
deutlich mehr mit geht....
Also dass WSUS allein nicht ausreicht, ist mir klar. SCCM ist definitiv gesetzt."required" oder "available" sind - du bist also mit SCCM schon auf dem richtigen Weg, zumal da ja noch
deutlich mehr mit geht....
Wie viele Standorte hast du denn?
4
N'Abend.
Und was hat das mit SCCM zu tun?
Ich lasse die Updates seit einiger Zeit auch erst mal mind. eine Woche "reifen" und beobachte die üblichen Quellen im Netz, ob Probleme damit auftreten/bekannt sind. Davon abgesehen sollte man alles, was man über Software XYZ an seine Clients ausrollt, vorher in einer Testumgebung testen (das können ja durchaus VMs sein oder ein, zwei ausgewählte Kollegenrechner).
Update Rollups für Exchange oder Service Packs für SQL installiere ich sowieso immer "per Hand", da würde ich mich auf keine wie auch immer geartete automatische Verteilung verlassen (wollen). Für meine Clients hingegen bin ich mehr als dankbar, wenn die Updates einfach nur an einer Stelle genehmigt und ausgerollt werden müssen und die Installation als solche dann eben automatisiert durchgeführt wird. Letztlich entscheide _ich!_, welche Updates ich da ausrolle....
Bei vier Standorten solltest du auf ne CAS verzichten und nur ne Primary Site einrichten mit DPs an den Remotestandorten.
Cheers,
jsysde
Und was hat das mit SCCM zu tun?
Ich lasse die Updates seit einiger Zeit auch erst mal mind. eine Woche "reifen" und beobachte die üblichen Quellen im Netz, ob Probleme damit auftreten/bekannt sind. Davon abgesehen sollte man alles, was man über Software XYZ an seine Clients ausrollt, vorher in einer Testumgebung testen (das können ja durchaus VMs sein oder ein, zwei ausgewählte Kollegenrechner).
Update Rollups für Exchange oder Service Packs für SQL installiere ich sowieso immer "per Hand", da würde ich mich auf keine wie auch immer geartete automatische Verteilung verlassen (wollen). Für meine Clients hingegen bin ich mehr als dankbar, wenn die Updates einfach nur an einer Stelle genehmigt und ausgerollt werden müssen und die Installation als solche dann eben automatisiert durchgeführt wird. Letztlich entscheide _ich!_, welche Updates ich da ausrolle....
Ich brauche nur eine Lösung, welche diese User-Interaktion ermöglicht, damit die Updates nur am Patchday und nur
"unter Aufsicht" installieren.
Das klappt per SCCM ganz hervorragend - wobei ich das bei 600 Rechnern als nicht machbar bezeichnen würde, hier _muss!_ eine automatisierte Lösung her => weiterer Punkt _für!_ SCCM."unter Aufsicht" installieren.
Bei vier Standorten solltest du auf ne CAS verzichten und nur ne Primary Site einrichten mit DPs an den Remotestandorten.
Cheers,
jsysde
Hi,
für Software außerhalb Windows Updates wäre evtl. noch Dell KACE etwas.
Gruß
für Software außerhalb Windows Updates wäre evtl. noch Dell KACE etwas.
Gruß
Hallo,
Allerdings konnte ich bisher keine Möglichkeit finden, die Updates nur nach vorheriger Freigabe durch den User auszurollen.
Übersehe ich was?
Ich habe mir z.B. folgendes Video angeschaut, welches das Deployment zeigt:
https://www.youtube.com/watch?v=4XmN189nbMc&t=4m24s
Dort gibt es viele Optionen, um ein Update automatisch zu installieren. Man kann auch Wartungsfenster & Co definieren.
Das ist aber eben genau nicht die Anforderung. Ohne Erlaubnis des Anwenders, soll keine Änderung erfolgen.
Gibt es eine Möglichkeit, den Anwender um Erlaubnis fragen, bevor irgend ein Update installiert wird?
Wenn das so stimmt stellt sich mir die Frage, ob man an jedem Standort einen Distribution Point braucht.
Ich hätte dicke Filer an jedem Standort, welche eigentlich deutlich besser mit dem Netzwerk-Traffic klar kommen, als ein einzelner Server.
Die Überlegung wäre, nur einen zentralen Distribution Point zu verwenden und die Clients zu den Filern zu schicken.
Oder spricht da was dagegen?
> Ich brauche nur eine Lösung, welche diese User-Interaktion ermöglicht, damit die Updates nur am Patchday und nur
> "unter Aufsicht" installieren.
Das klappt per SCCM ganz hervorragend - [...]
Ich habe mir zu SCCM 2012 einige Dinge anschaut.> "unter Aufsicht" installieren.
Das klappt per SCCM ganz hervorragend - [...]
Allerdings konnte ich bisher keine Möglichkeit finden, die Updates nur nach vorheriger Freigabe durch den User auszurollen.
Übersehe ich was?
Ich habe mir z.B. folgendes Video angeschaut, welches das Deployment zeigt:
https://www.youtube.com/watch?v=4XmN189nbMc&t=4m24s
Dort gibt es viele Optionen, um ein Update automatisch zu installieren. Man kann auch Wartungsfenster & Co definieren.
Das ist aber eben genau nicht die Anforderung. Ohne Erlaubnis des Anwenders, soll keine Änderung erfolgen.
Gibt es eine Möglichkeit, den Anwender um Erlaubnis fragen, bevor irgend ein Update installiert wird?
Bei vier Standorten solltest du auf ne CAS verzichten und nur ne Primary Site einrichten mit DPs an den Remotestandorten.
So wie ich SCCM verstehe, verweist ein Distribution Point ja lediglich auf ein Netzwerk-Share, welches die Updates enthält.Wenn das so stimmt stellt sich mir die Frage, ob man an jedem Standort einen Distribution Point braucht.
Ich hätte dicke Filer an jedem Standort, welche eigentlich deutlich besser mit dem Netzwerk-Traffic klar kommen, als ein einzelner Server.
Die Überlegung wäre, nur einen zentralen Distribution Point zu verwenden und die Clients zu den Filern zu schicken.
Oder spricht da was dagegen?
Moin.
Aber wie ich schon geschrieben habe, halte ich das für keine gute Idee/kein praktikables Szenario - ich kenne jedenfalls keinen User, der freiwillig Updates installieren würde, daher habe ich als Admin gern den Finger am Abzug und lege eben fest, wann die Updates installiert werden.
Zumal auch die Möglichkeit, den User selbst entscheiden zu lassen, wann ein Update installiert wird, dir das Testen der Updates nicht erspart - ein kaputtes Updates ist ein kaputtes Update, ob es nun automatisiert installiert wird oder der User die Installation anstossen muss. Daher halte ich dein Vorhaben, die Update-Installation den Usern zu überlassen, nach wie vor wie reichlich sinnfrei und nicht praktikabel.
Cheers,
jsysde
Zitat von @quin83:
Allerdings konnte ich bisher keine Möglichkeit finden, die Updates nur nach vorheriger Freigabe durch den User auszurollen.
Übersehe ich was?
Gibt es eine Möglichkeit, den Anwender um Erlaubnis fragen, bevor irgend ein Update installiert wird?
Klar - Deployment auf "Available" statt auf "Required" stellen.Allerdings konnte ich bisher keine Möglichkeit finden, die Updates nur nach vorheriger Freigabe durch den User auszurollen.
Übersehe ich was?
Gibt es eine Möglichkeit, den Anwender um Erlaubnis fragen, bevor irgend ein Update installiert wird?
Aber wie ich schon geschrieben habe, halte ich das für keine gute Idee/kein praktikables Szenario - ich kenne jedenfalls keinen User, der freiwillig Updates installieren würde, daher habe ich als Admin gern den Finger am Abzug und lege eben fest, wann die Updates installiert werden.
Zumal auch die Möglichkeit, den User selbst entscheiden zu lassen, wann ein Update installiert wird, dir das Testen der Updates nicht erspart - ein kaputtes Updates ist ein kaputtes Update, ob es nun automatisiert installiert wird oder der User die Installation anstossen muss. Daher halte ich dein Vorhaben, die Update-Installation den Usern zu überlassen, nach wie vor wie reichlich sinnfrei und nicht praktikabel.
So wie ich SCCM verstehe, verweist ein Distribution Point ja lediglich auf ein Netzwerk-Share, welches die Updates enthält.
Nö, ein DP kann auch gleichzeitig PXE bereitstellen, was gerade für das Deployment an Remotestandorten ein Segen ist.Wenn das so stimmt stellt sich mir die Frage, ob man an jedem Standort einen Distribution Point braucht.
Ja, weil der SCCM-Client die Software/Updates nur dann lokal findet, wenn der Server, auf dem selbige abgelegt ist, auch in der Hierarchie bekannt ist.Ich hätte dicke Filer an jedem Standort, welche eigentlich deutlich besser mit dem Netzwerk-Traffic klar kommen, als ein
einzelner Server. Die Überlegung wäre, nur einen zentralen Distribution Point zu verwenden und die Clients zu den Filern zu schicken.
Oder spricht da was dagegen?
Ja, siehe oben - du brauchst nen Server pro Standort, das kann ruhig ne VM sein und die braucht auch nicht wirklich viel Bumms (abhängig von der Anzahl der Clients vor Ort), selbst ne ATOM-CPU hat ausreichend Leistung, um per Gigabit-LAN ein paar Daten auszuliefern.einzelner Server. Die Überlegung wäre, nur einen zentralen Distribution Point zu verwenden und die Clients zu den Filern zu schicken.
Oder spricht da was dagegen?
Cheers,
jsysde
