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:
Users in Microsoft 365 (even experienced ones) often get confused as how languages work across the platform. This an important topic specially for organizations that operate across multiple countries, or in countries that have 2 official languages.
There are many areas where a language can be specified in Microsoft 365, and they can be grouped in 3 categories:
Group A: Services whos language can be changed in Account Settings.
Group B: Services who language can be changed in Delve.
Group C: Free For All. (Each service has its own way of setting the language).
We’ll be looking at each one of these categories, and then dig deeper into the new multilingual capabilities of SharePoint.
Group A (Account Settings): These services depend on the current user’s account settings to determine the language. If you login to Microsoft landing page: Office.com, and you want to change the language for that page or the language being used for Forms, Planner, Word Online, Excel Online. Then you need to do this using the account settings of Microsoft 365. To do this, you can follow these steps:
Click on your profile image, and click account settings:
Next, from “Settings & Privacy” section, click on Languages > Display language. (The display language is the one that is used to change the labels across the platform). Here you can assign the preferred language.
Group B (Delve): To change the language for SharePoint and OneDrive, the process is a bit more involved. There are 2 locations where the user can set the language, either on their browser or in Microsoft Delve. Delve has more priority than the browser language settings, meaning that if the user set their Delve settings to French, SharePoint sites will display in French (if French is supported on the site). If the user hasn’t specified a language in Delve, SharePoint will look for a preferred language in the browser settings. If the user hasn’t set a preferred language in both Delve and the browser, the site will be displayed in its default language.
For quick tests for SharePoint multilingual pages, it’s best to use the browser settings as it’s very quick to reflect the changes. Changing the language in Delve will take around 10 minutes to take effect. To change the language in browser will depend on the browser itself, but for Chrome and Edge, it’s done by clicking on the options menu:
Group C (Free For All): Services in this group have their own ways to change languages. For example, Teams will allow you to change the language while using Teams client. Stream will allow to change the languages in Stream itself and same for other services in this category.
In the next post, we will see how multilingual sites work in SharePoint and how they’re affected by the settings discussed in this post (Group B). Till the next time!
If you work with PnP Provisioning Engine that much, you might reach a point where you want to have your configuration sitting in an XML file, and read its settings and pass it to your provisioning engine. However, you might run into some issues when dealing with special characters if you try for example to name your sites something such as “R&D”.
We’ll have a look at a case. Let’s say you have an XML configuration file named config.xml, that contains some settings regarding site urls and site names that you want to use in your provisioning engine. One of the values in XML might look like this:
If you try to read its value like this:
You’ll end up with such an error:
Cannot convert value “System.Object” to type “System.Xml.XmlDocument”. Error: “‘<‘ is an unexpected token. The expected token is ‘;’
This means, that we’ll need to encode our value in XML, so we’ll end up with something like this:
Or we can keep the value is XML as R&D, and replace the & with & in our PowerShell script like the following:
Now when we get the right value from $Config in PowerShell, it works just fine, and we’ll have a string as “R&D”. However, when we pass this value to our provisioning template:
It will complain again with such an error:
‘ ‘ is an unexpected token. The expected token is ‘;’.
The reason is, when it’s passed from PowerShell as “R&D” to the provisioning engine, it has to be encoded one more time. To do so, we’ll need to execute this before passing our values to the provisioning engine:
You might come across a requirement to share an excel file on any page, or even on a SharePoint page (either on prem or online). Considering the options that would be available, and since we want to share an excel file, so why not using Excel online?
To do this, we can upload our document to either OneDrive or SharePoint online, since both of them will use Excel online to work with the Excel document. Once we do that, we can open our Excel document, then click File > Share > Embed:
In the page that appears you have many options to control the rendering of your excel file, the end result will be an iframe HTML element that you can copy and paste in any page you need (Even any site accessed anonymously).
ONE CATCH: The option to “Let people sort and filter” will provide you with the headers to sort and filter column, but it will also provide you with a refresh button at the bottom of the sheet:
HOWEVER, if you update the data in your workbook and you click on this button it won’t refresh the data. From what I’ve seen, it takes around 5 minutes to refresh the data in this embedded sheet from the actual data source. This button will serve well if you stay on that page for 5 minutes then click it. Otherwise, a page refresh will just give you the updated data after the minutes. So if you change the data in your excel file and don’t see them updated right away, don’t panic, wait a bit then refresh the page.
Now to embed this in a SharePoint on prem page, you can just use the script editor web part, for SharePoint online, you can edit the page, and from the list of web parts choose Embed:
Which is similar to the SharePoint on prem way of embedding the code. There you can just paste the iframe code you got from Excel.
There are 2 main PowerShell modules for managing Azure AD (and access O365 licenses): AzureAD module and MSOnline module. (There are 2 more modules for AzureAD for preview, but I haven’t worked with them yet).
Let’s say that you want to get all users in a specific office, who have O365 licenses? We can do something like this:
That might work, but.. it might also give you more results than what’s expected. What if some users use PowerBI (Free), Flow (Free) or Teams Exploratory license (free Teams license for those who aren’t yet assigned a license).
If you run the previous command, it will get those users too since their AssignedLicenses isn’t actually null.
To do that, let’s first query all O365 available licenses in our tenant and see what we get. We can run something like the following:
You’ll get a result of ObjectId and SkuPartNumber, the SkuPartNumber is the description for the licenses, and the ObjectId will be formatted like this: [TenantID]_[LicenseId]
For example, for the E5 license, the SkuPartNumber is SPE_E5, and the ObjectId is:
[GUID FOR TENANT]_06ebc4ee-1bb5-47dd-8120-11324bc54e06
Now that we know the license ID exactly, we can use it to get users in the required office, with the required license ID:
Yammer is an awesome tool to have company-wide communications. With open communities that people can join and interact with each other without having to work with each other on a daily basis. It’s a perfect network where people can reach out together, interact with the upper management, and share thoughts across the whole organization.
The bad thing about Yammer however, is by default it would allow everyone in the company to create Groups (newly named as Communities), and there’s no way by default for a Yammer admin to restrict the creation of these communities to be just for a subset of people. So how can we do it?
Knowing that the creation of Microsoft 365 groups creation can be restricted, so why not making Yammer follow the same policies as Microsoft 365?
Let’s have one step back and see the restriction on creating new Microsoft 365 groups. To restrict the creation of new groups in M365, you’d have follow steps mentioned in this article:
This is exactly the same code mentioned in the article, just make sure to have the correct group name you created in M365 that contains people who are allowed to create groups (Make sure to add the required people as members, adding them as owners only won’t grant them permissions to create M365 groups)
Now that we managed to have a security group whose members are allowed to create M365 groups. We’ll need to let Yammer follow same rules as M365. For that, we’ll have to put Yammer in Native Mode for M365. So what’s the native mode for M365 in Yammer?
The native mode is a way for Yammer to follow same rules of M365, so the documents will be stored in SharePoint online. The creation of a new Yammer community (group) will result in the creation of a new M365 group, you can search for Yammer content in the M365 security and compliance center.
So how do we put Yammer in native mode for M365? First we’ll need to enforce O365 identity in Yammer, which basically tells Yammer to let users login with their O365 accounts (which makes sense since you’d want them to login to Yammer that way). You do this step by going to Yammer admin page, and on the left menu under “Content and Security” click on “Security Settings”. Make sure to have “Enforce Office 365 identity”:
Now after enforcing O365 identity, we’ll finally tell Yammer to follow same rules as M365, but putting it in native mode for M365, to do so go to “M365 Native Mode” from the left menu in the Yammer admin page. You’d have to generate the Alignment Report. This report will show any warnings in case some users won’t be able to exist in the network if it’s migrated to the new mode, or if some old groups are available that aren’t already connected to O365 groups.
Old groups will have O365 groups provisioned and connected to them. If you have any naming convention policies for M365 groups, they won’t be applied in this case for these existing Yammer groups.
After running the alignment report, you can download it, I opened it in vscode like this:
and the page will be updated to show you the results of the analysis:
At the very end of the page, you confirm that you want to proceed with the conversion, the reason for that is that this change won’t be rolled back, once you go Native Mode, that’s it.
Now users who aren’t allowed to add a community (group), won’t see this option in Yammer: