- 3,740,929 Users
- 2,248,346 Discussions
- 7,861,504 Comments
- 381.2K All Categories
- 2.1K Data
- 204 Big Data Appliance
- 1.9K Data Science
- 446.5K Databases
- 220.6K General Database Discussions
- 23 Multilingual Engine
- 511 MySQL Community Space
- 462 NoSQL Database
- 7.7K Oracle Database Express Edition (XE)
- 2.8K ORDS, SODA & JSON in the Database
- 448 SQLcl
- 3.9K SQL Developer Data Modeler
- 185.6K SQL & PL/SQL
- 20.8K SQL Developer
- 291.8K Development
- 7 Developer Projects
- 117 Programming Languages
- 288.5K Development Tools
- 94 DevOps
- 3K QA/Testing
- 645.3K Java
- 18 Java Learning Subscription
- 36.9K Database Connectivity
- 150 Java Community Process
- 104 Java 25
- 22.1K Java APIs
- 137.7K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 12 Java Essentials
- 141 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 197 Java User Groups
- 191 LiveLabs
- 34 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 165 Deutsche Oracle Community
- 1.2K Español
- 1.9K Japanese
- 225 Portuguese
Why WSUS and SCCM managed clients are reaching out to Microsoft Online
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
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.
One of the main reasons why you may be experiencing a significant bandwidth consumption is because of the Proxy configuration. 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:
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.
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.
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.
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.
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
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).
I hope this information helps you to understand and appropriately plan your patching configurations.
If you have any doubts on SCCM visit Mindmajix. My personal impression is that SCCM is a very promising tool. On the one hand I like its clean and elegant design, and on the other hand I loved to find out that a young open source tool can still have an excellent documentation. In this article I tried to summarize my own understanding of the WSUS and SCCM managed clients are reaching out to Microsoft Online, which may or may not be 100% correct – feel free to let me know if there are any mistakes in the description above!