Win10/Win11: Fehler beim Staging von Metadaten. Fehler 0x80070490 =>funktionierender workaround ohne Deaktivierung

[Maghook]

Moinsen,

Problem und provisorischer workaround
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

Hintergrundbeschreibung:
Laut Günter Born https://www.borncity.com/blog/2024/02/1 ... ben-haben/ bzw. nach bleepingcomputer https://www.bleepingcomputer.com/news/m ... ll-broken/ 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.

Das serverseitige Problem in der M$ Cloud:
Die Ursache liegt anbieterseitig in einer fehlenden IP-Adresszuordnung für den FQDN devicemetadataservice.trafficmanager.net

TLDR: der clientseitige workaround:
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: 52.138.148.89
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:
52.138.148.89 devicemetadataservice.trafficmanager.net

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

[Tante Google]

[Maghook]

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.

[DK2000]

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

Code: Alles auswählen

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

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.

[Maghook]

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.

[Gastronom]

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

Unter Geräte und Drucker:
Geräteinstallationseinstellungen ändern

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

Dann ist der Spuk vorbei

[Maghook]

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

[Maghook]

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

Code: Alles auswählen

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

DeviceSetupManager Event 201

[DK2000]

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.

[Urmel07]

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/win ... e87?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.

[DK2000]

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.

[inge70]

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.