Oct 13 2016 06:36 AM
Oct 13 2016 06:36 AM
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.
Oct 18 2016 11:36 PM
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.
Oct 20 2016 09:00 AM
Nov 07 2016 08:21 AM
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.
Nov 16 2016 12:22 PM
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.
Nov 20 2016 03:51 PM
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.
Nov 29 2016 12:17 PM
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.
Nov 29 2016 12:49 PM
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!
Dec 22 2016 10:02 AM
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?
Dec 23 2016 09:53 AM
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.
Dec 23 2016 10:19 AM
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.
Dec 23 2016 10:22 AM
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.
Jan 23 2017 07:17 AM
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.
Mar 13 2017 10:46 AM
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.
Mar 14 2017 07:24 PM
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.
Mar 14 2017 07:53 PM
Dec 29 2017 05:09 AM
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.
Jan 02 2018 07:43 PM
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 :).