VISTA - Can't use HTTP Web Folders (WebDav)?

[Gerry Hickman]

Hi,

Under Windows 2000 there was a feature called "Web Folders" that was
installed by default. You could use it to browse a server-extended HTTP
site as part of the Windows Shell, including copying and pasting files.

Under VISTA I can not get this to work. I can go to "Computer", then
right-click blank space and choose "Add Network Place". I can then enter
a URL, after a delay it creates the shortcut, but it doesn't actually
work, it just sits there as an empty folder. It also does not prompt me
for my NTLM authentication. I can open the exact same site from within
SharePoint Designer 2007, and it opens quickly, authenticates, and works
straight away.

I really need to get this working in the Vista Shell, as we rely heavily
on being able to do document GET and PUT to web servers.

Thanks for any help.

--
Gerry Hickman (London UK)

[Frank Lesniak]

We are having this problem as well. I am researching it now... please post if
you have a solution!

[Gerry Hickman]

Hi Walter,

Thank you for your reply and the URL to Arther's post. I can't install
Office 2003, I have to use Office 2007.

You say below that the WebDAV redirector has replaced nearly all
functionality that used to exist in WebFolders, so why am I not able to
add a "network place" pointing to my server-extended web site? I have
tried at the root and at a sub-folder level. Note that I can open any
node of this site from within SharePoint designer, so why not in Vista?

I even tried doing NET USE P: http://myserver.mydomain.com/mySubFolder/
and that said

"The Command Completed successfully"

but it didn't, because when I looked at P: it was completely empty!

[Frank Lesniak]

Gerry,

For a URL http://intranet.foo.com/stuff try:
\\intranet.foo.com\DavWWWRoot\stuff

or for a URL https://intranet.foo.com/stuff try:
\\intranet.foo.com@SSL\DavWWWRoot\stuff

Hope that helps!
-Frank

[Gerry Hickman]

Hi Frank,

Are you sure this works when you're NOT on a LAN? We need to be able to
view web folders from remote workstations. Either way, we don't have a
folder or vDir called DavWWWRoot on our web server.

[Hero-san From Japan]

I have been the trouble with WebDav and Vista. I think this is a bug of WebDav function on Windows Vista, but I've found the solution at least.
Usually, Web root access (WWW) is allowed for anonymous users, so authentication level is checked on anonymous (IUSR_CompueterName). And WebDav folder is allowed for authenticated users, so authentication level is checked on anything but anonymous.
Through my test, Windows Auth was most stable. So I recommend Windows Auth for WebDav folder. And you “must” set the same authentication level as WebDav folder for the Web root (WWW). This point is important, but sometimes unusual. May be you have to reorganize your web site, though.

Thank you.


EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com

[Hero-san From Japan]

I have been the trouble with WebDav and Vista. I think this is a bug of WebDav function on Windows Vista, but I've found the solution at least.
Usually, Web root access (WWW) is allowed for anonymous users, so authentication level is checked on anonymous (IUSR_CompueterName). And WebDav folder is allowed for authenticated users, so authentication level is checked on anything but anonymous.
Through my test, Windows Auth was most stable. So I recommend Windows Auth for WebDav folder. And you “must” set the same authentication level as WebDav folder for the Web root (WWW). This point is important, but sometimes unusual. May be you have to reorganize your web site, though.

Thank you.


EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com

[Shivani Sharma]

Gerry,

The difference in functionality that affects most of our users is that
compared to webfolders, the Vista redirector does not work equivalently when
we do not have access to the root, and when webdav is not supported at the
root. The root is the DavWWWRoot directory which is generally present by
default with IIS servers. Gerry what type of server are you using?

Could you try ensuring that the client has access to the root, and that this
supports webdav? We send an OPTIONS request to the root generally and if that
fails the redirector does not continue.

Another thing to try is that the user has read access to all the resources
higher up than the one you are accessing. So eg if you are accessig
\\server\share1\share try enabling read access to \\server\DavWWWRoot and
\\server\share1.

Please let me know how the above workaround work for you.

Thanks