Sunday, January 18, 2009

SharePoint : Search using « This Site » or “This List” scope returning no results

I met a problem with the Search scope on a MOSS 2007 farm the other day that I thought was worth blogging about.

On all the content sites of our farm, the “All Sites” scope worked as expected, but the “This Site” or “This List” search scopes wouldn’t return a single result.

There are several reasons that can explains this problem according to this technet forum thread (, in our case the problem was due to a difference between the Content Source defined for the crawl and the default zone defined in the Alternate Access mapping.

Our Alternate Access Mapping for this zone was defined as follow:

Private URL Zone Public URL
http://hostname Default http://hostname Intranet

And we used as the start address for the crawl.

We tried changing the content source start address from to http://hostname, resetted the crawl content and launched a full crawl and that was it. The “This Site” and list scopes worked perfectly from then on.

That could have been it, except that this change caused another problem. Before this modification we had no trouble with links URL, I mean if I used to reach the site, all the links in the pages would use this dns name, not the hostname. After the modification of the content source however, some search results would sometimes be presented with the hostname in the url instead of the dns name.

To solve that problem we changed the Alternate Acces Mapping configuration to:

Private URL Zone Public URL
http://hostname Default Default

Voila! The Site and List scopes are working and the URL are always based on the DNS name when someone uses the DNS name to reach to site.

By the way, you might find this article about Alternate Access Mapping very useful:

Tuesday, January 06, 2009

Infinite looping the MOSS OOTB approval workflow

A few days ago, I noticed something weird with the Microsoft Office SharePoint Server out of the box workflow, most specifically with the workflow option to start when an item is modified.

I was trying to set up the Approval Workflow on a SharePoint List with content approval activated. I first set up the workflow to ask for approval when a new item is submitted to the list. It worked fine but we also needed to ask for approval when an item was updated (e.g. the writer made a mistake and notice it after the approver did his job, thus he modify the item that as a result needs to be approved a second time).

I fired up the workflow configuration page and checked the infamous “Start Workflow when an item is modified” in the start options.

From a french MOSS install

And from then everything went wrong. Whenever an approvers did his job by approving an item, the workflow would be launched again and a new approval task would be added to the workflow task list.

I tried tweaking the workflow, modifying the tasks list used … but nothing would do the trick, the workflow was stuck in an infinite loop whenever the “Start on item edit” was activated.

And that’s when it hit me, changing the approval status of an item seemed to be considered as a modification of the item itself.
I am still surprised by what I can’t help but see as a major flaw of SharePoint. I definitely don’t think that the approval status of an item is part of the item itself, it is only a SharePoint information about OUR piece of information (the item).

I also was surprised by how few people seems to react to this fact based on a few google search I made. Yet it seems other people faced the same problem ( and ).

If you have any information about this subject, I would enjoy to know it.