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!
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?
Introduction You may from time to time have run in to an issue where an Teams/SfB user has not been provisioned correctly. The most common scenario for this is a delay in Office 365 provisioning the user - you have assigned the required SfB/Teams licenses and it has yet to become available to the end user (it is not uncommon for licenses to take over 24 hours to be provisioned).
Introduction When using Office applications, such as Outlook, you will see the presence and contact cards that appear when hovering over a user. From here you can initiate actions such as an IM or call etc. This is all based on the “DefaultIMApp” value in the current user’s registry. If the user is using Skype for Business, this does not need any action from the user. However, in Teams, this needs to be enabled by the user under settings in Teams:
Note: This script is provided ‘as-is’ without any warranty or support. Use of this script is at your own risk and I accept no responisiblity for any damage caused. Background Graph is Microsoft’s API for Microsoft 365. By creating an Azure AD application it allows you to interface directly with Azure AD, Office 365, EMS etc using Graph API. You may want to write a script in PowerShell, Python, C# etc.
With the recent high-profile outages within Office 365 and the ever reliance on Office 365, it’s always good to stay up-to-date with any potential issues. There are lots of ways to check the status of Office 365 - the Office 365 portal, Twitter accounts etc. However, what I was after was an automated way of checking for issues and letting me and the team at Symity know about them ASAP (so we can look to mitigate impact) - rather than happening to come across it, or worse users noticing and informing us.
Whilst this article is still very much a valid approach, Microsoft have started work on a PowerShell SDK for Graph API - find out more here: https://www.lee-ford.co.uk/graph-api-powershell-sdk/ What is Graph? Graph is Microsoft’s API for Microsoft 365. By creating an Azure AD application it allows you to interface directly with Azure AD, Office 365, EMS etc using Graph API. The API not only allows you to access data from Microsoft 365 but also modify and delete it.
Background With the preview release of Teams Direct Routing users are now able to make and receive PSTN calls using certified SBCs instead of Calling Plans. Part of setting this up involves setting up PSTN Usages, Voice Routes, Online Voice Routing Policies, PSTN Gateways etc. within Skype Online PowerShell. Much like Skype for Business, if your users have multiple calling requirements the amount of Voice Routes, PSTN Usages etc. can grow quickly and sometimes make it quite hard to fathom how a call will route.