Adaptive Cards explained Adaptive Cards are actionable message cards that are adaptive depending on user interaction. Adaptive Cards can be used in different Microsoft 365 applications such as Outlook, Teams, Bots etc. but maintaining a native look and feel to the application they appear in. Whilst this post is centred around Microsoft Teams, one great feature about Adaptive Cards is that any card created can be re-used, no matter what application, within another application that supports adaptive cards.
Disclaimer: Although I have dabbled with Linux over the last 20 or so years, I mainly use it as a server OS rather than a desktop OS. As such, what you read below is the way I understand it, I am not a Linux expert! This had been announced for a little while, but just before the end of 2019, Microsoft released a version of Teams for Linux. At this time (January 2020), it is in public preview so there will be bugs and still room for changes or improvements to be made.
Updated: January 30, 2020 Introduction For a while, when using Graph API and PowerShell I have been using my own implementations of communicating with Graph API as outlined in the following posts: Getting started with Microsoft Graph and PowerShell Authenticating with Graph API Using a Device Code However, at Ignite 2019, it was announced there is a Graph API PowerShell SDK in the works. Even better, its available on GitHub today!
The running joke when having a poor user experience with applications is to “blame the network”. As it turns out, there is some truth to that. You see, if your network is not configured correctly or capable it may well be the cause of common complaints - especially when using real-time communication applications such as Teams. At Symity we are helping more and more customers shift from on-premises Skype for Business to Teams, with that comes network considerations that were not previously needed.
Disclaimer: This tool is provided ‘as-is’ without any warranty or support. Use of this tool is at your own risk and I accept no responsibility for any damage caused. Backup-Team Backup-Team is a tool used to backup and recreate Teams from Microsoft Teams. A backup from the tool can include items such as settings, channels, tabs, owners, members, conversations and files. Teams can be recreated, including on a different tenant for a pseudo migration scenario.
Introduction Recently, I’ve been wanting to use PowerShell Core more often with Graph API. But what has held me back was having to use WinForms or WPF to display the Microsoft login page to authenticate the user. Searching around, it appears you can authenticate Azure AD users with a device code too - https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-device-code By doing this, your script/tool/app/device can generate a device code to be entered on another device (that has a web-browser).
Introduction I’ve been asked a few times if there is an easy way to report on all web pages in use within Teams. The two main reasons are: Intrigue in to what sort of web pages users are attaching to their Teams A way of policing users to ensure the feature is not being abused (perhaps a website is blocked using a web-browser but works via Teams) Pre-requisites As with a lot of my posts, out comes PowerShell and Graph API.
Disclaimer: This script is provided ‘as-is’ without any warranty or support. Use of this script is at your own risk and I accept no responsibility for any damage caused. Introduction Backup-TeamsConfig is a PowerShell script allowing you to backup various parts of Microsoft Teams configuration and package it up in to a single file for safe keeping - this includes policies, configurations and voice applications (inc. audio files). Why? - Doesn’t Microsoft already keep copies of this?
I’ve previously blogged about the Office 365 Service Communications API before and how it can be used to obtain the service status/health of services in your Office 365 tenant. The API also allows you to get historical status along with messages (from message centre, incidents etc.). In my previous post I showed how this could be done in Flow using a standard HTTP call within each Flow. It works, but it also means you need to set up authentication and each API call manually (even if in the same Flow).
When first using Graph API a feature I missed was that data was paged. For example, if I want to retrieve all the groups in a tenant, I would use the following endpoint: HTTP GET: https://graph.microsoft.com/v1.0/groups This worked fine for me in the demo tenants I was using – I would get all the groups back. However, I found out there is a limit to results returned (for groups it is 100)!