none
SharePoint 2010 and Office 2013 Can't edit documents

    Question

  • Hello

    I have built a desktop image with Office 2013. I am receiving the following error when I click on a document in a SharePoint library and click "Edit in Microsoft Word" (the problem is not limited to Word):

    The document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document.

    I have tried the following:

    • Ensuring the "WebClient" service is running
    • Ensuring the site is in the "Local Intranet" zone
    • Checking the "SharePoint OpenDocuments Class" add-on is loaded
    • Making sure Internet Explorer is not running in 64-bit mode
    • Manually re-registering OWSSUPP.DLL
    • Ensuring the SharePoint Foundation integration components are installed
    • Repairing Microsoft Office

    The document sometimes loads succesfully but not always. When it will and won't load seems quite random. I am at a complete loss as to why this is!

    I am running the following on my client:

    • Windows 7 Enterprise SP1 (x64)
    • Office Professional Pro Plus 2013 (VL)

    If anyone has any ideas I would greatly appreciate this.

    Regards

    Peter

    Friday, February 15, 2013 11:04 AM

Answers

  • This took a lot of tracking down!!!! 

    The issue is with Office 2013. Someone at Microsoft has hardcoded what I think maybe the US local into a registry key request!!! Just brilliant!!

    The key in question is: HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\2057

    2057 is the US local

    However we are not in the US !! Our local is 1033. So the key that exists on our PCs is

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\1033

    But Microsoft is looking for x86\2057 and that is why it fails - Also, if you are getting it were the document opens first time then errors from then on until IE is restarted - That is because the first time you make a document call through SharePoint in a new IE session, it calls it differently to subsequent calls. I have verified this by tracing what is going on in the background...

    Now due to the nature of the call you cannot just rename they key to be the missing key - we need to create and additional key ending in 2057 with the same value as (in our case x86\1033. So in the end you should have the following keys in place:

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\1033

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\2057

    So there goes several hours of my life that I'm never getting back all for some sloppy coding - Thanks MS

    To everyone else who has been suffering from this problem, time to smile once more :-)


    • Edited by HAN_1231 Wednesday, April 03, 2013 3:22 PM
    • Proposed as answer by gjoris Wednesday, April 10, 2013 9:01 AM
    • Marked as answer by Steven AndrewsEditor Tuesday, July 02, 2013 10:56 PM
    Wednesday, April 03, 2013 3:21 PM
  • The issue is not SharePoint, but the Office Discovery Protocol, take a look at:

    "Opening an Office document from Internet Explorer"

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

    http://blogs.msdn.com/b/vsofficedeveloper/archive/2008/03/11/office-existence-discovery-protocol.aspx

    I found the same issue with Office 2010 x64 against SPS 2003 on Win7 x64 - its 2 years ago (when Office 2010 was RTM) so sorry i cant remember the details, we installed a 32 bit Access viewer and it solved the issue with office documents.

    I am not sure which Access thingy we solved the issue with;

    http://www.microsoft.com/en-us/download/details.aspx?id=13911

    http://www.microsoft.com/en-us/download/details.aspx?id=10910

    Basicly  its you client which do not know how it should open the document, you can dll it an edit and upload, because thats not Office Discovery Protocol.

    You would see with bingling og gogling many people have same issues, even with first document can be open but not the second hence something is rotten in the session.

    And ofcourse it can also be an firewall/proxy issue. 

    If you want to dive deeper in to it while "waiting for Godot", use procmon and see what it gives you, my bet it is looking for some registries which is not prescens

    Wednesday, February 20, 2013 11:35 PM

All replies

  • Is this 64-bit Office 2013?

    Also keep in mind that there are various compatibility issues between Office 2013 applications and SharePoint 2010.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Friday, February 15, 2013 4:22 PM
  • This is indeed 64-bit office. I appreciate that, unfortunately there is not alot of documentation around this. What is strange is that it occasionally works. By that I mean, if I try to open a handful of documents a couple of times inside of 60 seconds, a couple will succeed. This is not even a per document thing. One document which has opened properly before may not the next time.
    Friday, February 15, 2013 4:25 PM
  • Use 32bit Office.  64bit Office is generally still considered for testing purposes only, and not all ActiveX controls required by SharePoint 2010 (or 2013) are available in 64bit Office.

    There are other various incompatibilities with Office 2013 and SP 2010 like I said, but most of those that I've found surround Excel/Visio and are BI-specific.


    SharePoint - Nauplius Applications
    Microsoft SharePoint Server MVP
    MCITP: SharePoint Administrator 2010

    -----------------------
    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Friday, February 15, 2013 5:45 PM
  • I have tried 32 bit Office on the build and the same issues are there. It opened the document find the first time and failed the second.

    Don't understand why it would work sporadically!

    Monday, February 18, 2013 11:18 AM
  • Hello,

    Thank you for your question.

    We are trying to involve someone familiar with this topic to further look at this issue.

    This may take some time. Thanks for your patience.

    Thanks,


    Jack Gao
    TechNet Community Support

    Wednesday, February 20, 2013 3:19 AM
  • The issue is not SharePoint, but the Office Discovery Protocol, take a look at:

    "Opening an Office document from Internet Explorer"

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

    http://blogs.msdn.com/b/vsofficedeveloper/archive/2008/03/11/office-existence-discovery-protocol.aspx

    I found the same issue with Office 2010 x64 against SPS 2003 on Win7 x64 - its 2 years ago (when Office 2010 was RTM) so sorry i cant remember the details, we installed a 32 bit Access viewer and it solved the issue with office documents.

    I am not sure which Access thingy we solved the issue with;

    http://www.microsoft.com/en-us/download/details.aspx?id=13911

    http://www.microsoft.com/en-us/download/details.aspx?id=10910

    Basicly  its you client which do not know how it should open the document, you can dll it an edit and upload, because thats not Office Discovery Protocol.

    You would see with bingling og gogling many people have same issues, even with first document can be open but not the second hence something is rotten in the session.

    And ofcourse it can also be an firewall/proxy issue. 

    If you want to dive deeper in to it while "waiting for Godot", use procmon and see what it gives you, my bet it is looking for some registries which is not prescens

    Wednesday, February 20, 2013 11:35 PM
  • FYI - having the same issue. Very similar environment: Office 2013 64-bit, SP2010. Same error.

    Workaround #1: If I map a network drive to the SP site, I can open the documents.

    Workaround #2: Seems like I can also open the doc from the Office client (i.e. from PowerPoint CTRL-O) if I have the full path. 

    Would love a real solution for this though. 

    Steve


    Wednesday, March 20, 2013 4:02 PM
  • We are also getting the same issue on lots of PCs with fresh installs of Windows 7 and Office 2013.

    MICROSOFT - This smells like a bug??????  Please fix your software

    Thursday, March 21, 2013 3:46 PM
  • This took a lot of tracking down!!!! 

    The issue is with Office 2013. Someone at Microsoft has hardcoded what I think maybe the US local into a registry key request!!! Just brilliant!!

    The key in question is: HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\2057

    2057 is the US local

    However we are not in the US !! Our local is 1033. So the key that exists on our PCs is

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\1033

    But Microsoft is looking for x86\2057 and that is why it fails - Also, if you are getting it were the document opens first time then errors from then on until IE is restarted - That is because the first time you make a document call through SharePoint in a new IE session, it calls it differently to subsequent calls. I have verified this by tracing what is going on in the background...

    Now due to the nature of the call you cannot just rename they key to be the missing key - we need to create and additional key ending in 2057 with the same value as (in our case x86\1033. So in the end you should have the following keys in place:

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\1033

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\2057

    So there goes several hours of my life that I'm never getting back all for some sloppy coding - Thanks MS

    To everyone else who has been suffering from this problem, time to smile once more :-)


    • Edited by HAN_1231 Wednesday, April 03, 2013 3:22 PM
    • Proposed as answer by gjoris Wednesday, April 10, 2013 9:01 AM
    • Marked as answer by Steven AndrewsEditor Tuesday, July 02, 2013 10:56 PM
    Wednesday, April 03, 2013 3:21 PM
  • I've also seen articles that indicate uninstalling InfoPath 2013 will resolve this problem. Does this relate to your registry key fix?

    http://www.rightpoint.com/community/blogs/viewpoint/archive/2012/11/29/issue-with-office-2013-and-sharepoint-2010-on-same-machine.aspx

    I uninstalled InfoPath and it seems to work just fine now.
    • Edited by lucidgreen Thursday, April 04, 2013 4:24 PM
    Thursday, April 04, 2013 4:22 PM
  • I had a Microsoft support ticket that lead to the same fix this week - I'm based in Australia, and the reg key needs to match my region LCID.

    x86\3081

    3081 is Australia (en-au)

    Microsoft has commented to me that this will be included in the upcoming Office 2013 June CU.

    Anyway, the scenario is:

    • PC region settings not US (1033)
    • Office 2013 installed (in some case, only Lync 2013)
    • SharePoint.OpenDocument extension in IE is v15
    • IE9, IE10
    • Win7, Win8


    jliu - http://johnliu.net - http://sharepointgurus.net

    Wednesday, April 24, 2013 4:40 AM
  • This worked for me. Uninstalling InfoPath had no affect.

    For clarity, the actual location in the registry is 

    HKEY_CLASSES_ROOT\Installer\Components\55EAFA0B8A4403B428FDE038B252C621

    I originally looked for HKCR which does exist but doesn't contain Installer


    Friday, April 26, 2013 11:01 AM
  • Also applies to Surface RT, problem and resolution... hoping a hotfix is pending.


    Sunday, April 28, 2013 6:46 AM
  • Hello

    I have built a desktop image with Office 2013. I am receiving the following error when I click on a document in a SharePoint library and click "Edit in Microsoft Word" (the problem is not limited to Word):

    The document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document.

    I have tried the following:

    • Ensuring the "WebClient" service is running
    • Ensuring the site is in the "Local Intranet" zone
    • Checking the "SharePoint OpenDocuments Class" add-on is loaded
    • Making sure Internet Explorer is not running in 64-bit mode
    • Manually re-registering OWSSUPP.DLL
    • Ensuring the SharePoint Foundation integration components are installed
    • Repairing Microsoft Office

    The document sometimes loads succesfully but not always. When it will and won't load seems quite random. I am at a complete loss as to why this is!

    I am running the following on my client:

    • Windows 7 Enterprise SP1 (x64)
    • Office Professional Pro Plus 2013 (VL)

    If anyone has any ideas I would greatly appreciate this.

    Regards

    Peter

    Also very important.  After trying everything else - when you go into internet explorer / manage add-ons, hit the MORE INFORMATION link for the Opendocument class add-on and see what sites it's allowed to run on.  In my case it wasn't allowed to run on any sites.

    Wednesday, May 01, 2013 10:01 PM

  • Now due to the nature of the call you cannot just rename they key to be the missing key - we need to create and additional key ending in 2057 with the same value as (in our case x86\1033. So in the end you should have the following keys in place:

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\1033

    HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\2057

    Hi

    I don´t understand.

    Change the key \x86\1033 for \x86\2057 or both must be in the container HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621?

    Thanks

    Friday, May 03, 2013 3:33 AM
  • The registry key fixed it for me.

    On this page you can look up your local culture:

    http://www.gtrifonov.com/2010/02/12/setting-currentculture-lcid-code-table/

    In Control Panel > Region I have Dutch - Belgium configured. Adding a multi-string value  x86\2067 fixed the problem.

    Tuesday, May 07, 2013 8:36 AM
  • John and HAN I could kiss you both.

    I have been doing battle with this for days reading nothing more than "uninstall and install the 32 bit version" or "Downgrade IE.. letting it upgrade was your first mistake" or similar.

    I created these keys (3801 for me like John) and vooshka! Works every time.

    My added confusion comes from the fact that I am being published through a UAG and I wasn't even reading the Office 2013 articles because I have Office 2010 but at the end of the day it had nothing to do with UAG and it was affecting me because I have Lync 2013 installed over Office 2010.

    Brilliant!

    Friday, May 31, 2013 4:03 AM
  • I am based in the UK and adding a new string value of x86\2057 has fixed the problem for me.

    Thank you very much! And thank you Google! :-)

    Thursday, June 20, 2013 3:52 PM
  • I've got the same problems.

    Any listed solutions didn't work.

    windows 7(64bit), office 2013(x86) PlusPro, IE8 (x86).

    http://social.technet.microsoft.com/Forums/office/en-US/8ac59fc3-8c07-4669-a278-c2b6a0e67c25/office-2013-and-sharepoint-2010-win-764-ie-832-cant-edit-document-in-client

    Monday, August 05, 2013 8:14 AM
  • Thank you Thank you Thank you! I was trying for a long time to fix this. This helped and fixed a few other problems as well, like creating a new Document from a Template.
    Used x86\3079 for Germany-Austria.
    Monday, August 05, 2013 10:10 AM
  • Error:  I was getting a message that said Office 2010 needs to open in safe mode.

    My environment:  SharePoint 2010 with Office 2010 doc's.  Office 2013 (upgraded from Office 2010) on pc's

    Fix:  In my environment we had upgraded from Office 2010 to Office 2013, in doing so there was still some parts of Office 2010 still on the machine, I found this in Add\Remove programs.  I removed the Office 2010 and rebooted my pc, now I can open Office 2010 docs from my SharePoint 2010 server with my Office 2013 version.


    Hope this helps...

    James

    Thursday, August 22, 2013 10:38 PM
  • Thanks for this - I owe a beer to a few of the guys above!

    Is there an update on this? Any fixes ...

    === Update:

    Seems the June CU has the fix: 

    Description of the Office 2013 hotfix package (Owssupp-x-none.msp): June 11, 2013
    http://support.microsoft.com/kb/2726997


    • Edited by Peter_D503 Friday, September 06, 2013 6:59 AM
    Friday, September 06, 2013 5:34 AM
  • It is about the compatibility issue. Just install an older Office - 2007 or 2010 and it should work like a charm.
    Monday, September 30, 2013 9:37 AM
  • Hi

    I have a similar issue in my environment where it fails to load SharePoint OpenDocuments Class plugin in IE, even though Support for Microsoft SharePoint Foundation is enabled under my Office 2013 installation under Office Tools (it is all white in there)

    Tuesday, February 18, 2014 2:15 PM
  • This worked perfectly. I've now retrieved several hours of my life! Thank you!
    Wednesday, February 19, 2014 10:00 PM
  • This took a lot of tracking down!!!! 

    The issue is with Office 2013. Someone at Microsoft has hardcoded what I think maybe the US local into a registry key request!!! Just brilliant!!

    The key in question is: HKCR\Installer\Components\55EAFA0B8A4403B428FDE038B252C621\x86\2057

    2057 is the US local

    However we are not in the US !! Our local is 1033.

    I feel obligated to point out that 2057 is UK and 1033 is actually US. Good find, though!

    Wednesday, February 19, 2014 10:34 PM