Updateübersicht Windows 10 (v1809_17763.437) und Server 2019 (~LTSC)

[Nemo]

Zum "kleinen" Patchtag gab MS frei:

• Kumulatives Update
• Update für NetFx 3 und 4.72 *)
• dynamisches Update aus Beitrag #19 mangels neuem übernommen

Den ersten Beitrag habe ich aktualisiert.

*) Nach dem Einspielen auf zwei frisch installierte VMs (W10 und 2019) hat WU mir gleichwohl noch die eigentlich veraltete Version von NetFx unter KB4480056 verordnet.
So ganz falsch lag ich mit meiner von Thiersee aufgedeckten Unstimmigkeit also gar nicht ...
Die Unterschiede zwischen Daten- und Zufallsverarbeitung müssen die Praktikant*Innen (oder muss es demnächst Praktizierenden heißen?) in Redmond noch in harter Arbeit einebnen:

• Die extra eingerichtete Übersicht ist auch in der englischen Version immer noch nicht aktuell; von der deutschen Version ganz zu schweigen.
• In der Überschrift im DC ist (im Gegensatz zum MUC) immer noch von einer Vorschauversion die Rede.
• Der MUC nennt als überholte Version immer noch ausschließlich die erste Vorschau vom November '18 unter KB4461049 als überholt (superseded).

Gruß, Nemo

[Thiersee]

....
*) Nach dem Einspielen auf zwei frisch installierte VMs (W10 und 2019) hat WU mir gleichwohl noch die eigentlich veraltete Version von NetFx unter KB4480056 verordnet.
So ganz falsch lag ich mit meiner von Thiersee aufgedeckten Unstimmigkeit also gar nicht ...
...

Das kann ich bestätigen, leider!
Als ich den "Vertipper" gemeldet habe, hatte ich gerade davor die Integration mit der KB4480056 installiert....

Edit:
merkwürdig ist es, was MUC sagt:
KB4481031 ersetzt (nur) KB4469041

bei den anderen dagegen:
KB4469041 wurde ersetzt von KB4470502 und KB4481031
KB4470502 ersetzt KB4469041, wurde ersetzt von KB4480056
KB4480056 ersetzt (nur) KB4470502

Ich glaube MS wollte mit KB4481031 etwas korrigieren, was im KB4469041 (es war ein Preview!) enthalten war und das bei den nachfolgenden nicht korrigiert wurde...

Von wegen, MS hat wieder mal gepfuscht und das Update aus der automatischen Verteilung zurückgezogen!

aus dem Article KB4481031 : Zeige Spoiler

Known issues in this update

For 24 hours, this Jan 22, 2019 Cumulative Update for .NET Framework 3.5 and 4.7.2 (KB4481031) was made available broadly on Windows Update as an automatic update. As of January 23, 2019, this update is no longer offered on Windows Update as an automatic update, but rather only to "seekers" who go to Settings > Update & Security > Windows Update, and then select Check for updates, as is expected. This update continues to be available on WSUS and Microsoft Update Catalog.

LG

[Nemo]

Nach einigen Stunden "Spielerei":

• Das zusätzliche Integrieren von KB4480056 rief nach einer frischen Installation WU auf den Plan: Es wollte mir wieder das eigentlich integrierte kumulative Update (CU) installieren.
• Das zusätzliche Integrieren des CUs ins Medium brachte keine Besserung, nachdem WTK auch erkannt hatte, dass es bereits integriert war.
• Erst die volle Dröhnung mit CU und beiden NetFx-Patches brachte WU dazu, an dieser Baustelle Ruhe zu geben.

Die vorstehende Kritik von Thiersee an der erneuten Schlamperei kann ich gut verstehen.
QM ist anscheinend ein Fremdwort in Redmond.

Den ersten Beitrag habe ich nochmals überarbeitet.

Gruß, Nemo

[Nemo]

Gestern gab MS einen neuen Microcode-Patch frei.

Den ersten Beitrag habe ich aktualisiert.

Gruß, Nemo

[Nemo]

Zum offiziellen Patchtag gab MS frei:

• Kumulatives Update
  • Einen Tag zuvor war die Version per MCT bereits als Vorabversion (*.CAB) verfügbar.
  • Mir fiel beim Testen auf, dass nach der Integration in die Install.WIM der Build 177763.1 nunmehr17763.292 unter WTK angezeigt wurde
• FlashPlayer-Patch (die Versions-Nr. ist höher als die bei Adobe!)
• Update für NetFramwork (3.5&4.72). Die Ungereimtheiten des Vormonats wurden teilweise bereinigt:
  • Der eine Patch ist wirklich kumulativ und auch die ersetzten Updates werden im MUC korrekt angegeben.
  • Die Übersicht unter KB4466961 mit der Änderungshistorie verharrt seit Januar immer noch im Dornröschenschlaf

Den ersten Beitrag habe ich aktualisiert.

Gruß, Nemo

[Thiersee]

Hi Nemo,

Kumulatives Update
.....
Mir fiel beim Testen auf, dass nach der Integration in die Install.WIM der Build 177763.1 nunmehr17763.292 unter WTK angezeigt wurde

Ganz genau!
Die Integration des Builds .292 in die .1 ergab richtigerweise .292, dagegen die Integration der .316 ergibt weiterhin .292, aber nicht in NTlite: dort wird korrekterweise .316 angezeigt.
Installiert wird auf jedem Fall die .316.

Update für NetFramwork (3.5&4.72). Die Ungereimtheiten des Vormonats wurden teilweise bereinigt:

Der eine Patch ist wirklich kumulativ und auch die ersetzten Updates werden im MUC korrekt angegeben.
......

Ich habe es im MUC nicht kontrolliert, aber in die ISO habe ich nur die aktuellen integriert und WU hat bis jetzt nicht gemeckert (was schon erstaunlich ist!)

Off Topic

In der VM hatte ich die "blendende" Idee, sofort nach der Installation einzustellen, daß WU auch nach anderen MS-Software suchen soll; danach habe ich die frische ISO von Office 2010 (aktualisiert zum Patch-Tag) gestartet: das "blöde" WU hat sich die noch nicht fertige Installation geschnappt und 18 angeblich fehlende Updates gleich angestossen !

LG

[Nemo]

... Die Integration des Builds .292 in die .1 ergab richtigerweise .292, dagegen die Integration der .316 ergibt weiterhin .292, aber nicht in NTlite: dort wird korrekterweise .316 ngezeigt. Installiert wird auf jedem Fall die .316. ...

Zu meiner Vorgehensweise:

• Ich gehe immer von der 17763.1 aus. In die integriere ich die im ersten Beitrag genannten Patches.
• Bislang (bis zur 17763.292) zeigte mir WTK nach dem Prozess immer die 17763.1 an. Nach einer Installation warf winver.exe dann trotzdem die jeweils aktuelle Build-Nr. aus.
• Diesmal las WTK nach der Integration des Patches für die *.316 die Build-Nr. der älteren *.292 an. Auch jetzt wurde nach der Installation die gewünschte *.316 ausgewiesen.

...

Off Topic

In der VM hatte ich die "blendende" Idee, sofort nach der Installation einzustellen, daß WU auch nach anderen MS-Software suchen soll; danach habe ich die frische ISO von Office 2010 (aktualisiert zum Patch-Tag) gestartet: das "blöde" WU hat sich die noch nicht fertige Installation geschnappt und 18 angeblich fehlende Updates gleich angestossen !

Off Topic

Zum Vergleich meine "Raupensammung" an Patches für O2010-x86 (einschl. Project und Visio).

Patches_O2010_2019-02-12.ZIP

Gruß, Nemo

[Thiersee]

Zu meiner Vorgehensweise:

Ich gehe immer von der 17763.1 aus. In die integriere ich die im ersten Beitrag genannten Patches.
Bislang (bis zur 17763.292) zeigte mir WTK nach dem Prozess immer die 17763.1 an. Nach einer Installation warf winver.exe dann trotzdem die jeweils aktuelle Build-Nr. an.
Diesmal las WTK nach der Integration des Patches für die *.316 die Build-Nr. der älteren *.292 an. Auch jetzt wurde nach der Installation die gewünschte *.316 ausgewiesen.

Dasselbe hier !

Und danke für deine Office-Liste.

LG

[Holgi]

gestern war es mal wieder soweit:
Neuinstallation von Windows Server 2019 (17763.316 nach Kumulativem Update KB4487044)

Das Kumulative Update bei .net Framework benötigt jetzt nur noch ein Update (kb4483452), aber Flash benötigt bei mir immer noch zwei Updates (kb4487038 und kb4462930). Siehe auch Hardcopy.
Der Flash Player wird bei mir direkt nach der ersten Anmeldung mit einem Powershell-Script installiert:

Code: Alles auswählen

dism /online /add-package /packagepath:"C:\Windows\Servicing\Packages\Adobe-Flash-For-Windows-Package~31bf3856ad364e35~amd64~~10.0.17763.1.mum" /NoRestart

danach wird der WLAN Service aktiviert (Install-WindowsFeature -Name Wireless-Networking)
und nach einem Neustart wird dann nach Updates gesucht.

Updates Windows Server 2019.JPG

[Nemo]

Hallo Holgi,

Meine 2019er-ISO habe ich noch nicht auf 17763.316 hochgezogen. Da sollte in den nächsten Tagen auch noch etwas wegen gemeldeter Probleme mit dem IE kommen.

Aus Erfahrung, besonders mit Server 2016, weiß ich, dass es sich empfiehlt, standardmäßig nicht-aktivierte Features oder Packages gleich in der Build *.1 zu aktivieren; und zwar vor der Integration der Patches!

Das betrifft gleichermaßen NetFx3, das bei v1809 bekanntlich seit ein paar Monaten auch von CU unabhängige Patches verpasst bekommt.
Wenn ich das richtig erkenne, hattest Du offenbar NetFx3 nicht akiviert; sonst hätte Dir WU noch den letzten kumulativen Patch für .NetFramework angeboten.

Wenn man das erst nach erfolgter Installation macht, will einem WU dann gleich das letzte CU erneut drüberbügeln, obwohl es eigentlich schon integriert schien. In Deinem Fall betrifft das wohl den FlashPlayer für den IE, den Dir WU anscheinend im Doppelpack verpasst.

Nach der von Dir ausgegrabenen Sequenz habe ich eine Batchdatei gebaut, die ich auf die Ausgangsversion *.1 anwende:

Code: Alles auswählen

@ECHO OFF
COLOR 1F
SET "QIndex=1"
SET "MOUNT-Pfad=D:\Temp\Mount"
SET "Quelle=D:\I\OS\WIN10GESX64.1809\sources\install.wim"
SET "FODquelle=D:\I\OS\WIN10GESX64.1809\sources\#FOD"
SET "UEB=FlashPlayer in Server 2019 aktivieren (Index %QIndex%)" 
TITLE %UEB% 
ECHO.
ECHO %UEB%
DISM /mount-wim /wimfile:%Quelle% /index:%QIndex% /mountdir:%MOUNT-Pfad%

ECHO.
ECHO.
ECHO ********************************************************************************
ECHO FlashPlayer wird aktiviert
ECHO ********************************************************************************
DISM /Image:%MOUNT-Pfad%  /add-package /packagepath:"%FODquelle%\Adobe-Flash-For-Windows-Package~31bf3856ad364e35~amd64~~10.0.17763.1.mum"  /packagepath:"%FODquelle%\Adobe-Flash-For-Windows-WOW64-Package~31bf3856ad364e35~amd64~~10.0.17763.1.mum"
DISM /unmount-wim /mountdir:%MOUNT-Pfad% /commit
COLOR 2F
ECHO.
ECHO Feddisch!
ECHO.
PING >NUL localhost -n 2

Die genannten Packages hatte ich einem zuvor installierten 2019 aus dem Verzeichnis %windir%\Servicing\Packages\ entnommen und im Arbeitsverzeichnis FODquelle als *.cat und *.mum bereitgestellt

Ähnlich sieht's für NetFx3 aus:

Code: Alles auswählen

@ECHO OFF
COLOR 1F
SET "QIndex=1"
SET "MOUNT-Pfad=D:\Temp\Mount"
SET "Quelle=D:\I\OS\WIN10GEWX64.1809\sources\install.wim"
SET "SXSQuelle=D:\I\OS\WIN10GEWX64.1809\sources\sxs"
SET "UEB=Feature NetFx 3.5 aktivieren (Index %QIndex%)" 
TITLE %UEB% 
ECHO.
ECHO %UEB%
DISM /mount-wim /wimfile:%Quelle% /index:%QIndex% /mountdir:%MOUNT-Pfad%
ECHO.
ECHO.
ECHO ********************************************************************************
ECHO NetFx 3.5 aktivieren
ECHO ********************************************************************************
DISM /Image:%MOUNT-Pfad%  /enable-feature /featurename:NetFx3 /Source:%SXSQuelle% /LimitAccess
ECHO.
DISM /unmount-wim /mountdir:%MOUNT-Pfad% /commit
COLOR 2F
ECHO.
ECHO Feddisch!
ECHO.
PING >NUL localhost -n 2

Die Variablen am Anfang beider Prozeduren wären anzupassen an die eigenen Dateistrukturen und an die zu bearbeitenden Editionen der Install.WIM.

Mir scheint, dass Du den Server wie eine Arbeitsstation betreibst, wenn Du den FP und auch WLAN aktivierst.

Gruß, Nemo

PS:
Setze doch bitte die in Deinem Beitrag genannten PS-Befehle in Code-Tags, indem Du sie markierst und dann das 5. Symbol von links drückst.
Dann irritieren keine Zeilenumbrüche!
Alternativ möge ihm ein Admin oder Mod das Händchen führen.

[Holgi]

Danke!
kann es sein, dass da noch ein Fehler im Script ist?
da steht 2 X
"/packagepath:"%FODquelle%\Adobe-Flash-For-Windows-WOW64-Package~31bf3856ad364e35~amd64~~10.0.17763.1.mum"
hintereinander.

Und ja: ich betreibe das BS nicht als Server, sondern als Workstation. Den Store brauche ich sowieso nicht und alles andere ist nahezu gleich.

[Nemo]

... kann es sein, dass da noch ein Fehler im Script ist? ...

Sieh genau hin: Es sind nicht dieselben MUM-Päckcchen.

Gruß, Nemo

[Holgi]

Danke für den Hinweis. Jetzt sehe ich es auch (ich Blindfisch).
Das mit dem Adobe-Flash-For-Windows-WOW64-Package~31bf3856ad364e35~amd64~~10.0.17763.1.mum
sehe ich hier zum ersten Mal. Sonst überall nur die Rede ohne "WOW64".
Kannst du mal erklären, wofür das gut ist? Müssen beide angewendet werden, oder würde auch nur das "Adobe-Flash-For-Windows-Package~31bf3856ad364e35~amd64~~10.0.17763.1" alleine reichen?
Oder hat das was mit Online Integration und Offline Integration zu tun?

[Nemo]

... Oder hat das was mit Online Integration und Offline Integration zu tun?

Wohl eher nicht. Ich wollte einfach nur sichergehen.
Sieh einfach mal nach, was --- auch in Win10 --- unter C:\Windows\servicing\Packages\Adobe-Flash-For-Windows*.* zu finden ist.

Gruß, Nemo

[Nemo]

Kurz vorm WE hauten die (wohl überforderten) Praktikanten in Redmond noch mal raus:

• Kumulatives Update (CU) KB4482887
• Dynamisches Update KB4482886 und zusätzlich
• "Kompatibilitätsupdate" KB4489491 *)
• Kumulatives Update für NetFramwork (3.5&4.72) KB4486553. Hier wurde mal wieder geschlampert:
  • Wenn man nur dieses integriert, will WU doch noch ein älteres KB4480056 vom Januar nachschieben.
  • Die Übersicht unter KB4466961 mit der Änderungshistorie verlinkt ins Nirwana

Den ersten Beitrag habe ich aktualisiert.

Gruß, Nemo

*) Nachtrag 2019-03-02 21:15h
Da ich KB4489491 erst in die Finger bekam, nachdem ich bereits die übrigen Patches in 17763.1 integiert hatte, spielte ich es in einem separaten Lauf zusätzlich in die bereits aufgebohrte Install.WIM ein.
Das Ergebnis nach der Installation in einer VM war, dass WU mir dann nochmals das CU KB4482887 aufdrückte.

Nachtrag 2019-03-03 18:00h
Zur eigenartigen interpretation der Redmonder zum Begriff "kumulativ" hat Ben@DM eine Begründung von Abbodi1406@MDL ausgegraben und in deutscher Übersetzung bereitgestellt .

... das ist genau das gleiche disfunktionale Verhalten, das in Windows 7/8.1.NET Monthly Rollups verwendet wird.

[Thiersee]

Das kann ich nur bestätigen!
Ich habe heute das alte Laptop von 2007, HP 6715b, einem Update unterzogen und bemerkt, wie blind das ganze vor sich hin gegangen ist und wie unlögisch die Update Routine gelaufen ist:

Zuerst sofort die aktuelle Updates (CU, NETFW, Flash, Defender); nach dem Neustart hat W10 bemerkt, dass zurückliegende Updates noch fehlen (KB4480056 z.B.) und hat sie samt CU heruntergeladen und installiert.
Wieder Neustart, was bei dem Laptop eine halbe Ewigkeit dauert, danach noch ein Update und wieder das obligatorische CU: insgesamt war das CU 3mal im Update-Verlauf als "erfolgreich" eingetragen!
Danach ein letztes Mal das CU und dann war Ruhe in der Kiste!
Wohl bemerkt, das Laptop hatte ich erst Ende November 2018 frisch installiert, nicht vor ein paar Jahren!

BTW, WTK zeigt immer Build .292, winver .348.

LG

[Nemo]

... Zuerst sofort die aktuelle Updates (CU, NETFW, Flash, Defender); ...

Wenn man das MSRT, das Kompatibilitätsupdate KB4489491 und den Defender mal außen vor lässt, hättest Du Dir in folgender Reihenfolge Gemeckere von WU und den ein oder anderen Neustart erspart:

1. FP 2019-02-12
2. NetFx 2019-01-08
3. NetFx 2019-03-01
4. CU 2019-03-01

Aber hinterher ist man häufig schlauer ...
Mich hat die Bastelei mit Integration (x64 und x86) und Tests in VMs auch etliche Stunden gekostet.

Wie schon mehrmals vorgeschlagen, sollte man NetFx3 und auch andere Features am besten schon in der Basisversion aktiviert haben. Ansonsten wird das CU wieder fällig.

Gruß, Nemo

[Nemo]

Zum offiziellen Patchtag gab MS frei:

• KB4489899 - Kumulatives Update (CU)
• KB4489907 - FlashPlayer-Patch

Vermisst habe ich einen Patch für .NetFramework (3.5&4.72); so bleibt es bei den älteren beiden.
Diesmal habe ich das sog. "Kompatibilitätsupdate" (KB4489491) draußen gelassen; es sollte eigentlich mit dem CU an Bord sein. Von WU kamen nach einem Test in einer VM keine Klagen.

Den ersten Beitrag habe ich aktualisiert.

Gruß, Nemo

[Thiersee]

In WTK wird wieder das richtige Build 379 ausgegeben, man darf also davon ausgehen, dass es in den letzten paar Builds nicht an WTK gelegen hat, sondern an Microsoft (mal wieder).
LG

[Nemo]

In WTK wird wieder das richtige Build 379 ausgegeben, ...

Das kann ich bestätigen; ich fand's in meinem Änderungsbeitrag aber nicht erwähnenswert.

Harren wir der Dinge in Sachen .NetFramework: Demnächst vielleicht schon mit v4.8.

Gruß, Nemo