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

  • Question

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



    • Edited by Phil Shipley Friday, September 13, 2019 5:33 PM More Errors SHown
    Friday, September 13, 2019 5:04 PM

All replies

  • 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

    • Edited by Ksuvi Khor Saturday, September 14, 2019 12:39 AM Adding additional information
    Saturday, September 14, 2019 12:27 AM
  • 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 12:53 AM
  • 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:


    • Edited by Ksuvi Khor Saturday, September 14, 2019 1:21 AM Removed private data
    Saturday, September 14, 2019 1:19 AM
  • 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:

    Saturday, September 14, 2019 1:55 AM
  • 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 5:32 AM
  • 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.
    Monday, September 16, 2019 2:21 PM
  • 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.



    • Edited by Phil Shipley Tuesday, September 17, 2019 12:49 AM
    Monday, September 16, 2019 2:55 PM
  • 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?
    Monday, September 16, 2019 6:14 PM
  • 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 12:47 AM
  • **Maybe** Something is being addressed here. No longer am I seeing certificate error(s)...rather, indefinite stalling....
    Tuesday, September 17, 2019 1:44 AM
  • 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 3:28 AM
  • Good information Thomas. Whatever the underlying cause is, hopefully it will be repaired ‘soon’.
    Tuesday, September 17, 2019 9:01 AM
  • Update:

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

    Tuesday, September 17, 2019 12:33 PM
  • I am able to add printers and immediately see them again in Devices and Printers.
    Tuesday, September 17, 2019 12:54 PM
  • 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 4:23 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:03 PM
  • 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!

    • Edited by Angel97 Tuesday, September 17, 2019 6:40 PM
    Tuesday, September 17, 2019 6:39 PM
  • 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 7:31 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.
    Tuesday, September 17, 2019 8:08 PM
  • 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.  


    • Edited by Angel97 Wednesday, September 18, 2019 6:45 PM
    Wednesday, September 18, 2019 6:45 PM
  • 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 4: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.
    Thursday, October 10, 2019 6:57 PM