Many of us want access to our documents from anywhere these days, and if you are still storing documents on a Windows server then remote access to documents usually means either VPN or SharePoint. VPN is heavy on bandwidth and not great for security, so SharePoint seems the obvious solution.

SharePoint is a mixed bag of course, but once it is up and running the browser user interface seems reliable as a means of getting at your documents over the internet. That said, it is inconvenient to run up the browser and navigate to a web site whenever you want a document. A user recently highlighted another issue. Their company uses a web application that frequently requires documents to be uploaded. This is straightforward if the document is on a local hard drive or network share, but not if it is in SharePoint. The workaround is to save the document out of SharePoint to the local drive, then upload it.

Fortunately there is another option. SharePoint Explorer View lets you access documents through Windows Explorer; you can even map SharePoint as a network drive. Now you can browse documents without a web browser, and upload directly to a web application.

Sounds great; and when it works, it is great. Troubleshooting though is a world of pain. If you have looked into this, you will know that there are really two Explorer Views, one using Internet Explorer and ancient FrontPage protocols, and the other using WebDav and Explorer. It’s the second of these that you most likely want. However, achieving this is notoriously troublesome, raising uninformative messages such as “Your client does not support opening this list with Windows Explorer", or from the command line System Error 67, or System Error 53 “The network path was not found”.

Another common complaint is incessant login dialogs.

I discovered a few useful resources.

This white paper on Understanding and Troubleshooting the SharePoint Explorer View is essential reading.

From this you will discover that if you are using Windows XP, the WebDav SharePoint Explorer view will not work over SSL or on any port other than 80. You are stuck with the FrontPage view, which is less useful. Apparently Microsoft has no intention of fixing this. Upgrade to Vista or Windows 7.

In addition, many XP and even Vista users find this update essential before anything starts working. It is necessary on Windows 2003 since the web client is not installed by default. It does not apply to Windows 7 though.

A good resource on the repeated login issue is here. It can be tamed.

Windows 7 is better, though I experienced an odd issue. One Windows 7 machine cheerfully opened the Explorer view to a remote site on port 444. I could engage Explorer View from the SharePoint web site, or from Network in Explorer, and it just worked.

On another machine, same network, also Windows 7, same web client settings, I could not get it working. I was on the point of giving up when I happened on the right incantation from a command prompt:

net use s: https://your.domain.name:444\shared%20documents /user:domain\username password

In this example S is the drive letter for a mapped drive, your.domain.name is the URL for SharePoint, 444 is the port number, shared documents is the folder name. For some reason this worked instantly.

Well, SharePoint is an option. Before leaving this subject though, I would like to mention Gladinet, a third-party utility which is able to mount a variety of cloud storage providers as network drives, including Amazon S3, Google Docs, Windows Live SkyDrive, and in the latest version Windows Azure.  It works on XP, Vista, Windows 7 and Windows 2003, comes in 32-bit and 64-bit editions, and worked immediately in my quick test. The ability to mount drives in Explorer itself, as opposed to an Explorer-like application, makes a big difference in usability.

Gladinet does not support SharePoint, sadly. Still, before you roll out SharePoint it is worth considering that something like an Amazon S3 account requires no CALs (though third-party clients like Gladinet may do), is maintained by a cloud provider rather than on your premises, is not hooked in any way to Windows clients, and might be a lot less hassle to deploy.

I do also understand the attraction of SharePoint, if you don’t or can’t trust the cloud, and like the way it integrates with Active Directory or its other clever features such as versioning or workflow management. What I don’t get is why Microsoft makes basic features like Explorer View so hard to get working.

Finally, this aspect of SharePoint should get better in Office 2010 and SharePoint 2010, which includes SharePoint Workspace 2010. This will synchronize with SharePoint 2010 document lists, giving you an offline copy you can access in Explorer. Agnes Molnar has a summary with screenshots.