locked
"No connectivity with the server" error for one document but not the other, in the same document library RRS feed

  • Question

  • We have a number of users all of a sudden getting "No connectivity with the server.  The file 'xxx' can't be opened because the server couldn't be contacted." errors trying to open MS Office docs (Word, Excel, etc.) in SharePoint with IE, just by clicking the link and selecting the "Read Only" option.  If they select the "Check Out and Edit" option, they can open the document no problem.  One of my customers gets the error on one document but not the other, in the same document library!  The older document (a weekly report) was copied and renamed as per standard procedure.  She can read the older document, but not the new one.

    It is definitely a profile issue, as other people have logged onto the machines of the users with problems and do not get the error.  We have also renamed people's c:\user profile folders and the corresponding Profilelist registry entry and the newly created profile does not experience the error for these people.  Renaming the profile back restores all their personal settings but the error reappears.  When we copied the old profile's folder structure into the new profile, many of the user settings were restored (but not all, like Dreamweaver settings) but the error did not appear.  We think that the system folders files (like AppData) weren't totally copied over so we're going to run another test using xcopy.  We are rebooting between logons to make sure all files are unlocked.

    The laptops and computers are mainly 32bit, Win7 Enterprise running IE9 and Office 2010 Professional Plus, but there's a few 64bit machines as well. The SharePoint farm has 1 WFE, 1 App Server running search and CA, and a shared database server running SQL 2005 SP4.  SharePoint is 64bit MOSS 2007 with the latest CU.

    We've checked the logs on the client as well as on the server and there aren't any helpful entries.  We've also run Process Monitor, also with no helpful entries.  We're planning to run something like Fiddler next.

    It's not everyone, because there are many people are accessing the SharePoint system and the same files.  It is also not a permission thing, as we've tested by giving the users elevated permissions with no changes.  One person experiencing the errors is a Site Collection Admin.  That same person ran a test where I coped a simple Excel file into a Document Library which contained a problem file.  They were able to open it Read Only no problems that day, but the next day, the same file gave them an error.   In their case, they usually get a "xxx is not checked out" error and only occasionally get the "No connectivity with the server" error.

    We've tried lots of things including:

    • Deleting IE cache
    • Deleting SharePoint Drafts and webcache folder contents
    • Running IE without add-ons
    • Upgrading and Downgrading IE
    • Uninstalling and re-installing IE
    • Reinstalling our SSL certs
    • Repairing Office
    • Removing and then adding back in the Microsoft Office "Microsoft SharePoint Foundation Support" Office Tool 
    • Deleting all HKLM and HKLU Office registry settings
    • Toggling IE Compatibility Settings
    • Toggling the IE Automatic Logon option
    • Toggling the location of checked out files
    • Adding the site in the trusted sites list
    • Adding the site to the WebClient\Parameters registry locations
    • Making sure the WebClient service is started
    • Rebooting the machine (lol :)

    This is becoming a serious issue, not just because of the inconvenience for the users having to check out every document they want to read, but we have some files with macros that open up other documents to run which are now failing.  There aren't "check out" workarounds for some of those macros.

    We're planning to open a ticket with Microsoft, but I'm throwing it out here first in case someone has run into this before, or may have some suggestions on what to try next.  Thanks!

    -Richard.

    PS  I think this needs to be in the "General" forum instead?






    Monday, April 28, 2014 3:11 PM

All replies

  • Our Fiddler (actually Network Monitor) results discovered these errors in the failed attempt capture:

    Protocol   Name Description
    SMB2 SMB2:C   CREATE (0x5), Sh(RWD),   DHnQ+MxAc+QFid, File=Home4\xxx\System@#6  
    SMB2 SMB2:R  - NT Status: System - Error, Code = (52) STATUS_OBJECT_NAME_NOT_FOUND  CREATE (0x5) ,   File=Home4\xxx\System@#6 
    SMB2 SMB2:C   CREATE (0x5), Sh(RWD),   DHnQ+MxAc+QFid, File=Home4\xxx\Unavailable@#8  
    SMB2 SMB2:R  - NT Status: System -   Error, Code = (52) STATUS_OBJECT_NAME_NOT_FOUND  CREATE (0x5) ,   File=Home4\xxx\Unavailable@#8 

    Which weren't in the successful capture. (xxx is the local user's ID/home directory)

    Wednesday, April 30, 2014 8:13 PM
  • Hi Richard,

    I am trying to involve someone familiar with this topic to further look at this issue.

    Thanks,
    Daniel Yang
    Forum Support
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Daniel Yang
    TechNet Community Support

    Monday, May 5, 2014 7:45 AM
    Moderator
  • Hi Richard,

    I am not quite sure if my default lab box have c:\user profile folders, please let us know more detail regarding this.

    from your network result, seems there is a connectivity issue,

    http://msdn.microsoft.com/en-us/library/cc246324.aspx

    perhaps you can try to add a testing client machine and request the specific user to use and see the result, if should the issue not reproducible, then you may need to check the client machine proxy or WebDAV to make sure that the all the connection is ok.

    and you can also try to use other username in the client machine and reproduce the issue.

    you may also try to create a copy of the file and try to upload it, and check if should the issue also occurs.


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, May 5, 2014 11:14 AM
  • Thanks for responding.

    Win7 desktops have the users' profile folders in the c:\users folder, I think that's the default location for profile folders.  Where is yours located if not there?

    Which error code on the page you linked to is the Network error you are referring to?  I couldn't find the CREATE (0x5) error code on that page.

    The users do not have errors on machines they have not logged onto before.  Creating a new profile does not reproduce the error.

    Can you be more specific when you say "check the client machine proxy or WebDAV" as I have checked that the Webclient service is running and I don't think that's what you mean.

    Also, when other users log onto these machines, they do not have the same error.

    In some cases the upload a new copy works and sometimes it doesn't.  In one case, as I have documented above, it works one day, but does not work the next day.

    Thanks,

    -Richard.

    Monday, May 5, 2014 7:46 PM
  • Hi Richard,

    thank you for your time that you provide,

    Because Sharepoint is a server based product, so the method that sharepoint works may be different,

    sharepoint have its own user profile that is stored in database, and most probably will not effect with desktop/server user profile directly.

    we discussed with our colleagues, this issue most probably is with the locking of a file, they suggest that you to open also a thread at windows server forum or open a ticket to windows server team. the result of the issue may be vary, for example: http://support.microsoft.com/kb/899709 . Sharepoint use a shared folder to share the files, and the shared folder may have its own locking method.

    as we checked with other teams, such as windows server and desktop team, the issue may happened at windows server 2008 r2 or windows 7, as this KB describe:

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

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

    http://technet.microsoft.com/en-us/library/ff686200(WS.10).aspx

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/4b69fe06-2b72-4795-a691-aa68aa348cb1/explorer-folder-update-issues-server-2008-r2-terminal-server?forum=winservergen

    but we may suggest you to check your webdav also,

    http://www.iis.net/learn/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis

    http://www.iis.net/configreference/system.webserver/webdav


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Tuesday, May 6, 2014 5:26 AM
  • Thanks, now I understand.  The error we recorded using Network monitor (File=Home4\xxx\System@#6) may be the server-side location of the user's profile temp folder.  Do you know where that would be located?  I think it must be in the DB somewhere, as I believe we've searched the physical server drive for user folders and have not found them there.

    I'm wondering if the deletion of the user from the Site Collection would delete this "folder" location and perhaps fix the errors?  But I'm not sure what else that would break...  We could perhaps test with a non-power user, we have one that has these errors in our IT group.  That's something we have not tried yet.

    Tuesday, May 6, 2014 10:14 PM
  • Hi Richard,

    i am not quite sure if i understand you well enough,

    so i am not quite sure if there is user's profile temp folder that created by sharepoint, but i checked some articles IIS may have this.

    http://social.technet.microsoft.com/Forums/sharepoint/en-US/42f22a51-4da4-4494-9f27-21d109a63fa2/why-application-pool-identity-need-to-have-windows-profile?forum=sharepointgeneralprevious

    http://setspn.blogspot.com/2012/09/temporary-profiles-and-iis-application.html

    http://todd-carter.com/post/2010/05/03/give-your-application-pool-accounts-a-profile/

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


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, May 7, 2014 8:44 AM
  • You provided very interesting links, but none are applicable to the problem I am describing.  They are also kind of all over the place, not focusing on any particular problem or fix...  Thanks anyways!

    Monday, May 12, 2014 7:48 PM
  • The plot to this story thickens...  Now my machine displays the errors!

    One day I was working just fine, and then the next I wasn't.  I uploaded some xlsx files to a document library and was editing them just fine one afternoon, then the next morning, when I tried to open them, I got the errors.  It appears that all office documents give me problems now.

    What is different about my new errors is that I get them when I open the documents Read as well as Check Out and Edit.  Also, in my case, the error and the document appear almost simultaneously.  If I open an xlsx Read, the doc comes up as well as the No Connectivity to the Server error.  I click Retry open, then I get the https://xxx file is not checked out error and when I click OK, I get the Microsoft Excel cannot access the file xxx. there are several possible reasons error.  I click OK and I get the no Connectivity to the Server error again.  if I click Ok, the errors go away and I am in read mode.

    When I open an xlsx Check Out and Edit, the doc comes up as well as the No Connectivity to the Server error.  I click retry and the same.  I click retry, and no more errors, I have the document checked out and can edit and save.

    When I click a docx file, I do not get the No Connectivity to the server error, but instead get the https://xxx file is not checked out error.  The word doc does not come up at all.

    Now that this is happening on my machine, it will be easier to test rather than having to inconvenience our other users by commandeering their machines while troubleshooting.  I plan to do some xcopys and robocopies of my profile folder contents into a newly created profile to try to narrow down where the issue is, if it happens to be on the file system.  If it is in the registry I may be out of luck.

    I have done some network and process monitor scans, but nothing has popped out as a potential culprit yet.

    This feels a little like zombie-ism, as more and more machines are affected!


    Thursday, May 15, 2014 9:45 PM
  • Hi Richard,

    sorry for the late response, because i had some engagement with another issues. 

    anyway, please do check in the network scan, and have a try for timeout reflect.

    i am not quite sure about networking that deep, so i will try to contact and ask as i can to the network team if should they can give a shot.

    and perhaps you can terminate or restart the tcp chimney, http://support.microsoft.com/kb/951037

    http://blogs.technet.com/b/networking/archive/2008/11/14/the-effect-of-tcp-chimney-offload-on-viewing-network-traffic.aspx

    and how about your load balancer health or is there any clue that is blocking the request such as the anti virus?


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, May 16, 2014 12:30 PM
  • It took three days of dedicated troubleshooting, but I have found the cause of the errors, and a couple of fixes.  It helped tremendously that my own machine was throwing the error.  I have scheduled a couple of users to work with me to test the various fixes, to see which one works best, so the story isn't over yet.

    I had backed up my c:\users profile folder and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList registry key so I could restore my profile after I was done.  I made a copy of the profile folder and was using that for awhile, but then made another copy where I had deleted a lot of content out of it so that the copies would go faster.  Since a newly created profile did not have errors, I was trying to copy back as much of the profile as possible to make it easier for our users to get back to work.  Instead of blowing away their profile and starting from scratch (which we know worked) I wanted to narrow down what was causing the error and just skip that from the restore.  The concept was to keep as much as the users profile in tact (application settings, etc.) not just restoring their desktop and My Documents folders.

    When we first tested a few weeks ago, simply copying the folder contents didn't reproduce the error.  I then tried xcopy, but got the "can't read file" error.  Then I tried robocopy, and ran into the "junction" problem.  I went back to xcopy, and found that placing the excludes.txt file in the windows/system32 folder eliminated the error.

    So the process went as follows: 

    • Reboot and log into the machine as another user
    • Delete the profile and associated registry key
    • Reboot and log into the machine as the affected user, creating a new profile, and there is no error
    • Reboot and log in as the other user
    • xcopy the contents of the skinned-down backed-up profile to the newly created profile
    • Reboot and log in as the affected user, and the error occurs
    • Repeat the above, but add items in the excludes.txt file to see what, when eliminated, causes the error not to appear in the last step

    I eventually found that skipping the c:\users\<profile folder>\appdata\local\Microsoft\office\14.0 folder allowed the entire profile to be copied over without the error occurring.  That was strange, because we've cleaned out the cache folders before which didn't fix the issue. 

    So I went about it the opposite way, and tried to delete the 14.0 folder from the restored profile, and after reboot, the error still occurred.

    What eventually worked was deleting the 14.0 folder and copying over a 14.0 folder from a newly created profile!

    One way to do this was to:

    • Reboot and log in as another user
    • Rename the c:\users profile folder
    • Rename the appropriate [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList] registry key
    • Reboot and log in as the affected user, confirm that there is no error
    • Reboot and log in as the other user
    • Copy the C:\Users\<profile folder>\AppData\Local\microsoft\Office\14.0 folder to the other user's desktop
    • Delete new profile folder, and rename the backup to be the production folder
    • Delete the C:\Users\<profile folder>\AppData\Local\microsoft\Office\14.0 folder and then paste the 14.0 copy from the desktop
    • Reboot and log in as the affected user, confirm that there is no error

    We've tried this on a couple machines and it works.  I had to run Windows Explorer as Administrator to access the other profile's folders.

    We've also successfully copied a 14.0 folder created by one profile on one affected computer over another profile's folder on another computer, eliminating the error, so we're trying that first, as that is fewer steps.

    We may attempt to script this, but the self-help instructions are only 5 lines long:

    • Reboot and log into the affected computer with another account
    • Go to <link to location of 14.0 folder on network> and copy the 14.0 folder
    • Run Windows Explorer as Administrator
    • Go to c:\users\<profile folder>\appdata\local\microsoft\office and delete the 14.0 folder, and paste the copied 14.0 folder (trying to overwrite it makes Win7 want to merge the folders)
    • Reboot and log into your normal account, and confirm the error is gone

    I'll come back and report after we go into the field with this fix, but after the few tests, I am cautiously optimistic that this is it.


    • Edited by _Richard_D_ Tuesday, May 20, 2014 5:54 PM
    • Proposed as answer by Aries - MSFT Thursday, May 22, 2014 2:16 AM
    Tuesday, May 20, 2014 5:52 PM

  • May be a silly question - When you logged on to the server do you see a message 'Logged on as TEMP user?' a balloon pop up. Then the above solution is a definite work around not a fix.

    Regards Chen V [MCTS SharePoint 2010]

    Tuesday, May 20, 2014 8:45 PM
  • After a week of running OK, I now have issues with some xlsx files but not others.  The test file I was working on still opens up without any dialog boxes.  However, other xlsx files are giving me the "no connectivity to the server" and "https://xxx file is not checked out" errors.  Sometimes clicking try again works, other times I get the "Microsoft Excel cannot access the file http://xxx.  There are several possible reasons." error.

    I tried to overwrite the 14.0 folder while still logged in as that user, and there were files locked.  I will have to try to overwrite the 14.0 folder logged in as another user.

    Also, the fixed worked on 2 desktops but not 2 others, so this fix only has a 50% success rate.

    Update:  I logged in as another user, and overwrote the 14.0 folder.  When I tried to open the xlsx document, I got a "can not open xxx" error.  I clicked OK and then got the "Microsoft Excel cannot access the file http://xxx.  There are several possible reasons." error.  I closed excel and tried again, and then got the  "https://xxx file is not checked out" error" followed by the "Microsoft Excel cannot access the file http://xxx.  There are several possible reasons." error after I clicked OK.

    What I'll try next is logging into the computer as the other user, and opening the document in question, then making a copy of the 14.0 folder.  I'm wondering if there is something in the 14.0 folder that's based on the document.  Or perhaps it is date/time based?  The other test would be to open another document first, rather than the problem document, and see if new cache files are needed.



    • Edited by _Richard_D_ Wednesday, May 28, 2014 1:16 PM
    Tuesday, May 27, 2014 6:00 PM
  • I do not see any "logged on as TEMP user" dialog boxes, sorry.

    Do you expect that message to be displayed to the end user through the browser, or to the admin actually logged onto the server?

    Tuesday, May 27, 2014 6:02 PM
  • Hi Richard,

    if i may know, does by re-check-in/check-out may help to re-new the locking?

    or perhaps by re-installing webdav:

    http://www.iis.net/learn/install/installing-publishing-technologies/installing-and-configuring-webdav-on-iis

    i remember there is a 3rd party tool, but i havent try this to unlocked or check in/out (force)

    http://www.codeproject.com/Articles/93965/Force-SharePoint-Document-Unlocked-Checked-In


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, May 28, 2014 6:17 AM
  • Some more developments...

    Instead of network monitor scans, MS requested Fiddler results.  I was having the "no connectivity to the server" error on a particular document, so I confirmed the issue, then started Fiddler to capture the traffic.  I couldn't reproduce the issue with that document.  I closed Fiddler and was not able to get the error again on that document.  So I moved onto another document and was able to capture Fiddler results on the other document.  Using Fiddler didn't fix the error on that document, only that first one for some reason.

    Note that this is all happening within one document library.  Some xlsx documents open just fine, others throw an error, and one document gets "fixed" when opened while Fiddler is running, but not other documents.

    Later, I confirmed again that opening this particular document read only displays the no connectivity to the server" error, then went through the "replacing the 14.0 folder" process above, and now I do not get the error on that document.  What I specifically did was the following:

    • Logged in as the affected user, I deleted the second user's profile by deleting their c:\users profile folder and the associated HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList] registry key
    • I rebooted and logged in as the second user, building a brand new profile.  I opened the specific document that was displaying the error.  Remember that new profiles do not get the error.
    • I rebooted and logged in as the affected user.  Using Windows Explorer run as administrator, I copied the second user's 14.0 folder off to a common area of our network.
    • I rebooted and logged in as the second user.  Using Windows Explorer run as administrator, I deleted the affected user's 14.0 folder and then copied over the 14.0 folder that was on the common area of our network.  This gives the affected user's 14.0 folder the cached files from the second user.
    • I rebooted and logged in as the affected user. I was able to open the document which was previously displaying the error successfully. Putting the "virgin" cache files in the affected user's 14.0 folder seems to fix the issue.

    We will have to wait and see if this fix is temporary again.  I will also go back to the other users where the previous attempts didn't work and see if the "virgin cache files of the affected document" process documented above works for them.  Before, we were using 14.0 folders from my affected documents, not the affected user's documents. 

    I have a sinking suspicion that there something else working in conjunction with the 14.0 folder cache that I haven't tracked down yet that causes this problem.  That's because just deleting the affected user's 14.0 folder doesn't fix the issue, you need "virgin" cache files themselves to fix it, as well as the fact that the issue seems to come back after a period of time.

    This appears, at least in our case, to be a cache issue with Win7/IE10/Office 2010/SharePoint 2007.  Maybe I need to get smarter on how Office caching works exactly to be able to resolve this issue in our environment...  Time to do some more homework!

    Update:  This looks like it may save time by eliminating reboots.

    Update #2:  I went back and ran IE without add-ons, and the documents opened read-only without any errors.  The add-on that's causing the errors is the "SharePoint OpenDocuments Class."  Disabling just that add-on eliminates the error.  However, disabling that add-on changes the way SharePoint acts when you click on a document.  Instead of the option to open or check out, you get a different dialog asking to open or save.  If we did this as a fix, we would have to re-train everyone to select the checkout option from the dropdown list for that document, ouch.






    Tuesday, June 3, 2014 5:01 PM
  • Thanks for the reply.

    No, checking out then checking in the document does not resolve the issue.  On my machine, checking out the document throws the error.  On other computers, checking out the document is a workaround as it does not throw the error for them.

    We have not tried to re-install WebDAV on the server.  As far as I know, this is not happening in our development environment, where we would try to fix things with installs or re-installs.  But we do not use our development environment anywhere as much as we do our production environment.

    I don't think the forced check in 3rd party app would fix the "no connectivity to the server" errors, but you never know.  We normally don't install 3rd party apps, but we may get to that point eventually.

    See my latest post below, any help with the office caching process would be appreciated.  Thanks!



    Tuesday, June 3, 2014 5:11 PM
  • Hi Richard,

    for office product, i guess it will be better if you also open in our office forum thread.

    http://social.technet.microsoft.com/Forums/office/en-US/home?category=officeitpro

    please have a try to re-install the webdav first.

    as my colleague experience, once he had similar issue, then he move the content database, then solve it, at some point after investigating, the environment was corrupted.


    Regards,
    Aries
    Microsoft Online Community Support


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, June 4, 2014 8:07 AM
  • I got another error.

    This time, I opened Excel and tried to open a document using the Recent Files list.  The file was checked out in SharePoint to me.  First, I got the "no connectivity" error, but then the next error was "The file or folder name 'xyz' contains characters that are not permitted.  Enter a different name."

    When I perform the 14.0 replacement procedure above, I can open the document with no issues.

    Friday, June 6, 2014 6:15 PM
  • This is really strange.  I am getting different results opening documents when I have Fiddler running vs. when I don't have it running.

    I have IE only running and click a xlsx link and get the "no connectivity" error.  I click retry and I get the "xyz is not checked out" error.  I can do this consistently.  Then I open Fiddler and click the document link, and get the "no connectivity" error, but when I click retry, the document opens.  I close the document, and with Fiddler still running, I open the document again, and it opens without any errors!  With Fiddler running, it open consistently.  I close Fiddler and when I try to open the document again I get the "no connectivity" errors again.

    I ran both Process Monitor and Network Monitor separately and captured:

    • Running only IE, clicking the document and getting the error, then clicking retry and the document not opening
    • Opening Fiddler and clicking the document and getting the error, then clicking retry and the document opening
    • Closing the document and clicking the document, and not getting the error

    Next week I plan to go through the results. 

    Friday, June 6, 2014 7:51 PM