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
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”.
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
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: https://devpost.com/software/resolving-managed-metadata-madness-in-sharepoint – 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. Some of which quite interesting, I might add! This prompted me to 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!
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:
It worked for my developer account, but just wouldn’t work for the test accounts! This is the error I got: Continue reading
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)?
Imagine this: You’re trying to add or use an app, but the requires such permissions from your tenant, that only an administrator can grant.
Typically to add this kind of an app, you’ll have to be 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
In this post, I’ll try to archive everything you need to download and install to get commandlets like Connect-MsolService working. I’ve had to do it a couple of times when changing laptops, so it’s good to document them somewhere! 🙂
I’ll try to even keep this updated as things change.
- Microsoft Online Services Sign-In Assistant for IT Professionals RTW
- SharePoint Online Management Shell
- Windows Azure Active Directory Module for Windows PowerShell (v1)
- Update 5.3.2018: Microsoft actually moved this documentation, and apparently hid it behind authentication somewhere (might require Global Admin or similar on your tenant to even READ IT… That’s smart.)
- If you installed it before, it’ll still work, but if you didn’t, never mind. Just see this step.
Now, to run cmdlets like “Connect-MsolService”, just start SharePoint Online Management Shell (or PowerShell).
If you also need Azure Remote Management (AzureRM) cmdlets (I always do!), run this in an elevated PowerShell:
# Install the Azure Resource Manager modules from the PowerShell Gallery
What to do if Microsoft hid the AAD module for PowerShell?
Fear not – only the last step (step 3) changed! Instead of installing the AAD module, you run this on PowerShell: Continue reading
This post describes how to run Entity Framework’s code-first migrations against a database located in the Windows Azure. This is done by running Update-Database commandlet with suitable switches, see below.
The problem and symptoms
Okay, so you’re developing your MVC+EF cool web app with a database in Azure, and you’re using code-first migrations. Cool! What’s nice with code-first-migrations is the fact they are run automatically even in the cloud the next time your app is running (as long as you publish your app with that little box ticked – something like in the screen capture below). But wait – what if there are conflicts – what kind of errors are you going to get?
Not very useful ones, I’m afraid, and it’s a pain navigating the Azure portal to fetch the log files. At some point – for me, it wasn’t the first time I ran the web app, but the phase when I was logging in – you’ll be getting the error the migrator internally throws. That might be enough to point you to the right direction, and maybe you’ll be able to figure out what’s wrong! But if that’s not the case, here’s the way to run Update-Database against your Azure Database!
This post describes an issue with EF’s code-first migrations, when mapping between DB’s DateTime and C#’s DateTime kind of fails, and results in Update-Database cmdlet failing. It’s more or less a prime example of a situation, where the error itself tells very little about the actual issue, and since debugging code-first migrations is kind of difficult (see the best tips for that here!), it’s cumbersome to investigate.
While running Update-Database in a code-first ASP.NET MVC5 + EF6 -project, you get a following (or similar) error:
An error occurred while updating the entries. See the inner exception for details.
The whole, pretty terrifying error message is the following:
This post describes how to work your way around the exception ‘Cannot open server – requested by login…’ The issue is caused by Azure’s somewhat annoying firewall logic, and might stop you from accessing your databases from your development machine.
When trying to publish a web project to Azure from Visual Studio, you suddenly get the following (or similar) error message:
“Cannot open server ‘xxx.xxx.xxx.xxx’ requested by the login. Client with IP address ‘xxx.xxx.xxx.xxx’ is not allowed to access the server. To enable access, use the SQL Azure Portal or run sp_set_firewall_rule on the master database to create a firewall rule for this IP address or address range. It may take up to five minutes for this change to take effect.”
Your IP address has changed (for any reason) and Azure won’t allow your login anymore (as there’s a built-in IP filtering enabled). Azure kind of works as expected, Visual Studio’s error message just isn’t the most useful out there. Luckily, instead of running stored procedures or navigating the constantly evolving Azure Portal to desperately try to find a place where to edit SQL Server firewall rules, you can do this directly and conveniently in Visual Studio.
It appears that the pop-up dialog mentioned below sometimes randomly does not appear. In that case, there’s another way to add the firewall rule, see here.
You’ll need to connect to the SQL Server through Visual Studio, which will prompt you to allow access to the server for your current IP address. Like so:
This post describes a few different ways of fixing the error “The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.” one can get when trying to package/publish a SharePoint solution, web site or Azure Webjob.
UPDATE 11.4.2016: I actually got this nasty exception on another occasion (Azure webjob publish), so I updated the text accordingly.
Visual Studio throws the following error when packaging a SharePoint solution to a .wsp file, OR when deploying or publishing your web project (for example Azure Webjob).
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.