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!


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

How to get the user count for Azure AD Enterprise Application

PowerShell header

Have you ever tried to find out the number of users of an enterprise application in your Office 365 tenant? For apps with under 100 users it’s easy – just open Azure AD and check the user count. For more popular apps, it’s a lot more difficult, as Azure AD just shows “100+”. However, with some PowerShell magic, we can dig out the real user count!


When you have an “Enterprise Application” in your Azure AD, you can quite easily access its properties from the Azure Portal. However, if you want to find out the number of users using the app, that’s not as straightforward.

Continue reading

Solving “Sorry, your files couldn’t be uploaded. The upload might be too large or the server might be experiencing high network traffic.” in SharePoint

SharePoint cat fixing them errors

This is one of the kind of weird issues that you don’t really run into in your own development environments, but that you more often run into when you actually have non-godlike permissions. Oh, the woes of trying to use SharePoint with anything less than farm/global administrator… 🙂 Anyway, in this post I’ll describe a couple of solutions to an error: “Sorry, your files couldn’t be uploaded. The upload might be too large or the server might be experiencing high network traffic”.

You might encounter this issue, when uploading pretty much any files in any SharePoint document library. Typically, I run into this when trying to update a file in a library (in my case, the only times I’ve ever seen this, have been the Style Library of a SharePoint site). You can apparently encounter it with any file type, in this example below, it happened with a JavaScript (.js) file.

Style Library throwing an error: "Sorry, your files couldn't be uploaded. The upload might be too large or the server might be experiencing high network traffic."

Style Library throws an error:
“Sorry, your files couldn’t be uploaded. The upload might be too large or the server might be experiencing high network traffic.”

Funnily enough, I usually encounter this issue with a following set-up:

  • On-premises SharePoint server (2013 or 2016 – occasionally also SharePoint Online, but that’s less typical!)
  • Small files (of 1-200kb)
  • The server has been experiencing very low network traffic.

The error really doesn’t seem to describe the issue at all – so what’s actually causing this?


Quick googling didn’t give any actual reasons or fixes for the issue. A lot of people online seem to suggest changing your browser to something else from Internet Explorer… While it might not be a bad idea in itself, it does seem like a ridiculous fix – and also didn’t work for me 🙂

However, every single time so far, going through this checklist has helped me solve the issue and get rid of the error: Continue reading

SharePoint Localization – a (somewhat) comprehensive how-to!

Let me explain SharePoint

Localization – or showing users with different language preferences content in their preferred language – is not SharePoint’s strongest suite. It never was, and probably will never be, unless Microsoft perfects Machine Translation at some point. And even then it would probably require extra subscription, as Cognitive Services APIs are not available (above the peasant-tier) for free now either. In this article I’ll go through a few survival strategies for multilingual organizations – and I’ll try to expand the content as more options pop up!

Please note, that this article revolves mostly around Classic SharePoint. Microsoft’s current implementation of Modern SharePoint offers little-to-nothing for a controlled localization. It offers a curious way to use MUI to offer multilingual chrome with non-localized content, and that’s about it… But some of my tips work in Modern, too.

Different out-of-the-box localization features in SharePoint

So, what can SharePoint do out-of-the-box? There are a couple of features one can use – let’s go through them!

Continue reading

Fixing the error “Web Deploy cannot modify the file on the Destination because it is locked by an external process.”

"Publishing Failed" for an Azure Function

This post describes how to fix the error, where when publishing Azure Functions or Azure App Services you get an error like this: “Web Deploy cannot modify the file on the Destination because it is locked by an external process.”

This is luckily another straightforward fix! 


Azure Function Publish fails with a message:

“Web Deploy cannot modify the file on the Destination because it is locked by an external process.”

It is, indeed, caused by some of your files at the target of your publishing being in use, so they cannot be overwritten. Great – an actually accurate error message! Much appreciated.

This seems to apply to Azure Functions CLI versions 2.x (currently in beta), and not for the stable versions. At least that’s the state at the time of writing this. There’s even this unresolved issue open about it on GitHub.

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

How to fix Twitter embed in SharePoint

MFW another API just stops working without returning any errors

Twitter has always been good for developers, except for those who’d like to embed anything – hence making it possible to interact with their contents on other sites than Twitter. I guess it’s understandable, but they seem to hate anyone trying to embed feeds, searches or anything on their sites. And they express their hate by making the developers’ lives more difficult… This time by silently breaking the embed script in a way, that’s tricky to work around.

The Problem

In February 2018, Twitter announced that their widgets will start rendering fallback markup on IE9 and IE10 “in the near future”. Since SharePoint 2013 and 2016 are locked in document mode of IE 10 (i.e. using IE on SharePoint sites causes the user agent to be roughly that of IE10), that means trouble for SharePoint admins. Basically everyone, who’s using Twitter embeds on SharePoint, will be seeing empty feeds henceforth.

Well, save for SharePoint Online users, since SharePoint Online renders in whatever mode Microsoft chooses that week! For them, Twitter feeds will act like erratically, and I feel bad for whomever has to debug the behavior!

Anyway – that change’s immediate effects were surprisingly small. Widgets still rendered, until roughly 2 weeks ago (early May 2018). We started getting reports of Twitter being utterly broken – the embed being completely empty without any fallback rendering whatsoever. What’s worse, the embed fails silently, without any errors anywhere. Looking at the code, it looks like it just checks the user agent and ends the execution – thanks a lot, Twitter, much appreciated!

What’s even worse, is that it applies to IE11 users, too – if they’re in SharePoint, or on a site that’s running in compatibility mode (such as all sites on “intranet” zone). And since IE seems to be most actively used in large organizations, especially on internal communication channels, Twitter just decided to block the majority of IE users in the world from accessing their service via embeds. 


Luckily, there’s a dirty hack for this situation!

Continue reading

Solving Azure Web Application’s first load perfomance issues

Microsoft Azure logo

Is your Azure Web Application suffering from absolutely horrible load times every time someone accesses it for the first time every 15 minutes or so? Mine was. It was pitiful.

I was developing a web-based service using EF6 and ASP.NET MVC 5, where all the assets were hosted in the Azure. Even though the app was reasonably lightweight and usually responded very fast, the first time someone accessed it in a while it took 20-60 seconds to load AND sometimes even timed out (especially with mobile clients). Load testing revealed only the what I already knew: initial load times were horrendous, but after that everything worked fine. I did eventually find the solution, though!

Continue reading

Troubleshooting: Anonymous access on a public SharePoint site collection failing

SharePoint vs. Anonymous

Ah, everyone’s favorite, classic topic! Debugging SharePoint On-Premises configuration issues is the best thing since sliced bread, right? This post is about allowing/enabling Anonymous Access to a site collection – a simple configuration, that “simply works” like once every ten times you try it.


A lot of different ways to hit your head on this one. In any case, your on-premises SharePoint doesn’t allow anonymous access to a site where you are trying to allow it. Most typically, they’ll just encounter 401 error when accessing the site, or they might be missing some of the content or styles, resulting in partially broken site.


Usually incorrect configuration or non-published resources. Multiple reasons can cause this, though, I’ll describe some of them below with the solutions.


A lot of things to check – let’s go through all of the most typical issues here! Continue reading

Solving error “AADSTS90013: Invalid input received from the user”

AADSTS90013: Invalid input received from the user. (header thumbnail)

I stumbled upon a customer, that complained about some pages in their intranet throwing weird errors with authentication. Those pages seemed to have one thing in common – there was a Yammer embed (or a SharePoint script webpart with Yammer embed script in it, to be precise) there. The error code they got was “AADSTS90013: Invalid input received from the user”.

Below, you can see an example of the error screen.

AADSTS90013: Invalid input received from the user.

AADSTS90013: Invalid input received from the user.

Okay – this is going to be extremely specific, and probably won’t solve the issue for all of you out there! But this is what worked for this customer: Continue reading