How to fix “- – the web site does not support SharePoint Online credentials. The response status code is ‘Unauthorized'” error

SharePoint is not broken - it just does't work

While running some SharePoint Online -PowerShell commandlets, or connecting to a SharePoint Online site from your app, you get a following (or similar) error about your SharePoint Online credentials being unauthorized for something you should definitely be authorized to do:

And that’s not all – by digging into the full error message, you find the underlying internal error:

What awakens my curiosity, is this line:

However, when you open your browser, you can actually log in without a hitch. If that’s the case, this might be a weird internal error in SharePoint Online – doesn’t matter, there’s a hazy and weird, but simple fix!  Continue reading

How to solve “Unified Groups aren’t supported.” -error

Unified Groups aren't supported.

When trying to use some functionality, that relies on Unified Groups, you’re getting errors in the console, similar to this: “Unified Groups aren’t supported.” In truth, this most likely means, that Unified Groups (that’s the internal/technical name for Office 365 Groups) is not enabled for this particular user. That breaks a bunch of different features for them, since the Graph API for Groups of course won’t work. This post describes one way to fix this issue!

How to solve this?

Continue reading

How to Resolve Managed Metadata Madness in SharePoint?

Microsoft Flow that's used in this demo - it uses an Azure Function to extract text from a doc, which is then sent to Text Analysis, and finally written back to SharePoint. In the end, it sends notifications of the status of the run.

Using Azure Functions and Cognitive Services Text API to enrich a Flow that fills Metadata for new items in a Modern SharePoint Team Site. That’s, in a nutshell, the solution I submitted to a recent online hackathon. Quite a mouthful, isn’t it? The whole solution (and a public vote, if you’re interested!) is available here: – this blog post will describe the solution and the reasoning behind it.


Some time ago my manager asked me to take a few weeks off, since I had accrued quite a lot of overtime during the hectic months working for Valo. I got bored quite quickly, so I was pretty happy to encounter an online hackathon organized by Devpost. I wasn’t aware of them beforehand, but they seemed to have hosted quite a few interesting hackathons before, so I thought I’d also take part into a hackathon they were just hosting: “Work smarter, not harder with Office 365.”

I’m not a huge fan of hackathons, but the topic was too good to miss, so I submitted a solution I’d been thinking about implementing, but didn’t have a good enough reason to implement it for customers.

Description of the issue

So, which issue am I aiming to solve? Let’s see… 

  • The amount of data is surging (~90% of the data in the world has been created in the last 2 years)
    • To ensure that data in organizations is useful, you need to make sure, that your users find it easily!
  • A great “Enterprise-y” solution has been metadata tagging!
    • However, users generally hate doing that manually
    • Automatic solutions are either cumbersome to maintain, expensive to develop, or both
    • Many required metadata fields will cause users to migrate to shadow IT solutions (like DropBox) – or not use any collaboration solutions at all!
Resolving Managed Metadata Madness in SharePoint

Fig. 1: Resolving Managed Metadata Madness in SharePoint – in one Flow!

The Solution

Using Azure Functions and Cognitive Services Text API to enrich a Flow that fills Metadata for new items in a Modern SharePoint Team Site. Cool solution with fun new tools!

  • We’ll be using Modern Team Sites in SharePoint for document storage. That enables effortless collaboration in the cloud!
  • SharePoint’s Search is decent, but thorough metadata tagging makes it a lot more useful.
  • Using Azure Cognitive Services we can fill the metadata fields automatically – without any user interaction at all!
  • Users can find the content, and hence will be happy! 🙂

So essentially, what happens is, that this Flow automates metadata tagging for SharePoint Online. Like in the graph (Fig. 1), these are roughly the steps:

  1. User uploads a document
  2. This fires a Flow attached to Document Library
  3. The Flow will call the Azure Function that’ll do the heavy lifting
  4. An Azure Function will run, extract text, and analyze it using Azure Cognitive Services
  5. The Azure Function will then write the info back to SharePoint Online
  6. Finally, notifies admin of the execution and the creator of the file.

There’s a larger description and a demo video (in case the demo is not visible on the hackathon demo page, see it below! The actual demo starts around 3:10, it’s mainly issue and solution description before that) available on the hackathon website:

Using “DetectedLanguage” to return only localized results from SharePoint Search index

How to SharePoint?

Localization and targeting of content in multilingual SharePoint installations is always an issue. SharePoint offers a multitude of ways profile content based on user language (or other properties), but none of the solutions are fool proof. This post describes how to fetch only localized results from SharePoint Search index, which solves at least some of the issues.


SharePoint Search index can be used in quite a few different ways. Probably the most typical way is by searching on SharePoint, or using webparts like Content Search or Content Results. However, one can also build custom functionality, custom client-side liftups, webjobs, single-page applications, mobile applications and a ton of other things that fetch data from SharePoint search index. However, on multilingual tenants, results are, by default, not localized at all. That means, that typically everyone will get the highest-ranking results back, despite them being in the wrong language. And that’s one of the many, many ways to annoy your users!

Continue reading

How to form links to Planner tasks

Office 365 Planner logo

Office 365 Planner is a neat tool for task management. However, when you, for whatever use case, need to form urls that point you towards a single task (or a bucket, or a plan for that matter), you might run into trouble with how the url is formed. Custom domains actually make it a bit complicated, but luckily there’s a workaround!

Description of the issue

If you have multiple domains in your Azure AD, your Planner might end up using your custom domain in its urls. However, if you need to develop some multi-tenant code, that works with any tenant and whatever weird custom domains, you’d have to actually either create another user-supplied property (for the custom domain), or develop some creative extra code to fetch the domains from somewhere… Since the Graph API for Planner certainly does NOT return that!

No worries – you don’t actually need to develop any complicated or smart code. It’s actually WAY easier than that!  Continue reading

Call to sites Graph API requires “owner” permissions for site collection regardless of app permissions

Okay – yet another weird issue, and a hacky workaround. I was developing an app that was calling a SharePoint site through Graph API, using jQuery $.ajax call (developed in TypeScript), and ran into surprising 401 errors. I did find a workaround, but am also working on an actual fix.


To get SharePoint site ID, which is needed when accessing SharePoint lists, the calls seemed to fail for my test accounts. Everything was working fine for my developer account, which was a global admin, so the first thing I was suspecting was of course permissions…

The first offending test account was a Group member, and a restricted reader in the site collection I was trying to access via Graph. The account was also a contributor on the root site of the tenant. And all of my accounts were licensed with E3/E5.

I knew that this part of the code was supposed to get a site id for a certain SharePoint site collection with a call to Graph API, similar to this one:<tenant><site>/

It worked for my developer account, but just wouldn’t work for the test accounts! This is the error I got: Continue reading

Alternative Languages in SharePoint forcing the (cumbersome) use of localized Managed Properties

SharePoint Search No Results

Localization and multilingual environments in SharePoint are an endless source of interesting issues and blog post topics. In one case, we had a tenant created originally in English, and a site collection created in Finnish. In this particular case, SharePoint somehow messed up the language settings, and ended up requiring the use of localized managed properties on the search center of that site collection. That ended up being unexpected, unituitive and unusable for the end-users.

Description of the issue

Typically, when you use SharePoint Search, you can use managed properties to search for values in certain fields or columns of any items in the index. Our particular use case involved searching SharePoint’s people results for users of certain departments.

“Department” is a managed property on its own, and gets info from – surprise, surprise – a field called “Department” in the user profile service in SharePoint Online. In our case, the Search service API returned results with “Department:HR”, but search center did not. 

After a lot of playing around, it turned out the search center required us to use localized versions of the names of managed properties. In this particular case, search required the Finnish name (“Osasto”) for the property. Before this, I didn’t even know that was a thing! In all of the installations I’ve seen, the plain English internal names of the managed properties worked just fine – so, in this case, “Department”. Continue reading

Web part title changes not reflected to some users in multilingual SharePoint environment

SharePoint is not broken - it just does't work

​​When changing the web part title on a web part on a classic SharePoint page, changes seem to be saved for you. In reality, they are only reflected to some users.. And some users, on some devices, see the old title, whereas some see the new one. It’s a confusing situation and difficult to debug.

Why do web part titles get changed seemingly randomly?

Imagine this: You have a SharePoint environment, where you have multiple different languages set up. You also have users with multiple different workstation configurations – including multiple different languages. Different users, however, quite randomly see different revisions of web part titles in a very weird manner. This happens seemingly randomly even on new client devices, so no client-side caching is the reason.

This actually likely works as designed, it’s just kind of a confusing implementation. We’ve got Microsoft to blame for that, and their pretty bad documentation.. SharePoint actually localizes (and hence saves) Web part titles per-language.  Continue reading

4 ways to fix error AADSTS65001 (The user or administrator has not consented to use the application)

Azure AD Login error

Fixing issues with Azure AD authentication for Enterprise applications can be tricky. This article contains multiple different fixes to an issue, where granting admin consent has somehow failed. Not all of the different solutions will work for all situations, though! That’s why I included a couple of different options to try… 🙂

Why do you even get issues with Admin Consent (like AADSTS65001)?

You’re trying to add or use an app, that requires such permissions from your tenant, that can only be granted by an administrator. Typically this app has to be added by a global administrator. If it’s an enterprise application, it could also be in an invalid state after someone tried adding the app without sufficient permissions.

Our investigation was focused on a mobile app, that’s deployed as an enterprise app. Most of the things should apply for web-based apps or console programs or whatever else you’re deploying, too.

The whole error might look something like this: Continue reading