This blog is part of a series on Teams. For more articles, check back often
Written: 15/08/2021 | Updated: N/A
It’s kind of a weird time. A bit of a dry summer if you will. There hasn’t been a lot of conferences on or events. I haven’t written tons of blogs; mainly because there hasn’t been a great deal of major change when it comes to Teams the last few months. And whilst I’ve tried to keep things ticking over with a few user groups and a session at the Microsoft Reactor, I’m very much looking forward to things picking back up again in the Autumn. I’ll be at Commsverse. I’ll be at South Coast Summit too. There are several other events I may be at. But let’s see. I was saying to Vesku [Nopanen] we certainly all need a break given how crazy 2021 has been – we probably managed to stuff enough into H1 to compare to the whole of 2020: yet at the same time you always get the sense of wanting to be back out there and doing more. So this week the subject is, I guess, a bit of a filler – but it’s a legitimate ask and something I was asked this week by someone in my org. You yourselves may get asked at some point in the future. Why is Freehand by InVision visible in Teams Meetings? How can I get rid of it? Good news – there are ways and we can certainly do that. Can you as a user get rid of it by yourself? No. And there’s a bigger issue for you, the admin, than you realise. Why? Because Microsoft already have a Whiteboard app. Freehand by InVision is a third party app. What’s the problem with this? Users may get confused and when asked to use the Whiteboard they may end up using the wrong one, signing up for the third party app and then having company data stored in third party storage. You know, before the new meeting experience in Teams rolled out, people always asked why InVision was there and why Microsoft seemed to prioritise this specific app over others. If my memory serves me correctly it was in Teams before Microsoft’s own. However, with the ability to add apps to Teams Meetings due to meeting extensibility you would think it would be there not on the sharing screen, visible, by default. Now don’t get me wrong – this blog isn’t beating up on Freehand by InVision. Personally I have used it and I think it’s a solid app. However, this isn’t about whether an app is good or not. It’s about ensuring an easy and straightforward meeting experience for users who may not be as tech savvy as you. It is about compliance and it’s about users like me who if you never use something, and are likely never going to, why is it there at all?
This blog will cover
- How to disable Freehand by InVision for all users
- How to block Freehand by InVision for some users
- What if I want to check who is using it beforehand?
- What to do next?
- Teams Administrator or Global Administrator permissions
- Recommended Teams Licence (within an Office 365/Microsoft 365 Licence) to test
HOW TO DISABLE FREEHAND BY INVISION FOR ALL USERS
This is to not display Freehand by InVision in any meetings for all users within the organisation. This action will also disable the app and so it cannot be used in any context by anyone – in meetings, or in channels when collaborating. This will likely be the required action for organisations who are solely using Microsoft Whiteboard
1.) Login to https://login.microsoftonline.com with admin credentials
2.) Select Admin
3.) In the Microsoft 365 Admin Centre select Show All on the left navigation then select Teams
4.) In the Teams Admin Centre select Teams Apps and then Manage Apps
5.) Search for and select Freehand
6.) Swipe the status of the app from Allowed to Blocked
7.) Confirm that the app is now blocked
8.) Log out and back into Teams. Test out a meeting. No more Freehand by InVision for any users in the organisation in meetings
HOW TO BLOCK FREEHAND BY INVISION FOR SOME USERS
This is to not display Freehand for InVision in any meetings for some users within the organisation. Some could be using the app, and others not. You may want to remove it gradually, such as investigate if each department or user has used it before simply removing the functionality. For whatever reason, we can’t simply switch it off. In this scenario we would use an App Permission Policy. To note, an app permission policy will block specific users from using the app in any context – in meetings or in channels. You can’t have it so you can simply hide the app in meetings and yet still use it collaboratively elsewhere
This scenario will assume that half the users use the app and half don’t. In this scenario all users have the Org Wide Default Policy applied which allows all apps. Note: your configuration may be different than what is shown here and it’s important to state that the goal of this is to block the Freehand app in the policy applied to your users, or to create a new custom policy and assign it to your users.
1.) In the Teams Admin Centre, select Teams Apps and then Permission Policies
2.) We are going to create a new policy, select Add
3.) Give the policy a Name and Description (here called No Freehand by Invision Policy). Under Third Party Apps select Block Specific Apps and Allow all others
4.) Select Block Apps
5.) Search for, select and add Freehand
6.) Select Block at the bottom right
7.) Select Save
8.) Confirm the policy is created. Now the policy is created we need to assign it to users. There are several different ways to assign a policy in Teams including direct assign to the user, batch, group and policy package, however this example is simply going to cover direct assign to the user. Select Users from the left navigation
9.) Select View Policies on the user who you will assign the policy to
10.) We can see Mar has the Global Org-Wide Default policy which allows Freehand by Invision. We want to change this. Under assigned policies, select Edit
11.) In the right fly out, select the dropdown for App Permission Policy, set this to the policy you just created (in this scenario No Freehand by InVision Policy) and then select Apply
12.) The policy is now applied for Mar
13.) In a few hours time, Mar will no longer see Freehand by Invision in Microsoft Teams meetings. Rinse and repeat these steps to apply to other users, or use batch, group (only available via PowerShell) or Policy Packages to apply this to specific users. Since they can be applied for some users and not others, this allows a roll out around the organisation
Our job here is done.
No more confusion about which Whiteboard to use. No worrying about Freehand by InVision being lit up and users using this app alongside Microsoft Whiteboard in Teams. No corporate data being hosted in Amazon, or an app being used which isn’t ISO 27001 accredited.
WHAT IF I WANT TO CHECK WHO IS USING IT BEFOREHAND?
To better help make a decision which way you should go in terms of a simply disabling the app, or using an app permission policy, you can use the Apps Usage Report under the Usage Reports in the Admin Centre. If Freehand by InVision isn’t there at all – meaning being used in the last 90 days – you would probably be safe with disabling the app itself. If it is there you won’t be able to specifically see who is using the apps so you may need to reach out to Teams Owners to see if the app is installed
WHAT TO DO NEXT?
Stopping Freehand by InVision being used via Microsoft Teams is only one part of the issue: yes we have achieved what we needed to via disabling the app or applying an app permissions policy to the users we need. However, if users in the organisation have actively used Freehand by InVision that means that they may have set up InVision accounts to start whiteboarding in Teams meetings.
Having tested personally by creating an InVision account using the test tenant’s user’s credentials, it’s not easy to delete an InVision account once created: the user has to contact InVision support to delete it as it’s their policy they do not auto-purge unused accounts. However, users can log into their account and delete their data. The choice is yours on the deprovisioning strategy – and it remains to be seen whether InVision would delete all accounts linked to a domain upon an admin’s request – however my personal opinion here is that prevention is better than cure in this case and the app ought to be disabled or app permission policies applied before users get the opportunity to light it up.