Requirement

Utilize audience targeting for a SharePoint Intranet so content can be targeted to users in a particular region of the world.  The Active Directory structure stores users in organizational units that are hierarchical by Geography. 

For example, here is some of the OUs that exist in the directory

OU=Accounts,OU=NorthAmerica,OU=US…

OU=Accounts,OU=NorthAmerica,OU=Canada…

OU=Accounts,OU=Europe,OU=Germany…

OU=Accounts,OU=Europe,OU=France…

Options

• Use Active Directory Groups, if they exist.
• Assuming the groups are maintained, this would be an easy solution that would not require any configuration in the SharePoint SSP as we could just use Security Groups in the audience targeting dialog.
• For this scenario, existing groups did NOT exist and we do not want to create and maintain new groups.
• SharePoint Security Groups
• Works well for single site collection content targeting, but not well for a larger scale.  Discarded because of the large management effort.
• PREFERRED OPTION - Leverage Active Directory Attributes via the user Profile store in SharePoint to build audiences.
• By leveraging the distinguishedName attribute (CN=UserID,OU=AppletonOffice,OU=US,OU=NorthAmerica,OU=Accounts,DC=domain,DC=com) on Active Directory user accounts, we can use a new profile property as a rule in an audience using the contains operator (i.e. distinguishedName contains “OU=US” to build an audience of all US users)

Implementation

Option 1 – NOPE!

My first try was to create a new profile property in the Shared Service Provider (SSP) that maps to the distinguishedName in Active Directory.  This did not work.  Apparently, SharePoint only allows an Active Directory Attribute to be mapped to one profile property in the SSP.  When an Active Directory connection is created for the profile import in an SSP, the distinguishedName property is automatically mapped to the AccountName profile property and cannot be changed; at least through the SSP UI. 

I found the following error after increasing ULS logging level for the Search Server Common category:

05/06/2009 10:57:34.82         mssdmn.exe (0x15C4)                            0x0A60    Search Server Common                          Common                                 0                Monitorable            [UserProfileImport]@CacheDataSourceMapping() For Source: litware, Mapping: The DS property (distinguishedname) ==> profile property (urn:schemas-microsoft-com:sharepoint:portal:profile:AccountName) has been retrieved! Error Code: 0x0 - File:d:\office\source\search\search\gather\protocols\profileimport\spsimporthndlr.cxx Line:989  

05/06/2009 10:57:34.82         mssdmn.exe (0x15C4)                            0x0A60    Search Server Common                          Common                                 0                Monitorable            [UserProfileImport]@CacheDataSourceMapping() For Source: litware,  the DS property (distinguishedname) has been mapped to another profile property. Its map to profile property (urn:schemas-microsoft-com:sharepoint:portal:profile:distinguishedName) is ignored! Error Code: 0x8000ffff - File:d:\office\source\search\search\gather\protocols\profileimport\spsimporthndlr.cxx Line:998          

OPTION 2 – NOPE!

My next steps was to look at the AccountName profile property which was being mapped to the distinguishedName Active Directory attribute.  During the profile import, the AccountName is populated with the domain\username rather than the expected CN=UserID,OU=Appleton,OU=Wisconsin,OU=US,OU=NorthAmerica,OU=Accounts,DC=domain,DC=com string value that Active Directory stores.

OPTION 3 – 3rd times a charm!

This option requires some custom development.  In this case, we already had a custom program that updates user profile pictures to standard corporate image location.  I added some code to this program that would update a new user profile property with the value from the distinguishedName Active Directory attribute.

1. Create an unmapped profile property in the SSP called UserDistinguishedName
2. IMPORTANT - Make sure that the Default Privacy Setting is set to Everyone or the property will not include any users in your audience during audience compilation.  (It took me a while to figure this out.)

1. Update profile sync program to set the UserDistinguishedName profile property with that user’s distinguishedName AD attribute.
2. Create a new audience called US Users that contains the following rule: UserDistinguishedName contains “,OU=US,”
3. Compile the audience and it can now be used to target content!

I can also use any OU in the UserDistinguished to build out an audience, users by region, country, state or site.

After installing SP2 on my development MOSS machine, I was unable to load the Central Administration site.  By disabling custom errors and enabling the callstack in the Central Admin web.config file, I found out why I was having the issue.

The web application could not load assembly “Microsoft.Internal.Mime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35”.  The following web.config file was the culprit: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\ADMIN\web.config

After checking the GAC, I noticed that there was a newer version of this assembly that SP2, see http://support.microsoft.com/default.aspx/kb/970359.

Using Reflector, I copied the updated Name and updated the web.config file. 

Central Admin on my dev box is now working again.  I suppose I could dig through the SP2 installation log to see if I can find out why this didn’t update…

Background

Federated Search has been introduced with Microsoft Search Server 2008 (MSS 2008). It allows MSS 2008 to pass search requests to other search providers (Google News, Live.com, Yahoo News, etc) and display the results in one place. Basically, to implement a federated search in MSS 2008, you download a Federated Search Connector file, .FLD. FLD stands for Federated Location Description. This file is based on the Open Search standard and is uploaded to MSS 2008 to enable the federation.

More info here: http://www.microsoft.com/enterprisesearch/connectors/federated.aspx

MOSS 2007 & Federated Search

MOSS 2007 does not currently support federated search as this was introduced with MSS 2008. However, I did find the following post that states an update to MOSS 2007 will be made available when MSS 2008 RTM is released that will add the Federated Search capabilities.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2482165&SiteID=1

This article will walk you through how to leverage MOSS Enterprise Search to find all files that a user has currently checked out from Document Libraries.  By using this method, a user will be able to find all documents that they have checked out for all web applications that are using the current Shared Service Provider.

Obviously, the frequency in which you crawl SharePoint document libraries will affect the accuracy of these results.  However, this provides a solution that does not require any custom coding and is just another way in which you can leverage MOSS Enterprise Search.

Overview - the following are the steps that we will perform

1. Create a new managed property in the Shared Service Provider (SSP)
2. Perform a full crawl on the SharePoint content source
3. Use the new managed property

• Keyword Search
• Search Core Result web part with a fixed query
• Add a new property to the Advanced Search web part

Let's do it...

1.  First, we need to create a new Managed Property that is mapped to the ows_CheckoutUser Crawled Property in the Shared Service Provider (SSP) .

• Browse to the SSP home page, click Search Settings
• Click on Metadata property mappings in the Crawl Settings section
• Click New Managed Property on the toolbar
• Enter checkoutuser for the property name and leave the type as text.
• Click on the Add Mapping button
• On the Crawled property selection screen, enter check in the Crawled property name field and click the Find button.
• Select ows_CheckoutUser(Text) and click OK.
• Your new managed property settings should look like the following:

• Click OK to create the new managed property.

2.  Prior to being able to use the new managed property, a full crawl must be performed on a SharePoint content source of which you have at least one file checked out.

• From the SSP home page, click Search Settings
• Click on Content sources and crawl schedules
• Click on Start Full Crawl for the Local Office SharePoint Server sites content source.

3.  Once the full crawl has completed on the SharePoint content source, we can begin to use the new managed property.  Depending on whether or not the MOSS profile import is configured, will determine what value you should use in your search query.  In the case of my environment, I did not have my profile import configured and thus I will need to use my Active Directory user name in my query.

• The easiest way to use the new managed property is by issuing a search using a keyword.  To find all files that have been checked out to a user, enter checkoutuser:rsteeno into the search box:

• Below are the search results showing the file that I currently have checked out.

• An additional situation in which this new managed property can be used is by configuing an instance of a Search Core Results web part to use a Fixed Keyword Query.
• Add the Search Core Results web part to a web part page and Modify the properties.  Specifically, you will need to set the Cross-Web Part query ID to something other than User Query, which is the default, and set the Fixed Keyword Query property.  The following screen shot shows my configured web part:

• Ideally, this web part could be configured to use the current user information.  I'll save that for a later post as I still need to do some research on making that work.
• The final way in which this property can be used is in the Advanced Search web part.  To add this property to the advanced search web part, please check out this article by Joe Shepherd.

This blog will primarily used for posting SharePoint 2007 related information that I feel the need to share.  Check back soon for some useful posts...