Decide where the index lives, then prove that search on your own farm

Microsoft documents "two variants of hybrid search": cloud hybrid search and hybrid federated search (hybrid search, checked on 13 November 2026). The first sends what a farm crawler gathers to the tenant's index, so "search results come from one search index". The second leaves each index where it is, so "search results come from two indexes". In 2024 and 2025 Microsoft retired one direction of the second and the service behind the first, and its pages have not all caught up.

Which hybrid search, if any, does this farm run: one index in Microsoft 365, two indexes queried side by side, or both, and on which update is that documented?

The decision this chapter leads to is one recorded search architecture (cloud hybrid search, outbound federated search, both, or none), with the content each covers, the update it depends on and the test that proved it on your farm.

What this chapter settles

It settles which of the two architectures you configure, what each sends out of the farm, the documented procedure for each, the checks that prove it and what Microsoft documents about leaving.

It takes from Chapter 1 the farm's version, update level and the decision to run hybrid at all, and from Chapter 2 the synchronised accounts, the server-to-server trust and the Windows sign-in that both searches depend on. It hands Chapter 6 the question of what may be indexed outside the network, Chapter 7 the monitoring, and Chapter 8 the exit.

It leaves out the search dependencies of a migration (refiners, query rules, rollups, the full crawl after an attach): the first book's Chapter 11 decides those. Microsoft Graph connectors, which Subscription Edition supports "Starting from Version 16.0.17928.20238 released in November 2024" (Version 25H1, checked on 13 November 2026), are a different mechanism and are not covered. An index is not a migration: neither search moves a document.

Applies to

Sources for the table: hybrid search (above), removed from 2016, removed from 2019, removed from Subscription Edition and configure cloud hybrid search, all checked on 13 November 2026.

SharePoint Server 2016 and 2019 are themselves out of support: their servicing policies end on 14 July 2026 (2016 servicing policy, 2019 servicing policy, both checked on 13 November 2026). A 2016 or 2019 farm does not have to host the cloud Search service application to be searched: "SharePoint Server Subscription Edition supports crawling of existing SharePoint Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition content farms" (hybrid search).

Architecture

Two architectures

Sources for the table: hybrid search, configure cloud hybrid search, learn about federated search and plan federated search, checked on 13 November 2026.

The 2025 change

The roadmap, which is the procedure page, says: "Search Content Service (SCS), an internal component of Cloud Hybrid Search in SharePoint in Microsoft 365 has been retired from June 30, 2025. To continue using Cloud Hybrid Search by then, upgrade your SharePoint Server farm to SharePoint Server Subscription Edition July 2025 PU or later versions. Without this upgrade, all versions of SharePoint Server 2019/2016 and previous versions of SPSE can only search for on-premises and Microsoft 365 content separately through Hybrid Federated Search after this retirement" (configure cloud hybrid search). The update is two actions: "patching for SharePoint Server and reonboarding the Hybrid Search Service Application (Cloud SSA) in the on-premises farm using a PowerShell script" (Version 25H1). The script is Onboard-CloudHybridSearch-SPOONS.ps1, and a farm that ran the old service must "onboard Hybrid Search again" with it.

Three other pages name a different level, and still announce the retirement of that date as something to come: the farm needs "SharePoint Server Subscription Edition (SPSE) Version 25H1 or later versions" (learn about cloud hybrid search, plan cloud hybrid search and removed from Subscription Edition, checked on 13 November 2026).

The update history gives each a build. Version 25H1 is KB 5002698, build 16.0.18526.20080, March 2025, where the "Cloud Hybrid Search upgrade" sits in the Early release ring. The July update is KB 5002751, build 16.0.18526.20424, of 8 July 2025, whose article says it "Enables flight for the new Hybrid Search feature in the Standard release ring" (SharePoint updates, KB 5002698, KB 5002751, checked on 13 November 2026). Version 25H2 lists the upgrade as "Standard release" (Version 25H2, checked on 13 November 2026). A second update, KB 5002768 (16.0.18526.20508), shipped on 21 July 2025; no page says which of the two "July 2025 PU" means.

We would follow "July 2025 PU or later versions": it is on the procedure page, it is written in the past tense, and KB 5002751 is the update that turns the feature on for a farm in the Standard release ring. In practice the question is closed by another rule. Each public update "will be supported for one year from its release date" (Subscription Edition servicing policy, checked on 13 November 2026), so both builds are out of support today, and a supported farm is past both. The latest listed is KB 5002945, build 16.0.20326.20278, of 10 November 2026.

Pages that still describe the old state:

• The minimum update table lists "Cloud hybrid search | RTM" for 2019 and 2016 and has no table for Subscription Edition (minimum update levels, checked on 13 November 2026).
• The FAQ says the cloud Search service application "can only be installed in SharePoint Server 2013 through SharePoint Server 2019 environment" (cloud hybrid search FAQ, checked on 13 November 2026).
• The overview's body still says "You set up a SharePoint farm running SharePoint Server 2013 or SharePoint Server 2016 and create the cloud SSA on this farm" (learn about cloud hybrid search).

We would follow the roadmap and hybrid search pages against all three: they carry the retirement in the past tense and mark only Subscription Edition as applicable.

What is not established about the new service

• What replaced the Search Content Service. No page names the service, its endpoint or how the farm authenticates to it. The FAQ still says the crawler "passes what it can gather to the Search Content Services in the cloud". We do not know.
• The endpoints. The roadmap says they "are listed in the SharePoint in Microsoft 365 section of the article Microsoft 365 URLs and IP address ranges and are marked for use with Hybrid Search". The SharePoint section of that page, as we read it, carries no such marking (Microsoft 365 URLs and IP address ranges, checked on 13 November 2026). The FAQ lists *.sharepoint.com, https://accounts.accesscontrol.windows.net, https://login.windows.net/common/oauth2/authorize, https://sts.windows.net/* and https://login.microsoftonline.com, all on port 443, but that list predates the change. We do not know the current set. The test: run a full crawl of a small content source on a test farm behind your real outbound rules, and read the proxy or firewall log for what the search servers called.
• The permissions the onboarding consent grants. The step reads "Accept the requested permissions." and says no more. Read the consent screen when it appears and record it.
• Whether a full crawl is required after onboarding again. Not stated. Compare the item count for IsExternalContent:true before and after, and plan the window for a full crawl.
• Whether the Hybrid Configuration Wizard performs the new onboarding. Its option "creates a cloud Search service application in SharePoint Server and connects it to your Microsoft 365 organization", and "you must do the rest of the steps yourself" (Hybrid Configuration Wizard, checked on 13 November 2026). No page says whether "connects" now means the new script's onboarding. We would run the script, which the roadmap documents.

Azure ACS is a separate matter: no page links the two retirements, and the ACS page says its retirement "is not impacting any of the SharePoint on-premises use cases" and names hybrid search (ACS retirement, checked on 13 November 2026).

What is sent, and how results are trimmed

Microsoft's pages do not agree on what leaves the farm. The overview says "It's the metadata for the content that's indexed, and this metadata is encrypted when it's transferred to the search index in Office 365, so the on-premises content remains secure". The FAQ says the "Crawler sends the encrypted content to the Indexing API", that an Insert "Creates or overwrites a document's content and access control list", and that a batch "consists of ACLs, keywords, metadata, destination tenant info, etc.". No page defines whether the text extracted from a document counts as "metadata". We would plan as if the indexed text leaves the network, because that is the reading under which a wrong guess costs least, and settle it in Chapter 6.

Authorisation travels with each item: "The Microsoft 365 search index stores the ACLs together with the item, so the system needs to be able to recognize an on-premises user as the same person in Microsoft 365" (plan cloud hybrid search). That depends on directory synchronisation, which is not single sign-on: the FAQ says single sign-on "is not a mandatory prerequisite". The FAQ gives the mapping: user SIDs "are mapped to passport unique ID (PUID)", group SIDs "to Object IDs", and NT AUTHORITY\Authenticated Users and Everyone "are translated to" the tenant's "Everyone except external users". Results are then "security trimmed based on the user's Microsoft 365 identity".

Three limits follow, all documented:

• Default security groups. Members of Domain Users get no on-premises results, because the synchronisation tool excludes groups "that have the attribute IsCriticalSecurityObject=true ... and Domain Users is an example". Grant access through "the Everyone group, the Authenticated Users group, or a custom group" (plan cloud hybrid search).
• SAML. "Items secured with SAML claims when crawled using Cloud Search Service application will not show up in search results"; this "is by design", and the service "only supports Windows identity that has been synced to Microsoft Entra ID" (FAQ). The page does not mention OpenID Connect; we do not know how items secured that way are trimmed, and the test is a query by a user who holds access only through such a claim.
• Custom security trimming "isn't available with cloud hybrid search", and neither are thesauruses, custom entity extraction, the content enrichment call-out or cross-site publishing search (learn about cloud hybrid search).

The quota is "1 million items of on-premises content" for "each 1 TB of pooled storage space", up to "the threshold of 20 million items", beyond which you contact Microsoft Support (plan cloud hybrid search).

Prerequisites

For both searches, Chapter 2's work must be done: a registered public domain, matching UPN suffixes, synchronised and licensed accounts (configure Microsoft 365 for hybrid, checked on 13 November 2026).

For cloud hybrid search (configure cloud hybrid search, plan cloud hybrid search, FAQ):

• A server: "Minimum 100 GB storage, 16 GB RAM, and four 1.8 GHz CPUs", with Subscription Edition installed, a member of an Active Directory domain. The planning page gives the same sizing for each application server and each database server.
• One cloud Search service application: "Each search farm can have only one cloud SSA, but can have multiple SSAs in combination with the cloud SSA". It shares a farm with a standard one only if the two "don't share hardware between any components".
• A new service application: "You can't convert an existing SSA to a cloud SSA", and CloudIndex is set at creation: "you can't change this value later".
• Accounts: "a search account for cloud hybrid search in SharePoint Server, and a managed account for default content access", which needs "at least read access to the content to crawl". The crawler needs Windows authentication on the default zone (OIDC with Microsoft Entra ID, checked on 13 November 2026), and the FAQ says to crawl the Default zone.
• Topology: the content processing, index and analytics components of a cloud Search service application "are idle". The default lands on the Central Administration server; CreateCloudSSA.ps1 can place it on two servers. For high availability the FAQ asks for "at least two servers", where "each machine hosts all the search roles", and "one crawl database for each 20 million items".
• Outbound access to the endpoints, which are not established (above), with TLS 1.2: the Search service "will no longer accept connections that use TLS 1.1 or 1.0" (hybrid search failures, checked on 13 November 2026).

For outbound federated search: the outbound roadmap completed, "at least one local crawl", an Enterprise Search Center site collection (plan federated search), and a Search Center web application using "Integrated Windows authentication with NTLM" (configure server-to-server authentication, checked on 13 November 2026). The requirements page says plan E1 "supports Display hybrid federated search results in SharePoint Server only" (hybrid requirements, checked on 13 November 2026); its plan names are dated, so confirm yours with Chapter 1.

Decision criteria

Conditions that stop cloud hybrid search: no synchronised Windows identities; a farm that must feed two tenants (a farm "can only attach to one tenant", in text that names 2013 and 2016); two farms crawling the same content into one tenant, which "is not supported" (FAQ). We would not choose it for a farm whose remaining life is shorter than the time to prove it.

Procedure

Cloud hybrid search

The roadmap has ten steps (configure cloud hybrid search). On a farm that ran the old service, steps 3, 7 and 8 are the ones to repeat.

1. Configure Microsoft 365 for hybrid: Chapter 2.

2. Create the cloud Search service application. In Central Administration, or with CreateCloudSSA.ps1: on the server that hosts Central Administration, "using the same user account as when you installed SharePoint Server", in a PowerShell console run as administrator. It prompts for the search server's host name, a second search server if planned, the "Search service account in this format: domain\username", a name for the cloud SSA and the database server. A script of your own passes -CloudIndex $true to New-SPEnterpriseSearchServiceApplication.

3. Connect it to the tenant. On the same server, first "Ensure that the date and time of the server is synchronized with the other servers in the SharePoint Server farm". Download Onboard-CloudHybridSearch-SPOONS.ps1 from the Microsoft Download Center and run it as Microsoft writes it:

   PowerShellCopy code

   .\Onboard-CloudHybridSearch-SPOONS.ps1 -PortalUrl <SPOTenantPortalUrl> -CloudSsaId <CloudSSAIdCreated>

   Microsoft's documented commands, quoted as its page prints them. Not run by us: try them on a test farm first.

   "SPOTenantPortalUrl is the URL of your company's or organization's SharePoint portal, and CloudSsaId is the id of the cloud SSA that you created earlier", for example https://tenant.sharepoint.com, which is an example. "When prompted, sign in your Office 365 tenant as an Global Administrator or above", "Accept the requested permissions", then sign in again with the same account in the second window.

4. Set up the search architecture, only if it differs from the default.

5. Create a content source. Microsoft recommends "a small on-premises content source, for example a small file share, to test".

6. Set up a validation Search Center before the first full crawl (see Verify).

7. Start a full crawl of the content source.

8. Verify.

9. Tune: the schema for on-premises content is managed in Microsoft 365, "at the tenant level" only.

10. Remove the validation Search Center and set search to the default result source.

The Microsoft Graph PowerShell module is stated three ways. The roadmap's prerequisites say "You'll also need the Microsoft Graph Powershell module". Its step says "Download and install version 2.25.0 ... This step isn't required if you're using Onboard-CloudHybridSearch-SPOONS.ps1", with the command Install-Module Microsoft.Graph -RequiredVersion 2.25.0. The FAQ says "you need to ensure you have the latest version". We would follow the step, since it is the only one that names the new script, and run the script once on a test farm without the module to see whether it asks for it.

Behind a forward proxy, "it may be necessary to configure additional proxy settings" for Search, and "to configure the machine.config", at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config (configure cloud hybrid search).

The FAQ says the earlier onboarding script set the farm's authentication realm with Set-SPAuthenticationRealm, after which "existing SharePoint Add-ins fail to authenticate; users will get an HTTP 401". We do not know whether the new script does the same: read Get-SPAuthenticationRealm before and after on a test farm.

Outbound federated search

Four steps (outbound roadmap, checked on 13 November 2026): configure Microsoft 365 for hybrid; set up the services; configure server-to-server authentication, skipped "If you've already configured hybrid sites features"; display the results.

The last step is done by "an administrator for the Search service application" (display federated results in SharePoint Server, checked on 13 November 2026). Create a result source with Protocol set to Remote SharePoint, the tenant's root site collection as the remote service URL, type SharePoint Search Results and Default Authentication; the default transform is {searchTerms}. Then create a query rule that fires a result block from it. Both can sit at the service application, site collection or site level (plan federated search).

The server-to-server page adds a step 7, dated October 2021, for federated search: Update-FederatedHybridSearchForM365.ps1 -HybridWebApp YourHybridWebApplication -Force, signing in with a "Microsoft 365 Application Administrator account". It "must be run on a server where SharePoint On-Premises is installed (2013, 2016, or 2019)" and "attempts to install the required module dependencies (MSOnline, AzureAD)", modules Microsoft lists as deprecated (Graph PowerShell migration, checked on 13 November 2026). Subscription Edition is not named. We do not know whether the step applies to it. The test: configure the result source on a test farm and query as a synchronised, licensed user; if no Microsoft 365 block returns, this step is the first thing to examine.

Verify

Cloud hybrid search, as documented:

The first check names one property and reads another, in one sentence. We would read both and record both values:

# Farm server, SharePoint Management Shell. Reads the cloud Search service application; changes nothing.
$ssa = Get-SPEnterpriseSearchServiceApplication "<CloudSSAName>"
Write-Host "Reading Id, CloudIndex and IsHybrid of $($ssa.Name)"
$ssa.Id
$ssa.GetProperty("CloudIndex")
$ssa.GetProperty("IsHybrid")

Parsed, not yet run: try it on a test farm first.

The query is also written two ways on that page: "IsExternalContent:true" in the roadmap table and "IsExternalContent:1" in the procedure. Run both. Run them as a user who has access to the crawled content, and not through "one of the default security groups".

The validation Search Center keeps the change away from users until you are ready. Create a result source whose query transform is {?{searchTerms} NOT IsExternalContent:true} and point the existing Search Center at it; create a second Search Center on the default result source, with access for "only testers and administrators". One thing cannot be staged: "When metadata from on-premises content is in the Office 365 search index, Delve will display this content" (plan cloud hybrid search).

Federated search: sign in to the farm "as a federated user who has been activated in SharePoint in Microsoft 365 and who has permissions to view the root site collection", search, and expect two result blocks (display federated results in SharePoint Server).

When it fails

For monitoring, Microsoft documents little. Subscription Edition's crawl log has an online ID column "when SharePoint Farm is configured with cloud hybrid search" and a Warning breakdown pivot (new in Subscription Edition, checked on 13 November 2026). The FAQ names a ULS category, "Crawler:Azure Plugin" at VerboseEx, and a counter set, "Search Gatherer Azure Plugin - SharePointServerSearch"; both predate the 2025 change and we do not know whether the names survive it. Feeding "might" be throttled "if you crawl on-premises content at a high rate". Microsoft 365 usage reports hold nothing about actions on farm sites, and usage analytics "isn't operational" for this content. Not documented: a tenant-side view of what a farm has fed, an alert when feeding stops, or a freshness target. Chapter 7 builds the routine from the IsExternalContent count and the crawl log.

Security

• What is exposed, and to whom. With cloud hybrid search, the index entry and ACL of every crawled item sit in Microsoft 365, visible to synchronised users the ACL allows. An item granted to Everyone or Authenticated Users on the farm is granted to "Everyone except external users" in the tenant: read those grants before the first crawl.
• What limits it. Trimming on the Microsoft 365 identity, and nothing custom. Content you exclude with content sources and crawl rules is not sent.
• The sign-in. Onboarding asks for "Global Administrator or above", which Microsoft elsewhere says "should be limited to emergency scenarios" (accounts for hybrid, checked on 13 November 2026). No lower role is documented. We would elevate one account for the run and record the consent.
• Federated search sends queries, not items, and outbound is "generally the safest hybrid federated search solution because, unlike inbound hybrid search, it doesn't involve receiving unsolicited calls from the Internet" (plan federated search). We would retire a reverse proxy kept only for inbound search, unless it opens on-premises results from outside.

One page still describes configuring inbound results with no retirement note (display federated results in SharePoint in Microsoft 365, checked on 13 November 2026), while hybrid search says inbound "has been retired as of September 2024" and that outbound "and Cloud hybrid search remain operational". We would follow the retirement: it is dated and repeated on five of the pages we read.

Rollback and recovery

Microsoft documents the way out of cloud hybrid search in three sentences: "Cloud Hybrid Search may be removed by deleting the Search Service Application", "Before deleting the Search Service Application, make sure to delete the content sources", and "If you want to remove all hybrid documents from SharePoint Online search results, contact the support team for further guidance" (removing hybrid scenarios, checked on 13 November 2026).

On removing what is already indexed, the pages disagree. The planning page says "remove all the on-premises content sources". The overview and the roadmap say "open a ticket with Microsoft Support". We would do both in that order: delete the content sources, since the removal page requires it anyway, query IsExternalContent:true, and open the ticket if anything still returns.

What Microsoft does not document: how long items stay in the Microsoft 365 index after their content source is deleted; what happened to items fed by farms that were never updated; whether onboarding can be undone, since no offboarding script is named; and what the consent leaves in the tenant. We do not know. The test for the first is the item count over the days after a test content source is deleted.

For recovery, the FAQ describes a second cloud Search service application for disaster recovery that must not crawl the same content unless failed over. A new one starts from a full crawl, since an existing one cannot be converted.

For federated search, the part of the removal page we read names no steps. The procedure creates a result source and a query rule: we would delete the rule, then the source, and confirm one result block. The wizard "doesn't uninstall features". The trust is shared with other hybrid features, so its removal belongs to Chapter 8.

Working documents

The Hybrid Architecture Advisor generates these from your answers about the farm; what you did not answer is left as unknown, not guessed.

• Search Decision Matrix (Excel): one row per body of content, with the architecture chosen, the update it depends on, how access is granted and what stops it.
• Configuration and Validation Runbook (Word), the search part: the documented steps above in order, with the account for each and the evidence to keep.
• Validation Checklist (Excel), the search rows: each check in Verify with its expected result, who ran it and when.

Sources

• Hybrid search in SharePoint in Microsoft 365, checked on 13 November 2026
• Learn about cloud hybrid search for SharePoint in Microsoft 365, checked on 13 November 2026
• Plan cloud hybrid search for SharePoint in Microsoft 365, checked on 13 November 2026
• Configure cloud hybrid search - roadmap, checked on 13 November 2026
• Cloud hybrid search service (Cloud SSA) FAQ, checked on 13 November 2026
• Show results from Microsoft 365 in on-premises SharePoint with cloud hybrid search, checked on 13 November 2026
• Minimum public update levels for SharePoint hybrid features, checked on 13 November 2026
• Learn about hybrid federated search for SharePoint in Microsoft 365, checked on 13 November 2026
• Plan hybrid federated search for SharePoint Server, checked on 13 November 2026
• Configure hybrid federated search from SharePoint Server to SharePoint in Microsoft 365 - roadmap, checked on 13 November 2026
• Display hybrid federated search results in SharePoint Server, checked on 13 November 2026
• Display hybrid federated search results in SharePoint in Microsoft 365, checked on 13 November 2026
• Configure server-to-server authentication from SharePoint Server to SharePoint in Microsoft 365, checked on 13 November 2026
• Configure Microsoft 365 for SharePoint hybrid, checked on 13 November 2026
• Accounts needed for hybrid configuration and testing, checked on 13 November 2026
• Hardware and software requirements for SharePoint hybrid, checked on 13 November 2026
• Hybrid Configuration Wizard in the SharePoint admin center, checked on 13 November 2026
• Removing SharePoint hybrid scenarios, checked on 13 November 2026
• New and improved features in SharePoint Server Subscription Edition, checked on 13 November 2026
• New and improved features in SharePoint Server Subscription Edition Version 25H1, checked on 13 November 2026
• New and improved features in SharePoint Server Subscription Edition Version 25H2, checked on 13 November 2026
• What's deprecated or removed from SharePoint Server Subscription Edition, checked on 13 November 2026
• What's deprecated or removed from SharePoint Server 2019, checked on 13 November 2026
• What's deprecated or removed from SharePoint Server 2016, checked on 13 November 2026
• Updated Product Servicing Policy for SharePoint Server Subscription Edition, checked on 13 November 2026
• Updated Product Servicing Policy for SharePoint Server 2019, checked on 13 November 2026
• Updated Product Servicing Policy for SharePoint Server 2016, checked on 13 November 2026
• SharePoint updates, checked on 13 November 2026
• March 11, 2025, update for SharePoint Server Subscription Edition (KB5002698), checked on 13 November 2026
• Description of the security update for SharePoint Server Subscription Edition: July 8, 2025 (KB5002751), checked on 13 November 2026
• Set up OIDC authentication in SharePoint Server with Microsoft Entra ID, checked on 13 November 2026
• Hybrid search fails to crawl or return results, checked on 13 November 2026
• SharePoint Online content isn't displayed in a SharePoint on-premises search, checked on 13 November 2026
• Microsoft 365 URLs and IP address ranges, checked on 13 November 2026
• Azure ACS retirement in Microsoft 365, checked on 13 November 2026
• Upgrade from Azure AD PowerShell to Microsoft Graph PowerShell, checked on 13 November 2026

Related pages on this site

• Chapter 1 of this guide: readiness and the architecture decision, including the farm's update level.
• Chapter 2: identity, authentication and trust, which both searches depend on.
• Chapter 6: security, compliance and governance, for what may be indexed outside the network.
• Chapter 7: operations, monitoring and recovery.
• Chapter 8: migration, coexistence and exit.
• Decide every search dependency before the destination is built, in the SharePoint Migration Field Guide: the decision on search dependencies in a migration.
• Keep hybrid only for named features and keeping Subscription Edition supported, in the same book.
• Hybrid Architecture Advisor, for the working documents above.
• Microsoft 365 endpoints, for the outbound allow list.
• Install a Subscription Edition update without downtime.

Before you continue

• The architecture is recorded: cloud hybrid search, outbound federated search, both or none, with the content each covers
• The farm's build is read and is a supported Subscription Edition update, later than the July 2025 public update, if cloud hybrid search is chosen
• No plan relies on inbound federated search, or on cloud hybrid search hosted on 2016, 2019 or an earlier Subscription Edition build
• Content granted through Domain Users, SAML claims, Everyone or Authenticated Users is listed, with what each grant becomes in Microsoft 365
• A farm that ran the old service has been onboarded again with Onboard-CloudHybridSearch-SPOONS.ps1, and the consent screen is recorded
• The endpoints the search servers called during a test crawl are read from the proxy or firewall log and allowed
• Both IsExternalContent queries return the test content in a validation Search Center, and the CloudIndex and IsHybrid values are recorded
• The exit is rehearsed: content sources deleted, the service application deleted, and the decision made on a support ticket for what stays in the index

Download chapter 3 (PDF)Same text, same tables, same sources as this page.