Sometimes SharePoint is used in environments with a complex Active Directory structure (using multiple domains or forests). This can lead to problems regarding the resolve mode of People Picker fields, both in OOB SharePoint fields and within the corresponding MatchPoint fields (i.e. within a Form Web Part: PersonField, RoleField).

SharePoint Behavior

Per default, the SharePoint People Picker will resolve accounts from the domain where SharePoint is installed. For resolving user- and group accounts from other forests or domains, it is required to modify the People Picker settings (according to MSDN). SharePoint will then be able to resolve user- and group accounts, provided that trusts between the forests or domains are configured correctly. More information on the configuration of the SharePoint People Picker can be found within the following MSDN article:
People Picker overview

Please be cautious: If not configured correctly, there might me a severe performance impact.

If SharePoint should resolve user accounts within multiple AD forests or domains, it is required to specify these search paths per web application:
Peoplepicker-searchadforests: Stsadm property

For further optimization of account resolving, it might be necessary to use a custom query or custom search filters:
Peoplepicker-searchadcustomquery: Stsadm property
Peoplepicker-searchadcustomfilter: Stsadm property

Note: We have found that resolving accounts cross-forest (or cross-domain) might work without making modifications to the People Picker settings. However, we suggest following the MSDN guidelines and specifying the settings.

MatchPoint Behavior

As far as possible, MatchPoint's account resolving follows the implementation of SharePoint. However, SharePoint does not provide a documented API for using the functionality for resolving accounts directly, so there are some differences:

1. While SharePoint might be able to resolve accounts in multi forest or domain setups without additional configurations, it is essential to configure the search settings for any web applications in order for the MatchPoint People Picker controls to work correctly:

   stsadm –o setproperty –pn peoplepicker-searchadforests –pv <list of forests or domains> -url <WebApp>

   This is required so MatchPoint can include additional search paths when user- or group accounts are resolved.

2. For a custom LDAP filter, please use the PeoplePickerSettings element within the MatchPointConfiguration.xml configuration file. This corresponds with the configuration of a custom search filter for OOB SharePoint People Picker fields.
   
   Within MatchPoint's configuration settings, you can also configure a custom display name pattern that will be used within a People Picker field.

Note: As of April 16, 2012 there were no PowerShell commands to configure People Picker. Therefore the links and examples provided here use the STSADM utility.

I recently stumbled over the blog post Validation in SharePoint 2010. This blog post provides a good overview of what can be done with SharePoint built-in field validation. It also describes where the built-in validation falls short. Solutions with no custom code are bound to MS Excel style formulas:

=[Budget]<1000

These formulas can cover basic validation rules. As soon as you need to do validation based on dynamic values (e.g. the current date) or pre-defined patterns (e.g. telephone numbers, social security Number, e-mail¹, etc.) you need to create a custom field definition, implement a List Item Event Receiver or do hacky stuff with client script validation.

All of you that already wrote tried to write complex validation formulas know what I'm talking about.

The MatchPoint Form Web Part provides a powerful field value validation mechanism using the Expression Engine that enables you to write complex, no-code validation rules (including regular expressions).

Validation Expression Examples

The MatchPoint Form Web Part lets you configure a validation expression for every writable form field. In the following examples I use two expression variables FieldValue (the current field value) and Form.Values.XYZ. The latter will be introduced with MatchPoint 3.1.0 and provides access to other fields on the form.

Example #1

In a project management list the field budget must not exceed 1000$:

FieldValue <= 1000

Managers are allowed to set a budget exceeding this limit:

FieldValue <= 1000 || MPUtility.IsUserInRole("Manager")

Example #2

The end date of a task list item should not be in the past:

FieldValue > DateTime.Now

The end date of a task has to be at least two days from today:

FieldValue > DateTime.Today.AddDays(2)

It's OK for the end date to be in the past if the task is completed:

FieldValue > DateTime.Now || Form.Values.Status == "Completed"

Example #3

Validation expression for a phone number with format (541) 754-3010 or 754-3010 using a regular expression:

FieldValue.Matches("^(\\(\\d{3}\\)\\s?)?\\d{3}-\\d{4}$", "None").Count > 0

Filter on a set of invalid characters (for instance !?_-*):

FieldValue.Matches("^[^_./*<>]*$", "None").Count > 0

Setup

You need to set a Form Web Part as default edit form on a SharePoint list in order to validate form values with MatchPoint expressions. The following link and video provide information on how to use form web part as default edit form:

How to use the Form Web Part to edit a SharePoint List Item

In order to enable validation on a MatchPoint form field you have to add the Validator element to the field configuration:

The Validator element provides three settings:

1. Expression:
   Specifies an expression that is expected to return true for valid field values. Use FieldValue to access the field's value.

2. Message:
   Specifies the message that will be displayed if the field value is invalid. Use {FieldValue} to access the fields's value.

3. ExceptionBehavior:
   Specifies the behavior, if an exception occurs during the evaluation of the expression.

^{1: I Knew How To Validate An Email Address Until I Read The RFC}

Since SharePoint 2010 there is a feature called Managed Metadata shipped with the Server edition. It is a hiarchical collection of centrally managed terms, which can be applied to items in the SharePoint application. The hierarchical structure of the terms is organized as follows:

1. Managed Metadata Service Application (Term Store)
2. Group
3. TermSet
4. Term (Terms can have other terms as children)

Metadata Management in SharePoint

In order to administrate the metadata there is a Term Store Management Tool, where you can manually create and edit groups, term sets and terms and their properties.

If you have to deal with a lot of metadata, adding all by hand quickly becomes painful. But you can circumvent this by using the import functionality provided by the Term Store Management Tool. The import functionality allows to specify a managed metadata import file. This file is comma-separated values file (.csv) which defines the term set and the terms in the term set. A sample file of such an import file can be downloaded from the start page of the Term Store Management Tool. To carry out the import, click on Import Term Set in the context menu of an existing group in the term store and specify the import file in the opening dialog.

After the import has successfully completed the term set and terms show up below the group.

Importing metadata like this seems to work, but some limitations particularly strike out:

• If you have a lot of data the content of the file gets confusing and the file becomes unmanageable.
• The metadata that needs to be imported often exists already in an other application and is for example persisted in a database. That means that before you can import this data you have to export it to an importer file in the csv format.
• Metadata is usually liable to changes: metadata gets updated, deleted and added. The metadata import functionality in SharePoint does not take this in to account. You cannot use the initial importer file, apply some changes and reimport the metadata, otherwise you pretty mess up your terms (e.g. duplicate entries).
• In the importer file there is no option to define other labels such as synonyms or tranlations of a term, although it is possible to specify them in the Term Store Management Tool.
• There is no possibility to schedule the import of the metadata.

The consequence of these limitations is that you have to implement a custom application which resolves these problems. Another option to eliminate these problems is to use the metadata management that comes with MatchPoint.

Metadata Management with MatchPoint

MatchPoint provides a timer job called TermImporter, which allows importing terms to the term store. This timer job can be centrally configured like the other MatchPoint components. It offers the following functionality:

• Fully configurable through the MatchPoint Configuration Framework
• Import of hierarchical structured terms
• Three different import modes, which allows repeatedly running the importer and keeps the the metadata synchronized with an external system
• Import from different data sources like SQL databases, SharePoint lists and Active Directories
• Multilingual import of term labels and synonyms
• Scheduling the import on minutely, hourly, daily, weekly or monthly intervals

Let me demonstrate it in short example, where I have an SQL database with two tables. One table contains countries and the other table contains cities. The cities have a relationship to the countries where they belong to. The names of the countries and cities are available in two languages, english and german.

The goal is to import the data of these two tables as terms. Terms with countries have the related city terms as children. And the labels of the imported terms are available for both languages.

You can define a TermImporterConfiguration in the Manage Timer Jobs Form of the MatchPoint Instance.

1. In the TermImporterConfiguration specify a name and the target term store, where the terms are imported.

   

2. Crate a new TermImport element.

3. Before the required properties of the TermImport element are filled out, create a DbDataSource element below the TermImport element.

4. In the DbDataSource element enter the connection string to the database and specify a SQL query.

   

5. Back to the TermImport element set the values for the Name, the Key and the Parent attribute. The value for the Key attribute should point to a unique value for each datarow in the data source table and so we specify DataItem.ID, which means that the value from the ID column of each datarow is taken. Finally, for the value of the Parent attribute select a term set, which was previously created in the term store. The terms will be created below this term set.

   

6. Define the labels for the two languages. In order to achieve this create a Labels element below the TermImport element and then add a Label element for each desired language. In the Label element select a language and for the value of the Label attribute specify the column of the datarow, that holds the value for this label, which is DataItem.NameEN for the English label and DataItem.NameDE for the German label. Additionally, synonyms of a label could be specified in the OtherLabels attribute.

   

7. The next step is to define the import for the city terms, which should become child terms of the country terms. To achieve this create another TermImport element.

8. The configuration values for this TermImport element are equivalent to the values of the TermImport element for the country terms. The significant difference is the value of the Parent attribute in the TermImport element. Here, select Use Provider Id and Key Expression and choose Countries for the Provider Id and DataItem.CountryID for the Key Expression. Like this the desired hierarchical structure of the metadata is achieved, since the parent term of the importing city term is resolved by the value of the foreign key column CountryID.

   

Save and close the configuration. In the Manage Timer Jobs Form the newly created TermImporterConfiguration shows up. There you can click on the Start button to execute the term import.

After the term importer has run, go to the Term Store Management Tool and verify that the terms have been imported.

The term importer can be repeatedly run on a scheduled interval. For the scheduling are different interval types available. You can add a Daily-, Hourly-, Minute-, Monthly- and WeeklyScheduleConfiguration to the TermImporterConfiguration to specify how often and when the term importer should run.
Repeatedly running the term importer updates the terms according to the changes of the data defined by the data source, so that the terms are kept synchronized with this data.

The MatchPoint Term Importer makes importing metadata more comfortable and relieves most of the limitations from the standard term import functionality that comes with SharePoint. Find out more about the taxomomy management with MatchPoint on the product website.