Where did my updates download from?

For diagnosing the dreaded content not found, or the endless downloading message in Software Center, it is crucial to understand where the client obtains its content. A combination of boundary group settings, which distribution points host the content, and the download settings on the deployment determine the content location and prioritization.

Per the Microsoft Documentation, first, the Windows Update Agent attempts to locate the content using Delivery Optimization. If the Windows Update Agent cannot find the content, the Config Mgr client takes over the search for content in the following locations; listed in order of prioritization.

1. The distribution point on the same computer as the client
2. A peer source in the same network subnet
3. A distribution point in the same network subnet
4. A peer source in the same boundary group
5. A distribution point in the current boundary group
6. A distribution point in a neighbor boundary group configured for fallback
7. A distribution point in the default site boundary group
8. The Windows Update cloud service
9. An internet-facing distribution point
10. A cloud distribution point in Azure

Let’s review the default site boundary created during the site installation. In my lab, it is called “Default-Site-Boundary-Group.” The critical parts of this boundary are the site server assignment and default behavior. The site system server is the distribution point for clients to use when the local distribution point or a neighbor distribution point do not host the content. The default behavior tab determines how much time has to elapse before the client attempts to contact (fallback) the site system defined on the references tab. You can also set the site to never fallback.

Along with the Default Site Boundary, a site typically contains additional boundary groups. The details of how to create boundary groups are outside the scope of this article. The vital thing to know is that on the boundary group, you can specify which distribution point to use and you can configure a fallback neighbor.

A Software Update deployment has three options to select from if the content is not on a local boundary:

• Select the deployment option to use when a client uses a distribution point from a neighbor boundary group or the default site boundary group. Options are do not install or download and install.
• When software updates are not available on any distribution points in current or neighbor boundary group, client can download and install software updates from distribution points in site default boundary group. Options are do not install or download and install.
• If software updates are not available on distribution point in current, neighbor or site boundary groups, download content from Microsoft Updates.

I started a test in my lab to prove out my understanding of the were content for Office 365, and Microsoft updates would download. For my deployment, I selected all three deployment options: download from a neighbor, download from the site, download from Microsoft Updates. Below is what I expected to happen.

To monitor the results, I used the log files below.

In the first test, the content was downloaded from the local distribution point, precisely as planned. The content was on the local distribution point on the same subnet. See snip-it from the Content Transfer Manager Log.

In the second test, I expected content to download from the neighbor distribution point. There was no local distribution point. However, fallback was enabled and the neighbor distribution point hosted the content. The Content Transfer Manager log showed the expected results: Neighbor, Site, MS Updates. Nonetheless, the actual download came from Microsoft Updates.

Test three was a variation of test two. This time the goal was where the content would come from if there was no local distribution point, and no neighbor configured. The expected result would be that the content would come from the site server. Again the Content Transfer Manager log showed the expected results: site, Microsoft Updates. However, the actual download once again came from Microsoft Updates.

In the final test, no distribution points hosted the content. Rule eight above states a Microsoft cloud service provides the content. This test correctly downloaded the content from Microsoft Updates.

Next, I modified the second test. The new deployment did not have the checkbox to download from Microsoft checked. My expectations were the same as before; the client would pull content from the neighbor. This time the content did download from the neighbor.

With both Office 365 and Microsoft Updates, when the checkbox to download from the Microsoft Updates site, was checked, content came from Microsoft. The only explanation I have for why the updates downloaded from Microsoft instead of the distribution points in the order published by Microsoft, is when for remote distribution points the content source is picked at random. I am not sure that is correct. If anyone has an explanation for why my results were different from the Microsoft Documentation, please let me know.