Fragensteller
Update Delivery Optimization -> 256 GB-Grenze reduzieren

Allgemeine Diskussion
-
Guten Tag zusammen,
Update Delivery Optimization setzt clientseitig offenbar Festplatten mit mindestens 256 GB voraus - vgl.
There are minimum requirements for a PC to cache and provide content to peers, with at least 4GB of RAM and 256GB of disk space needed. There are also minimum requirements for clients to receive content from peers; those that don’t meet those requirements will download updates directly from the source (Windows Update or WSUS).
https://blogs.technet.microsoft.com/mniehaus/2016/08/16/windows-10-delivery-optimization-and-wsus-take-2/
Im Firmennetzwerk sind allerdings ausschließlich (!) Windows 10 Clients mit 120 GB-SSDs ausgerollt.
Alle Clients an allen genutzten Standorten ziehen die Updates somit vom WSUS-Server am Hauptstandort.
Die häufig 200, 400 oder gar 3.200 MB großen Updatepakete blockieren entsprechend regelmäßig die Standortverbindungen.
FRAGE:
Gibt es eine Möglichkeit - z.B. Registry-"Hack" - zur Reduzierung der 256 GB-Grenze, so dass Update Delivery Optimization auch funktioniert, wenn ausschließlich 120 GB SSDs vorhanden sind?
Vielen Dank im Voraus
Christian- Typ geändert Yavor TanevMicrosoft contingent staff Mittwoch, 9. November 2016 09:03 Mehrere Konfigurationsmöglichkeiten vorhanden, keine spezifische Antwort auf die gestellte Frage und involviert Hardware als mögliche Lösung
Alle Antworten
-
Moin,Am 06.11.2016 um 12:56 schrieb Christian Hambar:> Gibt es eine Möglichkeit - z.B. Registry-"Hack" - zur Reduzierung der> 256 GB-Grenze, so dass Update Delivery Optimization auch funktioniert,> wenn ausschließlich 120 GB SSDs vorhanden sind?Du nutzt die Win10 Clients als Download Peer?In den Richtlinien gibt es einige Einstellungen zur"Übermittlungsoptimierung", zB die Cache Größe.Da würde ich mal dran schrauben und schauen, was passiert.zB als mx. 20GB angeben oder die max. Cachegröße auf 20% beschränken.TschöMark--Mark Heitbrink - MVP Group Policy - Cloud and Datacenter ManagementHomepage: http://www.gruppenrichtlinien.de - deutschAktuelles: https://www.facebook.com/Gruppenrichtlinien/
-
Moin Mark,
herzlichen Dank für Deine Antwort!
"Download Mode" habe ich per GPO auf "LAN" gestellt in der Hoffnung, dass jeweils das eigene Subnetz als "LAN" definiert ist.
"Max Cache Size" habe ich jetzt eben nach Deiner Antwort auf "20" gestellt ("Set this policy to define the max cache size Delivery Optimization can utilize, as a percentage of available disk space.").
Ausgehend vom oben verlinkten Technet-Blog-Eintrag befürchte ich, dass dies nicht ausschlaggebend ist, da es einen absoluten Schwellenwert von mindestens 256 GB zu geben scheint ("256GB of disk space needed") - aber ich schaue mal, ob es eine Veränderung gibt.
Eine Anpassung des Schwellenwerts auf 120 GB wäre natürlich super und wahrscheinlich praxisnah für SSD-Nutzer im Firmenumfeld.
Viele Grüße
Christian
-
Am 06.11.2016 schrieb Christian Hambar:
Alle Clients an allen genutzten Standorten ziehen die Updates somit vom WSUS-Server am Hauptstandort.
Was spricht gegen einen WSUS am jeweiligen Standort?
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/ -
Hallo Winfried,
im Prinzip eine gute Idee.
Begrenzte Storage-Kapazität spricht jedoch primär gegen verteilte WSUS.
Nebenbei auch Verwaltungsaufwand und ggf. Lizenzkosten (wenn keine Datacenter-Lizenzen am Standort).
Aber primär stehen keine ausreichenden Storage-Kapazitäten zur Verfügung bzw. die Storage-Kosten wären unnötig hoch.
Microsoft bietet mit Delivery Optimization eine tolle Funktion, nur ist es offenbar auf Festplattengrößen von mindestens 256 GB begrenzt.
Besser wäre eine Begrenzung auf verfügbaren(!) Speicherplatz, aber die funktionale Grenze hart auf die Festplattengröße zu definieren, finde ich praxisfern, zumindest bei den sicherlich noch häufiger im Firmenumfeld verbreiteten 120 GB SSDs.
Im konkreten Fall geht es um ein Unternehmen mit mehreren hundert Windows 10-Arbeitsstationen, die im vergangenen Jahr einheitlich auf 120 GB SSDs umgestellt wurden.
Neun Standorte, drei Standorte davon ohne eigene Server-Infrastruktur (RDP / Terminalserver). An diesen drei Standorten kann natürlich gar kein WSUS installiert werden, da keine entsprechende Infrastruktur vorgehalten wird. Auch dort wäre ein funktionierendes Delivery Optimizatio super.
Viele Grüße
Christian
- Bearbeitet Christian Hambar Sonntag, 6. November 2016 19:48 Rechtschreibung
-
Hi,Am 06.11.2016 um 20:42 schrieb Christian Hambar:> Microsoft bietet mit Delivery Optimization eine tolle Funktion, nur> ist es offenbar auf Festplattengrößen von mindestens 256 GB> begrenzt.Alternative: Schraub in jeweils 2-3 von den Clients 256GB SSDs ;-)Unterm Strich immer noch günstiger als Datacenter ...TschöMark--Mark Heitbrink - MVP Group Policy - Cloud and Datacenter ManagementHomepage: http://www.gruppenrichtlinien.de - deutschAktuelles: https://www.facebook.com/Gruppenrichtlinien/
-
Moin Mark,
der Ansatz mit einigen 256 GB SSDs hatte ich gedanklich auch schon.
Allerdings sehe ich auch hier zwei Knackpunkte:
1.) Zunächst müsste ich die Updates gezielt auf diese ausgewählten Systeme verteilen, damit von dort weiterverteilt wird. Das könnte ich vermutlich sogar über WSUS-Gruppen regeln, aber auch das wäre zumindest etwas zusätzlicher Verwaltungsaufwand (zunächst die Updates gezielt für die "großen" Arbeitsstationen freigeben, abwarten und prüfen, ob die Updates dort angekommen sind, anschließend die Updates für alle freigeben). Ohne eine solches gezieltes Pre-Loading würden die Leitungen durch die restlichen Arbeitsstationen sofort blockiert werden, befürchte ich - noch bevor die 256 GB-Arbeitsstationen mit den Updates versorgt sind.
2.) Viele SSDs haben ja gar keine 256 GB, sondern nur z.B. 240 GB. Auch hier müsste man gezielt auswählen.
Natürlich könnte man einfach einige 480 GB SSDs verteilen, aber ich glaube, dass dann unnötiger Aufwand bei der gezielten Verteilung der Updates per WSUS (Punkt 1) entstehen würde.
Außerdem gilt zunächst noch: "There are also minimum requirements for clients to receive content from peers".
Eine nähere Definition dieser Anforderungen konnte ich nicht finden. Möglicherweise müssen auch die empfangenden Clients > 120 GB Festplatte / SSDs eingesetzt haben?Es wäre so schön, wenn Microsoft den Grenzwert einfach auf 120 GB setzen könnte. Das dürfte ja nicht schwer und schnell zu patchen sein. Ein Überlaufen der Platten könnte man durch "Max Cache Size" oder einem ähnlichen Parameter verhindern.
Naja, irgendwie bekomme ich es schon gebacken.
In jedem Fall danke für Eure Ideen.
Viele Grüße
Christian
- Bearbeitet Christian Hambar Montag, 7. November 2016 07:26 Ergänzung "There are also minimum requirements for clients to receive content from peers"
-
Bei der Größe sollte sich immer ein WSUS-Server realisieren lassen. Bei einem so großen Netz müßte es möglich sein, eine entsprechende Infrastruktur vorzuhalten. Es gibt doch sicherlich Datenserver, Sicherungsserver, Domänencontroller....., die man gegebenenfalls nutzen kann. Kosten für Speicherplatten sind relative gering.
Im konkreten Fall geht es um ein Unternehmen mit mehreren hundert Windows 10-Arbeitsstationen, die im vergangenen Jahr einheitlich auf 120 GB SSDs umgestellt wurden.
-
Hi,Am 07.11.2016 um 08:17 schrieb Christian Hambar:> 1.) Zunächst müsste ich die Updates gezielt auf diese ausgewählten> Systeme verteilen, damit von dort weiterverteilt wird.Easy. Gruppenrichtlinie.Alle Clients "http=0" und die Ausnahmen per Sicherheitsgruppe"WSUS-Verteiler" auf 1 oder 2.Du hast nur keine Kontrolle "wann" der Download stattfindet> 2.) Viele SSDs haben ja gar keine 256 GB, sondern nur z.B. 240 GB.> Auch hier müsste man gezielt auswählen.Autsch.Noch eine blöde Idee. Kann nicht eine vhdx größer sein, als diephysikalische Platte? Dann verwende die 120GB SSD, installiere aber dieClients in eine VHDx anstatt einer Partition. :-)TschöMark--Mark Heitbrink - MVP Group Policy - Cloud and Datacenter ManagementHomepage: http://www.gruppenrichtlinien.de - deutschAktuelles: https://www.facebook.com/Gruppenrichtlinien/
-
Hallo Jan-Gerd,
auch für Deinen Meinungsbeitrag vielen Dank!
Bei synchron gespiegeltem HP Lefthand-Storage und einer angenommenen WSUS-Kapazität von knapp 1 TB an sechs (von insgesamt neun) Standorten dürften sich die Storagekosten ganz locker im fünfstelligen Euro-Bereich bewegen (NetApp, EMC² etc. nehmen sich da nichts) - schau mal, was 12 TB (6 TB synchon gespiegelt) Storage kosten.Natürlich kann man auch QNAPs oder Synologys reinhängen, aber selbst das wäre ein Invest im deutlich vierstelligen Bereich und zudem würde die Einheitlichkeit des Gesamtsystems im konkreten Fall aufbrechen.
Ob man WSUS auf anderen Funktionsservern betreibt, ist sicherlich Geschmacksache.
Ich favorisiere eine klare Trennung der Funktionsrollen, was natürlich insbesondere bei einer Virtualisierung in Verbindung mit (überwiegend vorhandenen) Datacenter-Lizenzen problemlos möglich ist.
Aber ungeachtet der Rollentrennung entsteht der Storagebedarf natürlich durch das Content-Volumen der gesammelten Updates.
Microsoft bietet die passende und smarte Funktion, begrenzt sie aber leider - aus meiner Sicht praxisfern - auf 256 GB Festplatten.Ein Herabsetzen der Grenze auf 120 GB würde einen sehr großen Mehrwert darstellen.
Das ist der Hintergrund meiner konkreten Anfrage an das Forum.
Viele Grüße
Christian
-
Moin Mark,
sehr smarter Gedanke, die Clients in VHDx reinzuinstallieren.
Aber dann vielleicht doch etwas sehr aufwendig.
Ich glaube, ich bete einfach weiterhin zum Microsoft-Gott, dass es einen Patch gibt und der Text dann geändert werden möge in:
"There are minimum requirements for a PC to cache and provide content to peers, with at least 4GB of RAM and 120GB of disk space needed."
Oder ich stocke das Budget auf und kaufe ein paar (hundert) 480 GB-SSDs.
Einen Registry-"Hack" gibt es offenbar nicht. Schade.
Also Leute, danke!
Ich denke, dass das Thema abschließend bearbeitet wurde!Viele Grüße
Christian
-
Deine Annahme, dass du 12 TB (2*6*1TB) Speicher brauchst, erscheint mir seeehr viel. (Hängt natürlich davon ab, welche Software du auf den Clients nutzt.). Meiners Erachtens müßte WSUS mit einem einfachen, kleineren Speichersystem auskommen (Voraussetzung: man läd auch nur die Pakete, die wirklich benötigt werden und löscht alte Updates)
Für WSUS würde ich bei Budgetknappheit ohne Bedenken auf syncron gespiegelte Platten verzichten. Bei einem Ausfall hält sich der Schaden in Grenzen.
Rollentrennung: Sicher gut.
-
Hallo nochmals Jan-Gerd,
ich stimme Dir hinsichtlich der Risikobewertung bei einem möglichen Verlust des WSUS zu.
Man kann das Design so oder so gestalten.
Einheitlich in einer generell synchron gespiegelten Storage-Umgebung oder fragmentiert mit unterschiedlichen Storage-Teilkonzepten.
Man könnte auch einen WSUS auf einer EUR 280,00-Lenovo-Arbeitsstation mit 1 TB-Festplatte installieren.
Aber hierbei bewegen wir uns im Meinungsumfeld und da mag jeder seinen ganz individuellen Designansatz verfolgen, den er auch immer gut begründen kann.
Wie schon geschrieben, begrenzte sich meine Anfrage an das Forum auf die klar gesetzte 256 GB-Grenze einer ziemlich smarten und in Windows 10 out of the box vorhandenen Funktion, welche aber leider offenbar hart begrenzt wurde.
Für die Bewertung meines Dir nur teilweise bekannten Ansatzes bedanke ich mich aber natürlich kollegial bei Dir.
Beste Grüße
Christan
-
Moin,Am 07.11.2016 um 12:29 schrieb Christian Hambar:> sehr smarter Gedanke, die Clients in VHDx reinzuinstallieren.> Aber dann vielleicht doch etwas sehr aufwendig.Mit MDT ist das praktisch kein Unterschied, ob HDD/Partition oder vhdx.Ist aber eine Neuinstallation, bzw. ein Backup/Restore ...Da ist die größere Platte wohl die günstigere Variante, wenn einDeployment wie MDT nicht vorhanden ist.TschöMark--Mark Heitbrink - MVP Group Policy - Cloud and Datacenter ManagementHomepage: http://www.gruppenrichtlinien.de - deutschAktuelles: https://www.facebook.com/Gruppenrichtlinien/
-
Moin Mark,
wie schon geschrieben:
Wirklich ein smarter und kreativer Ansatz.
Es weckt immer meinen Respekt, wenn jemand um die Ecke denkt und nicht bloß "ich mache das schon immer so" abarbeitet!
Das dürfte wirklich funktionieren, ist aber ein krasser Workaround ; Thin Provisioning auf der Workstation zum Austricksen des Microsoft-Designs zu Update Delivery Optimization - fancy!
MDT Deployment ist leider nicht vorhanden; werde es mir aber aufgrund Deines Hinweise nun einmal näher anschauen.
Danke dafür, für alle vorherigen Postings zum Thema und - vor allen Dingen - für Deinen absolut wertvollen Gruppenrichtlinien-Blog. Damit hast Du mir schon sehr oft geholfen.
Beste Grüße
Christian