Teams Real Simple with Pictures: Custom Policy Packages

On the speaker circuit I occasionally talk about Policy Management in Microsoft Teams. It's something I enjoy talking about too. Why? Because when it comes to Teams I believe having a good grasp of policy is necessary for shaping a good user experience. It's important too from a security, compliance and governance perspective. Now like any talk this one's evolved to account for a number of incremental adds. We've seen the introduction of update policies where you can add users into private preview to test out functionality in advance. We've seen template policies. We've seen the ability to use the TAC to manage meeting backgrounds within the meeting policy. And during all of these talks one of the things which has featured has been policy packages. Policy packages are defined as 'a collection of predefined policies and policy settings that you can assign to users who have similar roles in your organization'. In other words, we assign a policy package to a teacher, or a student or a nurse or to a firstline worker - and that policy package contains a messaging policy, and a meeting policy, and a live events policy and so on and so forth. The benefit of the policy package - a container as it were similar to an access package in Azure AD - is that it makes it easy for administrators to standardise what users can do and how users can experience Teams based upon role. It can make it easier to assign multiple policies without getting too granular. An awesome functionality is that you can also use group policy with dynamic groups and assign the correct packages as users transition roles. Yet for all the virtues of packages, the big limitation has always been we couldn't create custom policy packages. We've had a number of preconfigured ones by Microsoft - and that's all well and good except we've needed to create packages for our own roles, our own organisations. Well now we can

Teams Nation reaches 1000 registrants, and will be returning April 6th 2022

The excitement for Teams Nation is building. Today, we discovered that we had surpassed 1000 registrants, which is absolutely amazing considering that just a few weeks ago we thought that we may not have been able to run Teams Nation at all. Now that the dates for Microsoft Build have been officially confirmed (25th - 27th May) we can disclose that we discovered these dates via a leak online and had to make an immediate call on whether to stick with the date of 26th May, whether to reschedule or whether to cancel it outright. Since we had committed to doing another event last October - the first since we changed the name from TeamsFest to Teams Nation we really didn't want to can it since we had been working on it since the new year. We also decided that it would be unfair to make attendees choose between Teams Nation and Build as we thought many who would register for our event would ultimately like to attend both. So we ended up bringing Teams Nation forward by two weeks to Wednesday 12th May. Our choice on this date is mainly due to when all of us were available, as well as avoiding conflicts or being too close to any other events that we were aware of in the calendar

Teams Real Simple with Pictures: Using the TAC to manage users backgrounds in Teams Meetings

A real short one this week - for two reasons. The first is that I am on annual leave - and whilst annual leave may conjure up the romantic idea of taking a break, this is when I usually crack on with the long list of things which I need take care of at home. This Easter weekend has included completing a 6 x 8 concreate base for a shed, and putting up a large trampoline in the back yard for my son. Secondly, I was all up for writing an in depth blog for Viva Connections - and I started doing that until I realised that the SharePoint app bar hasn't surfaced in my demo tenant yet. I decided I didn't want to push something out that I wouldn't be ultimately happy with. So in the meantime I was searching for something to write about when I saw that the ability to control meeting backgrounds has now come to the TAC. For some time this has only been available in PowerShell - and whilst this blog will literally be up there with the shortest I have ever written, the functionality is really important to consider for all organisations. Why? You see when custom backgrounds were first released there were a lot of people on social racing to advocate how these could be back doored on windows machines. And whilst I agree they were great for identity and personalisation, and great for marketing and buy-in in regards to adoption, I also agree they can be problematic for IT admins. How can they be policed? How could you stop someone in your organisation uploading something offensive as a background? Whilst I hope you haven't seen anything offensive I personally have. I've seen someone outside my organisation using a hospital ward as a background because they thought it was funny to do so during lockdown. I've seen another - again outside my organisation - using politicised images which aren't appropriate nor professional for any type of meeting. Where have they got those images from? Are they commons or are they copyrighted? So we need to make a call, especially as Microsoft Teams does not screen backgrounds which are uploaded by users. Surfacing these in the TAC is good in that it brings attention to these controls, but also helps admins which, let's face it, don't like PowerShell or don't read Docs all too often. Every IT admin now has the ability to easily control backgrounds based on the tools they like to use

Teams Real Simple with Pictures: Setting Table Permissions for Dataverse for Teams Apps such as Bulletins or Employee Ideas

Last month I wrote a bit about the new Power Apps Templates in Teams - Bulletins and Employee Ideas, and last week I discussed Applying DLP policies to the environments these apps are housed in. Now It feels pretty natural to continue this conversation about data and discuss Table Permissions within the apps themselves. This is because it's these permissions which determine how users inside and outside the team - and guests - can work with the apps and the data that they contain. Firstly, it's important from a usability perspective that we can granulate access. Think of the following scenario - one team member needs full access over one app in the environment because they are managing it whereas that same user may only need read access over another because they don't need to touch any data within it or add any data to it. You may also want team members to be able to modify data with a specific part of the app - for example links in Bulletins, and not in others. This is all possible with table permissions. Secondly, it's also important from a security and compliance perspective. We want the users we need using the app in the way we specifically need them to use it. Circling back to the DLP conversation last week whilst we want to trust that others will handle the apps and the data within them in the right way, having carte blanche in terms of permissions, or even having permissions for certain users, or guests, at all opens things up to all sorts of risks including insider threats. Like DLP, this is certainly something we want to think about when we deploy, or when we are sharing it outside the Team

Teams Real Simple with Pictures: Using Data Loss Prevention (DLP) to stop data leakage from Dataverse for Teams Apps such as Bulletins or Employee Ideas

Last month, I wrote a bit about the new Power Apps Templates in Teams - Bulletins and Employee Ideas. I really liked them. They are really useful for bringing in new functionality for Teams and filling some gaps, they can be used by both users inside the Team where they are deployed or outside of the Teams via the broad distribution functionality. They can be extended by developers looking to build on the functionality which already exists. However, in thinking about how these apps can be extended we must also put our security and compliance hats on and think about how the ability to extend them can be controlled - particularly in terms of connectors and data leakage. You see, when we start using these apps we will begin adding data - company data. In the case of bulletins we add things like company news, URL's and even contact details. In the case of employee ideas we add ideas about how the company may improve and these ideas could - for example - be based on company data or expose where the company is lacking. Whilst we like to believe that everyone who has access to modify these apps have the best of intentions, it is too big a risk to simply assume that data will never be exposed - accidentally or maliciously via connectors to places where it shouldn't be seen to audiences who should not see it. A good example is Twitter. Our data makes it onto Twitter it could seriously damage our brand and we could be facing some legal consequences