SITUATION: We are having an issue with users editing files in MOSS 2007 using IE8. This is not impacting users that still use Windows XP and Office 2007 (IE7), but rolling back is not an option. The issue occurs when a user attempts to edit a document. At first they receive a message indicating that the office product couldn't connect to the server to execute the save. Closing and reopening and trying to open the document then results in an error:

"No connectivity with the server. The file can't be opened because the server couldn't be contacted."

This occurs for all files they then attempt to open.

BACKGROUND: Testing has revealed an issue that appears to be on the client end. Basically, these Win7/Office2010 machines initially do not have the issue. When they are first joined to the network (using a standard image), they can edit documents in SP2007 without issue. As time goes by and various updates (patches, Group Policies, etc.) are applied, SOMETHING CHANGES and they start receiving the error.

For a while, we believed Java to be the culprit due to it being one of the two program updates (QuickTime was the other) that were applied to our test client machine between when it was working fine and when the user started getting the error. When we initially tested this theory by removing Java 1.6 update 37 (leaving only update 33) the user stopped getting the error and was able to edit again. At this point, we also noticed on a machine that still had update 37 that users other than the primary (who was most likely logged on when the update was applied to their machine) were able to edit without the errors. EUREKA! NOT SO FAST. It turned out that this ability to edit was short-lived. Before long, all users were getting the edit error on the machine whether it had update 37 or only 33. Java theory - disproved.

This ability to edit has occasionally returned for short periods of time with some of the edits tried on the client machine (see below), but it never takes long for the error to resurface.

Resolutions Tried (& Failed) on the Client Machines

-Adding a Registry Key for BasicAuthLevel with a value =2

-Using IE 64-bit to open files

-Removing Java 1.6 Patch 37

-Making a fake proxy in IE

  • Interestingly, removing all the registry entries for Office (14.0) under HKEY_CurrentUser did seem to re-enable editing of the documents in SharePoint. However, the user editing the document would then leave it locked for all others. After a reboot of that user's machine, the file was then even locked for editing from the user who had it locked.
    – Jennifer
    Feb 11, 2013 at 15:34
  • I have been battling a similar issue with Microsoft Dynamics CRM Online. One of the solutions I read in a TechNet forum suggested that the issue might be caused by a conflict with Microsoft Live IDs and user log ins. I am still in the testing phase, but you may want to give this a look.
    – tke808
    Feb 11, 2013 at 16:45
  • Did you ever come to a solution? If not, maybe support.microsoft.com/kb/870853 would help?
    – Nicole
    Dec 13, 2013 at 1:21


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.