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)!
One project I have been working on recently at Symity is a global roll out of Teams Direct Routing. This has resulted in SBCs being installed in different configurations based on local connectivity and requirements. One such requirement is where sites have multiple internet connections for resilience - can the SBC make use of this? It makes perfect sense especially when using cloud-based service – if one ISP has an issue, you want to be able maintain service with the other.
Microsoft have recently announced that they will be retiring Skype for Business Online on 31st July 2021. After this time, you will no longer be able to access Skype for Business Online. If you’ve been paying attention this isn’t a massive surprise. Teams is the new-ish kid on the block, getting all the attention and had been earmarked as Microsoft’s communication and collaboration tool moving forwards. Once ‘feature-parity’ was announced, Skype for Business Online’s days were numbered.
Last Updated: 2nd October 2019 Introduction This article will give an explanation of the Teams Call Queues (CQ) and Auto Attendants (AA) - what they are and how to set them up. You could previously create and administer the “SfB” CQ and AA in the (legacy) Skype for Business Admin Centre, but these have now been migrated as “Teams” CQ and AA in to the Teams Admin Centre. There are some key differences between the two versions that I will highlight:
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).
This article will assume you already have Teams Direct Routing in place. If you are not there yet, consider looking at my article on this subject: https://www.lee-ford.co.uk/teams-direct-routing-with-an-audiocodes-sbc/ Introduction to Media Bypass A welcome addition to Teams Direct Routing is Media Bypass. Before Media Bypass was released, all media when using Direct Routing would need to route up to one of six regional Teams Media Processors and back even if the Teams client and SBC were in the same location.
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 For a while I’ve been managing Teams using the Teams Admin Centre and PowerShell module but there have been some tasks I’d like to undertake that were not possible unless I joined the Team I wanted to make the change for e.
Last Updated: 15/5/2019 Introduction Microsoft have announced that from July 1st 2019 January 15th 2020, the shared Azure AD application/client that all 3PIP (3rd party) phones currently use will be revoked. Moving forward, each vendor will need to issue thier own specific Azure AD application. This means that if you have 3PIP phones that connect to Skype or Exchange Online you will be impacted. Will I be impacted? Here are the following 3PIP deployment scenarios (taken from a very helpful AudioCodes article) and wether any action is required: