Teams Real Simple with Pictures: Using B2B Management Policy in Azure AD to block Guest invitations to specific domains

called a B2B Management Policy. Now, why would we use this and how does it fit in with how we already manage guests? In terms of how we would use this, think of it as follows. When we enable guests in the TAC, we allow Teams owners to invite B2B users from any organisation. That's cool and frictionless - except thinking about zero trust, it means that we could be leaving ourselves open to insider risk and competitors being added to our Teams. Now, we could go down the route of using sensitivity labels - but we really want to simply block the competitors whole org and any of their users being added to ours as guests. We could go down the route of entitlement management - but this can be heavy and would involve actions on the part of users: besides; it could be bypassed anyway as EM doesn't lock the ability to add guests via Teams. No, we want something quick and frictionless and automatic: an all out block across the tenant. Well, we can do this in Azure AD. Now, to set expectation two things. Number one: this is simply another useful tool in the kit bag regarding management of guests: you would still use sensitivity labels and EM and this would simply layer over the top of that. Secondly, this isn't something that will all out block all sharing and communication with other domains: other things need to be added which will be referred to below. All good?

Teams Real Simple with Pictures: Terms of Use with Conditional Access

Happy Christmas! I hope you have enjoyed the last few days - and whether it has been with family, friends, going shopping, eating out, going to church, taking exams or feet up binge watching movies and taking a real break from everything I really hope you have managed to spend it how you have wanted to after a full on 2021. You deserve it. Me? I'm spending most my with my family, but during the holidays I'm also taking some a bit of time to clear the decks for 2022 and refocus on several things which I've missed doing this year. One of those things is the Microsoft Tech Community. Tech was where I first started out doing community work back in late 2018. I did it compulsively right up until the beginning of 2021 and it's been a big part of my life the past few years. It's a place where I met a lot of my community friends: people like Adam Deltinger, Chris Webb, Juan Carlos Gonzalez Martin, Vasil Michev and Linus Cansby. Its a place where I got the opportunity to help people directly. It's also the place which led to many more opportunities including Teams Nation. Yet with everything else going on this year - work, events, exams, speaking on the circuit, you name it - it's been tough to allocate the time in order to really get back into it like I used to. So I needed to change things up in order to get back to the start, and having re-engaged the last few weeks I feel much happier and sharper. Now one of the questions I was asked was regarding Terms of Use. This is fortunate considering I am teaching Microsoft SCI Fundamentals next month and it's a component of that. Terms of Use is an Azure AD functionality but applies to many services including Microsoft Teams. Do you require employees or guests to accept your terms of use policy before getting access? Do you require employees or guests to accept your terms of use policy on a recurring schedule per your compliance policies? Do you require employees or guests to accept your terms of use policy as part of a conditional access policy? Once you use it, it seems strange that you wouldn't want this in place to ensure anyone who is accessing your environment is accepting your terms - especially as it's an Azure AD P1 functionality and available to small businesses as well as large

Teams Real Simple with Pictures: Let’s saddle up and apply Adaptive Scopes to Retention and Label Policies

course updates. I am also back on the circuit courtesy of aMS Germany and Power Platform France. As always, thank you to the organisers for having me. Yet, despite all this good stuff I am also acutely aware that I haven't done any technical writing on the blog since the day before I got Covid - and as my good friend Vesku Nopanen released one today on the new Whiteboarding features in Teams, the situation demands I write. So where to start? Having effectively had two months off I can certainly say I am not in short supply of subject matter - but one that I thought I would start on since I am really interested in it is adaptive scopes for retention and label policies.

Teams Real Simple with Pictures: Granting Org Wide Admin Consent to an App

To all my friends and readers from the US - happy independence day! And to everyone else I hope you are enjoying the summer. It's nearly time for a break. But unlike my Scandinavian friends Vesa Nopanen and Adam Deltinger who are taking a month off - a month! (they tell me it's cultural), I still have a few weeks of grafting. Well, not all graft since Microsoft Inspire is here on the 14th and since I am going as an attendee it'll be enjoyable to just kick back and watch some sessions; something I have rarely done the last few years as I have been doing lots of speaking and moderating. So after focusing on Stream and the new web experience last week I am going to jump back into Teams this week. I originally thought about writing on Teams Meeting Recordings since I have an upcoming talk at the end of the month on exactly this. Yet something caught my eye in the Teams Admin Centre (TAC) and you know me...I thought I just have to write it TMR's can wait. Now this functionality is called Org Wide Admin Consent to an App. Sounds abstract right? Yeah. In layman's it's all about allowing apps permission to do what they need to do in your environment on behalf of users. Examples would include the ability for an app to read information stored in a team, for an app to read a user's profile, for an app to send an email on behalf of users and so on. Typically, when a user adds an app from the Teams App Store or starts using a custom or third party app, they have to grant the app permission. So administrators doing it on their users behalf can be beneficial. Why? It saves time, potentially a lot of confusion and makes the process of adding an app much more user friendly. Secondly, for the admin it gives them more control of apps and another tool alongside blocking, app permissions and custom app configuration. Third, users may not even be allowed to give consent as the admin may have locked this down already in Azure AD as part of their enterprise app configuration. Now, some things to know right off the bat is that org wide admin consent to an app can only be done by a global admin - not even the Teams Service Admin can do it. Secondly, it applies only to custom and third party apps. Microsoft's are exempt. Finally, org wide admin consent to an app is a much broader brush than resource specific consent (RSC) which is granular and applies to specific teams, so careful review has to be given before applying it. Sound good? Let's get going