Fastest way to verify your Client Id and Client Secret are valid with PowerShell

So, you have a Client Id and a Client Secret, but don’t know if they work anymore? Maybe they are expired? Maybe someone removed them? No worries! We can use PowerShell to validate them easily!

Solution

By using PowerShell, it’s fairly straightforward to verify, that your Client Id and Client Secret work. See the snippets below for 2 different steps:

  1. First we validate, that the values work.
  2. If they don’t, let’s run another script to see if the Client Id exists but has expired.

Validate your Client Id by trying to connect with it

We can validate the Client Id and Secret, by using Connect-PnPOnline to connect to SharePoint Online. 

Continue reading

Solving “Tenant app deployment is only supported in the app catalog site. The current site is not the app catalog site.” error

Something went wrong in SharePoint

Got an error “Tenant app deployment is only supported in the app catalog site. The current site is not the app catalog site.”, even if the current site very much IS an app catalog site? There might be an easy fix!

Problem

Imagine this: you browse into your fresh SharePoint tenant, open the app catalog, click on an app, try to deploy it, and out comes this error.

Tenant app deployment is only supported in the app catalog site. The current site is not the app catalog site.

Yes, while trying to deploy an app from app catalog, you get an error that the current site is not the app catalog site. Frustrating!  Continue reading

How to enable custom scripts for a SharePoint site collection?

This article explains how to enable custom scripts for any SharePoint site. Different instructions apply to SharePoint Online, and on-premises scenarios (SharePoint 2013, 2016 and probably 2019).

Different solutions resolve the issue for different target sites:

  • Modern SharePoint Team Sites (attached to Office Groups)
  • SharePoint MySites
  • Personal OneDrive sites
  • Any SharePoint site collection created based on self-service site creation
  • SharePoint Online tenant root site collection
  • Any Classic SharePoint site collection

Errors and causes

Most typically I run into this when trying to insert a script web part with custom JavaScript into a site, that has NoScript enabled. That’s annoying – since script webparts are incredibly useful! Continue reading

A cautionary tale of relying on the automatic backups in SharePoint Online

Microsoft Stores Backups For 14 Days, But Restores Them in 15

So Microsoft keeps 14-day rolling backups of your SharePoint Online sites. That’s awesome – no need to take backups anymore, right?

Not so fast. It’s not always so easy, and by just relying on these backups, you risk losing your data. Forever, I might add.

This cautionary tale is about SharePoint Online, but I’d say you’ll need to take caution anytime you’re dealing with Microsoft’s automatic backups. The story starts with the client doing something unwise – a prime example would be them removing the root web of their classic SharePoint Site Collection (don’t do that!).  Continue reading

Opening a web part page in maintenance mode

SharePoint doesn't work as intended

Can’t access a web part page because of a broken web part? Yeah, that’s a classic issue – and it’s nicely ported into Modern world, too! In these cases, web part page maintenance mode comes in handy!

There’s a query parameter available for accessing it. For whatever reasons, it’s different for Classic and Modern mode, though. Why make things easy if you can make them dificult, right? 🙂  Continue reading

Hackathon win: Resolving Managed Metadata Madness

Won my first hackathon!

I won a hackathon! They had fun topics, it was a cool challenge, a well organized event, and had cool prizes. Since this is the first hackathon I ever took part in, I thought I’d post something about my experience and the solution(s) I figured out. Continue reading

Don’t remove the root web of your classic SharePoint Site Collection!

Let me explain SharePoint

A quick heads-up – if you remove the root site (or RootWeb, like it’s called in the code) of your classic SharePoint Site Collection, that’s going to cause you some grey hairs. Whereas you can always restore a normal site from the site collection recycle bin, the root site you can’t. You actually can’t access the recycle bin after removing the root site, nor can you make magic happen with PowerShell commandlets anymore.

Site Collection Recycle Bin

Site Collection Recycle Bin – where you could access your removed sites, if you still had the root site!

The Recycle Bin would be located at a URL like this: https://<yoursite>/_layouts/15/AdminRecycleBin.aspx, but after the site is removed, it won’t be there. 

Continue reading

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:

Cannot contact web site 'https://<tenant>-admin.sharepoint.com/' or the web site does not support SharePoint Online credentials. The response status code is 'Unauthorized'.

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

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.

What awakens my curiosity, is this line:

Access denied. Before opening files in this location, you must first browse to the web site and select the option to login automatically.

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. Nothing you can do permissions/configuration-wise, but luckily – there’s a hazy and weird, but simple PowerShell-based fix! 

Continue reading

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.

Description 

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

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