{"id":196417,"date":"2017-11-16T12:28:51","date_gmt":"2017-11-16T11:28:51","guid":{"rendered":"http:\/\/www.borncity.com\/blog\/?p=196417"},"modified":"2024-04-10T18:00:39","modified_gmt":"2024-04-10T16:00:39","slug":"zwangs-upgrade-auf-windows-10-v1709-im-november-2017","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2017\/11\/16\/zwangs-upgrade-auf-windows-10-v1709-im-november-2017\/","title":{"rendered":"Zwangs-Upgrade auf Windows 10 V1709 im November 2017?"},"content":{"rendered":"

Administratoren aufgepasst: Ich bin auf eine ganz merkw\u00fcrdige Geschichte gesto\u00dfen. Mit dem Upgrade-Zyklus zum 14. November 2017 f\u00fchrt Microsoft ein Upgrade f\u00fcr alle Windows 10 Creators Update (V1703) Maschinen auf das Windows 10 Fall Creators Update durch. Gruppenrichtlinien scheinen nicht zu greifen. Entweder hat ein Bug zugeschlagen oder es steckt ein Zwangs-Upgrade per Featureupdate dahinter.<\/p>\n

<\/p>\n

Worum geht es?<\/h2>\n

\"\"Microsoft hatte Business-Anwendern die M\u00f6glichkeit an die Hand gegeben, Windows 10 verz\u00f6gert auf die n\u00e4chste Windows Build umzustellen. Urspr\u00fcnglich lief das Ganze unter Current Branch for Business (CBB). Feature Updates wurden f\u00fcr Maschinen, die im CBB einsortiert waren, nur verz\u00f6gert ausgerollt. Microsoft wartete in der Vergangenheit drei Monate, bis das jeweilige Funktionsupdate auf Business-Systeme ausgerollt wurde (siehe z.B. Windows 10 1607 im Current Branch for Business (CBB)<\/a>).<\/p>\n

Das war unabh\u00e4ngig davon, ob die Maschinen direkt per Windows Update aktualisiert oder ob die Verteilung per WSUS gesteuert wurde. Die Nomenklatur wurde von Microsoft bereits im August 2017 \u00fcber den Haufen geworfen. Im Blog-Beitrag Windows 10: Aus f\u00fcr CBB, Optimierungen bei Updates<\/a> hatte ich bereits erw\u00e4hnt, dass der betreffende Kanal jetzt Semi-Annual Channel\u00a0 genannt wird. Dort fand sind noch die Info: Diese Builds werden 18 Monate lang ab Ver\u00f6ffentlichung mit Updates versorgt. Dann stirbt der Support und die Leute m\u00fcssen auf die n\u00e4chste Build wechseln.<\/em><\/p>\n

\"Update-Optionen\"<\/p>\n

Administratoren von Systemen ab Windows 10 Pro k\u00f6nnen ja die Systeme in den Update-Einstellungen so konfigurieren, dass auch bei direkter Internet Verbindung die Funktionsupdates f\u00fcr eine gewissen Zeit zur\u00fcck gestellt werden (siehe obiger Screenshot aus Windows 10 V1703, Erweiterte Update-Steuerung in Windows 10 Version 1703<\/a>).<\/p>\n

Allerdings deutete sich bereits an, dass Microsoft inzwischen einen 'Zahn zulegen m\u00f6chte'. In diesem Blog-Beitrag<\/a> hatte ich bereits im Oktober 2017 darauf hingewiesen, dass Microsoft das Windows 10 Fall Creators Update auch als Business-ready ansieht.<\/p>\n

\"Windows<\/p>\n

Die obige Darstellung entstammt der Windows Release-Information Webseite<\/a>. Die Information hatte ich als 'sportlich' eingestuft und zur Kenntnis genommen.<\/p>\n

Betrifft Systeme im Semi-Annual Channel (CBB)<\/h2>\n

Nun macht Microsoft wohl N\u00e4gel mit K\u00f6pfen. System mit Windows 10 Creators Update (Version 1703), die von der Telemetrie als upgrade-f\u00e4hig eingestuft werden, erhalten zum Patchday 14. November 2017 wohl das Funktionsupdate auf Windows 10 Fall Creators Update (Version 1709) angeboten.<\/p>\n

Bei WSUS\/SCCM-Umgebungen m\u00fcssten die Administratoren die Verteilung zwar blockieren k\u00f6nnen. Systeme mit Windows 10 Pro V1703, die per Windows Update ihre Patches direkt per Internet von den Microsoft Servern bezogen, wurden aber teilweise auf Windows 10 Fall Creators Update aktualisiert. Und dies, unabh\u00e4ngig davon, wie die Update-Einstellungen in Windows 10 Pro gesetzt waren. Also selbst wer noch meinte, im CBB h\u00e4tte man Ruhe, fand seine Maschine nach dem Patchday auf Windows 10 Fall Creators Update aktualisiert.<\/p>\n

Das ist jedenfalls die Botschaft, die ich aus dem ComputerWorld-Artikel Microsoft forces Win10 1703 customers onto 1709, and other Patch Tuesday shenanigans<\/a> von Woody Leonhard herauslese. Bei ihm ist ein Nutzer in den Askwoody.com-Foren aufgeschlagen<\/a>, der folgendes berichtete.<\/p>\n

Anyone else using GP to enforce CBB (deferred) feature updates on their system?\u00a0 Today I just saw a massive number of Win 10 Pro version 1703<\/strong> installs that were set to stay on the deferred update (formerly known as CBB) get 1709<\/strong> \u2013 across two client systems.\u00a0 It's just been a month since that was released . . . so much for a four month breathing space?<\/p><\/blockquote>\n

War etwas, was mir sofort ins Auge fiel. Der Mann hat Gruppenrichtlinien aufgesetzt, um seine Windows 10 Pro-Systeme auf Version 1703 zu halten. Und sieht pl\u00f6tzlich, dass zwei seiner Clients auf Version 1709 laufen. In einem zweiten Posting schrieb er dann folgendes:<\/p>\n

More details:\u00a0 all 1703 systems that were under WSUS are fine (and most of them won't see updates until this coming Friday due to our odd custom schedule.)<\/p>\n

All (and I mean ALL) 1703 systems today, even with correct Group Policy settings enforced, that were NOT under a WSUS system have picked up and installed (or attempted to install) the 1709 feature update.<\/p>\n

Test systems that had CBB set, but also had the defer updates set for 60 or more days, did NOT update today.<\/p>\n

Test systems where we used WUShowHide to hide\/defer the 1709 update have ALSO attempted to upgrade to 1709 today.<\/p>\n

MS has apparently greatly shorted the wait time for (formerly known as CBB) from 4 months to 1 month.\u00a0 I do not yet know if this was an accident, or intentional.<\/p><\/blockquote>\n

Also in Kurz: Es ergibt sich eine ziemlich krude Situation, wenn ich das Ganze auf die Schnelle richtig interpretiert habe.<\/p>\n