Category Archives: sharepoint

internet, iphone, microsoft, sharepoint, silverlight, web authoring, windows

What’s on at Mix 2010 – some surprises as Microsoft talks standards

3 Comments

Microsoft’s Mix conference is on next month – probably the company’s second most interesting conference after PDC, though this Mix looks rather better than last year’s relatively drab PDC (free laptops aside). The company has plenty to talk about, primarily around Windows Phone development – twelve sessions! – Internet Explorer 9, and Silverlight 4. Mix is meant to be a web design conference – though it has always strayed extensively into Windows-only territory – and the inclusion of Windows Phone is a bit of a stretch, but I doubt attendees will care.

It’s notable that Microsoft is making more than a nod to web standards and open source. There is a full day workshop from Molly Holzschlag on HTML5 Now: The Future of Web Markup Today, John Resig on How jQuery Makes Hard Things Simple, and Doug Schepers from the W3C with Microsoft’s Patrick Dengler on SVG: The Past, Present and Future of Vector Graphics for the Web; Christian Heilmann on Participating in the Web of Data with Open Standards; and not forgetting Miguel de Icaza on The Mono Project.

Why would Microsoft talk about such things? Arguably it is a kind of smokescreen, talking standards while busily promoting proprietary stuff like SharePoint and Silverlight. I think there is some of that; but that this new focus also reflects power shifts in the industry. In the new cloud-based era Microsoft has to compete with Google, Mozilla and others; and to make sure that its stuff works in some measure on a diversity of clients, from Android to iPhone. Note the session on Practical Strategies for Debugging Cross-Browser Display Issues.

I would not call this a conversion. I would say this is more about “Windows if we can, standards if we must”. That necessity is increasing though, and the sessions at Mix reflect that.

internet, microsoft, sharepoint, Uncategorized

SharePoint Explorer View hassles show benefits of cloud storage

3 Comments

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”.

image

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.

image

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.

microsoft, sharepoint

Importing folders to SharePoint

I’ve been working with Small Business Server 2008 recently and one of the tasks was to import an existing shared folder into SharePoint.

You would have thought that would be trivial, but it turns out it is not quite so. The normal suggestion is to open a SharePoint library in Explorer and do the import there. That’s actually not ideal. One problem is that, at least in our case, it does not work on the server though it does work on workstations. I suspect this is some arcane permission problem or feature; but doing this over the network is inefficient. Another issue is that Explorer is not smart about things like setting the date to that of the original, which can be annoying. A third problem is that some characters are allowed in document names on the file system, but not in SharePoint – such as  & { } and %. If your Explorer copy hits one of these the copy will fail.

I looked for a script-based solution, initially using PowerShell, but came across SPIEFolder instead. This is a simple C# application. Once I’d figured out that you have to run it from an elevated command prompt, it worked fine. However, it only imports into the top level of a SharePoint library. I added a target subfolder argument to SPIEFolder, and some name mangling to deal with illegal characters, and now it does what I want. I’ve not changed the default file date behaviour yet; but I think I can see how do do this if necessary: see http://msdn.microsoft.com/en-us/library/ms439259.aspx for the code.