Windows 10 V1709 Zwangs-Upgrade von V1703 bestätigt

[English]Microsoft hat weltweit Windows 10 V 1703-Systeme zwangsweise auf Windows 10 Fall Creators Update aktualisiert, obwohl dies von den Administratoren im CBB eigentlich gesperrt worden war.


Anzeige


Mitte des Monats hatte ich im Blog den Beitrag Zwangs-Upgrade auf Windows 10 V1709 im November 2017? – dort noch mit einem Fragezeichen versehen. Jetzt müsste dort ein Ausrufezeichen dahinter stehen.

Worum geht es?

Microsoft ermöglicht Business-Anwendern Windows 10 verzögert auf die nächste Windows Build umzustellen. Ursprünglich lief das Ganze unter Current Branch for Business (CBB). Dort können Feature Updates verzögert ausgerollt werden (siehe z.B. Windows 10 1607 im Current Branch for Business (CBB)).

Update-Optionen

Administratoren müssen nur die Funktionsupdate in der Einstellungen-App um die gewünschte Zeit verzögern. So die Theorie, die in der Praxis auch ganz gut funktioniert hat – bis zum Windows 10 Fall Creators Update. Bereits in diesem Blog-Beitrag hatte ich im Oktober 2017 darauf hingewiesen, dass Microsoft das Windows 10 Fall Creators Update auch als Business-ready ansieht.

Windows Release-Information

Die obige Darstellung entstammt der Windows Release-Information Webseite. Woody Leonhard wies in dem ComputerWorld-Artikel Microsoft forces Win10 1703 customers onto 1709, and other Patch Tuesday shenanigans, dass Microsoft unter Windows 10 Version 1703 das Funktionsupdate für Windows 10 V1709 ausrollt, ohne sich um Einstellungen wie verzögerte Funktionsupdates zu kümmern.

Microsoft hat die Beschreibung aktualisiert

Woody Leonhard hat einen Nutzerhinweis auf eine Änderung in der Microsoft-Beschreibung zum Update kb4048954 bekommen. In der Beschreibung zum Update steht nun:


Werbung

Windows Pro devices on the Current Branch for Business (CBB) will upgrade unexpectedly.

Microsoft arbeitet an einem Fix und will diesen in einem kommenden Update beheben. So langsam laufen wir in die Situation, dass die Liste der bekannten Probleme länger als die Liste der behobenen Bugs wird.


Werbung


Dieser Beitrag wurde unter Windows 10 abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

22 Kommentare zu Windows 10 V1709 Zwangs-Upgrade von V1703 bestätigt

  1. Karl (al Qamar) sagt:

    Das ist ein tragischer und unverzeihlicher Fehler, ohne Zweifel. Die Liste der Fehler ist jedoch noch weit davon entfernt die Liste der Fixes einzuholen.
    Es ist aber auch kein Zwangsupgrade, sondern ein Fehler.
    Beides ist revidierbar.

    Bislang habe ich nach etwa 47 Upgrades sehr positive Erfahrungen mit 1709 gemacht. Windows 10 wird erwachsen.

    • Tim sagt:

      “Windows 10 wird erwachsen.”

      Ich beneide Optimisten manchmal…!

    • Ralph sagt:

      Bei Rechnern, auf den maximal ein Office läuft und zudem noch ein wenig im Internet gesurft wird, mag es sein, dass es nur positive Erfahrungen gibt. Dummerweise laufen auf sämtlichen Maschinen meiner durchaus anspruchsvollen Kunden anspruchsvolle Programme. Ich habe bislang mit 1709 noch gar keine positiven Erfahrungen machen können. Und grundsätzlich ist es peinlich, dass ZWEI Jahre nach Veröffentlichung ein Stück Saftware noch immer nicht rund läuft.

  2. Peter sagt:

    Soweit ich das beurteilen kann, sollte es Firmen, deren Clients vom hauseigenen WSUS versorgt werden, nicht betreffen, solange dieser WSUS keine !Upgrades! synchronisiert bzw. zur Verfügung stellt.

    • Günter Born sagt:

      Dem ist bisher so. Aber nicht immer kann man einen WSUS einsetzen.

      Das ist das, was mich an Windows 10 und dem neuen Ansatz stört. In Deutschland sind 70% der Firmen im KMU-Bereich beheimatet. Beim kleinen Handwerker, der Praxis etc. einen WSUS aufsetzen, um Updates zu verteilen, kann es ja wohl nicht sein. Da ist MS imho dabei, sich gerade ein ganzes Geschäftsfeld zu zerschlagen …

      • JohnRipper sagt:

        Ich betreibe einen WSUS auf einer virtuellen Maschine für eine handvoll Computer, eben weil ich die Verteilung kontrollieren will und zusätzliche Updates darüber verteile.

        Aber ja, mit diesem DualScan-Rotz hat MS den WSUS offensichtlich obsolet gemacht.

        • Günter Born sagt:

          Muss man sich aber mal auf der Zunge zergehen lassen, welchen Aufwand Du betreiben musst, um etwas selbstverständliches auf einem Client sicherzustellen.

          Ähnlich wie beim Auto: Neuestes Wegfahrsperrentechnologie, die sich leicht aushebeln lässt. Also kommt wieder die alte Lenkradkralle zum Einsatz. Das nennt sich Fortschritt – ich könnte lachen, wenn es nicht so krotesk wäre.

    • JohnRipper sagt:

      Die Option auf die es mE ankommt ist die Deaktivierung von “DualScan” (zu Deutsch: “Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird” muss aktiviert werden).

      Ansonsten operiert der Client ja seit 1607 mit gewissen Einstellungen am WSUS vorbei, womit dann völlig egal ist ob der WSUS Upgrades synced oder nicht.

      Die s** Fummelei an diesem Update-Service nervt in letzter Zeit ziemlich an.

      • Steffen sagt:

        Hi John,

        ich habe hier DCs auf Basis von Windows Server 2012 R2. Da gibt es in den GPOs diese Option nicht. Ebenso wie es auch das Zurückstellen von Feature-Upgrades nicht gibt. Oder ich habe was übersehen. Aber ich hatte die Policies über MS gezogen und im Policies-Verzeichnis bereitgestellt…

        Ich habe die Übermittlungsoptimierung auf LAN stehen und dass die Clients _keine_ Internetadressen fürs Update nutzen. Und latürnich “Turn off the upgrade to latest…” aktiviert, wobei das ja für W7 und W8/8.1 gilt.

        Ebenso wie Peter bin ich für Erhellendes dankbar.

        VG, Steffen

        • JohnRipper sagt:

          1)
          Zu dem Dual Scan Thema findet man mit den Worten “Dual Scan windows 10” doch einiges.
          Am besten fängt man vielleicht hier an:
          https://blogs.technet.microsoft.com/wsus/2017/08/04/improving-dual-scan-on-1607/ und klickt sich durch.

          2)
          Zugegeben mir war das Thema auch nicht wirklich bewusst, bis ich mich mit den neuen ADMX Templates für Windows 10 1709 mich versucht habe vorzubereiten.
          Bei mir war Windows 1709 als Funktionsupdate lange Zeit im WSUS als erforderlich aber natürlich noch nicht genehmigt vorhanden, da von einigen Clients anfragt. Die 1709er Templates ermöglichen das setzen von Einstellungen zu “Select when Feature Updates are received” und “Select when Quality Updates are received”, was dann den DualScan aktiviert.
          Ich habe das gesetzt, weil ich dachte, dass ich dadurch die Funktionsupgrates besser automatisch steuern kann (die Hoffnung war, dass die Clients die Feature Updates erst anfragen, wenn das Feature Upgrate im Semi-Anual-Channel +30 Tage erschienen ist), sodass ich das dann auch zeitnah genehmigen kann.
          Die Aktivierung von DualScan hat aber vielmehr dazu geführt, dass die Clients direkt begannen 1709 zu laden (unerwartet, da im WSUS nicht genehmigt).
          Daraufhin habe ich mich auf die Suche begeben und realtiv viel gefunden. Scheint viele überrascht zu haben.

          3)
          Um das Thema zu beheben, müssen die neuen ADMX Templates für Windows 1709 heruntergeladen und auf dem DC im CentralStore importiert werden.
          Dann kann die Option “Keine Richtlinien für Updaterückstellungen zulassen, durch die Windows Update überprüft wird” (Engl. Option siehe Bild im Blog) unter Windows Components/Windows Update im Richtlinieneditor in der entsprechenden GPO auf aktiviert gesetzt werden, wodurch DualScan abgeschaltet wird (ja, weder die deutsche und noch die englische Beschreibung lässt vermuten um was es geht).
          Alternativ kann auf jedem Client ab 1607 die Einstellung über den lokalen Richtlinieneditor manuell gesetzt werden, bzw. es gibt auch Möglichkeiten über das Feature über die Verteilung von Registryeinträgen zu steuern.
          Das Update der ADMX + GPO erscheint mir am einfachsten.

          Ich hoffe das hilft.

          nb
          4)
          Irgendwie scheint eine Option dann auch die manuelle Möglichkeit die Suche nach Updates anzustoßen deaktiviert zu haben, jedenfalls ist bei mir die Option “Suche nach Updates” jetzt ausgegraut und funktionslos.

          Was ich aber ganz ursprünglich abstellen wollte ist die Möglichkeit, dass die User die Qualitätsupdates verzögern können. Wenn also dafür jedemand eine Lösung hat, dann bin ich auch dankbar. 🙂

        • JohnRipper sagt:

          Aso und noch etwas. Ich habe die Option “keine Verbindungen mit Windows Update-Internetadressen herstellen” nicht aktiviert, da ich sonst Probleme bei der Aktivierung von Windows 10 habe und zwar genau wie hier beschrieben:
          https://oli.new-lan.de/2016/04/fiese-gpo-mit-wsus-windows-10-aktivierung-schlaegt-fehl/

          War das ein Bug bzw. ist das Problem behoben?

  3. Peter sagt:

    Von diesem Dual-Scan lese ich gerade zum ersten mal. :0

    Was muss ich in den Group-Policies eines Windows Server 2012 R2 denn konfigurieren, um etwaigen Windows 10-Clients auszutreiben neben dem WSUS evtl. auch selber direkt Microsoft Update zu befragen?

    Über das Thema findet man nicht viel…

    • JohnRipper sagt:

      Siehe oben.

      • Peter sagt:

        Ah ja, danke. Nachdem ich die neuen Administrativen Templates auf den Server gepackt habe, gab es die Option “DisableDualScan” auch.
        Bei uns allerdings gemäß der installierten Sprache auf englisch: “Do not allow update deferral policies to cause scans against Windows Update”

        • JohnRipper sagt:

          Auch damit weiß man nicht so wirklich um was es geht 🙂

          Frage: wie verhält es sich bei dir mit der manuellen Suche auf den W10 Clients?

        • Peter sagt:

          @JohnRipper:
          So, ich bin mal wieder im Büro gewesen und konnte das im LAN testen.

          Die von dir angefragte “Suche nach Updates” ist NICHT ausgegraut, sondern funktion wie gewünscht.

          “DisableDualScan” ist definitiv auf meinem Client (Windows 10 Enterprise 1703) aktiviert, das habe ich mit “GPRESULT” geprüft.

          Gruß,
          Peter

  4. ohne nam sagt:

    ein Bug also, “Microsoft arbeitet an einem Fix und will diesen in einem kommenden Update beheben.”
    => also eher etwas viel Lärm um rel. wenig, temp. ärgerlich auf jeden Fall, aber das wars dann auch.

    “Zwangs-Upgrade” in der Überschrift oder Schlagzeile triffts dann aber nicht mehr.

    • Günter Born sagt:

      Frag mal diejenigen, denen das System zwangsweise aktualisiert wurde, obwohl Featureupgrades geblockt wurden. Speziell die, die keinen WSUS betreiben und von IT-lern betreut werden und nun eine Rechnung erhalten, weil ein Supporter raus musste und das System restauriert hat …

      Was mir so auffällt: Es wird hier Haarspalterei um die Wortwahl in der Titelei betrieben (Du bist nicht der Einzige, der sich mokiert). Dass da aber mal wieder etwas schief gelaufen ist, was Nutzer ziemlichen Brass bereiten kann, wird auf ‘viel Lärm um nichts’ geschoben.

      Skalierung verloren gegangen?

      • ohne nam sagt:

        dann also ‘skalierung’,

        => eine reine Feststellung ist eine Feststellung, bleibt eine Feststellung. Nicht mehr.

        “getroffene Hunde bellen”, fiele dazu noch ein 😉 ,
        wollte man etwas sarkastisch sein. Was nicht wirklich der Fall ist. Aber:
        – weder mokant, noch
        – Haarspalterei – denn das klänge anders.
        lediglich eine Feststellung. Der Unterschied sollte bekannt sein. 😀
        – dazu war von “etwas viel Lärm um rel. wenig” die Rede, ist ungleich ‘viel Lärm um nichts’. bzw. bewusst(?) falsch verstanden. unnötig.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.