Microsoft

Microsoft really knows how to get me frustrated

by

While I was working on a walkthrough on authentication and authorization I decided to use the Microsoft Graph API as an example. In this example I wanted to use application permissions to list all users. Nothing special. Configured my application, wrote some code but… got an error message telling me that my application does not have the required permissions to read all users. So let’s go back to Azure and verify the permissions.

Azure Active Directory Permission Assignment
Azure Active Directory Permission Assignment

Looks pretty good. I actually do have some experience with authentication and authorization – which is why I’m writing this walkthough – but I do not have a clue about what I did wrong. No warning messages here. OK then, let’s search… and GitHub?! contains the answer. It appears that Microsoft decided that besides the permissions given by the administrator, the service principal also needs to be a “Company Administrator” (which you cannot configure from the UI) as a security measure. So the UI is just complete bogus without that role being assigned first. And another hour of my time is down the drain…

UPDATE:
To be consistent with not being consistent Microsoft does allow you to fetch all users if you use the BETA API (https://graph.microsoft.com/beta/users) as security in a public BETA – that is automatically enabled for everyone – apparently is not that important.

Who needs documentation?

by

While working on a solution that is supposed to list Azure Resources using client side code, I came into contact with Azure Resource Manager REST API. And honestly this is a pretty awesome collection of API’s! Now the whole issue with this API is that it is actually a constantly changing collection of API’s and that there is no documentation available at all. How useful is that?

Sure they’ve written an article with the title “Azure Resource Manager REST API Reference”, but it contains high level information only. They actually tell you that the best way you can find out what will be returned by the API, is by using a tool they call Azure Resource Explorer.

The first issue I have with that, is that you can only execute calls on resources that you’ve got in your Azure Subscription. So if you would like to find out what response will be returned when you request information on a Storage Resource, you will first have to create such a resource in your Azure Subscription. You can then use the Azure Resource Explorer, to see the JSON result returned. This will tell you nothing of course about the actual schema that you can expect.

The second issue I have with that, is that I have no way of creating a decent client side proxy with something like T4 templating. So it took me a couple of weeks to create a client side proxy to get only the basic information and it’s all based on guessing. Good job Microsoft!

Did nobody at Microsoft every heard about something like Swagger?

UPDATE:
Microsoft did hear about Swagger! Their own PowerApps product can connect to custom API’s as long as you can provide the definition file in… Swagger format! But wait. “Does that mean that I cannot connect to Microsoft’s own Graph API to fetch person details into my PowerApp unless I create the Swagger definition file manually?” Yes… sigh.

Reliable Microsoft

by

Microsoft has released a new future proof development method, with the last 3 versions of SharePoint. We’ve seen Sandboxed solutions, CAM applications (or should I say Add-ins?) and now they are about to release the ‘SharePoint Framework’. SharePoint is responsive now and our enterprise collaboration platform will work much better on mobile devices.

Public sites, like WordPress, must be response and mobile first nowadays, but collaboration sites for office workers can and should definitely focus on desktop (only?). If you want to add a limited, search driven, mobile view on top, sure, go ahead, but not mobile first. Weird as it may seem, in the enterprises I visit, most employees still use a desktop or laptop for office work. I don’t see a lot of employees with an empty desk, writing Word documents with their thumbs.

The funny part is that in January 2015 Microsoft discontinued the “SharePoint Online Public Website feature” for the following reason: “As part of the evolution of the Office 365 service, we periodically evaluate the capabilities of the service to make sure that we’re delivering the utmost value to customers. After careful consideration, we concluded that for public websites, Office 365 customers would be better served by third-party providers whose core competency is public websites. Therefore, we’ve made the difficult decision to discontinue the SharePoint Online Public Website feature so that we can focus our efforts and investments on delivering capabilities in Office 365 that will bring more value to our customers.”

So they first acknowledge that they have no real understanding of public web sites, and now they change the collaboration UI so it will behave more like public web sites? Okay…

The real problem I – as a consultant – face however, is that they’ve become a completely unreliable partner. The biggest laugh I had is when they suddenly shutdown coded Sandboxed solutions a few weeks ago. Yes, they’ve been telling us not to use coded Sandboxed solutions anymore because they are deprecated, but unfortunately the CAM model is still not up to par yet. Sometimes it is simply not possible to update or upgrade your coded Sandbox solution towards the CAM model. The reason they gave for stopping these coded Sandboxed solution now, is that they are not able to maintain this infrastructure as it does not scale. However…
When several migration tools stopped working, they somehow could make an exception for just those tools. These exceptions are however not available for paying customers. So not alone the infrastructure is still in place – even though they said they cannot do that anymore – but we now know who Microsoft values more, and it is apparently not its paying customers.

Now what can I advice my clients? I cannot tell them to use the “Yet Another Dev Method” for their future proof customizations. We’ve seen that these new development methods are as future proof as whip cream. So maybe the only honest advice I can give them is to either change their processes so they fit OOTB SharePoint, or not to use SharePoint at all anymore.

One last thing. I’m going to be bold here and make an prediction on when and what the new future proof development method for SharePoint web parts will be. In 2019 the new future proof development method for SharePoint web parts is: Web Components!