So you want to manipulate the new Categories in the Events WebPart in SharePoint, here are few tips that might help you out!
First of all, you want to do your changes in the list itself, not on the site column. The site column itself won’t be helpful as you won’t find it unless you go to the content type first, and you’ll notice it’s in the Hidden category. So if you want to add your categories, you’ll need to do it on the list itself.
What do you do it if you provision the list as part of a provisioning process aka PnP Provisioning 😉 ? Well, if you run Get-PnPSiteTemplate and try to get the list, you won’t find the categories as part of the exported template. So if we want to change the categories, we’d do it with PnP PowerShell. I’m using PnP.PowerShell module (using PowerShell Core). In order to change the categories, you’d want to run these commands:
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: