Thus, SharePoint needs a common way to store these times. It does this using UTC time (Coordinated Universal Time). This is, near enough, GMT, and it’s also called Zulu by pilots, the military, and pedants. 0700Z (the Z represents ‘Zulu’ as in ISO8601) is the same time whether you’re in London or Sydney - just in Sydney, 0700 Zulu is actually in the evening.

Now, you don’t need to worry about this, ‘cos SharePoint is smart enough to translate your local time to UTC when you set a date and time, and to translate it back again when displaying the date to you. Thus, 0700 in New York would be stored as 1100Z in the SharePoint database, and then when you looked at that document’s properties, it would be converted back to 0700. If you looked at the document in, say, London, it would convert 1100Z to 1200. (Well, all this is as happens today - summer/winter time makes things really hairy).

So where am I going with this? I have an application where you fill in a date and time, and submit it to SharePoint. When I get the dates back, though, the time is out by an hour. I’m in the UK and it’s summertime, so my timezone is actually UTC+1; therefore, time conversions seem likely to be the issue.

I fill in the date to set on a document in SharePoint via my application.

We’re going to use the web services to update this. This page implies I need to submit a UTC time - indeed, most of the information I’ve found shows submitting a UTC. So, I do my UTC time conversion - watching in Visual Studio, you can see the adjustment by an hour in to UTC time:

Okay, that’s correct. That time is submitted via the Lists.UpdateListItems method - but looking in SharePoint, the time appears as an hour too early.

So, I broke out my trusty SharePoint Manager - and it shows the time as an hour too early too:

Note that by formatting the date with a Z at the end it’s saying that this time is UTC. However, I just didn’t believe it - SharePoint isn’t showing me UTC time, it’s showing Local (UTC+1 remember), so they can’t both read 22:59. To check then, I decided to look in the database. (I wasn’t changing anything, so I figured this would be okay).

Right, now that is the UTC time - and it’s been adjusted for my time zone twice.

Therefore, even though when I submit the time to the Web Service I’m using UTC time, and saying that I’m using UTC time as I’m formatting the datetime with Z, the date time is being converted to UTC a second time. When I then view the time, it’s being converted back once.

And SharePoint Manager is just wrong; it’s displaying the local time, not the UTC one.

Still with me?

So, I decided to look into the UpdateListItems call - is there a way of specifying what the timezone being used is? In other words, can I force the web service to recognise that I’m using UTC time?

Looking through the MSDN documentation, all the examples seem to use UTC time. Eventually, I found information on the Field element description:

StorageTZ
Specifies how date/time values are stored. When StorageTZ is set to UTC, the date/time is handled as Coordinated Universal Time (UTC). To denote that a date/time value refers to “abstract” time, meaning that the date/time is stored in the database as entered by the user without conversion or storage of the local time zone, omit the StorageTZ attribute.

If that doesn’t make any sense to you, well, it doesn’t make sense to me either. From that I don’t know what I need to set StorageTZ to - do I need to say that I’m using UTC ‘cos I’m using UTC, or do I have to omit it ‘cos I don’t want any conversion? I have no idea from that documentation.

So, what happens if I don’t convert my datetime to UTC before submitting it over the Web Service? Well, it works - BUT I still have to format the date time as yyyy-MM-ddTHH:mm:ssZ ! If you format the time as just yyyy-MM-ddTHH:mm:ss then the Web Service returns an exception. So I have to declare my datetime as being UTC even when it isn’t and SharePoint isn’t treating it as one!

I’d be quite infuriated now then! I’ve just wasted a half day ‘cos some moron doesn’t get the idea of Universal Time, and didn’t wonder what that Z on the end of the string meant…

In this example, I’m going to insert an image into my document first as an embedded object, then as a linked object. The image itself has been uploaded to an images Library.

The image itself has to be in a library or on a webserver so that the converted page can refer to it by a URL.

In Word 2007 I go to the Insert Picture button:

This opens a file selection dialog. I entered the URL to my images library, and got the following view:

I’m sure that there is a way to add things like the images library to the ‘My SharePoint Sites’ section of the dialog, but I don’t know how to do that off the top of my head. Anyway, I did a normal insert of the image into my document:

Fine. I saved it, checked it in, and converted it. The result I got was:

No image - which is what we expected with embedded images. So next I repeated the process, but this time on the save dialog instead of just hitting Insert, I chose Link to File :

I saved this, checked it in, converted it, and got the output of:

Fantastic! The image is still being referred to after conversion. Now, who happens if I download a copy of the source document, and try and open it up offline. Say I’m a salesman on the road or something, what would I see?

Ah. The document itself has no image. Damn. Okay, lets try again, but this time choose the Insert and Link option:

Saved, converted, etc., and I get a working page:

And now if I open up the document offline I see:

Hurrah! A working document and a working page after conversion. It’s just a pain that it’s more complex that users are used to - they will make mistakes. It’s a real shame that the document conversion service can’t extract the images and put them into an images library for you.

(Side note - this was me at a friends party trying to use helium balloons to float a beer can. It took a surprising number of balloons)

Note 1 - I guess he inherited from SPNavigationProvider or SPXmlContentMapProvider as SPSiteMapProvider and SPContentMapProvider are both sealed.

Note 2 - He doesn’t mention caching. I kind of wonder how that would work.

Still, interesting stuff - might have a look sometime as part of my ‘one breadcrumb only’ campaign.

Bamboo’s List Roll-up Web Part is the most feature rich, but a bit tricky - certainly it’s a bit too complex if you’re wanting to allow users to set up their own roll-up. The use of CAML is also a big no-no for allowing basic users to set up their own. It’s a shame; it really is let down by this complexity, although it’s still simpler than using SharePoint Designer.

Using the Dataview Web Part directly has the same problem as Bamboo’s List Roll-up - complexity. It also requires SharePoint Designer. It’s harder to generate the Data View Web Part, but to be honest (given that you can do the same things as Bamboo’s List Roll-up web part) I suspect that most organisations would be fairly willing to live with that.

For me, it’s main problem is that it doesn’t pick up new lists automatically; you have to modify the data view web part to add the new lists. For that reason, I think you can only use this approach when you have a fixed set of lists to aggregate over.

The Content Query Web Part is pretty good, and there is a reason that it’s so often discussed in SharePoint Solutions. The web part itself is fairly straight forward to use - but using custom metadata in the display is a bit too complicated. Again, I think this solution is out of the range of the ability of typical users. I don’t like the lack of pagination options, either.

Lightning Conductor is the only one of the web parts that struck me as being simple enough that a non-technical person would be able to set up and use for content roll-up. It had many of the more complex features that we’ve seen (e.g. using XSL for formatting the results), but you didn’t have to use them, and the user interface exposes things that seem missing from the CQWP - like the ability to select the fields you want in the display! I’ve got to say, this is my favourite of the solutions I looked at.

So which one should you use? Well, as I said, it depends. The main factors involved seem to be:

• Are you wanting to aggregate across site collections?
• Are the source lists fixed, or will they be changing?
• Will the roll up be configured by technical or non-technical staff?

I guess you weigh those up and take your choice.

Edit: One questions I was asked was if it’d be difficult to write your own. Well, there’s no reason why you couldn’t; with the SPSiteDataQuery it wouldn’t even be hard. Programming around the configuration would take longer, and as we’ve seen, this can make a big difference to the usability of your solution. What I would observe is that both the 3rd party solutions were pretty cheap; it’d be diffult to write your own for as small a cost.

| Introduction | Content Query Web Part | Data View Web Part |

| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |

This web part is a little strange; indeed, I’m not sure how to describe it. As I understand it, basically it’s a web part to generate a data-view web part, and add it to the page. Sound strange? Well, it is a little bit. Let’s have a look:

As you can see, this is a big web part on page. It’s user interface is much more complicated than the Lightning Conductor. I couldn’t help but notice that to do filtering by metadata column values appears to require writing CAML - which really is a bit much for many users.

This web part then generates an output Dataview Web Part:

(In that example, it’s only aggregating from one list - ‘cos I forgot that gave my lists different names, and then told the view to roll-up by list name).

So, it’s advantages:

• Can consolidate across Multiple Site Collections (which isn’t possible through the Out-of-box options)
• Can consolidate a single site collection, a site and it’s subsites or a specific list.
• Can also consolidate sibling sites - which isn’t something I’ve seen elsewhere.
• Can filter by list type
• Can filter by content type or meta data fields
• Can Group results
• Has user definable sorting
• Has Pagination of results
• Fine control over caching

And it’s disadvantages:

• More complex to use
• More complex user interface
• Probably requires writing CAML
• Costs money (though I think is still a bargain compared to developer time)
• Could be a tough sell to customers (”But SharePoint already has the Content Query Web Part“)

In short: Probably the most powerful and feature rich of the web parts, but not as easy to use as some of the others. Really, more of a developer tool than a user tool.

So, on to the conclusions…

| Introduction | Content Query Web Part | Data View Web Part |

| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |

Okay, so it looks similar to the data view web part (apart from the ‘trial version’ message!), but it has the same sorts of roll up options to the Content Query web part. One of the things that impressed me about this web part was actually the configuration screens in SharePoint:

The main settings form is a well laid out, clear (if somewhat long) form. It just looks right.

The other significant administration screen with it is selection what columns you want to show, and their order, and any sorting or grouping.

Now that is much easier than displaying extra columns in the Content Query Web Part (or the Data View Web Part, come to that. Again, quite a long form, but clear, and trust me, easier than writing XSL

I did have a couple of little problems with it, though. Firstly, for some reason it didn’t seem to want to show me my Project or Project Status columns in the ‘Filters’ section, so I couldn’t restrict my view by these fields. I may have configured something wrongly that this wasn’t possible.

The other thing that struck me was that while the web part does have column headings that the user can click to sort by, there is no icon to tell them what column they’re sorting by already, or whether it is sorting ascending or descending.

So, it’s advantages:

• Good user interface. I could imagine non-technical people being able to set up their own views.
• Can consolidate across Multiple Site Collections (which isn’t possible through the Out-of-box options)
• Can consolidate a single site collection, a site and it’s subsites or a specific list.
• Can filter by list type
• Can filter by content type or meta data fields (though I had a problem with them)
• Can Group results
• Has user definable sorting (but needs a little arrow to show which column is being sorted, and in what order)
• Has Pagination of results.
• Can define view by XSL if you really want to.

It’s disadvantages:

• Costs money (though I think is still a bargain compared to developer time)
• Could be a tough sell to customers (”But SharePoint already has the Content Query Web Part“)

In short: It’s what everyone really wished that the Content Query Web Part actually was.

So, I’m quite impressed by the Lightning Conductor Web Part, but what of the other commercial option I’m reviewing - Bamboo’s List Roll-Up Web Part?

| Introduction | Content Query Web Part | Data View Web Part |

| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |

Here’s an example of a Data View Web Part showing the same data as our examples from the Content Query Web Part

It’s advantages are:

• Can show a view with user defined filtering, grouping and sorting.
• Has pagination of results
• Showing extra columns of data is easy to add
• Can filter the results by Content Type, or Metadata field values
• Cheap (Out-of-box)
• Designing the view is easy

It’s disadvantages are:

• Requires SharePoint Designer - and therefore a suitably technical user
• Can only query and merge results from a fixed set of sites - there is no ‘All Site collection’ or ‘This site and subsites option’
• Limited by site collection boundary

In Short: Flexible in the views it presents, but it’s actual ability to roll up data is limited and could require constant maintenance. Requires someone fairly technical with SharePoint Designer to set view up.

| Introduction | Content Query Web Part | Data View Web Part |

| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |

Here’s an example of one rollup up the ‘Project Documents’ type:

It’s advantages are:

• Can select from an entire Site Collection, a Site and it’s Sub-Sites, or from a List
• Can select by List type
• Can filter the results by Content Type, or Metadata field values
• Can be configured to do Sorting and Grouping
• Can display custom data - but this is a little complex

It’s disadvantages are:

• Customising the view is possible, but tricky.The view has to be defined in XSL, and the Content Query Web part configured correctly to get the data you want to display.
• No pagination of results - it’s just truncated.
• The user can’t select the results order, or add his own filter.
• You can’t query across Site collections.

All in all, I’d say that defining the styles for what you want to display puts this into more a ‘development’ task, which isn’t ideal if you’re trying to push administration out to your users a bit more.

Also, a major issue as far as I’m concerned is the lack of pagination. You can limit the number of items shown, but without an link to the next ‘page’ of items.

Here’s an example of a Content Query Web Part showing some custom data (highlighted in yellow):

In short: Cheap, and available, but has that ‘just a bit awkward’ feel to setting it up, and lacks some of the features you’re likely to want. Often will require someone a bit technical for customisation.

| Introduction | Content Query Web Part | Data View Web Part |

| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |

What is content roll-up? Simply, it’s about pulling data from different locations in SharePoint into a single view, and presenting it to the user in a consolidated form. This is a pretty common task in SharePoint. For example, think of things like roll-up of News items from the sites in your site collection. That’s actually built into the Collaboration site template:

I’ve bracketed both the web parts being used with red and blue - otherwise it’s not clear that there are two web parts doing content roll-up here - one for the most recent headline, and another to show a list of recent News items.

There are lots of other examples of where this is useful - consolidation of tasks for a user is another common requirement, or rolling-up all the documents of one type or another - such as expenses, etc..

Anyway, over the next week or so I’ll examine some of the solutions to content roll-up that I’ve seen. It’s not meant to be an exhaustive list - there are quite a lot of solutions to content roll-up around, and you can write your own - but why reinvent the wheel?

| Introduction | Content Query Web Part | Data View Web Part |

| Lightning Conductor Web Part | Bamboo’s List Roll-Up Web Part | Conclusions |

1. Add extra columns to the selected data (CommonViewFields) by exporting, editing and importing the web. part.
2. Add a new display format to the ItemsStyle.xsl file.

Okay, so I did this, and one of my extra columns of data I wanted to present was shown (’Project’), but the
other (’Project Status’) wasn’t. What was going on?

Well, I sort of figured it was the space in the name - SharePoint does a funny encoding of spaces to _x0020_ which is annoying, and often causes errors. Anyway, I opened up SharePoint Manager to check what the field was called internally - and sure enough, it was called Project_x0020_Status. Fair enough, I’d got the internal name right, but using that still didn’t work.

I decided in the end to have a look at what the fields the CQWP was retrieving. But how to? I could define my own XSL, but I didn’t know what use to get the list of fields. Well, I found the answer on Bart Callaerts web site (actually, there is another good ‘how to customise the CQWP article). Anyway, I’m shamelessly plagiarising just in case that page in unavailable.

His idea was to define an Item Style to show all the columns of the retrieved items. The code for this is:

<xsl:template name="ViewFields" match="Row[@Style='ViewFields']” mode=”itemstyle”>
<xsl:for-each select=”@*”>
P: <xsl:value-of select=”name()” />
</xsl:for-each>
</xsl:template>

And you can download a copy here - copying and pasting from this page can screw up so of the characters.

Anyway, I used this view to see my items:

Looking through that list of fields, I saw that the name of my column (according to the CQWP) is now Project_x005F_x0020_Status. That’s a bit strange, and I don’t know why that’s happened. I guess that Michael Hoffer’s suggestion (don’t use spaces in the names when you create the columns - add them later) is a good one - I reckon it’d have saved me this trouble!

Anyway, this suggestion worked nicely. I’ve highlighted my data in yellow:

Like him, I hear the terms ‘Workflow’ and ‘BPM’ used interchangably, but he is right - workflow is a technology that can be used to support a business process. It’s not the only technology, though, and it isn’t always appropriate to use. Too often I see workflows with some horrible process in them for dealing a with a variety of edge cases where actually all the customer needs is to record that this is an exception to their normal process, and that it was sent to Joe Bloggs to deal with.

I’m a big fan of allowing human intelligence a role in the process. But I digress…

The point I was leading around to is that you don’t have to use just workflow to support a business process. You can actually achieve quite a lot with views, and you can provide some of the automation with just event handlers. Or, if you’re brave, you can use workflow - but Keep It Simple, Stupid! A lot of the example workflow projects are pretty simple, and short - keeping yours the same seems a safer plan.

Also, I do think keeping workflows short and simple, and having a number of them supporting a business process is generally a good idea.

We did a project just after SharePoint RTM was released where I was supposed to be using workflow. I’d been trying to build this particular workflow since the Beta 1 release, but there were still a lot of issues in the TRM version, such as:

• reading in InfoPath data from repeating sections
• populating data into certain InfoPath form fields
• Delay activities never returning
• not being able to get Modification forms working

…and a whole list of other minor niggles and complaints. The Delay activities thing was the killer for us though - they were essential to the process we were trying to support. In the end, we had to abandon workflow, but instead we used views and event handlers. With the correct views, users could still see what items were ‘late’. Event Receivers let us move items between different states. Certain users could take control of items and change statuses by hand, which mean that it dealt with exceptions well. It wasn’t as elegant as what we’d wanted to do in Workflow (which wasn’t that complicated), but it did work, and it didn’t take long to build. (That was important; the project ended up being 4 months late, which I thought was actually pretty good).

Actually, I built a similar system years ago. Most organisations, when you first go to see them, insist that they know all their business processes, and have them all well documented. Later, it becomes clear that their documentation is wrong, or incomplete (”Oh, yes, actually sometimes we have to do Y instead of X“), or contradictory - but this doesn’t matter as the people in this process are doing something different anyway.

However, we had this one particular customer who sat down with us and said “I don’t think we know our processes at all, although we think we do.” (Smart move). He went on to explain that they had a number of things that had to be done, and that as long as they were completed, nobody would really mind what order they were in. Oh, and sometimes they’d want to add other tasks that needed to be done in that specific case. We suggested a sort of ‘Task List’ for each item, with different templates of tasks for different processes.
He concurred - and it was one of the best solutions I’d written. On time, within budget, no problems.

So I guess the lessons there were:

• Be sure you really know your process
• Only automate things that actually really benefit from it
• Keep automation short, so your process is a bit more loose
• Leave human intelligence in the loop to deal with exceptions. Don’t try to design in ever case - exceptions are… well, exceptional!

Bob Mixon’s note about ‘Agility’ is also worth considering when designing your solution - try to design in a way that allows future changes to your process, ‘cos it will change. Short automation and loose coupling really helps that.

Just my thoughts

The solution is to copy both CDs to a single directory on the hard disc of the machine, and run the installer from there.

Unfortunately, for some reason my virtual machine won’t let me do that directly - it complains about copying one of the files from the DVD - but I can share a folder on the host, and copy the installation files into the VM via that folder.

Once you’ve copied the files on, though, the ‘pre-filled’ licence key isn’t there anymore. You can get the key by starting installing from the DVD, writing it down, and then using it when you install from the hard disc.

It’s crazy the work-arounds you have to go through sometimes

Unfortunately, it also had Visual Studio 2008 too. I didn’t think this would be a problem, though, and so I when I opened the project on it for the first time and it asked me to upgrade the project to 2008, I was happy do. I didn’t think there’d be a problem.

Well, during development, there wasn’t. Whenever I went to test my MSI installer, though, I started to have problems. Installation kept failing and I kept getting the error:

Error 1937. An error occurred during the installation of assembly ‘Extensibility,Version=”7.0.3300.0″,Culture=”neutral”,PublicKeyToken=”B03F5F7F11D50A3A”,ProcessorArchitecture=”MSIL”‘. The signature or catalog could not be verified or is not valid. HRESULT: 0×80131045. assembly interface: IAssemblyCacheItem, function: Commit, component: {8C306A7E-AE8E-14F0-4168-C43060985CF4}

This was surprising. Extensibility.dll isn’t one of mine - it’s a Microsoft one that should’ve been in the Primary Interop Assemblies for Office. Anyway, it’s not one of mine, it hadn’t changed, and it was signed correctly. So what gives?

My first investigations using the error code ‘0×80131045′ suggested that the problem lay with the operating system, and offered some pretty terrifying solutions. I tried them anyway - they didn’t work.

Next, I wondered if the old version of the MSI installer (compiled on Visual Studio 2005) would work on my dev machine - it did. I began to wonder if I my new MSI installer would work on another machine - it didn’t. The old version still worked, and my new MSI wouldn’t work on either machine. I was comfortable with the conclusion that the problem wasn’t the OS.

Well, after that I consided the Installer project in Visual Studio. This is the thing that makes the MSI with my DLL in it. Perhaps upgrading the project for Visual Studio 2008 had screwed something up? Well, it sure looked the same, and looking into the actual code showed only minor differences. In fact, other than declaring themselves to be for different versions of Visual Studio, the two projects were identical. So I don’t think that the upgrade screwed anything up.

This left me in an unenviable position. I couldn’t see anything wrong with the installer for the latest version of my code - but it didn’t work. The error being reported back was clearly wrong - the assembly I was installing was correctly signed.

The only conclusion that I could come to was that packaging the MSI in Visual Studio 2008 was producing a different result than Visual Studio 2005, and that my only option was to merge my code back into the old VS2005 version of the project.

Fortunately, WinMerge is great.

Anyway, I did this. I could now compile my new code on my old VS2005 Development system, and then try installing on my MSI on my VS2008 system. It worked perfectly! Sadly, I’ve now got a fair effort to go to to build a new stable development environment.

So the upshot of all this is that although they might look nearly identical, and in fact might be nearly identical, there are clearly other differences in the output MSI installers for Visual Studio 2005 and Visual Studio 2008. If you get the same sort of error as me, consider using Visual Studio 2005.

The intermittent nature of the problem suggests a timing issue - something is under race conditions. Saving the same file to the same library would sometimes work, and sometimes wouldn’t. Naturally, I couldn’t reproduce the problem on my test system.

Looking in the logs from my application, I found that when the metadata wasn’t set, there was an exception being recorded:

Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes. Error Code: 0×81020015

Interesting. How could my changes conflict with those made by another user? I’ve only just created the item!

Well, there is a way, actually. The customer has an event receiver on all of their Document Libraries, and it runs on the ItemAdded event. Could this be the issue? I decided to write my own ItemEventReceiver class. On the ItemAdded event, I just put in code to make the thread sleep for 3 seconds. I deployed it, and started by doing a normal upload through the SharePoint web UI.

It worked normally, although after I clicked the upload there was a delay of about 3 seconds before I was shown the Edit Item Properties page - which I’d kind of half expected (otherwise, what if the ItemEventReceiver was setting some of those properties?)

Next, I tried using my application to upload a file and set its metadata - and it failed. I got a response back in about a second - that’s for uploading the same file, and setting it’s metadata. Looking in the logs, I could see the same error as is happening on the customer’s system. Clearly, my call to Lists.UpdateListItems was being run at the same time as the ItemEventReceiver - and the event receiver had the item ‘locked’. I deactivated my event receiver - and my test system started to work just fine again.

The reason that the problem is intermittent on the customer’s system is, I think, that sometimes the event receiver has finished before I try to add the metadata - and sometimes it hasn’t. There is a race between the event receiver finishing and setting the metadata starting.

Not sure what to do about it though. I guess I can just keep retrying until it works. It is interesting that the user interface waits for the event receiver to finish whereas the Web services don’t

My app communicates with SharePoint via the Web Services, and tracking through my code showed me that the problem was coming from the Webs.GetWebCollection call. As this problem was only affecting some users - notably, those who’d have limited rights, I wondered if this was a permission issue. It seemed strange though; users could still see the sub-sites, either in the navigation menus or in the ‘View all site content’ page.

Digging further into permissions, I found that users with ‘Read’ rights got errors with my application. I decided to set up a test system.

I created a site collection with three ‘levels’ of sites (Gateway, Branch, Subsite). For my test, I would use the Gateway site, the Branch A site inside it, and the Subsite 1 site inside that. Thus, they looked like:

Gateway > Branch A > Subsite 1

I then created four users and gave them different memberships on the different sites:

As usual, Members have Contribute rights and Visitors have Read rights

I tried logging into SharePoint through the web browser as the different users to see what I could see in the navigation. Alice, Bob and Chan all saw the same:

All these users could see and navigate to Gateway, Branch A and Subsite 1 without error, although sites where they were only visitors they couldn’t make any changes, like creating new documents, etc..

The user Dina was a little different though. With no rights on Branch A, she couldn’t see it in the navigation:

She could, however, still go to Subsite 1 via it’s URL.

Note that the breadcrumb shows Branch A, but clicking on it gives:

So far, so good. The browser interface behaves pretty much as one would expect.

Next, I wrote a console app that would, as each of the users, try the Web.GetWebCollection web service call on each of those sites. The results I got were:

Looking through the results, a pattern becomes pretty clear. Only sites where the user has Contribute rights work correctly, otherwise the result is an error. In other words, users with Read rights aren’t able to call the Web.GetWebCollection service, even though they can see sub-sites of the site in the web browser.

Strange.

So what permission is doing this? Looking at Read and Contribute perms, I noticed the Browse Directories permission:

Hmm. All I can find on google says:

Enumerate files and folders in a Web site using an interface such as SharePoint Designer or Web-based Distributed Authoring and Versioning (Web DAV).

Well, it looks like something related to web services. I mean, SharePoint Designer must use the web services, right? Well, one way to find out - I added that right to the ‘Read’ permission level, and ran my application again:

This looks better - all calls have been successful, apart from Dina’s request of Branch A, which is also correct - she has no rights on that site!

So has this affected what users can see and do in the web interface?

Well, no, would be the short answer.

So what is the Browse Directories permission? Well, damned if I know. All I can find on Google is the same text as above. I gather that it does somehow affect Spell-checking, but that still doesn’t tell me what it does.

After a fair bit of testing, I can’t see any other effects.

Unfortunately, I wanted to show some of out Sales and pre-sales guys some of the ’standard’ customisations to search that I was working on last month. I could do screenshots and Powerpoint - but it’s slower to create, and not as easy to see as a video.

Well, I’d heard of Camtasia, and it transpires they’ve a 30 day free, so I thought I’d give it a go. Well, it is very good. Clearly, there is a lot to the program - much more than I’ve used - but I was able to get a video recorded showing my stuff in an hour. Not bad when the film itself is 20 minutes long!

It has some really neat features, too, like zooming and panning to where you’ve clicked, so that if you’ve only got a small video resolution you can still see the important bits on an activity at 100% zoom.

What I would say is that the documentation and introductory videos do seem to gently suggest that planning what you’re going to demonstrate might be useful - and they’re right. I’d say from my short experience that planning what you’re going to do is essential. As is a decent mike - my seemed to struggle a bit.

Anyway, would I pay $300 for it? Well, for the company, yes, it’s a snap. It isn’t something that a ‘home’ user is likely to pay that for, but for business quality screen recordings, I wouldn’t look any further.

This seemed a bit weird, so I went to see what he’d done wrong. I looked in Central admin - it showed his site collection as existing, but going to it, I got a 404 too. So I created my own - and after it was create, if I went to it, it 404′d too.

(The examples below use the managed path ‘demos’ - I took the screenshot when I was reproducing the problem, having apparently fixed it for the ’sites’ managed path already. Trust me, this happens just the same if the items involved are using the text ’sites’).

If you look at the screenshot you’ll see that I’m trying to go to the site collection ‘vaa’ inside the ‘demos’ managed path.

Well, at this point I tried using some other managed paths to create a site collection, and they worked fine - no 404s when you try going to them just after creation. I began to wonder if it was something about this path, so I opened IIS Manager to see if anything was going on.

Inside my virtual directory for my web app, I found a ’sites’ folder (or ‘demos’ in this screenshot):

That was a bit strange - normally I wouldn’t expect to see ’sites’ folder. It seemed empty, so I deleted it, and then I could access my new site collection without getting a 404. I then created a folder to interfer with one of my working managed paths (I created a folder called ‘demos’), and suddenly I started getting 404 errors if I tried going to it.

I don’t know why there was a ’sites’ folder in that virtual directory, but it was definitely causing problems. I guess I won’t be using a managed path of ‘bin’ or ‘aspnet_client’ then