23
Windows Server 2022 Update ohne Funktion - Fehler: 80072EFE
Guten Morgen!
Ich habe hier ein Problem mit einem Windows Server 2022 der seit dem 29.07. plötzlich keine Updates mehr laden kann.
Folgender Fehler wird angezeigt: "Wir konnten keine Verbindung mit dem Updatedienst herstellen. Wir versuchen es später erneut. Alternativ können Sie es jetzt versuchen. Überprüfen Sie Ihre Internetverbindung, falls es immer noch nicht funktioniert.". Ich habe ein Log File erstellt und hier ist der bekannte Fehler: 80072EFE aufgeführt.
Im Updatelog werden folgende Fehler angezeigt:
Es kommt kein Proxy zum Einsatz und ist auch nirgends Konfiguriert.
Weiter unten kommen dann noch folgende Fehlermeldungen:
In dem Zeitraum in dem der Fehler auftrag wurde am System eigentlich nichts verändert. Das kummulative Update 07-2024 wurde bereits ein paar Tage vorher installiert und es gab keine Schwierigkeiten danach.
Was habe ich alles schon probiert?
Da auf dem Virtualisierer noch weitere Server laufen und bei keinem anderen das Problem besteht, schließe ich Fehler in der Internetverbindung und am Virtualiserer aus.
Ehrlich gesagt fällt mir momentan nichts mehr ein...
Hat jemand von euch noch eine Idee oder hatte das Problem in ähnlicher Form und konnte es lösen?
Vielen Dank!
Gruß Markus
Ich habe hier ein Problem mit einem Windows Server 2022 der seit dem 29.07. plötzlich keine Updates mehr laden kann.
Folgender Fehler wird angezeigt: "Wir konnten keine Verbindung mit dem Updatedienst herstellen. Wir versuchen es später erneut. Alternativ können Sie es jetzt versuchen. Überprüfen Sie Ihre Internetverbindung, falls es immer noch nicht funktioniert.". Ich habe ein Log File erstellt und hier ist der bekannte Fehler: 80072EFE aufgeführt.
Im Updatelog werden folgende Fehler angezeigt:
*FAILED* [80072EFE] WinHttp: SendRequestToServerForFileInformation (retrying with default proxy)Weiter unten kommen dann noch folgende Fehlermeldungen:
*FAILED* [80072EFE] Method failed [CSLSClient::GetResponse:625]
*FAILED* [80072EFE] Method failed [CSLSEndpointProvider::GetWUClientData:2275]
*FAILED* [80072EFE] EP: get client data
*FAILED* [80072EFE] Method failed [CSLSEndpointProvider::GetSecondaryServicesEnabledState:1689]
*FAILED* [80072EFE] Method failed [CAgentServiceManager::DetectAndToggleServiceState:2910]
*FAILED* [80072EFE] SLS sync failed during service registration.In dem Zeitraum in dem der Fehler auftrag wurde am System eigentlich nichts verändert. Das kummulative Update 07-2024 wurde bereits ein paar Tage vorher installiert und es gab keine Schwierigkeiten danach.
Was habe ich alles schon probiert?
- Problembehandlung auf Update und auf Netzwerkadapter angewandt
- sfc /scannow ausgeführt
- dism /online /cleanup-image /restorehealt ausgeführt
- Temporäre Dateien aus catroot2 und SoftwareDistribution gelöscht
- ipconfig /flushdns ausgeführt
- nach abgelaufenen Zertifikaten geguckt - nichts gefunden
- Updates deinstalliert - keine Besserung
- manuelle Updates über WSUSOflline installiert, auch das bereits erschienene kumulative Update 08-2024 installiert. Ebenfalls keine Besserung.
- Host Datei auf Einträge geprüft - keine Einträge vorhanden
- Uhrzeit und Datum überprüft. Passen. Uhrzeit und Datum manuell eingestellt - keine Besserung, synchronisiert - keine Besserung.
- Server per Snapshot auf den Stand vom 29.07. und davor zurückgesetzt. Fehler traten jedoch weiterhin auf. Update Suche läuft an, scheint dann zu hängen und nach zig Minuten erscheint dann die bekannte Fehlermeldung. Wird anschließend die Suche erneut gestartet wird die Fehlermeldung bereits nach wenigen Sekunden angezeigt.
- Inplace Reparatur durchgeführt - Apps und Einstellungen wurden behalten. Ohne Besserung.
- Gruppenrichtlinien auf Fehler / Einstellungen geprüft - hier ist mir nichts aufgefallen. Habe dies auch mit anderen Servern abgeglichen um zu sehen ob hier Unterschiede vorliegen.
- virtuelle Netzwerkkarte gelöscht und neu installiert - keine Besserung
- Firewall geprüft, testweise auch deaktiviert - keine Besserung
- DNS Abfragen funktionieren sowohl lokal als auch extern.
Da auf dem Virtualisierer noch weitere Server laufen und bei keinem anderen das Problem besteht, schließe ich Fehler in der Internetverbindung und am Virtualiserer aus.
Ehrlich gesagt fällt mir momentan nichts mehr ein...
Hat jemand von euch noch eine Idee oder hatte das Problem in ähnlicher Form und konnte es lösen?
Vielen Dank!
Gruß Markus
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: 8319465558
Url: https://administrator.de/forum/windows-server-2022-update-ohne-funktion-fehler-80072efe-8319465558.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
23 Kommentare
Neuester Kommentar
Moin,
und der Server hat auch die Möglichkeit aufs Internet zuzugreifen? Das sieht ja nicht danach aus.
Firewall am Gateway?
Gruß
Spirit
und der Server hat auch die Möglichkeit aufs Internet zuzugreifen? Das sieht ja nicht danach aus.
Firewall am Gateway?
Gruß
Spirit
Hallo,
ja der Server hat Zugriff auf das Internet und dieser funktioniert auch. Ein Zugriff auf den Microsoft Update Catalog ist z.B. ohne Probleme möglich.
Gruß
Markus
ja der Server hat Zugriff auf das Internet und dieser funktioniert auch. Ein Zugriff auf den Microsoft Update Catalog ist z.B. ohne Probleme möglich.
Gruß
Markus
- *FAILED* [80072EFE] WinHttp: SendRequestToServerForFileInformation (retrying with default proxy)
Zeig doch mal die Ausgabe vonnetsh winhttp show proxySteht da einer drin dann mittels folgenden Befehls entfernen
netsh winhttp reset proxyGruß
Hallo
@14260433693
Abfrage ergibt:
PS C:\Users\Administrator> netsh winhttp show proxy
Aktuelle WinHTTP-Proxyeinstellungen:
DirectAccess (kein Proxyserver).
Gruß
Markus
@14260433693
Abfrage ergibt:
PS C:\Users\Administrator> netsh winhttp show proxy
Aktuelle WinHTTP-Proxyeinstellungen:
DirectAccess (kein Proxyserver).
Gruß
Markus
Ist ein WSUS für den Abruf von Updates konfiguriert? Kontrolliere die Registry Einstellungen dazu.
Zitat von @14260433693:
Ist ein WSUS für den Abruf von Updates konfiguriert? Kontrolliere die Registry Einstellungen dazu.
Ist ein WSUS für den Abruf von Updates konfiguriert? Kontrolliere die Registry Einstellungen dazu.
Nein, kein WSUS konfiguriert. Hab aber überlegt nun einen zu installieren und zu gucken ob die Updates über einen WSUS möglich wären.
Gruß
Markus
Zitat von @mwormer:
Nein, kein WSUS konfiguriert. Hab aber überlegt nun einen zu installieren und zu gucken ob die Updates über einen WSUS möglich wären.
Gruß
Markus
Zitat von @14260433693:
Ist ein WSUS für den Abruf von Updates konfiguriert? Kontrolliere die Registry Einstellungen dazu.
Ist ein WSUS für den Abruf von Updates konfiguriert? Kontrolliere die Registry Einstellungen dazu.
Nein, kein WSUS konfiguriert. Hab aber überlegt nun einen zu installieren und zu gucken ob die Updates über einen WSUS möglich wären.
Gruß
Markus
"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
und
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate"
sind clean bzw. dessen Inhalt sieht wie aus?
Zitat von @14260433693:
"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
und
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate"
sind clean bzw. dessen Inhalt sieht wie aus?
Zitat von @mwormer:
Nein, kein WSUS konfiguriert. Hab aber überlegt nun einen zu installieren und zu gucken ob die Updates über einen WSUS möglich wären.
Gruß
Markus
Zitat von @14260433693:
Ist ein WSUS für den Abruf von Updates konfiguriert? Kontrolliere die Registry Einstellungen dazu.
Ist ein WSUS für den Abruf von Updates konfiguriert? Kontrolliere die Registry Einstellungen dazu.
Nein, kein WSUS konfiguriert. Hab aber überlegt nun einen zu installieren und zu gucken ob die Updates über einen WSUS möglich wären.
Gruß
Markus
"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
und
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate"
sind clean bzw. dessen Inhalt sieht wie aus?
"HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
selbst ist leer. Im Pfad:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"
ist der Eintrag: AUOption=3 hinterlegt.
bei "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsUpdate"
ist der Eintrag: SupportsUUP=1 hinterlegt.
Beide Einträge sind mit den anderen Servern welche Updates beziehen können identisch.
Gruß
Markus
OK, dann mal folgendes probieren
netsh winsock reset
netsh int ip reset
netsh int tcp reset
shutdown -r -f -t 0Zitat von @14260433693:
OK, dann mal folgendes probieren
OK, dann mal folgendes probieren
netsh winsock reset
netsh int ip reset
netsh int tcp reset
shutdown -r -f -t 0Hab ich schon probiert, brachte nichts. Hab es gerade nochmals durchgeführt und den Server dementsprechend neu gestartet. Keine Änderung
.Zitat von @14260433693:
Mal Reparaturinstallation drüber bügeln.
Mal Reparaturinstallation drüber bügeln.
Habe ich gestern Abend gemacht - selbes Problem.
Was meiner Meinung nach bedeutet das es an einer fehlerhaften Konfiguration liegen müsste..
Allerdings habe ich bei der Reparaturinstalltion auch die APPs und Einstellungen behalten. Da hier wohl der Fehler liegt wurde er somit mit übernommen. Oder habe ich hier einen Denkfehler?
Was ich glaub ich vergessen habe.
Auf dem Server laufen folgende Dienste:
- Active Directory
- DHCP
- DNS
Außerdem ist dort unser Warenwirtschaftsprogram mit installiert und eine Postgre SQL die aus dem Warenwirtschafsprogramm Daten exportiert zwecks Auswertung.
Sollte eine Neuinstallation anstehen würde ich das vermutlich ändern und unser Warenwirtschaftsprogramm auf einem gesonderten Server laufen lassen.
Auf dem Server laufen folgende Dienste:
- Active Directory
- DHCP
- DNS
Außerdem ist dort unser Warenwirtschaftsprogram mit installiert und eine Postgre SQL die aus dem Warenwirtschafsprogramm Daten exportiert zwecks Auswertung.
Sollte eine Neuinstallation anstehen würde ich das vermutlich ändern und unser Warenwirtschaftsprogramm auf einem gesonderten Server laufen lassen.
Zitat von @mwormer:
Was ich glaub ich vergessen habe.
Auf dem Server laufen folgende Dienste:
- Active Directory
- DHCP
- DNS
Außerdem ist dort unser Warenwirtschaftsprogram mit installiert und eine Postgre SQL die aus dem Warenwirtschafsprogramm Daten exportiert zwecks Auswertung.
Sollte eine Neuinstallation anstehen würde ich das vermutlich ändern und unser Warenwirtschaftsprogramm auf einem gesonderten Server laufen lassen.
Was ich glaub ich vergessen habe.
Auf dem Server laufen folgende Dienste:
- Active Directory
- DHCP
- DNS
Außerdem ist dort unser Warenwirtschaftsprogram mit installiert und eine Postgre SQL die aus dem Warenwirtschafsprogramm Daten exportiert zwecks Auswertung.
Sollte eine Neuinstallation anstehen würde ich das vermutlich ändern und unser Warenwirtschaftsprogramm auf einem gesonderten Server laufen lassen.
Ein DC bleibt ein DC ein DC ein DC ... da hat eine Warenwirtschaft nichts drauf zu suchen und schon gar keine Datenbank ...
Einen DC setzt du per Snapshot zurück?? Bist du des wahnsinns 🙆? Stichwort USN-Rollback. Oder ist das der einzige DC?
Vielleicht ein guter Zeitpunkt mal "klar Schiff" zu machen und die Rollen zu trennen.
Einen DC setzt du per Snapshot zurück?? Bist du des wahnsinns 🙆? Stichwort USN-Rollback. Oder ist das der einzige DC?
Ist der einzige DC. Da es komplette Backups gibt und ich mit meinem Latein am Ende bin dachte ich es wäre einen Versuch wert. Ich habe aber bereits geprüft ob Replikationsfehler vorhanden sind. Da ist nix.
Das Warenwirtschaftsprogramm läuft deshalb auf dem DC weil es bei Installation noch keinen anderen Server (egal physisch oder virtuell) gab. Das Warenwirschaftsprogramm selbst bedarf in dem Sinne auch keiner wirklichen Installation. Die Clients greifen lediglich auf eine Netzwerkfreigabe zu und starten dort das Programm. Auf dem Client werden dann lediglich ein paar Dateien in den Temp Ordner kopiert. Das Warenwirtschaftprogramm läuft incl. SQL auf einer eigenen NVME SSD. Der Server auf seiner eigenen.
Das dies trotzdem nicht unbedingt der Idealfall ist, ist mir klar. Da dass Warenwirtschaftsprogramm aber durchaus auch zickig sein kann habe ich bis dato einen Bogen darum gemacht.
Moinsen!
Hier
https://serverfault.com/questions/1115854/windows-update-failed-to-check ...
wird auf Probleme mit dem BITS verwiesen. Läuft der fehlerfrei? Der hat in der Registry auch verschiedene Einstellmöglichkeiten, soweit ich mich erinnere.
Nur so als Hinweis, welche Richtung du noch einschlagen könntest...
VG
Buc
Hier
https://serverfault.com/questions/1115854/windows-update-failed-to-check ...
wird auf Probleme mit dem BITS verwiesen. Läuft der fehlerfrei? Der hat in der Registry auch verschiedene Einstellmöglichkeiten, soweit ich mich erinnere.
Nur so als Hinweis, welche Richtung du noch einschlagen könntest...
VG
Buc
Guten Morgen!
@the-buccaneer
Bits hatte ich schon im Visier und hab auch hier schon geprüft. Bits läuft, bringt keine Fehlermeldungen. In den Abhängigkeiten ist nichts verdächtiges und die Abfrage nach offenen Jobs wird mit 0 ausgegeben.
Werde aber mal die Registry Einträge prüfen / vergleichen. Mal sehen ob ich hier evtl. was finde. Vielen Dank für den Hinweis.
Gruß
Markus
@the-buccaneer
Bits hatte ich schon im Visier und hab auch hier schon geprüft. Bits läuft, bringt keine Fehlermeldungen. In den Abhängigkeiten ist nichts verdächtiges und die Abfrage nach offenen Jobs wird mit 0 ausgegeben.
Werde aber mal die Registry Einträge prüfen / vergleichen. Mal sehen ob ich hier evtl. was finde. Vielen Dank für den Hinweis.
Gruß
Markus
Moin Markus,
bei uns seit 06.08.2024 gleiches Problem bei einem einzigen Server 2022 Datacenter. Auf dem gleichen Host befinden sich noch dutzende andere Server 2022 Datacenter mit gleichen Updatestand / Patchstand - alle ohne Probleme.
Der betroffene Server verweigert einfach mit Fehlercode 80072EFE Updates über Windows-Update und auch Updates für Windows Defender mit dem gleichen Fehlercode.
Installierte Rollen: Exchange Server über Exchange Hybrid License
Installierte Third-Party-Software: Teamviewer, Google Chrome - das wars.
virtualisierter Server
Aktuell hab ich mal die WindowsUpdate.log über das Powershell cmdlet ausgeben lassen und durchforstet, finde dort aber außer dem Errorcode nicht wirklich was brauchbares.
- BITS getestet - scheint ok
- TLSCiphers wurden geprüft (https://learn.microsoft.com/de-de/windows/win32/secauthn/tls-cipher-suit ..)
- Kein Proxy
- hinter einer aktuell Sophos-Firewall (bereits mit ANY-Allow Regel auf den Host getestet, ob die vllt schuld ist)
- per IISCrypto sämtliche TLS-Ciphers und Schannels geradeziehen lassen
- sämtliche URLs auf die der Zugriff laut WindowsUpdate.log fehlschlägt geprüft und im Browser geöffnet - die funktionieren allesamt.
- Backup aus dem Juli eingespielt: ohne Erfolg gleicher Fehler
- Anschließend Backup aus dem JuNi eingespielt: ohne Erfolg gleicher Fehler
- aktuellstes Kumulativupdate manuell aus dem Updatekatalog heruntergeladen und eingespielt
bin aktuell etwas ratlos, wenn du bei deinem Server das Update eingespielt hast - kannst du mal ne Rückmeldung geben ob das bei dir zu einer Besserung geführt hat? Tue mich aktuell etwas schwer damit den Fehler weiter einzugrenzen.
Gruß
bei uns seit 06.08.2024 gleiches Problem bei einem einzigen Server 2022 Datacenter. Auf dem gleichen Host befinden sich noch dutzende andere Server 2022 Datacenter mit gleichen Updatestand / Patchstand - alle ohne Probleme.
Der betroffene Server verweigert einfach mit Fehlercode 80072EFE Updates über Windows-Update und auch Updates für Windows Defender mit dem gleichen Fehlercode.
Installierte Rollen: Exchange Server über Exchange Hybrid License
Installierte Third-Party-Software: Teamviewer, Google Chrome - das wars.
virtualisierter Server
Aktuell hab ich mal die WindowsUpdate.log über das Powershell cmdlet ausgeben lassen und durchforstet, finde dort aber außer dem Errorcode nicht wirklich was brauchbares.
- BITS getestet - scheint ok
- TLSCiphers wurden geprüft (https://learn.microsoft.com/de-de/windows/win32/secauthn/tls-cipher-suit ..)
- Kein Proxy
- hinter einer aktuell Sophos-Firewall (bereits mit ANY-Allow Regel auf den Host getestet, ob die vllt schuld ist)
- per IISCrypto sämtliche TLS-Ciphers und Schannels geradeziehen lassen
- sämtliche URLs auf die der Zugriff laut WindowsUpdate.log fehlschlägt geprüft und im Browser geöffnet - die funktionieren allesamt.
- Backup aus dem Juli eingespielt: ohne Erfolg gleicher Fehler
- Anschließend Backup aus dem JuNi eingespielt: ohne Erfolg gleicher Fehler
- aktuellstes Kumulativupdate manuell aus dem Updatekatalog heruntergeladen und eingespielt
bin aktuell etwas ratlos, wenn du bei deinem Server das Update eingespielt hast - kannst du mal ne Rückmeldung geben ob das bei dir zu einer Besserung geführt hat? Tue mich aktuell etwas schwer damit den Fehler weiter einzugrenzen.
Gruß
Hallo @elpadrino
Ich tendiere immer noch zu der Richtung das mit irgendeinem Zertifkikat was nicht passt.
Ich habe mir nun wieder erneut ein Backup auf eine gesonderte virtuelle Maschine zurückgesichert um weiter probieren zu können. Ich habe in die Richtung auch weiter gegoogelt und bin noch auf zwei Threads gestossen die evtl. in Frage kommen würden.
1. https://learn.microsoft.com/en-us/answers/questions/354230/windows-updat ...
Hier wurde: "Ich habe festgestellt, dass ich Windows Update zum Laufen bringen kann, indem ich „SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\EccCurves“ entferne (konfiguriert durch die Gruppenrichtlinie „Administrative Vorlagen\Netzwerk\SSL-Konfigurationseinstellungen\ECC Curve Order“ und vorgeschrieben durch DoD STIG V-74413 im Windows Client 10-2.1)."
Habe den Eintrag auf dem Testserver vorhin entfernt, muß den Server allerdings noch neu starten. Werde ich später machen da ich noch einen Termin habe.
Mal sehen was dabei rauskommt.
2. https://answers.microsoft.com/en-us/windows/forum/all/windows-update-we- ...
Hier wurde der komplette Stamm aus HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates von einem System bei dem die Updates laufen exportiert und in den nicht funktionierenden importiert.
Allerdings handelt es sich hierbei offensichtlich um ein Windows 11 System. Jedoch scheint es die Vermutung das es an einem fehlerhaften / abgelaufenen Zertifikat liegt zu bestätigen.
Ich habe hier auch noch andere Server 2022 laufen. Werde daher auf dem Test Server mal den Weg beschreiten falls erster Ansatz nicht funktioniert.
Gruß
Markus
Ich tendiere immer noch zu der Richtung das mit irgendeinem Zertifkikat was nicht passt.
Ich habe mir nun wieder erneut ein Backup auf eine gesonderte virtuelle Maschine zurückgesichert um weiter probieren zu können. Ich habe in die Richtung auch weiter gegoogelt und bin noch auf zwei Threads gestossen die evtl. in Frage kommen würden.
1. https://learn.microsoft.com/en-us/answers/questions/354230/windows-updat ...
Hier wurde: "Ich habe festgestellt, dass ich Windows Update zum Laufen bringen kann, indem ich „SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002\EccCurves“ entferne (konfiguriert durch die Gruppenrichtlinie „Administrative Vorlagen\Netzwerk\SSL-Konfigurationseinstellungen\ECC Curve Order“ und vorgeschrieben durch DoD STIG V-74413 im Windows Client 10-2.1)."
Habe den Eintrag auf dem Testserver vorhin entfernt, muß den Server allerdings noch neu starten. Werde ich später machen da ich noch einen Termin habe.
Mal sehen was dabei rauskommt.
2. https://answers.microsoft.com/en-us/windows/forum/all/windows-update-we- ...
Hier wurde der komplette Stamm aus HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates von einem System bei dem die Updates laufen exportiert und in den nicht funktionierenden importiert.
Allerdings handelt es sich hierbei offensichtlich um ein Windows 11 System. Jedoch scheint es die Vermutung das es an einem fehlerhaften / abgelaufenen Zertifikat liegt zu bestätigen.
Ich habe hier auch noch andere Server 2022 laufen. Werde daher auf dem Test Server mal den Weg beschreiten falls erster Ansatz nicht funktioniert.
Gruß
Markus
Hi Markus,
auf die Threads bin ich auch schon gestoßen und habe sie noch auf meiner ToDo, sollte sich in der Zwischenzeit noch was neues finden oder einer der Lösungsansätze für mich funktionieren poste ich hier ein Update
auf die Threads bin ich auch schon gestoßen und habe sie noch auf meiner ToDo, sollte sich in der Zwischenzeit noch was neues finden oder einer der Lösungsansätze für mich funktionieren poste ich hier ein Update
Hallo,
hier kurz die Rückmeldung. Lösung Nummer 1 brachte die Lösung und Updates laufen gerade wieder.
Mal sehen ob das so bleibt. Werde zu einem späteren Zeitpunkt dann den Schlüssel näher angucken und entsprechend anpassen.
Gruß
Markus
hier kurz die Rückmeldung. Lösung Nummer 1 brachte die Lösung und Updates laufen gerade wieder.
Mal sehen ob das so bleibt. Werde zu einem späteren Zeitpunkt dann den Schlüssel näher angucken und entsprechend anpassen.
Gruß
Markus
Hi Markus,
stark, ich hoffe das bleibt so und dir vielen Dank für deine Rückmeldung - ich werde das später heute Abend bei unserer Infrastruktur mal implementieren und schauen ob es den erwünschten Erfolg bringt und das hier auch nochmals zurückmelden
stark, ich hoffe das bleibt so und dir vielen Dank für deine Rückmeldung - ich werde das später heute Abend bei unserer Infrastruktur mal implementieren und schauen ob es den erwünschten Erfolg bringt und das hier auch nochmals zurückmelden
Hallo,
hier auch nochmal meine Rückmeldung - der Hinweis von Markus mit folgendem Beitrag im MS-Forum hat auch in meinem Falle weitergeholfen:
https://learn.microsoft.com/en-us/answers/questions/354230/windows-updat ...
Allerdings war im Falle meines Servers notwendig den Registry-Schlüssel zu erstellen - dieser war in der registry des betroffenen Servers nicht vorhanden.
Gemäß admx.help:
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Typ: REG_MULTI_SZ
Werte:
curve25519
NistP256
NistP384
Anschließend ein Reboot und in meinem Falle war das Problem damit gelöst.
hier auch nochmal meine Rückmeldung - der Hinweis von Markus mit folgendem Beitrag im MS-Forum hat auch in meinem Falle weitergeholfen:
https://learn.microsoft.com/en-us/answers/questions/354230/windows-updat ...
Allerdings war im Falle meines Servers notwendig den Registry-Schlüssel zu erstellen - dieser war in der registry des betroffenen Servers nicht vorhanden.
Gemäß admx.help:
https://admx.help/?Category=Windows_10_2016&Policy=Microsoft.Policie ...
Typ: REG_MULTI_SZ
Werte:
curve25519
NistP256
NistP384
Anschließend ein Reboot und in meinem Falle war das Problem damit gelöst.
Hallo,
auch von mir nochmals die Rückmeldung - @elpadrino war nur schneller
.
Key wieder manuell angelegt, Neustart und Updates laufen wie gewohnt.
Gruß
Markus
auch von mir nochmals die Rückmeldung - @elpadrino war nur schneller
.Key wieder manuell angelegt, Neustart und Updates laufen wie gewohnt.
Gruß
Markus
1
