Context

A couple of months ago I was building a client’s production farm. It was a pretty straight-forward architecture with few unusual requirements. I’d successfully provisioned everything and was deploying the PDF iFilter as one of my last steps. When I ran a test crawl to see if it could pick up the contents of PDF documents, I was surprised to find the Local SharePoint sites Scope contained zero items, even though the crawl successfully gathered 459 items. To add to my confusion, the People scope was fully populated. I verified that the scope didn’t need to be updated, then launched ULS Viewer. While reading the trace logs in real time, I re-ran a full crawl and spotted this clue (my bold):

AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user’s Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user.

Investigation

This error message reveals quite a bit. We know the error occurs in a w3wp.exe process associated with SharePoint Server Search’s, “Query Processor”, and that the application pool identity of this process doesn’t have read access to the tokenGroupsGlobalAndUniversal attribute in Active Directory. This tells us the error is occurring on the SharePoint Search Service Application pool’s identity, rather than on the Search Service (which is not a w3wp). After searching for a bit I found a few useful posts/articles, but what really helped me was Russ Maxwell’s article, which I linked to at the top of this post.

I suspect that in his testing, Russ found different scenarios where Pre-Windows 2000 Compatibility Access rights needed to be granted to the Search service account, but in my case these rights didn’t help. His error and his explanation of the problem are different. I don’t want to make too much of this, since his post was circa Beta, but it’s worth noting there may be multiple issues with these rights and Search. In our case, we tried to grant rights to the Search Service account but the error persisted until we added the Search Service Application Pool Identity account to this group. In actuality, we identified these same errors on the farm account initially as well, but granting these rights to the farm account didn’t solve the problem.

I should also note for completeness, that there were Security event 4625 Logon Failure errors accompanying the ULS log entries until we granted access to the Search Service Application Pool Identity account, at which point these events were replaced by 4624 Success events.

After running one more Full Crawl I confirmed that the ULS errors were also gone. It’s reasonable to infer from these new ULS events that when PluggableSecurityTrimmerManager is selecting, “workid from scope()”, it needs these Pre-Windows 2000 Compatibility Access permissions in a Windows Server 2000 or Windows Server 2003 domain. Presumably if SIDs can’t be initialised, everything gets security trimmed.

How to use these findings

I’d recommend adding this to the list of permissions you may need to grant in a Windows Server 2000 or Windows Server 2003 domain. This is basically what Russ Maxwell was saying initially, as I read it. In this scenario, I’ve merely spotted a scenario where different rights are required and I can’t shed any light on why this hasn’t been required in every Windows 2000 or Windows 2003 domain I’ve worked in.

If working from a principle of least privileged access, I’d suggest granting these rights as needed during deployment. They shouldn’t need to be granted particularly broadly (unless you’re working with a 1-way trust from a resource domain, which is another story – see the comments in the Russ Maxwell post for an introduction). Alternately, it’s arguable that granting read access to this tokenGroupsGlobalAndUniversal (TGGAU) attribute isn’t opening an enormous hole, but that’s a question for each organisation to answer based on their security models.

A Note on User Profile Pre-Windows 2000 Compatibility Access Rights

While I’m speaking of variance in these permission requirements, I should note that I’ve seen a number of sources including Spencer Harbar, TechNet and this Russ Maxwell article mentioning the need to grant these same Pre-Windows 2000 Compatibility Access rights to the User Profile Synchronisation account, but I haven’t had any problems running without these rights in two different Windows 2000 or 2003 domains.

If the domain controller is running Windows Server 2003, the synchronization account must be a member of the Pre-Windows 2000 Compatible Access built-in group. See Add an account to the Pre-Windows 2000 Compatible Access group for instructions to grant this permission.

Given those sources, I’d suggest you’re probably best off granting the rights, but I haven’t yet been able to validate the need myself. I’d definitely be interested if anyone can shed more light on that topic.

• I have an intranet and a MySite, each with a default zone used by all users to access the application, in this example https://sp and https://my.
• I want to optimise my crawl performance by crawling over HTTP, in order to remove the encryption/decryption load for each request, so I create a new Alternate Access Mapping zone on HTTP, for each of these web applications. These new URLs are http://s and http://m.
• I also set up HOSTS file entries on my Crawl Component servers so they will be able to crawl these applications locally. I don’t want my crawls to add load to the WFE servers.
• If I don’t want real people to access the site on this zone (and I probably don’t), I don’t set up DNS entries for it. Only Search will be using this zone.
• (Optionally) I create a Web Application User Policy that restricts access to this zone, since it is not running under SSL.
• I reconfigure my Content Sources in the Search Service Application to crawl the new zones, http://s, http://m and sps3://s
  • Note, for an SSL-secured site, the final People Search Connector, “sps3://s” will actually be “sps3s://s” by default, so make sure to get rid of that last “s”.
• I run a full crawl and verify that it completes much faster than it did when I was crawling the site over HTTPS/SPS3S.
• Once my full crawl completes successfully, I verify that All Sites and People search results are returning as https://sp and https://my (the default zones).

This was all working as expected – until Anthony noticed that the Org Browser web part appeared to be broken. On further inspection, we identified that:

• Alternate Access Mappings didn’t appear to be working on this link (it displayed the crawled address).
• All other links on the People Search Results tab pointed at the default zone; they accurately respected Alternate Access Mappings.
• All results for the All Sites tab/scope successfully respected Alternate Access Mappings.

So we have one link to the wrong zone on the Enterprise Search Centre’s out-of-the-box People Search results page (or tab, if you prefer). I took this scenario to my development environment to confirm. Indeed, the behaviour was the same. I’ll illustrate below.

Alternate Access Mappings for my Blank Site

Alternate Access Mappings for my My Site

The updated Content Sources page

The “All Sites” Search Results Page With All Links Mapped

In the following four screen shots of the same People Search results, notice the status bar as I hover over various links on this page (see: bottom left of the browser).

The Correct Link to Me

The Correct Link to “Add as Colleague”

The Correct Refinement Link to “All Matches”

The Incorrect Organisation Chart Link (http://m)

It would be incorrect to say that this link is broken. It works, so long as you have name resolution for it. The link is just pointing at the wrong zone, which may not be in DNS. Further, clicking that link may not be desirable or could disrupt the user experience, if the zone is locked down. In short, we explicitly want to avoid edits from that zone in this case, for a number of reasons, all of which I will gloss over here as my preference for a single zone.

Long story short: this looks like a bug to me. I’ll call it a bug. These links are new to User Profiles in SharePoint 2010, so there’s a likelihood that Alternate Access Mappings were overlooked here.

What to do?

I still want to use Alternate Access Mappings, because the performance overhead of crawling encrypted data is not unsubstantial. This leaves me with an option to escalate this issue through Microsoft Support, which I really don’t have the time to do, or we could probably whip up some script quickly to update the results page and fix these two links up, but that’s not a very elegant solution. This is no longer a pressing need in my case, because this client has opted to delay launch of MySites and People Search for reasons completely off this map, but the bug remains and pertains elsewhere (like in my development environment). I will take this to Microsoft when I can find the time, but that’s not going to happen in the near future. Until then, any other ideas?

17-03-2011 update: David noted in the comments that he’s worked around this by running his sps3:// crawl on a different web application – even creating one with no real content, specifically for this purpose. I haven’t had a chance to test it out yet but it sounds like a great idea to me. See the comment for more detail. Anthony has put this to the test for our client and all is working now. Hooray!

Afterword: Server Name Mappings

Somewhere along the line I’ve got myself in a muddle regarding Server Name Mappings. When we first encountered this problem, I configured both Alternate Access Mappings and Server Name Mappings (with the same mappings). In this case, I don’t believe this has caused any problems, but it’s not necessary and isn’t correct. Alternate Access Mappings should translate search results to the same zone that you’re browsing from, without doing any extra work. Server Name Mappings translate crawled data like file shares to other links that don’t already exist as Alternate Access Mappings. As this Enterprise Search blog post explains, “Although Server Name Mapping and Alternate Access Mapping achieve seemingly similar results, they work independently, addressing different problems, and should not be used together”. This is perhaps the only content I’ve found that clearly explains how to use Server Name Mappings correctly, and is well worth a read.

It’s worth noting that the Server Name Mappings had no impact on the Organisation Browser link either.

Round I

My difficulties started when I attempted to move a newly-provisioned Query Component to a web front end server. When it failed, I tracked the problem down to missing permissions on C:\Windows\Tasks. At this point I didn’t know why the permissions had been removed and this was actually the first time I’d noted these permission requirements. TechNet suggests WSS_ADMIN_WPG needs Full Control of %WINDIR%\Tasks, but the description of this requirement is “N/A”. Oddly, according to this TechNet article, the WSS_WPG group does not appear to need these same rights, although they are assigned by the SharePoint installation/configuration processes – or at least they are in the environments that I’ve built.

Adding to this confusion, I found this strange ULS event, in which the provisioning process tries to remove WSS_WPG access to %WINDIR%\Tasks and grant R/W access to the Search service account. This is pretty weird! It might explain why the WSS_ADMIN_WPG group needs Full Control rather than just R/W access, but I wouldn’t typically expect SharePoint to be modifying ACLs in the Windows directory.

“Modifying ACL to allow R/W access to ‘C:\Windows\Tasks’ and to remove access for WSS_WPG.”

Back to the provisioning problem at hand, once I added the missing permissions for both the WSS_WPG and WSS_ADMIN_WPG local groups on %WINDIR%\Tasks the provisioning process completed successfully. You can also see that the “Modifying ACL” event directly precedes the failure to start the new Service Instance. While this event helped me track down the problem, and is clearly related to it, unfortunately I need to leave that mystery behind for now, as there are bigger issues to address in this post.

Round II

Later, this client got back in touch and mentioned that their Search Service Application wasn’t working. In this case the Search Administration page was available but all Content Sources, Scopes, Crawl Logs, etc. pages failed with errors on the Admin Component.

Crawl status: The search service is not able to connect to the machine that hosts the administration component. Verify that the administration component <GUID> in search application ‘<Search Service Application name>’ is in a good state and try again.

To cut a long story short, my initial troubleshooting didn’t immediately lead me back to these missing permissions due to a number of other concurrent infrastructure changes which lead me astray. Additionally, when we tried to delete the Search Service Application to recreate it, the deletion failed after removing just one of the Search databases. Eventually we managed to re-provision the Service Application but the topology changes failed again, at which point we identified the missing %WINDIR%\Tasks permissions (again) and granting the missing permissions fixed these problems (almost).

In fact, we also needed to grant missing permissions on \Program Files\Microsoft Office Servers\14.0\Data\Office Server, but I believe that was a one-off related to the failed Search Service Application deletion earlier. One way or the other it doesn’t appear to be a core issue here. However, I should also mention that I suspect the Search Service Application deletion failed because of the missing %WINDIR%\Tasks permissions – although I’m basing this entirely on the fact that the ULS events above suggests that a similar process takes place for deletion, by virtue of the “(un)provisioning” job.

Round III

With Search back up and running, we moved on to other things, but eventually Search started acting up again. Unfortunately I’ve lost track of the visible failure, but the application logs were full of 6398 and 6482 errors (which typically indicate the unavailability of the service rather than the cause). I vaguely recall that we had items in the index but that new crawls were failing to run. At the time, I was most focused on Gatherer Access Denied messages on the Portal_Content Catalog.

Again, to abbreviate other misguided efforts related to on-going infrastructure work, we eventually found out that the permissions on %WINDIR%\Tasks were missing. Obviously, at this point the most reasonable explanation for the change was a Group Policy setting, so we reviewed the event logs in between the last known good crawl and the first crawl failure. I quickly spotted a Group Policy change message. I recommended that we review the Resultant Set of Policy on this server, just to be absolutely certain the Group Policy wasn’t applying permission changes in this location. The client assured me this was very unlikely, because they don’t have an overly restrictive culture, but it turned out this was the one and only file system permission change and it was applied to the Default Domain Security Policy. Presumably the previous Search failures occurred after reboots or some other event that would re-apply this group policy. And presumably all of this strange behaviour can be accounted for by these missing permissions, given that we know they were getting removed and we know that adding them back in fixed the problem.

Conficker

Later that night, curiosity got the better of me. I dug a bit deeper to see if I could identify anything that recommends these permission changes. I found Microsoft Support KB article KB962007, Virus alert about the Win32/Conficker worm. In this article, Microsoft recommends the following mitigation steps to prevent the virus from spreading:

Set the policy to remove write permissions to the %windir%\Tasks folder. This prevents the Conficker malware from creating the Scheduled Tasks that can reinfect the system.To do this, follow these steps:

1. In the same GPO that you created earlier, move to the following folder:

   Computer Configuration\Windows Settings\Security Settings\File System

2. Right-click File System, and then click Add File.
3. In the Add a file or folder dialog box, browse to the %windir%\Tasks folder. Make sure that Tasks is highlighted and listed in the Folder dialog box.
4. Click OK.
5. In the dialog box that opens, click to clear the check boxes for Full Control, Modify, and Write for both Administrators and System.
6. Click OK.
7. In the Add Object dialog box, click Replace existing permissions on all subkeys with inheritable permissions.
8. Click OK.

In effect, this Group Policy removes the special Read/Write permissions assigned to Authenticated Users on the %WINDIR%\Tasks folder by default. Note: it replaces all permissions with those defined in the Group Policy. I suppose the moral of this story is not to apply security settings like this to the Default Domain Security Policy. But fair play to my client for the security diligence in the first place.

Default %WINDIR%\Tasks permissions for Authenticated Users, without the group policy

This issue raises a couple of other questions. What is the best way to handle this for SharePoint servers, given that there are legitimate reasons harden this location? I suppose the best option would be to create another Group Policy for the SharePoint servers OU which will add the local WSS_WPG and WSS_ADMIN_WPG group permissions back on the %WINDIR%\Tasks folder. There will be other options, depending on how your domain/Group Policies are structured, but this illustrates an approach. It would be helpful to understand if the Search account should be added as well, but for now I’m going on what the installer/configuration wizard does rather than what TechNet fails to describe fully.

Next question: why isn’t this issue more common, given that the virus first emerged over two years ago? I suppose the group policy might not have been taken up by many organisations, but it’s more likely that there are further wrinkles I’ve not uncovered. I tried to replicate the problem in my single server + DC development environment, but frustratingly, everything worked fine after applying this group policy. I rebooted and confirmed the permission changes, ran a full crawl, ran a query and reviewed event logs, but all seemed fine. I even re-provisioned my Search Service Application and that succeeded. To be perfectly honest I’m not sure what to make of this. Perhaps this is only an issue once the search topology takes a specific shape? That feels like the most likely explanation. I hope to do more testing on this in future, but for now I wanted to identify a fix that worked for me and which aligns with the settings applied by the SharePoint installer/configuration wizard, should this problem arise for others. I’m not the first person to discover this problem. I think it’s actually been around since MOSS 2007, based on some forum posts, but I haven’t seen it described in relation to this Conficker protection, which hopefully helps make the Group Policy modelling decisions a bit less obscure.

More broadly, I’d be really curious to hear if anyone has information about the mismatch between TechNet and SharePoint default permissions on %WINDIR%\Tasks, and the further mismatch between the “Modify ACL” event, TechNet and the default settings. It may turn out that the WSS_WPG permissions are unnecessary or even undesirable, but given that SharePoint puts them there in the first place, I’m uncomfortable removing them until there’s better information to rely on.

When I initially created our SharePoint 2010 beta development environments, I built them in a Workgroup, for many of the reasons that I chose to do so in 2007 (see the Workgroup Development section in Part II of my series on SharePoint development environments). Now, the SharePoint 2010 Configuration Wizard (psconfigui) throws an error when choosing the Complete install option in a Workgroup. I was able to get past this error by following the suggestions on the Microsoft From the Field blog, but a few weeks down the road we’ve pinned down two issues (as confirmed by Neil, the author of that post).

1. Search will crawl successfully in this configuration, but the query role will never initiate. Queries from web applications that consume this Service Application will produce an error, which you will be able to trace to an application event log 6398 error and the key event in ULS, “The SDDL string contains an invalid sid or a sid that cannot be translated.” As Victor Magidson from Microsoft puts it on this Technet thread, this error occurs when a, “topology activation job is trying to create a propagation file share.” In short, the query role never finishes initialising so it will never serve queries. This only occurs on the single server Complete installation and deleting/re-creating the Service Application yields the same result.
2. The User Profile service application will also be useless*, but it always would have been since you couldn’t import users from the local user database in 2007 either. However, this has wider implications in SharePoint 2010 because of the social computing features, which developers probably won’t be able to live without.

All this means that I need to consider rebuilding our development environments in a domain or we need to use the Simple installation. In the past I always avoided the Simple installation because it uses system accounts like Network Service for application pool identities, so it took some re-acquaintance to identify some of its limitations. It has no configuration options (thus the use of local system accounts), the User Profile Service Application does not start (presumably per Forefront Identity Manager 2010 installation issues as seen in other topologies) and it uses SQL Server Express (which developers aren’t very fond of), so we’re unlikely to pursue this option. Accordingly, we’re reviewing the ways that we can re-create the development environment in a domain.

Why don’t I just make the development machine a domain controller? This isn’t clear-cut and there are benefits to the simplicity of it, but ultimately I think it’s a bad idea because:

• Domain Controller security is bad for development. It means developers will be coding as Domain Admins and they will be doing so on a machine with Domain Controller security policies. This is just a mess.
• SQL doesn’t like to run on a DC.
• Running a DC, SQL and SharePoint on the same machine creates a massive load of service start-up contention and sometimes the environment will start from an unstable point because dependent services will not be ready when a depending service tries to start.
  • This also increases start-up time considerably, which is a big concern when using Hyper-V on a laptop, where we don’t have Sleep/Hibernate.
• Adding Visual Studio to this mix causes known performance issues. The machine simply can’t keep up with doing all of this.

Why won’t we use a central development domain? Because then we can’t clone the VMs. We don’t just clone standard builds, we also use the same VM for each developer/consultant/architect on a single project. We may opt for this approach eventually, but I think the investment in automation is pretty considerable for it to be efficient with our team development requirements.

So I’m probably going to separate the DC on to a different server for now. I’m unlikely to add a third server for SQL, as even though it might be faster, I think the complexity of managing networking and snapshots across three servers is undesirable for developers, if we can get by with two.

All of this underlines the reasons why I didn’t publish any SharePoint 2010 build guidance yet. Some things don’t become clear until you get your hands dirty. I’ll revisit this topic as soon as I feel comfortable that we’re pinning things down, but for now we’re still adapting our methods.

*I’ll note that I haven’t properly tested Claims Based Authentication against a single server complete installation, so it’s conceivable that you could import non-A/D users in to this configuration, but you’d still need to live without Search.

This is the fourth post in a six-part series on SharePoint 2007 administrative commands. The first part was an overview, the second covered Farm administration, the third covered web application administration, and this post is devoted to Shared Service Provider (SSP) administration. The bulk of this post only applies to MOSS, as there is no SSP for WSS. This means that WSS does not provide:

• My Sites
• Audiences and all of the targeting functionality they unlock
• Search across site collections (which has massive implications to how WSS can scale)
• Any of the other features below, including the Business Data Catalog and Excel Services

What WSS does provide that is analogous but less robust is:

• WSS Search: search within a Site Collection
  • However, custom scopes and People Search are also missing
• User Information List: The UIL is populated from Active Directory with current user information at the time of the user’s first login. The user information list can have additional column data, but it needs to be updated manually rather than by scheduled synchronisation

Neither WSS Search nor the User Information List have configuration options.

The remainder of this post will focus on SSP administration in MOSS 2007.

User Profiles and My Sites

User profiles and properties

MOSS 2007 supports importing user profiles from Active Directory, other LDAP directories or custom profile stores. Additionally, SSP administrators can:

• Configure import schedules
• Manually add or view user profiles
• Manually run import jobs and review import logs
• Manage profile properties

User Profile planning is critical to populating profiles with accurate, relevant and current information. As User Profile data are the building blocks of audience compilation, the ramifications of poor planning are felt widely, as illustrated in more detail in the Audiences diagram above

Profile services policies

Profile services policies apply to user profiles and My Sites. Manage policy enforcement, attribute visibility and user override settings here

My Site settings

• Specify the Personal Site Provider application, path and naming format
• Disallow/allow users to choose the language of their own My Site from the list of language packs deployed to the server
• Update default membership of the My Site Reader group for newly created My Sites
• Specify a preferred Search Centre for searches initiated from the My Site

My Site Global Deployments

My Site global deployments are also configured within the My Site settings page and the trusted My Site locations are specified in the next screen below. This note from the SSP Administration site helps to explain My Site Global deployments:

Multiple My Site deployments can exist in the same environment allowing for specific users to have their My Site hosted by a different Shared Service Provider, this is common with global deployments. When a user’s My Site is hosted by a Shared Service Provider other than this one, that user will be blocked from using My Site related personalization features provided by this Shared Service Provider. The loss of functionality includes the ability to add users to their Colleagues list, the use of My Links and viewing people search results grouped by social distance.

Enabling My Site to support global deployments, will allow a users who’s My Site is hosted by a different Shared Service Provider to perform actions such as adding colleagues and links to their default My Site and viewing people search results grouped by social distance. To associate specific users with different Shared Service Providers use the Trusted My Site hosts list.

Note: It is recommended that you implement a profile replication solution before enabling My Site to support global deployments. Without a profile replication solution in place users that have their My Site hosted on a different Shared Service Provider will have a disconnected user experience.

Trusted My Site host locations

If My Site Global Deployments are enabled, this setting specifies the trusted My Site locations defined in other Shared Service Providers. Users are partitioned to distinct My Sites by audience or distribution/security group membership

Published links to Office client applications

Manage and Create audience-targeted links to SharePoint sites, useable through the My SharePoints tab in Office 2007 Open/Save As dialogue boxes. Note: this assumes Client Integration Features are enabled for the web application(s) and a supported authentication method is in use

Personalization site links

Adds audience-targeted or global links in between the My Home and My Site links, as below:

Personalization services permissions

Assign rights to create personal sites and use personal features. Delegate My Site management of analytics, audiences, profiles and permissions

Search

Search settings

General settings

• Specify content sources and crawl schedules
  • Crawl Settings
  • Specify the behaviour for crawling this type of content
    • Crawling everything under the hostname will also crawl all the SharePoint Sites in the server.
      • Crawl everything under the hostname of each start address if the links on the start address tend to point to relevant content
    • Select crawling behaviour for all start addresses in this content source
      • Crawl only the SharePoint site at each start address if the content available on linked sites is not likely to be relevant, and the content on the site itself is relevant

• Specify rules, such as inclusion/exclusion and unique authentication for specific paths
• Manage crawled file types
• Specify the default content access account
• Reset all crawled content
• Manage, create and view search scopes

Metadata Property Mappings

Map crawled properties to managed properties and determine inclusion of the managed property in search scopes

Add Server Name Mappings

Set up a translation from a crawled address to a search result’s rendering of that same location. This is a one-to-one replacement, as follows:

Configure Search-based Alerts

Search-based Alerts configuration options are useful for temporarily globally disabling Search-based alerts when a catalogue is reset, as users may receive a deluge of notifications when the crawl recompiles the catalogue

Specify Authoritative Pages

• Create lists of the most authoritative, second-level authoritative and third-level authoritative pages
• Demote non-authoritative sites
• Force immediate ranking updates

Search usage reports

View search usage statistics by month, year, originating-query-Site-Collections and Search Scope

Office SharePoint Usage Reporting

Usage reporting

Enable/disable advanced usage analysis processing for site and site collection administrators. Enable/disable search query logging for Search usage reports in the SSP administration site

Audiences

Audiences

• Create audiences by reporting chain or group membership, or based on user profile property rule satisfaction
• View/Delete rules
• Specify audience compilation schedules

A lot of planning needs to be invested in audiences due to the potential complexity of their use for targeting content throughout the organisation. To illustrate, see the chart at the top of this post.

Excel Services Settings

Edit Excel Services settings

Configure Excel Calculation Services security, load balancing, session management, memory utilisation, caching and external data connections

Trusted file locations

• Define WSS, UNC or HTTP trusted locations of Excel workbooks
• Define location-specific session management, workbook/chart size limits, calculation behaviour and external data connection rules
• Allow/disallow user-defined functions

Trusted data connection libraries

A list of trustworthy data connection library locations

Trusted data providers

Add/edit/delete trusted OLE DB, ODBC or ODBC DSN data provider types

User-defined function assemblies

Add/manage file or GAC paths to user-defined functions in .NET assemblies

Business Data Catalog

• Import application definitions
• View applications and entities
• Manage BDC permissions
• Edit the profile page template

Federated Search was integrated into MOSS 2007 with the post-SP1 Infrastructure Update, which effectively brought the Search Server 2008 product to the MOSS 2007 platform. Federated Search will pass a query from a single interface to multiple OpenSearch-compatible indices. It will then render matching results from these indices asynchronously as they return. In MOSS 2007 a federated search web part is added to a search results page and each web part renders only if results are found through that Search Connector. This works brilliantly, as local results will typically return first, then remote sources will render in due course.

This functionality has now been added to Windows Search. I think this is a fantastic move, as these choices will often be very preferential. I may want Wikipedia while you will want Britannica. I may roam among three branch offices and need to query each of the regional SharePoint portals. It’s very powerful stuff – especially when it moves to the client and can be configured to individual needs.

Find more Search Connectors on the Enterprise Search site. Read the Windows 7 Federated Search Provider Implementer’s Guide.