Trinkit, Thinking Web Solutions

UPDATE: Congrats to the NZ team for taking out this event. It's always enjoyable beating the Aussies and this is no different. However the great thing about this competition is that both charities will get a fully operational website, not just the winner.

Check out the NZ site: http://www.fcp-nz.com/
and the AUS site: http://test.fcp-aussie.com/

There are more details about the results over on the fullcodepress blog.

- - -

Exciting news .... my wife Kate Smith was just selected to represent New Zealand in the FullCodePress web competition. What is FullCodePress?

"The concept is simple. Web teams take each other on, at the same location, to build a complete website in 24 hours. No excuse, no extensions, no budget overruns."

Kate will be taking the role of designer in the competition, but I'm sure her information architecture, UX and HTML/CSS skills will come into play at some point. The competition is in Sydney so we will both be heading over to check it out. Incidentally Kate is also the other half of Trinkit.

Read more on the FullCodePress website and see the rest of the NZ team.

Go the CodeBlacks!!

The other day I was messing around with the MOSS search web service (search.asmx) when I ran into a bit of a show stopper. Every time I tried to execute a method on the web service on a particular site I got the following error:

Attempted to perform an unauthorized operation.

Now it turns out that if anonymous access is enabled, the search service will return this error whether you are accessing it anonymously or not. In fact even if you haven't enabled anonymous access at the site level it will still not work. In this case it is still enabled at the web application/zone level and hence in IIS. I believe this is only an issue with the search web service, but I can't confirm that.

So I have come up with three different solutions to address the issue, and the right solution will depend on your scenario:

1. Disable anonymous access on the search.asmx file in IIS.  Doing this means that anonymous access is enabled for everything except the one web service that doesn't like it. The bad thing about this approach is that it requires a manual edit in IIS putting SharePoint and IIS out of sync. This may mean the setting gets overwritten later, or it may have strange affects if you later disable anonymous access for the whole site.
2. Use the URL of another non-anonymous enabled SharePoint site (could even be central admin). This is a good quick fix if you are trying to put together a prototype or something, but not the best in a production environment. Reason being that the user account used for the search service access will need to authenticate on the other site.
3. Extend the web application to provide a non-anonymous zoned IIS site - you may already have one. This is my recommended approach, but like many best practices it is the most complicated/time consuming/puts biggest load on server. See this article on TechNet if you are unsure how to go about that.

So why was I playing with the search web service anyway? Why not just use the object model? Or better yet why not use the OOTB search webparts? Basically I wanted more flexibility, I wanted to use the search components of MOSS as a remote service that doesn't require SharePoint context. For example utilising search from a separate non-SharePoint web application. An even more interesting use might be to provide anonymously accessible people search.

There are also some great search web service controls available from the awesome SharePoint search community tool kit.

Sometimes when updating a custom theme it can be really difficult to get your changes to take effect.

Normally the process to update a theme would be something like:

1. Copy new theme files to theme directory
2. Change selected theme to any other theme in site settings
3. Perform an IISRESET
4. Re-apply theme in site settings

However, sometimes no matter how hard you try it just won't update. In fact even if you manually update the cached theme css file in SharePoint Designer (in the _themes dir) it just reverts back to the previous version.

Turns out there is an extra step after copying your theme files in. You need to update the version settings in the theme.INF file. If I was changing this for the SIMPLE theme I would find the file to edit in the following directory:

And the values that need to be updated are highlighted below:

I normally just increment the numbers each time as with any versioning.

Follow the rest of the steps and you should have no trouble.

Here are a couple of related resources:

• How to create a custom theme
• 10 New themes released by Microsoft
• SharePoint Branding Tool

I am very, very pleased to have been re-awarded as an MVP for 2009!

Congrats to all the others that were also (re)awarded!!