This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(233.6, 35%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETM%3C/text%3E%3C/svg%3E)
I have stumbled upon what I think is an interesting problem with Office 365 updates delivered though Configmgr.
We have found that updates fail to download and install on clients that are not part of a boundary that is assigned to a DP.
For other types of updates that are delivered via Configmgr, clients will fall back to the defined site fallback DPs, but for O365 updates this appears to not work.
I had a small number of clients that were receiving updates and deployments correctly, but were not getting O365 update. After investigating I could see in the SCCM related update logs that they were pulling locations for the default site DPs that are used when the clients are not part of a defined IP boundary. However the clients were stalling out when it came to C2R actually grabbing the update components via CMBits.
As I looked into the clients that were not updating correctly, I noticed that many of the clients were on similar address ranges. I added a boundary definition for one of those subnets and assigned it to a boundary group that had a DP assigned. The client almost immediately corrected itself and was applying the missing update even before I could get client center open to check on it.
I am unable to tell if there is a setting that lets O365 C2R updates fall back to the defined site default boundary group DPs that I have just neglected to set. I do have the O365 patch deployments configured for fallback to the site default boundary group in the "When software updates are not available on any DP in current..." I see there is a check box to tell the deployment to reach out to Microsoft (I assume CDN) if it cannot locate the source on premise. But even that text mentions the site boundary groups DPs. I think maybe C2R update system is just not built to gather site default boundary group DPs as sources.
My plan is to discover clients that are not assigned to any boundary, make boundary definitions for them, and assign them to a boundary group for the fallback DPs. My problem, and I am sure I am not alone here, is that the network changes frequently and our change management process is not 100%. So new areas are brought on line that I dont find out about. These clients work with Configmgr in all other respects - Windows patching, software deployment, etc... but they start failing to grab O365 C2R updates.
Does anyone have additional information or insight they could add to this discussion?
@Todd Miller
Thank you for posting in Microsoft Q&A forum and thanks for the detailed description of the issue.
I haven't noticed this phenomenon before, and I will do some test about this issue.
I also hope that someone who has encountered the same problem can provide some ideas
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
I should have rounded back to give an update.
We proceeded with the plan to discover clients that were not assigned to any boundary - these clients were getting MS patches and Software deployments OK - but were not able to process O365 updates.
After creating network range boundaries and assigning those boundaries to the default site DPs (where unassigned clients were getting software and MS Updates) the client immediately started patching O365 apps - within a few hours. The only change was to make sure the clients were assigned to a boundary with a DP assigned.
We have not finished creating boundaries for all of our unassigned clients - and often networks are brought on line that we aren't immediately aware of. These clients continue to not patch unless a boundary is created and assigned. It is like flipping a switch- so I am pretty confident that this is the cause and workaround to the problem. But it is only a workaround...
The logs on the clients, when they are having this problem show the traditional update logs getting stuck at the fake 50% download status for O365 updates... Then digging in to the cmbits log you can see that the download is failing. The traditional CM windows update logs show the correct default site boundary DPs though the O365 process seems unable to detect or fallback to the default site boundary DPs though the setting for the deployment says it should. If the box was not checked to use the default site boundaries, I dont think the DPs would show in the traditional CM Windows Update logs for O365 software update.