Why WSUS and SCCM managed clients are reaching out to Microsoft Online

This post was authored by Shadab Rasheed, Technical Advisor, Windows Devices & Deployment 

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 reaching 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.

So, what’s exactly going on here?

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.

OS impact: 1511 & 1607

Scenario 1

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.

Here the concern could be two situations:

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

B. It is consuming a significant bandwidth towards this url.

While both these scenarios are interconnected, if you are observing Scenario A then you may also report Scenario B.

What is happening here?

Scenario A + B

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’t used the download switches to BITS. From 1607 build onwards, it is the default downloader for Windows Update and Windows Store content.

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.

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.

So, what you are is experiencing is by-design behavior.

Scenario B

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. The requirement is that your proxy server should support byte-range requests.

If it does, then you need to apply a rule to permit HTTP RANGE requests for the following URLs:

*.download.windowsupdate.com

*.au.windowsupdate.com

*.tlu.dl.delivery.mp.microsoft.com

How will it help?

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.

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.

Learn more about Windows 10, Delivery Optimization, and WSUS.

Learn more about policy updated for DO in TH2 and RS1.

As you figured out we didn’t 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’t cancel the existing download. However, it may help in mitigating new clients not reaching out for Store app updates. Thus, we don’t recommend it.

The app update has to be cancelled from the Store itself or using wsreset.exe from Run.

Refer to the Windows Update logs after you have decoded the etl. Look for following entries:

11/17/2016 08:48:39.74543 AM 6440  6536  downloadjob_cpp183             [ComApi] * START *   Download ClientId = WSAutoUpdate

11/17/2016 08:48:39.74543 AM 6440  6536  downloadjob_cpp186             [ComApi] Flags: 0X302; Download priority: 3; Network Cost Policy: 0

11/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

11/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

11/17/2016 08:48:41.60514 AM 816   6432  downloadmanager_cpp14250       [DownloadManager] Updates to download = 1

11/17/2016 08:48:41.60514 AM 816   6432  susupdateinfo_cpp121           [Agent]   Title = Windows Calculator

11/17/2016 08:48:41.60514 AM 816   6432  susupdateinfo_cpp11            [Agent]   UpdateId = 7DD40C91-F143-4628-A87A-3B29D4199C64.1

11/17/2016 08:48:41.60515 AM 816   6432  susupdateinfo_cpp15            [Agent]     Bundles 2 updates:

Scenario 2

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.

For example, look at this log snippet:

11/18/2016 09:13:09.18706 AM 936   16068 service_cpp393                 [Shared] * START * Service startup

11/18/2016 09:13:09.19555 AM 936   16068 susclientglobal_cpp67          [Agent] WU client version 10.0.14393.351

11/18/2016 09:13:09.19571 AM 936   16068 sleepstudytracker_cpp162       [Agent] SleepStudyTracker: Machine is non-AOAC. Sleep study tracker disabled.

11/18/2016 09:13:09.19576 AM 936   16068 susclientglobal_cpp115         [Agent] Base directory: C:\WINDOWS\SoftwareDistribution

11/18/2016 09:13:09.19604 AM 936   16068 dscore_cpp1033                 [Agent] Datastore directory: C:\WINDOWS\SoftwareDistribution\DataStore\DataStore.edb

11/18/2016 09:13:09.21624 AM 936   1840  settingcache_cpp191            [Agent] Initializing global settings cache

11/18/2016 09:13:09.21624 AM 936   1840  settingcache_cpp192            [Agent] WSUS server: https://wsus.contoso.com

11/18/2016 09:13:09.21624 AM 936   1840  settingcache_cpp194            [Agent] WSUS status server: https://wsus.contoso.com

11/18/2016 09:13:09.21624 AM 936   1840  settingcache_cpp196            [Agent] Target group: (Unassigned Computers)

11/18/2016 09:13:09.21624 AM 936   1840  settingcache_cpp200            [Agent] Windows Update access disabled: No

11/18/2016 09:13:09.22079 AM 936   16068 agent_cpp142                   [Agent] Initializing Windows Update Agent

11/18/2016 09:13:09.22085 AM 936   16068 downloadmanager_cpp13864       [DownloadManager] Download manager restoring 0 downloads

11/18/2016 09:13:09.22220 AM 13660 520   discoveryjob_cpp36             [ComApi] *QUEUED* SLS Discovery

11/18/2016 09:13:09.25741 AM 936   4988  downloadmanager_cpp9702        [DownloadManager] PurgeExpiredUpdates::Found 650 non expired updates.

11/18/2016 09:13:09.33071 AM 936   12612 slsclient_cpp413               [SLS] Retrieving SLS response from server using ETAG "ltWsyjl36fnzgR4MZLDNwWkS+BpTJFrLWZwzas2Z+9Y=_1440"...

11/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

11/18/2016 09:13:09.33179 AM 13660 9700  discoveryjob_cpp150            [ComApi] *RESUMED* Discovery

11/18/2016 09:13:09.33184 AM 13660 9700  discoveryjob_cpp208            [Api] * END *   Discovery ClientId

Point to note: If you didn’t 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.

What you need to check?

Check the Windows Update Group policies and ensure that none of these policies are configured (Enabled or Disabled).

Ensure that the registry HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate doesn’t reflect any of these values.

• DeferFeatureUpdate
• DeferFeatureUpdatePeriodInDays
• DeferQualityUpdate
• DeferQualityUpdatePeriodInDays
• PauseFeatureUpdate
• PauseQualityUpdate
• DeferUpgrade
• ExcludeWUDriversInQualityUpdate

What just happened here? Aren’t these update or upgrade deferral policies?

Not in a managed environment. These policies are meant for Windows Update for Business (WUfB). Learn more about Windows Update for Business.

Windows Update for Business aka WUfB enables information technology administrators to keep the Windows 10 devices in their organization always up to date with the latest security defenses and Windows features by directly connecting these systems to Windows Update service.

We also recommend that you do not use these new settings with WSUS/SCCM.

If you are already using an on-prem solution to manage Windows updates/upgrades, using the new WUfB settings will enable your clients to also reach out to Microsoft Update online to fetch update bypassing your WSUS/SCCM end-point.

To manage updates, you have two solutions:

• Use WSUS (or SCCM) and manage how and when you want to deploy updates and upgrades to Windows 10 computers in your environment (in your intranet).
• Use the new WUfB settings to manage how and when you want to deploy updates and upgrades to Windows 10 computers in your environment directly connecting to Windows Update.

So, the moment any one of these policies are configured, even if these are set to be “disabled”, a new behavior known as Dual Scan is invoked in the Windows Update agent.

When Dual Scan is engaged, the following change in client behavior occur:

• Whenever Automatic Updates scans for updates against the WSUS or SCCM server, it also scans against Windows Update, or against Microsoft Update if the machine is configured to use Microsoft Update instead of Windows Update. It processes any updates it finds, subject to the deferral/pausing policies mentioned above.

Some Windows Update GPOs that can be configured to better manage the Windows Update agent. I recommend you test them in your environment.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]

“DoNotConnectToWindowsUpdateInternetLocations”=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]

“NoAutoUpdate”=dword:00000001

“UseWUServer”=dword:00000001

In GPO

Windows Components/Windows Update

Configure Automatic Updates: Disabled

Do not connect to any Windows Update Internet locations: Enabled

Specify intranet Microsoft update service location: Enabled

WSUS Endpoints

More information

Delivery Optimization is integrated with and builds on the existing security measures in Windows Update and Windows Store to ensure a highly secure download system.

Delivery Optimization ensures that your PC only downloads trusted OS updates and apps from Windows Update and Windows Store.

Delivery Optimization does not use broadcast messages like BranchCache. Instead it uses a cloud service for peer discovery and peer management.

This means that client – service calls (HTTPS) to *.do.dsp.mp.microsoft.com need to be allowed for DO to work (even if you’re restricting DO to use the local network / LAN option).

DO uses TCP port 7680 to listen for incoming connections from peers.

3544 is a Teredo port that DO uses for NAT traversal which is used for Internet peers or if Group DownloadMode is enabled (for peering across NATs).

Get more information on Group mode and Bypass mode.

I hope this information helps you to understand and appropriately plan your patching configurations.