Windows 10 per WSUS auf 1607 upgraden schlägt fehl

[Marco31 33]

Die sollen gefälligst ein funktionierendes Upgrade nachschieben was man dann guten Gewissens per WSUS verteilen kann, es ist wohl kaum zumutbar an allen Clients nach dem Upgrade manuell ein update nachzuschieben. Ist schon ziemlich peinlich was da abläuft.

[Sunny61 807]

Die sollen gefälligst ein funktionierendes Upgrade nachschieben was man dann guten Gewissens per WSUS verteilen kann, es ist wohl kaum zumutbar an allen Clients nach dem Upgrade manuell ein update nachzuschieben. Ist schon ziemlich peinlich was da abläuft.

Du brauchst hier nicht zu jammern, du mußt das schon in Redmond publizieren. Am besten machst Du einen Call auf, nur so kann etwas auch nur Ansatzweise dort ankommen, wo es ankommen soll.

 

Wie schwer ist es, so ein Update per Computerstartupscript auszurollen? Wer sich ganz vorne hinstellt bei den Neuerungen, muss auch darauf gefasst sein, dass nicht alles so wunderbar läuft, wie man es gerne hätte.

[scirocco790 11]

Kurze Rückinfo:

Mit dem Update vom September (KB3189866) melden sich meine 1607 Installationen wieder am WSUS.

[PowerShellAdmin 169]

Die Verteilung vom 1607 via WSUS lief nach dem WSUS Update problemlos.

Vorraussetzung war natürlich der ESD MIME Typ.

 

Nach dem 1607 haben die Clients keine Updates mehr vom Server bezogen - Download vom WSUS war nicht möglich.

Nach der manuellen Installation von KB3189866 geht es bei mir ebenfalls wieder...

 

Bin froh hier nur 3 Testbüchsen zu haben und mit der Umstellung noch zu warten...

 

PS: Verteilung des Updates kann man ja auch via GPO und z.B. PS Skript übernehmen.

bearbeitet 15. September 2016 von PowerShellAdmin

[Sunny61 807]

Jetzt mach ich mal den Griffelspitzer. Der WSUS verteilt nichts, gar nichts, nicht mal Freibier! Die Clients *holen*, der WSUS stellt nur zur Verfügung, wie ein stummer Diener.

 

Bevor ich so ein Update per GPO zur Installation anwerfe, mach ich das lieber per Script. Das Reporting kann ich mit dem Script steuern, per GPO geht IMO gar nichts.

[PowerShellAdmin 169]

Ja ich weiß der WSUS ist ne Prostituierte und die Clients sind seine Freier... alles gut.

 

Aber wenn wir schon so pendantisch sind:

Ich habe geschrieben, dass die Verteilung des Updates via Skript läuft.  Die GPO Dient nur zu Planung der Ausführung.

bearbeitet 15. September 2016 von PowerShellAdmin

[lefg 276]

Ja, immer wieder wird wohl fälschlich der Begriff Verteilung verwendet. Manchmal ist es aber schwierig. Verteilt die Tafel Lebensmittel oder holen die Bedürftigen diese ab? :)

 

Im Falle von WSUS drückt dieser ja aber nicht den Clients die Updates auf, diese gucken nach, holen die Updates ab. Oder?

bearbeitet 15. September 2016 von lefg

[PowerShellAdmin 169]

Mir ist es ja selber bekannt - daher auch die Analogie.

 

Ansonsten - Der technische Vorgang war mit meiner Formulierung im Detail falsch beschrieben.
Inhaltlich sieht das wieder ganz anders, da ist die Beschreibung für den Vorgang absolut i.O. und korrekt.
 

:-)

bearbeitet 15. September 2016 von PowerShellAdmin

[Sunny61 807]

Wenn von einer Verteilung ausgegangen wird, wird bei Fehlern immer an der falschen Stelle gesucht. Es macht einen Unterschied ob ich glaube der WSUS ist das Problem, oder ob ich weiß der Client ist das Problem. Und weil immer abgeschrieben wird, wird es auch die nächsten 100 Jahre leider falsch abgeschrieben.

 

Auch diese Assage ist immer falsch:

 

Der WSUS findet keine Clients.

Wenn jemand das glaubt, versucht er immer an der falschen Stelle das Problem zu lösen und hat die Technik dahinter noch nicht verstanden. In dem Fall WSUS/Clients ist das allerdings sehr simpel.

 

Bezüglich GPO und Script, das war mir schon fast klar. Aber ich kann mir auch andere Fragen vorstellen:

 

Wie kann ich ein MSU über GPO zur Installatin verteilen?

Wie schon geschrieben, ich markiere den Griffelspitzer. Aber wenn damit auch nur eine Rückfrage vermieden wird und ein Groschen gefallen ist, hat sich das ausgezahlt. :)

[PowerShellAdmin 169]

Auch diese Assage ist immer falsch:

Ich kann nachvollziehen, wieso du den technischen Vorgang - weil eben Client-Pull und nicht -Push- richtig stellst und eben eine Bereitstellung nicht Verteilung stattfindet.

Das erschließt sich ja auch indirekt aus der konkreten Situation, da das KB auf den Client aufgespielt werden muss und eben nicht via WSUS aufgespielt werden kann.

 

Dennoch bin ich der Meinung, dass das Vorgehen mit der Verteilung -logische Konsequenz- richtig beschrieben ist.

 

Wie schon geschrieben, ich markiere den Griffelspitzer. Aber wenn damit auch nur eine Rückfrage vermieden wird und ein Groschen gefallen ist, hat sich das ausgezahlt. :)

Ich weiß, sehr ich ja auch als Ergänzung ;) und ich bin doch nur ein Sturrkopf der seine ungenaue Formulierung retten will ;)

[scirocco790 11]

Seit heute gibts einen KB-Artikel zu dem Thema:

https://support.microsoft.com/en-us/kb/3194588

Mal sehen ob es damit funktioniert.

 

Edit:

Achtung, der Artikel von MS enthält einige Schreibfehler.

Im Skript muss es "delete from" und nicht "deletefrom" heissen.

Weiterhin passen einige Tabellennamen nicht, da das Skript für die Englische Sprachversion ist.

 

Mein Güte, was treiben die bei MS?

bearbeitet 23. September 2016 von scirocco790

[Pfuscher 12]

Seit heute gibts einen KB-Artikel zu dem Thema:

https://support.microsoft.com/en-us/kb/3194588

Mal sehen ob es damit funktioniert.

 

Edit:

Achtung, der Artikel von MS enthält einige Schreibfehler.

Im Skript muss es "delete from" und nicht "deletefrom" heissen.

Weiterhin passen einige Tabellennamen nicht, da das Skript für die Englische Sprachversion ist.

 

Mein Güte, was treiben die bei MS?

Ich probiere das auch grad aus.

 

Was mich immernoch abnervt ist, sobald der WSUS die 1607 auf dem Schirm hat, wird kein 1511 mehr angeboten und verteilt. Egal ob noch nicht genehmigt oder sogar abgelehnt...

 

Edit #1

 

Hier noch ein Link zum KB wo die Developer wohl reagieren: https://blogs.technet.microsoft.com/wsus/2016/09/21/resolving-error-0xc1800118

 

Edit #2

Okay, wäre mal clever gewesen von denen zu schreiben das der Block hier ein SQL Query ist. Hab ich erst auf dem dritten Blick begriffen.

// delete files from tbFile table

declare @NotNeededFiles table (FileDigest binary(20) UNIQUE);

insert into @NotNeededFiles(FileDigest) (select FileDigest from tbFile where FileName like '%14393%.esd'  except select FileDigest from tbFileForRevision);

delete from tbFileOnServer where FileDigest in (select FileDigest from @NotNeededFiles)

delete from tbFile where FileDigest in (select FileDigest from @NotNeededFiles)

Edit #3

Gut, laut dem hier:

// Detect whether WSUS is in a bad state. To do this, run the following query:

select TotalResults = Count(*)
from tbFile
where (IsEncrypted = 1 and DecryptionKey is NULL) or (FileName like '%14393%.esd' and IsEncrypted = 0)

Note A bad state is indicated by a "TotalResults > 0" result.

Darf die Abfrage nicht größer 0 (NULL) sein. Nach dem ersten Durchlauf, ist der Cout von 16 auf 12 gesunken. Kurz gegrübelt. "SearchUpdates" angepasst für 2ten Durchlauf.

// delete all update content on the current server belonging to the 1607 release

$s = Get-WsusServer

$1607Updates = $s.SearchUpdates(“version [Release]”)

$1607Updates | foreach { $_.Decline() }

$1607Updates | foreach { $s.DeleteUpdate($_.Id.UpdateId) }

Anschliessend SQL Query für 2ten Durchlauf gestartet. Anschliessend ist "TotalResults" gleich 0 (NULL)

bearbeitet 26. September 2016 von Pfuscher

[scirocco790 11]

@Pfuscher:

Hattest Du bisher Erfolg?

Ich bin bisher noch nicht dazu gekommen, das ganze mal zu testen. DIe WSUS Neuinstallationen hab ich mir gespart, da ich das in allen Werken hätte machen müssen. Irrer Aufwand.

Wenn der Weg hier funktioniert, okay.

 

Ganz lustig: Nachdem ich heute den KB-Artikel https://support.microsoft.com/en-us/kb/3194588 aufgerufen hatte wurde er mir automatisch übersetzt auf deutsch angezeigt. Inkl. aller SQL Befehle, die wurden auch mit "eingedeutscht".

Die sind zur Zeit schon ganz schön cool drauf bei MS.

bearbeitet 27. September 2016 von scirocco790

[Pfuscher 12]

Guten Morgen,

 

die ersten Clients haben in der Nacht erfolgreich von RTM (10240) und von 1511 auf 1607 aktualisiert bzw sind noch dabei (zeitplanabhängig).

 

Die KB https://support.microsoft.com/en-us/kb/3194588 wurde in der Nacht von Revision 5.0 auf 7.0 aktualisiert.

[scirocco790 11]

Funktioniert! :D :D :D

 

@Pfuscher:

Danke für Deinen kleinen Hinweis bei "Edit 3". Hatte ich übersehen, deswegen gings bei mir erst mal auch nicht.

bearbeitet 27. September 2016 von scirocco790