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

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?

Answer 1

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.