I have been struggling with a particular problem at my current contract. One where windows 7 machines could connect to a webdav path to sharepoint sites and libraries, but older windows XP machines could not.
Originally I thought it might be something I configured on the server (like permissive versus strict), but it wasn't anything to do with that. You see alot of posts on server admins turning on the IIS webdav, but that wasn't it either.
For this particular environment, it just so turned out that StoragePoint was installed on the very same web app that we were trying to connect too, but it was simple chance that it was installed on this particular web app and thusly it wasn't StoragePoint that was causing the problem (but I won't old my breath that it won't cause issues later, there Librarian product has so many bugs it isn't funny).
So what was it? I was able to track down the issue using WireShark. I would start the trace and then follow the HTTP calls (which on the working mapped drive was PROPFINDs, and the broken web app, OPTIONS calls). It turns out that once you have a successful OPTIONS response, windows will cache the information in your registry. After that, all you will see are PROPFINDs. This is documented here:
After watching the TCP stream, I noticed the last call to the OPTIONS after all the authentication was a 404 error. That's when I was able to make some nice google searches and stumbled upon this blog by sudeepg:
He found that you have to have a root site collection in order to respond to the OPTIONS http request. Sure enough, after adding the root site collection (in my dev environment which doens't need a root site collection), the WEBDAV calls started working.
Talk about a shot in the head…its the simple things…
Follow me on twitter: @givenscj
Check out the previous blog post: