Change the Home page in SharePoint

Happy New Year to Everyone!
Wow, it's been a while that I had the time to write a blog post. I was simply swamped over the last two months. Soo much has happened!
Now I look forward to a good new year and I wish everyone exactly the same!
Back to business!
Unbelievable, but after years of working with SharePoint, for the first time, I needed to change the home page. 2 seconds thinking, 20 seconds googling - only to come up with ideas like doing this programmatically ...nuh, this had to be simpler.
Hey, what about SharePoint Designer? And there it was, the "Set as Home page" command! It couldn't be more simple :-)
Set as Home page

Published: Jan-04-11 | 0 Comments | Link to this post

SharePoint 2010 Translation "Gem"

We'll be releasing the FC.ImageSearch for SharePoint 2010 product also in German. While testing we recognized this very innovative translation of a list column name:
English: "CheckedOutUserId"
German: "ID des Benutzers, der das Element ausgecheckt hat"
Perfect down to the punctuation with the comma after "Benutzers". ROTFLMAO :-D
Hey, whoever translated that column name, you have a career opportunity: you should switch jobs and start writing books rather than technical documentation.

Published: Oct-27-10 | 0 Comments | Link to this post

More "Site Assets" issues

While we're finishing the port of our FC.ImageSearch product to SharePoint 2010 we're coming across a number of flaws with the search result mechanism and especially the "Site Assets" library, which is a new feature in the commercial version of SharePoint 2010.
What's wrong with this picture?
Site Assets search result data 
Well, the "Site Assets" part (marked in yellow in the screenshot above) is not a sub site but in fact the name of the library. So, the real sitename should be http://2k8r2x64sp10.
What's worse is that if you have a search result that is stored within a folder of a library then even the folder name will be concatenated to the sitename!
As written in the previous blog post, the Site Assets library has a BaseTemplate and RegistrationID of "851". Well, that lack of better naming exists in the search result as well: while the Picture library has a proper contentclass of type "STS_ListItem_PictureLibrary", the Site Assets library is of contentclass "STS_ListItem_851".
Well, as you can see there are no thumbnails available for the images in a Site Assets library. Of course, that is wrong: as you probably noted, the Site Assets library absolutely contains the usual thumbnail and web preview images in the "_t" and "_w" folders. The links just don't get carried over to the search result.

Published: Oct-24-10 | 0 Comments | Link to this post

Site Assets library has RegistrationID 851

In case you haven't noticed: if you modify the Ribbon and think your modifications are fine by attaching to RegistrationID 101 (Document Library) then you won't have them show up for the Site Assets library, which has its own RegistrationID of 851.
I couldn't find the msdn entry for it. I am sure it's there as documentation is supposed to be sooo much better for SP 2010 (pun intended ;-)
Well, once I had the RegistrationID and did a search specifically for it I found 1 (ONE) page that had this info and also a comprehensive list for RegistrationID's: "Mike Smith's Tech Training Notes".
I love the SharePoint community! Otherwise half the solutions out there wouldn't exist.

Published: Oct-03-10 | 2 Comments | Link to this post

Crawled Properties not accessible from content application in SharePoint 2010

As we are in the process of porting our FC.ImageSearch product to SharePoint 2010 we came across a couple of Properties that are inaccessible if the code is running in the context of a Content Application, e.g. the AllCategories property of the schema object (more details on that here).
To make a long story short: Microsoft has opted to block access to certain data in the object model in order to prevent administration work to be done from a content application (instead of utilizing the central administration web application).
While I agree that security is always a concern I think that the current implementation is too tight.
One Example: In our scenario we want to give the site administrator the information which columns of the site's lists are mapped by which Managed Property's, so that he/she then knows how to configure the Advanced Search page properties accordingly. However, that's not possible as the CrawledProperty's - the "link" between columns and ManagedProperty's - are inaccessible from the content application.
Again, I consider it right to prevent any modifications to be made to the search' objects from a content application, but why cut off read access?
To solve this we implemented a custom WCF service on the central administration web application which the content application's code can talk to. While that's not bad or difficult it still doesn't feel right.
What do you think?

Published: Sep-20-10 | 0 Comments | Link to this post

Leverage the FREE Windows TIFF iFilter for OCR in SharePoint

I knew about the TIFF iFilter available in Windows 2008R2 and its OCR capabilities, but I had not had the time to try it out until very recently when it became a priority as a customer requested it.
The setup for it is very SIMPLE and well described in John Liu's blog post. It consists of no more than two essential steps: activating the TIFF iFilter Windows Feature and to configure the OCR Group Policy properties.
I might want to add a couple of things to John's description though:
1) You should also configure the option "Select OCR languages from a code page".
2) You do NOT need to restart your server: simply restart the SharePoint Search services and then execute an iisreset.
3) You only need to start a "Full Crawl" if you want to reindex TIFF files that are already in SharePoint. All TIFF files uploaded AFTER the iisreset will be indexed automatically.
Of course you need to consider the amount of text being added to the general search index file. However, the upside of searching on all the scanned documents' text is certainly quite obvious.

Published: Sep-20-10 | 0 Comments | Link to this post

FC.MetadataExtractor released for SharePoint 2010

A few days ago we released our first product for the new SharePoint 2010 platform: FC.MetadataExtractor 3.0
By far the biggest improvement in SharePoint 2010, in regards to this new release of our product, is the ability to better control the asynchronous ItemAdded event receiver. Given the positive feedback at the SharePoint 2010 conference when Microsoft announced the addition of such a synchronous ItemAdded event, quite a number of people must have encountered that problem.
Recap: in SharePoint 2007, the ItemAdded event fires asynchonously and so does the thread that brings up the EditForm.aspx with the properties of the newly created item. This of course creates a collision if both threads then try to modify that same item. The only way out of this issue was to provide a custom EditForm.aspx page that would wait for the ItemAdded event receiver to finish before the EditForm.aspx would load and access the item.
In SharePoint 2010 the ItemAdded event receiver can now be configured to either fire synchronously or asynchronously and also be given a sequence number. This eliminates the need for a custom EditForm and any manual synchronization and allowed a much "cleaner" solution with the new product release.
On the user interface front, the Ribbon does take a bit to get used to, both for programmers and users. I do think though that accessing the Ribbon is easier for many users than having to search through several popup menus for a certain command.
FC.MetadataExtractor for SharePoint 2010
The ability to have client-side ECMAscript code and the new Notification elements in the user interface is definitely a great step forward. We made use of it for the manual metadata extraction that now happens asynchronously at the server while the user can continue to work in the browser.

Published: Jun-24-10 | 0 Comments | Link to this post

Search Server Express 2010: Trial period for this product is about to expire

...well, should Search Server Express be showing this? And, isn't that a bit harsh considering that I only installed it yesterday? :-D
SSX Trial Expiring
QA, any comments?

Published: May-14-10 | 2 Comments | Link to this post

Crawled Property problems

The SharePoint technical documentation leaves a lot to wish for in general, but Crawled Properties is probably one of the worst topics when it comes to documentation. On top of that, the functionality to implement is weak as well. Let me give you some examples:
When you google for "SharePoint CrawledProperty" you get a whopping 1500 search results (I'm not sarcastic, just comparing Google to Bing, read on!) and on Bing you find 122 results on the same search, with the majority being people asking for help, I'd say.
Anne Stenberg provides a few clues on her blog about how to "interpret" the Crawled Properties. Let me quote:
"Property Set ID - A GUID that identifies the property set for the crawled property. Doing a search for the GUID B725F130-47EF-101A-A5F1-02608C9EEBAC and filtering the results for the Property Name of 12 yields several links to related content. One such link, on MSDN, provides a tremendous amount of information. This tells us that this property set is a System property and the propID of 12 is the file size"

While helpful to know, for me it simply shows how awkward the whole naming system is around Crawled Properties. But let's move on and get productive. We want to make things work here...


I'll use a real-world scenario to describe a typical problem around Crawled properties and how to solve it: assume you want to search on the "Date Picture Taken" column of the Picture library. After you put a fresh MOSS installation on a server, you can look up in the Search Administration of the Central Administration what Managed Property is available for that kind of search (only Managed Properties can be used in the search!). You'll find one entry:

Initial DatePictureTaken Mapping
A Managed Property (DatePictureTaken) already exists and has a mapped Crawled property called "ows_Image_x0020_CreateDate". While this looks good at first glance it will actually not help us at all. Why? Because the internal name for the "Date Picture Taken" column in the Picture library is "ImageCreateDate", so the CrawledProperty we'd need would be "ows_ImageCreateDate".
Just a quick explanation on the Crawled property naming convention: Crawled Properties are created automatically by the search crawler when it detects new columns that have a value. SharePoint columns always start with "ows_" (probably stands from "Office web server") concatenated with the internal name of the column.
So, let's have a look if there is another Crawled Property available with the right name. Under the Crawled Properties section we find this:
Initial ImageCreateDate Crawled Properties
Hmm, there are even three such Crawled Properties: two with the same, wrong name (including the text/hex version of a blank in the name) and one with the right name... but it's got the wrong type: we need a DateTime field, not a Text field!
OK, time to upload some images that include metadata for the "Date Picture Taken" column. A (shameless ;-) plug for our FC.MetadataExtractor product here: it extracts that DatePictureTaken metadata (and more) by default, and puts it in the right column. After that, starting a Crawl will "nudge" the search crawler to recognize the Date Picture Taken column in the Picture library, because it now has data. And voila, we have the "Date Picture Taken" column linked to the right Crawled Property and in turn we can go ahead and link this Crawled Property to the existing "DatePictureTaken" Managed Property (done in the following screenshot with our FC.ImageSearch product, but you can also do that in the Search Administration section of the Central Administration).
The right DatePictureTaken Crawled Property
But we're still not done: if we'd do a search now we'd get a really unfriendly error from the search service:
SearchService Error with Property
This is because we now have two Crawled Properties mapped to the Managed Property, but it can only take input from one at a time, so we need to change another setting for the Managed Property to "include values from a single crawled property...":
Single Crawled Property mapped
Yet another full crawl will help to push the Crawled Property data on to the newly linked Managed Property.
Now comes the fun! In the Search Configuration page of the FC.ImageSearch you can simply add the DatePictureTaken Managed Property that is now linked to the library's "Date Picture Taken" column and add it to the properties for the Advanced Search page:
Add DatePictureTaken to Advanced Search

Now, in the Advanced Search page you can select the "All Images" scope of the FC.ImageSearch solution and then choose from its Managed Properties the DatePictureTaken property:

DatePictureTaken search

...and that will get the successful search on our "Date Picture Taken" column:

DatePictureTaken search result 

Well, I still wonder why there are - out of the box - three ambiguous ImageCreateDate Crawled Properties. And what's more, deleting Crawled Properties is not possible in SharePoint, so you'll just have to ignore them.
But at least we got the search to work!

Published: May-12-10 | 4 Comments | Link to this post

SearchBox ignores custom scope search result page

Another one out of the "weird" series: now, our FC.ImageSearch solution includes an "All Images" custom scope that has an "ImageSearch.aspx" result page attached to it and usually, when the user selects this scope in the Search Dropdown menu, the search result is shown in the before-mentioned result page. But NOT always!
A search with this configuration:
SearchBox With All Images Scope
...resulted in the dreaded OSSSearchResults page on one of our MOSS test servers:
The dreaded OSSSearchResultsPage
Hmm, if this was the SearchBox on the landing page of the Search center, you could simply go into its Web Part properties and fix the problem there but, unfortunately, this is the SearchBox on the master page, so you can't simply call "Edit page" for it. What's worse, messing around with the control on the masterpage wouldn't necessarily help much either, as that's only a Delegate control.
Well, there's still an easy way to solve this: simply open up the "\12\TEMPLATE\FEATURES\OSearchEnhancedFeature\SearchArea.xml" file and add the following property, which is selected in the screenshot below:
SearchBox with added property
Close and save the file, do an "iisreset", refresh your page, re-issue the query and you should see the search result page of the custom scope come up:
Correct Search Result page after property modification
Easy to solve but still annoying that the default setting of the SearchBox would ignore the result page of the custom scope. If I were the product manager I'd call that a bug, Microsoft probably calls it a feature. ;-)

Published: May-11-10 | 4 Comments | Link to this post
<< Previous    Next >>