I wanted to add extra properties in the results page when searching for a staff member in SharePoint Server 2007. While I found a great article by Micrsoft here, they didn't explain how to add the managed property to start with, which you will need if the property isn't part of the default results property set. For the sake of this article I am going to add a user's mobile phone number into the search results.

First you will need to go to the administration of the Shared Services provider. Go to Search Settings -> Managed Properties -> Add Managed Property.

In here you can add your managed property. I added Mobile as my property name, gave it a type of text and for the Mappings to Crawled properties I found its mapping to be in the people section. The result was the mapping appeared as:

People:CellPhone(Text).

I would recommend running a full crawl of the index to make sure the new properties are propagated.

The next step is to go the search results page. Open up the search center and modify the 'People Search Core Results' web part. I added in the following property to the 'Results Query Options' -> 'Selected Columns':

<Column Name="Mobile"/>

Finally, you will need to edit the view properties of the web part. Go to the XSL Editor button in the web part, then modify the code. Where you want the value to appear, just add in  the selected code:

<xsl:if test='string-length(Mobile) &gt; 0'>
    <xsl:value-of select="Mobile" />
</xsl:if>

Now, whenever I do a search, the users mobile number also comes up in the search results!

In our current work environment we are looking at running Microsoft AX 4.0 (Axapta) along side an installation of Microsoft Server (MOSS) 2007. The idea was to have Microsoft AX do all the business financial's, and for any user access they would go via SharePoint web parts and web forms. This is of course the Microsoft concept. So we went ahead and have had MOSS running for some time now on a 64bit server, and AX running separately on its own server. Yesterday we decided to try and expose Enterprise Portal (the web facing part of AX) on SharePoint. After closely following all of Microsoft's instructions we kept getting the same message when we tried to deploy the Enterprise Portal Templates and WebParts:

"enterprise portal cannot be deployed because windows SharePoint services is not installed on this computer."

This made no sense at all as we have had SharePoint running for some time now. It is of course our Intranet. After trying almost everything and ripping all my hair out I posted on the AX news group. I am glad I did this as they gave me the answer I (didn't want) to hear. I checked the Microsoft documentation and it confirmed my thoughts:

"Enterprise Portal is currently not supported on 64-bit computers."

Wow! Top work Microsoft. You go and release some great, brand new Enterprise tools for an organisation, however you overlook the small fact that we might be running 64-bit servers. I am so annoyed. Hopefully some kind of fix comes out for this soon. In the meantime, I have to go deliver the bad news to the organisation...

When working in SharePoint, columns are used to display the information that constitutes each item in a list or library. At the top of each column is the name of the column. One of the features you have with setting default values in a column is to use a calculated column - this can be a great little feature to know about to help save time for users when they are inputting values into forms.

Calculated columns display the results of mathematical or logical operations. A calculated column enables you to also perform operations on data in any other column. And the columns need not be side-by-side or even next to the calculated column. So for example if you wanted to add the total of 2 columns you would use a formula such as:

[column 1] + [column 2].

This is simply placed in the calculated column definition.

You can also combine the text in the first two columns by entering the following formula for the calculated column:

[Family Name] & ", " & [First Name]

Which would give you a result as a default for that field as 'Cherry, Clinton' if it were me.

So if I wanted to create a title for a document based on today's date (ie "Clinton List Item - 12-5-2007") then I would simply use a calculated value for the column which would look something like:

="Clinton List Item - "&TEXT(Today,"dd-mm-yyyy")

There is a Microsoft article on how to do this here. Better still, I always find examples are a great start, and there are some great examples here on the Microsoft site.

One of the many customizations you might find yourself doing for a client using SharePoint is creating custom Site Templates for the various types of areas or sites that they will have on their site - this might be a custom project management folder or a template for a HR area - it could really be any custom template at all - but creating that is a different story.

Once you have created the template and added it to your site template list, it will more often than not end up under a 'custom' tab in the picker list for creating a new site. You however might want to personalize this a little more for your client by naming it something like 'My Client's templates'. Lucky with SharePoint 2007 this is a piece of cake.

1. Find the file core.en-US.resx in the \Program Files\Common Files\Microsoft Shared\web server extensions\12\Resources folder.
2. Edit the value for "TemplatePickerControl_Custom", changing it from 'Custom' to whatever you want (ie to 'My Client's templates).
3. Do an IISRESET (I always do this to be sure my changes are picked up).

To customise what site templates are available, you will need to go to the site settings page, and under 'Look and Feel', select 'Page layouts and site templates'. On this page if you select 'Subsites can only use the following site templates', you can select the templates to display in the picker.

Thanks to Mauro.

When developing in SharePoint I find it really beneficial to use post build events in Visual Studio.  For those of you not familiar with pre and post build events in Visual Studio, these can be accessed via the properties of your project. They enable scripts to be run before and after the build of your project. In the case of developing for SharePoint this is really useful for doing activities such as building a cab file or copying an assembly to the Global Assembly Cache (GAC).

So for example if you are frequently updating an assembly in the GAC you will save a lot of time to add the following into your post build event:

@SET GACUTIL="c:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe"
%GACUTIL% /iF MyAssembly.dll

Another common post build event I like to use is to differentiate between debug and release environments. I might want to copy a file to the assembly during debug, however for my release I might be building a cab file. As a result I would use the following code:

if $(ConfigurationName)==Release goto Release 
if $(ConfigurationName)==Debug goto Debug 

:Release
cd "$(ProjectDir)"
"C:\Source\Utilities\MAKECAB.EXE" /f package.ddf
goto End

:Debug
%GACUTIL% /iF CPMining.Portal.MyNavigation.MyAssembly.dll
goto End

:End

Another common task might be to copy files to a deployment or other folder after building - a simple xcopy comes to the rescue. In the following example I would run this snippet after running MakeCab.exe to make my cab, then simply run this code to copy the cab solution file to my deployment directory:

xcopy /y /f "$(ProjectDir)Deploy\*.cab" "C:\Source\Deployment\"

Basically all that happens with pre and post build events is that batch files are created by Visual Studio which are run. However as these are batch files, you are only limited by your own imagination as to what tasks you might add to the build process to automate tasks and make your life as a developer a lot easier!

For some more information it might be worth checking out Creating a Visual Studio Project for Windows SharePoint Services 3.0

Working with SharePoint Designer lately, I found that when you get a list of items from a multi select control, they are returned to the page in a delimiter separated list (ie item1;item2;item3). In the SharePoint Designer environment everything is done using XSL, so in order to loop over each item in the list to further process them, I needed a way to loop over such a list using XSL. I came up with the following code, which may not be the best way of doing this - but it definitely worked!

This first piece of code calls the template. The parameters passed in define the index to start processing the list at, and the second parameter is the delimiter separated list to process.

<xsl:call-template name="ProcessEachRow">
    <xsl:with-param name="index" select="1" />
     <xsl:with-param name="TextToProcess" select="$DelimiteredList" />
</xsl:call-template>

This second piece of code is the template that is used for looping over the list. It does a simple recursion on itself to process all the items in the delimited list.

<xsl:template name="ProcessEachRow">
    <xsl:param name="index" select="0"/>
    <xsl:param name="TextToProcess" select="''" />        
     
        <xsl:choose>
            <xsl:when test="contains($TextToProcess, ';')" >
                <xsl:variable name="CurrentItem"  select="substring-before($TextToProcess, ';')" />
                 <!-- more code in here -->
            </xsl:when>
            <xsl:otherwise>
                <xsl:variable name="CurrentItem"  select="$TextToProcess" />
                <!-- more code in here -->
            </xsl:otherwise>
        </xsl:choose>           
                        
  <xsl:variable name="left" select="substring-after($TextToProcess, ';')" />
    <xsl:if test="string-length($left)>1" >
        <xsl:call-template name="ProcessEachRow" >
            <xsl:with-param name="index" select="$index+ 1" />
            <xsl:with-param name="TextToProcess" select="$left" />
        </xsl:call-template>
    </xsl:if>
</xsl:template>

I problem that I have come across more than once when installing SharePoint is not being able to get the services started from the 'Services on Server' area of the Operations menu. When you go to start the service you might get an error like:

An unhandled exception occurred in the user interface.Exception Information: OSearch (administrator)

My first thought that this was an issue with my installation of SharePoint Server 2007. In fact it isn't - it is just a result of laziness on my behalf.

When starting the services you are taken to a form where you specify the account for crawling and searching etc, and you need to specify a username and password for these accounts. What you need to do is specify the domain also (which in the case of using the local account is the name of the machine). So for an administrator on a single server called 'DomainComputer' you would enter DomainComputer\Administrator as your account (not just administrator).

Remember this, and you'll never see that error again! Shame the error message displayed by SharePoint wasn't more useful in the first place.

(thanks also to WinSmarts for the original solution for this!)