none
Fehler 0x800705b4 bei jedem Windows Server Update

    Frage

  • Hallo allerseits,

    ich hab mittlerweile bei mehreren Server 2016 Systemen das Problem, dass die Installation der kumulativen Updates mit der Fehlermeldung 0x800705b4 fehlschlägt, wenn diese vom WSUS oder auch von WU gezogen werden. Bisher waren es einige Systeme in der Testumgebung, mittlerweile hab ich es auch schon bei produktiven Systemen gesehen. 

    Eine manuelle Installation des über den Update Catalog heruntergeladenen Updates funktioniert. Ist aber halt kein Dauerzustand, Updates immer manuell zu installieren. 

    Das Problem taucht sowohl bei physischen als auch bei virtuellen Maschinen auf, gerne allerdings wohl bei Systemen, die nicht so massig Performance haben

    Beispielsystem 1: Intel NUC5CPYH, 8 GB Ram (6 GB frei), Intel SSD. Wird als reiner DC ohne jegliche weitere Software im Testnetz betrieben. Server 2016 Standard, kein Virenscanner, keine sonstigen Installationen. Als Rollen nur der DC installiert.

    Beispielsystem 2: HP Microserver Gen8, Xeon CPU, 32 GB, ESXi 6.0, darauf zwei VMs mit Server 2016 Standard, verschiedene Rollen installiert, die VMs werden als DC und Fileserver in kleinen Außenstandorten genutzt. 

    Was bereits erfolglos versucht wurde:

    - Neustart vor der Installation
    - Zurücksetzen der Windows Update Funktion und Löschen von CatRoot2 und Softwaredistribution
    - der integrierte Windows Defender wurde deaktiviert

    Im Netz finden sich mehrere Berichte, wo als Lösung immer nur "manuell installieren" kam. Das ist leider keine Lösung. Hat jemand eine tatsächliche Lösung?

    Danke und Grüße, 

    Ingo


    cu, Ingo

    Mittwoch, 14. Februar 2018 20:46

Alle Antworten

  • Am 14.02.2018 schrieb Ingo Böttcher [MVP]:

    ich hab mittlerweile bei mehreren Server 2016 Systemen das Problem, dass die Installation der kumulativen Updates mit der Fehlermeldung 0x800705b4 fehlschlägt, wenn diese vom WSUS oder auch von WU gezogen werden. Bisher waren es einige Systeme in der Testumgebung, mittlerweile hab ich es auch schon bei produktiven Systemen gesehen. 

    Ist es wirklich die Installation oder der Download? Wie viele Einträge
    vom WSUS hat dein Server? Zwei oder drei? Es sollten drei sein. AFAIR
    hatten wir am Anfang auch diese Fehler, den dritten Eintrag via GPO
    setzen, booten, schon hatte alles geklappt.

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    UpdateServiceUrlAlternate
    http://DeinWSUS:8530 eintragen.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Donnerstag, 15. Februar 2018 05:52
  • Danke für den Tipp. Ich habe es grad mal kontrolliert: es sind momentan zwei Einträge für den WSUS im Test-Netz in der GPO. Ich werde den dritten Eintrag mal dazu packen. Im Produktiv-Netz sind allerdings eh schon alle drei Einträge gesetzt. 

    Allerdings gibt es ja auch genauso in beiden Umgebungen Server, die mit den aktuellen Einstellungen problemlos updaten können. Sollte sich der Eintrag nicht auf alle 2016er Server gleich auswirken? 


    cu, Ingo

    Donnerstag, 15. Februar 2018 18:29
  • Am 15.02.2018 schrieb Ingo Böttcher [MVP]:

    Danke für den Tipp. Ich habe es grad mal kontrolliert: es sind momentan zwei Einträge für den WSUS im Test-Netz in der GPO. Ich werde den dritten Eintrag mal dazu packen. Im Produktiv-Netz sind allerdings eh schon alle drei Einträge gesetzt. 

    Sind die produktiven Server alle auf der gleichen Build?

    Allerdings gibt es ja auch genauso in beiden Umgebungen Server, die mit den aktuellen Einstellungen problemlos updaten können. Sollte sich der Eintrag nicht auf alle 2016er Server gleich auswirken?

    Sollte ja, prüf doch mal die Build der Server.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Donnerstag, 15. Februar 2018 21:38
  • Ja. Die produktiven Server sind alle auf dem Stand des Januar 2018 Updates. Die Testserver waren es bis gestern auch. Von fünf Maschinen im Testnetz haben diesmal drei das Update problemlos eingespielt, zwei liefen in die genannte Fehlermeldung.

    Das Problem an sich taucht aber schon länger auf. Ich habe halt im Testnetz in den letzten Monaten die Updates immer auf den betroffenen Maschinen manuell installiert und gehofft, dass es nur ein Problem mit dem jeweiligen Update wäre. Ist es aber demnach wohl nicht. 

    Edit: eine der Maschinen (VM unter Hyper-V) wurde testweise vor etwa zwei Monaten neu installiert. Änderte an der Sache wenig. 


    cu, Ingo


    Donnerstag, 15. Februar 2018 21:43
  • Am 15.02.2018 schrieb Ingo Böttcher [MVP]:

    Edit: eine der Maschinen (VM unter Hyper-V) wurde testweise vor etwa zwei Monaten neu installiert. Änderte an der Sache wenig.

    Kannst Du die komplette Server GPO Einstellungen hier posten? Ich kann
    sie dann mit unseren vergleichen, evtl. findet man etwas.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Freitag, 16. Februar 2018 05:57
  • Ich glaube zwar, dass wir da auf dem falschen Weg sind, aber klar, kann ich gerne machen. Wie gesagt, ich würde bei einer falschen Einstellung erwarten, das Problem auf allen Systemen zu sehen. Es ist aber nur auf den langsameren Systemen vorhanden.

    WSUS

    Daten ermittelt am: 16.02.2018 21:11:50
    Alle ausblenden
    AllgemeinAusblenden
    DetailsAusblenden
    Domäne example.com
    Besitzer EXAMPLE\Domänen-Admins
    Erstellt 01.02.2008 22:52:08
    Geändert 15.02.2018 19:26:08
    Benutzerrevisionen 0 (AD), 0 (SYSVOL)
    Computerrevisionen 17 (AD), 17 (SYSVOL)
    Eindeutige ID {4881E15A-3B87-4076-A60E-B0FEDE8769FF}
    GPO-Status Benutzereinstellungen deaktiviert
    VerknüpfungenAusblenden
    Standort Erzwungen Verknüpfungsstatus Pfad
    Alle Computer Nein Aktiviert example.com/Alle Computer
    Domain Controllers Nein Aktiviert example.com/Domain Controllers
    Server Nein Aktiviert example.com/Server

    Die Liste enthält Verknüpfungen zur Domäne des Gruppenrichtlinienobjekts.
    SicherheitsfilterungAusblenden
    Die Einstellungen dieses Gruppenrichtlinienobjekts können nur auf folgenden Gruppen, Benutzer und Computer angewendet werden:
    Name
    NT-AUTORITÄT\Authentifizierte Benutzer
    DelegierungAusblenden
    Folgende Gruppen und Benutzer haben die angegebene Berechtigung für das Gruppenrichtlinienobjekt
    Name Zulässige Berechtigungen Geerbt
    NETPARTY\Domänen-Admins Einstellungen bearbeiten, löschen, Sicherheit ändern Nein
    NETPARTY\Organisations-Admins Einstellungen bearbeiten, löschen, Sicherheit ändern Nein
    NT-AUTORITÄT\Authentifizierte Benutzer Lesen (durch Sicherheitsfilterung) Nein
    NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION Lesen Nein
    NT-AUTORITÄT\SYSTEM Einstellungen bearbeiten, löschen, Sicherheit ändern Nein
    Computerkonfiguration (Aktiviert)Ausblenden
    RichtlinienAusblenden
    Administrative VorlagenAusblenden
    Richtliniendefinitionen (ADMX-Dateien) wurden aus dem zentralen Speicher abgerufen.
    Windows-Komponenten/ÜbermittlungsoptimierungAusblenden
    Richtlinie Einstellung Kommentar
    Downloadmodus Aktiviert
    Downloadmodus: Gruppe (2)
    Windows-Komponenten/Windows UpdateAusblenden
    Richtlinie Einstellung Kommentar
    Automatische Updates konfigurieren Aktiviert
    Automatische Updates konfigurieren: 4 - Autom. Herunterladen und laut Zeitplan installieren
    Die folgenden Einstellungen sind nur erforderlich und anwendbar, wenn die Option 4 ausgewählt wurde.
    Während automatischer Wartung installieren Aktiviert
    Geplanter Installationstag: 0 - Täglich
    Geplante Installationszeit: 03:00
    Wenn Sie für den geplanten Installationstag "4 - Autom. herunterladen und laut Zeitplan installieren" ausgewählt und einen Zeitplan angegeben haben, können Sie mithilfe der folgenden Optionen Updates auch einmal pro Woche, alle zwei Wochen oder einmal pro Monat suchen lassen:
    Jede Woche  
    Erste Woche des Monats  
    Zweite Woche des Monats  
    Dritte Woche des Monats  
    Vierte Woche des Monats  
    Updates für andere Microsoft-Produkte installieren Aktiviert
    Richtlinie Einstellung Kommentar
    Automatische Updates sofort installieren Aktiviert
    Empfohlene Updates über automatische Updates aktivieren Aktiviert
    Erneut zu einem Neustart für geplante Installationen auffordern Deaktiviert
    Internen Pfad für den Microsoft Updatedienst angeben Aktiviert
    Interner Updatedienst zum Ermitteln von Updates: https://srvapp1.example.com:8531
    Intranetserver für die Statistik: https://srvapp1.example.com:8531
    Alternativen Downloadserver festlegen: https://srvapp1.example.com:8531
    (Beispiel: http://IntranetUpd01)
    Dateien ohne URL in den Metadaten herunterladen, wenn ein alternativer Downloadserver festgelegt ist Deaktiviert
    Richtlinie Einstellung Kommentar
    Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind Aktiviert
    Signierte Updates aus einem Intranetspeicherort für Microsoft-Updatedienste zulassen Aktiviert
    Softwarebenachrichtigungen aktivieren Aktiviert
    Suchhäufigkeit für automatische Updates Aktiviert
    In folgenden Abständen (Stunden)
    nach Updates suchen: 1

    cu, Ingo

    Freitag, 16. Februar 2018 20:15
  • Am 16.02.2018 schrieb Ingo Böttcher [MVP]:

    Ich glaube zwar, dass wir da auf dem falschen Weg sind, aber klar, kann ich gerne machen. Wie gesagt, ich würde bei einer falschen Einstellung erwarten, das Problem auf allen Systemen zu sehen. Es ist aber nur auf den langsameren Systemen vorhanden.

    So ganz glaub ich nicht, dass wir auf dem falschen Weg sind. Der
    Unterschied ist, wir benutzen den BITS komplett von den
    Clients/Servern von/zum WSUS.

    http://gpsearch.azurewebsites.net/#11083
    Das wäre dann die Option 100 bei dir. Du kannst das ja für ein paar
    Testserver umstellen und beobachten, wie es sich verhält. Wobei ich
    nach der Umstellung und nachdem der Client/Server sich das GPO so
    gezogen hat, erneut Softwaredistribution leeren würde.

    Zusätzlich wird in diesem Thread auf einen sauberen Neustart
    verwiesen, anschauen kann sicherlich nicht schaden.
    https://partnersupport.microsoft.com/en-us/par_servplat/forum/par_winserv/server-2016-std-windows-update-0x800705b4/28df8b5a-7d6d-4bbb-abb8-da3f1556a2dd?auth=1

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Samstag, 17. Februar 2018 09:15
  • hast du den RegKey für QualityCom drinnen?

    https://support.microsoft.com/eu-es/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software

    ansonsten installiere bitte das letzte Update 2018-02 einmal manuell.  


    Chris

    Sonntag, 18. Februar 2018 13:48
  • Ja, habe ich. Wird per GPO verteilt. 

    Ich installiere die letzten Monate schon immer manuell. Langsam sollte es mal wieder automatisch gehen. ;-) 


    cu, Ingo

    Sonntag, 18. Februar 2018 13:53
  • windows update und BITS Service stoppen, c:windows Softwaredistribution umbenennen, Dienste wieder starten

    Chris

    Sonntag, 18. Februar 2018 15:48
  • Hatte ich bereits gemacht, wie bereits im Ausgangsposting geschrieben. 

    cu, Ingo

    Sonntag, 18. Februar 2018 15:49
  • Hallo Ingo,

    ich bin Admin für 2 Domänen(Standorte). An beiden Standorten werden Windows Server 2012R2 und Windows Server 2016 als phys. Hyper-V Hosts und auch als virtuelle Maschinen betrieben.

    Der gegenwärtige Ist-Zustand: Auf allen(!) phys.(!) Windows 2016 Servern mit der Hyper-V-Rolle an beiden Standorten funktionieren die kumulativen Updates nicht. Die Defender-Updates aber schon.

    Anders gesagt: Auf allen(phys. + virt.) Windows 2012R2 Servern und allen virtuellen Windows 2016 Servern funktionieren alle Windows-Updates.

    Ein phys. Windows 2016 Server läuft als Datacenter ohne die Hyper-V-Rolle - auch hier funktionieren die Windows-Updates.

    Fazit: Mein Verdacht ist die Hyper-V-Rolle, ev. ein Netzwerk-Kommunikationsproblem (virtuelle Switches)

    Ich lade die Updates seit ca. 6 Monaten vom Update-Katalog runter und installiere sie manuell.

    Das kostet Zeit und Geld und die Hoffnung stirbt zuletzt, dass Microsoft das in den Griff bekommt.

    Bg, Mathias

    Mittwoch, 21. März 2018 08:38
  • Danke für die Rückmeldung, aber die Beobachtung kann ich nicht teilen.

    Der Timeout-Fehler tritt hier auf (langsameren) physischen und virtuellen Servern auf, die kein Hyper-V-Host sind.

    Auf dem Hyper-V-Host selber taucht er hingegen nicht auf. Zumindest ich sehe hier keinen Zusammenhang zu Hyper-V.


    cu, Ingo

    Mittwoch, 21. März 2018 23:07
  • Hallo Ingo,

    die von Dir beschriebenen Fehler beim Updateservice für Windows Server 2016 Systeme scheint es sich um keinen Einzelfall zu handeln. Auch wir sind hier betroffen, und zwar ebenfalls mit mehreren Server 2016 Maschinen die unter VMware virtualisiert sind. Die Updates werden herunter geladen, aber deren Installation schlägt schließlich fehl. Dabei handelt es sich bei den Servern teilweise um Domänencontroller und/oder Domänenmitglieder, aber auch Server die nicht Mitglied in einer Domäne sind, sind gleichermaßen davon betroffen.

    Über die PowerShell konnten die Windows Updates auch installiert werden. Ebenso konnten über den Windows Updatekatalog heruntergeladene Updates installiert werden. Nur die automatische Windows Updateroutine scheitert. Es werden aber nur kommulative Monatsupdates nicht installiert. Andere Updates können installiert werden.

    Als Schutzmodul wird auf allen Rechnern nur Defender von Microsoft eingesetzt.

    Wir haben einen Fall beim Support von Microsoft dazu eröffnet. Aber auch dort hat man wohl keine Lösung. Wenn ich neue Erkenntnisse habe melde ich mich wieder.

    Andreas

    Freitag, 18. Mai 2018 04:53
  • Danke, ich bin gespannt. Das Problem ist hier zumindest auch weiterhin vorhanden.

    cu, Ingo

    Freitag, 18. Mai 2018 20:15
  • ohja, und wir seit heute auch. Gibt es schon Neuigkeiten?
    Mittwoch, 13. Juni 2018 14:43
  • Gleiches Problem hier, seit mehreren Monaten. Bin mal gespannt...
    Mittwoch, 27. Juni 2018 20:23
  • Hallo Forum

    Wir stehen vor dem gleichen Problem.

    Server lassen sich nicht gegen Online mit den CUs patchen und müssen immer manuell hochgezogen werden.

    Reboots helfen auch nicht, löschen des Softwaredistributions-Folder hilft nicht.

    Gibt es schon Neuigkeiten?

    Donnerstag, 9. August 2018 11:11
  • Hallo Para el Mundo,

     

    ja, zwischenzeitlich hatten wir beim Microsoft Support einen Fall eröffnet, und es wurde uns eine Herangehensweise vorgeschlagen, die in unserem Fall zur Lösung geführt hat.

     

    Hier die Instruktionen des Microsoft Helpdesks:

     

    1. Check for updates

    2. Open cmd as administrator and type

    net stop wuauserv 

    regsvr32 %WinDir%\System32\wups2.dll 

    net start wuauserv

    3. Check for updates again

    -================================================-

     

    Falls das nicht geholfen hat sind noch folgende Schritte auszuführen:

     

    1. open the updates settings window

    2. click the “Advanced options” link.

    3. enable (tick on) the option to receive updates for other Microsoft products

    4. Check for updates one more time.

    5. In case again fails follow steps from AP1

     

    Bitte teilen Sie mir gerne mit, ob die vorgenannte Herangehensweise auch in Ihrem Fall zum Erfolg geführt hat.

     

    Mit bestem Gruß

     

    Andreas Neubauer


    Donnerstag, 9. August 2018 11:28
  • Keine der Varianten hilft hier.

    Die genannte Systemdatei sollte an sich eh registriert sein. Sie ist ja Teil von Windows Update. Auch mit der erneuten Registrierung ändert sich nichts. Die Option zum Laden von Updates für andere Microsoft Produkte ist hier eh schon aktiv gewesen. 


    cu, Ingo

    Donnerstag, 9. August 2018 19:01
  • Ich kämpfe auch auf vielen Servern mit dem 0x800705b4 Fehler.

    Wie bei Dir hilft das manuelle Installieren des vollständigen Updates (die ca. 1,2 - 1,4 GB Pakete).

    Es sind diverse Server, die meisten (oder alle? müsste das mal prüfen) mit Windows Server 2016 Essentials oder Windows Server 2016 Standard + Essentials Rolle.

    Leistungsschwache (z.B. HP Microserver Gen10) aber auch leistungsstarke (HP DL160 u.a.) dabei.

    Hyper-V ist teilweise im Einsatz.

    Unterschiedliche Virenscanner.

    WSUS ist nirgendwo im Spiel.

    "Microsoft Update" ist überall aktiviert.

    Jedenfalls SEHR lästig. Gefühlsmäßig tritt das Problem seit dem 2018-04 Update auf?

    Wenn jemand eine Lösung hat wäre ich sehr dankbar! ;-)

    Grüße, FFK

    Sonntag, 12. August 2018 15:52
  • Moin,

    wir haben das Problem bei uns auch, diverse Server mit der Fehlermeldung und ich kann dein Gefühl bestätigenseit dem 2018-04 gibt es die Probleme. Bisher sind alle Lösungen Fehlgeschlagen, nur die manuelle installation war erfolgreich.

    gruss

    Sebastian

    Mittwoch, 15. August 2018 08:08
  • net stop wuauserv 

    regsvr32 %WinDir%\System32\wups2.dll 

    net start wuauserv

    Danke fürs Teilen! Das hat mir geholfen.

    KB4457131 konnte ich nicht einmal mehr händisch installieren. Es lief für Stunden, nur um nach einem Neustart trotzdem wieder "Fehler" im Updateverlauf anzuzeigen. Nach einem "sfc /scannow", Neustart und den drei Schritten, ließen sich Updates über Windows Updates ganz fix einspielen.

    Freitag, 14. September 2018 18:35
  • Hat alles bei mir nicht geholfen. Die letzten monatlichen Updates werden einfach verweigert. Auch manuelle Installation schlägt fehl. Hoffentlich bessert Microsoft da bald nach. Es darf doch nicht wahr sein, dass man seinen Server neu aufsetzen soll, wie es vom Microsoft Support an meine Adresse vorgeschlagen wurde.
    Dienstag, 18. September 2018 19:22
  • Folgende Lösung:

    Anmerkung: Neustarts nie abbrechen, auch wenn sehr lange die Meldung angezeigt wird: „Windows wird vorbereitet, schalten sie den Computer nicht aus“. Diese Meldung wurde mir auch schon über 4 Stunden angezeigt.

    Hier die Schritte, die ich gemacht habe:

    Microsoft Defender deaktivieren

    Sfc /scannow in der Eingabeaufforderung (als Administrator)

    (dauert ca. 30 Minuten)

    Im CBS.log wurde eine Datei als repariert gekennzeichnet:

    Info CSI 0000e805 [SR] Repairing corrupted file \??\C:\Windows\SysWOW64\NlsData0000.dll from store

    Diese Datei (NlsData0000.dll) ist laut Support noch aus einem Juni-Update und kann ignoriert werden.

    Server neu starten und unmittelbar nach dem Neustart in der Eingabeaufforderung als Administrator folgendes eingeben:

    net stop wuauserv

    regsvr32 %WinDir%\System32\wups2.dll 

    net start wuauserv

    Microsoft Update Problembehandlung für Windows 10 herunterladen und ausführen. (wu170509.diagcab).

    https://support.microsoft.com/de-de/help/4027322/windows-update-troubleshooter

    Dabei den ersten Punkt Windows Update auswählen. (Dauert ca. 10 Minuten)

    Alle Reparaturpunkte, die angeboten werden ausführen. Bei mir wurde unter anderem eine defekte Windows Update Datenbank gefunden und das Problem wurde behoben. Auch „ausstehende Updates herunterladen und installieren“ auswählen.

    Windows Defender muss deaktiviert sein. Vorsichtshalber prüfen

    Windows Update, erweiterte Optionen aufrufen und sicherstellen, dass der Haken bei „Update für weitere Microsoft Produkte bereitstellen“ gesetzt ist.

    Windows Update starten.

    Folgende Schritte werden angezeigt:

    Installation von Updates wird vorbereitet (0%) ca. 10 Minuten

    Installation von Updates wird vorbereitet (10%) ca. 15 Minuten

    Nach ca. weiteren 10 Minuten ist das Update beendet und der Server muss neu gestartet werden. Dauer des Neustarts ca. 1 Stunde 10 Minuten

    Sollte das Update nicht geklappt haben, einfach die Schritte noch einmal durchführen. Also mit sfc /scannow beginnen. Bei einigen Servern musste ich das 2x wiederholen.

    Windows Defender wieder aktivieren und Windows Defender Definitionen manuell aktualisieren.

    Bei Servern, bei denen ich diese Schritte vor dem letzten Update durchgeführt habe, konnte ich die nachfolgenden Updates nach einem Server Neustart normal über Windows Update installieren und der nachfolgende Serverneustart dauerte auch nicht mehr so lange.

    Mal sehen, wie es beim nächsten Update läuft.

    Sonntag, 23. September 2018 16:41
  • Nachtrag: Mir fiel jetzt noch auf, dass die kumulativen Updates nur durchlaufen, wenn der Energiesparplan auf Höchstleistung gestellt ist. Mit "Ausbalanciert (empfohlen)" scheitert es.

    Sonntag, 23. September 2018 21:12
  • Bei mir hat die Untersuchung des CBS.log ergeben, dass der Server sich das Polnische Sprachpaket wünscht und er ein File aus einem vorhergehenden Update nicht finden kann. Also dieses Update neu installiert und auch das Polnische Sprachpaket. Dann war noch die Updatedatenbank beschädigt, also diese auch zum Neuaufbau gelöscht. Danach konnte ich alle fehlenden Updates manuell installieren und der Server ist erst einmal auf dem aktuellen Stand. Allerdings weigert er sich noch, ein paar Rollen zu installieren. Mal sehen, ob ich ihm dies auch noch abgewöhnen kann oder ob sich das in einem zukünftigen Update von selbst behebt.
    Montag, 24. September 2018 07:26