93
Win10 1607 und WSUS
Hi.
Es gibt ja bereits ein Update für den frischen Build 1607. Bei wem kann dieses Update (NICHT 1607 selbst, sondern das erste Update für 1607) über WSUS verteilt werden? Wenn erfolgreich, welche Modifikationen musstet Ihr dafür machen und welches WSUS-OS nutzt Ihr?
Hier gelingt der Download WSUS->Client nicht, Fortschrittsbalken steht bei 0% für immer, und ich bin nicht der Einzige: https://community.spiceworks.com/topic/1749367-windows-10-ver-1607-havin ...
Es gibt ja bereits ein Update für den frischen Build 1607. Bei wem kann dieses Update (NICHT 1607 selbst, sondern das erste Update für 1607) über WSUS verteilt werden? Wenn erfolgreich, welche Modifikationen musstet Ihr dafür machen und welches WSUS-OS nutzt Ihr?
Hier gelingt der Download WSUS->Client nicht, Fortschrittsbalken steht bei 0% für immer, und ich bin nicht der Einzige: https://community.spiceworks.com/topic/1749367-windows-10-ver-1607-havin ...
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 311563
Url: https://administrator.de/forum/win10-1607-und-wsus-311563.html
Ausgedruckt am: 23.12.2024 um 13:12 Uhr
93 Kommentare
Neuester Kommentar
Hallo DWW,
du meinst den Patch, der taggleich mit dem neuen Update erschienen ist? Der ist bei mir ganz normal im WSUS heruntergeladen und auch richtigerweise an die Clients verteilt worden...
Hier bspw:
Gemacht habe ich nichts dafür. Der Wsus läuft auf einem 2012R2:
Viele Grüße,
Belloci
du meinst den Patch, der taggleich mit dem neuen Update erschienen ist? Der ist bei mir ganz normal im WSUS heruntergeladen und auch richtigerweise an die Clients verteilt worden...
Hier bspw:
Gemacht habe ich nichts dafür. Der Wsus läuft auf einem 2012R2:
Viele Grüße,
Belloci
Hi,
habe das Problem auch. Der Windows Update Dienst beendet sich mit einer Fehlermeldung, deswegen bleibt der Download stehen.
Lösung: kurzzeitig die Verbindung zum WSUS trennen, Update normal über Internet beziehen, dann WSUS wieder aktivieren (oder die MSU manuell draufspielen).
Lg,
Chris
habe das Problem auch. Der Windows Update Dienst beendet sich mit einer Fehlermeldung, deswegen bleibt der Download stehen.
Lösung: kurzzeitig die Verbindung zum WSUS trennen, Update normal über Internet beziehen, dann WSUS wieder aktivieren (oder die MSU manuell draufspielen).
Lg,
Chris
@DerWoWusste Gib uns ruhig mal ein kleines Feedback wie es mit 2016 läuft - interessiert mich sehr!
Lieben Dank und Gruß,
Belloci
Lieben Dank und Gruß,
Belloci
So, interessante News:
auch mit TP5 keine Veränderung. Die Lösung fand sich darin, dass ich die Clients (mittlerweile 3/3, bei denen es nicht ging) mit dem Internet verbunden habe. Unsere Firma ist komplett offline, ich habe mir einen Testclient aufgesetzt, das Problem nachgestellt, und danach Internetzugang zugelassen - schwupps, es geht. Dann habe ich das Update deinstalliert, Internet weg - zack, Problem wieder da.
Belloci, könntest Du bei dir mal testen, den Internetgateway-Eintrag zu entfernen und/oder den Proxyeintrag, dann das Update zu deinstallieren und nach einem Neustart neu detektieren zu lassen? Ich würde mich nicht wundern, wenn das nicht geht.
Lustig ist, dass noch kein MS Betriebssystem vor 10 in der Stufe 1607 Internet gebraucht hätte, um mit einem WSUS zusammenzuarbeiten...
auch mit TP5 keine Veränderung. Die Lösung fand sich darin, dass ich die Clients (mittlerweile 3/3, bei denen es nicht ging) mit dem Internet verbunden habe. Unsere Firma ist komplett offline, ich habe mir einen Testclient aufgesetzt, das Problem nachgestellt, und danach Internetzugang zugelassen - schwupps, es geht. Dann habe ich das Update deinstalliert, Internet weg - zack, Problem wieder da.
Belloci, könntest Du bei dir mal testen, den Internetgateway-Eintrag zu entfernen und/oder den Proxyeintrag, dann das Update zu deinstallieren und nach einem Neustart neu detektieren zu lassen? Ich würde mich nicht wundern, wenn das nicht geht.
Lustig ist, dass noch kein MS Betriebssystem vor 10 in der Stufe 1607 Internet gebraucht hätte, um mit einem WSUS zusammenzuarbeiten...
Guten Morgen,
gib mir den Vormittag dann teste ich das. Danke für dein Feedback.
LG,
Belloci
gib mir den Vormittag dann teste ich das. Danke für dein Feedback.
LG,
Belloci
Also:
Du liegst mit deiner Vermutung richtig. Ohne Internetzugang funktioniert es anscheinend nicht.
@Chris-75 hatte gesagt, dass sich der Dienst aufhängt und das konnte ich bei mir ebenfalls feststellen. Nachdem ich den Dienst dann wieder per Hand gestartet habe, lief das Update (zwar mit einem Fehler) durch aber nach einem Neustart wird es als "installiert" angezeigt und die Buildnummer ist richtigerweise auf *.10 angehoben. Und das ist alles ohne Internetzugang geschehen. Das löst nicht das Problem aber eventuell ist das ein temporärer Workaround.
Gruß,
Belloci
Du liegst mit deiner Vermutung richtig. Ohne Internetzugang funktioniert es anscheinend nicht.
@Chris-75 hatte gesagt, dass sich der Dienst aufhängt und das konnte ich bei mir ebenfalls feststellen. Nachdem ich den Dienst dann wieder per Hand gestartet habe, lief das Update (zwar mit einem Fehler) durch aber nach einem Neustart wird es als "installiert" angezeigt und die Buildnummer ist richtigerweise auf *.10 angehoben. Und das ist alles ohne Internetzugang geschehen. Das löst nicht das Problem aber eventuell ist das ein temporärer Workaround.
Gruß,
Belloci
Danke.
Auf meinen Beitrag bei experts-exchange hin wurde mir Ähnliches berichtet. Offline geht es nicht, dann hat der Tester neu gestartet, ein paar Stunden gewartet und dann hieß es "ready for installation" - dann installiert, eine Fehlermeldung erhalten, aber es gilt danach als installiert.
Auf meinen Beitrag bei experts-exchange hin wurde mir Ähnliches berichtet. Offline geht es nicht, dann hat der Tester neu gestartet, ein paar Stunden gewartet und dann hieß es "ready for installation" - dann installiert, eine Fehlermeldung erhalten, aber es gilt danach als installiert.
Update:
Es ist und bleibt ein Bug. Auch das erste kumulative Update hat es nicht gerichtet. Das zweite kumulative Update kam gestern raus und konnte dann mit Ach und Krach installiert werden. Mal sehen, ob das die Probleme beseitigt - wir werden es erst beim nächsten Patch erfahren.
Beeindruckend ist, wieviele Dienste abstürzen, wenn der Updatebug durch Updatedetektion hervorgerufen wird, hier mal ein Auszug:
--
--
Es ist und bleibt ein Bug. Auch das erste kumulative Update hat es nicht gerichtet. Das zweite kumulative Update kam gestern raus und konnte dann mit Ach und Krach installiert werden. Mal sehen, ob das die Probleme beseitigt - wir werden es erst beim nächsten Patch erfahren.
Beeindruckend ist, wieviele Dienste abstürzen, wenn der Updatebug durch Updatedetektion hervorgerufen wird, hier mal ein Auszug:
--
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local BitLocker Drive Encryption Service 1 60000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Computer Browser 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Certificate Propagation 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Delivery Optimization 1 60000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Group Policy Client 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local IP Helper 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Server 1 60000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local User Profile Service 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Task Scheduler 1 0 4 Restart the service in a separate process
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local System Event Notification Service 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Remote Desktop Configuration 1 60000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Shell Hardware Detection 1 60000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Themes 1 60000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Windows Management Instrumentation 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Microsoft Account Sign-in Assistant 1 0 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Windows Push Notifications System Service 1 120000 1 Restart the service
8:09:40 AM 1 0 7031 Service Control Manager N/A pc.domain.local Windows Update 1 60000 1 Restart the service
7:34:50 PM 1 0 7038 Service Control Manager N/A pc.domain.local CoreMessagingRegistrar NT AUTHORITY\LocalService %%1312
1
Jap ist bei mir leider auch noch immer so (auch auf anderen Foren bereits berichtet).
Da Fragt man sich echt warum das bei den Tests vorher niemanden bei MS aufgefallen ist
Da Fragt man sich echt warum das bei den Tests vorher niemanden bei MS aufgefallen ist
Da Fragt man sich echt warum das bei den Tests vorher niemanden bei MS aufgefallen ist
Weil Microsoft nicht testet. Weil sie Ihre eigenen Technologien nicht verwenden. Weil sie WSUS nicht verwenden, kein Eventlogsammeln machen, keinen Reliability-Monitor verwenden. Weil sie dumm sind? Es gibt einfach keine Erklärung, die schlüssig ist.Auch das Insiderprogramm, an dem ja angeblich ach so viele Hotshots teilnehmen, darf in Frage gestellt werden - oder verwendet von denen keiner WSUS?
Hallo zusammen,
das hat Microsoft ja toll hinbekommen. Warum schrauben die an seit Jahren weitestgehend zuverlässig funktionierenden Bereichen herum? Ich habe alle Home- gegen Pro-Lizenzen ausgetauscht, damit ich wieder meinen WSUS verwenden kann, da ich es für unsinnig halte, dass jedes der Home-Systeme sich die Updates von Microsoft herunterladen will. Bei uns kommt es selten vor, dass gerade 2 Client-Systeme laufen, so dass das eine sich die Updates vom anderen herunterladen könnte.
Ich habe die aktuellen Patches bisher auf insgesamt 5 Rechnern installiert und dabei 3 unterschiedliche Verhaltensweisen festgestellt: Bei einem System funktionierte die Installation über WSUS ohne Probleme. Bei 3 Systemen musste man mehrere Male den Dienst "wuauserv" durchstarten und in den Systemeinstellungen zwischen den unterschiedlichen Optionen hin- und herspringen. Und ein System wollte die Patches überhaupt nicht herunterladen und installieren. Ich habe dann dort das kumulative Update auf Build 14393.51 vom MSU-Paket aus manuell installiert, den Neustart durchgeführt und schließlich hat das System die noch fehlenden Patches vom WSUS heruntergeladen und installiert.
Vielleicht hilft es ja dem einen oder anderen auch weiter, zuerst das kumulative Update auf Build 14393.51 manuell zu installieren und dann die restlichen Updates wieder über WSUS herunterzuladen und installieren zu lassen.
Bis einschließlich Windows 10 1511 war in den Einstellungen zu sehen, dass einige Optionen von Windows Update vom Administrator verwaltet werden, wenn man WSUS verwendet. Seit 1607 ist kein entsprechender Hinweis mehr zu sehen. Könnt Ihr das bestätigen?
Viele Grüße
TheExpert
das hat Microsoft ja toll hinbekommen. Warum schrauben die an seit Jahren weitestgehend zuverlässig funktionierenden Bereichen herum? Ich habe alle Home- gegen Pro-Lizenzen ausgetauscht, damit ich wieder meinen WSUS verwenden kann, da ich es für unsinnig halte, dass jedes der Home-Systeme sich die Updates von Microsoft herunterladen will. Bei uns kommt es selten vor, dass gerade 2 Client-Systeme laufen, so dass das eine sich die Updates vom anderen herunterladen könnte.
Ich habe die aktuellen Patches bisher auf insgesamt 5 Rechnern installiert und dabei 3 unterschiedliche Verhaltensweisen festgestellt: Bei einem System funktionierte die Installation über WSUS ohne Probleme. Bei 3 Systemen musste man mehrere Male den Dienst "wuauserv" durchstarten und in den Systemeinstellungen zwischen den unterschiedlichen Optionen hin- und herspringen. Und ein System wollte die Patches überhaupt nicht herunterladen und installieren. Ich habe dann dort das kumulative Update auf Build 14393.51 vom MSU-Paket aus manuell installiert, den Neustart durchgeführt und schließlich hat das System die noch fehlenden Patches vom WSUS heruntergeladen und installiert.
Vielleicht hilft es ja dem einen oder anderen auch weiter, zuerst das kumulative Update auf Build 14393.51 manuell zu installieren und dann die restlichen Updates wieder über WSUS herunterzuladen und installieren zu lassen.
Bis einschließlich Windows 10 1511 war in den Einstellungen zu sehen, dass einige Optionen von Windows Update vom Administrator verwaltet werden, wenn man WSUS verwendet. Seit 1607 ist kein entsprechender Hinweis mehr zu sehen. Könnt Ihr das bestätigen?
Viele Grüße
TheExpert
Hi.
Ja, das zweite CU scheint es gebracht zu haben. Die MSU-Datei vom kb3176495 kann über den Windows Update Cataloque vom WSUS aus runtergeladen und ins Dateisystem gespeichert werden (Haken entfernen bei "direkt in WSUS imoprtieren"). Diese MSU kann man dann geskriptet ausrollen, vermutlich mit dism.exe.
Ja, das zweite CU scheint es gebracht zu haben. Die MSU-Datei vom kb3176495 kann über den Windows Update Cataloque vom WSUS aus runtergeladen und ins Dateisystem gespeichert werden (Haken entfernen bei "direkt in WSUS imoprtieren"). Diese MSU kann man dann geskriptet ausrollen, vermutlich mit dism.exe.
Bis einschließlich Windows 10 1511 war in den Einstellungen zu sehen, dass einige Optionen von Windows Update vom Administrator verwaltet werden, wenn man WSUS verwendet. Seit 1607 ist kein entsprechender Hinweis mehr zu sehen. Könnt Ihr das bestätigen?
Ja.
Leider funktioniert WSUS weiterhin nicht. Die Updates von letzter Nacht werden erneut nicht automatisch installiert.
Die für die Windows-Updates erforderlichen Dienste beenden sich nach der Update-Suche. Ein Starten der Dienste hilft nicht weiter.
Die erforderlichen Updates werden gefunden, aber nicht vom WSUS-Server heruntergeladen. Man muss sich erneut die msu-Dateien herunterladen und die Patches manuell installieren.
Die für die Windows-Updates erforderlichen Dienste beenden sich nach der Update-Suche. Ein Starten der Dienste hilft nicht weiter.
Die erforderlichen Updates werden gefunden, aber nicht vom WSUS-Server heruntergeladen. Man muss sich erneut die msu-Dateien herunterladen und die Patches manuell installieren.
Zitat von @TheExpert:
Leider funktioniert WSUS weiterhin nicht. Die Updates von letzter Nacht werden erneut nicht automatisch installiert.
Kann das bestätigt werden?Leider funktioniert WSUS weiterhin nicht. Die Updates von letzter Nacht werden erneut nicht automatisch installiert.
bei welchem Build?
Ich habe das gleiche Problem, mit dem Unterschied, dass meine Clients ein Internetgateway haben.
Dienst neu gestartet - Problem nicht behoben
Wenn ich das richtig verstanden habe ist die einzige Möglichkeit den Fehler zu beheben, die Patches Manuell zu installieren, da es bei mir mit dem Neustart des Dienstes nicht funktioniert.
gruß fluluk
Ja ist auch bei uns immer noch so. Als Workaround habe ich bis auf weitere den WSUS auf den entsprechenden Geräten deaktiviert.
Also mit anderen Worten ist das Problem noch nicht "gelöst"...
mich wundert es nur, da ich hierher über 3 Umwege komme, alle haben das gleiche Problem und dennoch gilt das Problem in allen 3 Foren als Gelöst.
@DerWoWusste: Du schreibst, dass es bei Dir mit Internetverbindung funktioniert, ist das auch hinter einer Firewall getestet oder wurden die PCs direkt ins Internet geroutet?
gruß
fluluk
mich wundert es nur, da ich hierher über 3 Umwege komme, alle haben das gleiche Problem und dennoch gilt das Problem in allen 3 Foren als Gelöst.
@DerWoWusste: Du schreibst, dass es bei Dir mit Internetverbindung funktioniert, ist das auch hinter einer Firewall getestet oder wurden die PCs direkt ins Internet geroutet?
gruß
fluluk
ich habe meinen Thread zugemacht, da er hier schon exisitert...
Des Weiteren....auch mit dem neuen CU funktioniert der WSUS nicht...
Internetupdate dagegen einwandfrei....da wir noch nicht alle Rechner auf 1607 umgestellt haben, bleibt der Rest jetzt erst einmal auf 1511
VG
Hanuta
Des Weiteren....auch mit dem neuen CU funktioniert der WSUS nicht...
Internetupdate dagegen einwandfrei....da wir noch nicht alle Rechner auf 1607 umgestellt haben, bleibt der Rest jetzt erst einmal auf 1511
VG
Hanuta
Hi @DerWoWusste
Ich hab' mich heute Abend auch mal an das Update auf v1607 gewagt und kann nur sagen: Da hat MS einmal mehr völlig geschlafen beim Thema Qualitätssicherung!
Zu erst kann das Update selbst nicht vom WSUS heruntergeladen werden, ich musste erst die MIME-Type Zuordnung für .esd konfigurieren. Nachdem das dann geklappt hat, bin ich an zwei Maschinen auf genau die gleichen Probleme gestossen: Download weiterer Updates vom WSUS klappt schlicht nicht (WSUS bei unter 2012R2 inkl. der Patches + manueller Nachkonfiguration).
Ich hab' mir die Updates dann über den Update Catalogue runtergeladen und manuell installiert, das hat mehr oder weniger gut geklappt; die beiden Windows 10 Pro verhalten sich jetzt etwas merkwürdig, z.B. wird beim ersten Aufruf der Computerverwaltung ein Fehler ausgegeben "Stub nicht verfügbar"; dito für den Task Manager.
Ob nun die nächsten Updates wieder korrekt via WSUS ausgeliefert werden: Keine Ahnung. Aktuell sagt der WSUS, meine Win10-Systeme seien aktuell...
Cheers,
jsysde
Ich hab' mich heute Abend auch mal an das Update auf v1607 gewagt und kann nur sagen: Da hat MS einmal mehr völlig geschlafen beim Thema Qualitätssicherung!
Zu erst kann das Update selbst nicht vom WSUS heruntergeladen werden, ich musste erst die MIME-Type Zuordnung für .esd konfigurieren. Nachdem das dann geklappt hat, bin ich an zwei Maschinen auf genau die gleichen Probleme gestossen: Download weiterer Updates vom WSUS klappt schlicht nicht (WSUS bei unter 2012R2 inkl. der Patches + manueller Nachkonfiguration).
Ich hab' mir die Updates dann über den Update Catalogue runtergeladen und manuell installiert, das hat mehr oder weniger gut geklappt; die beiden Windows 10 Pro verhalten sich jetzt etwas merkwürdig, z.B. wird beim ersten Aufruf der Computerverwaltung ein Fehler ausgegeben "Stub nicht verfügbar"; dito für den Task Manager.
Ob nun die nächsten Updates wieder korrekt via WSUS ausgeliefert werden: Keine Ahnung. Aktuell sagt der WSUS, meine Win10-Systeme seien aktuell...
Cheers,
jsysde
Ja, die Fehlermeldung "Stub nicht verfügbar" beim ersten Aufruf des Task Managers kann ich bestätigen - zumindest für Build 14393.82. Allerdings kommt diese bei mir nicht immer beim ersten Aufruf.
Gestern Abend habe ich von WSUS den Hinweis erhalten, dass ein neues CU bereitsteht. Leider musste ich das wieder manuell installieren. Jetzt habe ich Build 14393.105. Die Fehlermeldung "Stub nicht verfügbar" habe ich bisher nicht erhalten, aber das muss noch nichts heißen, denn diese ist nicht immer aufgetreten.
Ich frage mich, wann Microsoft endlich die Patchverteilung per WSUS wieder zum Laufen bringt... Es ist nervig, das ständig von Hand installieren zu müssen - auch wenn ich nur eine handvoll Rechner in meinem Heimnetz zu betreuen habe.
Gestern Abend habe ich von WSUS den Hinweis erhalten, dass ein neues CU bereitsteht. Leider musste ich das wieder manuell installieren. Jetzt habe ich Build 14393.105. Die Fehlermeldung "Stub nicht verfügbar" habe ich bisher nicht erhalten, aber das muss noch nichts heißen, denn diese ist nicht immer aufgetreten.
Ich frage mich, wann Microsoft endlich die Patchverteilung per WSUS wieder zum Laufen bringt... Es ist nervig, das ständig von Hand installieren zu müssen - auch wenn ich nur eine handvoll Rechner in meinem Heimnetz zu betreuen habe.
jap...neues kb update, behebt den Fehler nicht -.-
VG
Hanuta
VG
Hanuta
N'Abend.
Ich konnte heute Abend das gestern bereitgestellte Update problemlos via WSUS installieren - das ursprüngliche Problem sollte damit also erledigt sein, sofern man erstmal den WSUS konfiguriert und die genannten Updates manuell installiert hat.
Cheers,
jsysde
Ich konnte heute Abend das gestern bereitgestellte Update problemlos via WSUS installieren - das ursprüngliche Problem sollte damit also erledigt sein, sofern man erstmal den WSUS konfiguriert und die genannten Updates manuell installiert hat.
Cheers,
jsysde
@jsysde:
Vielen Dank und viele Grüße
TheExpert
- Welche Updates müssen manuell installiert sein, damit die Patchverteilung via WSUS wieder funktioniert?
- Muss im WSUS etwas umkonfiguriert werden? Hast Du WSUS über GPOs der Domäne konfiguriert oder arbeitest Du mit Registry-Settings für Rechner ohne Domänenmitgliedschaft?
Vielen Dank und viele Grüße
TheExpert
Hallo,
ich habe folgende Updates manuell installiert:
KB3176929, KB3176495, KB3176934
Gestern habe ich KB3176938 manuell installiert; KB3189031 (Adobe Flash Player) welches ich heute morgen freigegeben habe wurde vom WSUS gezogen, ich möchte allerdings nichts 100% Garantieren, da ich es gerade bei einem Test PC probieren konnte.
gruß fluluk
ich habe folgende Updates manuell installiert:
KB3176929, KB3176495, KB3176934
Gestern habe ich KB3176938 manuell installiert; KB3189031 (Adobe Flash Player) welches ich heute morgen freigegeben habe wurde vom WSUS gezogen, ich möchte allerdings nichts 100% Garantieren, da ich es gerade bei einem Test PC probieren konnte.
gruß fluluk
Hallo,
KB3189031 wurde bei mir heute automatisch per WSUS verteilt und installiert. Das heißt aber noch nicht, dass das Thema gelöst ist, denn diese Situation hatte ich schon am 12.08. hier beschrieben: Nach der manuellen CU-Installation wurden die anderen Patches ohne Fehler per WSUS verteilt und installiert - na ja, bereitgestellt und durch die Clients installiert.
Es wäre natürlich schön, wenn auch die CUs nun per WSUS bereitgestellt und von den Clients dort heruntergeladen und dann installiert werden. Leider sehen wir das erst beim Erscheinen des nächsten CUs. Und nach den bisherigen Erfahrungen möchte ich nicht glauben, dass dieses Thema erledigt ist. Ich glaube, dass uns das noch einige Zeit verfolgen wird.
Gruß
TheExpert
KB3189031 wurde bei mir heute automatisch per WSUS verteilt und installiert. Das heißt aber noch nicht, dass das Thema gelöst ist, denn diese Situation hatte ich schon am 12.08. hier beschrieben: Nach der manuellen CU-Installation wurden die anderen Patches ohne Fehler per WSUS verteilt und installiert - na ja, bereitgestellt und durch die Clients installiert.
Es wäre natürlich schön, wenn auch die CUs nun per WSUS bereitgestellt und von den Clients dort heruntergeladen und dann installiert werden. Leider sehen wir das erst beim Erscheinen des nächsten CUs. Und nach den bisherigen Erfahrungen möchte ich nicht glauben, dass dieses Thema erledigt ist. Ich glaube, dass uns das noch einige Zeit verfolgen wird.
Gruß
TheExpert
Moin.
Die GPO tut nix anderes, als Reg-Werte zu setzen, daher irrelevant.
Cheers,
jsysde
* Welche Updates müssen manuell installiert sein, damit die Patchverteilung via WSUS wieder funktioniert?
KB3176929, KB3176495, KB3176934.* Muss im WSUS etwas umkonfiguriert werden?
Nope.Hast Du WSUS über GPOs der Domäne konfiguriert oder arbeitest Du mit Registry-Settings für Rechner ohne Domänenmitgliedschaft?
Welche Rolle spielt das?Die GPO tut nix anderes, als Reg-Werte zu setzen, daher irrelevant.
Cheers,
jsysde
Hallo,
Ich kann nicht bestätigen, dass der Fehler mit der manuellen Installation der genannten Updates behoben ist. Ich musste auch das CU für das aktuelle Build 14393.105 manuell installieren - trotz der Tatsache, dass ich bereits Build 14393.82 (KB3176934) installiert hatte.
Für mich sieht es derzeit so aus, dass CUs nicht per WSUS verteilt werden können. Andere Updates, z. B. das letzte Update für den Flash Player wurde zumindest bei mir via WSUS verteilt und installiert bzw. haben sich die Clients das Update vom WSUS-Server heruntergeladen und installiert..
Viele Grüße
TheExpert
Ich kann nicht bestätigen, dass der Fehler mit der manuellen Installation der genannten Updates behoben ist. Ich musste auch das CU für das aktuelle Build 14393.105 manuell installieren - trotz der Tatsache, dass ich bereits Build 14393.82 (KB3176934) installiert hatte.
Für mich sieht es derzeit so aus, dass CUs nicht per WSUS verteilt werden können. Andere Updates, z. B. das letzte Update für den Flash Player wurde zumindest bei mir via WSUS verteilt und installiert bzw. haben sich die Clients das Update vom WSUS-Server heruntergeladen und installiert..
Viele Grüße
TheExpert
Hallo zusammen,
ich klink mich hier mal ein da ich ein Problem mit einem WSUS (Server 2008R2) und Windows 10 (1607) habe.
Seit dem Upgrade auf die 1607er Version werden die Clients brav im WSUS angezeigt und die Gruppenrichtlinie greift wohl laut RSOP auch. Leider gibt es keinen Hinweis mehr darauf das die Updates vom Administrator verwaltet werden und die Clients machen brav ihre Updates übers Internet.
Bei den Clients mit 1511 funktioniert alles wie es soll (bis jetzt).
Hat jemand eine Idee woran das liegen kann? Gibt es seit dem 1607er Upgrade wieder ein Update für die GPO's oder den WSUS?
Vielen Dank für eure Ideen.
LG Chris
ich klink mich hier mal ein da ich ein Problem mit einem WSUS (Server 2008R2) und Windows 10 (1607) habe.
Seit dem Upgrade auf die 1607er Version werden die Clients brav im WSUS angezeigt und die Gruppenrichtlinie greift wohl laut RSOP auch. Leider gibt es keinen Hinweis mehr darauf das die Updates vom Administrator verwaltet werden und die Clients machen brav ihre Updates übers Internet.
Bei den Clients mit 1511 funktioniert alles wie es soll (bis jetzt).
Hat jemand eine Idee woran das liegen kann? Gibt es seit dem 1607er Upgrade wieder ein Update für die GPO's oder den WSUS?
Vielen Dank für eure Ideen.
LG Chris
Also ich habe das gleiche Problem seit dem Update/Upgrade auf 1607.
im Powershell Modul PSWindowsUpdate kann man per Get-WuServiceManager die Daten abfragen und es es zeigt sich auf allen unseren Win10 1607 folgendes Bild:
PS C:\WINDOWS\system32> Get-WUServiceManager
ServiceID IsManaged IsDefault Name
--------- --------- ----
7971f918-a847-4430-9279-4a52d1efe18d False True Microsoft Update
117cab2d-82b1-4b5a-a08c-4d62dbee7782 False False Windows Store
855e8a7c-ecb4-4ca3-b045-1dfa50104289 False False Windows Store (DCat Prod)
3da21691-e39d-4da6-8a4b-b43877bcb1b7 True False Windows Server Update Service
9482f4b4-e343-43b6-b170-9a65bc822c77 False False Windows Update
es sind alle CU installiert bis heute.
Hoffe dass ein kommendes Update das Problem löst... :/
im Powershell Modul PSWindowsUpdate kann man per Get-WuServiceManager die Daten abfragen und es es zeigt sich auf allen unseren Win10 1607 folgendes Bild:
PS C:\WINDOWS\system32> Get-WUServiceManager
ServiceID IsManaged IsDefault Name
--------- --------- ----
7971f918-a847-4430-9279-4a52d1efe18d False True Microsoft Update
117cab2d-82b1-4b5a-a08c-4d62dbee7782 False False Windows Store
855e8a7c-ecb4-4ca3-b045-1dfa50104289 False False Windows Store (DCat Prod)
3da21691-e39d-4da6-8a4b-b43877bcb1b7 True False Windows Server Update Service
9482f4b4-e343-43b6-b170-9a65bc822c77 False False Windows Update
es sind alle CU installiert bis heute.
Hoffe dass ein kommendes Update das Problem löst... :/
Zur Info:
MS hat in einem Technetforum angekündigt, das Problem (1607 Updatedienst buggy) mit dem nächsten CU (erscheint am 13.9.) zu beheben.
MS hat in einem Technetforum angekündigt, das Problem (1607 Updatedienst buggy) mit dem nächsten CU (erscheint am 13.9.) zu beheben.
1
Na da sind mehr mal gespannt 
Vielen Dank für die Info
VG
Vielen Dank für die Info
VG
Ein Segen...
Danke für die Info!
Danke für die Info!
Der besagte Thread ist übrigens: https://social.technet.microsoft.com/Forums/office/en-US/5521e7f1-fa2d-4 ... ->Steve Henry's Kommentar
2. Clients have upgraded to 1706 using Anniversary Update, but cannot get Cumulative Updates
This is a bug in the Windows client that will be fixed in an upcoming cumulative update. In the meantime, clients may experience some delay in getting the monthly content, but they will eventually download it. The workaround here is to simply wait longer than usual, or to scan directly against Windows Update if you've waited several days and haven't seen any download success in that time. Ich denke er meint 1607.
Kommt es denn heute Nacht?
Ja, sollte kommen.
Ob dieses Update dann wirklich funktioniert werden wir erst beim Erscheinen des nächsten sehen ...
Bei uns ist es heute nicht auf dem WSUS aufgetaucht ...
VG
VG
dito
bei mir schon...
KB3189866
der WSUS lädt es gerade herunter. Dank 1607 ist allerdings unsere Internetverbindung nicht mehr zu gebrauchen und der Download dauert entsprechend lange...
Ich werde berichten sobald ich es auf den ersten Clients verteilt habe.
gruß fluluk
KB3189866
der WSUS lädt es gerade herunter. Dank 1607 ist allerdings unsere Internetverbindung nicht mehr zu gebrauchen und der Download dauert entsprechend lange...
Ich werde berichten sobald ich es auf den ersten Clients verteilt habe.
gruß fluluk
okay...sync nochmal manuell angestossen, jetzt hat ers auch
Wie willst du das den verteilen?
Das Problem ist doch gerade, dass sich die Updates nicht verteilen lassen.
Das Problem ist doch gerade, dass sich die Updates nicht verteilen lassen.
Huhu,
wir haben noch eine Softwareverteilung, mit der ich das Update manuell verteilen kann
bzw. kannst du das ja auch über die GPOs verteilen.
VG
Hanuta
wir haben noch eine Softwareverteilung, mit der ich das Update manuell verteilen kann
bzw. kannst du das ja auch über die GPOs verteilen.
VG
Hanuta
Ich befürchte, dass das Kumulative Update KB3189866 das Problem überhaupt nicht adressiert.
Nur Updates für Office und C++ Redistributable werden über WSUS geladen, das Sicherheitsupdate für den Flash Player KB3188128 und das Update KB3176936 wurden ohne mein Zutun über P2P bezogen.
Nur Updates für Office und C++ Redistributable werden über WSUS geladen, das Sicherheitsupdate für den Flash Player KB3188128 und das Update KB3176936 wurden ohne mein Zutun über P2P bezogen.
Bei funktioniert jetzt alles mit folgenden Setup:
WSUS = Windows 2012R2 mit Hotfix KB3095113 und KB3159706 (inkl. Nacharbeiten und MIME Type ESD)
Policy -> Downloadmodus = aktiviert und Modus auf "Umgehen" gestellt
Policy -> Keine Verbindugen mit Windows Update-Internetadressen herstellen = aktiviert
Client: Windows 10 Build 14393.0 mit kb3176936
PSWindowsUpdate Ergebnis:
ServiceID IsManaged IsDefault Name
3da21691-e39d-4da6-8a4b-b43877bcb1b7 True True Windows Server Update Service
9482f4b4-e343-43b6-b170-9a65bc822c77 False False Windows Update
WSUS = Windows 2012R2 mit Hotfix KB3095113 und KB3159706 (inkl. Nacharbeiten und MIME Type ESD)
Policy -> Downloadmodus = aktiviert und Modus auf "Umgehen" gestellt
Policy -> Keine Verbindugen mit Windows Update-Internetadressen herstellen = aktiviert
Client: Windows 10 Build 14393.0 mit kb3176936
PSWindowsUpdate Ergebnis:
ServiceID IsManaged IsDefault Name
3da21691-e39d-4da6-8a4b-b43877bcb1b7 True True Windows Server Update Service
9482f4b4-e343-43b6-b170-9a65bc822c77 False False Windows Update
Und das meint Microsoft wirklich ernst?
Wir sollen jetzt selber durch Trial & Error herauabekommen, wie das geht?
Microsoft, wo kann ich das White Paper herunterladen?
Wir sollen jetzt selber durch Trial & Error herauabekommen, wie das geht?
Microsoft, wo kann ich das White Paper herunterladen?
Ich klinke mich jetzt auch mal mit ein.
Win 10 1607 Fehler beim Update 0x8024500c auch nach allen Einstellungen und KB.
Win 10 1511 Ohne Probleme.
Hat jemand noch den Komischen Fehler?
Google findet nicht wirklich was dazu
Win 10 1607 Fehler beim Update 0x8024500c auch nach allen Einstellungen und KB.
Win 10 1511 Ohne Probleme.
Hat jemand noch den Komischen Fehler?
Google findet nicht wirklich was dazu
Den Fehler hatte ich auch und das ist wohl ein Bug. Workaround: deaktivierte die Option Featureupgrades zurückstellen in den Einstellungen -> Updates. Danach hat es bei mir funktioniert
2
Super!! Was habe ich da nach dem Fehler gesucht...
Microsoft´s QM sollte mal WIRKLICH getreten werden.....
Sowas kostet nur Zeit,Geld und Nerven......
Microsoft´s QM sollte mal WIRKLICH getreten werden.....
Sowas kostet nur Zeit,Geld und Nerven......
Bei mir läuft es jetzt auch wieder. Falls noch jemand nach einer Lösung sucht, hier noch mal die Zusammenfassung:
Fehler:
Windows 10 Clients mit Version 1607 laden keine Updates von einem internen WSUS-Server (Download hängt bei 0%)
Lösung:
KB3189866 manuell installieren
Danke an alle für die Hilfe!
Fehler:
Windows 10 Clients mit Version 1607 laden keine Updates von einem internen WSUS-Server (Download hängt bei 0%)
Lösung:
KB3189866 manuell installieren
Danke an alle für die Hilfe!
Der Fehler ist leider falsch dargestellt. 1607 lädt schon Updates, nur leider keine kumulativen. Ob es also mit KB3189866 behoben ist, wird der hoffentlich erfolgreiche Download des nächsten CUs zeigen. Dieses kommt in ca 2 Wochen.
Jetzt noch wieder ein weiteres Problem.
Bei manchen Rechnern ist der haken Featureupgrades zurückstellen ausgegraut....
Hatte das per GPO eingestellt gehabt, aber wieder zurückgenommen.
Dennoch kann ich den Haken nicht Markieren/Demarkieren.
Hat jemand auch noch das Problem?
Jetzt habe ich mal getestet. Wenn ich das Windows zurück setzte ist es nicht ausgegraut.
Sobald ich aber nur "einmal" nach updates suchen lasse über den WSUS wird es sofort grau.
In der GPO ist der haken aber nicht gesetzt(mehrfach gescheckt mit rsop und gpresult).
Bei manchen Rechnern ist der haken Featureupgrades zurückstellen ausgegraut....
Hatte das per GPO eingestellt gehabt, aber wieder zurückgenommen.
Dennoch kann ich den Haken nicht Markieren/Demarkieren.
Hat jemand auch noch das Problem?
Jetzt habe ich mal getestet. Wenn ich das Windows zurück setzte ist es nicht ausgegraut.
Sobald ich aber nur "einmal" nach updates suchen lasse über den WSUS wird es sofort grau.
In der GPO ist der haken aber nicht gesetzt(mehrfach gescheckt mit rsop und gpresult).
Das Problem habe ich auch: Windows 10 (1607) Clients melden sich zwar auf dem WSUS Sever (läuft auf einem Server 2012 R2, Einstellungen werden per Gruppenrichtlinie verteilt an die Clients), holen sich die Updates aber trotzdem direkt aus dem Internet. Auch solche Upates, die ich per WSUS gar nicht freigegeben habe. Im Endeffekt verhalten sie sich also so, als wenn sie gar nicht am WSUS hängen würden. Sobald MS Patches bei Windows Update freigibt, holen sich die 1607er Clients die Sachen aus dem Internet.
Alle anderen Clients (Windows 7 und Windows 10 ohne Anniversary Update) verhalten sich normal und holen nur die von mir genehmigten Updates vom WSUS, nicht aus dem Internet.
Habe diesen Thread durchgelesen, aber für dieses spezielle Problem keine Antwort gefunden (habe hoffentlich nichts überlesen).
Was kann man da machen?
Gruß
Andreas
Alle anderen Clients (Windows 7 und Windows 10 ohne Anniversary Update) verhalten sich normal und holen nur die von mir genehmigten Updates vom WSUS, nicht aus dem Internet.
Habe diesen Thread durchgelesen, aber für dieses spezielle Problem keine Antwort gefunden (habe hoffentlich nichts überlesen).
Was kann man da machen?
Gruß
Andreas
Ich für meinen Teil warte erstmal auf das nächste CU von Microdoof.
Das runterladen aus dem Netz kannst du auch per gpo verbieten falls du das möchtest ;) Ich mache es alleine nur um schon zu wissen wann es wieder klappt :D
Das runterladen aus dem Netz kannst du auch per gpo verbieten falls du das möchtest ;) Ich mache es alleine nur um schon zu wissen wann es wieder klappt :D
Kann es sein, dass KB3189866 zurück gezogen wurde?
ich finde es nämlich nichtmehr im Update Katalog
ich finde es nämlich nichtmehr im Update Katalog
...und Server 2016, der ja nun erschienen ist knapp 2 Monate nach 1607? Hat natürlich das gleiche Problem. Und natürlich ebenso das "the stub received bad data"-Problem. Lösung: wie gehabt, auf dem WSUS die Update-Katalog-Website öffnen, KB3192366 suchen und separat runterladen als .msu-Datei und auf dem 2016er-Server installieren.
Setzt Microsoft seine eigenen Produkte eigentlich selbst ein? Nutzen die kein Win10, keinen Server 2016, keinen WSUS? Es ist absurd. Selbst wenn sie intern keinen WSUS nutzen, sondern SCCM, müssen sie doch mal mit WSUS getestet haben.
Setzt Microsoft seine eigenen Produkte eigentlich selbst ein? Nutzen die kein Win10, keinen Server 2016, keinen WSUS? Es ist absurd. Selbst wenn sie intern keinen WSUS nutzen, sondern SCCM, müssen sie doch mal mit WSUS getestet haben.
Erst mal ein "Hallo" an alle.
ich habe mich auch schon länger mit dem Thema beschäftigt, da meine 10 Clients mit 1607 das beschriebene Verhalten aufzeigen.
Melden sich beim WSUS, aber keine Updates, oder melden sich erst gar nicht.
Das beschriebene KB3189866 wurde ersetzt durch KB3193494.
https://www.windows-faq.de/2016/09/21/kb3193494-kumulatives-update-erset ...
Nach der manuellen Installation auf den Clients haben sich alle Clients beim WSUS gemeldet und Updates gesucht, bzw. wenigstens einen Statusbericht erstellt.
Unter Windows Update erscheint nun auch "Online nach Updates suchen" und WindowsupdateLog zeigt keinen Fehler mehr.
Der WSUS selbst macht aber immer noch den Fehler, das er keinen Bericht erstellen kann.
Berichte werden auf dem WSUS aber aktualisiert, wenn man am Client "Updates suchen" ausführt.
Soviel erstmal dazu.
PS: Tolles Forum... hat mir schon öfter geholfen
ich habe mich auch schon länger mit dem Thema beschäftigt, da meine 10 Clients mit 1607 das beschriebene Verhalten aufzeigen.
Melden sich beim WSUS, aber keine Updates, oder melden sich erst gar nicht.
Das beschriebene KB3189866 wurde ersetzt durch KB3193494.
https://www.windows-faq.de/2016/09/21/kb3193494-kumulatives-update-erset ...
Nach der manuellen Installation auf den Clients haben sich alle Clients beim WSUS gemeldet und Updates gesucht, bzw. wenigstens einen Statusbericht erstellt.
Unter Windows Update erscheint nun auch "Online nach Updates suchen" und WindowsupdateLog zeigt keinen Fehler mehr.
Der WSUS selbst macht aber immer noch den Fehler, das er keinen Bericht erstellen kann.
Berichte werden auf dem WSUS aber aktualisiert, wenn man am Client "Updates suchen" ausführt.
Soviel erstmal dazu.
PS: Tolles Forum... hat mir schon öfter geholfen
@thomas
das Problem tritt auf wenn die Policy "Bei Empfang von Funktionsupdate auswählen" aktiviert ist. Dabei spielt es keine Rolle ob der Haken "Funktionsupdates aussetzen" aktiviert ist.
Bitte überprüfe folgenden Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
wenn Du dort folgende Einträge findest, ist die Policy "aktiviert":
BranchReadinessLevel
DeferFeatureUpdates
DeferFeatureUpdatesPeriodInDays
wenn Du diese entfernst und dann nach Updates suchst, ist der Haken nicht mehr ausgegraut
das Problem tritt auf wenn die Policy "Bei Empfang von Funktionsupdate auswählen" aktiviert ist. Dabei spielt es keine Rolle ob der Haken "Funktionsupdates aussetzen" aktiviert ist.
Bitte überprüfe folgenden Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
wenn Du dort folgende Einträge findest, ist die Policy "aktiviert":
BranchReadinessLevel
DeferFeatureUpdates
DeferFeatureUpdatesPeriodInDays
wenn Du diese entfernst und dann nach Updates suchst, ist der Haken nicht mehr ausgegraut
Habe einen entscheidenden Hinweis zu meinem Problem gefunden (Post vom 28.09.2016, Win10 1607er Clients holen Updates aus dem Internet statt vom WSUS). Das Problem hängt wohl mit dem Schalter "Featureupdates zurückstellen" unter Windows 10 zusammen. Ist dieser gesetzt, schaut Windows 10 Version 1607 bei MS im Internet nach Updates statt beim WSUS. Ist natürlich ein Bug, der angeblich bald behoben werden soll. Bei uns ist dieses Feld per GPO deaktiviert worden, was aber wohl den gleichen Effekt erzeugt.
Siehe hier: https://social.technet.microsoft.com/Forums/windowsserver/en-US/5521e7f1 .... Der Beitrag vom "Thursday, September 22, 2016 10:35 PM" von "Steve Henry [MSFT]".
Gruß
Andreas
Siehe hier: https://social.technet.microsoft.com/Forums/windowsserver/en-US/5521e7f1 .... Der Beitrag vom "Thursday, September 22, 2016 10:35 PM" von "Steve Henry [MSFT]".
Gruß
Andreas
1
Edit:
Also ich kann sagen, das meine Client’s sich heute brav beim WSUS gemeldet haben.
Notebooks und Workstations sind in unterschiedlichen OU’s mit unterschiedlichen GPO’s.
Beide haben so funktioniert wie Sie sollen.
Notebooks sollen melden, dass Updates verfügbar sind
Workstations sollen installieren, nur den Neustart selbst entscheiden lassen, oder beim Runterfahren.
Beide haben heute das Kumulative Update KB3194496 heruntergeladen und installiert.
Bericht im WSUS wurde auch aktualisiert.
Der WSUS selbst macht aber immer noch den Fehler, wenn man auf „Statusbericht“ klickt.
Da Arbeite ich am Dienstag weiter…
Schönes Wochenende
Also ich kann sagen, das meine Client’s sich heute brav beim WSUS gemeldet haben.
Notebooks und Workstations sind in unterschiedlichen OU’s mit unterschiedlichen GPO’s.
Beide haben so funktioniert wie Sie sollen.
Notebooks sollen melden, dass Updates verfügbar sind
Workstations sollen installieren, nur den Neustart selbst entscheiden lassen, oder beim Runterfahren.
Beide haben heute das Kumulative Update KB3194496 heruntergeladen und installiert.
Bericht im WSUS wurde auch aktualisiert.
Der WSUS selbst macht aber immer noch den Fehler, wenn man auf „Statusbericht“ klickt.
Da Arbeite ich am Dienstag weiter…
Schönes Wochenende
Jupp, bei mir auch, es geht und somit Fall erledigt.
Nix erledigt.
Meine clients melden immer noch an den WSUS "keine Updates erforderlich" und laden das Update über das Internet.
Wie muss ich denn meine Gruppenrichtlinien anpassen, damit es klappt?
Meine clients melden immer noch an den WSUS "keine Updates erforderlich" und laden das Update über das Internet.
Wie muss ich denn meine Gruppenrichtlinien anpassen, damit es klappt?
Du musst nichts anpassen. Nimm einen WSUS auf Server 2008 oder höher, patch den durch und ein Win10 1607, installiere dort von Hand das letzte kumulative Update für win10. Danach kann Win10 problemlos Updates vom WSUS beziehen.
Die Frage "wie kann ich major updates per WSUS verteilen", also z.B. 1511->1607 über WSUS durchführen, ist eine völlig andere. Laut MS braucht man dazu einen WSUS 2012 , an dem auch Anpassungen vorgenommen werden müssen. Diese Anpassungen hatte ich mal testhalber durchgeführt, es ging danach auch bei einigen 1511ern, dass 1607 Update vom WSUS runteruladen, aber nicht bei allen und somit ist das für mich endgültig gestorben. Major Updates werden bei mir nun nur noch per Skript verteilt, da hat man eh mehr Kontrolle als beim WSUS.
Die Frage "wie kann ich major updates per WSUS verteilen", also z.B. 1511->1607 über WSUS durchführen, ist eine völlig andere. Laut MS braucht man dazu einen WSUS 2012 , an dem auch Anpassungen vorgenommen werden müssen. Diese Anpassungen hatte ich mal testhalber durchgeführt, es ging danach auch bei einigen 1511ern, dass 1607 Update vom WSUS runteruladen, aber nicht bei allen und somit ist das für mich endgültig gestorben. Major Updates werden bei mir nun nur noch per Skript verteilt, da hat man eh mehr Kontrolle als beim WSUS.
OMG, DANKE, ich suche schon seit Tagen nach der korrekten Lösung und war falsch gewickelt, da ich die Lösung in einer falschen GPO oder sonstigen Misskonfiguration meines WSUS vermutet hatte. Kaum hatte ich den Haken bei "Featureupdates zurückstellen" draußen, schon hat alles geklappt, danke dir
Weiß zufällig, ob sich diese Option für User ausgrauen lässt per GPO?
Weiß zufällig, ob sich diese Option für User ausgrauen lässt per GPO?
Tut mir leid, es geht nicht.
Die Windows 10 clients reporten immer, dass sie keine Updates benötigen und laden dann die Updates aus dem Internet.
Ich werde gar nicht gefragt, ob ich die freigeben will.
Die Windows 10 clients reporten immer, dass sie keine Updates benötigen und laden dann die Updates aus dem Internet.
Ich werde gar nicht gefragt, ob ich die freigeben will.
Ich kann Dir nur sagen, wie es ist. Out of the box kann ein durchgepatchter 2008 Server mit WSUS Windows 10 mit Updates versorgen.
Hi, also ich kann dir gerne sagen, wie ich es gemacht habe. Wie ich gehört habe, sollte auch ein 2008 R2 Server Windows 10 Clients versorgen können, da kann ich nicht mehr mitreden, ich habe auf 2012 R2 umgestellt und damit funktioniert es so:
1. Die neuesten ADMX-Files laden, die wurden von Microsoft zum letzten Funktionsupdate neu herausgegeben und man erhält sie hier: https://www.microsoft.com/de-DE/download/details.aspx?id=53430 (ggf. Sprache ändern). Das dann wie immer auf den DC und replizieren lassen. Es gibt dort in den WSUS-Einstellungen ein paar Änderungen, die Windows 10 betreffen.
2. Patch deinen WSUS zum aktuellsten Stand, aktuell bedeutet jetzt 6.3.9600.18324 (ich hab allerdings die Updates von dieser Woche noch nicht freigegeben, weiß also nicht ob es nicht schon einen höheren STand gibt). Die Version kannst du im Hauptbildschirm der WSUS-Konsole auslesen (nicht über ? > Info über WSUS Updates, dort kommt ne andere Version).
3. Stelle sicher, dass du KB3159706 installiert hast und führe folgende Schritte aus, damit die Kommunikation wirklich klappt: https://support.microsoft.com/en-us/kb/3159706
4. Wenn du, wie ich, eine GPO für deine Clients hast, die nur die Hand voll Einstellungen für den WSUS enthält, lösch die alte und mach eine neue. Hier empfehle ich, was natürlich jetzt nur für meine Umgebung ausreichend ist, dir zumindest folgende Settings.
PS: wenn dein WSUS noch nicht über HTTPS laufen sollte, hole das noch nach. Ist keine große Umstellung und Dokus dazu findest du überall im Netz.
1. Die neuesten ADMX-Files laden, die wurden von Microsoft zum letzten Funktionsupdate neu herausgegeben und man erhält sie hier: https://www.microsoft.com/de-DE/download/details.aspx?id=53430 (ggf. Sprache ändern). Das dann wie immer auf den DC und replizieren lassen. Es gibt dort in den WSUS-Einstellungen ein paar Änderungen, die Windows 10 betreffen.
2. Patch deinen WSUS zum aktuellsten Stand, aktuell bedeutet jetzt 6.3.9600.18324 (ich hab allerdings die Updates von dieser Woche noch nicht freigegeben, weiß also nicht ob es nicht schon einen höheren STand gibt). Die Version kannst du im Hauptbildschirm der WSUS-Konsole auslesen (nicht über ? > Info über WSUS Updates, dort kommt ne andere Version).
3. Stelle sicher, dass du KB3159706 installiert hast und führe folgende Schritte aus, damit die Kommunikation wirklich klappt: https://support.microsoft.com/en-us/kb/3159706
4. Wenn du, wie ich, eine GPO für deine Clients hast, die nur die Hand voll Einstellungen für den WSUS enthält, lösch die alte und mach eine neue. Hier empfehle ich, was natürlich jetzt nur für meine Umgebung ausreichend ist, dir zumindest folgende Settings.
PS: wenn dein WSUS noch nicht über HTTPS laufen sollte, hole das noch nach. Ist keine große Umstellung und Dokus dazu findest du überall im Netz.
@snakerl: Du brauchst keine neuen ADMX-Files, damit Win10 gepatcht wird, nein. Es gibt für den Updatedienst in Win10 genau eine neue Option: "Defer Upgrade". Du siehst, es ist unnötig.
Aber warum soll ich veraltete ADMX-Dateien verwenden, wenn Microsoft extra für ihr Release des Funktionsupdates 1603 neue ADMX-Dateien bereitstellt?
Meiner Meinung nach geht man auf Nummer sicher, wenn man für Windows 10 1603 auch die ADMX-Dateien von 1603 verwendet anstatt der 1511er oder älter.
Es kann somit nicht schaden, die neuesten ADMX-Dateien zu verwenden und die wenigen Einstellungen (s. Screenshots) nochmal kurz per Hand zu setzen. Ist aber nur eine warme Empfehlung. Natürlich kann man gerne auch versuchen, die ADMX-Dateien von vor einem Jahr weiter zu verwenden. Ich behaupte nicht, dass es unmöglich wäre, einen Windows 10 1603er Client damit zu patchen
Ich hab noch ne kleine Ergänzung zu den GPO-Screenshots:
- Definieren der Reihenfolge der Quellen für das Herunterladen von Definitionsupdates InternalDefinitionUpdateServer | MicrosoftUpdateServer | MMPC > Kann unter Umständen zu Fehlercodes führen, wenn man das hier nicht korrekt einstellt und zusätzlich das Abrufen der WU via Internet verbietet. Ich konfiguriere praktisch so, dass zunächst der interne Updateserver als Quelle für die Definitionsupdates verwendet wird.
- Downloadmodus: Umgehen
- Keine Verbindung mit Windows Update Internetadressen herstellen: tja, ich hatte das früher mal anders konfiguriert, aktuell ist das bei mir aber aktiviert. Damit verhinderst du definitiv dass deine Clients Windows Updates aus dem Internet ziehen können. Das ist ggf. nicht immer so wünschenswert, das verstehe ich. Hier müsste ich selbst noch testen, ob ich das mittlerweile wieder auf Deaktiviert setzen könnte. Für dich zum testen wäre diese Option aber erforderlich um zu sehen, ob es dann funktioniert oder ob die Clients dann einen Fehlercode bekommen.
- Der Reg-Key ganz am Anfang entfernt den Haken "Funktionsupdates umgehen", graut diesen aber nicht aus. Ist der Haken gesetzt werden sich die 1511er Clients z. B. beim WSUS melden und auch innerhalb der 1511er updates, aber nicht das 1603er Funktionsupdate als benötigt erkennen.
Alle Einstellungen habe ich nach besten Wissen und Gewissen gemacht und sind das Resultat langem Herumprobierens und Analysierens meiner Windows 10 Update Probleme. Natürlich führen sicherlich viele Wege nach Rom. Just my two cents.
Meiner Meinung nach geht man auf Nummer sicher, wenn man für Windows 10 1603 auch die ADMX-Dateien von 1603 verwendet anstatt der 1511er oder älter.
Es kann somit nicht schaden, die neuesten ADMX-Dateien zu verwenden und die wenigen Einstellungen (s. Screenshots) nochmal kurz per Hand zu setzen. Ist aber nur eine warme Empfehlung. Natürlich kann man gerne auch versuchen, die ADMX-Dateien von vor einem Jahr weiter zu verwenden. Ich behaupte nicht, dass es unmöglich wäre, einen Windows 10 1603er Client damit zu patchen
Ich hab noch ne kleine Ergänzung zu den GPO-Screenshots:
- Definieren der Reihenfolge der Quellen für das Herunterladen von Definitionsupdates InternalDefinitionUpdateServer | MicrosoftUpdateServer | MMPC > Kann unter Umständen zu Fehlercodes führen, wenn man das hier nicht korrekt einstellt und zusätzlich das Abrufen der WU via Internet verbietet. Ich konfiguriere praktisch so, dass zunächst der interne Updateserver als Quelle für die Definitionsupdates verwendet wird.
- Downloadmodus: Umgehen
- Keine Verbindung mit Windows Update Internetadressen herstellen: tja, ich hatte das früher mal anders konfiguriert, aktuell ist das bei mir aber aktiviert. Damit verhinderst du definitiv dass deine Clients Windows Updates aus dem Internet ziehen können. Das ist ggf. nicht immer so wünschenswert, das verstehe ich. Hier müsste ich selbst noch testen, ob ich das mittlerweile wieder auf Deaktiviert setzen könnte. Für dich zum testen wäre diese Option aber erforderlich um zu sehen, ob es dann funktioniert oder ob die Clients dann einen Fehlercode bekommen.
- Der Reg-Key ganz am Anfang entfernt den Haken "Funktionsupdates umgehen", graut diesen aber nicht aus. Ist der Haken gesetzt werden sich die 1511er Clients z. B. beim WSUS melden und auch innerhalb der 1511er updates, aber nicht das 1603er Funktionsupdate als benötigt erkennen.
Alle Einstellungen habe ich nach besten Wissen und Gewissen gemacht und sind das Resultat langem Herumprobierens und Analysierens meiner Windows 10 Update Probleme. Natürlich führen sicherlich viele Wege nach Rom. Just my two cents.
Jeder sollte immer die aktuellen admx-Dateien nutzen oder mit RSAT von einem geeigneten Client aus administrieren - gar keine Frage.
Ich wollte nur unterbinden, dass sich in diese Fragestunde zu Updates, die hier und anderswo ja ausartet, noch mehr unnötige Infos einschleichen, die zudem auch falsch sind. Du schreibst explizit "Die neuesten ADMX-Files laden, die werden dringend benötigt, damit alles korrekt läuft" - und das stimmt nicht.
Was soll's. Viel Glück Euch allen.
Ich wollte nur unterbinden, dass sich in diese Fragestunde zu Updates, die hier und anderswo ja ausartet, noch mehr unnötige Infos einschleichen, die zudem auch falsch sind. Du schreibst explizit "Die neuesten ADMX-Files laden, die werden dringend benötigt, damit alles korrekt läuft" - und das stimmt nicht.
Was soll's. Viel Glück Euch allen.
Okay, ich habe mein Ausgangsposting diesbezüglich überarbeitet, da es tatsächlich etwas übertrieben war. Ich denke wir einigen uns darauf, dass es sinnvoll ist, bei aktuellem Patchstand auch die neuesten ADMX-Dateien bereitzustellen. Leider muss ich aber auch sagen, dass es gerade wegen dem Ersetzen der ADMX-Dateien (bzw. den neuen Einstellungsmöglichkeiten/den entfernten vorherigen Einstellungsmöglichkeiten) nötig war, die alte GPO zu löschen und eine neue zu erstellen. Muss man zwar nicht zwangsläufig, kann aber nicht schaden. Mir hat es zumindest geholfen.
Ich wünsche ebenfalls allen viel Erfolg ;)
Ich wünsche ebenfalls allen viel Erfolg ;)
Ich krieg echt noch ein Hörnchen bei den Update Problem.
Bei mir setzt sich der Haken Feature Updates zurückstellen immer wieder neu zurück.
In der Gpo ist nichts davon hinterlegt.
Dennoch wird der Haken immer wieder neu gesetzt, und das bei den meisten PC´s, ABER nicht bei allen...
Hat da noch jemand eine Idee?
Bei mir setzt sich der Haken Feature Updates zurückstellen immer wieder neu zurück.
In der Gpo ist nichts davon hinterlegt.
Dennoch wird der Haken immer wieder neu gesetzt, und das bei den meisten PC´s, ABER nicht bei allen...
Hat da noch jemand eine Idee?
Schau dir bitte meinen letzten Screenshot an. Dort habe ich einen Reg-Key bei der Machine forciert: "DisableOSUpgrade". Wenn du den Regkey ebenfalls verteilst, sollte es theoretisch klappen.
Wenn ich mich recht entsinne, gab es dafür früher mal einen GPO-Eintrag, der nun aber nicht mehr in dieser Form existiert (er hieß glaube ich "Upgrade zurückstellen"). Hatte man das damals hinterlegt (also Zurückstellen auf "Ja") und hat dann die ADMX-Dateien erneuert, dann könnte es sein, dass diese GPO weiterhin noch so angewendet wird, du bekommst es aber nicht unbedingt mit bzw. du siehst die Einstellung nicht mehr. Vielleicht kannst du ja mithilfe von GPRESULT /H herausfinden, ob da etwas an einem betroffenen Client ankommt bzw. ob sich der Regkey, wenn du ihn manuell änderst nach einem GPUPDATE /Force wieder zurückändert. Im Zweifelsfall die alte GPO deaktivieren/löschen und schnell eine neue zusammenklicken
Wenn ich mich recht entsinne, gab es dafür früher mal einen GPO-Eintrag, der nun aber nicht mehr in dieser Form existiert (er hieß glaube ich "Upgrade zurückstellen"). Hatte man das damals hinterlegt (also Zurückstellen auf "Ja") und hat dann die ADMX-Dateien erneuert, dann könnte es sein, dass diese GPO weiterhin noch so angewendet wird, du bekommst es aber nicht unbedingt mit bzw. du siehst die Einstellung nicht mehr. Vielleicht kannst du ja mithilfe von GPRESULT /H herausfinden, ob da etwas an einem betroffenen Client ankommt bzw. ob sich der Regkey, wenn du ihn manuell änderst nach einem GPUPDATE /Force wieder zurückändert. Im Zweifelsfall die alte GPO deaktivieren/löschen und schnell eine neue zusammenklicken
Das schnell neu zusammenklicken hatte ich schon gemacht
Bin jetzt mal hingegangen und habe die alten 1511 Vorlagen reinkopiert und siehe da, ES TAUCHT die Einstellung im Klar Text auf.
Oh man ENDLICH ist dieses Thema erledigt........
Bin jetzt mal hingegangen und habe die alten 1511 Vorlagen reinkopiert und siehe da, ES TAUCHT die Einstellung im Klar Text auf.
Oh man ENDLICH ist dieses Thema erledigt........
Naja, das ist doch das was ich sagte: die Einstellung wurde mit den 1607er ADMX-Dateien entfernt. Wenn du nach dem Kopieren der 1607er ADMX-Dateien eine neue GPO angelegt hast, so wie ich geraten habe, hätte diese Einstellung also nicht mehr angewendet werden dürfen. Wie kann es sein, dass du eine neue GPO erstellt und verteilt hast und trotzdem die alten Einstellungen verteilt wurden? War die alte noch aktiv?
@ snakerl Die Einstellungen wurden nicht entfernt, man konnte nur die nicht mehr wirklich sehen in der GPO mmc.
Wenn dem so wäre würden ja alle anderen PC´s diese GPO nicht mehr verwenden können.
Ich fahre jetzt 2 gleisig für die Dauer. Werde jetzt Rechner nach und nach auf 1607 Updaten. Danach kann ich die GPO für 1511 entfernen.
Gemacht habe ich das nach diesem Artikel.
https://4sysops.com/archives/managing-windows-update-changes-in-windows- ...]
Wenn dem so wäre würden ja alle anderen PC´s diese GPO nicht mehr verwenden können.
Ich fahre jetzt 2 gleisig für die Dauer. Werde jetzt Rechner nach und nach auf 1607 Updaten. Danach kann ich die GPO für 1511 entfernen.
Gemacht habe ich das nach diesem Artikel.
https://4sysops.com/archives/managing-windows-update-changes-in-windows- ...]
Hallo DerWoWusste,
ich sitze derzeit bei dem identischen Problem und es mag einfach nicht so funktionieren.
Das derzeitige Setup:
ESD-MIME-Typ hinzugefügt
Folgende Einstellungen werden per GPO verteilt:
Die Rechner/Server melden sich korrekt beim WSUS und können dort in die passenden Gruppen verschoben werden.
Seit 1607 kommt folgende Meldung
(diese kommt bei einem zu Testzwecken online geupdateten Client)
oder alternativ
(diese kommt bei einer gerade komplett neuen TestVM ohne sonstige Updates)
Diese kommen nicht nach/beim Installieren von Updates, sondern direkt nach dem suchen von Updates.
Was habe ich vergessen etwas zu setzten?
Mit freundlichen Grüßen
WinWord
ich sitze derzeit bei dem identischen Problem und es mag einfach nicht so funktionieren.
Das derzeitige Setup:
- Microsoft Windows Server 2012 R2
ESD-MIME-Typ hinzugefügt
- Windows 7 Clients
- Windows 10 1607 Clients
Seit 1607 kommt folgende Meldung
oder alternativ
Diese kommen nicht nach/beim Installieren von Updates, sondern direkt nach dem suchen von Updates.
Was habe ich vergessen etwas zu setzten?
Mit freundlichen Grüßen
WinWord
Was sagt dir denn das Windows Update Log File wenn du es ausliest? Kann es sein, dass die Clients versuchen (fälschlicherweise) über das Internet an die Updates zu kommen und dort aber nicht hin können (Firewall usw.)?
Hast du die von mir empfohlene Einstellung für den Windows Defender (s. "InternalDefinitionUpdateServer") gesetzt? Hast du ansonsten die Settings verteilt, die ich oben gepostet habe?
Hast du die von mir empfohlene Einstellung für den Windows Defender (s. "InternalDefinitionUpdateServer") gesetzt? Hast du ansonsten die Settings verteilt, die ich oben gepostet habe?
Hallo DerWoWusste,
ich sitze derzeit bei dem identischen Problem und es mag einfach nicht so funktionieren.
Hallo WinWord. Das Problem ist nicht identisch. Ich hatte beklagt, dass man seitr v1607 überhaupt keine Updates mehr vom WSUS bekommt. Du bist noch nicht einmal auf 1607 und hast Probleme, es über den WSUS zu verteilen. Die hatte ich auch schon und habe aufgegeben, da ich eh keinen Sinn darin sehe, hier WSUS zu nutzen. Ich nutze ein Skript - das kann ich hier mal hinstellen, bei Zeiten.ich sitze derzeit bei dem identischen Problem und es mag einfach nicht so funktionieren.
Hallo snakerl,
1. Windows Update Log File
Ich habe einmal alle Error/Fatal/Warnings des getrigen Tages zusammengeschnitten:
"
WARNING: SleepStudyTracker: Machine is non-AOAC. Sleep study tracker disabled.
WARNING: Network Cost is assumed to be not supported as something failed with trying to get handles to wcmapi.dll
WARNING: CSerializationHelper:: InitSerialize failed : 0x80070002
WARNING: Failed to get Wu Exemption info from NLM, assuming not exempt, error = 0x80240037
WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037
FATAL: CNetworkCostChangeHandler::RegisterForCostChangeNotifications: CoCreateInstance failed with error 80004002
WARNING: RegisterNetworkCostChangeNotification: Error 80004002
FATAL: SLS:CSLSRequest::RetrieveAdditionalAttributesIfRequired: CoCreateInstance failed with 0x80040154.
WARNING: Failed to retrieve SLS response data for service 117cab2d-82b1-4b5a-a08c-4d62dbee7782, error = 0x80040154
FATAL: Caller Service Recovery failed to opt in to service 117cab2d-82b1-4b5a-a08c-4d62dbee7782, hr=0X80040154
FATAL: GetClientUpdateUrl failed, err = 0x8024D009
WARNING: Failed to evaluate Installed rule, updateId = {{4DEB7F5F-D14D-43E2-93FA-F81B10846CF7}.200}, hr = 80070057
WARNING: Failed to evaluate Installable rule, updateId = {{4DEB7F5F-D14D-43E2-93FA-F81B10846CF7}.200}, hr = 80070057
WARNING: Failed to evaluate Installed rule, updateId = {{22FFD207-0EB5-4FCF-9F6A-67078327D7A3}.200}, hr = 80070057
WARNING: Failed to evaluate Installed rule, updateId = {{A4ECF96E-FE76-4933-B1A9-FAA712DC2A3B}.200}, hr = 80070057
WARNING: Failed to evaluate Installable rule, updateId = {{A4ECF96E-FE76-4933-B1A9-FAA712DC2A3B}.200}, hr = 80070057
WARNING: Failed to evaluate Installed rule, updateId = {{9941EB5F-4953-446D-99A2-C5989C596283}.200}, hr = 80070057
WARNING: Failed to evaluate Installable rule, updateId = {{9941EB5F-4953-446D-99A2-C5989C596283}.200}, hr = 80070057
WARNING: IsSessionRemote: WinStationQueryInformationW(WTSIsRemoteSession) failed for session 2, GetLastError=2250
"
Wobei mir hier leider nicht ersichtlich ist, inwiefern hier eine auf die Problematik der Updateverteilung nur an Windows 10 1607 hinweist?
2. Internetzugriff
Das mit dem Internetzugriff sollte bei den Büro-PCs kein Problem darstellen,
allerdings wird sich hier die Produktion die Zähne ausbeißen.
Die Updatesuche dauert ca. 3 Sekunden, danach resultieren beide gezeigten Fehler.
3. Windows Defender
Dieser ist bei uns deaktiviert, ich habe die GPO vorsichtshalber dennoch gesetzt.
Hallo DerWoWusste,
die Windows 7 Clients bleiben auf der Version, es ist nicht vorgesehen diese upzugraden.
Alle die nun Windows 10 haben, besitzen 1607 (wenn auch manuell auf Stand gebracht), danach wurde der WSUS auf 2012 R2 gewechselt.
Schlussendlich geht es mir nur um die Updateverteilung an Windows 10 1607 über WSUS welche leider nicht klappen möchte.
Noch eine interessante (gerade gemachte) Erkenntnis.
Nachdem ich die virtuelle Testmaschine hochgefahren habe, und eine weile nichts daran geändert wurde, kam folgende Meldung:
Sollte man aber nach Updates suchen => Bekannter 0x8024500c Fehler.
Mit freundlichen Grüßen
WinWord
1. Windows Update Log File
Ich habe einmal alle Error/Fatal/Warnings des getrigen Tages zusammengeschnitten:
"
WARNING: SleepStudyTracker: Machine is non-AOAC. Sleep study tracker disabled.
WARNING: Network Cost is assumed to be not supported as something failed with trying to get handles to wcmapi.dll
WARNING: CSerializationHelper:: InitSerialize failed : 0x80070002
WARNING: Failed to get Wu Exemption info from NLM, assuming not exempt, error = 0x80240037
WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037
FATAL: CNetworkCostChangeHandler::RegisterForCostChangeNotifications: CoCreateInstance failed with error 80004002
WARNING: RegisterNetworkCostChangeNotification: Error 80004002
FATAL: SLS:CSLSRequest::RetrieveAdditionalAttributesIfRequired: CoCreateInstance failed with 0x80040154.
WARNING: Failed to retrieve SLS response data for service 117cab2d-82b1-4b5a-a08c-4d62dbee7782, error = 0x80040154
FATAL: Caller Service Recovery failed to opt in to service 117cab2d-82b1-4b5a-a08c-4d62dbee7782, hr=0X80040154
FATAL: GetClientUpdateUrl failed, err = 0x8024D009
WARNING: Failed to evaluate Installed rule, updateId = {{4DEB7F5F-D14D-43E2-93FA-F81B10846CF7}.200}, hr = 80070057
WARNING: Failed to evaluate Installable rule, updateId = {{4DEB7F5F-D14D-43E2-93FA-F81B10846CF7}.200}, hr = 80070057
WARNING: Failed to evaluate Installed rule, updateId = {{22FFD207-0EB5-4FCF-9F6A-67078327D7A3}.200}, hr = 80070057
WARNING: Failed to evaluate Installed rule, updateId = {{A4ECF96E-FE76-4933-B1A9-FAA712DC2A3B}.200}, hr = 80070057
WARNING: Failed to evaluate Installable rule, updateId = {{A4ECF96E-FE76-4933-B1A9-FAA712DC2A3B}.200}, hr = 80070057
WARNING: Failed to evaluate Installed rule, updateId = {{9941EB5F-4953-446D-99A2-C5989C596283}.200}, hr = 80070057
WARNING: Failed to evaluate Installable rule, updateId = {{9941EB5F-4953-446D-99A2-C5989C596283}.200}, hr = 80070057
WARNING: IsSessionRemote: WinStationQueryInformationW(WTSIsRemoteSession) failed for session 2, GetLastError=2250
"
Wobei mir hier leider nicht ersichtlich ist, inwiefern hier eine auf die Problematik der Updateverteilung nur an Windows 10 1607 hinweist?
2. Internetzugriff
Das mit dem Internetzugriff sollte bei den Büro-PCs kein Problem darstellen,
allerdings wird sich hier die Produktion die Zähne ausbeißen.
Die Updatesuche dauert ca. 3 Sekunden, danach resultieren beide gezeigten Fehler.
3. Windows Defender
Dieser ist bei uns deaktiviert, ich habe die GPO vorsichtshalber dennoch gesetzt.
Hallo DerWoWusste,
die Windows 7 Clients bleiben auf der Version, es ist nicht vorgesehen diese upzugraden.
Alle die nun Windows 10 haben, besitzen 1607 (wenn auch manuell auf Stand gebracht), danach wurde der WSUS auf 2012 R2 gewechselt.
Schlussendlich geht es mir nur um die Updateverteilung an Windows 10 1607 über WSUS welche leider nicht klappen möchte.
Noch eine interessante (gerade gemachte) Erkenntnis.
Nachdem ich die virtuelle Testmaschine hochgefahren habe, und eine weile nichts daran geändert wurde, kam folgende Meldung:
Mit freundlichen Grüßen
WinWord
Installier das letzte kumulative Update für 10manuell, mehr musst du nicht tun. So lief es bei uns und alle reden wieder mit dem wsus.
Kurze Recherche: KB3194798 (https://support.microsoft.com/de-at/kb/3194798) sollte das letz mögliche sein.
Nach erfolgreicher Installation auf meiner Test-VM prangert leider immer noch bekannter 0x8024500c Fehler auf dem Bildschirm.
Nach erfolgreicher Installation auf meiner Test-VM prangert leider immer noch bekannter 0x8024500c Fehler auf dem Bildschirm.
Das Log schaut schon mal nicht so toll aus Ich bin mir dennoch nicht ganz sicher, ob das Problem jetzt das vom Client oder das vom Server ist ...
WSUS läuft auf Server 2012 R2? Welche Version wird dir angezeigt im Hauptfenster? Bei mir sagt er im Moment: Serverversion: 6.3.9600.18324
Achja, ich hoffe ich habs nicht überlesen: aber wie sieht der WSUS die Clients? Erkennt er sie korrekt und sieht auch dass da noch Updates für Windows 10 1607 ausstehen?
Ich bin mir dennoch nicht ganz sicher, ob das Problem jetzt das vom Client oder das vom Server ist ...WSUS läuft auf Server 2012 R2? Welche Version wird dir angezeigt im Hauptfenster? Bei mir sagt er im Moment: Serverversion: 6.3.9600.18324
Achja, ich hoffe ich habs nicht überlesen: aber wie sieht der WSUS die Clients? Erkennt er sie korrekt und sieht auch dass da noch Updates für Windows 10 1607 ausstehen?
Hört mal bitte... ich muss was klarstellen:
Wenn Win10 das kumulative Update installiert hat, dann geht es ohne wenn und aber, was jeder mit 2 VMs (WSUS+1x win10) nachstellen kann. Soweit waren wir auch schon.
Was auch immer bei irgendwelchen Lösungsversuchen bei Euch nun verstellt worden ist, ist schwer nachvollziehbar.
Der Thread ist für mich als Ersteller abgeschlossen. Ich würde an Eurer Stelle einen neuen anfangen.
Wenn Win10 das kumulative Update installiert hat, dann geht es ohne wenn und aber, was jeder mit 2 VMs (WSUS+1x win10) nachstellen kann. Soweit waren wir auch schon.
Was auch immer bei irgendwelchen Lösungsversuchen bei Euch nun verstellt worden ist, ist schwer nachvollziehbar.
Der Thread ist für mich als Ersteller abgeschlossen. Ich würde an Eurer Stelle einen neuen anfangen.
Nein geht definitiv nicht.
Hast Du vielleicht W10 Enterprise?
Ich habe nur Pro-Lizenzen im Einsatz.
Windows 10 Clients ziehen auch mit installiertem KB3189866 keine Windows-Updates vom WSUS.
WSUS läuft auf Server 2012 R2 (voll gepatched), Verbindung über ssl.
Die Windows 10 Rechner laden die Windows-Updates direkt über Microsoft Update und reporten an den WSUS immer, dass sie keine Updates benötigen. Ich werde nicht gefragt, ob ich die Updates freigeben will.
(Ausgenommen sind Updates für andere Produkte (Office oder über WPP bereitgestellte). Die funktionieren wie gewohnt.)
Wenn ich die Verbindung zu Windows Update über eine Gruppenrichtlinie untersage, bekommen sie gar keine Windows-Updates mehr.
Windows 10 - 1607 und WSUS funktionieren nicht zusammen. Da hat sich noch gar nichts geändert.
Wenn das an der Lizenz liegt, laufe ich amok. Dass die Pro-Version jetzt nicht mehr alle Gruppenrichtlinien verarbeitet stinkt mir schon gewaltig. Die spinnen doch in Redmond.
Ihr werdet es lieben...
Hast Du vielleicht W10 Enterprise?
Ich habe nur Pro-Lizenzen im Einsatz.
Windows 10 Clients ziehen auch mit installiertem KB3189866 keine Windows-Updates vom WSUS.
WSUS läuft auf Server 2012 R2 (voll gepatched), Verbindung über ssl.
Die Windows 10 Rechner laden die Windows-Updates direkt über Microsoft Update und reporten an den WSUS immer, dass sie keine Updates benötigen. Ich werde nicht gefragt, ob ich die Updates freigeben will.
(Ausgenommen sind Updates für andere Produkte (Office oder über WPP bereitgestellte). Die funktionieren wie gewohnt.)
Wenn ich die Verbindung zu Windows Update über eine Gruppenrichtlinie untersage, bekommen sie gar keine Windows-Updates mehr.
Windows 10 - 1607 und WSUS funktionieren nicht zusammen. Da hat sich noch gar nichts geändert.
Wenn das an der Lizenz liegt, laufe ich amok. Dass die Pro-Version jetzt nicht mehr alle Gruppenrichtlinien verarbeitet stinkt mir schon gewaltig. Die spinnen doch in Redmond.
Ihr werdet es lieben...
Hey bdmin, ich habe ja nun auch schon einiges dazu geschrieben und ich kann dir nur sagen: mit server 2012 r2 (aktueller Patchstand) und Windows 10 Pro funktioniert das, sofern man an alles gedacht hat. Es ist somit kein generelles Problem, sondern irgendwo ist bei deiner Konfiguration etwas noch nicht ganz rund...
Woran soll es denn liegen?
Die Windows 10 clients beziehen ja Updates vom WSUS.
Nur die Updates fürs Betriebssystem selbst wollen sie nicht mehr.
Verteilen diejenigen, bei denen es geht, vielleicht nichts über WPP oder ähnliches?
Die Windows 10 clients beziehen ja Updates vom WSUS.
Nur die Updates fürs Betriebssystem selbst wollen sie nicht mehr.
Verteilen diejenigen, bei denen es geht, vielleicht nichts über WPP oder ähnliches?
Es funktioniert sowohl mit 2012 R2 (Test-wsus) als auch mit Server 2008 (noch ein paar Tage produktiv) bei uns. Keine Einstellungen nötig. Win10 1607, größtenteils Pro.
Verteilen diejenigen, bei denen es geht, vielleicht nichts über WPP oder ähnliches?
Kein WPP, aber LUP (das selbe in grün).Puh! - Ich glaube ich habs gefunden.
War natürlich mein Fehler. - hmpf
Ich hatte als internen Pfad für den Microsoft Updatedienst eine URL in folgender Form angegeben:
"https://wsus.firma.de:8531"
Der DNS-Server hat einen Eintrag , der auf die interne IP-Adresse verweist.
(Ich hatte mal WSUS übers Internet ausprobiert und die Einstellung dann einfach so gelassen.)
Ich weiß nicht genau warum das jetzt mit W10-1607 nicht mehr funktioniert aber mit dieser URL geht es:
"https://WSUS-Server:8531"
Unter >>Einstellungen>Update und Sicherheit<< bekomme ich jetzt auch wieder "Suchen sie online nach Updates von Microsoft Update." angezeigt. Edit 01.11.2016
Vergesst das wieder.
Man muss in der Gruppenrichtlinie unter >>Windows-Komponenten/Windows Update/Windows-Updates zurückstellen<< alles deaktivieren.
Dann geht es.
Kann das jemand bestätigen?
Ich würde, wie angeraten, auf meinen neu erstellten Thread verweisen:
Updateverteilung Windows 10 1607 und WSUS 2012 R2
Updateverteilung Windows 10 1607 und WSUS 2012 R2
Wenn du einerseits die GPO verteilst, welche besagt, dass Clients nicht via Internet Updates beziehen dürfen/sollen und andererseits die falschen Einstellungen in der "Zurückstellen-GPO" hinterlegst, könnte es theoretisch schon zu Problemen kommen. Diese Zurückstellen-Einstellungen sollten, soweit ich das weiß, nur gesetzt werden, wenn man WUfB anstatt eines eigenen WSUS nutzt. Finger weg davon also, wenn du möchtest, dass deine Clients eigentlich nur über deinen WSUS Updates ziehen sollen.
Hättest du dir 5 Minuten Zeit genommen um ne neue WSUS-GPO zu erstellen um diese auf nen Testclient loszulassen, hättest du dir vermutlich sehr viel Zeit gespart ... und uns auch
EDIT: Hier etwas zum Nachlesen zu dem Thema WUfB
https://technet.microsoft.com/de-de/itpro/windows/manage/waas-configure- ...
https://www.windowspro.de/wolfgang-sommergut/verteilerringe-konfiguriere ...
https://www.windowspro.de/wolfgang-sommergut/gpos-fuer-windows-10-1607-e ...
Hättest du dir 5 Minuten Zeit genommen um ne neue WSUS-GPO zu erstellen um diese auf nen Testclient loszulassen, hättest du dir vermutlich sehr viel Zeit gespart ... und uns auch
EDIT: Hier etwas zum Nachlesen zu dem Thema WUfB
https://technet.microsoft.com/de-de/itpro/windows/manage/waas-configure- ...
https://www.windowspro.de/wolfgang-sommergut/verteilerringe-konfiguriere ...
https://www.windowspro.de/wolfgang-sommergut/gpos-fuer-windows-10-1607-e ...
Entschuldigung, aber die Auswirkungen dieser neuen Gruppenrichtlinien sind nun mal recht bescheiden dokumentiert.
Erst seit kurzem kristllisiert sich so langsam heraus, was es mit WUfB überhaupt auf sich hat.
Ich habe jetzt das Zurückstellen der Updates über die Gruppenrichtlinie deaktiviert, was nach meinem Verständnis WUfB deaktivieren sollte. Die Kommunikation mit dem WSUS funktioniert auch wie gewünscht.
Allerdings kann man weiterhin auf den Clients die Option "Featureupdates zurückstellen" anhaken. Das sollte jetzt meiner Meinung nach ausgegraut sein.
Ich denke, dass MS hier immer noch eine Baustelle hat.
Erst seit kurzem kristllisiert sich so langsam heraus, was es mit WUfB überhaupt auf sich hat.
Ich habe jetzt das Zurückstellen der Updates über die Gruppenrichtlinie deaktiviert, was nach meinem Verständnis WUfB deaktivieren sollte. Die Kommunikation mit dem WSUS funktioniert auch wie gewünscht.
Allerdings kann man weiterhin auf den Clients die Option "Featureupdates zurückstellen" anhaken. Das sollte jetzt meiner Meinung nach ausgegraut sein.
Ich denke, dass MS hier immer noch eine Baustelle hat.
Da bin ich auch mal wieder...
Jetzt wollte ich das 1607 Update über Wsus verteilen, klappt ja auch soweit.
Aber das ist dann die Release Version ohne jegliche Updates. Von daher bleibt der Download schon bei 0% Hängen.
Kann ich irgendwie die ESD auf dem Wsus auf eine Aktuelle Version hochziehen und diese beim Upgrade nutzen?
Jetzt wollte ich das 1607 Update über Wsus verteilen, klappt ja auch soweit.
Aber das ist dann die Release Version ohne jegliche Updates. Von daher bleibt der Download schon bei 0% Hängen.
Kann ich irgendwie die ESD auf dem Wsus auf eine Aktuelle Version hochziehen und diese beim Upgrade nutzen?
Bis heute nicht, nein. Dafür will die "Datenträgerbereinigung" nach dem Upgrade 3,99TB auf einer 500GB Platte wieder frei machen...
Was ein gefrickel
Gruß
Andi
Was ein gefrickel
Gruß
Andi
