C/AL NavSherpa (up to Business Central 14) is using CSOM library to connect to SharePoint and you can quite easily use for example Basic authentication.

 

AL extension NavSherpa is using REST API in the background and old methods of authentication are now deprecated – you need to use OAuth. It works out-of-the-box with SharePoint Online – and for on-prem SharePoint installations (SharePoint 2013, 2016, 2019) you need to do a few actions to properly establish the connection.

 

 

We recommend upgrading NavSherpa extension at least to version 17.07.00, 18.05.00 or 19.00.00.

 

 

Low-trust authorization basically means that:

 

Before you can run the Setup Access Token wizard, you need to establish trust between your O365 tenant and SharePoint on-prem. This is done via PowerShell and setup is documented here: https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/use-an-office-365-sharepoint-site-to-authorize-provider-hosted-add-ins-on-an-on#to-configure-your-on-premises-sharepoint-site-to-use-acs

 

All steps must be done on the server, where SharePoint on-prem is installed and you need admin access to both SP on-prem and your O365 tenant. It is recommended, that you use HTTPS protocol on your SharePoint on-prem server.

 

After you do all the steps in the article, the script can be run like this:

 

 

Use this variant for testing purposes if you have your SharePoint with http only:

 

 

Instead of “MyO365Domain” use the name of your O365 tenant domain. Successful output looks like this:

 

 

In the background the authentication realm GUID in your SharePoint on-prem changed to the GUID of your O365 tenant. You can check the realm ID with these two commands:

 

 

 

And it will be visible in NavSherpa SharePoint Access Tokens page too:

 

 

If you have a token with wrong Bearer Realm here, delete it and rerun the Setup Access Token wizard.

 

 

If you are not able to install MSOnlineExt PS module with an error:

You need to allow TLS 1.2 on the server, see the setup here: https://www.alitajran.com/unable-to-install-nuget-provider-for-powershell/

 

If you want to test NavSherpa in your local Docker on a SharePoint, that is installed in local network only (e. g. on a local address like http://spsolution.navisys.local), NavSherpa may not be able to see the SharePoint initially. To fix this, add the SharePoint IP and domain into hosts file inside the container:

 

Note: you can view the contents of your docker .hosts file with command:

 

High-trust authorization means, that a SharePoint add-in is authenticating by a registered certificate and creates the authentication token by itself (https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/creating-sharepoint-add-ins-that-use-high-trust-authorization). Unlike Low-trust authorization this method does not need any calls to external service, even for getting an access token.

 

NavSherpa does not support this form of authorization now, please use low-trust authorization instead.

 

 

If your on-prem SharePoint has an external web address visible from internet and exposed through firewall (e. g. https://yoursite.yourdomain.com/sites/nsptest), NavSherpa will work as usual with no manual fixes needed.

 

If you however have your SharePoint on-prem farm in your internal network only, you will need to do a few actions manually. The reason is that AL NavSherpa is not able to do a few actions via REST API and must use Azure functions to achieve the goal (and Azure functions need an endpoint accessible from internet for that). These actions include:

Both issues can be quite easily mitigated manually. Please note, that you must do both steps before calling Update List on SP action.

 

Let’s say you have a custom content type in Library Setup, that does not exist on SharePoint site yet:

 

 

Open the SharePoint web, go to Site Settings and select Site Content Types.

 

 

Create a new content type:

 

 

Now open your SharePoint list setup Content Types and manually select the existing content type – you need to select Site Content Types for that.

 

 

That’s it, NavSherpa will now use the existing SharePoint content type.

 

You can add fields to content type via field Count Of Content Types (open the details to see the full list). For internal network only installations we recommend deleting all existing assignments, so you will have 0 in the entire column.

 

 

This way NavSherpa will not try to add any field to a content type and the Azure function won’t be needed – and NavSherpa will export all fields data to all content types.

 

If you need to see the fields in the SharePoint file properties form, you can add them manually in Document Library Settings on SharePoint.

 

 

Go to the Site Contents on SharePoint, select your library and open Settings.

 

 

In the Content Types section open your content type.

 

 

Add new columns with action Add from existing site or list columns.

 

 

After you confirm the action, you will see the selected fields in the edit form for selected content type.

 

 

Please note, that since you did not attach fields to content types in NavSherpa list setup, NavSherpa will fill all fields in the background. If this is not acceptable, you can select the field content types manually now (however, you might have some issues with function Update list on SP afterwards).