SharePoint Hybrid Sync, Permission, and Access Errors, All Fixes
Why SharePoint Hybrid Errors Happen
I've seen this exact scenario play out on dozens of enterprise SharePoint deployments: you spend days, sometimes weeks, configuring SharePoint hybrid search between your on-premises farm and Microsoft 365. You follow the setup wizard, tick all the boxes, set up the result sources, configure the query rules. Then a user runs a search from a SharePoint Online site and gets nothing back from on-premises. Or worse, they hit this message:
Sorry, something went wrong. (Search has encountered a problem that prevents results from being returned. If this issue persists, please contact your administrator)
I know how demoralizing that is after all that configuration work. The error message tells you absolutely nothing useful. And if you try to open Query Builder from the result block inside the associated query rule in SharePoint Online, you get slapped with a 401 Unauthorized deep inside a stack trace referencing Microsoft.SharePoint.Client.ClientContext and RemoteSharepointProducer. Not exactly the friendly guidance you were hoping for.
So what's actually going on? The root cause in the vast majority of SharePoint hybrid search not returning results cases is that your Search Service Application Proxy is deployed in partitioned mode. Microsoft 365 simply does not support incoming hybrid search queries when the on-premises Search Service Application Proxy is running in partitioned mode. Full stop. The two systems can't negotiate the query handshake properly, and the result is either a blank result set or that 401 Unauthorized authentication failure.
Partitioned mode is a multi-tenancy feature designed for SharePoint hosting environments where different tenants need isolated search indexes. In a single-organization hybrid setup, which is what most enterprises are running, partitioned mode is almost never intentional. It often gets set during an automated farm provisioning script, an older version of the Hybrid Configuration Wizard, or a migration from a managed hosting provider. You may not even know it's enabled until search breaks.
This problem affects SharePoint Server 2013, 2016, 2019, and Subscription Edition farms configured for inbound hybrid search with Microsoft 365. If you're running any of those versions and you're seeing these symptoms, you're in the right place.
The SharePoint hybrid access errors and sync permission problems you're experiencing all trace back to one misconfigured property on the proxy object. Fixing it is entirely doable from PowerShell, no GUI gymnastics, no recreating the entire hybrid configuration from scratch (unless the property fix alone doesn't take, but we'll cover that too). Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you want the shortest path to resolving SharePoint hybrid search not returning results, this is it. Open the SharePoint Management Shell on your on-premises server, run it as Administrator, and execute this block of commands. I'll explain every line in detail in the step-by-step section below, but if you're experienced with PowerShell and just need the fix right now, here it is:
# Step 1: Grab the Search Service Application
$ssa = Get-SPEnterpriseSearchServiceApplication
# Step 2: Grab the Search Service Application Proxy
$proxy = Get-SPEnterpriseSearchServiceApplicationProxy
# Step 3: Disable partitioned mode on the proxy
$proxy.Properties["Microsoft.Office.Server.Utilities.SPPartitionOptions"] = 0
$proxy.Update()
# Step 4: Tell the SSA to ignore tenantization
$ssa.SetProperty("IgnoreTenantization", 1)
$ssa.Update()After running those four commands, give it a few minutes, search index propagation isn't instant, then go back to a SharePoint Online site and run a search query that should pull on-premises results. If you see results from your on-premises content sources, you're done.
If the property update doesn't stick, or if results still don't come through after 15–20 minutes, don't panic. The next escalation is removing and recreating the proxy entirely, I walk through that in Step 5 below. That fixes the remaining cases.
One important note before you touch anything: make a backup of your Search Service Application first. This is a core SharePoint component and modifying proxy properties directly can have unintended side effects if something goes wrong mid-operation. The official guidance is explicit on this. Use Central Administration → Backup and Restore → Perform a backup, or run Backup-SPFarm targeting the Search Service Application specifically. Don't skip this.
Get-SPEnterpriseSearchServiceApplication without assigning it to a variable first. If your farm has multiple SSAs (rare but it happens in large enterprises), you need to target the right one explicitly using the -Identity parameter, otherwise $ssa will grab whichever one comes back first and you may update the wrong proxy.
I can't stress this enough. Before you change any proxy properties in a production farm, create a backup. SharePoint hybrid configuration errors are recoverable, but only if you have a restore point. Modifying the SPPartitionOptions property on a live proxy is a direct write to the configuration database, and if anything goes sideways you want a clean rollback path.
Open SharePoint Central Administration and navigate to Backup and Restore → Perform a Backup. In the component list, expand the farm tree and select your Search Service Application. Set the backup type to Full and point it at a reliable UNC path with enough space. Alternatively, from the SharePoint Management Shell:
Backup-SPFarm -Directory "\\yourserver\backups\ssa-backup" -BackupMethod Full -Item "Search Service Application"Wait for the backup to complete before proceeding. If you're in a time-critical situation and the farm is non-production, you can move faster, but on a production farm serving real users, the 20 minutes for a backup is non-negotiable. Once the backup is confirmed, you're ready for the next step.
You should see a green success status in the Backup and Restore Job Status page, or a completion message in the PowerShell output. If the backup fails, investigate that issue first, a backup failure often signals underlying health problems with the Search Service Application that could complicate the fix below.
Now let's get oriented. Open the SharePoint Management Shell as Administrator and pull the Search Service Application object. This gives you the SSA instance you'll be working with throughout the rest of the fix:
$ssa = Get-SPEnterpriseSearchServiceApplication
$ssaYou'll see output showing the Name, Status, and other properties of your SSA. Make a note of the name, it's usually something like "Search Service Application" or whatever your farm admin named it during setup.
Next, get the Search Service Application Proxy. The proxy is the connector object that Microsoft 365 communicates through when it sends inbound hybrid search queries to your on-premises farm. This is the object we need to inspect and fix. Run:
$ssaproxy = Get-SPServiceApplicationProxyThis returns all service application proxies in the farm, not just the search proxy. Look through the output for your search proxy; its TypeName will contain "Search Service Application Proxy". Note the GUID in the Id column, it is completely unique to your farm and will not match any documentation or example you find online. That GUID is what you'll use if you need to target the proxy by identity in later steps.
Once you have both objects confirmed, you're ready to inspect the partition state. If you see your search proxy listed, proceed to Step 3.
This is the diagnostic step that confirms what we suspect. With your $ssaproxy variable set, inspect its Properties collection to see whether partitioned mode is actually enabled. Run:
$proxy = Get-SPEnterpriseSearchServiceApplicationProxy
$proxy.PropertiesLook through the output for the key Microsoft.Office.Server.Utilities.SPPartitionOptions. If this property exists and its value is anything other than 0, typically you'll see 1, that confirms your proxy is running in partitioned mode. That single setting is what's blocking inbound hybrid search queries from Microsoft 365.
The Properties collection can look a bit noisy with several key/value pairs. Don't worry about the others for now. The only one we're targeting is SPPartitionOptions. A value of 1 means partitioned (broken for hybrid). A value of 0 means non-partitioned (what we need).
If you don't see SPPartitionOptions in the output at all, that can mean either that it's not set (defaults may still cause issues) or that your proxy isn't the search proxy, double-check you're looking at the right object. Once you confirm the partitioned mode setting is the culprit, move to Step 4 to fix it.
Here's the core fix for SharePoint hybrid configuration errors caused by partitioned mode. You're making two changes: disabling the partition option on the proxy, and telling the Search Service Application itself to stop enforcing tenantization. Both changes are required, making only one of them typically doesn't resolve the issue.
Run the following block in the SharePoint Management Shell:
# Disable partitioned mode on the search proxy
$proxy = Get-SPEnterpriseSearchServiceApplicationProxy
$proxy.Properties["Microsoft.Office.Server.Utilities.SPPartitionOptions"] = 0
$proxy.Update()
# Tell the SSA to ignore tenantization boundaries
$ssa = Get-SPEnterpriseSearchServiceApplication
$ssa.SetProperty("IgnoreTenantization", 1)
$ssa.Update()After running these commands, wait approximately 5–10 minutes. SharePoint's timer jobs need to propagate the configuration change. You can check whether the timer job has processed the update by going to Central Administration → Monitoring → Review Job Definitions and looking for search-related timer jobs.
Then test from a SharePoint Online site by running a search query that should surface on-premises content. If results from your on-premises content sources appear in SharePoint Online search, the fix worked. Most farms, probably 70–80% in my experience, are resolved at this step without needing to go further.
If you still see the error or get no on-premises results after 15–20 minutes, the proxy properties may not have persisted correctly. That happens occasionally with certain farm configurations. Move to Step 5.
If Step 4 didn't fully resolve the SharePoint hybrid access errors, you need to take the more definitive approach: delete the existing proxy and create a fresh one. The fresh proxy will not have partitioned mode enabled by default, which is exactly what we need.
First, make sure you still have your $ssaproxy and $ssa variables set from earlier steps. If your session timed out, re-run the assignment commands before proceeding. Then remove the existing proxy:
# Remove the existing broken proxy
Remove-SPServiceApplicationProxy $ssaproxyPowerShell will prompt you to confirm the deletion, type Y and press Enter. This step is irreversible within the current session, which is why we took that backup in Step 1.
Now create a new, clean proxy tied to the same Search Service Application:
# Create a new proxy without partitioned mode
New-SPEnterpriseSearchServiceApplicationProxy -SearchApplication $ssa -Name "Search Service Application Proxy"The name you give the proxy doesn't technically matter for functionality, but keeping it consistent with what was there before avoids confusion in Central Administration and any monitoring scripts you have running. Once the new proxy is created, give SharePoint's timer jobs 10–15 minutes to register the change and re-establish the connection topology with Microsoft 365.
After that window, test your hybrid search again from SharePoint Online. At this point, with a clean proxy and IgnoreTenantization set on the SSA, inbound hybrid search queries should return on-premises results successfully. If you're still hitting issues after this, see the Advanced Troubleshooting section below.
Advanced Troubleshooting for SharePoint Hybrid Search Errors
When the standard proxy fix doesn't fully resolve SharePoint hybrid sync permission errors, there are a few deeper places to look. I'll walk through the most common culprits I've seen in enterprise environments.
The 401 Unauthorized Error in Query Builder
That System.Net.WebException: The remote server returned an error: (401) Unauthorized error you get when opening Query Builder from the result block is a separate, though related, issue. It shows up in the RemoteSharepointProducer.RetrieveDataFromRemoteServer method and typically means the service account used by the on-premises farm to communicate with SharePoint Online doesn't have sufficient permissions, or the OAuth trust between the farms has broken down.
Check your Server-to-Server (S2S) trust configuration. In Central Administration, go to Security → Manage Trust and verify your Microsoft 365 trust is listed and shows as healthy. If it's missing or shows an error, you may need to re-run the Hybrid Configuration Wizard to re-establish the trust relationship.
Also verify that the account listed under your web application's User Policy has the correct permissions. Open Central Administration → Application Management → Manage Web Applications → select your web app → User Policy. The crawl account and the app pool account both need appropriate access.
Checking ULS Logs for Deeper Insight
SharePoint's Unified Logging Service (ULS) logs are where the real detail lives. The on-screen errors are sanitized, ULS gives you the full stack. On your SharePoint server, ULS logs are typically in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\ (adjust 16 to 15 for SP 2013). Filter by Correlation ID, you can grab the correlation ID from the error page SharePoint shows users. Look for entries with category Search and severity Unexpected or Critical.
If you see entries referencing Tenantization, PartitionId, or AccessDenied, those confirm the proxy partition issue. If you see authentication token errors or certificate validation failures, the S2S trust configuration needs attention.
Verifying the Outbound Connectivity Path
For inbound hybrid search to work, your on-premises SharePoint server needs outbound HTTPS connectivity to Microsoft 365 endpoints. Check that your proxy or firewall isn't blocking calls to *.sharepoint.com, login.microsoftonline.com, and the Microsoft 365 IP ranges published in the official Microsoft 365 URL and IP address documentation. Run a quick test from the SharePoint server:
Test-NetConnection -ComputerName login.microsoftonline.com -Port 443If TcpTestSucceeded comes back as False, your outbound network path is blocked and no amount of PowerShell property changes will fix the search results until that's resolved with your network team.
Re-running the Hybrid Configuration Wizard
If the proxy fix and S2S trust checks don't resolve the SharePoint hybrid access errors, the Hybrid Configuration Wizard in Microsoft 365 admin center can re-establish the full hybrid topology. Go to SharePoint admin center → Settings → Configure hybrid and re-run the wizard. It's non-destructive in most cases, it overwrites configuration rather than duplicating it, but always take a fresh backup before doing so.
Get-SPEnterpriseSearchServiceApplication, Get-SPServiceApplicationProxy, and a screenshot of the Query Builder error. That shortens the diagnosis time significantly. You can reach Microsoft Support directly through the Microsoft 365 admin center under Health → Service support.
Domain-Joined and Hybrid Azure AD Scenarios
In environments where devices are hybrid Azure AD joined, meaning they're registered with both on-premises Active Directory and Azure AD, there's an additional layer to check. The user's claims token presented to SharePoint Online during a search query may not be translating correctly to the on-premises identity. This is especially common in organizations that migrated from ADFS to Pass-through Authentication or seamless SSO after the initial hybrid search setup. If users are getting results in SharePoint Online for their SharePoint Online content but not on-premises content even after the proxy fix, claims translation is worth investigating with your identity team.