Problem with connecting to SharePoint Online in Office 365 with PowerShell, SharePoint Designer and other 3. party tools

You are not any longer able to log into SharePoint using PowerShell, SharePoint Designer and other 3. party tools (ex. ShareGate, SharePoint Search Query Tool etc). The error message states something that you are “Unauthorized” and “…the web site does not support SharePoint Online credentials” even though you username and password is fine.

Example: Error while logging in with PnP PowerShell

Connect-PnPOnline : Cannot contact web site ‘https://TENANTID.sharepoint.com/‘ or the web site does not support SharePoint Online credentials. The response status code is ‘Unauthorized’.  The response headers are ‘X-SharePointHealthScore=0, X-MSDAVEXT_Error=917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.,

Example: Stuck while logging in with SharePoint Designer

Reason

SharePoint Online has a setting named “LegacyAuthProtocolsEnabled” with the purpose “Prevents Office clients using non-modern authentication protocols from accessing SharePoint Online resources .”.

By default this is allowed in all tenants. But as an administrator it is possible to tighten up the security and disallow us to login with these non-modern approaches.

More details can be found here: https://technet.microsoft.com/en-in/library/fp161390.aspx

Solution

1. Start using modern authentication (recommended)

Check if your application support the use of modern authentication through either WebLogin or using application credentials (ClientId/ClientSecret) authentication. This is advice to be the recommended and a more secure approach.

Not all tools, like SharePoint Designer, supports this modern authentication and if you are required to continue to use these apps further on, you might have to re-enable the support as described in the next point.

2. Re-enable support for legacy apps (temporary fix)

Note: Your company might have performed a security hardening and disabled this by purpose. If so it would not be advisable to continue without verifying the reason for this change.

Using “SharePoint Online Management Shell” login in with “Connect-SPOService”.


Connect-SPOService -Url "https://TENANTID-admin.sharepoint.com"

Verify the value of “LegacyAuthProtocolsEnabled”.


$TenantSettings = Get-SPOTenant

$TenantSettings.LegacyAuthProtocolsEnabled

If this value is “False”, then this issue will be solved by setting this to “True”.


Set-SPOTenant -LegacyAuthProtocolsEnabled $True

Updating you SharePoint Online tenant settings does not take immediate effect. So you need to while a while, exact how long can be from from minutes to 24 hours with the different settings, before you retry.

Summary

Changing the value of “LegacyAuthProtocolsEnabled” can cause issues for some existing applications. Checking if you can start using more modern authentication options will solve the issue in many apps, but for  some you might still need to keep this support open.

Unable to search for pages in SharePoint Online when using Managed Navigation

This is a summary of an issue we have had with publishing pages not being indexed, and then unable to build the search-driven pages we wanted using for example Content Search Web Part. This occured in SharePoint Online (Office 365) and we have only had this issue with a couple of tenants. So my guess is that most tenants are working fine, but if you should come across this strange behavior, I hope this post can help you save some time.

The issue

  • Created a Publishing Site
  • Added a Content Type and a Page Layout, created a few test articles
  • Added a Content Search Web Part and set up a query to return articles for the Content Type created above
  • Waited a long time (normal)
  • No results (oops)
  • Tried to reindex the library (curious)
  • No results (worried)
  • Retried all the steps (scared)
  • No results (desperate)
  • Got coffee (calm)
  • No results (called support)

I guess you get it. Something was very wrong and I was stuck on not getting any results back. On-Premises this would probable been one of those situations a full crawl, or at worst a index reset, had fixed it. But running in Office 365 we don’t have these abilities.

The workaround

After some trial and error I understood what was causing the issue, and got this workaround:

  • Go to “Site Settings”
  • Select “Navigation” under “Look and feel”
  • Uncheck these options:
    • Add new pages to navigation automatically
    • Create friendly URLs for new pages automatically

search-mn-error-1

All pages created and published after making this change was indexed and showed up as expected. Unfortunately all the pages created before doing this change was a lost cause. Believe me, I tried a lot but unable to get them indexed.

The fix

As being on Office 365 this issue was addressed with Microsoft Support, and after a while they released a fix.

Unfortunately I suspect this error can still occur in some scenarios, and to make sure we don’t run into this trouble again, a recommendation is to avoid using the Managed Navigation set up as shown above just to be safe.

Error: There is a compatibility range mismatch between the Web server and database

There is a compatibility range mismatch between the Web server and database “SP2013_Content_InsertDatabaseNameHere”, and connections to the data have been blocked to due to this incompatibility. This can happen when a content database has not been upgraded to be within the compatibility range of the Web server, or if the database has been upgraded to a higher level than the web server. The Web server and the database must be upgraded to the same version and build level to return to compatibility range.

error-after-sp1-upgrade

 

Cause

Discovered the error the first time I tried to upgrade a sandboxed solution within the selected database using PowerShell after upgrading to SP1. The error message appears the script output, Event Viewer and ULS. All databases had “No action required” as upgrade status, so this wasn’t the problem in my case. Hidden behind this error it appeared that insufficient database permissions was the cause.

Solution

It turned out that the logged in users’ permissions for this database had been lost after upgrading SharePoint 2013 from March PU to SP1 for some reason.

Fixed this was easy by adding the “SPDataAccess” role back to the user for the content database that was failing.