Copilot for Microsoft 365 Tech Accelerator
Feb 28 2024 07:00 AM - Feb 29 2024 10:30 AM (PST)
Microsoft Tech Community

Office 365 ProPlus Updates vis SCCM

Copper Contributor

Hi all!  We are deploying the monthly current channel updates with SCCM 1606 and some clients get stuck at "Downloading - 50%".  Has anyone else seen this?  The SCCM clients are on v1602 and we saw this back when the SCCM server was on 1602 as well.  So far we haven't been able to find much info or troubleshooting steps for this.  And we've gone through some of the basics like verifying the package is replicated.  If the users run the update from Office itself it downloads and works just fine.  

23 Replies

Hi Chris,


I've seen similar behavior at one of my customers. Are you running multiple languages of office 365?
All supported languages should be configured/enabled in WSUS, SCCM and in your ADR rules.

Hi Chris, In a follow up to Ronni, have you noticed this happening when going to a specific DP or at a specific site...or does it seem wide spread or random? Do you have an estimation of how many clients are experiencing this issue? Thanks! JohnG

We verified we are downloading all four languages that we are configuring Pro Plus to contain (English, Spanish, Portuguese-Brazilian, and Polish).  So far we are primarily testing within one site so hard to say if its a DP issue or not. I created some test machines this weekend to reproduce the issue and analyze more logs and noticed that the update seemed to hang at Downloading (50%) for over 30 minutes before it went to installing.  Of course my attempt to reproduce the issue failed and both machines installed the updates :).  I would say out of 75 people we hear from at least 10 folks every month that they see the updates fail.

Did you get this problem solved? I'm on latest build for SCCM (1606 UR1) and I see this issue on quite a lot of users, maybe thousands. It looks very random, different sites etc. I'm really confused and is out of any more ideas.

Not yet... but we have a Premier Support call open.  I spent about 90 minutes on the phone with the support tech last week and they are in research mode now.  I'll definitely update this once I find out more from MS.

Update on this - the MS support rep was able to repro our issue in their lab.  They claim that even though we specifcy Current Channel, the update process is also looking for Deferred Channel (which we do not download).  I went ahead and tested deploying updates from both channels to an affected client; however, this did not result in any change. 

Great update... I've got the same problem at one of my customers. I'll download the Deferred Channel updates and see if that will change anything. Thanks for the update!

We are experiencing the same problem with SCCM 1610 while deploying Office 365 Client Update - Current Channel (1611-5).  The status gets to the status "Download 50%" and then it just hangs.  I'm curious if anyone ever found a solution to this issue?  

Well, that squashes my hope that this issue is resolved in SCCM 1610 :).  Are your clients also on v1610?


I'm still pursuing this with Microsoft via a premier case.  This past week we were able to determine that the download will start for a bit and then stop.  During this time the UI just hangs on Downloading 50%.  You can see this in the DataTransferService log in C:\Windows\CCM\logs.  If you restart the ccmexec.exe service you'll see more files get donwloaded in the log; however, it will stop after a few files.  Keep restarting the service and the cycle repeats.


The Microsoft support rep was going to take this information back to their senior engineer and look into it further.

Yes, our clients have been updated to 1610 as well.  Also, our SCCM Operations Team installed KB3211925 on the MPs last night.  We're still seeing either the problem I described in yesterday's post or the update just fails right away with this error: 0x8007755A(-2146994854).  The update handler log has this error everytime the update fails: "CAS failed to download update (855487e5-cce6-47c0-976b-269a8ae5b03d). Error = 0x8007755a. Releasing content request."


Our operations team has been looking into this as well, but so far no one has any answers.  The odd thing is that we're seeing different behaviors on different machines, and yesterday a few of the clients were able to successfully install the update after it had hung at 50% for about an hour.  


This one is frustrating. 

Very frustrating indeed!  We too are seeing inconsitencies across machines.  It also seems to vary per month for us.  Machines that have failed for one month's update will have the next month work.  Makes troubleshooting difficult.

Well, its been a month since my last post.  We haven't made any progress as to figuring out what is going on.  I can say that the past month's updates seem to have gone much smoother.  I'm not hearing reports from users that they are failing. 

i'm seeing the same behavior here and inconsistencies. were you able to find the root cause?

We were never able to determine a root cause.  Even Premier Support was unable to help us.  We've kept SCCM and the clients up-to-date with patches and that has seemed to have helped?  I'm not hearing of the update issues like I heard of months ago. 

Hi Chris,
I was having a similar issue and posted on technet.

The workaround was to:
1. Remove Existing Office 365 Deployments.
2. Deploy, but UNCHECK these options:
    2a. "Allow clients to share content"
    2b. "If software updates are not available on distribution point in current..... download content from Microsoft Updates"

Please update if this resolves your problems.


hey chris. did they provide an explanation as to how it was looking for a deffered channel update rather than the specified current channel???

it's such a relief to find that i'm not the only one experiencing this issue ahah

Hi Chris,


I suspect that if a client having deployed deferred channel update to client configured to get current channel update may be the issue.


This could be the scenario when you might have used GPO/ODT to ensure all clients to have same channel of updates, but the GPO or ODT might not have done this job completely.

Hi Parveen!


We ended up opening a few Premier calls on this with the latest one occurring last month.  It turns out there was a known bug with SCCM and the Office 1705 series of updates.  SCCM didn't download an Experiment folder that was part of the update so the update install would fail with a file not found error.  MS stated they plan on fixing this bug in their SCCM 1802 release; however, they provided a workaround where we deleted the updates out of the database and forced a WSUS re-sync.  All seems well now :).