Running two Search Service Applications is a deliberate architectural choice. It gives you complete backend isolation — a full crawl of your SharePoint team sites cannot starve a My Sites crawl, and a hardware failure on the Collaboration index does not take personal content search offline. But this isolation creates a new problem: from a user’s perspective, search results are fragmented. A user on a SharePoint team site queries only the Collaboration SSA. Their personal OneDrive content, profile, and personal documents are invisible.

Federated search via Result Sources solves this by sending a coordinated secondary query to the My Sites SSA whenever a user searches from the Enterprise Search Centre. The user sees a unified results page. The backend isolation is preserved completely.

This post covers when to use this pattern, the trade-offs involved, and the exact configuration steps.

Note: My Sites in SPSE refers to OneDrive for Business on-premises (personal sites hosted on the My Site host). This is distinct from Microsoft Teams, which is a Microsoft 365 cloud product and is not available in on-premises SPSE deployments.

Why You’d Run Two Search Service Applications

The single-SSA model is simpler and works well for most farms. The dual-SSA pattern is a deliberate trade-off that makes sense when:

Crawl isolation is required. In a single SSA, all content sources share the same crawl component and the same crawl database pool. A large SharePoint team site performing a full crawl generates tens of thousands of crawl requests per hour. These requests compete directly with the My Sites crawl. At peak crawl load, My Sites content can fall days behind, causing personal documents to disappear from search results. Separate SSAs give each content type its own independent crawl pipeline.

Independent scaling is needed. Collaboration content in a large enterprise is typically an order of magnitude larger than My Sites content. The Collaboration SSA needs dedicated index servers with high IOPS SSD storage and more content processing capacity. The My Sites SSA can run on smaller hardware. With a single SSA, you must size the entire infrastructure for the largest workload.

Fault tolerance per content type. If the Collaboration index server needs emergency maintenance, a dual-SSA farm keeps My Sites search running. With a single SSA, any index component failure affects all content types.

Independent relevancy tuning. Document relevancy models, query rules, result sources, and promoted results are configured per SSA. Separate SSAs let you tune the collaboration search experience independently from the personal content search experience.

The Problem with Two SSAs: Search Silo

Separate SSAs do not communicate with each other by default. Each SSA has its own index, its own query processing pipeline, and its own result set. When a user searches from the Enterprise Search Centre (which is associated with the Collaboration SSA), the query goes only to the Collaboration SSA. My Sites content — OneDrive documents, user profile pages, personal notes — does not appear.

Users must navigate to the My Sites search to find personal content. This is a significantly degraded user experience. Most users do not know two search centres exist, and those who do find switching between them disruptive.

This is the search silo problem: perfect backend isolation with a fragmented frontend experience.

What Federated Search Solves

Federated search via Result Sources adds a coordinated background query to the search experience. When a user runs a search from the Enterprise Search Centre:

1. The primary query executes against the Collaboration SSA index as normal.
2. Simultaneously, a background query is sent to a Remote Result Source pointing at the My Sites SSA.
3. The results from the My Sites SSA are presented on the same page as a Result Block — a distinct result group (typically showing the top 3–5 personal results with a “See more personal results” link).

From the user’s perspective, one search returns content from both sources. From the infrastructure perspective, the two SSAs remain completely independent.

The key mechanism is the Remote SharePoint Result Source. It points the Search Centre’s query engine at a second SharePoint web application (typically the My Sites host), which has the My Sites SSA as its associated search provider.

Pros and Cons of the Dual-SSA Pattern

Advantages

Trade-offs

Prerequisites Before Configuration

Ensure the following are in place before beginning configuration:

Both SSAs are fully provisioned and crawling:

• Collaboration SSA has completed at least one successful full crawl of collaboration content.
• My Sites SSA has completed at least one successful full crawl of My Sites content.
• Both SSA topology pages show all components Active.

Web application SSA proxy associations are correct:

• The collaboration web application is associated with the Collaboration SSA proxy only.
• The My Sites web application is associated with the My Sites SSA proxy only.
• Verify in Central Admin → Manage Web Applications → Service Connections.

Claims-based authentication on both web applications:

Get-SPWebApplication | Select Url, UseClaimsAuthentication

Both should show UseClaimsAuthentication = True.

Correct service account permissions: The Collaboration SSA’s search crawl account must have Read access to the My Sites web application.

Configuration Steps: Creating the Remote Result Source

Step 1: Open the Collaboration SSA Management Pages

1. Open Central Administration.
2. Navigate to Application Management → Manage Service Applications.
3. Click on the Collaboration Search Service Application (not the proxy).

Step 2: Create a Remote Result Source

1. In the SSA management page, click Result Sources in the Queries and Results section.
2. Click New Result Source.
3. Fill in the following fields:

1. Click Save.

Note: The Remote Service URL must be the root URL of the My Sites web application, not a specific site collection within it.

Step 3: Test the Result Source

After saving, click Launch Query Builder on the Result Source page. Enter a search term you know exists in personal content and confirm results are returned.

If the test returns no results or an error, check:

• The Remote Service URL is reachable from the SharePoint application servers.
• The crawl/search service account has Read access to the My Sites web application.
• Claims auth is enabled on both web applications.

Step 4: Create a Result Block on the Search Results Page

1. Navigate to the Enterprise Search Centre.
2. Open the Search Results page in edit mode.
3. In the Collaboration SSA management page, click Query Rules.
4. Click New Query Rule.
5. Under Actions, click Add Result Block.
6. Configure the result block: Title: Personal Results; Query: {searchTerms}; Search this URL: select the Remote Result Source you created; Items: 3; Rank: Bottom of results page
7. Save the Query Rule.

Step 5: Verify with a Test Query

1. Navigate to the Enterprise Search Centre as a regular user (not farm admin).
2. Search for a term you know appears in a personal OneDrive document.
3. Confirm that primary results show collaboration site content and a distinct result block titled “Personal Results” appears with OneDrive/personal content.

When NOT to Use Federated Search

Federated search is the right answer in specific scenarios. It is the wrong answer when:

The farm is small. A single SSA is simpler to maintain, has no query overhead, and supports full refiner merging. For farms under 10TB with no crawl isolation requirement, dual-SSA architecture adds operational complexity with no meaningful benefit.

Query latency is already at its limit. If your Collaboration SSA query performance is already poor, adding overhead from a federated background query will push the user experience past acceptable limits. Fix the primary query performance before introducing federation.

Unified refiner filtering is a hard requirement. If the business requires that users be able to filter all results by the same Content Type or Author refiner, federation cannot deliver this. The solution in this case is a single SSA with content source isolation (not SSA isolation).

Summary

The dual-SSA pattern with federated search is a mature, production-proven architecture for large SPSE farms where crawl isolation and independent scaling are required. Federation via a Remote Result Source bridges the user experience gap without compromising the backend isolation that makes the dual-SSA pattern valuable.

The configuration is entirely UI-driven in Central Admin and the Search Service Application management pages. No scripting is required. The most common failure points are service account permissions on the My Sites web application and claims authentication consistency between web applications — both are easy to validate before beginning configuration.

👉 SPSE Search Topology Starter Kit (Production-Ready PowerShell + PDF Runbooks)

👉 SPSE Search Config Backup Kit

👉 SPSE Search Deployment Kit for Large Farms

👉 SPSE Crawl Optimisation Kit 

👉 Complete SPSE Search Architecture Pack

Related Posts

• Post #1: Designing the Right SharePoint Search Topology for Production SPSE Farms
• Post #2: Deploying a Custom SharePoint Search Topology with PowerShell (End-to-End)
• Post #3: Scaling SharePoint Search for Large Enterprise Farms: Index Distribution and Crawl Isolation
• Post #4: Controlling SharePoint Crawl Performance: Impact Rules and Crawl Rules