While the WebDav interface within SharePoint libraries provides a very useful function of opening the library and the whole Site collection structure through the Windows Explorer application, it might be more detrimental to your SharePoint solution then you think. Let me explain one business scenario where you will run into problems when using this;
Let's say your users want to edit PDF files from task view generated by a workflow that provides them only a link to the originating file. You know the outcome... the browser will open the file within it's self without the ability for users to save the document after editing into the source location (which is the SP library in this case), the doc will have to be saved onto their local HD and then re-uploaded into the library. What happens to the original document's metadata??? Yep, it's lost, the document is now a new entity within the library. Or the PDF file will be opened in Adobe Acrobat, but again without the ability to save this file into the source location.
In this case it seems that Adobe is fighting with Microsoft.
I've went around this restriction by opening the link to the PDF using WebDav interface (you can find the description here). You might think this is an answer to your question, if you make sure that all your desktops are OK for this.
After implementing this solution and reading a lot of different forum questions and comments on the usage of (citing) "Open in Windows Explorer" functionality, I've come to realization that people do not understand components involved into this functionality. OK, let's talk about one of the major issues that people are trying to troubleshoot: "why for some users this works fine... the explorer opens quickly and they can manage the documents. For other users it takes up to 5 minutes before the explorer view opens. During this time the browser becomes completely unresponsive."
First of all, it is not an issue on your SharePoint environment but it’s a problem on the desktop
Two words - "Web Folders Client" :-)
The webfolder functionality is implemented by means of MSDAIPP.DLL this is the DLL that is responsible for WebDav interface functionality. It usually resides inside "C:\Program Files\Common Files\SYSTEM\OLE DB" or it's language dependant equivalent (such as "C:\Programme\Gemeinsame Dateien\SYSTEM\OLE DB" for German Windows versions). To find the DLL version, select the file in Explorer, choose "Properties" from the right-click context menu, then select the "Version" tab.
Here is the link to the posting that explains it all. http://greenbytes.de/tech/webdav/webfolder-client-list.html
Do not expect all your desktops to have the same "working" version of Web Folders.
Another one: "when MS Office document is edited users have trouble saving the document back to the library"... well, there are several variations to the errors they are getting, but I'll not list them all, simply because I have not seen ALL of them.
In this case it is directly related to the user's rights to the desktop in relation to the account the user is logged into the SharePoint with (presuming that user logged into the desktop is not the account used to log into SharePoint). If the user does not have sufficient rights to this desktop, than FORGET IT unless you add the user account to the local desktop group. While this is not such a common scenario, because of the ways most of the networks are setup, but the case I'm describing here is when a number of users is relatively small within the company and IT decides that a user account expected to be used at this particular workstation should be added manually into local desktop group.
Before you start using WebDav interface make a number of considerations:
1. Are your desktop images are "STANDARD" (and do not use the definition of "standard image" loosely)
2. Are you ready to maintain the web folders component individually on all desktops if they vary in applications and versions of apps. that are being ran locally.
If your users are local admins on their desktops, may god help you then. J
Enjoy
5 comments:
Thanks for the very timely post on SharePoint and WebDav. I have just set up a WebDav test for a client and experiencing some of the things you talk about in your post. It has now given me reason to pause.
Drew
Isn't "Web Folders Client" 3 words?
Three words for you - "So what" :-)
I also do work for a law firm. We deal with PDF's a lot and have been fighting this since day one.
We have seen some bad behavior with web folders too, where you can open a file from a browser view but not any kind of explorer (unless you have the Webclient service turned on). The crawler apparently also cannot open these files as they are not indexed. This does not happen to Office files, just PDF's, eml's etc.
It just happens sometimes - not sure when. Maybe when stuff got renamed or moved??
I haven't figured it out yet but I am going to try this: http://support.microsoft.com/kb/943337.
Thanks for this article. We are having a terrible time mapping a network drive to a Sharepoint Document Library. We can establish a "Network Place" but not a mapped drive. Interestingly though, on the Sharepoint server itself (W2003 SP2) we navigate to a Document Library and try to open the library in Explorer View...we get prompted to authenticate and it accepts nothing and eventually gives us a network path was not found error. Not sure if this is SPoint or the server itself.
Post a Comment