When you provision a Search Service Application through Central Administration, SharePoint places every search component on the server where you ran the wizard. Within seconds you have a working search index — and that is exactly what the default setup is designed to do. It is an excellent starting point for development environments, pilots, and small farms where simplicity matters most.

Production farms have different requirements. As content volume grows, as the number of concurrent users increases, and as availability expectations tighten, the topology decisions you make at provisioning time directly affect crawl throughput, query latency, and fault tolerance. The default setup does not come with those decisions pre-made — making them yourself, deliberately, is what separates a production-ready search deployment from a default one.

This post explains what the default topology gives you, what additional design choices are needed for production, and how to approach those decisions for farms of different sizes. It is the conceptual foundation for the rest of this series.

Default Topology: What It Gives You and What Production Requires

All Six Components on One Server

The Central Administration wizard places every search component on the current server. For a development farm or a small pilot with a few hundred documents, this is ideal — one server, one setup step, everything in one place.

On a production farm with millions of items and hundreds of concurrent users, sharing all six components on a single server means:

• Crawl I/O (downloading documents from WFEs) competes with Index I/O (writing to and reading from the on-disk index).
• Content processing (parsing Office documents, extracting entities) demands CPU at the same time query processing is serving live user searches.
• Analytics processing runs its continuous background jobs against the same memory pool.

The default setup does not prevent this — it simply leaves the placement decision to you. Explicitly distributing components across servers is a standard production configuration step, not a workaround.

Single Crawl Database

The default topology creates one crawl database. The crawl database is write-heavy during every incremental and full crawl — it records every URL encountered, every item’s last-modified time, and every crawl error. On a large content corpus, a single database concentrates write load and can cause crawl queue depth to grow faster than the crawlers can process it. Adding crawl databases per content type is a recommended step for farms beyond a certain content volume.

High Availability Is Not Configured by Default

A single-server topology places all components on one server. Distributing components across multiple servers — so that a maintenance event or restart on one server does not take search offline — is a configuration step that needs to be planned and executed explicitly. For most enterprise deployments, HA for the search index is a standard requirement.

Content Source Isolation Is Not Configured by Default

The default topology does not distinguish between content sources. A large collaboration content crawl and a My Sites personal content crawl share the same crawl threads, the same crawl database write capacity, and the same content processing pipeline. On a farm with high crawl volume across both content types, explicitly separating content sources — or splitting into dual SSAs — gives you control over each pipeline independently.

The Six Search Components and What Each Does

SharePoint’s search engine is divided into six distinct components. Understanding what each component does is essential before you decide where to place it.

Note: The Admin component controls the health of the entire SSA. If it goes offline, the topology cannot be modified and health reporting stops. Always place it on a reliable, always-on application server.

Each component can be placed independently on any server that has the Search Service Instance running. This flexibility is the foundation of a well-designed topology.

Single SSA vs. Dual SSA: When to Split

Single SSA

A single Search Service Application manages one unified index that covers all your content. The entire crawl pipeline — all content sources — feeds into one index, and all query processing reads from the same index store.

Best for: Farms with a homogeneous content corpus up to approximately 10TB of crawled content, where crawl isolation is not required.

Dual SSA Pattern: Collaboration SSA + My Sites SSA

As the farm grows, a common pattern is to split search into two independent SSAs:

• Collaboration SSA — covers SharePoint team sites, document libraries, project sites. Typically the larger corpus with heavy document content.
• My Sites SSA — covers My Sites (OneDrive for Business on-premises), user profiles, personal documents.

Splitting SSAs provides:

• Independent crawl pipelines — collaboration content crawl load never affects My Sites crawl throughput.
• Independent scaling — the Collaboration SSA can run on larger hardware; the My Sites SSA on smaller.
• Fault isolation — if the My Sites SSA’s index server fails, collaboration search continues uninterrupted.
• Independent relevancy tuning — you can configure ranking weights, managed properties, and best bets independently per SSA.

The cost of this pattern is that a user on a SharePoint team site cannot see My Sites content in their search results by default. Post #5 in this series covers how to bridge this gap with federated search via Result Sources.

Topology Design for a Small to Medium Farm (4–6 Servers)

For a farm with 2–4 WFEs, 2 App servers, and a SQL cluster (a common SPSE medium-farm layout), a practical topology looks like this:

• Both App servers are on the ApplicationWithSearch MinRole.
• All six search components are placed on both App servers, providing full HA for every component.
• Index partition 0 is hosted on both App servers (primary + replica).
• The single crawl database is adequate for up to approximately 5–10TB of content.

APP-SERVER-1                    APP-SERVER-2
─────────────────               ─────────────────
Admin Component                 Admin Component
Crawl Component                 Crawl Component
Content Processing              Content Processing
Analytics Processing            Analytics Processing
Query Processing                Query Processing
Index (Partition 0, Primary)    Index (Partition 0, Replica)

The Set-SPSearchCustomTopology.ps1 script in this post’s scripts/ folder implements this layout. It accepts a list of server names and places all components on each one.

Prerequisites

Before running either script:

• Both App servers must be members of the farm with the ApplicationWithSearch or Custom role.
• The Search Service Instance must be startable on both servers (check via Central Admin → Manage Services on Server).
• Index directories must exist on each server: create D:\SearchIndex (or your chosen path) before running.
• SP Search service account: Full Control; WSS_ADMIN_WPG: Full Control; WSS_WPG: Read
• All managed accounts (AppPoolAccount, SearchServiceAccount, ContentAccessAccount) must be registered with Register-SPManagedAccount before running the scripts.

Running the SSA Creation Script

New-SPSearchServiceApplication.ps1 creates the SSA on a single server first:

.\New-SPSearchServiceApplication.ps1 `
    -ServerName "<APP-SERVER-1>" `
    -SSAName "Search Service Application" `
    -IndexLocation "D:\SearchIndex" `
    -AppPoolAccount "<DOMAIN>\<AppPoolServiceAccount>" `
    -SearchServiceAccount "<DOMAIN>\<SearchServiceAccount>" `
    -ContentAccessAccount "<DOMAIN>\<SearchContentAccessAccount>"

The script derives the SQL server automatically from the farm’s Configuration Database — no SQL server name is hardcoded. It uses Get-SPManagedAccount to retrieve accounts, so no passwords are passed as parameters or stored in the script.

Validating the Single-Server SSA

After the script completes:

1. Open Central Admin → Manage Service Applications → Search Service Application → Search Topology.
2. Confirm all six components show status Active.
3. Verify the SSA proxy appears in Central Admin → Manage Service Applications.

Applying the HA Topology

Once the single-server SSA is running, apply the HA topology across both App servers:

.\Set-SPSearchCustomTopology.ps1 `
    -SSAName "Search Service Application" `
    -SearchServers "<APP-SERVER-1>", "<APP-SERVER-2>"

This script:

1. Waits out any in-progress topology activation (prevents the “already activating” error).
2. Removes all inactive or failed topologies (prevents the “duplicate component” error).
3. Creates a fresh topology (not a clone) and places all components on every listed server.
4. Activates the topology and waits for confirmation before removing the legacy topology.

Validating the HA Topology

After topology activation:

1. In the Search Topology view, confirm every component appears twice — once per server.
2. Run a test query from the Search Centre and confirm results are returned.
3. Start a Full Crawl from the content source and monitor the crawl log for errors.

Topology Design for a Large Farm (80M+ Items)

At 80 million items and above, placing the Index component on the same servers as Content Processing is no longer viable. The Index component needs dedicated SSD storage, controlled IOPS, and sufficient memory for index caching. Sharing these resources with document parsing workloads causes index read latency to spike during active crawls.

The large farm reference architecture introduces:

• 3× dedicated Index servers — host only Index components across multiple partitions.
• 3× Application servers — host Crawl, Content Processing, Query, and Analytics components.
• Multiple crawl databases — one per content type, distributing write load across SQL.

This architecture is covered in depth in Post #3: Scaling SharePoint Search for Large Enterprise Farms.

Choosing the Right SQL Placement for Search Databases

Search creates several SQL databases, each with a different access pattern. Placing them correctly matters at scale.

For farms under 50TB, all search databases can share a SQL instance as long as that instance is on separate disk from the SharePoint content databases. For farms above 50TB, placing crawl databases on a dedicated SQL instance significantly reduces contention during large crawl runs.

Note: The index is stored on disk on the Index component server, not in SQL. The size of the on-disk index is typically 15–25% of your raw content volume after text extraction and compression.

Summary

The default SharePoint search topology is designed for rapid provisioning and works well for development and smaller environments. For production farms, several deliberate design choices are needed on top of the default:

1. Identify whether your farm needs a single SSA or a dual SSA pattern.
2. Decide which servers will host which components based on the resource profile of each.
3. Pre-create index directories with correct permissions on all index-hosting servers.
4. Register all required managed accounts in the farm.
5. Plan SQL placement based on the access pattern of each search database.

For a small to medium farm, New-SPSearchServiceApplication.ps1 and Set-SPSearchCustomTopology.ps1 in this post’s scripts/ folder implement a solid, HA-ready topology that can be in place within a single maintenance window.

👉 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 #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
• Post #5: Federated Search in SPSE: Searching Across Multiple Search Service Applications