Hey, I’m back. Long time since I did some writing on this blog. But I needed to get this one out. As you all know I’m a huge fan of the Microsoft Teams extensibility model and now with the SSO support for Tabs, it’s even easier to create integrated experiences for your end users where they can consume data and information from the Microsoft Graph or LOB systems. I recently did a small appearance at the Microsoft 365 PnP webcast showcasing how to configure and scaffold a Microsoft Teams project that uses this new SSO Tab feature.
I’ve been building chat-bots for a while now and I’m seeing more and more requests of building these bots for enterprises. For bots targeted at the enterprise, perhaps being hosted in Microsoft Teams, one of the first requirements is that they should get data from their internal systems and most specifically from Office 365, through the Microsoft Graph. The problem here is that we need to authenticate and authorize the user, through Microsoft Azure AD, to be able to access these resources.
Over the last few days the issue on how to prevent users to create Office 365 Groups has popped up in all sorts of conversations. This blog post will show you how to do it in the correct way, and serve as a future reference. I’m not the only one who have blogged about this, it’s in many places including official documentation. But in many places both scripts and some caveats are either wrong or outdated.
One very common requirement in SharePoint, and other portal solutions for that matter, is to have the possibility to target content to a dynamic audience of users and even secure information based on dynamic rules. Traditionally this has been done with Audiences in SharePoint. Audience is a dynamic set of users that is compiled, usually once a day, and at compile time the rules of the Audience is evaluated. A SharePoint Audience is used to target information, but cannot be used to protect content - ie as a security group.