As discussed in the previous post, we can enable developers (and users) to upload custom apps to Microsoft Teams. However, sometimes (and most often) you don’t want to enable everyone to upload custom apps everywhere. This is where Teams enables you to have granular control on who can do what.
First step is to ask this question:
Did I block custom apps at all in my environment?
The very first option that you will need to be aware of is the “Allow interaction with custom apps”. This setting is found by going to the Teams Admin Center > Teams Apps > Manage Apps > Org-wide app settings:
Once this setting is enabled in your tenant, you can now move forward and control who can upload custom apps. If this setting is off, then you won’t have a way to upload custom apps to your tenant, so if you need to upload apps, you’ll need to make sure this setting is on. (Note, in cases when you want to stop uploading apps altogether to the tenant, you can always use this option to shutdown this capability)
Now with this option enabled, in order for a user to be able to upload a custom app, you’ll need to ask this question:
Is the user assigned a custom policy that allows him/her to upload an app?
The user will need to be assigned an app policy that has uploading custom apps enabled.
This can be done by going to Teams Admin Center > Teams Apps > Setup Policies. By default, developer tenants will have this policy enabled by default, but if you want to sideload apps in other tenants, you’ll need to have at least one policy where “Upload custom apps” is enabled.
Once you have the policy set to upload custom apps, go back to the policies list, select the policy, and add the user you want to grant this access to for this policy:
After you add the user to the policy. The user will be able to upload custom apps depending on the answer of the upcoming question:
Will the user need to upload personal apps only or teams apps?
If the user needs to upload personal apps only, then it’s all good so far and the user can do so. However if the user needs to upload custom apps to a Team and that user isn’t an owner, then the Team owner should enable the option for members to upload custom apps. This can be done on the Team settings itself:
For a better understanding for those who prefer visual sequence, you can consult the following diagram:
I hope this helps someone out there! Enjoy Teams App development!
We hear the term “Sideloading” when it comes to Microsoft Teams, we even used to hear that when talking about SharePoint apps. So what does it mean to sideload an app in Teams and who can do it?
The “normal” way of uploading an app to the tenant in Teams is to upload it to the organization app store without sideloading (we’ll talk about sideloading in a minute). In the organization store, it will be available to the all tenant users to install. You can view all tenant apps when you click on Apps in the left-hand rail in Teams client, you will find your custom apps available for the current tenant under a section named: Built for [Tenant Name]
To upload an app to the organization store, you can do it from the same page, by clicking on “Upload a custom app” then click “Upload for [Tenant Name]”
You can also do the same from the Teams admin center by clicking on Teams apps > Manage apps > Upload:
Now.. what if we’re developing an application and we want to test it in the scope of a team or a personal scope? We don’t want to upload it to the whole tenant rather just to a specific team. That’s what sideloading does, it allows us to upload an application to a team or personally without showing it to the whole tenant.
This setting is controlled in Teams Admin Center, if you go to Teams Admin Center > Teams apps > Setup policies. You can create a new policy and ensure to enable the setting “Upload custom apps”. Upload custom apps is just the equivalent of “Sideloading”. After you create the policy, assign it to yourself (or any person that you would want to upload custom apps):
In developer tenants, you will notice that this option is already enabled through the “Global (Org-wide default)” policy:
After you enable the policy to upload custom apps and make sure it’s assigned to you, when you go to the Apps section in the Teams client, and click on Upload an app, you will notice the option to “Upload for me or my teams”:
Note that enabling sideloading might take sometime for the new option to show up in Teams. (up to 24 hours).
Also remember, you can control who can sideload apps in teams by assigning users to the new policy you created in Teams admin center. In the next post, we’ll go over policies and settings that enable us to have more granular control on who can upload apps to our tenant. See you in the next post!
If you work with multiple tenants and for each tenant you login with a different account, you might want to have a smooth way to use Teams across all of these tenants. One way to do it is by adding the Team as an App. In this post am using the new Edge browser (Which will be the default browser on Windows in April). But the same thing can be done with Chrome as well.
Let’s say you use Teams client with your main account, in my case @bdo.com but at the same time I’d like to login to Teams on my personal dev tenant @technifier.com. To do so, I can go to teams.microsoft.com and login with my @technifier.com account. Once I have Teams open there, click on the options menu and click on Install this site as an app:
Now it will install this browser instance as an actual application on your computer. You can now give it a name, in my case Technifier Team
You will notice that it opened in your taskbar as an actual application, now you can just right click it and pin it to taskbar.
There you go. You can even search for the application in Windows and it will appear as a regular application:
Note, if you’re not getting notifications when someone sends you a message on that Teams instance, make sure you’re allowing notifications from Teams in your browser. To verify that, go to the browser options list, and click settings:
Search for notifications, and make sure notifications are allowed for teams.microsoft.com:
Now when someone sends you a message, you’ll get a Windows notification:
When dealing with external users in Microsoft Teams, you would find yourself having to add users to your Teams, and when this functionality is enabled across your organization, you would want to have a way to review this access in order to have more control on who can access resources in your environment, in this case, it’s Microsoft Teams.
The way we can do it is by utilizing Azure Access Reviews which is available in Azure AD Premium P2. By using Access Reviews, we can create a policy to remind Teams Owners or basically anyone in the tenant to be responsible for reviewing the guest access on these teams. We can choose to review all teams guest access in the environment, or select specific teams. We can schedule the access review to be done on regular basis and having decisions made upon review completion. For example, if a guest is denied access to one Team, then remove the guest completely from the tenant or just remove the guest from that specific Team.
Let’s dig into how this actually works. I’ll first invite a Gmail user to my Team as a guest user:
Users will get an email notifying them that they were added to the team:
Note that even as a Gmail user, you can be added to multiple tenants, and sign in with your Gmail account, you will be able to see the tenants just like any normal Teams user who’s using his/her Microsoft 365 accounts:
Now, we’d like to review this Employee Onboarding Team, since, let’s assume it contains lots of guest users. Remember we can set the review access to be done across many teams that have guest users, but in our scenario we’ll do it just one for one to demonstrate how it works. Head over to Microsoft Azure AD, click on Identity Governance, then click on Access Reviews:
Now we’ll need to create a new Access Review, so we’ll click on New access review and choose Teams + Groups. It will ask us if we want to create the access review for guests across all Teams or just select specific Teams, in our case we’ll select a specific team and set the scope to Guest users only.
In the reviewers selection, we can decide if the group/team owner should be the one doing the review, or select a specific person, or even let users review their own access. In preview, it allows current user’s manager to review their access, which depends on the manager’s property in the user’s profile.
Next comes the scheduling, and how it works is that you define the recurrence, to either happen one time or on a Weekly/Monthly/Quarterly/Semi-annually or Annual basis. So in my case I’ll define Weekly and set the duration to 3 days. 3 days means that the reviewer will have 3 days to review the status, after that there’s a job that will run and make a decision upon the current reviewers selection. I’ll get to this point later in this post but let’s continue with defining the schedule. You can choose the start date and the end date of this schedule, and then hit Next.
The next page tells you if you want to apply a decision to the resource (being user’s access to that resource), so make it enabled. There’s also an option on what to do if the reviewer doesn’t respond, which allows you in this case to choose on whether to keep the user’s access to the resource (the team) or deny it. The next option defines what happens when the access is denied which is really cool. You can define if the user’s permissions is removed from that team but still gets access to your tenant as a guest or being removed from the tenant completely.
Other options on the page are self-explanatory, however one thing that is worth mentioning is the decision helper, which will provide you with recommendations when you actually start the review process and will advise you on whether to approve or reject the access. Now you can give your access review a name and hit Create, and we’ll have our access review ready.
Now when the date of the review arrives, you as a reviewer will receive an email asking you to start the review process:
When you click on Start review you will be redirected to Access reviews page where it will list all the reviews that you need to complete. In my case I’ll deny the access for this user even though the recommendation by Azure is to approve it (remember that you can enable recommendations when you configure the access review):
Now here’s the catch. Even though you clicked on deny and you expect the user to be removed from the team, it won’t be removed.. why? This actually confused me at the start, but the actual decision is applied when the review period ends. So if you set the period schedule to weekly and the period duration to 3 days, it will wait for 3 days until it acts upon your decision even though you made the decision on the first day. So you actually have sometime during the period to change your mind and approve the user’s access again. When the period ends, you will get an email telling you that the review ended and your decision will be applied to the resource (the team):
Now that the review decision has been applied, head over to Microsoft Teams, and you’ll see that the guest user is gone! Such a nice way to do reviews across many teams which is really beneficial for large organizations with many guest users all over the place!
In this blog post, we will learn how to apply naming conventions to our teams. As large organizations have special needs on what teams’ names would be in order to easily manage them, it’s essential for teams admins and even anyone who is working professionally with Microsoft 365 to know how it’s done.
The ability to apply naming convention to Microsoft Teams is done by applying a naming policy on groups in Azure. Once the policy is applied on the groups then any newly created team will be constrained by these rules. Any existing Microsoft Teams won’t be affected by these rules. Also note that in order to make this work, you will need to have Azure AD Premium P1 license (or EDU license).
Let’s have a fun scenario and say that in our organization, we would love that all newly created teams to be named as: Accountants-[Team Name] or Teams Developers-[Team Name]. Meaning that they should be prefixed by the person’s title + s-. How can this be done? This can be done by having a combination of an attribute prefix combined with a string prefix. So the combination of both would give us something such as [Job Title]s-[Team Name]. Note that I added an s to the job title as another prefix to achieve the s in Developers or Accountants.
In order to apply this policy, go to Microsoft Azure (portal.azure.com), and navigate to Azure Active Directory > Groups > Naming Policy
On the first tab, you can specify words that you want to be prevented from being part of your Team’s name. You can download the csv file, populate it with the required words, and reupload it again. Note that it’s not case sensitive, so if you add the word tips, TIPS will also be prevented from appearing in the team’s name, however tipss will be allowed.
Now click on the next tab that says Group naming policy, and here you can see we have 2 types, we have prefix and suffix, and under each one we can specify the policy to be based on free text (String) or based on user’s attribute. The attributes supported are shown in the dropdown list:
Note that not all user’s properties are supported and only 6 of them are at the time of this writing. Now to achieve our goal, we’ll have the first prefix as Attribute = Title, and the second prefix as s- so our newly created team would look like: Accountants-TeamName
Note that the prefixes and suffixes are applied in the order they’re listed here, by appending the latter to the previous prefix. Now save the changes and try to create a team. If you get an error like the one showed below that says: “The team prefix or suffix is incorrect, please try again”:
Don’t worry, as it takes some time for the changes to be applied. In my case it took around 10-15 minutes. Also note that if you’re testing with a global admin account then you won’t be affected by these policies and you can create teams with whatever names you want.
So with a regular user who’s title is Retail Manager, when creating a team, it will look like this for a team named Client Support:
The catch here is that this naming policy is done on the Azure groups themselves, which means if we try to create groups from another service, let’s say in Outlook, we’ll have the same constraints applied there as well: