How to Fix SharePoint Hybrid TOC Errors

The S2S trust is the foundation of every SharePoint hybrid feature, including your hybrid TOC. Without a valid trust, no token exchange happens and everything downstream fails. Go to Central Administration → Security → Manage trust. You should see an entry for SharePoint Online, if it's missing entirely, your hybrid configuration was never completed or was deleted.

To validate it properly from PowerShell, run:

# List all trusted service token issuers
Get-SPTrustedSecurityTokenIssuer | Select Name, RegisteredIssuerName, IsSelfIssuer | Format-Table -AutoSize

# Specifically look for the SharePoint Online issuer
Get-SPTrustedSecurityTokenIssuer | Where-Object {$_.RegisteredIssuerName -like "*00000001-0000-0000-c000*"}

You should see an entry with a RegisteredIssuerName containing your tenant GUID. If the output is empty, the trust is broken. To re-establish it, you'll need your SharePoint Online tenant ID. Get it from the Azure portal under Azure Active Directory → Properties → Tenant ID.

# Re-establish S2S trust (replace YOUR-TENANT-ID with actual GUID)
$tenantId = "YOUR-TENANT-ID"
$stsMetadata = Invoke-WebRequest "https://accounts.accesscontrol.windows.net/$tenantId/metadata/json/1"
New-SPTrustedSecurityTokenIssuer -Name "SharePoint Online" -IsTrustBroker -MetadataEndPoint "https://accounts.accesscontrol.windows.net/$tenantId/metadata/json/1"

If the trust exists but looks wrong, remove and re-create it rather than trying to patch it, partial trusts cause intermittent hybrid TOC failures that are maddening to debug. After creating the trust, run an IIS Reset across all servers in the farm: iisreset /noforce. Give it five minutes, then check your hybrid navigation again.

This is the fix that enterprise admins forget until it bites them. The Security Token Service certificate used for hybrid OAuth has an expiry date. When it expires, your hybrid TOC stops working with no obvious error, it just silently breaks. Check it right now:

# Check current STS certificate details
$sts = Get-SPSecurityTokenServiceConfig
$cert = $sts.LocalLoginProvider.SigningCertificate
Write-Host "Subject: $($cert.Subject)"
Write-Host "Thumbprint: $($cert.Thumbprint)"
Write-Host "Expires: $($cert.NotAfter)"
Write-Host "Days remaining: $(($cert.NotAfter - (Get-Date)).Days)"

If days remaining is under 30, or negative, you need to renew it. SharePoint can generate a new self-signed STS certificate, but you also need to update SharePoint Online's trust with the new certificate. Here's the process:

# Generate a new STS certificate
$newCert = New-SPSelfSignedCertificate -FriendlyName "SharePoint STS" -CommonName "SharePoint STS" -AlternativeNames @() -OrganizationalUnit "IT" -Organization "Contoso" -Locality "Redmond" -State "WA" -Country "US" -Exportable -HashAlgorithm SHA256 -KeySize 2048 -KeyUsage None

# Assign it to STS
Set-SPSecurityTokenServiceConfig -SigningCertificateThumbprint $newCert.Thumbprint
iisreset /noforce

After updating the certificate on-premises, go to SharePoint Online admin center → Settings → Hybrid picker and re-run the hybrid configuration wizard. It will pick up the new certificate and update the trust. Alternatively, use the SharePoint Online Management Shell to update the trusted certificate directly. Once done, restart the timer service and give the hybrid TOC five minutes to re-establish. You should see your navigation tree populate correctly.

Your SharePoint Hybrid TOC taxonomy sync depends on the Managed Metadata Service Application being properly connected and having the right proxy configuration. I've seen setups where an upgrade or migration left the MMS proxy pointing to the old service application instance, silently breaking all term group replication.

Navigate to Central Administration → Application Management → Manage service applications. Find your Managed Metadata Service. Click on its connection (proxy), then check the properties, you should see a checkbox for "This service application is the default storage location for column specific term sets" and "This service application is the default storage location for site collection specific term sets." Both should be checked.

Now verify the hybrid term group replication is actually configured:

# Check the Managed Metadata service application
$mms = Get-SPServiceApplication | Where-Object {$_ -is [Microsoft.SharePoint.Taxonomy.MetadataWebServiceApplication]}
$mms | Select Name, Status, Id

# Check which term groups are marked for replication
Add-PSSnapin Microsoft.SharePoint.PowerShell -EA SilentlyContinue
$session = New-PSSession -ConnectionUri https://yourtenantname.sharepoint.com -Authentication Kerberos
# Note: for the term store, check via the UI in SharePoint Online Term Store Management

In SharePoint Online, go to SharePoint Admin Center → Term store. Look for any term groups that should be replicated from on-premises. If they're missing or stale, the replication timer job is failing. In Central Administration on-premises, navigate to Monitoring → Timer Jobs → Review job definitions, search for "Taxonomy," and check the Taxonomy Groups Replication job. Its last run time and status will tell you whether it's running at all. If the status shows Failed, check the ULS logs at the time of its last run, look for event category Taxonomy or Hybrid in the SharePoint ULS log viewer.

The hybrid TOC uses the User Profile Application to resolve user identity across the on-premises/cloud boundary. When UPA can't reach SharePoint Online, which happens after firewall rule changes, proxy updates, or expired credentials, your hybrid navigation personalization breaks and the TOC can't render user-specific navigation nodes correctly.

First, verify the UPA service is running:

# Check UPA service status
Get-SPServiceInstance | Where-Object {$_.TypeName -like "*User Profile*"} | Select Server, Status, TypeName

# Check the actual service application
Get-SPServiceApplication | Where-Object {$_ -is [Microsoft.Office.Server.Administration.UserProfileApplication]} | Select Name, Status

If those look healthy, test whether your on-premises farm can actually reach SharePoint Online endpoints. From your SharePoint application server, open PowerShell and run:

# Test connectivity to SharePoint Online
$testUri = "https://login.microsoftonline.com"
$result = Invoke-WebRequest -Uri $testUri -UseBasicParsing -TimeoutSec 10
Write-Host "Status: $($result.StatusCode)"

# Test the specific token endpoint
$tenantId = "YOUR-TENANT-ID"
$tokenEndpoint = "https://accounts.accesscontrol.windows.net/$tenantId/tokens/OAuth/2"
try {
    $ping = Invoke-WebRequest -Uri $tokenEndpoint -Method HEAD -UseBasicParsing -TimeoutSec 10
    Write-Host "Token endpoint reachable: $($ping.StatusCode)"
} catch {
    Write-Host "Token endpoint FAILED: $($_.Exception.Message)"
}

If either of those fails, you have a network-level block. Check your proxy server settings. SharePoint on-premises needs to reach *.microsoftonline.com, *.sharepoint.com, accounts.accesscontrol.windows.net, and login.windows.net without SSL inspection breaking the certificate chain. If your proxy is doing SSL inspection, you need to whitelist those endpoints with passthrough.

To configure SharePoint to use a proxy for outbound connections:

# Set proxy for SharePoint outbound connections
$webProxy = New-Object System.Net.WebProxy("http://yourproxy.contoso.com:8080")
[System.Net.WebRequest]::DefaultWebProxy = $webProxy

# Or configure it in Central Admin:
# Central Admin → Security → Configure web proxy settings

Every SharePoint hybrid deployment relies on a specific Azure AD app principal with ID 00000003-0000-0ff1-ce00-000000000000 (SharePoint Online) being trusted on-premises. After tenant migrations, Azure AD conditional access policy changes, or accidental deletion by another admin, this app principal registration breaks, and your hybrid TOC fails with 401 errors that are incredibly hard to trace back to this cause.

To check and fix the app principal registration, open the SharePoint Management Shell as administrator and run:

# Check existing app principal registrations
Get-SPAppPrincipal -Site https://yourintranet.contoso.com -NameIdentifier "00000003-0000-0ff1-ce00-000000000000@YOUR-TENANT-ID"

# If the above returns nothing or an error, register it fresh
$site = Get-SPSite "https://yourintranet.contoso.com"
$tenantId = "YOUR-TENANT-ID"
$appPrincipal = Register-SPAppPrincipal -Site $site.RootWeb -NameIdentifier "00000003-0000-0ff1-ce00-000000000000@$tenantId" -DisplayName "SharePoint Online"

# Grant it the right permissions
Set-SPAppPrincipalPermission -Site $site.RootWeb -AppPrincipal $appPrincipal -Scope SiteSubscription -Right FullControl

After running this, you need to do an IIS reset across all servers in your farm and then restart the SharePoint Timer Service. Navigate back to a SharePoint site that should show the hybrid TOC navigation and do a hard refresh (Ctrl+Shift+R). If the app principal was the issue, you'll see the navigation populate within about 60 seconds as the new trust propagates. If you see error code AADSTS700016 or AADSTS90019 in your ULS logs, that confirms this is exactly the problem, the app wasn't found in the directory, and re-registering it is the correct fix.