none
Solution for error 0x80070643: Service Pack 2 for Microsoft Office 2010 (KB2687455) 32-Bit Edition?

    Question

  • We are experiencing a lot of difficulty installing the newly released Windows 2010 Office SP2 patch via WSUS since it has been released. Especially with the x32 version.

    Locally on the client = error: Code 78F and via the WSUS server = error 0x80070643

    On researching this, it appears a similar issue occurred with the release of Office 2007 SP2:

    Here is a link for the error occurring with Office 2007 SP2:

    http://support.microsoft.com/kb/967642

    "The installation of 2007 Microsoft Office suite service packs fail with error 1935 or with error 78F. This failure occurs when the Windows Installer encounters a reference either to a drive that no longer exists or to a removable media device that contains no readable media...Typically, this issue occurs when the 2007 Office suite was originally installed by using a temporary storage device."

    On this older error, Microsoft released an update (KB967642) that you could apply, then retry the Windows Service Pack.
    (of course this does not fix this 2010 issue, but shows that Microsoft fixed a similar issue with a previous Office Service pack release.)

    I suspect that because nearly all of our Office 2010 installs are via our Computer Associates ITCM Software Delivery product which initially installed the Office software, it might be why the “storage drive” issue is popping up.

    On the positive side, we’ve had a good deal of success by downloading the Service Pack and then deploying that to the clients that fail via our Software Delivery within ITCM, but this has created a sizable project here within our Corporate office and we have yet to still approve Office 2010 SP2 to the larger WSUS Enterprise which we would like to do.

    Anyone have any success on resolving this error or hear of a forthcoming fix from Microsoft on this?


    Wednesday, August 14, 2013 6:50 PM

All replies

  •  Absolutely pathetic we deal with the same update issues time and time again. We have this problem, very wide spread, XP with 32 bit Office 2010, Win 7 & 8 with 32 or 64 bit versions, total mess.

     Haven't looked farther in to it because their AD FS update took most everyone off Office 365 for 24 + hours until they pulled their "fixes" and had everyone revert back. Nice month of updates Microsoft, get your act together, unbelievable.

     This costs money when this fool hardiness towards professional software is applied. This is a multi-billion dollar corporation, act like one. Try testing your software updates a little more thoroughly. Just look at all the forums to how wide spread this is, real poor level of testing obviously. 

    Friday, August 16, 2013 5:24 AM
  • Thanks for posting and I'm glad I found and read this before approving this update via WSUS. It is unbelievable
    that this is a Microsoft forum and we have no response from MS, not really suprising......


    • Proposed as answer by McBen47 Friday, August 30, 2013 5:15 AM
    Tuesday, August 27, 2013 7:19 PM
  • Hi having encountered the error and looked here

    I thought I would rely on my memory and map a drive to the installation source with it being; I recalled Drive Z

    Thought worth a try given what had been said re Office 2007 SP2

    Guess what it worked

    So you need to have access to the installation source and probably on the same drive reference it was on when originally installed.

    Hope this helps

    Friday, August 30, 2013 5:21 AM
  • McBen47,

    We already have a short term solution, deploying the full Service Pack via our Computer Associates ITCM software delivery component. The point is, this should not be happening at all. This creates a major project for us as there are over 5,000 endpoints that need it in our WSUS Enterprise across 190 sites. Obviously as you have demonstrated, mapping a Z drive with the installation media would fix it too, but that is also not practical given the volume of endpoints that we need to get this service pack to, however I am glad to hear there is another workaround if this benefits someone else in a smaller scale environment.

    Friday, August 30, 2013 11:58 AM