user1000
Goto Top

Windows 10 1607 und WSUS - Registryeinträge

Hallo!

Wir setzen WSUS auf einem Windows Server 2008 R2 ein. Leider wollen unsere Windows 10 Enterprise LTSB1607 PCs darüber keine Windows-Updates herunterladen, sondern nur Office-Updates. Ich vermute, dass wir in unserer WSUS-GPO irgendwelche Haken falsch gesetzt haben. Könnte jemand von euch mal posten, bei welchen Einstellungen (GPO oder Registry) die normalen kumulativen Windows-10-Updates erfolgreich über den WSUS auf die Clients verteilt werden?

Uns ist klar, dass wir über den 2008-R2-Server keine Windows-10-Upgrades bereitstellen können. Das wird auch gar nicht benötigt, da wir ja die LTSB-Version einsetzen. Aber die "normalen" Windows-10-Qualitätsupdates werden bei uns entweder gar nicht installiert, oder über das Internet heruntergeladen. Dass die Updates über den WSUS heruntergeladen werden, haben wir noch nicht hinbekommen...


Grüße
User1000

Content-ID: 335403

Url: https://administrator.de/contentid/335403

Ausgedruckt am: 22.11.2024 um 10:11 Uhr

DerWoWusste
DerWoWusste 18.04.2017 aktualisiert um 14:41:18 Uhr
Goto Top
Hi.

Es geht nicht um fehlende Haken, sondern lediglich um fehlende Patches für den WSUS selbst. Aktualisiere den Mal gegen die Microsoft Updateserver.
sabines
sabines 18.04.2017 um 14:55:56 Uhr
Goto Top
Moin,

die aktuelle Version ist WSUS 3.0 (SP2) + KB2938066 (Build 3.2.7600.274).
Neustart, auch wenn nicht angefordert, nicht vergessen.

Gruss
User1000
User1000 18.04.2017 um 18:38:00 Uhr
Goto Top
Danke für die Rückmeldungen. Der WSUS läuft seit Februar mit Build 3.2.7600.274. ich habe ihn soeben nochmals neu gestartet.

Die GPO-Einstellungen tauchen in der Registry wie folgt auf:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization]
"DODownloadMode"=dword:00000063  

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://WSUS:8530"  
"WUStatusServer"="http://WSUS:8530"  
"ElevateNonAdmins"=dword:00000000  
"AcceptTrustedPublisherCerts"=dword:00000000  
"SetActiveHours"=dword:00000001  
"ActiveHoursStart"=dword:00000007  
"ActiveHoursEnd"=dword:00000012  
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001  

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"AutoInstallMinorUpdates"=dword:00000001  
"NoAUAsDefaultShutdownOption"=dword:00000001  
"IncludeRecommendedUpdates"=dword:00000000  
"RebootRelaunchTimeoutEnabled"=dword:00000001  
"RebootRelaunchTimeout"=dword:00000258  
"UseWUServer"=dword:00000001  
"NoAutoRebootWithLoggedOnUsers"=dword:00000001  
"RebootWarningTimeoutEnabled"=dword:00000001  
"RebootWarningTimeout"=dword:0000001e  
"NoAUShutdownOption"=dword:00000001  
"DetectionFrequencyEnabled"=dword:00000001  
"DetectionFrequency"=dword:00000016  
"AUPowerManagement"=dword:00000000  
"RescheduleWaitTimeEnabled"=dword:00000001  
"RescheduleWaitTime"=dword:0000000a  
"NoAutoUpdate"=dword:00000000  
"AUOptions"=dword:00000004  
"ScheduledInstallDay"=dword:00000000  
"ScheduledInstallTime"=dword:00000002  

Könnte jemand mal schauen, wie die Einstellungen an Windows 10 PCs aussehen, bei denen die WSUS-Updates problemlos laufen?
An meinen Testrechnern erhalte ich nun bei der Windows-Update-Suche folgende Fehlermeldungen:
PC1:
DerWoWusste
DerWoWusste 19.04.2017 aktualisiert um 09:28:55 Uhr
Goto Top
An den Clients ist nichts einzustellen. Gar nichts.
Nachdem ich ein zweites Mal über "Leider wollen unsere Windows 10 Enterprise LTSB1607 PCs darüber keine Windows-Updates herunterladen, sondern nur Office-Updates." nachgedacht habe, fällt mir nun doch die Lösung ein: Windows 10 1607 hatte einen Bug!
Man muss auf win10 ein kumulatives Update manuell einspielen (nimm einfach das April Update), danach geht es auch mit den Windows updates über WSUS.

Ich weiß, es klingt komisch, aber Microsoft ist zu solchen Schnitzern fähig.
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4015217
Runterladen und per Startskript (mittels der wusa.exe) überall installieren lassen. wusa \\server\share\NAME-OF-UPDATE.msu /quiet
User1000
User1000 19.04.2017 aktualisiert um 19:59:36 Uhr
Goto Top
Wir hatten das Februar-Update manuell eingespielt, daran lag es also nicht, dass keine Updates eingespielt wurden.

Allerdings: Jetzt geht es.

Irgendeiner der folgenden Schritte war wohl dafür verantwortlich:


a) WSUS-Version geprüft -> ist aktuell

b) Software distribution Ordner am Client geleert

c) Vorhandene WSUS-GPO kopiert, alte nur für Win7-PCs, neue nur für die WIn10-PCs freigegeben (WMI-Filter), viele (unnötigen?) Einstellungen entfernt.

d) Im WSUS das Produkt „Windows 10 LTSB“ zusätzlich aufgenommen.

e) In der GPO unter Übertragungsoptimierung sowohl 99 „Einfach“ als auch 100 „Umgehung“ (BITS) getestet.
-> keine Auswirkung

f) In der GPO unter Computer/Administrative Vorlagen/Windows-Komponenten/Windows Update/ die Einstellungen „Keine Treiber in Windows-Updates einschließen“, „Beim Empfang von Funktionsupdates auswählen“ sowie „Beim Empfang von Qualitätsupdates auswählen“ auf „Nicht konfiguriert“ gesetzt, gemäß http://www.mcseboard.de/topic/208721-windows-10-1607-updates-h%C3%A4nge ....
-> Sonst wird automatisch von WSUS-Synchronisation auf Internet-Synchronisation umgestellt und es kommt eine Fehlermeldung (da die Internet-Synchronisation durch die aktivierte Einstellung „Keine Verbindung mit Windows Update-Internetadressen herstellen“ verhindert wird). Das Verhalten konnte nachvollzogen werden. Vor der Änderung dieser Einstellung kam eine andere Fehlermeldung an den Clients.

g) Zeitlimits etc. im IIS-Manager auf dem WSUS-Server umgestellt gemäß https://serverfault.com/questions/835287/why-can-win10-nodes-will-check- ....

h) Die Datei „C:\Program Files\Update Services\WebServices\ClientWebService\web.config” am WSUS-Server angepasst gemäß https://community.spiceworks.com/topic/1970827-wsus-on-server-2016-windo ... (wobei bei uns Standardwert 600 anstatt 4096 eingestellt war)

i) ESD-Datentyp dem IIS beigebracht gemäß https://social.technet.microsoft.com/Forums/lync/en-US/d7dbb851-4e3a-41d ...

j) Die neusten ADMX-Dateien für Windows 10 heruntergeladen und in das SYSVOL-Verzeichnis installiert. Danach eine ganz neue GPO für WSUS-Updates angelegt und nur die allernötigsten Einstellungen gesetzt.

k) Den WSUS-Servernamen als FQDN angegeben in der GPO

l) In der GPO bei alternativem WSUS-Server https://WSUS.FIRMA.LOCAL:8531 angegeben. -> brachte nichts, zurück geändert auf http://WSUS.FIRMA.LOCAL:8530

m) Dem WSUS-Server TLS beigebracht gemäß https://helpdesk.estos.de/Knowledgebase/Article/View/164/1/howto-tls-ver ... (siehe Anlage), anschließend den Server neu gestartet.

n) Beim nächsten manuellen Update-Versuch am Client begann der IIS Worker Process auf dem WSUS-Server loszulegen. Er arbeitete mit voller CPU-Last und stark zunehmendem RAM-Verbrauch (über 2 GB RAM-Nutzung), bis man auf dem Server nichts anderes mehr machen konnte.

o) Nach ca. 30 Minuten lief der IIS-Prozess wieder mit normaler CPU-Nutzung - und plötzlich begannen meine Clients die Updates abzuholen. face-smile
sven173
sven173 25.04.2017 um 14:34:56 Uhr
Goto Top
Hi,

vieleicht bin ich einfach zu doof, ich versuche bei meinen wsus auf einen 2012 datacenter den wsus upzudaten aber finde keine datei wo es klappt sagt immer ihr computer ist nicht für das update geignet genau das selbe bei den win10 enterprise, versuche da irgendein update manuell zu installieren geht nicht. Habe soweit wie es oben steht alles druch er hat gestern einmal eine report an den wsus gesendet seid dem nicht mehr bekomme jetzt immer die 0x8024401c. Kann mir vieleicht jemand 2 exakte download links schicken für wsus update und irgenwein manuelles update für win 10 enterprise laut manchen foren soll es dann gehen. vielen dank

gruss sven
sabines
sabines 25.04.2017 um 14:51:14 Uhr
Goto Top
Hi,

erstelle hierfür bitte ein neues Thema, so erhöhst Du die Chancen, dass es jemand liest.

Gruss