none
DeviceMetadataServiceURL: http://go.microsoft.com/fwlink/?LinkID=252669&clcid=0x409 RRS feed

  • السؤال

  • 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!):



    • تم التحرير بواسطة Phil Shipley 14/محرم/1441 05:33 م More Errors SHown
    14/محرم/1441 05:04 م

جميع الردود

  • 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

    • تم التحرير بواسطة Ksuvi Khor 15/محرم/1441 12:39 ص Adding additional information
    15/محرم/1441 12:27 ص
  • 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
    15/محرم/1441 12:53 ص
  • 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:


    • تم التحرير بواسطة Ksuvi Khor 15/محرم/1441 01:21 ص Removed private data
    15/محرم/1441 01:19 ص
  • 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:

    15/محرم/1441 01:55 ص
  • 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.

    17/محرم/1441 05:32 ص
  • 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:

    https://aka.ms/AA62vmp

    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.
    17/محرم/1441 02:21 م
  • 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.



    • تم التحرير بواسطة Phil Shipley 18/محرم/1441 12:49 ص
    17/محرم/1441 02:55 م
  • 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?
    17/محرم/1441 06:14 م
  • 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.
    18/محرم/1441 12:47 ص
  • **Maybe** Something is being addressed here. No longer am I seeing certificate error(s)...rather, indefinite stalling....
    18/محرم/1441 01:44 ص
  • 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.

    18/محرم/1441 03:28 ص
  • Good information Thomas. Whatever the underlying cause is, hopefully it will be repaired ‘soon’.
    18/محرم/1441 09:01 ص
  • Update:

    For me, this issue looks now to be resolved. Can other's please confirm?

    18/محرم/1441 12:33 م
  • I am able to add printers and immediately see them again in Devices and Printers.
    18/محرم/1441 12:54 م
  • 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?
    18/محرم/1441 04:23 م
  • 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.

    18/محرم/1441 06:03 م
  • 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!

    • تم التحرير بواسطة Angel97 18/محرم/1441 06:40 م
    18/محرم/1441 06:39 م
  • 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.

    18/محرم/1441 07:31 م
  • 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.
    18/محرم/1441 08:08 م
  • 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.  


    • تم التحرير بواسطة Angel97 19/محرم/1441 06:45 م
    19/محرم/1441 06:45 م
  • 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?
    11/صفر/1441 04:57 م
  • 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.
    11/صفر/1441 06:57 م
  • 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'

    07/ربيع الأول/1441 01:56 م
  • 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


    07/ربيع الأول/1441 08:07 م
  • 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.

    08/ربيع الأول/1441 04:07 م
  • 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.
    09/ربيع الأول/1441 06:46 م
  • 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

    09/ربيع الأول/1441 08:45 م
  • Hi.

    the problem not fix yet. got same problem.

    10/ربيع الأول/1441 08:26 ص
  • same issue here - 11th November 2019
    10/ربيع الأول/1441 12:11 م
  • We are still experiencing an issue in our organization as well.
    10/ربيع الأول/1441 02:02 م
  • Issue is not resolved.  11-07-2019 9:23 a.m., CST.
    • تم التحرير بواسطة Ran Harris 10/ربيع الأول/1441 03:23 م
    10/ربيع الأول/1441 03:22 م
  • Still experiencing it.
    10/ربيع الأول/1441 03:34 م
  • the problem still exists - and beside the printers all USB attached devices are shown as unidentified devices in devices and printers
    11/ربيع الأول/1441 01:47 م
  • 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?

    15/ربيع الأول/1441 07:10 م
  • Same for my company. Issue still persists all printers are in the printmanagement dialog but not in control panel or devices and printers
    16/ربيع الأول/1441 05:49 م
  • Are the ANY updates on this issue?   Is it worth opening a call with Microsoft about it?
    17/ربيع الأول/1441 12:45 م
  • 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?


    • تم التحرير بواسطة mister_dj 18/ربيع الأول/1441 09:46 م
    18/ربيع الأول/1441 09:39 م