none
Verständnisfragen zu Software Updates SCCM 2012 und Automatic Deployment Rules RRS feed

  • Frage

  • Hallo zusammen,

    ich habe einige Fragen zu der Funktionsweise der Software Updates in SCCM 2012 und den Best Practices:

    Wenn ich mit Automatic Deployment Rules arbeite habe ich die Möglichkeit eine neue Software Update Gruppe zu erstellen, jedes mal wenn die ADR läuft und neue Updates findet. So wie ich gelesen habe ist das auch "Best Practice" um nicht über 1000 Software Updates pro Deployment zu kommen. Wegen hoher Rechenlast Client und Serverseitig??

    Wenn die ADR ein paar mal gelaufen ist, so sind eben genau so viele Deployments auf meiner ausgewählten Collection. Fallen automatisch expired Updates raus??? So wie es scheint nämlich nicht immer....das Deployment wächst und wächst...Warum bleibt das "alte" Deployment drauf, bzw. warum werden alte Deployments nicht entfernt??

    Worin liegt der Sinn dass dann mehrere Deployments auf der Collection wirken z.b. "Software Updates Win7 Datum1" + "Software Updates Win7 Datum2"....? Es kommt nach jedem Durchlauf der ADR ein Deployment auf die Collection hinzu...

    Was ist wenn ich mehrere ADRs definiere z.b. critical Updates + security Updates aufteile. So habe ich 2 ADRs und auch 2 Deployments. So könnte ja verhindert werden dass die Grenze von 1000 Software Updates pro Deployment überschritten wird. Oder macht dies keinen Sinn da im eigentlichen Sinne die wirkenden Policies auf dem Client zählen, also die Updates aus beiden ADRs zusammengezählt??

    Wann würde es überhaupt Sinn machen nach jedem Durchlauf der ADR eine neue Software Update Gruppe zu erstellen?

    Vielen Dank im Voraus!

    Grüße
    RundG

    Mittwoch, 11. September 2013 13:04

Antworten

  • Pro ADR-Lauf eine neue Software Update Group zu erstellen macht nicht so viel Sinn, da - wie bereits richtig bemerkt - sehr viele SUGs & Deployments entstehen. Ich würde pro Produkt (Windows 7, Office 2010, Server 2012 etc) eine SUG verwenden und am Jahresende (oder viertel- halbjährlich alle konsolidieren). Entsprechend sind damit alle anderen Fragen hinfällig.


    Torsten Meringer | http://www.mssccmfaq.de

    Mittwoch, 11. September 2013 15:29
    Beantworter
  • Ich kann bei einer allgemeinen Frage auch nur eine mehr oder minder allgemeine Antwort geben. Ohne Details ist es unmöglich, den optimalsten Weg aufzuzeigen.Wo ist das Problem mit 1000 Updates? Ich habe jetzt nicht wirklich nachgezählt oder nachgeschaut, aber ich denke nicht, dass es für XP mehr als 1000 Updates gibt. Die Grenze wurde so von Microsoft definiert, nachdem vermutlich diverse Tests gezeigt haben, dass es ab dieser Anzahl problematisch werden könnte. Das Limit ist hardcoded und kann nicht überschritten werden. In welchem Fall (nicht nur theoretisch konstruiert, sondern wirklich in der Praxis vorkommend) kommen denn überhaupt mehr als 1000 Updates für einen Rechner zusammen? Mir würde hier nichts praxisrelevantes einfallen ...
    Welche "Best practice"? Pro Lauf einer ADR eine SUG zu erstellen? Das wäre mir so nicht bekannt. "Best practice" als allgemeine Aussage gibt es nach meiner (!) Auffassung nicht. Was im Umfeld X passt und für dieses optimal ist, muss noch lange nicht in Umfeld Y passen oder praktikabel sein. Hierfür gibt es zu viele unterschiedliche Anforderungen, Parameter, Konstellationen, als dass man eine one-fits-all Lösung nennen könnte. Man muss also für jeden Fall alle Details beleuchten und dann eine passende Lösung/Umsetzung erarbeiten - wobei das wieder an den Eingangssatz anknüpft.




    Torsten Meringer | http://www.mssccmfaq.de

    Donnerstag, 12. September 2013 20:17
    Beantworter

Alle Antworten

  • Pro ADR-Lauf eine neue Software Update Group zu erstellen macht nicht so viel Sinn, da - wie bereits richtig bemerkt - sehr viele SUGs & Deployments entstehen. Ich würde pro Produkt (Windows 7, Office 2010, Server 2012 etc) eine SUG verwenden und am Jahresende (oder viertel- halbjährlich alle konsolidieren). Entsprechend sind damit alle anderen Fragen hinfällig.


    Torsten Meringer | http://www.mssccmfaq.de

    Mittwoch, 11. September 2013 15:29
    Beantworter
  • Hallo,

    Vielen Dank für die schnelle Antwort. Allerdings sind damit noch nicht alle Fragen geklärt. Du gibst natürlich einen machbaren Weg vor, welcher aber je nach Situation nicht unbedingt der optimalste ist. Was ist mit Rechnern (zb XP) die mal angenommen viele Jahre nicht am Netz waren. Um je nach Anforderung die beste Möglichkeit zu finden fehlt mir das genaue Verständnis in den gefragten Punkten:

    Warum die Grenze von 1000 Software Updates pro Deployment? Wodurch genau entsteht die hohe Rechenlast?

    Was genau heißt  pro Deployment? Kann man ein Deployment das die 1000er Grenze überschreitet aufteilen (2 ADRs mit unterschiedlicher classification) oder macht dies keinen Sinn weil die insgesamt wirkenden Policies auf einem Client zählen?

    Warum dann das "Best Practice" immer eine neue SUG zu erstellen?

    Fallen alte (expired,superseded) Updates automatisch raus?

    Vielleicht steh ich hier selbst auf dem Schlauch...allerdings ist das ganze eine nur schwer durchsichtige graue Wolke.

    Vielen Dank nochmal!

    Gruß
    RundG

    Donnerstag, 12. September 2013 08:53
  • Ich kann bei einer allgemeinen Frage auch nur eine mehr oder minder allgemeine Antwort geben. Ohne Details ist es unmöglich, den optimalsten Weg aufzuzeigen.Wo ist das Problem mit 1000 Updates? Ich habe jetzt nicht wirklich nachgezählt oder nachgeschaut, aber ich denke nicht, dass es für XP mehr als 1000 Updates gibt. Die Grenze wurde so von Microsoft definiert, nachdem vermutlich diverse Tests gezeigt haben, dass es ab dieser Anzahl problematisch werden könnte. Das Limit ist hardcoded und kann nicht überschritten werden. In welchem Fall (nicht nur theoretisch konstruiert, sondern wirklich in der Praxis vorkommend) kommen denn überhaupt mehr als 1000 Updates für einen Rechner zusammen? Mir würde hier nichts praxisrelevantes einfallen ...
    Welche "Best practice"? Pro Lauf einer ADR eine SUG zu erstellen? Das wäre mir so nicht bekannt. "Best practice" als allgemeine Aussage gibt es nach meiner (!) Auffassung nicht. Was im Umfeld X passt und für dieses optimal ist, muss noch lange nicht in Umfeld Y passen oder praktikabel sein. Hierfür gibt es zu viele unterschiedliche Anforderungen, Parameter, Konstellationen, als dass man eine one-fits-all Lösung nennen könnte. Man muss also für jeden Fall alle Details beleuchten und dann eine passende Lösung/Umsetzung erarbeiten - wobei das wieder an den Eingangssatz anknüpft.




    Torsten Meringer | http://www.mssccmfaq.de

    Donnerstag, 12. September 2013 20:17
    Beantworter