SharePoint 2019 On Premise - Webhooks subscription with a private EndPoint

[valentinschweizer]

Category

• Question
• Typo
• Additional article idea

Question

We develop a REST MVC Webservice in .net C#, which is able to receive Webhook notifications from our internal SharePoint 2019. It works fine, when I test the application from Visual Studio 2019 with Ngrok but when I publish the service to an IIS web server internally, I still get the following error:

{ "odata.error": { "code": "-1, System.InvalidOperationException", "message": { "lang": "fr-FR", "value": "Failed to validate the notification url « https://xxxx.xxx.local/api/SPWebhook/HandleSharePointRequest » " } 

When I debug the Endpoint from IISExpress with Ngrok on my computer, everything works perfectly. The validation token is returned and SharePoint add the subscription correctly (based on official doc: https://docs.microsoft.com/en-us/sharepoint/dev/apis/webhooks/get-started-webhooks). But when I publish this Endpoint to a Web Server IIS in our Private Domain I always received the error above. If I use a Ngrok URL for the notification URL it works but when I use a domain URL servername.domain.local we always get the error.
Does the endpoint URL have to be public, even for SharePoint On Premise ? It seems surprising that for an On Premise version the Endpoint must be public. Is there a way to use a private url for the EndPoint?
Many thanks in advance for your help!

Environment details (development & target environment)

development OS: Windows 10
OS: Windows Server 2019, with IIS
Target Environment: SharePoint 2019 On Premise on Windows Server 2019
Framework: NET Framework v4.5.2
Tooling: Visual Studio 2019

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[valentinschweizer]

Does anyone have an idea? I haven't found any information so far. @andrewconnell Do you know who can help me with this topic?
Thanks in advance for your help!

[GreyMana-git]

@valentinschweizer
There seems to be a requirement that the endpoint of the webhook needs to be public. To be more precise, the DNS of the URL will be resolved and checked if this is a public IP (SPWebRequest.CreateSafe). If it resolved to an internal IP, there will be no requests, so debugging the endpoint will show nothing!

My guess is that Microsoft is using some code of the add-in model. To avoid that some malicious add-ins are sniffing around the local infrastructure Microsoft added a check to only allow communication to public endpoints, which seems reasonable for public Add-Ins bought from the Office store.

@andrewconnell Is it possible to update the documentation about this behavior?

[andrewconnell]

My understanding isn't that the URL must be public, but that (1) it must be secured (SSL) & (2) the cert must be legit.

If you're using an internal cert, then that cert must be in the TRA of the SP servers that post to the webhook. Otherwise, the cert can't be verified as legit & thus, can't be trusted as really being "secure". That's why the Ngrok one works; ngrok uses a wildcard cert for their subdomains.

@GreyMana-git I can't update the docs on something like this without someone from engineering to state it exactly... not just observations. I've asked around, but yet to get a response.

[GreyMana-git]

@andrewconnell Fully understand that changing the document needs some verification first. I hope my comment didn't come over too harsh.

I checked again all my configurations and they seemed to be fine. Unfortunately I was unable to get any kind of logging into the ULS, even with Verbose Severity, which is kind of strange.

After some more research I was able to register the local endpoint after executing the following code in the Management Shell:

$farm = Get-SPFarm
$farm.Properties["DisableIntranetCalls"] = $false
$farm.Update()

When adding the webhook again (the same request that didn't work before) my web service was called, I was able to return the validation code and SharePoint returned 201 (created) with the correct payload (subscription id, etc.).

The property sound scary, it's not something I would add to a production environment. Maybe this helps a bit when analyzing and understanding what's going on there a bit more.

[flaviuc]

@andrewconnell actually it seems that the IP must NOT be in the intranet address range. if it is the problematic behavior still happens.

[GreyMana-git]

@flaviuc This is what I noticed too. The URL of the webservice will be resolved to an IP Address and then SharePoint checks if the IP is private or public. When it's a private IP (intranet range) and the farm does not have the "DisableIntranetCalls" set to false, no call to the webservice will be done to register the hook.

[github-actions]

Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.

If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.

We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.