12
1607 Update über WSUS Server 2016 - Fehler 0x8000ffff
Hallo Zusammen,
ich verzweifle gerade an der Verteilung des dusseligen Anniversary Updates
Wir hatten bis vor kurzem nur Server 2008 R2, weshalb ich es bis dato aus bekannten Gründen gar nicht verteilen konnte.
Nun haben wir einen ersten Server 2016 Standard, der nun der neue WSUS werden und endlich alle Clients auf 1607 heben soll (Das will man ja bei dreistelliger Clientanzahl nicht per Hand machen).
Server ist komplett eingerichtet, SSL, Updates, Testclients tauchen auf, alles funktioniert, bis auf das 1607er
Meine Recherche zum Fehler 0x8000ffff führt immer zu angeblich defekten oder nicht lesbaren Installdateien. Alle Lösungen beziehen sich aber eigentlich immer auf Server 2012R2 und das Fehlen eines bestimmten Updates oder wenn das 1607er vor dem besagten Update auf den WSUS heruntergeladen wurde. Lösung ist hier immer gewesen: Bereits geladene 1607er Updates per Powershell löschen (https://support.microsoft.com/en-us/kb/3194588) und neu herunterladen.
Das habe ich gemacht und danach ging es tatsächlich bei einem Client, obwohl ich das nicht verstanden habe, da der Server erst Tage vorher frisch aufgesetzt und der Content neu heruntergeladen wurde. Bevor ich das ganze live schalte, wollte ich aber sicherheitshalber noch ein paar mehr Testupgrades machen.
Gut, dass ich das gemacht habe. Der nächste Testclient zeigt nämlich erneut den 0x8000ffff Fehler.
Wie kann das sein? Es sieht so aus, als ob das Update nach einmaligem Nutzen "kaputt" gegangen wäre. Ist natürlich quatsch, aber ich finde keine Erklärung dafür. Ich kann ja jetzt nicht jedes Mal den WSUS Content resetten...
Ein Löschen des SoftwareDistribution -> Download-Verzeichnisses und $WINDOWS.~BT-Ordners auf den Clients wie anderorts beschrieben hat nichts gebracht.
Habt ihr eine Idee?
Danke!
ich verzweifle gerade an der Verteilung des dusseligen Anniversary Updates
Wir hatten bis vor kurzem nur Server 2008 R2, weshalb ich es bis dato aus bekannten Gründen gar nicht verteilen konnte.
Nun haben wir einen ersten Server 2016 Standard, der nun der neue WSUS werden und endlich alle Clients auf 1607 heben soll (Das will man ja bei dreistelliger Clientanzahl nicht per Hand machen).
Server ist komplett eingerichtet, SSL, Updates, Testclients tauchen auf, alles funktioniert, bis auf das 1607er
Meine Recherche zum Fehler 0x8000ffff führt immer zu angeblich defekten oder nicht lesbaren Installdateien. Alle Lösungen beziehen sich aber eigentlich immer auf Server 2012R2 und das Fehlen eines bestimmten Updates oder wenn das 1607er vor dem besagten Update auf den WSUS heruntergeladen wurde. Lösung ist hier immer gewesen: Bereits geladene 1607er Updates per Powershell löschen (https://support.microsoft.com/en-us/kb/3194588) und neu herunterladen.
Das habe ich gemacht und danach ging es tatsächlich bei einem Client, obwohl ich das nicht verstanden habe, da der Server erst Tage vorher frisch aufgesetzt und der Content neu heruntergeladen wurde. Bevor ich das ganze live schalte, wollte ich aber sicherheitshalber noch ein paar mehr Testupgrades machen.
Gut, dass ich das gemacht habe. Der nächste Testclient zeigt nämlich erneut den 0x8000ffff Fehler.
Wie kann das sein? Es sieht so aus, als ob das Update nach einmaligem Nutzen "kaputt" gegangen wäre. Ist natürlich quatsch, aber ich finde keine Erklärung dafür. Ich kann ja jetzt nicht jedes Mal den WSUS Content resetten...
Ein Löschen des SoftwareDistribution -> Download-Verzeichnisses und $WINDOWS.~BT-Ordners auf den Clients wie anderorts beschrieben hat nichts gebracht.
Habt ihr eine Idee?
Danke!
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: 324083
Url: https://administrator.de/contentid/324083
Ausgedruckt am: 25.11.2024 um 22:11 Uhr
12 Kommentare
Neuester Kommentar
Dort geht es um Updates NACHDEM 1607 installiert wurde. Bei mir scheitert die Installation des 1607 selbst
Hallo,
bevor die Upgrades für 1607 und späer über einen 2012R2 verteilt werden können müssen einige Updates, die Dummerweise nicht bei erforderlich sondern Optional gelistet werden installiert werden.
Ohne die Updates geht die Verteilung von Upgrades nicht.
Wenn man schon 1607 gesynct hat, muss das komplett entfernt werden inc. Datenbankbereinigung (glaube das hattest Du schon gepostet) dann neu syncen und dann kann es verteilt werden.
Gab dazu hier auch schon Beiträge.
Ich sucke mal ob ich die KB noch finde.
Mach das Rollout erst bei einem Testrechner, kann sein das nach dem upgrade kein Netzwerk mehr da ist....
Gruß
Chonta
bevor die Upgrades für 1607 und späer über einen 2012R2 verteilt werden können müssen einige Updates, die Dummerweise nicht bei erforderlich sondern Optional gelistet werden installiert werden.
Ohne die Updates geht die Verteilung von Upgrades nicht.
Wenn man schon 1607 gesynct hat, muss das komplett entfernt werden inc. Datenbankbereinigung (glaube das hattest Du schon gepostet) dann neu syncen und dann kann es verteilt werden.
Gab dazu hier auch schon Beiträge.
Ich sucke mal ob ich die KB noch finde.
Mach das Rollout erst bei einem Testrechner, kann sein das nach dem upgrade kein Netzwerk mehr da ist....
Gruß
Chonta
Ich bin nicht sicher, ob ich dich verstehe. Die Clients waren vorher alle mit einem anderen WSUS verbunden. Haben also alle bis dato verfügbaren 1511 Updates bezogen und sollten dementsprechend für 1607 vorbereitet sein, wie du sagst.
Nich die Clients, der Server braucht Updates, die als Optional eingestuft sind um das Upgrade 1607 verteilen zu können.
Das 1607 wird irgendwie "verschlüsselt" bereitgestellt und damit der WSUS die ESD entschlüsseln kann braucht der Updates.
Mit den Clients hat das nix zu tun, die zeigen nur den Fehler an.
Gruß
Chonta
Das 1607 wird irgendwie "verschlüsselt" bereitgestellt und damit der WSUS die ESD entschlüsseln kann braucht der Updates.
Mit den Clients hat das nix zu tun, die zeigen nur den Fehler an.
Gruß
Chonta
Ja, das habe ich bei meiner Recherche gelesen aber das betrifft doch den 2012. Ich hab nen 2016, für den gibt es das Update afaik gar nicht
Mein Fehler hab das mit dem 2016 WSUS überlesen.
Das mit den ESD ist aber im IIS hinterlegt?
Bei 2016 kann ich leider nix zu sagen, sorry, haben nur 2012R2.
Gruß
Chonta
Das mit den ESD ist aber im IIS hinterlegt?
Bei 2016 kann ich leider nix zu sagen, sorry, haben nur 2012R2.
Gruß
Chonta
Ja, hab ich geprüft. Ist bei 2016 anscheinend standardmäßig drin
.esd
application/vnd.ms-cab-compressed
(http://windows-update-checker.com/FAQ/Windows%2010%201607%20upgrade%20f ..)
.esd
application/vnd.ms-cab-compressed
(http://windows-update-checker.com/FAQ/Windows%2010%201607%20upgrade%20f ..)
Und was sagt das Updatelog auf den cllients?
Hallo
Vielleicht blöde Frage, aber haben deine Clients eine Internet-Verbindung?
Gruss
Vielleicht blöde Frage, aber haben deine Clients eine Internet-Verbindung?
Gruss
Hi.
Ich würde aus Sicherheitsgründen von wsus zur Verteilung von os upgrades wie 1607 abraten. Nimm dir ein freies Wochenende und ein Skript und gut.
Grund: Admin werden dank des Windows 10 Upgrade-Setups
Ich würde aus Sicherheitsgründen von wsus zur Verteilung von os upgrades wie 1607 abraten. Nimm dir ein freies Wochenende und ein Skript und gut.
Grund: Admin werden dank des Windows 10 Upgrade-Setups
Hi,
Ich konnte das Problem lösen.
Zur Lösung muss auf jedem Client, bevor das Upgrade installiert werden kann, die DataStore.edb unter C:\Windows\SoftwareDistribution\DataStore gelöscht werden.
Ich werde also auf allen Clients ein kleines Script ausführen müssen.
net stop wuauserv
RMDIR C:\Windows\SoftwareDistribution\DataStore /S /Q
net start wuauserv
wuauclt.exe /updatenow
Ich habe das Verhalten mit 4 Testrechnern nachstellen können. Manche waren auf der aktuellsten 1511er Version, manche nicht. Der Fehler war überall vorhanden und lies sich überall durch obige Maßnahme lösen. Ich habe nicht den Hauch eines Schimmers, warum das nötig ist, aber es löst das Problem.
@DerWoWusste
Deinen Post kannte ich bereits, danke. Zwischen den Feiertagen sind bei uns aber 90% der Leute nicht hier und die, die hier sind, sind technisch nicht so versiert und kriegen ErsatzPCs für die Zeit, sollte also passen.
Ehrlich gesagt, sehe ich es auch nicht ein, meine Freizeit für die Unfähigkeit von Microsoft zu opfern. Das mal nur so am Rande.
Danke für alle Hilfestellungen
Ich konnte das Problem lösen.
Zur Lösung muss auf jedem Client, bevor das Upgrade installiert werden kann, die DataStore.edb unter C:\Windows\SoftwareDistribution\DataStore gelöscht werden.
Ich werde also auf allen Clients ein kleines Script ausführen müssen.
net stop wuauserv
RMDIR C:\Windows\SoftwareDistribution\DataStore /S /Q
net start wuauserv
wuauclt.exe /updatenow
Ich habe das Verhalten mit 4 Testrechnern nachstellen können. Manche waren auf der aktuellsten 1511er Version, manche nicht. Der Fehler war überall vorhanden und lies sich überall durch obige Maßnahme lösen. Ich habe nicht den Hauch eines Schimmers, warum das nötig ist, aber es löst das Problem.
@DerWoWusste
Deinen Post kannte ich bereits, danke. Zwischen den Feiertagen sind bei uns aber 90% der Leute nicht hier und die, die hier sind, sind technisch nicht so versiert und kriegen ErsatzPCs für die Zeit, sollte also passen.
Ehrlich gesagt, sehe ich es auch nicht ein, meine Freizeit für die Unfähigkeit von Microsoft zu opfern. Das mal nur so am Rande.
Danke für alle Hilfestellungen
