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:

Let’s Script It

For a small subset of Teams users, asking them to go into settings isn’t a massive issue. But what if you have 100s or 1000s of users who have migrated from Skype for Business to Teams? Expecting those users to make the change might be a challenge!

Thankfully the setting is just a registry key that can be modified. Using the below PowerShell script it will modify the current user’s Default IM App. This could perhaps be added to a login script or task.

]]>https://www.lee-ford.co.uk/change-teams-to-the-default-im-app-by-using-a-script/feed/01735MSGraphAPIGUI – A PS GUI for Microsoft Graph APIhttps://www.lee-ford.co.uk/msgraphapigui-a-ps-gui-for-microsoft-graph-api/
https://www.lee-ford.co.uk/msgraphapigui-a-ps-gui-for-microsoft-graph-api/#respondFri, 01 Mar 2019 07:30:12 +0000https://www.lee-ford.co.uk/?p=1707Note: 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. to use with Graph API – or maybe you want to use Flow.

Sometimes it’s easier to use a GUI for your needs (especially for testing scripts) – for delegated (user) permissions in Graph API you can use the excellent Graph Explorer. However, I wanted to be able to use a GUI for application permissions (e.g. run without user sign-in). I tried using tools such as Postman but it was too much hassle dealing with access tokens, so the selfish need for a script began!

Graph Explorer

Introducing MSGraphAPIGUI

Yeah… I’m not a UX designer!

I’ve created a PowerShell GUI script for working with Graph API. High-level features include:

Support of Azure AD applications v1 and v2

Support of Azure AD delegated (user) permissions

The script prompts to sign in as a user to authenticate

Request permissions

Support for Azure AD application permissions

Run Graph API as an application (no user login required)

Support for any Redirect URI

Run a Graph API query with

Method

URL

Body

Request Headers

Export response content to a file

Prerequisites

This script relies on WPF for it GUI elements so I’m afraid PowerShell Core is not currently supported.

Before you can use the script with Graph API, you need to ensure you have an Azure AD application to use with Graph API. If you already have one setup as you need, the next part can be ignored.

The application will now get created. Make a note of the Application (client) ID and Directory (tenant) ID as these will be needed for the script. Next, you need to specify a Redirect URI to use for the acript. Select Add a Redirect URI from the application page.

The script is set to use https://login.microsoftonline.com/common/oauth2/nativeclient as the Redirect URI, but any can be used. Whatever you use, it will need to be put in the script.

If you intend to use application permissions, create an application secret . From within the application page, select Certificates and secrets and select New client secret.

Give the secret a Description and set an Expiry on the secret.

IMPORTANT: Copy the secret and put it somewhere secure, as once you click away, it will be hashed out and you’ll need new one.

This application will now need permissions assigned to it.

Under the application, select API permissions and then select Add a permission.

You may have noticed these permissions have not been consented by an Admin. Without consent by an Admin these permissions will not be granted and the Graph requests will fail. To grant consent there are two methods:

Grant consent in the Azure AD application API permissions area – if you are using application permissions this is the only method. If permissions are granted for users using this method, all users are granted permissions!

Have users ask for consent – if you are going to use delegated (user) permissions, if not already granted consent the signed-in user is prompted to ask for consent from an admin.

With permissions assigned you can now use this Azure AD application with the Graph API.

Using MSGraphAPIGUI

Ensure you have the MSGraphAPIGUI.ps1 and MainWindow.xaml in the same folder.

Run the script by typing the following in PowerShell:

.\MSGraphAPIGUI.ps1

The GUI should appear. The first step is to enter the application/client id and directory/tenant id of the Azure AD application.

After that, select if you are using application or delegated (user) permissions. If you are using application permissions, specify the secret of the Azure AD application. If using delegated permissions you do not need to enter any additional permissions unless you wish to ask for them to be granted consent.

With the permissions specified, click Authenticate to get an OAuth token. This is valid for 1 hour. After that time the script should automatically renew the token.

You can now query Graph API using the OAuth token. Enter the method, query URL and any request headers/body required.

Below the query is the response. This will include the response code, content (usually in JSON) and the headers.

If there is content, you can export it and save it as a file.

Wrap Up

I hope you found this post and more importantly, the tool useful. This is my first GUI script and it probably shows! Any and all feedback welcome – raise an issue on the GitHub or if you know how to improve it, submit a pull request.

]]>https://www.lee-ford.co.uk/msgraphapigui-a-ps-gui-for-microsoft-graph-api/feed/01707Get Latest Office 365 Service Status with Flow or PowerShellhttps://www.lee-ford.co.uk/get-latest-office-365-service-status-with-flow-or-powershell/
https://www.lee-ford.co.uk/get-latest-office-365-service-status-with-flow-or-powershell/#commentsMon, 25 Feb 2019 08:00:24 +0000https://www.lee-ford.co.uk/?p=1631With 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.

Doing a quick Google Bing, I came across a REST API for reporting the latest Office 365 status of a tenant – it is called the “Office 365 Service Communications API” – a bit of a mouthful.

Note: This API is in preview, so may be subject to change.

A cursery glance at the API looks like it will fit the bill. Now, at this stage I could use PowerShell or some other scripting language, but why not use Flow?

Create an Azure AD Application

As you will need to query the status of your tenant directly, you need to be able to authenticate with it. To do this, you will need to create an Azure AD application.

Select New registration and give your application a Name and Supported account type. In my case, I only want to allow accounts from my Azure AD to authenticate using the application. Leave Redirect URI blank (for now) and select Register.

The application will now get created. Make a note of the Application (client) ID and Directory (tenant) ID as these will be needed later. Next, you need to specify a Redirect URI to use for the application. Select Add a Redirect URI from the application page.

I’ve tended to select https://login.microsoftonline.com/common/oauth2/nativeclient as the Redirect URI, but any can be used I believe. Whatever you use, make a note of it for later.

The next step is to create an application secret. The secret is used when authenticating with Azure AD – it is similar to a password. From within the application page, select Certificates and secrets and select New client secret.

Give the secret a Description and set an Expiry on the secret.

IMPORTANT: Copy the secret and put it somewhere secure, as once you click away, it will be hashed out and you’ll need new one.

This application will now need some permissions assigned to it to read the Office 365 service status. Under the application, select API permissions and then select Add a permission.

To complete, permissions you need to Grant Consent for the permissions by selecting Grant admin consent.

With that done, you are ready to query using the Azure AD application.

Whilst it’s great you can go back and look at historical status, this post is about the latest status, so I can going to use the Current Status query.

Querying using PowerShell

The following script will return the current status of each service on Office 365 for a given tenant. You will just need to populate the Azure AD application/client id, client secret and tenant id.

This script will get an OAuth token from Azure AD and with that token query the Office 365 API for the latest servie status. You can of course tweak the script to do something with the output e.g. send an email if a service is not under “Normal service”.

Querying using Flow

PowerShell is just one of a multitude of ways of querying this API, another is Flow.

I’ve alreadycovered flow before, in more detail, so will keep it brief here.

Create a new flow and in this case, the trigger will be a scheduled re-occurrence.

The next step is to initalise 3 variables, these are the Azure AD application client id, client secret and tenant id.

After that, you need to create an HTTP action to query the Office 365 API. Populate the same as below, making sure all 3 variables are used.

If you were to run the flow at this point it would return a big output of JSON. It’s best to use the Parse JSON action to make it easier to read. Set the Content as the Body of the previous HTTP action and the Schema below:

Once the data has been parsed, you can loop through each service and check for service status. The next action is to add an Apply to each action for the value variable.

Within the loop, add a Condition that Status is not equal to ServiceOperational.

Under the If yes condition, you can add an action because the service is not operational. To demonstrate, I’ve sent an email, but you may want to do something else.

This should then be triggered when there is a service degraded within Office 365. If you are going to use this to be alerted you may want to add some extra logic to group all affected services into one email, or perhaps only have the flow trigger on new action to avoid getting spammed with the same alerts (this would rely on persistence between flow runs, so perhaps somewhere external to store the last status and compare to current).

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.

How to do I use Graph API?

By using an Azure AD application, you can send queries to the API using HTTP requests to https://graph.microsoft.com. An example could be – a ‘POST’ to https://graph.microsoft.com/v1.0/me – this would return the user details of the user making the request.

Select New registration and give your application a Name and Supported account type. In my case, I only want to allow accounts from my Azure AD to authenticate using the application. Leave Redirect URI blank (for now) and select Register.

The application will now get created. Make a note of the Application (client) ID and Directory (tenant) ID as these will be needed later. Next, you need to specify a Redirect URI to use for the application. Select Add a Redirect URI from the application page.

I’ve tended to select https://login.microsoftonline.com/common/oauth2/nativeclient as the Redirect URI, but any can be used I believe. Whatever you use, make a note of it for later.

The next step is to create an application secret. The secret is used when authenticating – it is similar to a password. From within the application page, select Certificates and secrets and select New client secret.

Give the secret a Description and set an Expiry on the secret.

IMPORTANT: Copy the secret and put it somewhere secure, as once you click away, it will be hashed out and you’ll need new one.

This application will now need permissions assigned to it.

There are two types of permissions you can use (and I will demonstrate both later in the post):

1. Delegated (User) Permissions

These permissions are granted when making requests to the API based on a user being authenticated. This works well for user-facing applications, but not for scripts or unattended applications.

Note: You do not assign these permissions to a specific user, any user wishing to use these permissions will need to be granted consent by an administrator.

2. Application Permissions

Here you can assign the application itself permissions. The benefit of this is it allows the application to access the API without a user being logged in – useful for a script, for example. Instead of a username and password to authenticate, a secret or certificate is used.

Under the application, select API permissions and then select Add a permission.

For this post, I’ve select Microsoft Graph and assigned the following permissions to both Delegated (User) and Application.

Group.Read.All

Group.ReadWrite.All

User.Read (only for delegated as there is no signed-in user for applications)

User.Read.All

You may have noticed these permissions have not been consented by an Admin. Without consent by an Admin these permissions will not be granted and the Graph requests will fail. To grant consent there are two methods:

Grant consent in the Azure AD application API permissions area – if you are using application permissions this is the only method. If permissions are granted for users using this method, all users are granted permissions!

Have users ask for consent – if you are going to use delegated (user) permissions, if not already granted consent the signed-in user is prompted to ask for consent from an admin.

Both scenarios will work, but if developing an application where users sign-in, I would strongly recommend the latter approach.

In this scenario, as I will be demonstrating both permission types, I’ve gone with the first method and granted consent from within Azure AD.

With permissions assigned you can now use this application with the Graph API.

Authenticating with Azure AD Explained

I want to explain the basic authentication flow that will take place in the code. Authentication is done using OAuth 2.0 requests, so if you are familiar, this is nothing new. The flow is different depending on if you are using application or delegated permissions.

Delegated (User) Permissions Authentication Flow

User is directed to Azure AD (https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/) to sign-in with their credentials.

Once signed in, if permission has been granted to the user for the Azure AD application, the application will be issued an authentication code.

With the authentication code, a second request is made to Azure AD (https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/token) to request an OAuth token.

If the request is successful, an OAuth token is issued to the application.

With the OAuth token, a request can now be made to Graph API.

Graph API will verify the token and issue a response.

Application Permissions Authentication Flow

With the application ID and secret, a request is made to Azure AD (https://login.microsoftonline.com/<tenantid>/oauth2/v2.0/token) to request an OAuth token.

If the request is successful, an OAuth token is issued to the application.

With the OAuth token, a request can now be made to Graph API.

Graph API will verify the token and issue a response.

Without further ado, on to the code!

Authenticate with Azure AD using PowerShell

Here are the two different methods dependant on what type of permissions you want to use. I won’t delve into the nitty-gritty of each script, but the comments should explain it enough.

Delegated (User) Permissions Authentication with PowerShell

Application Permissions Authentication with PowerShell

Either script will return the access token (as $token) you will need to include with your Graph queries. Don’t forget to change the client ID, tenant ID and secret to your own.

Note: This is the bare minimum required, if you are going to use in production, you may want to add some extra validation steps and error handling.

Make a Graph API query using PowerShell

With the token obtained already, all that is left to do is make a query. In this example, I will list all users by querying ‘GET’ https://graph.microsoft.com/v1.0/users

The reponse to the query will be stored in $query.

Wrap Up

I hope this has been of some help to you. This should allow you to authenticate and query Graph API using PowerShell as a user or an application.

All and any feedback welcome.

]]>https://www.lee-ford.co.uk/getting-started-with-microsoft-graph-with-powershell/feed/11588New Team request for Teams using Flow (and Graph API)https://www.lee-ford.co.uk/new-team-request-for-teams-using-flow-and-graph-api/
https://www.lee-ford.co.uk/new-team-request-for-teams-using-flow-and-graph-api/#commentsThu, 07 Feb 2019 08:00:17 +0000https://www.lee-ford.co.uk/?p=1511Whilst Flow does have some integration with Microsoft Teams, one missing feature is the ability to create a Team in Microsoft Teams (you can create Channels, messages etc.).

With recent additions to Graph API, you can create a Team using a template and a Graph API call. This API call can be used within a flow. In this scenario, I’m going to create a flow to create a Team. This will work like so:

A user (who cannot create a Team on their own) sends a request to have a new Team created for them. They will request a Team name and description.

The team that is responsible for these requests will approve or deny the request.

If the request is approved, a Team is then created using the user submitted details. The requester is also added as a Team owner.

With the Team created, the requester can manage the Team and add other members to it.

Prerequisites

Before starting, you will need to ensure you have the following:

Access to an Office 365 tenant with administrative access to Azure AD

Access to create flows in Microsoft Flow

Access to create a Form in Office 365

In addition, you need to have created an Azure AD application with the Group.ReadWrite.All and User.Read Application permissions (see Step 1 of this post for instructions on how to create an Azure AD application).

With the Azure AD application created, make sure you have the Application ID, Directory ID and Secret to hand as these will be needed later.

Step 1 – Create a Form

Whilst there are various methods to get the data into Flow, for ease of use I’ve created a Form to capture the request.

Go to https://forms.office.com and create a Form. It should ask two text-based questions – Team Name and Team Description.

Step 2 – Create a Flow

Under the search box, search for Forms and select Microsoft Forms. Select When a new response is submitted. You may get asked to sign in. Once signed in, select the Form Id that you just created.

The next step in the flow is to create some variables. These variables are the application (client) id, directory (tenant) id and secret you should have from the creating the Azure AD application. Create 3 variables like below.

Now select New step and search Apply to each. Select List of response notifications to apply to each.

Select Add an action and search for Forms again and select Get response details.

Select the Form Id as the Form you created earlier. The Response Id is List of responce notifications Response id.

Add another action and search for Approvals and select Start an approval. Fill in the approval similar to below.

Next, you need to add a condition based on whether the request is approved or rejected. Select Add an action and search for Conditon. Fill in condition as below.

Next, we need to set the behaviour based on the response. If yes (approved), it will create a Team. Under yes, search for HTTP action and select it. This is a Graph API call to get the requester’s user id (as you need this to create the Team). Complete the HTTP as follows:

Method to GET

URI to https://graph.microsoft.com/beta/users/@{body(‘Get_response_details’)[‘responder’]}?$select=id

Authentication to Active Directory OAuth

Authority to https://login.microsoft.com

Tenant to the directory_id variable you created

Audience to https://graph.microsoft.com

Client ID to the application_id variable you created

Credential Type to Secret

Secret to the secret variable you created

The HTTP request will create a JSON output. Within this is the id of the user. To extract it, we need to parse the JSON into variables. Add another action called Parse JSON and populate like below.

The next action I added after this was a Condition that if the group was created (status code 202).

Status code (from ‘HTTP 2’) is equal to 202

If yes (the team was created), I’ve added an action (in my case Send an email) to notify the requester and approver.

You could also mirror above if the group was not created or rejected, but I’m not going to repeat those steps.

The flow is now complete, an overview of my flow looks like this.

Step 3 – Test the Flow

With the flow created, it can now be tested. Go back to the Form and submit a new Team.

The approval team will receive an email with the request.

The request is approved.

The requester is notifed of the Team creation.

The Team is there to be used by the requester.

And there you have it, automated Team creation based on requests.

]]>https://www.lee-ford.co.uk/new-team-request-for-teams-using-flow-and-graph-api/feed/71511Using Flow with Graph APIhttps://www.lee-ford.co.uk/using-flow-with-graph-api/
https://www.lee-ford.co.uk/using-flow-with-graph-api/#commentsMon, 04 Feb 2019 11:00:08 +0000https://www.lee-ford.co.uk/?p=1466This 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. This can effectively provide access to Azure AD by methods other than a user account.

With the application now created – make a note of the Application and Directory IDs (you will need these later in Flow) Next, you need to grant the application some permissions. To do this select the application and then select API Permissions.

Select Graph API.

Select Application permissions.

Grant the required permissions you need. For reference, use the Graph API documentation and under each API call, there are the permissions required for that call. In this case, I’m using User.Read.All and selecting Add permissions.

With the permissions created, you need to grant consent to the application. Effectively, you are allowing the application to access Graph API without a consent screen – which is key when using in Flow as there will be no user interaction.

The next step is to create a secret for the application to use. By using a secret, you can effectively use the application without any user credentials being used – perfect for something scripted like Flow. The fact it’s called a secret should be enough warning to make sure you keep this safe!

Staying within the application, select Certificates and secrets. Select New client secret.

Give the secret a description and select an expiry time of the secret. As this is a demonstration, I will choose 1 year.

Make a note of the secret somewhere safe along with the Application and Directory IDs.

Step 2 – Create a Flow

With the Azure AD application created, you can now look to create a flow using it. First, go to https://flow.microsoft.com and go to My flows. Select New > Create from blank to create a new flow.

Don’t use any triggers and select Create from blank

Select a trigger to start the flow. In my case I will use a Recurrence (once a day at midnight)

The next step in the flow is to create some variables. These variables are the application (client) id, directory (tenant) id and secret you should have from the previous steps. Create 3 variables like below.

With the variables defined, they can be used to create the API call to Graph. To do this, create a HTTP action with the following information:

Step 3 – Run the Flow

All being well, the flow should run successfully and not produce any errors.

Drilling down into the HTTP Graph API call, I can see the status code 200 (OK) and the data itself in the body.

Next Steps

This post has outlined how to create an Azure AD application and use it with Flow/Logic Apps. You should be able to take this and implement it into other Graph API calls, this could be to create or modify existing data, not just retrieve data.

]]>https://www.lee-ford.co.uk/using-flow-with-graph-api/feed/21466Send Message Cards with Microsoft Teamshttps://www.lee-ford.co.uk/send-message-cards-with-microsoft-teams/
https://www.lee-ford.co.uk/send-message-cards-with-microsoft-teams/#respondTue, 22 Jan 2019 08:30:50 +0000https://www.lee-ford.co.uk/?p=1370Microsoft Teams has a feature that I don’t see used or talked about a whole lot – Cards.

Cards allow you to post a container to a Teams channel. The type of card I will use here is a Message Card. These can contain text, images, links etc.

Message Cards are not to be confused with Adaptive Cards. These are entirely different and are not exclusive to Teams. Adaptive cards are more flexible and interactive than Message Cards but unfortunately, do not support the method I employ here – Incoming Webhook.

Create Incoming Webhook in a Team Channel

The first action you need to undertake is creating an Incoming Webhook within Teams. An Incoming Webhook is a way to deliver data into a service using HTTP calls.

To create an Incoming Webhook:

Find the Team you want to use for the Message Cards and click “Manage team”:

Next, go to “Apps” and click “Go to store”:

In the Store, search for “Incoming Webhook” and click on it. The Team should already be selected. Click “Install”:

Select the Channel to receive the Webhooks and click “Set up”:

You will be taken to a list of connectors, click “Configure” next to Incoming Webhook.

Give the Webhook a name and upload an icon (if desired) and click “Create”:

The next step is important – copy the Webhook URL and keep it safe – this will be needed later and this is the only time it is shown. Once copied, click “Done”.

You have now setup an Incoming Webhook in Teams

Create a Message Card

A Card is structured using JSON. I won’t go over all permutations of a Card (as they differ between Card types) – the Mircosoft Docs do a pretty good job explaining it, though – https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/cards/cards-reference

If you wish to test your JSON for a Message Card before using in Teams, I recommend using the Message Card Playground website – https://messagecardplayground.azurewebsites.net/ – it allows you to visualise the layout and view sample code.

For this article, I’m going to post tweets containing the hashtag #MicrosoftTeams as a Message Card. Here is the JSON without any values assigned:

Send Message Card in to Teams

Now there is an Incoming Webhook defined and the Team channel and there is a Message Card JSON to use, the next step is to send the JSON via an Incoming Webhook. I’ll first demonstrate how this can be done via a manual HTTP POST and afterwards how this could be automated.

Send Message Card using HTTP POST

An Incoming Webhook is expecting the body (Message Card in this case) in JSON format using a HTTP POST method. As the URL of the Incoming Webhook is intended to be kept secret, there is no authentication required. I am going to demonstrate how to send to an Incoming Webhook using PowerShell, but ultimately any language that support HTTP POST should work.

Essentially the script is running a HTTP POST method to the Incoming Webhook URL, setting the HTTP ContentType (body) as JSON and attaching the JSON as the body. Here is the output in Teams:

Automating the Process

The script has proved that everything is now in place, but ideally you want this to be automated with dynamic data inside. Enter Microsoft Flow (or Azure Logic Apps if you prefer).

I’ve set up a Flow to look for new #MicrosoftTeams posts on Twitter and post an HTTP POST request when one is found. This will contain the user, time posted and the tweet itself. Additionally, there is a link to view all tweets with #MicrosoftTeams in.

When creating the body, I’ve populated the values with values from the tweet itself. Special care has to be taken to ensure any @ values contain two @ symbols otherwise the flow will not save.

Once saved, it should start flowing in to Teams…

And there you are, Message Cards posted in to Teams.

]]>https://www.lee-ford.co.uk/send-message-cards-with-microsoft-teams/feed/01370Deploying an AudioCodes SBC in Azure using the Azure Marketplacehttps://www.lee-ford.co.uk/deploying-an-audiocodes-sbc-in-azure-using-the-azure-marketplace/
https://www.lee-ford.co.uk/deploying-an-audiocodes-sbc-in-azure-using-the-azure-marketplace/#commentsTue, 04 Dec 2018 08:00:01 +0000https://www.lee-ford.co.uk/?p=1336If 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:

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. Instead, they have published the SBC to the Azure Marketplace. As long as you have access to create resources in Azure, you’re good to go.

Let’s begin!

Step 1 – Login to Azure Portal and locate AudioCodes Mediant SBC

Easiest method for this is to click “Create a resource” in the top left and search for “AudioCodes Mediant”. Select “AudioCodes Mediant VE SBC for Microsoft Azure” (rolls off the tongue).

You will need to specify a subscription and a resource group within that subscription. If you don’t have any, they will be created.

Next, you’ll need to give the VM a name and be asked to place it in a region (I’d recommend as close as possible).

If you are planning on deploying multiple SBCs in the same Azure tenant and region, you may want to setup an Availability Group (stops resources using same hardware).

For sizing, I went with an A2 v2, which should work fine up to 50 SBC sessions with no transcoding. If you are planning on going over that or plan to transcode, you may want to go for something beefier.

Lastly, you need to choose a username (cannot be admin or administrator) and password/SSH public key. In my scenario, I went SSH public key as I will be accessing over the internet and is that extra layer of protection.

Once completed, click “Review + create”

Step 3 – Review further setup of VM

You will be asked a list of further questions (hardrive, networking, management etc.). I just skipped through without needing to make a change.

Standard SSD should suffice.

If you have existing networking to use, specify it here.

Good idea to enable boot diagnostics incase of a machine being unable to boot.

Step 4 – Review configuration and build VM

You should now be at the stage to build the VM. Review the configuration, then click Create if happy.

Built in less than 5 minutes!

Step 5 – Ensure you have access to SBC

Once built you should be provided with a public IP address. From there you can access via HTTPS and SSH using the account specified under Step 2. Note: If you selected SSH public key, the password for the web portal of the SBC will be the same as the username – so change it ASAP!

Once you have access, I would strongly think about locking down HTTPS and SSH access in the NSG to your own IP address ranges.

Hopefully, you managed to follow this guide. In my opinion, this is by far the easiest way to deploy an AudioCodes SBC in Azure!

]]>https://www.lee-ford.co.uk/deploying-an-audiocodes-sbc-in-azure-using-the-azure-marketplace/feed/21336Review: AudioCodes 450HDhttps://www.lee-ford.co.uk/review-audiocodes-450hd/
https://www.lee-ford.co.uk/review-audiocodes-450hd/#respondSat, 20 Oct 2018 20:21:21 +0000https://www.lee-ford.co.uk/?p=1292Whilst attending Evolve in Birmingham this year (which I highly recommend), I went to the AudioCodes booth and got on to the subject of their handsets. I’ve mainly used LPE or Polycom VVX so was intrigued by their offerings and they kindly offered to lend me a handset to test and review.

Today, I have an AudioCodes 450HD with expansion module (allows for an extra 22 one-touch keys). It is certified Skype for Business Online and On-Premises (in addition to ‘standard’ SIP). It is marketed as a high-end device – does it live up to it? Here is my quick review of the handset.

Build

The device is quite sturdy and has some heft to it – with the added expansion model, it does take up quite a bit of the desk.

The screen is 5″ colour touchscreen. It looks to be a higher resolution (800x400px) compared to other handsets I’ve used in the past and is responsive to the touch.

The only knock I would have with the build of the device is the keys can feel a bit ‘mushy’ when pressed, so you aren’t always convinced your button press has registered and end up pressing twice.

Audio

Audio quality is great. It helps that the device supports higher quality codecs such as SILK.

Handset and USB headsets work well. Speaker phone sounds passable my end, but I personally don’t like putting the far end on speaker!

Usage

The device can sign in to Skype for Business Online using User/Password, Web Sign-In or Common Area Phone. For Skype for Business On-Premises, it supports User/Password and Extension/PIN (can be used as a Common Area phone).

There is also support for MS Teams, but this doesn’t include the native application (that will be the C450HD) as the phone essentially still signs in to SfBO, it just allows calls to be made/received even if you only use Teams.

Once signed in, the device is very simple to use, with a clearly laid out UI. Whether that is adding contacts to one-touch keys, transferring calls, parking calls or viewing the calendar. Most functions can either be completed using the touchscreen or the keys.

The majority of the device configuration can be configured on the device itself, but can also be completed by web-browsing to the device. Additionally, if you have multiple devices you can administer using AudioCodes’s own IP Phone Manager solution and push out congfiguration that way.

Overall

Overall, it’s been a great device to use, when I don’t want to use a headset. If I need to join a scheduled SfB meeting, it’s a one-touch to join, which has been great. If I want to make a quick call, it just works.

I have noticed a few minor issues too. One being the screen never goes to sleep – even on the lowest setting, it is still always on.

Another issue is I am unable to join MS Teams meetings – if I select ‘join’ on the phone, it reboots! UPDATE: AudioCodes have advised me this is a known issue that will be resolved in an upcoming release.

If you are looking to use a phone in a Skype for Business and want a high-end phone, I would certainly give this phone a look. If you are possibly looking to move to MS Teams, you may better waiting for Teams native devices to hit the market.

I’ve had this issue reported to me a few times. A customer will not be able to call certain numbers from Skype for Business/Teams. When I look at the SIP trace within Syslog there is an error message from the SIP provider – SIP/2.0 483 Too Many Hops. This isn’t an AudioCodes specific issue, but this is how to resolve it for AudioCodes SBC.

AudioCodes Syslog Trace showing error from SIP provider

Essentially, this error is that there are too many “hops” (SIP peers) between yourself and the destination. Think of it like a traceroute, if you set the number of hops too low, it would fail

Resolution

Fortunately, this is easily resolved by changing the amount of “hops” by changing the Max Forwards value like below.