SharePoint indexer "No such host is known"

Hi @Sujay Dutta

Thanks for sharing the workaround and investigation results.

Based on the findings in this thread, the issue does not appear to be related to SharePoint connectivity, DNS resolution, or network access. The behavior is instead associated with the identity configuration used by the SharePoint datasource when working with the SharePoint Indexer preview feature.

In the reported scenario, the datasource and indexer began failing with the error:

"No such host is known"

Updating the datasource configuration by leaving federatedIdentityClientId empty:

JSON

"federatedIdentityClientId": ""

resolved the issue and allowed indexing operations to proceed successfully.

If other users encounter the same symptom, we recommend reviewing the datasource identity configuration and validating whether an explicitly populated federatedIdentityClientId is contributing to the failure. As demonstrated in this case, removing the value may help restore normal SharePoint indexing behavior.

Thank you for posting the resolution and detailed explanation. This information will be valuable for other community members who encounter similar SharePoint Indexer issues.

References

• https://learn.microsoft.com/azure/search/search-how-to-index-sharepoint-online
• https://learn.microsoft.com/azure/search/search-how-to-managed-identities

If the answer is helpful, please do click "Accept the answer” and Yes, this can be beneficial to other community members.

Found a fix for the issue, making "federatedIdentityClientId": "" in the datasource json fixed the issue. In the example below the application_id is the enterprise application with Sites.Selected.

"No such host is known" was never a DNS/networking problem at all — it's very likely a bug in this specific preview API's (2026-05-01-preview) federated-token-exchange code path when FederatedCredentialApplicationId/federatedIdentityClientId is explicitly populated: something in that path was failing before the connector even got to actually resolving abc.sharepoint.com, and the generic/misleading "No such host is known." was masking an internal failure in Microsoft's own connector, not a real DNS lookup. Omitting the field makes the connector fall back to resolving the identity implicitly, which apparently exercises a different (working) code path.

{
  "@odata.context": "https://<your-search-service>.search.windows.net/$metadata#datasources/$entity",
  "@odata.etag": "\"<etag>\"",
  "name": "ds-example-whatever-dev",
  "description": "Example SharePoint source: whatever",   
  "type": "sharepoint",
  "subtype": null,
  "indexerPermissionOptions": [],
  "credentials": {
    "connectionString": "SharePointOnlineEndpoint=https://<your-tenant>.sharepoint.com/sites/<YourSiteName>;ApplicationId=<application-id-guid>;TenantId=<tenant-id-guid>;"
  },
  "container": {
    "name": "useQuery",
    "query": "includeLibrary=https://<your-tenant>.sharepoint.com/sites/<YourSiteName>/Shared%20Documents"
  },
  "dataChangeDetectionPolicy": null,
  "dataDeletionDetectionPolicy": null,
  "encryptionKey": null,
  "identity": {
    "@odata.type": "#Microsoft.Azure.Search.DataUserAssignedIdentity",
    "userAssignedIdentity": "/subscriptions/<subscription-id-guid>/resourceGroups/<your-resource-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<your-managed-identity>",
    "federatedIdentityClientId": ""
  }
}