6
GPO Reste aus alter Domain entfernen (WSUS)
Hallo zusammen,
ich habe mich endlich mal von einer Altlast getrennt (Hyper-V Server in produktiver Domain/AD-Struktur).
Eigentlich hat das problemlos funktioniert, aber gestern Abend wollte ich die aktuellen Updates einspielen und bin auf ein Problem gestoßen:
Zum Hergang, in der "alten" Domain gibt es einen WSUS und eine entsprechende GPO.
Die Managementdomain hat aktuell keinen WSUS und die Updates stehen auf manuell.
Gemäß des o.g. Fehlercodes verweist Microsoft auf
Also kann der Zielname wohl nicht aufgelöst werden, was logisch wäre, aber warum sollte er noch dahin wollen?
Unter
gibt es keinen WindowsUpdate-Eintrag mehr.
Also haben die Server 2022 Datacenter ein paar Leichen im Keller.
Ich bin nun auf diesen Pfad aufmerksam geworden:
Dort gibt es ein CacheSet001 & CacheSet002 und letzteres beinhaltet noch den alten WSUS.
Cache klingt für mich als ob man das einfach löschen könnte, bzw. das automatisch aufgeräumt werden sollte.
Ein Reboot hat das aber nicht getan.
Ein Abgleich mit den anderen Systemen im Management offenbart mir, dass es CachSet002 auch dort gibt, nur ohne die Einträge zum WSUS.
Also was tun?
Letzteres wäre mir wohl recht, aber vermutlich wird es auf "löschen" hinauslaufen?
Grüße
ToWa
ich habe mich endlich mal von einer Altlast getrennt (Hyper-V Server in produktiver Domain/AD-Struktur).
Eigentlich hat das problemlos funktioniert, aber gestern Abend wollte ich die aktuellen Updates einspielen und bin auf ein Problem gestoßen:
Zum Hergang, in der "alten" Domain gibt es einen WSUS und eine entsprechende GPO.
Die Managementdomain hat aktuell keinen WSUS und die Updates stehen auf manuell.
Gemäß des o.g. Fehlercodes verweist Microsoft auf
0x8024402C – Der Proxyserver- oder Zielservername kann nicht aufgelöst werden.
da die anderen Systeme im Management problemlos Updates ziehen konnten und es nur die zwei Server betrifft, die zuvor über einen WSUS versorgt wurden, schließe ich den Zugriff aufs Internet aus (ping auf www.google.de klappt ebenfalls).Also kann der Zielname wohl nicht aufgelöst werden, was logisch wäre, aber warum sollte er noch dahin wollen?
Unter
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsAlso haben die Server 2022 Datacenter ein paar Leichen im Keller.
Ich bin nun auf diesen Pfad aufmerksam geworden:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate\UpdatePolicy\GPCacheCache klingt für mich als ob man das einfach löschen könnte, bzw. das automatisch aufgeräumt werden sollte.
Ein Reboot hat das aber nicht getan.
Ein Abgleich mit den anderen Systemen im Management offenbart mir, dass es CachSet002 auch dort gibt, nur ohne die Einträge zum WSUS.
Also was tun?
- UpdatePolicy oder GPCache einfach löschen und schauen, ob er neu anlegt.
- UpdatePolicy von einem anderen System importieren?
- GPCache über einen mir nicht bekannten Befehl auf Default setzen?
Letzteres wäre mir wohl recht, aber vermutlich wird es auf "löschen" hinauslaufen?
Grüße
ToWa
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671919
Url: https://administrator.de/forum/gpo-reste-aus-alter-domain-entfernen-wsus-671919.html
Ausgedruckt am: 25.03.2025 um 19:03 Uhr
6 Kommentare
Neuester Kommentar
Moin.
Die WSUS-Policy greift nicht mehr, der Cache hat damit nichts zu tun.
Um dich dessen zu versichern, lade dir bitte wuinstall runter und starte
wuinstall /search
Der sagt Dir dann schon, ob er noch gegen einen WSUS geht, oder nicht.
https://web.archive.org/web/20151227002916/http://www.hs2n.at/component/ ...
Die WSUS-Policy greift nicht mehr, der Cache hat damit nichts zu tun.
Um dich dessen zu versichern, lade dir bitte wuinstall runter und starte
wuinstall /search
Der sagt Dir dann schon, ob er noch gegen einen WSUS geht, oder nicht.
https://web.archive.org/web/20151227002916/http://www.hs2n.at/component/ ...
1
Hmm OK, der sagt mir das, was Microsoft mir auch sagt + kein WSUS mehr konfiguriert:
Dann frage ich mich also, was passiert dort und wie bekomme ich die Server wieder ans WindowsUpdate?
Grüße
ToWa
Gute Frage.
Da muss wohl schon tiefer gebohrt werden (tcpview/procmon/Wireshark/fiddler), um zu sehen, was er vor dem Fehler gerade versucht hat.
Da muss wohl schon tiefer gebohrt werden (tcpview/procmon/Wireshark/fiddler), um zu sehen, was er vor dem Fehler gerade versucht hat.
Zitat von @dertowa:
Gemäß des o.g. Fehlercodes verweist Microsoft auf
Das eine hat mit dem anderen nichts zu tun. Wenn man einen falschen Proxy eingetragen hat, dann kann man pingen bis zum Mond. Es würde nichts nützen.Gemäß des o.g. Fehlercodes verweist Microsoft auf
0x8024402C – Der Proxyserver- oder Zielservername kann nicht aufgelöst werden.
da die anderen Systeme im Management problemlos Updates ziehen konnten und es nur die zwei Server betrifft, die zuvor über einen WSUS versorgt wurden, schließe ich den Zugriff aufs Internet aus (ping auf www.google.de klappt ebenfalls).Also unter dem aktuellen Benutzer und unter System prüfen, ob da ein Proxy eingetragen ist und ob dieser korrekt ist.
Oder PAC oder WPAD.
Tja, nur dass es nie einen Proxy gab, geschweige denn jetzt gibt.
Der müsste sich also durch Domain Aus- und Eintritt selbst herbeigezaubert haben.
Entsprechend soll man manchmal ja seinem Gefühl folgen...
Morgen nehm ich mir die Registryeinträge mal genauer vor, aber dort liegt somit der Quell allen Übels.
Grüße
ToWa
Der müsste sich also durch Domain Aus- und Eintritt selbst herbeigezaubert haben.
Entsprechend soll man manchmal ja seinem Gefühl folgen...
- UpdatePolicy kurzerhand umbenannt
- WindowsUpdate Dienst neugestartet -> kein UpdatePolicy mehr entstanden
- gpupdate ausgeführt -> auch nix passiert
- Updates suchen lassen -> zack Registryeintrag wieder da und tada:
Morgen nehm ich mir die Registryeinträge mal genauer vor, aber dort liegt somit der Quell allen Übels.
Grüße
ToWa
So, der zweite Hyper-V Server zeigt übrigens 0x80072EE2 an bei der Suche, also ein wenig anders.
Das ist dann laut MS: Überprüfungsfehler im Zusammenhang mit HTTP-Timeout oder Authentifizierung
Deutet laut MS ebenfalls auf einen WSUS hin.
Lustig dabei, in meinem o.g. Registrypfad ist nun anders als beim Server 01 kein Eintrag zum WSUS vorhanden.
Links Server 01 und rechts Server 02
Den Standard, welchen WindowsUpdate nach der Umbenennung angelegt hat, hier mal im Vergleich.
Links Server 02 (weil dort etwas kompaktere Daten) und rechts Standard:
Hätte müsste sollte beim Server 02 also problemlos funktionieren, tat es aber nicht.
Hier war der Grund tatsächlich ein anderer, die Schnittstelle mit dem Gateway hatte noch die falsche VLAN Zuordnung.
Äußerst komplex diese IT, andere würden sagen vielschichtig (deswegen wird es auch nie langweilig).
Grüße
ToWa
Das ist dann laut MS: Überprüfungsfehler im Zusammenhang mit HTTP-Timeout oder Authentifizierung
Deutet laut MS ebenfalls auf einen WSUS hin.
Lustig dabei, in meinem o.g. Registrypfad ist nun anders als beim Server 01 kein Eintrag zum WSUS vorhanden.
Links Server 01 und rechts Server 02
Den Standard, welchen WindowsUpdate nach der Umbenennung angelegt hat, hier mal im Vergleich.
Links Server 02 (weil dort etwas kompaktere Daten) und rechts Standard:
Hätte müsste sollte beim Server 02 also problemlos funktionieren, tat es aber nicht.
Hier war der Grund tatsächlich ein anderer, die Schnittstelle mit dem Gateway hatte noch die falsche VLAN Zuordnung.
Äußerst komplex diese IT, andere würden sagen vielschichtig (deswegen wird es auch nie langweilig).
Grüße
ToWa
