Earlier this year we saw the Microsoft 365 Admin App introduced into Microsoft Teams. Now, we have the Support App. The app is designed to 'Troubleshoot problems they [as in any user] encounter while using or managing Teams, such as failed login or trouble with changing Teams backgrounds, escalate a problem to Microsoft support [admin] and track the status of service requests [also admin]'. In other words, it is bringing the support bot, ticket escalation and monitoring into what Microsoft market as its front end. In terms of time saving - considering that many admins work daily within Microsoft Teams it may shave minutes off from having to login and navigate to raise a ticket when in the flow of the work. Exposing troubleshooting to users may also work in terms of self-service. Additionally, if Power Apps have been built for Internal support, then these may also sit nicely alongside the Support App in regards of having things to hand. But it's a lot of 'may' as opposed to will. Naturally, some admins will wonder - why another app? Why split the ticket function further between the Microsoft 365 admin centre, the Teams app, the Mobile Admin App, and now the Support app. It's bringing apps to hand but there's also a conversation to be had about duping functionalities, increasing unnecessary complexity and surfacing everything everywhere. Why wasn't this surfaced in the help section of the client? Is Support too broad and vague a name and actually cause confusion? These sort of conversations I think we'll see more of in the not-too-distant future
There are many ways that we can join meetings in Teams. We can join a scheduled Teams meeting straight out of the Calendar App. We can join it via the calendar booking in Outlook which many of us tend to do. We can join a channel meeting one-click in the channel itself or we can even generate a join link for an ad-hoc meeting or get the link right off of the meeting card again in the calendar app. The latest way? We can now join scheduled and channel meetings using a Meeting ID and passcode. Now, there isn't a great deal to go through here, and whilst ID and passcode sounds like it should be for security, it is only another alternative way to join a meeting. Meeting security is enforced by things like the lobby, and roles, and settings not this latest functionality, and there may be some which see it as a concern given it cannot - at the time of writing - be disabled. However, it may serve in situations such as providing 100 people with access to the meeting without adding 100 to the meeting invite, or spinning it up on SharePoint. Imagine having a kind of 'personal' meeting room for yourself with a defined meeting ID and Passcode.
If we have an issue with Teams and we raise a ticket to Microsoft, then occasionally we will be asked to provide logs for engineers to analyse. With Teams, there are several different ones. These include Debug logs, Media logs and Desktop Logs. This week, I noticed that it is now possible to enable Media Logging with PowerShell. Up until this point the user would have to enable it within the Teams client, and this would be problematic for IT in terms of being dependent on users and if it would be enabled at the required time. The Media Logs, by definition, contain diagnostic data about audio, video, and screen sharing. They are linked to call-related issues. Having a problem with resolution? Or an encoder? Or rendering? Or a situation where share control is given in a meeting but cannot be taken back? The Media logs may provide insights to fix the issue. Yet Media Logging is only enabled by default on machines using the Teams client with specific CPU's: any Apple M1, any Intel Xeon, any Intel i9, except for the U, G7, M, and MQ series and any 6th generation and later Intel i7, except for the U, G7, M, and MQ series. So, in many cases it has to be enabled. Being able to do it with PowerShell saves time - for both the user and the admin
This week, it is a new functionality called Live Share which we heard about at Microsoft Build back in May. It's being able to use collaborative apps on the Teams meeting stage powered by fluid. I haven't seen anything on a roadmap (granted I haven't been looking). I haven't been privy to it in some insider session. I stumbled across it yesterday after playing about with transcripts and discovered that you can now do this in preview with the YouTube App. So lets surface video right into the heart of the meeting. Great for lots of scenarios without having to share the whole screen, or - as our favourite expression goes - keeping in the flow of the work. So naturally once I've done this I'll be off to ask my friend Mark Mroz and the Stream Team all about the timeline...
So imagine this scenario. Say we have two teams in our organisation. One team is the Sales Team. The other is the Marketing Team. I need to ensure specific users are part of the Sales Team dependent upon their role. I need to then make sure that specific users are part of the Marketing Team dependent upon their role. For this? We can use Dynamic Groups. But now we need to ensure that everyone in the Sales and Marketing Team need to be in a third team - the Commercial Team, and this also needs to be done automatically without manual adds. For this we are going to use a new functionality called Nested Dynamic Groups. Users of Dynamic Group A comprise of Users dynamically added and removed within Dynamic Group B and Dynamic Group C. Sounds pretty nuts. But it's straightforward as I'll show you. Nested Dynamics Groups support Security Groups and Microsoft 365 groups - so we can use them for Teams. As a public preview feature there is some caveats such as they aren't supported in the rule builder. The full list is in the footnotes I'm sure they'll knock them out soon.