Hi This error may have been reported in the forum before. If so I apologise for asking again, but I just can't find any reference to it (or any solution).This is using IE7, Vista Business 64bit, Word 2007To summerise: (step by step)1. We log into Sharepoint (from remote locations)2. We locate the list containing items with attached documents3. Selecting the document gives the "harmful..." message4. Microsoft Word loads up with a certificate warning (which we accept)5. We then are prompted to log in a second time.6. It then prompts with a certificate ("Select Certificate") dialog. (We select OK 3 times)7. Word opens the document in Reader view8. Document reports "Server document" at the top of the screen next to the "Edit Document" option.9. Choose "Edit Document"10. and we get "Unknown Error trying to lock file".The same sequence of events using Windows XP has no problems.Switching back to XP is not an option.Various threads scattered through the internet talk of various solutions from port numbers to running Word in XP sp2 compatible mode. None of these solve the problem. Can someone give me some indication of what is going wrong here. I'm not completely up to speed with sharepoint, but if you ask the questions, I'll dig out the answers.Best regardsRobert

Is the site in the Trusted and/or Intranet security zones in IE7 ?WSS FAQ sites: WSS 2.0: http://wssv2faq.mindsharp.com WSS 3.0 and MOSS 2007: http://wssv3faq.mindsharp.com Total list of WSS 3.0 and MOSS 2007 Books (including foreign language titles) http://wss.asaris.de/sites/walsh/Lists/WSSv3%20FAQ/V%20Books.aspx

Hi MikeThe site was neither in Intranet or Trusted sites. I added it to Trusted sites, but same error occurs.ThanksRobert

Hi, We have confirmed a issue *while opening a document in Read Only and clicking the "Edit Document" it throws "unknown error trying to lock file"* and it is fixed in hotfix described in KB954571 (http://support.microsoft.com/kb/954571) The scenario of your issue is very similar like the issue fixed in KB954571. I suggest you to prepare a test environment and patch the hotfix. If your issue is not resolved by the hotfix, please let me know more information about your environment to do further research: 1. The operation system of the SharePoint Server. 2. Your SharePoint farm topology. 3. Have you enabled Web Client Service? Is the issue resolved by disable the Web Client Service? 4. Have you enabled IP V6? Is the issue resolved by disable the IP V6? 5. Is the issue happened in entire farm, a specific web application, site collection or site? Let me know the result if possible. -lambertPosting is provided "AS IS" with no warranties, and confers no rights.

Thanks Lambert. I will see if we can apply this hotfix today and will report back with the results and more information if required.

Hi Lambert (and everyone else)Unfortunately the problem still occurs after applying the hotfix.1 - Windows 2003 Server - Standard2 - Single server deployment3 - Web Client enabled4 - Doesn't work with IPv6 enabled or disabled5 - Documents fail in two of the sites that I know of. I don't know of any part of the install that does work.I hope this is the information you are seeking.Robert

Hi GuysDoes anyone else have any suggestions? It has gone rather worryingly quiet.We have discovered that the problem does not exist in Windows7 (beta) either, so that would suggest it's a Vista thing. Is there any way we can trace the process to see if we can capture where the problem lies.RegardsRobert

This is about status quo with regards to sharepoint bugs. I have the same issue and it basically makes the entire shared documents feature unusable for clients. The fact that the integration is so poorly executed really makes for a great sales pitch but god awful user experience.

Hi YMI feel your pain. I would have hoped for a solution before now, but it appears no-one knows whats going on. Yes, it's frustrating when you can see the potential of what it can deliver, but some silly little bug/feature/switch knocks the whole implementation on its head. We have had to resort to the good old method of emailing documents and then managing the changes from differentdepartments manually.We're looking at raising an incident report with Microsoft to see if we can get this thing moving along. If I get an answer (that works), then I'll post it here.RegardsRobert

We are in the middle of implementing SP and this is a key piece of functionality that needs to work.We want to use this feature to email a link to a document in SP rather than sending physical docs around, which can then be edited online (or checked out) so that changes are versioned. The Vista problem is a real problem for us. When we follow the link, open document and then click on edit document it then gave us the error message. We've scoured the internet for solution but like everyone has suggested MS has gone quiet. However I do think we have cracked it (subject to more testing): Firstly on the machine with Vista we: 1. Installed"Software Update for Web Folders (KB907306)": http://www.microsoft.com/downloads/details.aspx?familyid=17C36612-632E-4C04-9382-987622ED1D64&displaylang=en 2. Disabled IP6 on TCP/IP protocol 3. Changed properties of Winword.exe to run in compatibility mode - Windows XP (Service Pack 2) We tested this and it worked! How we rejoiced! We could send a link to a doc in a library and it would open and "edit document" button would allow us to click it without an error, amend and save the document!! However, that was short lived - one of my colleagues, using the same link, could open the document but the "edit document" button did not appear and the document opened in read only, so when he tried to amend and save it, it asked him for a new save location . Gutted!! Soon after, it started happening on my machine so we knew it wasn't a viable solution. Until.............I found last night, i found another MS KB http://support.microsoft.com/kb/870853. I followed the instructions added a new registry key and low and behold it works again. One slight caveat - when the document opened it did not give display the "edit option" button. However, the document was not in read-only and any direct changes and saves - saved directly in to the library and added a version. I also found that the "check out document" option in the Word menu was also back. A word of warning...we have only tested this on two Vista machines so far so I'm not holding my breath! Please let me know if anyone has success doing steps 1 to 3 and then adding the registry key.

Thanks for the info Dave.I will try this out today and let you know how successful it is. Fingers crossed it solves the issue.RegardsRobert

Did the solution ever work?

It has definitely worked for us. I am not sure if the registry key alone will do it (and therefore not do steps 1 - 3) but we will be testing this shortly - will let you know outcome.CheersDave

These settings worked for me, but only after the last bit of the compatibility mode. I am running this on Windows 2008 server (OK, almost Vista).However, I have serious reservations deploying this sequence of dubious settings to a large number of clients without an acknowledgement fromMicrosoft that these steps are required on Vista / Server 2008 to do thetrivial thing of opening an Office file from a SharePoint server. On the other hand, I can imagine that the solution is somewhat embarrasing to Microsoft.And also.... are we going to need the XP virtual machine on Windows 7 to open an office file from sharepoint? Mm, interesting setup, bravo for those who manage to sell this.

We were having the same trouble and then, lo and behold, I found your post. Lifesaver! Works a treat. We didn't need to perform step 2 as we had disabled that early on. All our users are running Vista sp1, using Office 2007. We are on MOSS 2007. It's funny, because not all users were experiencing this error which made it all the more frustrating to fix. Thanks again for your post.

Process monitor showed an access writes error when writing back to the SharePoint URL. I noticed that basic authentication was in use for making the connection to the URL. After a little research, I found the following article: http://support.microsoft.com/kb/841215 Evidently the default setting for the WebClient service is to use Basic authentication for SSL shares only. The connection is not an SSL connection so I changed the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters DWORD Value: BasicAuthLevel to “2” which enables basic authentication for Non-SSL shares. Rebooted the system and tried it again and it works.

I ran into the message "Unknown Error trying to lock file" on a laptop running Windows 7, IE8, Office 2007 and connecting to MOSS 2007. When the customer clicks on the Word document it comes up as normal. Selecting the "Edit" button throws the error. I also note that on this machine, the error window appears in the SE of the SE quadrant of the screen rather than somewhere near the center. Selecting "Edit in Microsoft Office Word" from the drop down menu does not cause the error. Using this method, the document can be edited and saved as normal. The customer is fine with this solution.

same error here...running Windows 7, IE8, Office 2007 and connecting to MOSS 2003

We also encounter this with the user on Win7, using SharePoint that came with TFS2010 and office 2007. Any ideas?

Use www.deletelongfile.com to unlock the file efficiently