Several months ago, I decided that a rebuild of my primary MOSS environment here at home was in order. My farm consisted of a couple of Windows Server 2003 R2 VMs (one WFE, one app server) that were backed by a non-virtualized SQL Server. I wanted to free up some cycles on my Hyper-V boxes, and I had an “open physical box” … so, I elected to rebuild my farm on a single, non-virtualized box running (the then newly released) Windows Server 2008 R2.
The rebuild went relatively smoothly, and bringing my content databases over from the old farm posed no particular problems. Everything was good.
The Situation
Fast forward to just a few weeks ago.
One of the site collections in my farm is used to store and share pictures that we take of our kids. The site collection is, in effect, a huge multimedia repository …
… and allow me a moment to address the concerns of the savvy architects and administrators out there. I do understand SharePoint BLOB (binary large object) storage and the implications (and potential effects) that large multimedia libraries can have on scalability. I wouldn’t recommend what I’m doing to most clients – at least not until remote BLOB storage (RBS) gets here with SharePoint 2010. Remember, though, that my wife and I are just two people – not a company of hundreds or thousands. The benefits of centralized, tagged, searchable, nicely presented content outweigh scalability and performance concerns for us.
Back to the pictures site. I was getting set to upload a batch of pictures, so I did what I always do: I went into the Upload menu of the target pictures library in the site collection and selected Upload Multiple Pictures as shown on the right. For those who happen to have Microsoft Office 2007 installed (as I do), this action normally results in the Microsoft Office Picture Manager getting launched as shown below.
From within the Microsoft Office Picture Manager, uploading pictures is simply a matter of navigating to the folder containing the pictures, selecting the ones that are to be pushed into SharePoint, and pressing the Upload and Close button. From there, the application itself takes care of rounding up the pictures that have been selected and getting them into the picture library within SharePoint. SharePoint pops up a page that provides a handy “Go back to …” link that can then be used to navigate back to the library for viewing and working with the newly uploaded pictures.
Upon selecting the Upload Multiple Pictures menu item, SharePoint navigated to the infopage.aspx page shown above. I waited, and waited … but the Microsoft Office Picture Manager never launched. I hit my browser’s back button, and tried the operation again. Same result: no Picture Manager.
Trouble In River City
Picture Manager’s failure to launch was obviously a concern, and I wanted to know why I was encountering problems … but more than anything, I simply wanted to get my pictures uploaded and tagged. My wife had been snapping pictures of our kids left and right, and I had 131 JPEG files waiting for me to do something.
I figured that there was more than one way to skin a cat, so I initiated my backup plan: Explorer View. If you aren’t familiar with SharePoint’s Explorer View, then you need not look any further than the name to understand what it is and how it operates. By opening the Actions menu of a library (such as a Document Library or Picture Library) and selecting the Open with Windows Explorer menu item as shown on the right, a Windows Explorer window is opened to the library. The contents of the library can then be examined and manipulated using a file system paradigm – even though SharePoint libraries are not based in (or housed in) any physical file system.
The mechanisms through which the Explorer View are prepared, delivered, and rendered are really quite impressive from a technical perspective. I’m not going to go into the details, but if you want to learn more about them, I highly recommend a whitepaper that was authored by Steve Sheppard. Steve is an escalation engineer with Microsoft who I’ve worked with in the past, and his knowledge and attention to detail are second to none – and those qualities really come through in the whitepaper.
Unfortunately for me, though, my attempts to open the picture library in Explorer View also led nowhere. Simply put, nothing happened. I tried the Open with Windows Explorer option several times, and I was greeted with no action, error, or visible sign that anything was going on.
SharePoint and WebDAV
I was 0 for 2 on my attempts to get at the picture library for uploading. I wasn’t sure what was going on, but I was pretty sure that WebDAV (Web Distributed Authoring and Versioning) was mixed-up in the behavior I was seeing. WebDAV is implemented by SharePoint and typically employed to provide the Explorer View operations it supports. I was under the impression that the Microsoft Office Picture Manager leveraged WebDAV to provide some or all of its upload capabilities, too.
After a few moments of consideration, the notion that WebDAV might be involved wasn’t a tremendous mental leap. In rebuilding my farm on Windows Server 2008 R2, I had moved from Internet Information Services (IIS) version 6 (in Windows Server 2003 R2) to IIS7. WebDAV is different in IIS7 versus previous versions … I just hadn’t heard about SharePoint WebDAV-based functions operating any differently.
Playing a Client-Side Tune
My gut instincts regarding WebDAV hardly qualified as “objective troubleshooting information,” so I fired-up Fiddler2 to get a look at what was happening between my web browser and the rebuilt SharePoint farm. When I attempted to execute an Open with Windows Explorer against the picture library, I was greeted with a bunch of HTTP 405 errors.
405 ?!?!
To be completely honest, I’d never actually seen an HTTP 405 status code before. It was obviously an error (since it was in the 400-series), but beyond that, I wasn’t sure. A couple of minutes of digging through the W3C’s status code definitions, though, revealed that a 405 status code is returned whenever a requested method or verb isn’t supported.
I dug a little deeper and compared the request headers my browser had sent with the response headers I’d received from SharePoint. Doing that spelled-out the problem pretty clearly.
Here’s an example of one of the HTTP headers that was sent:
[sourcecode language=”text”]
PROPFIND /pictures/twins3/2009-12-07_no.3 HTTP/1.1
[/sourcecode]
… and here’s the relevant portion of the response that the SharePoint server sent back:
[sourcecode language=”text”]
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS, TRACE
[/sourcecode]
PROPFIND was the method that my browser was passing to SharePoint, and the request was failing because the server didn’t include the PROPFIND verb in its list of supported methods as stated in the Allow: portion of the response. PROPFIND was further evidence that WebDAV was in the mix, too, given its limited usage scenarios (and since the bulk of browser web requests employ either the GET or POST verb).
So what was going on? The operations I was attempting had worked without issue under II6 and Windows Server 2003 R2, and I was pretty confident that I hadn’t seen any issues with other Windows Server 2008 (R2 and non-R2) farms running IIS7. I’d either botched something on my farm rebuild or run into an esoteric problem of some sort; experience (and common sense) pointed to the former.
Doing Some Legwork
I turned to the Internet to see if anyone else had encountered HTTP 405 errors with SharePoint and WebDAV. Though I quickly found a number of posts, questions, and other information that seemed related to my situation, none of it really described my particular scenario or what I was seeing.
After some additional searching, I eventually came across a discussion on the MSDN forums that revolved around whether or not WebDAV should be enabled within IIS for servers that serve-up SharePoint content. The back and forth was a bit disjointed, but my relevant take-away was that enabling WebDAV within IIS7 seemed to cause problems for SharePoint.
I decided to have a look at the server housing my rebuilt farm to see if I had enabled the WebDAV Publishing role service. I didn’t think I had, but I needed to check. I opened up the Server Manager applet and had a look at Role Services that were enabled for the Web Server (IIS). The results are shown in the image on right; apparently, I had enabled WebDAV Publishing. My guess is that I did it because I thought it would be a good idea, but it was starting to look like a pretty bad idea all around.
The Test
I was tempted to simply remove the WebDAV Publishing role service and cross my fingers, but instead of messing with my live “production” farm, I decided to play it safe and study the effects of enabling and disabling WebDAV Publishing in a controlled environment. I fired up a VM that more-or-less matched my production box (Windows Server 2008 R2, 64-bit, same Windows and SharePoint patch levels) to play around.
When I fired-up the VM, a quick check of the enabled role services for IIS showed that WebDAV Publishing was not enabled – further proof that I got a bit overzealous in enabling role services on my rebuilt farm. I quickly went into the VM’s SharePoint Central Administration site and created a new web application (http://spsdev:18480). Within the web application, I created a team site called Sample Team Site. Within that team site, I then created a picture library called Sample Picture Library for testing.
When It Works (without the WebDAV Publishing Role Service)
I fired up Fiddler2 in the VM, opened Internet Explorer 8, navigated to the Sample Picture Library, and attempted to execute an Open with Windows Explorer operation. Windows Explorer opened right up, so I knew that things were working as they should within the VM. The pertinent capture for the exchange between Internet Explorer and SharePoint (from Fiddler2) appears below.
Reviewing the dialog between client and server, there appeared to be two distinct “stages” in this sequence. The first stage was an HTTP request that was made to the root of the site collection using the OPTIONS method, and the entire HTTP request looked like this:
[sourcecode language=”text”]
OPTIONS / HTTP/1.1
Cookie: MSOWebPartPage_AnonymousAccessCookie=18480
User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7600
translate: f
Connection: Keep-Alive
Host: spdev:18480
[/sourcecode]
In response to the request, the SharePoint server passed back an HTTP 200 status that looked similar to the block that appears below. Note the permitted methods/verbs (as Allow:) that the server said it would accept, and that the PROPFIND verb appeared within the list:
[sourcecode language=”text”]
HTTP/1.1 200 OK
Cache-Control: private,max-age=0
Allow: GET, POST, OPTIONS, HEAD, MKCOL, PUT, PROPFIND, PROPPATCH, DELETE, MOVE, COPY, GETLIB, LOCK, UNLOCK
Content-Length: 0
Accept-Ranges: none
Server: Microsoft-IIS/7.5
MS-Author-Via: MS-FP/4.0,DAV
X-MSDAVEXT: 1
DocumentManagementServer: Properties Schema;Source Control;Version History;
DAV: 1,2
Exires: Sun, 06 Dec 2009 21:13:27 GMT
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated=18480; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6510
Date: Mon, 21 Dec 2009 21:13:27 GMT
[/sourcecode]
After this initial request and associated response, all subsequent requests (“stage 2”) were made using the PROPFIND verb and have a structure that was similar to the following:
[sourcecode language=”text”]
PROPFIND /Sample%20Picture%20Library HTTP/1.1
User-Agent: Microsoft-WebDAV-MiniRedir/6.1.7600
Depth: 0
translate: f
Connection: Keep-Alive
Content-Length: 0
Host: spdev:18480
Cookie: MSOWebPartPage_AnonymousAccessCookie=18480; WSS_KeepSessionAuthenticated=18480
[/sourcecode]
Each of the requests returned a 207 HTTP status (WebDAV multi-status response) and some WebDAV data within an XML document (slightly modified for readability).
[sourcecode language=”text”]
HTTP/1.1 207 MULTI-STATUS
Cache-Control: no-cache
Content-Length: 1132
Content-Type: text/xml
Server: Microsoft-IIS/7.5
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated=18480; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6510
Date: Mon, 21 Dec 2009 21:13:27 GMT
<?xml version="1.0" encoding="utf-8" ?><D:multistatus xmlns:D="DAV:" xmlns:Office="urn:schemas-microsoft-com:office:office" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:Z="urn:schemas-microsoft-com:">
<D:response><D:href>http://spdev:18480/Sample Picture Library</D:href><D:propstat>
…
</D:propstat>
</D:response>
</D:multistatus>
[/sourcecode]
It was these PROPFIND requests (or rather, the 207 responses to the PROPFIND requests) that gave the client-side WebClient (directed by Internet Explorer) the information it needed to determine what was in the picture library, operations that were supported by the library, etc.
When It Doesn’t Work (i.e., WebDAV Publishing Enabled)
When the WebDAV Publishing role service was enabled within IIS7, the very same request (to open the picture library in Explorer View) yielded a very different series of exchanges (again, captured within Fiddler2):
The initial OPTIONS request returned an HTTP 200 status that was identical to the one previously shown, and it even included the PROPFIND verb amongst its list of accepted methods:
[sourcecode language=”text”]
HTTP/1.1 200 OK
Cache-Control: private,max-age=0
Allow: GET, POST, OPTIONS, HEAD, MKCOL, PUT, PROPFIND, PROPPATCH, DELETE, MOVE, COPY, GETLIB, LOCK, UNLOCK
Content-Length: 0
Accept-Ranges: none
Server: Microsoft-IIS/7.5
MS-Author-Via: MS-FP/4.0,DAV
X-MSDAVEXT: 1
DocumentManagementServer: Properties Schema;Source Control;Version History;
DAV: 1,2
Exires: Sun, 06 Dec 2009 22:04:31 GMT
Public-Extension: http://schemas.microsoft.com/repl-2
Set-Cookie: WSS_KeepSessionAuthenticated=18480; path=/
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6510
Date: Mon, 21 Dec 2009 22:04:31 GMT
[/sourcecode]
Even though the PROPFIND verb was supposedly permitted, though, subsequent requests resulted in an HTTP 405 status and failure:
[sourcecode language=”text”]
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS, TRACE
Server: Microsoft-IIS/7.5
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6510
Date: Mon, 21 Dec 2009 22:04:31 GMT
Content-Length: 0
[/sourcecode]
Unfortunately, these behind-the-scenes failures didn’t seem to generate any noticeable error or message in client browsers. While testing (locally) in the VM environment, I was at least prompted to authenticate and eventually shown a form of “unsupported” error message. While connecting (remotely) to my production environment, though, the failure was silent. Only Fiddler2 told me what was really occurring.
The Solution
The solution to this issue, it seems, is to ensure that the WebDAV Publishing role service is not installed on WFEs serving up SharePoint content in Windows Server 2008 / IIS7 environments. The mechanism by which SharePoint 2007 handles WebDAV requests is still something of a mystery to me, but it doesn’t appear to involve the IIS7-based WebDAV Publishing role service at all.
Steve Sheppard’s troubleshooting whitepaper (introduced earlier) mentions that enabling or disabling the WebDAV functionality supplied by IIS6 (under Windows Server 2003) has no appreciable effect on SharePoint operation. Steve even mentions that SharePoint’s internal WebDAV implementation is provided by an ISAPI filter that is housed in Stsfilt.dll. Though this was true in WSSv2 and SharePoint Portal Server 2003 (the platforms addressed by Steve’s whitepaper), it’s no longer the case with SharePoint 2007 (WSSv3 and MOSS 2007). The OPTIONS and PROPFIND verbs are mapped to the Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler type in SharePoint web.config files (see below) – Stsfilt.dll library doesn’t even appear anywhere within the file system of MOSS servers (or at least in mine).
Regardless of how it is implemented, the fact that the two verbs of interest (OPTIONS and PROPFIND) are mapped to a SharePoint type indicates that WebDAV functionality is still handled privately within SharePoint for its own purposes. When the WebDAV Publishing role is enabled in IIS7, IIS7 takes over (or at least takes precedence for) PROPFIND requests … and that’s where things appear to break.
To Sum Up
After toggling the WebDAV Publishing role service on and off a couple of times in my VM, I became convinced that my production environment would start behaving the way I wanted it to if I simply disabled IIS7’s WebDAV Publishing functionality. I uninstalled the WebDAV Publishing role service, and both Microsoft Office Picture Manager and Explorer View started behaving again.
I also made a note to myself to avoid installing role services I thought I might need before I actually needed them :-)
Additional Reading and References
- Blog Post: Todd Klindt, “Installing Remote Blob Store (RBS) on SharePoint 2010
- Whitepaper: Understanding and Troubleshooting the SharePoint Explorer View
- Blog: Steve Sheppard
- Microsoft TechNet: About WebDAV
- IIS.NET: WebDAV Extension
- Tool: Fiddler2
- W3C: HTTP/1.1 Status Code Definitions
- MSDN: Client Request Using PROPFIND
- TechNet Forums: IIS WebDAV service required for SharePoint webdav?
- Site: HTTP Extensions for Distributed Authoring
Damn it man, you solved my problem!
I literally yelled out “OH F&*K IT WORKED!” at the top of my lungs after fidgeting around with this and trying various silly registry fixes for hours. HOURS!
Thanks for taking the time to share your feedback, Charles. I really appreciate it and am glad that the post helped out!
You are genious, man! Thanx a lot!!! Now I want to share this feature with all of SharePoint administrators around the world, I think almost everyone will face this problem when SharePoint server OS will be upgraded!
Thank you, thank you, you’ve saved a lot of my time!
I agree, Sabbah. This little “hiccup” caught me off guard, and I think you’re right that others will run into it as well. At least SharePoint Server 2010 will come with a prerequisites installer that should alleviate configuration errors like this. Thanks for taking the time to leave a comment; I appreciate it!
Sean, there is another problem with SharePoint (or maybe with Windows Explorer) while using explorer view and WebDAV. When you open document library that contains media files such as pictures, video, audio or for example AutoCAD files (dwg) in explorer view, traffic analyzer shows that not only files list, but also content of all files in library downloads. And if you just rename files to unknown format (for example “ddd”) everything goes right and we get files list without content of files. This feature is very annoying when you store AutoCAD files in the document library because file size can reach 5 Mb and exploring such library is equivalent to downloading 200-300 Mb of data. Have you faced such problem?
Sabbah: I haven’t witnessed the behavior you describe. If I were to try and troubleshoot it or find the source of the behavior, I’d probably start on the client side and look for any services or Explorer extensions, IE add-ons, etc. that are associated with the file type (.dwg) you mentioned. The key here (for me) is that the behavior changes when you change the extension. Does AutoCAD integrate with Windows Explorer or perhaps have additional services that comb through the files in the background to extract metadata, do differntial comparisons, build thumbnails, or something like that?
My experience in describing the HTTP 405 issue is limited to picture libraries. Picture libraries are just glorified document libraries, and I haven’t seen any background attempts by Explorer to pull all of the files down. If I use an application that can interact with the library to do a slideshow of all the pictures, though, then that app may process all files in the library to build properly-sized images.
Parting thought: if you have the tools, you might consider comparing AutoCAD’s interactions with a standard file share against those you’re seeing with SharePoint. I suspect that AutoCAD exhibits similar behavior for standard file shares (with .dwg files) as you’re seeing with SharePoint. Just a guess, though.
Good luck!
Big thanks!
This solved my problem. Not a very easy to find soulution.
Great explanation too :)
After countless hours working on this exact issue, I found this article, what a revelation! To get webdav to work…. remove it!!! LOL It fixed my problem, only three more MOSS issues for me to solve.
Jon, Mark: I appreciate your feedback! Glad to hear that my experience helped you in some way.
Thanks so much, you explained your troubleshooting very clearly so I didn’t have to question your method or test your process myself
You’re welcome, Ken!
Two weeks spent trying to figure out why Explorer View wasn’t working. Then, I read your post. THANK YOU!
Two weeks — ouch. I’m glad that things are working now, Massimo. Thanks for the comment!
You are beautiful.
Can I have your children?
Helped me out big time on an issue I had traced to PROPFIND, but didn’t get any further.
Thanks for the in depth detail/discovery/explanation Really Really brilliant.
I have two children and think I’ll stop there, but you’re very welcome, Crashing Bore. :-) Glad I was able to help!
Hello all together.
May be you can help me with my little WebDAV Problem ?
We don’t get any further :( and your researches seem to be very good and conclusive. I got here by searching answers for my problem ( May be deactivating this webclient “thingy” in iis7 is also my problem? )
Let me explain the Problem very fast :
We have a Sharepoint Server 2010 and want to edit/create/move/etc files via WebDAV from Sharepoint. As you click in a library of folder “Open in Explorer” it opens the folder in the Explorer and everything works fine – EXCEPT : Moving Files.
If you want to move a file windows tells me that there could be a security issue with these files. You cna click “ok” or “cancel” but both have the same effect : Nothing.
I’ve searched for hours now but we didn’t get any useful help anywhere yet.
In Internet Explorer : We already have these sites in Intranet Zones , We already checked that Intranetsettings are getting searched automatically , We turned off the Automatic Search of properties in the LAN Properties , We also set theAuthForwardServerList entry (added the sites)
Perhaps this information will help too :
Domain: domainA.com
SharePoint: http://www.domainB.com
——–
So everything just works fine except “moving files/folders” in the explorer view of a sharepoint list/library.
Hope anyone can help us soon because we can’t find any further help for now and searched almost the whole internet ;)
Thanks in advance !
ps.: This problem only occurs on Windows 7 Machines !
DEDE: if you’re seeing a security pop-up when you attempt to move files from a workstation into SharePoint, then the workstation thinks you’re trying to cross a security zone. I read the steps you took in order to address this in IE, but there still appears to be a cross-zone issue. I don’t know that crossing zones is the source of your difficulties, but it’s certainly worth investigating further.
Near the beginning of your comment, you mentioned that you had deactivated the WebClient “thingy.” From the workstation perspective, the WebClient service needs to be running if you wish to connect to WebDAV-exposed endpoints. If you disable the WebClient service on Win7, you won’t be able to use Explorer View with SharePoint. Go into the Services MMC snap-in (Start -> Administrative Tools -> Services) on the workstation and ensure that “WebClient” isn’t disabled. It’s commonly set to start manually, and the OS will start it as needed if it detects that a connection to a WebDAV store is needed.
These are just some general thoughts and observations. I realize that you’ve spent quite a bit of time troubleshooting already, so what I’d suggest you do is fire-up Fiddler and take a look at the exchange that takes place between a client workstation and your SharePoint server when you attempt to move files. Of particular interest will be any 400 and 500 series HTTP responses, as these indicate errors and internal server problems respectively. If you’re able to at least browse the virtual file structure on the server, then some form of communication is taking place (and working). You need to figure out which parts aren’t.
If Fiddler doesn’t give you everything you need and you are comfortable with networking and protocols, consider using WireShark (http://www.wireshark.org/download.html) to dig even deeper. I’d be surprised if you had to dive to this level, but if your problems are caused by something lower in the stack, WireShark is a great (albeit tedious) way to ferret out the issues.
When you get it figured out, please share your results … and good luck!
Sorry may be i explained it wrong.
WebDAV is turned on and i try to move files inside the sharepoint folder which gets opened in explorer view. So nothing in to it just files in there. So the files stay in the original area but not in the same folder.
If you copy or cut and paste them (ctrl + x ; ctrl + v) there won’t pop-up any security message !
It’s really very weird and we don’t get this failure/issue.
So thanks in advance for the help you already gave me or tried giving me ;)
Sorry again for my bad first explanation and my bad english (I’m german).
Hope I could explain it udnerstandable now and anyone can help me.
If we release our sharepoint server to the user they won’t use it if they get this failure notices just when they try moving files.
It’s really awkward and disgusting for a typical user or someone who gets angry/mad very fast ;)
Sorry but thanks again and thanks for upcoming solutions ;)
Sorry may be i explained it wrong.
WebDAV is turned on and i try to move files inside the sharepoint folder which gets opened in explorer view. So nothing in to it just files in there. So the files stay in the original area but not in the same folder.
If you copy or cut and paste them (ctrl + x ; ctrl + v) there won’t pop-up any security message !
It’s really very weird and we don’t get this failure/issue.
So thanks in advance for the help you already gave me or tried giving me ;)
Sorry again for my bad first explanation and my bad english (I’m german).
Hope I could explain it udnerstandable now and anyone can help me.
If we release our sharepoint server to the user they won’t use it if they get this failure notices just when they try moving files.
It’s really awkward and disgusting for a typical user or someone who gets angry/mad very fast ;)
Sorry but thanks again and thanks for upcoming solutions ;)
DEDE,
If you’ve verified that the WebDAV Publishing Service is *off* on the server and that the WebClient service is installed (and not disabled) on the client, I’d fall back to Fiddler or WireShark to see what’s actually happening on the wire. Without seeing errors on the server or client, the only real point of visibility you’re going to have into what’s happening is the HTTP conversation that’s taking place between the client and server.
Good luck!
Sean,
You take credit as being the first site where I formally give credit for helping me fix a problem. After 7 hours troublshooting this, your thorough explanation resolved the problem I was having. THANK YOU. On behalf of the legions of ingrates like me that never give credit to guys like you that invest in proper explanations. A thousand times, thank you!
You’re very welcome, Ignacio … and thanks for the chuckle :-)
Thank you for great post. It solved my problem!
My pleasure, Anton — glad it solved your problem.
Sean, hello again!
And finally here is my contribution in “around the world” sharing this experience:
http://myknowledgeshare.wordpress.com/2010/12/31/%D0%BD%D0%B5%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5-%D0%B0%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D1%8B-%D0%BF%D0%B5%D1%80%D0%B5%D1%85%D0%BE%D0%B4%D0%B0-sharepoint-2007-%D0%BD%D0%B0-%D0%BF%D0%BB%D0%B0%D1%82/
You are great! Thanks again! :)
Thanks for the link, Sabbah … and you’re certainly welcome. You’ve been battling WebDAV problems for quite a while it seems. I ran your page through a translation routine (I don’t speak Russian), and although I wasn’t able to process everything you wrote, it sounds like you’ve made a lot of progress. Congratulations!
Thank you, Sean, you really inspire me!
Hi Sean. I have a similar issue in SharePoint 2010.
I have a required field in a library and when i try to move an office file through explorer view I got a invalid parameter error.
I just got that error if I try to move files that are already inside Sharepoint, with the required field filled. If I move an office file from my computer it works (and the file turns checked out waiting for the required field fullfillment)
In some computers, i get a permission error instead the parameter error, although I’m sure it’s not a permission issue (as I can paste fresh office files or non-office files)
I used Fiddler to check the traffic and I got 401 erros. Pretty sure it’s a WebDAV issue…
Do you how to solve this?
Thx
Jack: I read your comment several times, and I’m not sure what’s going on. You may have more than one issue in-play. If you’re getting 401 errors, I’d probably start by looking at the IIS logs to gain some additional insight into where they’re occurring. As far as moving files that are already in SharePoint — I don’t know what to suggest. I wish you the best of luck with it, though; sorry I can’t be of more assistance.
Thanks for your patience posting a lot of details and answering the questions. It’s almost unnecessary to mention that it helped (me) my customer too.
You’re welcome, Andreas, and thanks for the feedback!
Thanks, It was very helpful to us ,
fixed issue related to third party application integration with Microsoft sharepoint SharePoint .
If I can pile on years later, thanks – this is a great write up and helped me as I’m troubleshooting a related issue: windows explorer view opens fine, and I can “read” okay, but when I try to paste a file I see a 500 error from the server. I can see in wireshark this is in response to an HTTP PUT. It also happens in response to a DELETE. I don’t have this problem with any other of several farms I manage. Any idea how I can figure out what might be happening?
Andy,
Thanks for the feedback! As far as troubleshooting goes, I’d probably try a couple of different things. I’d look at the series of interactions (via Fiddler) that you’re trying to carry out on a “good” farm and then on the “trouble” farm to see if there are any differences. Are there any network or security appliances present in the trouble farm that aren’t in the other environments? Application-layer filtering? Firewalls? Also, the ability to read the content (but not alter it) feels like it could have a permissions component to it – either in SharePoint or somewhere along the line (e.g., a Firewall application filter). What filters/devices/components, if any, are in-line between you and the SharePoint WFE? What does the web traffic go through to get to the farm?
Those are just some “off the top of my head” thoughts/questions. For what they’re worth :-)
Thanks so much for the response. This post and some forum interaction led me to use Wireshark and find the server was responding with a 500, then used Trace Logging for Failed Requests, and was able to trace the 500 to an HTTP module that I had installed in IIS a while back. Once I removed the module, everything worked fine. Not sure why the module was stepping in though – I think it was a video converter that should have only executed if videos were uploaded via PUT, not just any file. Looked like a handler was defined to narrow the scope to certain file types, but maybe the installer didn’t do it right or something. Not sure if it was Windows Media Services or some 3rd party thing I was messing around with. Shouldn’t be doing that on a SP server, I must have been desperate for IIS on some dev box, any dev box… Anyway, thanks again. p.s. Love “your work” with CBS Sports ;) http://www.cbsnews.com/2100-500609_162-34664.html
My suggestions obviously took the hardware/network approach, but it looks like the problem was in the software path being traversed rather than the hardware. Regardless, I’m glad to hear that you nailed it down, Andy! Definitely not the first time that HTTP modules have “bumped heads” with one another and with HTTP handlers.
As far as the sports thing: I can only chuckle. :-) I sometimes joke that sportscasting is my “side gig” (which, of course, it isn’t). I’ve even had TSA ask me (going through a checkpoint) if I was the same guy. Sportscasting tends to be a little more visible than SharePoint – imagine that :-)
THANK YOU! Seriously I have been trolling the internet for days trying to figure out my problem! I couldn’t open a SharePoint library in explorer view, but more troubling, I couldn’t open office docs in edit mode. I added the verbs “OPTIONS” and “PROPFIND” in IIS7 for my SP App and it worked! Thank you for posting this!
You’re welcome, Paulette! I’m glad the article helped :-)
Hi Sean, Thank you! for a great post, I am new to SharePoint. I reached your website while searching for a issue I was facing at work. we have built a macro which runs on a Wintel box and connects to a sharepoint unc path and extracts data from excel workbooks and creates a dat file. we have mapped the sharepoint unc path on the wintel box and use that drive to connect to the path in the excel macro. Wierd thing we are noticing is when we run the program directly from the server it works fine but when we use a mainframe scheduler and the scheduler runs the same program its gets a http 405 error, which says method not allowed.