Hallo zusammen,
ich habe das Problem, dass ich keine optionalen Features, wie RSAT-Tools oder Windows-Media-Pack auf meinem Windows11-Client hinzufügen kann. Ich bekomme den Fehler 0x80072EE6 angezeigt (Fehlerbeschreibung). Dieses Problem besteht ebenfalls bei unseren älteren Win10-Modellen.
Nach einigen Recherchestunden und einigen Umsetzungsversuchen scheitere ich weiterhin, Updates oder Features hinzuzufügen.
Folgendes habe ich bereits versucht:
GPO: Computer-Konfiguration > Administrative Vorlagen > System > Einstellungen für die Installation optionaler Komponenten und Reparatur von Komponenten angeben > Aktivieren mit dem Haken bei Laden Sie Inhalte für das Reparieren… direkt von Windows Update anstatt von WSUS herunter
In der Registry die Pfade bei dem Update-, Alternativ- und Statistik-Server um https:// ergänzt
In der Registry unter Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU „UseWUServer“=dword:00000001 > auf 0 gesetzt, anschließend den Windows-Update-Dienst neu gestartet
Netzwerkprobleme kann ich ausschließen, da das Internet einwandfrei funktioniert
Firewall oder Antivirus-Software habe ich überprüft - hier könnte es natürlich sein, dass die Verbindung zum Windows-Update-Server nicht hergestellt werden kann, da der ganze Traffic bei uns über den Proxy geleitet wird - wobei ich dies auch ohne Proxy erfolglos probiert habe. Dennoch könnte es eine Option sein die Whitelist der Firewall anzupassen, wobei die Frage wäre welche Adressen alle für ein Windows-Update bzw. die Optionalen Features benötigt werden (die gängigen Adressen rund um Microsoft sind bereits hinterlegt)
Den Ordner SoftwareDistribution habe ich versucht zu löschen, was allerdings nicht ging, da mindestens eine Datei immer in Verwendung war (auch wenn ich diese Datei aus den laufenden Prozessen gekickt habe) - ein Anwendungsfehler meinerseits ist natürlich nicht auszuschließen, da gegebenenfalls ein anderer Prozess auf die Datei zugreift.
Ich habe versucht in der Powershell mit dem Befehl DISM.exe /Online /Cleanup-Image /RestoreHealth das aktuelle Image zu reparieren. Allerdings funktioniert dies nur mit einer Quelldatei, die nicht auf dem Client hinterlegt ist, sondern der Client via Linbo bzw. Lmn, was vom Server gezogen wird, geimaged wird. Daher gehe ich nicht davon aus, dass sich solch eine Quelldatei auf den Clients befindet.
Es könnte auch an fehlenden Windows-Updates liegen, die ich mit der Fehlermeldung 0x8024500C nicht installieren kann Fehlerbeschreibung. Diesen Fehler habe ich auch versucht zu umgehen bzw. zu lösen, indem ich unter anderem GPOs angepasst (analog zu oben und noch zusätzlich Keine Richtlinie für Updaterückstellungen zulassen, … aktiviert habe.
Conclusion/ Annahme
Ich gehe davon aus, dass es mit der Dömane zu tun hat. Sobald ich den Domänenjoin aufhebe kann ich die Optionalen Features installieren. Die Idee mit Austreten>Installieren>Beitreten funktioniert allerdings nicht, da wir ein Vertrauensstellungsproblem haben, sobald ich der Dömane erneut beitrete. Hinzukommt, dass dies eher eine Symptombekämpfung statt einer Fehlerbehebung wäre.
Langer Beitrag, was daran liegt, dass ich schon vieles versucht habe und nichts funktionieren wollte. Vielleicht hat ja jemand aus der Community ähnliche Probleme gehabt und kann mir weiterhelfen.
wen du einen Proxy dafür nutzen willst, sollte dieser auch für den SYTEM-Nutzer hinterlegt sein. Enthält die Ausgabe von netsh winhttp show proxy deinen Proxy? Die Liste von Adressen zum Whitelisten findest du auf Step 2 - Configure WSUS | Microsoft Learn.
Um Software-Distribution löschen zu können, muss der Dienst Windows Update (wuauserv) gestoppt sein.
Pfade zum WSUS-Server sollten nur https:// sein, wenn du da HTTPS entsprechend eingerichtet hast. Per default ist das nicht der Fall, also sollte das ggf. http:// sein.
Normalerweise sollten Sie IIS so konfigurieren, dass Port 8531 für HTTPS-Verbindungen und Port 8530 für HTTP-Verbindungen verwendet wird.
Hallo Buster,
eine späte Antwort meinerseits erfolgt nun, da wir in der Zwischenzeit an der Schule viel ausprobiert haben, wobei ich jetzt nicht alle Umsetzungsideen beschreibe, sondern lediglich die zielführende Lösung (Vgl. unten).
Vielen Dank für deine Tipps, anbei meine Antworten auf die „offnen“ Fragen bzw. Hinweise:
winhttp show proxy: wir haben bei uns an der Schule die proxy settings per User, d.h. über diesen Befehl erhalten wir immer die Meldung no proxy, da der Befehl meines Wissens nach den Proxy der Local Machine ausgibt > die Proxy settings per User kommen aber an - das passt.
Software Distribution löschen: exakt, den Dienst habe ich ausgeschaltet/ gestoppt, den Ordner gelösch und den Windows Update Dienst neu gestartet - ohne Erfolg
Pfade: sind mit https:// hinterlegt
Das Problem besteht nach wie vor, dass keine Kommunikation zum WSUS-Server hergestellt werden kann. Einen WSUS-Server haben wir bei uns auch nicht in der Infrastruktur angelegt, weshalb wir die Kommunikation mit dem „allgemeinen“ Windows Server suchen. Da wir viel mit GPOs arbeiten, liegt der starke Verdacht nahe, dass eine GPO hier blockiert. Grund dafür ist auch, dass der PC außerhalb der Domäne die Updates installiert (s. gleich unten). Diese GPOs muss ich mal in einem ruhigen Moment mit viel Zeit analysieren.
Solange überbrücken wir mit dem Vorgehen:
Domänen Unjoin (Ziel: GPOs der Domain aushebeln)
Updates und Windows Features installieren
Domänen Join (Problem hier: Vertrauensstellung mit der Domäne nicht vorhanden, da Maschinenpasswort nicht übereinstimmend)
Maschinenpasswort als local-admin neusetzen Reset-ComputerMachinePassword -Server yourServer -Credential -yourDomainAdmin
Neues Image schreiben
Wichtig ist hierbei: Zeit mit einplanen, da anschließend alle PCs mit Win11 neu geimaged werden müssen (logisch, da Maschinen-Passwort zurückgesetzt).
Vielleicht hat jemand anderes eine ähnliche Problematik, für die das beschriebene Vorgehen ebenfalls weiterhilft.
Viele Grüße
mweidner
kann es sein, dass hier ein Missverständnis vorliegt? Ich hatte den Ursprungsbeitrag so verstanden, dass die lokal installierte Version der Windows Update Services (=WSUS; ein lokal installierte Dienstesammlung für Windows-Server, die im Zusammenspeil Cache und Steuerzentrale sind und die Möglichkeit bieten Windows Updates zwischenzuspeichern, auszuliefern, zu genehmigen, abzulehnen, …) auf einem Windows-Server verwendet werden. Da du auch was von „WSUS ausgeschalten“ schriebst, lag der Schluss nahe. Aber so wie ich es jetzt interpretiere, könntest du den Dienst „Windows Update“ im Windows-Client gemeint haben. Microsoft tut seinen Kunden da leider mit der Namenswahl keinen Gefallen, wenn auch noch deren Online-Server, welche die normalen Update-Pakete zum Download anbieten, umgangssprachlich Windows Update Server sind. Viele lesen flüchtig und dann geht auch der Unterschied zwischen Dienst/Service, Services und Server unter. Dass der Windows-Update-Client im Windows-Client dann technisch noch „wuauserv“ heißt, also vermutlich Windows Update Auto Update Serv(ice), ist nur das i-Tüpfelchen.
Wenn kein WSUS auf einem Windows-Server im Einsatz ist, sollten alle diesbezüglichen GPO-Einstellungen unkonfiguriert bleiben. Im Zweifel betrifft das auch die Richtlinieneinstellungen, welche sagen „(wenn WSUS genutzt wird), lade Komponente X trotzdem von Onlinequellen“. Insbesondere dürften in keiner GPO http/https-Adressen bzgl. Windows-Updates konfiguriert sein. Der Dienst Windows-Update im Client kennt die Microsoft-Server von Haus aus.
Ein Austritt aus der Domäne setzt keine Gruppenrichtlinieneinstellungen zurück. Es können Reste an diesen Stellen bleiben:
Hallo,
vielen Dank für die rasche Rückmeldung. In der Tat hat es aufgrund der mehrdeutigen Namensgebung von Windows zu einem Missverständnis geführt, denn wir haben keinen Windows-Server bei uns in Betrieb genommen. Da hätte ich bei meiner Problembeschreibung wahrscheinlich noch präziser sein müssen. Es ging in erster Linie um Windows-Updates und die Optionalen Features, die im umgangssprachlichen Windows Update Server als Paket zum Download bereitstehen.
Da ich die Rolle als Windows-Client-Beauftragter übernommen habe und nicht komplett von Beginn an dabei war, sind dies vielleicht einige Grenzen an die ich stoße. So wie ich es mitbekommen habe sind die GPOs für den WSUS eingeschaltet, sodass während des normalen Schulbetriebs keine Updates installiert geschweige denn eine Update-Meldung auf den Clients zu sehen ist. Ich meine, dass das der Grund war, weshalb in diesem Kontext eine GPO erstellt wurde mit dem Verweis auf eine fiktive IP-Adresse - mittlerweile wird man das sicherlich auch anders regeln können.
Verwunderlich bleibt es für mich nach wie vor, dass die Updates nicht geladen werden können, wenn diese GPO deaktiviert ist. Wie bereits in meiner vorangegangenen Nachricht erwähnt, vermute ich, dass noch andere GPOs hier ein Problem darstellen.
… eigentlich kann es ja so nicht gehen: dass die Windowsclients selber Updates holen, selbst wenn du den Proxy einträgst, da sie am Proxy zerschellen, der ja nur denjenigen durch läßt, der ein gültige Cerberos Ticket vorzeigen kann (das der Clietn nciht hat).
Wenn du also deine Clients aktuell halten willst, dann kommst du (meines Wissens nach) nicht umhin einen WSUS ins Netz zu stellen, der die Updates am Proxy vorbei holt und im lokalen Netz bereitstellt (der WSUS Rechner steht dan in der Proxyausnahmeliste, dass er direkt ins Netz kann: da meldet sich ja auch nie Jemand an).
Ich verfahre nicht so, weil Windwosupdates nicht zu unserem Sicherheitskonzept gehören, sondern linbo.
Die Rechner werden bei jedem Start gesynct (automatischer Start Morgends vor der ersten Stunde an Schultagen).
Windowsupdates sind nicht bekannt für ihre unproblematische Handhaben: ich habe updates mittels eines updateblockers in Windows komplett deaktiviert. Das mache ich seit 20 Jahren so und hatte nochnie Probleme damit.
der Nutzer SYSTEM läuft mit dem AD-Computerkonto „<Computername>$“ und das hat Kerberos-Tickets, sonst könnte ja noch vor der Nutzeranmeldung die Anmeldung des Computers am AD nicht über Kerberos abgesichert verifiziert werden. Online-Updates ohne WSUS funktionieren ohne weiteres, wenn man den Proxy mittels netsh-winhttp-Methode setzt, aber das ist nicht das Problem des OP. Er will ja WSUS-Einstellungen nur missbrauchen, um Windows Updates zu unterbinden. Dafür gibt es aber eigene Einstellungen.
Was hier zuverlässig hilft Windows Updates zu unterbinden sind diese Gruppenrichtlinien-Einstellungen: