Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, September 13, 2019 5:04 PM | 8 votes
It appears that as of today: 09-13-2019, the URL specified in:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata\DeviceMetaDataServiceURL:
http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409
is redirecting to a site that has a 'bad' certificate attached to it.
The above URL redirects to:
https://devicemetadataservice.trafficmanager.net/dms/metadata.svc
The certificate attached to this URL has name mismatch.
This seems (perhaps?) to be causing ALOT of issues/delays with device staging (Device Setup in Progress....for PnP devices)
Can anybody else confirm this and advise?
Attached is the Certificate warning, and then (upon continuing anyhow, the service is simply not available!):
All replies (43)
Saturday, September 14, 2019 12:27 AM | 2 votes
We have been experiencing issues with this all day today as well.
We originally suspected an issue on one of our firewalls, but we have been working on this tirelessly all day and have yet to get it working. Once we hunted down the URLs that the Device Metadata service was trying to access by poring over our firewall logs (a bit of information which should be easily-found public knowledge in my opinion) it led us to your post, and now it is becoming quite clear that the cause for this issue is most likely on Microsoft's end.
For those who might be searching for answers, here are a series of URLs all of which appear to point to the same resource on Microsoft's end or which are otherwise related in some way (at least at this very moment):
http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409
https://devicemetadataservice.trafficmanager.net/dms/metadata.svc
https://dmd.metaservices.microsoft.com/dms/metadata.svc
https://waws-prod-dm1-117.cloudapp.net/dms/metadata.svc
40.113.236.45
Saturday, September 14, 2019 12:53 AM | 2 votes
Hi Ksuvi, Glad I am not the only one here experiencing the issue. I too suspected a firewall issue initially. Then, I tried on 3 different networks, all with the same result. In fact, just doing a fresh install of W10 (tested 1809 and 1903) will show ‘Device Setup in Progress’ for the baked in ‘Microsoft Print to PDF’’ device. Essentially any device that typically fetches Metadata at the WMIS site will delay until a reboot. And even then, the Metadata is not retrieved. Caused havoc today for me in a multitude of ways: -Clients connecting to printer shares (attached printer would NOT show up client side) -InTune Powershell scripts failing to run (possibly related) The certificate is a valid wildcard certificate for Azure services it seems, but it doesn’t cover the site/domain where the WMIS service is (supposedly) hosted. I’m chalking it up to it being Friday the 13th AND a full moon. (Apparently that doesn’t happen again until the year 2049) :) Let’s hope that this gets sorted sooner than later. LMK if you see success and I will do the same. -Phil
Saturday, September 14, 2019 1:19 AM | 3 votes
Here is some additional information, in case it helps. We found an error in Event Viewer which appears to be related to this issue. Here are the details from an example event:
Log Name: Microsoft-Windows-DeviceSetupManager/Admin
Source: Microsoft-Windows-DeviceSetupManager
Date: 9/13/2019 8:45:30 PM
Event ID: 131
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: *****.*****.***
Description:
Metadata staging failed, result=0x80070057 for container '{2C0B3550-385C-5A97-96F4-2C3D988D4B52}'
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-DeviceSetupManager" Guid="{FCBB06BB-6A2A-46E3-ABAA-246CB4E508B2}" />
<EventID>131</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x4000000000000000</Keywords>
<TimeCreated SystemTime="2019-09-14T00:45:30.208357500Z" />
<EventRecordID>2024</EventRecordID>
<Correlation />
<Execution ProcessID="4332" ThreadID="5240" />
<Channel>Microsoft-Windows-DeviceSetupManager/Admin</Channel>
<Computer>*****.*****.***</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="Prop_ContainerId">{2C0B3550-385C-5A97-96F4-2C3D988D4B52}</Data>
<Data Name="HRESULT">2147942487</Data>
</EventData>
</Event>
Please note that this event was found in Applications and Services Logs -> Microsoft -> Windows -> DeviceSetupManager -> Admin. Here is a screenshot:
Saturday, September 14, 2019 1:55 AM | 3 votes
More info:
Something certainly changed recently with this service. A quick peek deeper into the contents of this site shows modifications made (maybe?) on 9-12:
Monday, September 16, 2019 5:32 AM | 2 votes
My apologies for the late reply.
We have found and implemented a temporary workaround for these issues until Microsoft is able to fix the root cause on their end. The workaround which worked best for us was to create a Group Policy which prevents device metadata retrieval from the internet by enabling the aptly-named "Prevent device metadata retrieval from the internet" policy, which can be found under the following path:
Computer Configuration -> Policies -> Administrative Templates -> System -> Device Installation
The only downside we have found to this workaround so far is that it seems to cause an inability to locally manage any queue which was added from the list of published printers at the top of the Printers & scanners window. After adding a published printer from the initial list which shows up after clicking the "Add a printer or scanner" plus sign we have found that the only button available on the resulting local copy of the queue is the "Remove Device" button. The "Open Queue" and "Manage" buttons are conspicuously missing. This can be avoided by adding the same queue via UNC path, browsing the directory, or via an installation script of some sort, and it also appears to be resolved after a reboot.
Monday, September 16, 2019 2:21 PM | 3 votes
In the interest of trying to get as many eyes on this issue as possible, I have submitted feedback to Microsoft regarding this issue. The feedback I submitted can be found here:
Also, in case it helps, I uncovered a few more details regarding the SSL certificate error which seems to be the root cause of this issue. Specifically, I found that the certificate in use on the site which hosts the metadata information is only valid for the following names: *.azurewebsites.net, *.scm.azurewebsites.net, *.sso.azurewebsites.net, *.azure-mobile.net, and *.scm.azure-mobile.net.
Clearly none of these domain wildcards applies to any of the aforementioned URLs which are referenced and accessed by the appropriate services in Windows 10.
Monday, September 16, 2019 2:55 PM | 1 vote
Hi Ksuvi,
I also reported this issue to Microsoft over the weekend via several different avenues.
I too wound up using the workaround to prevent devices from gathering metadata from WMIS.
As FYI, the GPO changes the following DWORD from 0 to 1 located here: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata\PreventDeviceMetadataFromNetwork
I also found that I could not remove any printer connections to shared queue(s) until the change was made.
And yes, the certificate's SAN does not appear to cover the domain being queried.
Monday, September 16, 2019 6:14 PM | 2 votes
My organization has also seen this starting on 09/13/2019. I have added feedback to MS as well. Does anyone know if MS is actually working on this?
Tuesday, September 17, 2019 12:47 AM | 1 vote
Hi SysAdm79, Certainly hope so, but as of now, a big mystery. I am a bit surprised this hasn’t been more ‘upfront’ considering impact (printing aside). Granted, fatter fish to fry regrading Sept cumulative update, but PnP consistency/reliability is somewhat of a surprise here IMHO.
Tuesday, September 17, 2019 1:44 AM | 1 vote
**Maybe** Something is being addressed here. No longer am I seeing certificate error(s)...rather, indefinite stalling....
Tuesday, September 17, 2019 3:28 AM | 2 votes
I believe the certificate error is a red herring.
I saw the traffic in fiddler, and for whatever reason, the Device Setup Manager service, either gets redirected to http through serverside trickery, or it otherwise intercepts the redirect and contacts it through http.
It posts to the service with data containing your OS build, language, as well as some details on the device itself, in my testing it always gets a 503 response, indicating a server error.
Tuesday, September 17, 2019 9:01 AM | 1 vote
Good information Thomas. Whatever the underlying cause is, hopefully it will be repaired ‘soon’.
Tuesday, September 17, 2019 12:33 PM | 1 vote
Update:
For me, this issue looks now to be resolved. Can other's please confirm?
Tuesday, September 17, 2019 12:54 PM
I am able to add printers and immediately see them again in Devices and Printers.
Tuesday, September 17, 2019 4:23 PM | 1 vote
I can confirm that the issue appears to be resolved for us as well. With the device installation settings enabled, we are able to add and manage print queues as normal again.
Interestingly, as Phil mentioned last night, I am now stalling out when trying to visit the web resource manually. Whether or not the SSL error was a red herring as Thomas suggested, something has definitely changed on their end since we are no longer receiving these errors when browsing to the repository manually.
I have not yet received any response from Microsoft on the feedback I left with their Windows 10 team. Has anyone else heard anything official from anyone at Microsoft?
Tuesday, September 17, 2019 6:03 PM
Yeah, I think they just disabled https since it isn't used. But other than that I can only confirm that it seems to be working fine now.
Tuesday, September 17, 2019 6:39 PM | 1 vote
I'm currently in the process of whitelisting permissible traffic through our egress firewall, and came across the same issue, as in the past, we never saw outbound traffic being requested to devicemetadataservice.trafficmanager.net until last week.
Can someone please kindly confirm whether the redirection initiated from http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409 (URL present in Windows registry) to devicemetadataservice.trafficmanager.net is a permanent update to this traffic flow?
Would we now need to whitelist devicemetadataservice.trafficmanager.net on our egress firewalls going forward?
Thanks!
Tuesday, September 17, 2019 7:31 PM | 1 vote
Hi Angel,
IMHO, I don't think we could every consider it 'permanent' per-se, as this issue has indeed crept up in the past (going back years if you dig/search enough), for one reason or another. Maybe a better approach would be to examine the traffic payload/content type (if even available/defined) and allow that instead.
Tuesday, September 17, 2019 8:08 PM
Can someone please kindly confirm whether the redirection initiated from http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409 (URL present in Windows registry) to devicemetadataservice.trafficmanager.net is a permanent update to this traffic flow?
Would we now need to whitelist devicemetadataservice.trafficmanager.net on our egress firewalls going forward?
Thanks!
Angel - While I am not comfortable making any direct suggestions regarding what you should or should not whitelist on your firewalls, please note that http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409 merely redirects all traffic to devicemetadataservice.trafficmanager.net.
Furthermore, both dmd.metaservices.microsoft.com and devicemetadataservice.trafficmanager.net are both CNAME records in DNS - neither of them point directly at the resource Microsoft is wishing to publish. Rather, Microsoft uses these CNAME records to point to one of a multitude of cloudapp.net websites.
For example, devicemetadataservice.trafficmanager.net is currently resolving to dms-prod-eas-su1.cloudapp.net. This is different from yesterday, which in turn was different from last Friday.
Again, I am not comfortable suggesting whether or not you should whitelist any or all of these URLs - I merely wanted you to have as much factual information as possible to try and help you make your own determination on that issue.
Wednesday, September 18, 2019 6:45 PM | 1 vote
Thank you Phil and Ksuvi for your quick replies.
Ksuvi made a good point concerning public DNS, and the utilization of CNAME records that I overlooked.
I think I understand the rationale behind the recent change by Microsoft:
- Microsoft likely wanted to provide geo-failover or performance-based routing capabilities to the web endpoints hosting device metadata service content.
- *.trafficmanager.net corresponds to the domain Microsoft Azure uses for Azure Traffic Manager (ATM) profiles which is a global DNS load balancer service used to direct clients to different endpoints without updating public DNS (e.g. failover, performance based routing, etc.).
- Microsoft likely incorporated the redirect from the go.microsoft.com URL to the trafficmanager.net subdomain so that Microsoft can change the underlying endpoints that host the actual device metadata service content at their discretion (e.g. *.cloudapp.net endpoints) without requiring updates to public DNS.
- They could simply update their ATM profile endpoint, let the client DNS TTL expire, and the client would get redirected to the appropriate web endpoint via the appropriate CNAME returned from ATM.
I don't work for Microsoft, and so I am only speculating here, but the above assumptions would make sense from a traffic flow/DNS resolution perspective.
Anyways, I have the information I need now, and I thank you once again for your valuable insight into this.
Thursday, October 10, 2019 4:57 PM | 4 votes
FYI, we are starting to see evidence of this issue rearing its ugly head again. Half of our organization is currently being directed to dms-vmss-prod-neu-lb.northeurope.cloudapp.azure.com for these services (which is very odd in and of itself since we are based entirely in the continental USA), and this half of our organization is having the same exact print queue issues as the last time (see history above).
Same as before, we can sidestep this issue by setting the Device installation settings to "No" so that Windows 10 does not call out to this site for the "manufacturers' apps and custom icons" which it so desperately wants to retrieve.
This settings page can be accessed by opening the legacy Control Panel and searching for "device installation". Please see my earlier post from September 16th 2019 for instructions on how to accomplish this via Group Policy.
So, the real question here is: How many times are we going to see this problem negatively affect our organizations before Microsoft takes notice and either fixes the root cause or at least explains to us what is going on and why this keeps occurring?
Thursday, October 10, 2019 6:57 PM
I have the same problem, but on my Windows server 2016 and i cant install any features. This problema was causing a big problem for us.
Monday, November 4, 2019 1:56 PM | 1 vote
And yet again, 11-4-2019, we see that (perhaps?) the MetaDataServiceURL:
http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409
is directing to 'broken' service:
Redirecting to:
http://dmd.metaservices.microsoft.com/metadata.svc
Which then comes back with:
'The service is unavailable'
Monday, November 4, 2019 8:07 PM | 1 vote
I confirm, as of this morning I am seeing the same redirection as Phil mentions.
11-4-2019
Further,
changing the registry entry
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata\PreventDeviceMetadataFromNetwork
from 0 to 1, and a quick reboot and all three of our shared Xerox GPD printers showed up immediately in both Control Panel | Devices and Printers and Printers & Scanners modern app.
"Time is an illusion, Lunchtime, doubly so..." - Ford Prefect
Tuesday, November 5, 2019 4:07 PM
Our organization is also having this issue. I created a Group Policy as listed above: Computer Configuration -> **Policies **-> Administrative Templates -> **System **-> Device Installation - Prevent device metadata retrieval from the Internet - Enable
After applying this policy, the registry setting from above did not change to 1. Here is the quote from above: As FYI, the GPO changes the following DWORD from 0 to 1 located here: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata\PreventDeviceMetadataFromNetwork
The group policy setting did change the Device Installation Settings option above to No (your device might not work as expected) so the policy seems to be working but we were looking at the registry key to see if the change took effect and that was throwing us off.
Wednesday, November 6, 2019 6:46 PM | 2 votes
FYI, we are starting to see evidence of this issue rearing its ugly head again. Half of our organization is currently being directed to dms-vmss-prod-neu-lb.northeurope.cloudapp.azure.com for these services (which is very odd in and of itself since we are based entirely in the continental USA), and this half of our organization is having the same exact print queue issues as the last time (see history above).
Same as before, we can sidestep this issue by setting the Device installation settings to "No" so that Windows 10 does not call out to this site for the "manufacturers' apps and custom icons" which it so desperately wants to retrieve.
This settings page can be accessed by opening the legacy Control Panel and searching for "device installation". Please see my earlier post from September 16th 2019 for instructions on how to accomplish this via Group Policy.
So, the real question here is: How many times are we going to see this problem negatively affect our organizations before Microsoft takes notice and either fixes the root cause or at least explains to us what is going on and why this keeps occurring?
Exactly. The fact that this continues to occur points to a larger QC issue IMHO.
Wednesday, November 6, 2019 8:45 PM
Thank you for your report. We have identified the configuration change which resulted in delays and/or metadata not being received. This has been rectified. Please post again if you continue to see issues.
Thank you,
James
Thursday, November 7, 2019 8:26 AM
Hi.
the problem not fix yet. got same problem.
Thursday, November 7, 2019 12:11 PM | 1 vote
same issue here - 11th November 2019
Thursday, November 7, 2019 2:02 PM
We are still experiencing an issue in our organization as well.
Thursday, November 7, 2019 3:22 PM
Issue is not resolved. 11-07-2019 9:23 a.m., CST.
Thursday, November 7, 2019 3:34 PM
Still experiencing it.
Friday, November 8, 2019 1:47 PM
the problem still exists - and beside the printers all USB attached devices are shown as unidentified devices in devices and printers
Tuesday, November 12, 2019 7:10 PM | 5 votes
James -- There have been multiple reports of this issue affecting organizations since your all-clear message on the 6th. Can you give us an update on where we stand on this? It has been a recurring issue for many of us for almost two months now, and there is nothing any of us can do to permanently fix it short of implementing the aforementioned workarounds indefinitely.
Is disabling this feature, which Microsoft enables by default, considered to be the official "fix" for this issue?
Wednesday, November 13, 2019 5:49 PM
Same for my company. Issue still persists all printers are in the printmanagement dialog but not in control panel or devices and printers
Thursday, November 14, 2019 12:45 PM
Are the ANY updates on this issue? Is it worth opening a call with Microsoft about it?
Friday, November 15, 2019 9:39 PM
I work at an MSP and saw this issue (printers not showing up in Devices and Printers, but showing up in the print dialog) recently, and so far have been able to be resolved by setting PreventDeviceMetadataFromNetwork to 1 as another user noted.
Today I found a case where this fix did not work, instead the printer is showing as Unspecified in Devices and Printers.
Is there an update/response from Microsoft to this yet?
Thursday, November 21, 2019 9:02 PM
Has anyone tried removing the URL all together? I did this and it seems to be working for me, but I don't know what other effects that may have down the road.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Metadata\DeviceMetaDataServiceURL - delete entire value.
Monday, November 25, 2019 1:21 PM
Hi James,
This issue appears to have returned. Please can it be investigated?
Thanks
Reece
Tuesday, November 26, 2019 9:46 AM
I can confirm, deleting the entire value resolves the issues for now......
Tuesday, November 26, 2019 5:06 PM
Did you need to restart after deleting the value? Deleting the value didn't work in my case (still showing a good printer as "Unspecified" but I didn't restart.
Monday, December 2, 2019 4:16 PM
I always like to make sure there is a clean reboot after messing around in the registry.
Saturday, March 14, 2020 2:27 PM
Any updates on this? It's been a while and metadata still not downloading for me.