{"id":8375,"date":"2017-01-09T09:00:42","date_gmt":"2017-01-09T17:00:42","guid":{"rendered":"https:\/\/blogs.technet.microsoft.com\/windowsserver\/?p=8375"},"modified":"2024-03-07T16:45:32","modified_gmt":"2024-03-08T00:45:32","slug":"why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online","status":"publish","type":"post","link":"https:\/\/cm-edgetun.pages.dev\/en-us\/windows-server\/blog\/2017\/01\/09\/why-wsus-and-sccm-managed-clients-are-reaching-out-to-microsoft-online\/","title":{"rendered":"Why WSUS and SCCM managed clients are reaching out to Microsoft Online"},"content":{"rendered":"

This post was authored by Shadab Rasheed, Technical Advisor, Windows Devices & Deployment\u00a0<\/em><\/p>\n

Of late, several customers have reached out to my team asking why their Windows 10 1511 and 1607 clients, which are managed by WSUS or SCCM are going online to Microsoft update to download updates. Not only the clients are\u00a0reaching out to external Microsoft URL, outside of the internal update endpoint, but they are downloading a significant amount of data from the Microsoft content delivery gateway.<\/p>\n

So, what\u2019s exactly going on here?<\/h2>\n

There are essentially two different behaviors that is being experienced here. It is important that we understand and identify them instead of brushing them under the same stroke. I will try to add some important details to help you identify them.<\/p>\n

OS impact: 1511 & 1607<\/h2>\n

Scenario 1<\/h3>\n

You have WSUS or SCCM to manage Windows update in the environment, but you observe that Windows 10 machines are going online to url – tlu.dl.delivery.mp.microsoft.com and are downloading updates.<\/p>\n

Here the concern could be two situations:<\/p>\n

A. Why is it reaching out to Microsoft url= tlu.dl.delivery.mp.microsoft.com despite WSUS endpoints provided through GPO?<\/p>\n

B. It is consuming a significant bandwidth towards this url.<\/p>\n

While both these scenarios are interconnected, if you are observing Scenario A then you may also report Scenario B.<\/p>\n

What is happening here?<\/h2>\n

Scenario A + B<\/h3>\n

Delivery optimization (DO) was introduced in TH2, but it was only used for downloads of large content. DO in 1511 build is used in about 50% of the downloads, and when DO isn\u2019t used the download switches to BITS. From 1607 build onwards, it is the default downloader for Windows Update and Windows Store content.<\/p>\n

While system specific updates will still reach out to WSUS or SCCM, or against Microsoft Update if the machine is configured to use Microsoft Update instead of Windows Update, the Store App updates are not yet cached or supported on WSUS or SCCM yet.<\/p>\n

So actually, the machine is going out to url- tlu.dl.delivery.mp.microsoft.com only to update the Windows Store Apps. There is no set timeline for the release of the store App updates, unlike patch Tuesdays. Each app update is released almost weekly and could be on different days.<\/p>\n

So, what you are is experiencing is by-design behavior.<\/p>\n

Scenario B<\/h3>\n

One of the main reasons why you may be experiencing a significant bandwidth consumption is because of the Proxy configuration. We recommend that you refer to https:\/\/support.microsoft.com\/en-us\/kb\/3175743<\/a>. The requirement is that your proxy server should support byte-range requests.<\/p>\n

If it does, then you need to apply a rule to permit HTTP RANGE requests for the following URLs:<\/p>\n

*.download.windowsupdate.com<\/p>\n

*.au.windowsupdate.com<\/p>\n

*.tlu.dl.delivery.mp.microsoft.com<\/p>\n

How will it help?<\/h2>\n

Most of the customers may already have included the first two URLs but may not be aware of the 3rd URL, which is the CDN for Store App updates. In the absence byte-range inclusion, the store app update is not downloaded as delta and instead the entire payload is downloaded which, needless to say, it will be bigger in size. Thus, consuming more bandwidth when downloading the store app updates.<\/p>\n

We also recommend you to apply GPO for DO to use over LAN-in which case the clients will establish peer to peer connection and download already cached content.<\/p>\n

Learn more about Windows 10, Delivery Optimization, and WSUS<\/a>.<\/p>\n

Learn more about policy updated for DO in TH2<\/a> and RS1<\/a>.<\/p>\n

As you figured out we didn\u2019t recommend disabling the Store itself to prevent the store app updates download since it breaks the entire store and makes it inaccessible for the clients. Also, if a machine has already queued for an app update, it doesn\u2019t cancel the existing download. However, it may help in mitigating new clients not reaching out for Store app updates. Thus, we don\u2019t recommend it.<\/p>\n

The app update has to be cancelled from the Store itself or using wsreset.exe from Run.<\/p>\n

Refer to the Windows Update logs after you have decoded the etl. Look for following entries:<\/p>\n

11\/17\/2016 08:48:39.74543 AM 6440  6536  downloadjob_cpp183             [ComApi] * START *   Download ClientId = WSAutoUpdate\r\n\r\n11\/17\/2016 08:48:39.74543 AM 6440  6536  downloadjob_cpp186             [ComApi] Flags: 0X302; Download priority: 3; Network Cost Policy: 0\r\n\r\n11\/17\/2016 08:48:41.46862 AM 816   7568  downloadmanager_cpp19049       [DownloadManager] BITS job {EAEFD6D9-9143-42CD-8CE7-D126152AD743} hit a transient error, updateId = {FF39AB78-CBBF-4F6F-84F5-FCE88A67260B}.1, error = 0x80200056\r\n\r\n11\/17\/2016 08:48:41.46882 AM 816   7568  downloadmanager_cpp19059       [DownloadManager] File: https:\/\/2.tlu.dl.delivery.mp.microsoft.com\/filestreamingservice\/files\/3f93f3a8-59bb-497c-96d6-fceab9e53b99?P1=1479373825&P2=301&P3=2&P4=c0yzfIEEswvsym8OSjwcei83366u7NOp7GMfPOt2ccc%3d\r\n\r\n11\/17\/2016 08:48:41.60514 AM 816   6432  downloadmanager_cpp14250       [DownloadManager] Updates to download = 1\r\n\r\n11\/17\/2016 08:48:41.60514 AM 816   6432  susupdateinfo_cpp121           [Agent]   Title = Windows Calculator\r\n\r\n11\/17\/2016 08:48:41.60514 AM 816   6432  susupdateinfo_cpp11            [Agent]   UpdateId = 7DD40C91-F143-4628-A87A-3B29D4199C64.1\r\n\r\n11\/17\/2016 08:48:41.60515 AM 816   6432  susupdateinfo_cpp15            [Agent]     Bundles 2 updates:<\/pre>\n
Scenario 2<\/h3>\n
You have WSUS or SCCM configured to manage Windows Update in the environment, but you observe that Windows 10 machines are reaching online to get updates including system updates<\/strong>.<\/p>\n
For example, look at this log snippet:<\/p>\n
11\/18\/2016 09:13:09.18706 AM 936   16068 service_cpp393                 [Shared] * START * Service startup\r\n\r\n11\/18\/2016 09:13:09.19555 AM 936   16068 susclientglobal_cpp67          [Agent] WU client version 10.0.14393.351\r\n\r\n11\/18\/2016 09:13:09.19571 AM 936   16068 sleepstudytracker_cpp162       [Agent] SleepStudyTracker: Machine is non-AOAC. Sleep study tracker disabled.\r\n\r\n11\/18\/2016 09:13:09.19576 AM 936   16068 susclientglobal_cpp115         [Agent] Base directory: C:\\WINDOWS\\SoftwareDistribution\r\n\r\n11\/18\/2016 09:13:09.19604 AM 936   16068 dscore_cpp1033                 [Agent] Datastore directory: C:\\WINDOWS\\SoftwareDistribution\\DataStore\\DataStore.edb\r\n\r\n11\/18\/2016 09:13:09.21624 AM 936   1840  settingcache_cpp191            [Agent] Initializing global settings cache\r\n\r\n11\/18\/2016 09:13:09.21624 AM 936   1840  settingcache_cpp192            [Agent] WSUS server: https:\/\/wsus.contoso.com\r\n\r\n11\/18\/2016 09:13:09.21624 AM 936   1840  settingcache_cpp194            [Agent] WSUS status server: https:\/\/wsus.contoso.com\r\n\r\n11\/18\/2016 09:13:09.21624 AM 936   1840  settingcache_cpp196            [Agent] Target group: (Unassigned Computers)\r\n\r\n11\/18\/2016 09:13:09.21624 AM 936   1840  settingcache_cpp200            [Agent] Windows Update access disabled: No\r\n\r\n11\/18\/2016 09:13:09.22079 AM 936   16068 agent_cpp142                   [Agent] Initializing Windows Update Agent\r\n\r\n11\/18\/2016 09:13:09.22085 AM 936   16068 downloadmanager_cpp13864       [DownloadManager] Download manager restoring 0 downloads\r\n\r\n11\/18\/2016 09:13:09.22220 AM 13660 520   discoveryjob_cpp36             [ComApi] *QUEUED* SLS Discovery\r\n\r\n11\/18\/2016 09:13:09.25741 AM 936   4988  downloadmanager_cpp9702        [DownloadManager] PurgeExpiredUpdates::Found 650 non expired updates.\r\n\r\n11\/18\/2016 09:13:09.33071 AM 936   12612 slsclient_cpp413               [SLS] Retrieving SLS response from server using ETAG \"ltWsyjl36fnzgR4MZLDNwWkS+BpTJFrLWZwzas2Z+9Y=_1440\"...\r\n\r\n11\/18\/2016 09:13:09.33097 AM 936   12612 slsdownloader_cpp156           [SLS] Making request with URL HTTPS:\/\/sls.update.microsoft.com\/SLS\/{9482F4B4-E343-43B6-B170-9A65BC822C77}\/x64\/10.0.14393.0\/0?CH=448&L=en-US&P=&PT=0x4&WUA=10.0.14393.351\r\n\r\n11\/18\/2016 09:13:09.33179 AM 13660 9700  discoveryjob_cpp150            [ComApi] *RESUMED* Discovery\r\n\r\n11\/18\/2016 09:13:09.33184 AM 13660 9700  discoveryjob_cpp208            [Api] * END *   Discovery ClientId<\/pre>\n
Point to note: If you didn\u2019t try to scan it against Microsoft Online manually, then why did it try to establish connection with *.update.microsoft.com although WSUS endpoint is in place.<\/p>\n
What you need to check?<\/h2>\n
Check the Windows Update Group policies and ensure that none of these policies are configured (Enabled or Disabled).<\/p>\n
\"Image1\"<\/a><\/p>\n
Ensure that the registry HKEY_LOCAL_MACHINE\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate<\/strong> doesn\u2019t reflect any of these values.<\/p>\n