Saturday, April 16, 2011

In this post I want to share small tip which will help you to run Sharepoint management console (or management shell) in any custom folder. If you work with automatization of Sharepoint administrative tasks with PowerShell, then this tip may be helpful for you. The problem is that when you run OTB Sharepoint management console in runs in default home folder (e.g. “c:\users\myuser”). But in real life you may need to reopen it frequently (e.g. if you consume some code written on C# in assembly which is located in GAC. If this code is changed you need to reinstall assembly into GAC. Also if you want your changes to affect management console you need to reopen it because otherwise console will use old cached version of the assembly). After restart console will be again use default location, so you will need again perform “cd c:/projects/myscripts” command in order to go to the folder with your scripts.

In order to avoid this, go to the folder “ C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration” and edit “SharePoint.ps1” file. Find the following line:

1: Set-location $home

and replace $home with your folder:

1: Set-location "c:\projects\myscripts"

After that once you will start Sharepoint management console – it will be launched in your folder and you will be able to start working with your scripts immediately. But note that this change will affect all users of the management console, so I recommend to revert changes when you will finish your development.

Saturday, April 9, 2011

In one of my previous posts (see Create custom AD attribute and map it to Sharepoint user profile property) I showed how you can extent your AD schema with custom attributes and how to add them into User profiles properties. Here I want to show how to use these custom attributes in standard People search and how to customize People search results for displaying them.

Once you mapped attributes, customization of People search results is fairly easy. First of all you need to create Managed properties in Search service application and map them to properties of user profiles (see also my post AD attributes used in standard configuration of People search in Sharepoint where I showed what attributes are used in standard configuration of People search and their mappings). In order to do this go to Central Administration > Manage service applications > Search service applications > Metadata properties and create new Managed property for your custom attributes. E.g. if you follow by the same example which I used in the post mentioned above, you can create new Managed property with name “BusinessUnit” and add map to the Crawled property (User profile property) “People:BusinessUnit” (you can filter crawled properties by categories). After that perform full crawl.

Now you can go to your site and search for people using custom BusinessUnit property. E.g. if you need to find people which belongs to Russian business unit you can specify BusinessUnit:Russia in the search box – search results will contain people for specified unit.

The remaining problem is that business units themselves are not displayed on the search result page. In order to display them we need to customize OTB CoreResultsWebPart on People search page in the Search center site. Go to People search page and edit it, then choose Edit web part for Core results web part. Here uncheck “Use Location Visualization” checkbox and add the following columns into “Fetched Properties” textbox:

1:<ColumnName="BusinessUnit"/>

Name attribute should contains name of Managed property which we created earlier. After this you need to modify XSLT template – add custom property into template. Click XSLT editor in web part properties and make the following changes:

Wednesday, April 6, 2011

Sharepoint 2010 uses CoreResultsWebPart on People search page in standard Search center. You can control what properties can be shown by this web part using SelectColumns and PropertiesToRetrieve properties (or via web part properties in UI: Display Properties > Fetched Properties). Here you need to specify names of Managed properties (you can find them in Central Administration > Manage Service Applications > Search Service Application > Metadata properties). This properties are mapped on Crawled properties (available on the same page – if you will click appropriate link on top of the page) which are used by Search crawler. There are several categories of Crawled properties. For People search we are interested in People category. Crawled properties from People category are in associated with User Profile Properties (Central Administration > Manage Service Applications > User Profile Service Application > Manage user properties). Some User Profile Properties are in turn mapped to AD attributes (and some are editable by users).

So we have the following mapping chain: Managed property > Crawled property > User profile property > AD attribute. I created a table where summarized all properties and their mappings:

As I said you can customize CoreResultsWebPart and use whatever properties you need. But this table may e useful if you need to know what AD attributes are used in standard configuration of People search in Sharepoint 2010.

Tuesday, April 5, 2011

When use standard webHttpBinding in WCF (e.g. for RESTful endpoints) you may face with the following problem: standard error handler WebErrorHandler which ships with WebHttpBehavior returns generic “Internal Server Error” message for any exception you throw in the WCF service. Or to be more precise it returns response message which contains exception message like this:

Here I use 2 external classes: WebException from WcfRestContrib project and ErrorBodyWriter which realization I found in one of the forum threads. WebException is very easy: is just allows you to specify HTTP status when throw exception (as far as I know in .Net 4.0 there is standard equivalent of this class for WCF):

About Me

I've created this blog for sharing my technical experience in software engineering. Most of posts will be dedicated to Sharepoint. But I will write also about another areas of software development for .Net platform. Hope it will be useful and will help you in your work.