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.
This is a quick post to outline the steps to integrate Microsoft Graph API using Microsoft Flow or Azure Logic Apps. The intent is to be able to integrate Graph API without user input. I intend to follow this post with other posts outlining use-cases for this. Before you start, you need to make sure you have the following: Access to an Office 365 tenant with administrative access to Azure AD Access to create flows in Microsoft Flow Step 1 - Create an Application in Azure AD You will need to register an application within Azure AD.
If you’re keeping count, this is the 3rd article on this topic. Previosuly, I have written about two other methods employed to deploying an AudioCodes SBC in Azure: Using Azure Site Recovery Uploading a pre-packaged ‘Azure VHD’ to Azure Whilst both worked, it still involved uploading an up-to-date copy of the SBC to Azure and a bit of patience. I’ve had quite a few users reach out to me and ask where they can download the ‘Azure VHD’, but it was never released for download by AudioCodes.
Introduction Following on from Part 1, you should now have an AudioCodes SBC up and running in Azure. This article will cover any Azure specific setup to allow Teams Direct Routing to function. For Direct Routing configuration you can follow my earlier blog post for instructions. Note: In Azure, we are using a single NIC, so the “LAN” and “WAN” NIC mentioned is the same interface, so bear this in mind when configuring Media Realms, SIP interfaces etc.
This article is now out-of-date, please refer to this article for Deploying an AudioCodes SBC in Azure using the Azure Marketplace. Introduction I’ve written in the past about deploying AudioCodes SBC into Azure by using Azure Site Recovery. Whilst this works, it’s not supported! I recently asked AudioCodes if there were any plans to officially release an “Azure Edition” of the SBC and to my surprise, they said “Yes”. It’s about to hit GA, but I’ve been given a pre-release build to try.
Introduction Following on from my blog post about monitoring SfB and CCE in Azure OMS and Power BI, then recently deploying a Skype Room System (SRS) for the first time, I came across monitoring SRS devices via Azure OMS. This seems a good idea, much like it did for CCEs, as these are unmanaged devices spread across the network where you might not always have someone on hand to keep an eye on them.
Edit 09/07/18 - There is now an easier, supported method to achieve this here. Introduction For a while, I’ve been running SBCs and other virtual machines for my lab on physical servers, which consume a fair bit of power and most of the time sit there unused. I’ve managed to move other machines to Azure but wanted to also move an AudioCodes SBC too. One thought when Direct Route arrives, I could have a whole PSTN calling lab in Azure to play with.
Introduction As of CCE 2.1.0 there was mention of support for Azure Operations Management Suite (OMS). Being that the CCE is generally left alone once installed, this piqued my interest. Whilst on the whole CCE has been OK to leave to it’s devices, it would be nice to know exactly what it’s doing sometimes. Using OMS we are able to get an insight in to running CCE (and SfB server) installed in multiple configurations and locations in a single place - for someone who manages exactly that, awesome!