Skip to content

Sharepoint

Thinking of copying a locked SharePoint site collection ? Think twice !

clip_image002[7]I recently had to copy a locked SharePoint site collection from one farm to another farm. I soon realized this wasn’t such a great idea especially if the farms aren’t in the same AD domain. Here is a quick recap of what I noticed after a few more investigatory steps. Eager readers will eagerly jump to the final conclusion.

Copying though stsadm backup/restore

Let’s try copying this site collection with the stsadm backup and restore commands. Both farms are MOSS RTM farms. The backup worked smoothly. The restore is a total disaster (“Additions to this Web site have been blocked. Please contact the administrator to resolve this problem.”) : screenshot.1 The weirder part is that the collection is visible in the central administration but it seems totally messed up. No way to delete it from the Central Adminsitration. The stsadm deletesite command returns the “Additions to this Web site have been blocked. Please contact the administrator to resolve this problem.” error. Conclusion : Not a good idea ! Might actually works using the trick I finally used, see below.

Copying using a SQL Server backup

Seemed like today would be another day battling with SharePoint. But I wasn't short on idea. Indeed My locked site collection was alone in its content DB, therefore I was able to use a backup to restore the collection on my target farm. The restore wentsmoothly. I was starting to believe it was actually going to be easy! And then my frail hopes were cruelly shattered by the terrible SharePoint truth when I opened up the Central Administration to change the collection administrator. The first obvious step is to select the site collection but when selecting the site collection in the “Select Site Collection” popup, none of the collection details would appear on the right. clip_image004 Huh ? I tried validating the popup anyway and was presented with this screen: clip_image006 It seemed just as if I had selected nothing, yet the adress bar contained the id of the content database : clip_image008 Trying to unlock this site collection would produce kind of the same result. I then realized that the farm administrator had no right on the collection. He indeed had no permissions on the collection when it was backuped. Lucky me, the farms were part of the same domain, therefore I tried a quick and dirty fix, I added the original farm administrator to the target farm administrator group and logged in the Central Adminsitration with this administrator. It was a relief to be able to see the details of the collection. Thou shan’t prevail over me SharePoint ! But once again, I underestimated my adversary which quickly retaliated with a now too common “Additions to this Web site have been blocked” when I tried changing the collection administrator. clip_image010 But victory was mine at long last when I unlocked the collection while logged in with the original farm administrator account on the target farm. After this step I was able to change the collection administrator to the target farm administrator as I intended from the beginning. Conclusion : It works, but both farms have to be in the same AD domain

Final Conclusion

If possible I would advise you to unlock the site collection before proceeding with the copy. If it isn’t possible, I hope both of your farms are part of the same AD domain, otherwise good luck! Please keep me posted if the powers that be are you on your side. By the way, for those of you thinking that I should have tried the stsadm export command, one simply can’t export a locked site collection this way.

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 (http://social.technet.microsoft.com/Forums/en-US/sharepointsearch/thread/906045d8-8782-4c39-be1b-7632f7239019/#page:1), 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
http://intra.dnsname.com Intranet http://intra.dnsname.com
And we used http://intra.dnsname.com as the start address for the crawl.
We tried changing the content source start address from http://intra.dnsname.com 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 http://intra.dnsname.com 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 http://intra.dnsname.com
http://intra.dnsname.com Default http://intra.dnsname.com
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: http://blogs.msdn.com/sharepoint/archive/2007/03/06/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-1.aspx

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 (http://social.msdn.microsoft.com/Forums/en-US/sharepointworkflow/thread/62f5921d-9d02-4924-a61f-97ad169d1043/ and http://unitedsupplyco.sharepointsite.net/publicfacing/bensblog/Lists/Posts/Post.aspx?ID=34 ). If you have any information about this subject, I would enjoy to know it.

Sharepoint - Sorting people search results by name

Hello Dear Reader, for this new post. First some personal news, after working for quite sometime on load testing a java CRM application, I wanted to move on and finally work with the newest Microsoft technologies. And that’s what I did as I managed to land a job at a local Microsoft Gold Partner in Nantes, France. The team I ‘m part of is mainly working integrating the Sharepoint solution for local partner, and I got to say it’s a nice opportunity so far.

Background

For my first Sharepoint post I’ll speak about the limitation of the integrated People Search functionality. With MOSS 2007 comes the Enterprise Search Center that allows you to gives an easy acces to the search engine to your users. This Sharepoint site (because that’s exactly what it is) comewith two search mode OOB:

  • a standard search for searching through documents, lists, pages, ... basically whatever you let the Search Engine crawl and
  • a people search for, you guessed it, searching people based on any properties you want among the profile properties defined in the SSP (Shared Service Provider)

We recently had a problem where a client wanted to:

  • Display the list of employee for each office, sorted by name/firstname
  • Be able to search a client based on its name/firstname
The problem

We first imagined to fulfill these two needs with a single item, a people search page, where results per office would be obtained by adding the office as a searchable property. And that’s when we realized a huge shortcoming of the Search Center:

People search results can’t be sorted on arbitrary fields you will define, such as the name/firstname. Two standard Sorting modes are available and that’s it. Results can be sorted based on the ranking computed by the Search server. Results can also be sorted by social distance, the principle is fine enough, if you are looking for a John, it will first display the John who is your direct colleague instead of the John who is working in another department of another office.

The almost working workaround

Starting from this realization, we figured we might solve this problem by doing a quick sorting in the XSL displaying the results. This way, the sorting could be done on any fields necessary. While this solution is perfect if you have less than 50 results, it is not a full working solution. The thing is, the search engine first returns the results. These results are then divided (by the Search Core Results web part) in x collections of y elements (people) where y is a webpart parameter capped at 50. Therefore if we have more than 50 matchs, the sorting will be done separately on each page in a discontinued manner. That is , a hypothetical “Albert Alden” might be on page 2 while “Brittany Bern” is on page 1 if his rating is lower than Brittany’s. But we know for sure that “Cindy Costner” which is on page 2 will be presented after Albert whatever her rating is because the sorting on each page is done lexicographically by our XSL.

The working workaround

Keeping these limitations in mind we had to devise a quick solution. We chose to keep the standard people search for standard people search, considering the size of the company and the fact way it is going to be used. Yet we still needed a way to present the users with a list of all the employees of any given office (at this point, it’s probably needless to remind you that we REALLY want this list to be sorted by name/firstname J). That’s when we stumbled upon this superb article by Dietmar Kurok (http://www.codeproject.com/KB/sharepoint/DepartmentPeopleViewer1.aspx ). The solution is to use the Web Service exposed by the search engine to get the information we need sorted as we need and then present it with a XSL of our own. In our case we used the same principle as the one used in Dietmar Kuork’s article, however we chose to generate our QueryEx input parameter (the Querypacket) with a very nice tool available on CodePlex. The tool is named SharePoint Search Service Tool and will be found at http://www.codeplex.com/SharePointSearchServ. The general idea of the process is to: image I hope you enjoyed this first Sharepoint post and I hope to be able to post more often on this nice product in the future.