none
WSUS RRS feed

  • Frage

  • In einem Unternehmen mit mehreren Abteilungen und pro Abteilung stark unterschiedlichen Anforderungen an Updates soll ein WSUS-Windows-Update-Server betrieben werden.

    Nun wäre es ideal, wenn WSUS mandantenfähig ist, also wenn aus jeder Abteilung ein Admin die Updates für die Rechner in seiner OU bzw. WSUS-Gruppe selbst und alleine freigeben könnte, nachdem er zuvor die Updates in einer eigenen Testgruppe geprüft hat. Bisher sehe ich nur die Möglichkeit, in WSUS Gruppen zu definieren, zu denen aber dann alle Administratoren des Unternehmens Zugriff haben.

    Eine Lösung wäre, in jeder OU einen eigenen WSUS zu installieren und diesen dann mit dem Unternehmens-WSUS zu kaskadieren.

    Weiß jemand eine bessere Lösung?

    Danke!

    Dienstag, 8. Dezember 2015 10:14

Antworten

  • Hi,
     
    Am 08.12.2015 um 11:14 schrieb WolfgangVogt:
    > Nun wäre es ideal, wenn WSUS mandantenfähig ist, also wenn aus jeder
    > Abteilung ein Admin die Updates für die Rechner in seiner OU bzw.
    > WSUS-Gruppe selbst und alleine freigeben könnte,
     
    Gibt es, nennt sich dann SCCM ...
     
    > Eine Lösung wäre, in jeder OU einen eigenen WSUS zu installieren und
    > diesen dann mit dem Unternehmens-WSUS zu kaskadieren.
     
    oder SCCM kaufen ...
     
    > Weiß jemand eine bessere Lösung?
     
    Ja, es gibt ein "Team Windows Updates" und die regeln alles.
    Genauso, wie es ein "Softwarepaketierer-Team" gibt und eine "GPO-Team".
    Das muss nicht jeder selber können, sondern es sollten die Leute machen,
    die technisch können, nicht politisch dürfen ...
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Dienstag, 8. Dezember 2015 11:01

Alle Antworten

  • Hi,
     
    Am 08.12.2015 um 11:14 schrieb WolfgangVogt:
    > Nun wäre es ideal, wenn WSUS mandantenfähig ist, also wenn aus jeder
    > Abteilung ein Admin die Updates für die Rechner in seiner OU bzw.
    > WSUS-Gruppe selbst und alleine freigeben könnte,
     
    Gibt es, nennt sich dann SCCM ...
     
    > Eine Lösung wäre, in jeder OU einen eigenen WSUS zu installieren und
    > diesen dann mit dem Unternehmens-WSUS zu kaskadieren.
     
    oder SCCM kaufen ...
     
    > Weiß jemand eine bessere Lösung?
     
    Ja, es gibt ein "Team Windows Updates" und die regeln alles.
    Genauso, wie es ein "Softwarepaketierer-Team" gibt und eine "GPO-Team".
    Das muss nicht jeder selber können, sondern es sollten die Leute machen,
    die technisch können, nicht politisch dürfen ...
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Dienstag, 8. Dezember 2015 11:01
  • Am 08.12.2015 schrieb WolfgangVogt:

    In einem Unternehmen mit mehreren Abteilungen und pro Abteilung stark unterschiedlichen Anforderungen an Updates soll ein WSUS-Windows-Update-Server betrieben werden.

    Hmm.

    Nun wäre es ideal, wenn WSUS mandantenfähig ist, also wenn aus jeder Abteilung ein Admin die Updates für die Rechner in seiner OU bzw. WSUS-Gruppe selbst und alleine freigeben könnte, nachdem er zuvor die Updates in einer eigenen Testgruppe geprüft hat. Bisher sehe ich nur die Möglichkeit, in WSUS Gruppen zu definieren, zu denen aber dann alle Administratoren des Unternehmens Zugriff haben.

    Eine Lösung wäre, in jeder OU einen eigenen WSUS zu installieren und diesen dann mit dem Unternehmens-WSUS zu kaskadieren.

    Du kannst natürlich 10 oder 20 WSUS-Server installieren, aber ob das
    der Übersicht gut tut?

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Dienstag, 8. Dezember 2015 17:40
  • In einem Unternehmen mit mehreren Abteilungen und pro Abteilung stark unterschiedlichen Anforderungen an Updates soll ein WSUS-Windows-Update-Server betrieben werden.

    Spätestens mit Windows 10 wird sich dies erübrigt haben - daher -> umdenken.

    Best regards,

    David das Neves

    Technology Specialist - Consulting Services
    Computacenter AG & Co. oHG - Munich

    Blog    
    Creating Powershell GUIs with XAML? Take a look! PSGUI

    Dienstag, 8. Dezember 2015 21:31
  • Am 08.12.2015 schrieb David das Neves:

    In einem Unternehmen mit mehreren Abteilungen und pro Abteilung stark unterschiedlichen Anforderungen an Updates soll ein WSUS-Windows-Update-Server betrieben werden.

    Spätestens mit Windows 10 wird sich dies erübrigt haben - daher -> umdenken.

    Erklär doch auch warum Du das so meinst. Einfach so einen Satz
    hinschreiben, ist verbesserungswürdig.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Dienstag, 8. Dezember 2015 22:03
  • Hallo Winfried,

    nun die Anforderungen der Abteilungen an die Updates wird sich in Windows 10 dahingehend verändern, als dass sich die gesamte Update-Umsetzung in Win 10 verändert. Es macht Sinn einen Prozess für alle Abteilungen zu finden und nur noch zwischen zwei Szenarien, U-Boot-Szenarien (LTSB) und Standard CB zu differenzieren.

    s. hierfür: 

    Link

    Auch wird man die Update-Frequenz bestimmt überdenken müssen, da Microsoft hier detailliert Zeitspannen vorgibt und viele Kunden ihren Update-Zyklus aktuell selbst entschieden haben.

    Aufgrund dieser ganzen Änderungen macht es Sinn, den gesamten Ansatz nochmal zu überdenken, da man diesen ggf. beim Upgrade auf Win 10 nochmal revidieren bzw. anpassen müsste.


    Best regards,

    David das Neves

    Technology Specialist - Consulting Services
    Computacenter AG & Co. oHG - Munich

    Blog    
    Creating Powershell GUIs with XAML? Take a look! PSGUI

    Mittwoch, 9. Dezember 2015 16:27
  • Am 09.12.2015 schrieb David das Neves:

    nun die Anforderungen der Abteilungen an die Updates wird sich in Windows 10 dahingehend verändern, als dass sich die gesamte Update-Umsetzung in Win 10 verändert. Es macht Sinn einen Prozess für alle Abteilungen zu finden und nur noch zwischen zwei Szenarien, U-Boot-Szenarien (LTSB) und Standard CB zu differenzieren.

    Spätestens wenn die ersten Leitungen bei einem weiteren Upgrade in
    Höhe von 2,5 GB dicht sind, überlegen die Unternehmen wieder, wie man
    W10 los wird. Du kannst aber nicht wegen W10 von Unternehmen
    verlangen, bisher gut funktionierende Prozesse, einzustampfen.

    s. hierfür: 

    Link <https://technet.microsoft.com/de-de/library/mt598226(v=vs.85).aspx>

    Auch wird man die Update-Frequenz bestimmt überdenken müssen, da Microsoft hier detailliert Zeitspannen vorgibt und viele Kunden ihren Update-Zyklus aktuell selbst entschieden haben.

    Ähm, Du meinst also ganz im Ernst, sobald MSFT ein neues Upgrade für
    W10 raus gibt, muß es der Kunde morgen installieren?

    Aufgrund dieser ganzen Änderungen macht es Sinn, den gesamten Ansatz nochmal zu überdenken, da man diesen ggf. beim Upgrade auf Win 10 nochmal revidieren bzw. anpassen müsste. <https://technet.microsoft.com/de-de/library/mt598226(v=vs.85).aspx>

    Sorry, aber bisher hast Du nur Marketing gesprochen, technische
    Details habe ich noch keine gefunden.

    MSFT vergisst immer wieder, nicht jeder auf der Welt hat die Zeit, die
    Lust und auch die Mittel sich mit dem OS so lange zu beschäftigen. Das
    hat zu funktionieren. Auch ist ein Zangsupdate, und das wird auch bei
    Firmen mit W10 eingeführt, nicht so prickelnd.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Mittwoch, 9. Dezember 2015 17:35
  • Hey - ich hab nicht gesagt, dass alles gut ist, was die Burschen da treiben. ;)

    Aber - Stand heute - müssten fast alle Unternehmen ihren Update-Prozess mittelfristig anfassen. 

    >> Spätestens wenn die ersten Leitungen bei einem weiteren Upgrade in
    >> Höhe von 2,5 GB dicht sind, überlegen die Unternehmen wieder, wie man
    >> W10 los wird. Du kannst aber nicht wegen W10 von Unternehmen
    >> verlangen, bisher gut funktionierende Prozesse, einzustampfen.

    Die Leitungen werden zwar sicherlich belastet werden, aber durch die Peer to Peer-Funktionen "Windows Update Delivery Optimization (WUDO)" wird die Last wenigstens im ganzen Netz verteilt werden. Daher kann ich mir schon gut vorstellen, dass man das in den Griff bekommen kann, wenn man das richtig angeht. 

    >> Ähm, Du meinst also ganz im Ernst, sobald MSFT ein neues Upgrade für
    >> W10 raus gibt, muß es der Kunde morgen installieren?

    Natürlich nicht - wenn wir uns im Enterprise bewegen, denke ich, dass die Kunden zum CBB greifen werden, der bereits 4 Monate (und länger) im Vorfeld an die Versuchskaninchen "Consumer" getestet wurde. Zudem kann man diesen auch nochmal verzögern oder einmal ganz aussetzen. Nichtsdestotrotz ist es so, dass kritische Sicherheitsupdates immer asap auf die Rechner installiert werden, ungeachtet CB oder CBB. 

    >> MSFT vergisst immer wieder, nicht jeder auf der Welt hat die Zeit, die
    >> Lust und auch die Mittel sich mit dem OS so lange zu beschäftigen. Das
    >> hat zu funktionieren. Auch ist ein Zangsupdate, und das wird auch bei
    >> Firmen mit W10 eingeführt, nicht so prickelnd.

    Ich denke, dass das MSFT auch so sieht. Windows wird ja nicht mehr wirklich als "OS" bezeichnet - es soll ja in Richtung WAAS - Windows as a Service gehen. Man soll sich eben NICHT mehr damit beschäftigen müssen und alles soll sorgenfrei von selbst laufen. Updates usw.
    Hand aufs Herz - sehr utopisch - aber der Grundgedanke ist genau der.

    Es bleibt abzuwarten, wie das Ganze aussieht, wenn das erste CBB nächstes Jahr erscheint. Bis dahin ist die Situation aktuell eh unbefriedigend mit TH2 usw.
    Nichtsdestotrotz kann man nicht einfach die Augen zu machen und so tun, als ob MSFT nie ein Windows 10 veröffentlicht hätte. Es ist nun da und man sollte sich mit dem Gedanken abfinden, dass man früher oder später auch dahin migrieren muss; spätestens, wenn der offizielle Support nach und nach für die Vorversionen ausläuft.

    Der Schritt über Windows 8 und der Universal Plattform zielte langfristig auf das Win 10 ab. Ein OS auf allen Geräten - und überall konsistente Update-Stände, um nicht ständig Altlasten mitzuführen und Altlasten zu supporten und somit die Entwicklerteams fokussiert auf neuen Ständen am neuen OS arbeiten zu lassen.

    Ich persönlich finde die Idee dahinter recht gut. Die Umsetzung ist bis dato noch nicht ganz ausgereift (freundlich formuliert) - aber hey - wir wollen ja auch noch was zu tun haben ;)


    Best regards,

    David das Neves

    Technology Specialist - Consulting Services
    Computacenter AG & Co. oHG - Munich

    Blog    
    Creating Powershell GUIs with XAML? Take a look! PSGUI

    Mittwoch, 9. Dezember 2015 18:12