Evidently I’ve spent too much time working on installation and deployment of FIM as opposed to actually designing and delivering a FIM 2010 R2 portal as this was news to me!

Search Scopes have been changed.  In FIM 2010 a couple of key attributes, namely DisplayName, were wrapped in a contains() function whereas everything else was wrapped in the starts-with() function, e.g. the All Users search scope executed the following XPath:

/Person[contains(DisplayName, ‘<val>’) or starts-with(AccountName, ‘<val>’) or starts-with(MailNickname, ‘<val>’)]

In FIM 2010 R2 this has changed.  Nothing uses contains() now.  For performance reasons everything is now starts-with() so the default All Users scope now executes the following XPath:

/Person[starts-with(DisplayName, ‘<val>’) or starts-with(AccountName, ‘<val>’) or starts-with(MailNickname, ‘<val>’)]

This change is applied to existing search scopes when you upgrade too, i.e. your 2010 scopes will be modified during upgrade to reflect the new behaviour.

The release notes do mention this:

FIM Portal: Default search operator for DisplayName has been changed to starts-with from contains
As a result of working with a number of internal and external customers, on portal search performance we chose to change the default search operator used by the FIM Portal (Search Scopes, Identity Picker) to leverage starts-with rather than contains for the DisplayName attribute. This will impact your existing FIM Portal implementation and your FIM portal administrative searches. If you wish to return to the default search behavior for one or more search scopes, we have added the ability to configure an “Advanced Filter”. Please see FIM 2010 R2 Search Changes for more information.

Note that there’s a URL to an entire document on the subject:

• FIM 2010 R2 Search Changes

That document is interesting and discusses the manual override that can be applied on a per-search scope basis.  There’s a couple of things of note however.

1. There doesn’t appear to be a global setting.  The setting is on a per search scope basis only.  If you have a bunch of search scopes affected by this you need to factor this into your upgrade plan as you’ll need to script a bunch of changes.
2. There’s no validation on what you specify in the AdvancedFilter attribute!
   

   Be aware that the Advanced Filter does not validate the xpath query so if there is a typo in there it may be the cause of the Search Scope not functioning properly.

3. SQL LIKE wildcards are supported with the starts-with predicate.  That’s good. 
4. When you use an advanced filter a null search will not return all resources.  This is quite logical but is a breaking change.  We’re very used to hitting search with no criteria to pull everything back –a bad habit no doubt but one I live and breath by.  The document doesn’t mention this but it appears to be a known issue.  The workaround is to type %.  Personally I’m hoping someone takes issue and bugs this via CSS…

Let me explain #4 above in just a little more detail.  If I open the portal and simply click the magnifying glass next to the All Users scope all users are displayed, e.g.

Now.  If I override the scope to use the old contains() predicate by specifying the following AdvancedFilter attribute value:

/Person[(contains(DisplayName, '%SEARCH_TERM_STRING%') or starts-with(AccountName, '%SEARCH_TERM_STRING%') or starts-with(MailNickname, '%SEARCH_TERM_STRING%'))]

The following happens when I click search with a null field.

To get the old behaviour I have to submit a ‘%’.

This may or may not be an issue for you.  It’s a pain for me but I’ll have to live with it because I don’t have a customer I’m working with complaining yet. 

And one last thing on this subject.  If you mess up the XPath in the AdvancedFilter attribute the output in the Portal is like this:

The error message in the event log (default tracing level) tells you what you already knew and not much more…

Validate those XPath statements people!