wie es scheint, behebt MS da wohl nix mehr. Selbst auf Windows 11 24H2 tauchen diese Fehler auf bei jedem PC-Start. So ein murx.

Merkwürdigerweise hat der Dell AiO meiner Frau diese Fehlereinträge nicht, obwohl sie am selben Router hängt usw. Registry-Einträge zu diesem Thema sind zu meiner Kiste identisch.

Da wird einem wohl nur das "Ignorieren" bleiben oder eben diese Dinger zu deaktivieren, was aber scheinbar ja nicht zielführend ist.

In Windows 11 habe ich das auch wieder deaktiviert. Bezweifele da im Moment, dass das in Windows 11 noch benötigt wird. Alle Geräte funktionieren auch ohne diese Metadaten einwandfrei und die Einstellungen passen auch.

Bei Windows 10 klappt das ja mit der anderen URL, aber bei Windows 11 nicht.

Meist in englischsprachigen Foren findet man aktuelle Posts zu dem Thema.
Ich habe leider auch keine Lösung, aber zumindest kann ich diejenigen beruhigen, die diesen Fehler auf Ihrem System haben. Es liegt nicht an Eurem Computer. Das Thema hat bald Geburtstag.

Man kann sich jedoch hier im MS Forum anschließen und so versuchen den Druck auf MS zu forcieren. Je öfter User das machen, je höher die Wahrscheinlichkeit das die IT'ler bei MS aufwachen oder mal den Kaffeebecher oder Ihren Hamburger zur Seite stellen.

https://answers.microsoft.com/en-us/windows/forum/all/why-am-i-seeing-lots-of-event-id-131/48e86fda-03c6-4292-9dbb-88bd9218ae87?page=3

Trotzem vielen Dank für diesen Beitrag. MS hat es anscheinden nicht nötig darüber zu informieren. So bleibt man wenigstens auf Stand.

In Windows 10 funktioniert es, in Windows 11 nicht. Allerdings frage ich mich, ob das in Windows 11 überhaupt noch nötig ist, zumal es ja "Systemsteuerung/Geräte und Drucker" gar nicht mehr gibt.

Die Verbindung mit den Windows Metadata and Internet Services (WMIS) konnte nicht hergestellt werden. 

Hmm. Scheine eine Meldung nun durch eine andere getauscht zu haben?

[code]Die Verbindung mit den Windows Metadata and Internet Services (WMIS) konnte nicht hergestellt werden. [/code]
DeviceSetupManager Event 201

Das entspricht im Ergebnis dem gesetzten Regkey im ersten Beitrag und ist genau nicht das Ziel gewesen, sondern der Zustand von dem ich weg wollte ;)

Systemsteuerung > Alle Systemsteuerungselemente ==> (oben rechts "G" eingeben)

Unter Geräte und Drucker:
[i]Geräteinstallationseinstellungen ändern[/i]

"[i]Möchten Sie für Ihre Geräte verfügbare Hersteller-Apps und benutzerdefinierte Symbole automatisch herunterladen[/i]?
[b]Nein[/b] auswählen

Dann ist der Spuk vorbei

Merci.
Stimmt. Ist so etwas eleganter als über die hosts zu gehen.
Mal sehen, wann die URL in Registry wieder von M$ angefasst wird. Scheint mir aber recht stabil zu sein über die Jahre.

DeviceMetadataServiceURL="https://devicemetadataservice.prod.trafficmanager.net/dms/metadata.svc?LinkID=2257403&clcid=0x409"

In der Registry, wo Du das deaktiviert hast, die URL ersetzen.

[code]DeviceMetadataServiceURL="https://devicemetadataservice.prod.trafficmanager.net/dms/metadata.svc?LinkID=2257403&clcid=0x409"[/code]

Die funktioniert so weit. Bis Microsoft da wieder etwas ändert.

Ich weiß bloß nicht genau, ob man da clcid=0x409 (US) oder clcid=0x407 (DE) nehmen muss. Gehen tut beides.

PS:
die IP gehört genau wie
52.138.148.159
52.164.240.59
52.178.147.240
korrekterweise zu dmd.metaservices.microsoft.com und devicemetadataservice.trafficmanager.net ist hier eigentlich nur ein CNAME.
Interessanterweise geht es bei mir aber ohne den Loadbalancer FQDN Eintrag nicht ohne die 0x80070490 Fehlermeldungen. :?

Moinsen,

[b][color=#FF0000]Problem und provisorischer workaround[/color][/b]
auf meinen Windows Maschinen habe ich seit längerem den nervigen Fehler, dass das Metadata Staging (Windows Metadata and Internet Services (WMIS)) im Eventlog permanent fehlschlägt (0x80070490). Das Log wird geradezu Performance beinträchtigend geflutet, so dass ich notgedrungen das Metadata staging in der Registry bislang deaktiviert habe (s.u.). Ist ein schlechter workaround, aber definitiv keine gute Dauerlösung.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata]
"PreventDeviceMetadataFromNetwork"=dword:00000001

[b][color=#FF8000]Hintergrundbeschreibung[/color][/b]:
Laut Günter Born [url]https://www.borncity.com/blog/2024/02/19/microsoft-will-sein-metadaten-server-problem-mit-den-februar-2024-updates-behoben-haben/[/url] bzw. nach bleepingcomputer [url]https://www.bleepingcomputer.com/news/microsoft/microsoft-says-it-fixed-a-windows-metadata-server-issue-thats-still-broken/[/url] hat M$ nach eigener Aussage das Problem endgültig mit dem Februar Patchday 2024 gefixt, was aber eben nicht der Fall ist, wie bleeping es auch ausführt.

[b][color=#FF8000]Das serverseitige Problem in der M$ Cloud[/color][/b]:
Die Ursache liegt anbieterseitig in einer fehlenden IP-Adresszuordnung für den FQDN [b]devicemetadataservice.trafficmanager.net[/b]

[b][color=#00BF00]TLDR: der clientseitige workaround[/color][/b]:
Nicht ganz optimal, aber im Grunde reicht es aus solange bis M$ mal aufwacht, in der lokalen hosts-Datei oder ggf. auf dem lokalen DNS eine Zuordnung von devicemetadataservice.trafficmanager.net zu einer der passenden M$ Azure Loadbalancer IP für den WMIS backend Service vorzunehmen.

Ich bin bei der Suche auf folgende funktionierende IPv4 gestoßen für Nordamerika: [b]52.138.148.89[/b]
Ferner bin ich auch auf 2 IPv4-Adressen von M$ in Honkong gestoßen, habe diese aber für den Moment wieder verworfen.
Folgenden Zeile in der hosts ergänzen:
[b]52.138.148.89 devicemetadataservice.trafficmanager.net[/b]

Vielleicht hilft dies ja dem einen oder anderen oder jemand kennt die IPv4/v6 für den WMIS Balancer aus EMEA?