none
Office 365 client update - current channel (1610-4) 32-bit edition is failing with error 8007007e

    Question

  • I'm getting closer to using SCCM to deploy updates to Office 365.

    I've upgraded to SCCM 1606, installed and configured kb3159706.

    Configured my xml file to use SCCM for current branch updates and enabled the new clients to:

    Enable Management of the Office 365 client agent.

    I've made a software update package and deployment and distributed it  to my local dps.

    The update package size on the console is: 1,728,323 kb

    The update shows up on my client machines but when it runs,  it attempts to download and fails quickly.

    With no content in my cache folder.

    updatehandler.log

    Method (Download) called from SDM.

    Starting job with id = {A3A6AE7D-4D89-49BD-84AE-914C3F35FF0F}

    Initiating Scan. Forced = (0)

    Successfully initiated scan for job ({A3A6AE7D-4D89-49BD-84AE-914C3F35FF0F}).

    Scan completion received for job ({A3A6AE7D-4D89-49BD-84AE-914C3F35FF0F}).

    Evaluating status of the updates for the job ({A3A6AE7D-4D89-49BD-84AE-914C3F35FF0F}).

    Initiating download for the job ({A3A6AE7D-4D89-49BD-84AE-914C3F35FF0F}).

    Bundle update (5914baa3-1b0d-46ef-99be-5e2be6237db0) is requesting download from child updates for action (INSTALL)

    Ignoring update state (DOWNLOAD_READY) change in job state (2)

    Starting download on action (INSTALL) for Alternate Update (7aa0e019-b348-4a1c-965d-6e92325e0af6)

    BeginDownload alternate update content failed. Error = 0x8007007e

    CBundledUpdate -- Failed to download update (7aa0e019-b348-4a1c-965d-6e92325e0af6). Error = 0x8007007e

    Ignoring update state (DOWNLOAD_READY) change in job state (2)

    CDeploymentJob -- Failed to download update (5914baa3-1b0d-46ef-99be-5e2be6237db0). Error = 0x8007007e

    Download completed for the job ({A3A6AE7D-4D89-49BD-84AE-914C3F35FF0F}).

    Successfully sent job ({A3A6AE7D-4D89-49BD-84AE-914C3F35FF0F}) success completion to the SdmAgent

    CompleteJob received from SDM.

    My cas.log shows two local distribution points:

    Requesting locations synchronously for content 7aa0e019-b348-4a1c-965d-6e92325e0af6.1 with priority Foreground

    sRelatedContentIDs is <RelatedContentIDs><RelatedContentID ID="4a3a6548-7a49-4e5e-84cd-

    1b7bf8c43368"/></RelatedContentIDs>. Length = 100.

    The number of discovered DPs(including Branch DP and Multicast) is 2

    Calling back with the following distribution points

    Distribution Point='http://servername/SMS_DP_SMSPKG$/7aa0e019-b348-4a1c-965d-6e92325e0af6', Locality='LOCAL'

    Distribution Point='http://otherServerName/SMS_DP_SMSPKG$/7aa0e019-b348-4a1c-965d-6e92325e0af6', Locality='LOCAL'

    What am I doing wrong?

    Thursday, November 17, 2016 12:01 AM

Answers

  • Hello,
    They finally found the problem with the Error = 0x8007007e

    If you look the error up it says "The specified module could not be found."
    It is a missing DLL-file that probably contains that missing module.
    The file is ApiClient.dll and it should be present in C:\Program Files\Common Files\Microsoft Shared\ClickToRun

    Luckily I had at least one working machine where I was able to find that DLL and copy it to a non-working machine, an that did the trick, the update is installed!
    The case has now moved from the CM team to the Office 365 team and they will try to find out why this file is missing´in the first place.
    So I am able to continue with my pilot and hopefully this will give you a hint as well.


    • Edited by Patric K Monday, December 12, 2016 9:22 AM
    • Marked as answer by David Best Monday, December 12, 2016 2:11 PM
    Monday, December 12, 2016 9:21 AM

All replies

  • Did you use an ADR for the O365 updates?

    Have you installed UR1 for 1606?


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, November 17, 2016 4:31 PM
  • No I ran the update manually.

    No I haven't applied UR1 but I'm about to.

    I'll let you know how it goes.

    Thanks

    Thursday, November 17, 2016 4:43 PM
  • > "No I ran the update manually."

    Sorry, not sure if that answers my question; let me expand: Did you use an ADR to create the update group and download the updates into an update package?


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Thursday, November 17, 2016 8:08 PM
  • I didn't create an ADR.

    I selected the update /created an update group/downloaded the content/ created the update package and distributed the update package to my DPs.

    Then I created a deployment and targeted a couple of computers with Office 365 installed.

    UR1 isn't available in my console yet.

    I do have Kb3202796 listed in Updates and Servicing which I installed.

    Thursday, November 17, 2016 8:48 PM
  • I am experiencing the same problem, same error code, but we are on deferred channel and trying to push the update for 1605-8, however it works on some clients.
    We are in an test phase so we don’t have that many installations, only 16, but it works on 8 and fails on 8 with the same error. I spent a couple of days reading logs and comparing the working and failing clients without any clues. I have opened a case with Microsoft at the end of last week and hopefully I’ll get some feedback on it soon.
    Another thing, the O365 patches are not downloaded to the CM cache, they end up in
    C:\Program Files (x86)\Microsoft Office\Updates\Download

    Monday, November 21, 2016 8:45 AM
  • Thanks for the reply Patric. I was thinking about opening a case with Microsoft this morning. In addition to the install error I can only download the current channel update, the other ones fail repeatedly.

    Error: Failed to download content id 16810126 Error: Incorrect function.

    I did upgrade my test network to 1610 this weekend.

    I noticed a new feature that lets you manage 365 clients from the SCCM console. I'm thinking the 1610 includes a bunch of fixes that may take care of the problems on my production network. I'll let you know how it goes.

    Monday, November 21, 2016 1:01 PM
  • Howdy,

    Thanks for sharing your current situations - just wanted to add we're in the same boat with not being able to update our clients.

    • Seeing the same 0x8007007e errors.
    • SCCM 1606 with UR1 applied - no change to behaviour noted.
    • Office 2016 CTR with XML and GPO options set for SCCM management. FirstReleaseDeferred 
    • Updates downloaded manually (non-ADR)
    • Had been able to update clients via SCCM without issue previously. 

    Also considering a move to 1610 in early 2017. Be interested to hear if anyone else has had similar experiences.  :(


    Monday, November 28, 2016 8:10 PM
  • Hello,

    Just want to let you know I haven't heard much from MS yet.
    I will contact them today and ask them to prioritize this since we have to extend our pilot.
    I'll let you know once I hear something.

    Tuesday, November 29, 2016 9:44 AM
  • Has anyone done any progress yet?
    Microsoft is still struggling with this issue, everything looks fine from what they can see, I am waiting for their respons from my latest feedback on some tests I did, unfortunately without success.
    Thursday, December 8, 2016 9:08 PM
  • Yes, I also put in support requests to Microsoft about four weeks ago. They decided the problem needed to be divided into two parts.

    1. Can't download any but current updates.

    2. Can't deploy the ones I can download.

    The first part took two weeks most of which was taken up by a Microsoft  level one (starter) tech.

    They took a lot of time and then handed off to level two. He found the problem in 10 minutes and fixed it in three hours.

    Not being able to download all Office 365 client updates came down to missing meta data in the properties\content information tab of the displayed update. Only one line of source path instead of 50 or so lines.

    The fix was to remove the Office 365 client selection from the software update point products.

    Then run a SQL query that set the cleanup age from 7 days to 0.

    select * from SC_Component_Property where Name like 'updates cleanup age'
    --Update SC_Component_Property set Value3 = 0 where Name like 'updates cleanup age'

    Then schedule a custom sync schedule to run in a few minutes and monitor the wsyncmgr.log to see it start and finish.

    Next reselect the Office 365 client and schedule another sync.

    Next put the cleanup age back to 7 days.

    After running these steps I could download any Office 365 client but still couldn't deploy any.

    The second problem, first tech has been at it for two weeks and doesn't seem to want to hand it off to the escalated level tech. So that's where I am now.


    • Edited by David Best Friday, December 9, 2016 1:33 PM
    • Proposed as answer by Espen Jaegtvik Tuesday, December 13, 2016 1:51 PM
    Friday, December 9, 2016 1:25 PM
  • Thanks David, great to hear, will recheck with my environment.
    Sunday, December 11, 2016 8:50 PM
  • Hello,
    They finally found the problem with the Error = 0x8007007e

    If you look the error up it says "The specified module could not be found."
    It is a missing DLL-file that probably contains that missing module.
    The file is ApiClient.dll and it should be present in C:\Program Files\Common Files\Microsoft Shared\ClickToRun

    Luckily I had at least one working machine where I was able to find that DLL and copy it to a non-working machine, an that did the trick, the update is installed!
    The case has now moved from the CM team to the Office 365 team and they will try to find out why this file is missing´in the first place.
    So I am able to continue with my pilot and hopefully this will give you a hint as well.


    • Edited by Patric K Monday, December 12, 2016 9:22 AM
    • Marked as answer by David Best Monday, December 12, 2016 2:11 PM
    Monday, December 12, 2016 9:21 AM
  • Hello Patric,

    Great news.  I looked for the file you described but only found one called: ApiClient.PreSxS.dll

    I also downloaded new Office install files last week, but its installs were also missing the file.

    On a machine that was currently running and failing an update, I renamed the file to ApiClient.dll

    and clicked on retry. Which successfully installed my first update after downloading the contents to:

    C:\program files\Common Files\Microsoft Shared\ClickToRun\Updates\16.0.7571.2072\

    I guess I'll wait for the Office 365 team to come up with a fix. My fix might introduce new problems.

    Thanks

    Monday, December 12, 2016 2:10 PM
  • Thanks for sharing your update Patric.

    I repeated your test - copied an existing ApiClient.dll from a machine with the file to one without. Tested deployment of First Release for Deferred Channel (1609-6) and can confirm that this installed successfully with the ApiClient.dll in place. Thanks also to David - can confirm I had the ApliClient.PreSxS.dll on another test installation. 

    Looks like an extraction\expansion routine wasnt completed during servicing? Waiting for MS reponse.

    :)


    Tuesday, December 13, 2016 1:08 AM
  • Thanks for the update David & Patrick, I've copied the file ApiClient.PreSxS.dll and renamed it to ApiClient.dll and that has worked for me as well. 

    I've pushed the renamed file out to a few PCs via GPP and that is working too, but would be much happier with a proper fix from MS. 

    Tuesday, December 13, 2016 3:02 AM
  • Side question: Why would you use GPP to push out a file when you have ConfigMgr in place?

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, December 13, 2016 2:00 PM
  • Exact same issue here.

    The ApiClient.dll was missing and thus SCCM 1602 SUP Office 365 deferred updates were failing on my clients with "unable to find module". Copied and renamed the ApiClient.PreSxS.dll file and the updates work. Now copying the file into the correct location as part of OSD.  Not the best solution really. What are Microsoft saying about this?


    M Tipler

    Monday, December 19, 2016 1:53 PM
  • Microsoft asked for log files, from update install attempts, before and after renaming the file.

    They were thinking the latest December updates had fixed the problem.

    But that wasn't the case for me.

    I believe they also have to work out who's department this problem falls into,

    SCCM or Office 365.

    I'm hoping the next time I download the latest oneclick Office 2016 full install files, and run an install, the file renaming will take care of itself.

    Monday, December 19, 2016 2:46 PM
  • Thank you for the update David and thank you for brining this to Microsoft and the communities attention. No doubt you'll have saved a lot of administrators hours smashing heads against walls.

    Thank you and have a great xmas.


    M Tipler

    Monday, December 19, 2016 4:19 PM
  • Looks like we have this issue in our environment as well. How are you guys resolving this if its widespread in your environment?

    Any updates from Microsoft support on resolving this?

    Wednesday, January 4, 2017 1:11 PM
  • I also am seeing this in my environment.  It seems to be introduced with, at minimum, deferred channel release 16.0.6965.2105 of Office ProPlus.  I have a case open with Microsoft, but I am waiting on them to get back to me.
    Thursday, January 5, 2017 8:42 PM
  • As part of the Office 365 deployment you could script the copying of the missing .dll to relevant location. That is how we are currently working around this issue. Not the best really...

    Cheers.


    M Tipler

    Friday, January 6, 2017 8:45 AM
  • Does anyone know if this is resolved in SCCM 1610?  I'm going to update it this weekend.

    Tuesday, January 17, 2017 2:09 PM
  • I upgraded my server to 1610 a month ago and it didn't change the Office 365 update problem.

    I heard back from Microsoft that they were still working the problem.

    That was about three weeks ago.

    Tuesday, January 17, 2017 4:08 PM
  • Thanks for the reply.  The DLL copy and rename worked for me. Hopefully someone will post here when they hear back from MS on a proper fix.

    Thanks all

    Tuesday, January 17, 2017 5:37 PM
  • Note that this isn't a ConfigMgr issue, the .dll that is missing is part of the Office Installation and thus no update to ConfigMgr can fix this.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, January 17, 2017 6:42 PM
  • .dll is in place, having download issue between MS and SCCM, and between SCCM and client. This conserns ONLY O365 products. Everything else like W10 and O2016 patching working fine.

    From 01/2017, one update gets downloaded, another doesn´t. The one which gets downloaded and distributed to DP, fails in downloading process for the client.

    I think there is something seriously wrong in O365 patching, we have 2-3 enviroments and my lab acting like this...


    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!

    Tuesday, January 17, 2017 9:16 PM
  • I have the same issue, SCCM indicates it downloaded the office 365 update, but if you look at properties, there is a bunch of remote content that is listed as 0 bytes, and if you try and download again, it goes for 10+ mins and fails.

    Wednesday, January 18, 2017 12:31 PM
  • For those experiencing issues deploying O365 updates through SCCM SUP, I had this issue wherein the 365 update was intermittently failing on some of my targeted workstations. I removed the update from my deployment package and downloaded again, added to the package again and updated the DP. The O365 update then worked fine for all other deployments.

    Hope this helps someone.


    M Tipler

    Wednesday, January 18, 2017 1:11 PM
  • Try to redownload the content now, maybe re-syncing the catalog would be good idea too. My collegue received the notification from MS, that they did something to the content.

    Please remember to mark my post as an answer, if I really helped you out, or vote if usefull. Thank you!

    Wednesday, January 18, 2017 3:49 PM
  • Any further updates to this issue? We are having the same problems and we have tried the fixes from above, with no luck. Everytime you try and install the update on the Client it fails. I have had to remove the update from the ADR. Seems like MS would want to acknowledge and fix this issue.

    Any assistance is appreciated.

    Monday, March 27, 2017 9:13 PM
  • You may be having another issue and thus should open your own support case. Yes, Microsoft wants to fix issues but they cannot do so unless they know the issue exists

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Monday, March 27, 2017 9:20 PM
  • Microsoft closed the support ticket a few weeks ago.

    Their solution, according to the tech working my ticket, was to manually rename the file.

    Hopefully they will correct that particular problem in newer releases.

    Tuesday, March 28, 2017 12:59 PM