Skype for Business Voice Lab – Part 4

SfB Voice Lab Part 4 – AudioCodes Mediant Virtual Edition (VE) Deployment

To read other parts in this series, please click the links below:

Part 1: Overview and Architecture
Part 2: Azure Prep Work
Part 3: Skype for Business 2015 On-Prem Deployment
Part 4: AudioCodes Mediant Virtual Edition (VE) Deployment
Part 5: SIP Trunk Setup (IntelePeer – AudioCodes – Skype for Business)
Part 6: Office 365 and Skype for Business Online Deployment (Hybrid)
Part 7: On-Prem PSTN Connectivity with Hybrid (OPCH) setup and Tenant Dial Plans
Part 8: Cloud Connector Edition (CCE) Deployment
Part 9: Legacy PBX Deployment and SfB Integration

In Part 4, we’ll be installing an AudioCodes Mediant Virtual Edition (VE) in Azure. In Part 5, we’ll cover the integration with Skype for Business and our ITSP (IntelePeer).

NOTE: Installing the AudioCodes SBC in Azure is unsupported, and can be quite challenging to get working!!! I’ve tried to document it the best I could for those willing to give it a shot.  If you’re not doing this in Azure, use the virtual image that best matches your environment.

Software Required:

Note: You will need to create an account with AudioCodes in order to download anything from their site. You may need to contact AudioCodes direct to get the required permissions for media downloads.

Here is the software I used for this series.

  • VMWare 7.2 OVF File (Version 7.20.100)
  • Syslog Viewer – Version 1.14
  • INI Viewer and Editor

 Here are a couple of documents I’d also recommend downloading.  There may be newer versions available.

  • LTRT-10820 Mediant Virtual Edition SBC Installation Manual Ver. 7.2.pdf
  • LTRT-31623 Mediant Series SBC Design Guide.pdf
  • LTRT-41876 Mediant Software SBC Virtual and Server Editions User’s Manual Ver. 7.2.pdf
  • LTRT-54030 Skype for Business – Mediant SBC for ITSP SIP Trunking Configuration Note Ver. 7.2.pdf
  • LTRT-30541 INI Viewer and Editor Utility User’s Guide.pdf
  • LTRT-17928 Media Gateway & SBC CLI Reference Guide Ver. 7.2.pdf

Step 1: Convert VMWare VMDK file to Azure supported VHD format

There are 4 versions of the AudioCodes Mediant Virtual Edition:

  1. Hyper-V – Mediant VE (Virtual Edition) Hyper-V 7.2 VM Image
  2. VMWare – Mediant VE (Virtual Edition) VMWware 7.2 OVF File
  3. KVM – Mediant VE (Virtual Edition) KVM/Openstack 7.2 Qcow2 File
  4. Amazon Web Services – Amazon Machine Image

Your first question might be why did you use the VMWare image instead of the Hyper-V image?  A great question.  To answer that, we’ll look at the virtual machine formats supported by Azure.  “Azure supports only generation 1 VMs that are in the VHD file format and have a fixed sized disk.”   The Hyper-V download comes in a Generation 2 VHDX format, which makes it unusable in Azure.  To get around this, you can download the VMWare version, and convert the VMDK to a VHD.

To do this, I used the Microsoft Virtual Machine Converter version 3.1.  After installing the converter, I turned to PowerShell.


Step 2: Prepare the Mediant VE locally in Hyper-V

Now that the virtual machine is in a supported file format, there’s a bit of prep work that needs to be done to the Mediant VE image before it can be uploaded in to Azure.

To complete these steps, you’ll need Hyper-V.  I simply used my Windows 10 machine that had Hyper-V installed.

First things first, create a new Virtual Machine. This is done easy enough in Hyper-V.

Actions -> New -> Virtual Machine

Select Generation 1 Virtual Machine

Attach the SBC VHD created in the previous step

Summary view of new Virtual Machine

Add an additional Network Adapter to the Virtual Machine settings
I wanted two network interfaces on the SBC so I could simulate a two-legged setup. One leg (network interface #1) in the DMZ connecting to the public internet, and one leg (network interface #2) on the internal network connecting to the

LAN.Settings -> Add Hardware -> Network Adapter

Reset the SBC to its factory configuration (Return to Default Snapshot)

Power on the newly created Virtual Machine in Hyper-V and reset the SBC to its factory image.

Select Rescue Options from the Boot Menu

Select Return to default snapshot

Sit back and watch the SBC re-install itself

Configure network interface for local Hyper-V network

After the SBC reinstalls, it will boot up and you can access the CLI from the console.  The first thing you must do is configure the network interface so that you can access it via your local Hyper-V network.Sign in using the default username/password.

(REMINDER: Don’t forget to change the default Username/Password)

Enter into enable mode

Enter into network configuration mode

Configure the IP Address, Gateway, Subnet Mask and activate

Restart to save settings

Enable DHCP

This step is critical. In Azure, you will not have console level access to the CLI. You will need to ensure that when the SBC is powered on, it obtains an IP address automatically so that you can access the GUI via a browser. Since Azure Virtual Machines use DHCP for IP assignment, we need to ensure DHCP is enabled on the SBC (it is disabled by default).  If you skip this step, you’ll never be able to access the SBC in Azure.

Connect to the admin portal using the IP address that was set via the CLI

Enable DHCP:

IP Network –> Advanced –> Network SettingsDHCP –> Enable DHCP: Change from Disable to Enable

Click Save at the top of the screen, and then Reset

Once DHCP has been enabled and the system has been reset, the image is ready to be uploaded.  You can go ahead and shut down the machine in Hyper-V.

Step 3: Upload Mediant VE VHD to Azure Blob Storage

There are a couple of ways to upload the VHD to Azure Blob Storage. You can do it directly from the Azure Portal or via PowerShell.


Storage Account -> Select Storage Account Used -> Blobs -> VHDs -> Upload




Step 4: Create the SBC Network Interfaces

While the VHD was uploading, I pre-staged the network interfaces in Azure so that I could associate them with the new VM I was going to build.  NOTE: This can all be achieved in PowerShell, I simply chose to do some of it in the Portal.

Why two?  Again, the SBC can operate using a single leg, but I want to simulate a real-world configuration, where one leg is in the perimeter network and one leg is in the internal network. This also matches the network interfaces I created in the Hyper-V image prior to uploading.

Step 5: Create a new virtual machine using Mediant VE VHD

I modified the following script to meet my needs: 


Step 6: Configuring the AudioCodes Mediant VE

Reference: LTRT-10820 Mediant Virtual Edition SBC Installation Manual for additional assistance.pdf

Reference: LTRT – 41876 Mediant Software SBC Virtual and Server Editions User’s Manual Ver. 7.2.pdf

Once the VM is created, you can Start your SBC via the Azure portal.  It may have started automatically once created.  Keep in mind you do not have console level access.  So, cross your fingers that it boots properly and DHCP assigns it a valid IP address.   While there is no console interaction, we do have console screenshots via Boot Diagnostics.  It doesn’t hurt to review this to see what’s going on at boot time.


I had a couple of issues getting connected the first time, so I’ll give you some of the troubleshooting methods I used.

  1. Make sure you are trying to connect from a machine in your Azure tenant on the same VNet, in the same subnet and in the same subscription.
  2. Try pinging the SBC from a machine in your Azure tenant
  3. Check the Network Security Group assigned to your Network Interface.  Make sure nothing is being denied.  You can try adding a rule to allow HTTP: TCP/80, HTTPS: TCP/443, and SSH TCP/22, although it shouldn’t be necessary for allowing connections from within the same VNet and subnet.
  4. Review the Boot Diagnostics log.  It may be stuck in an infinite loop, indicating the VM was not prepared properly before uploading.

If it doesn’t boot properly, doesn’t obtain a DHCP address, or you have any other issues, you’ll likely need to start over by fixing the issue locally within Hyper-V and re-uploading the image.  Don’t feel bad if you have to start over.  I think I was on upload #6 before I got things working the way I wanted.

Signing into the GUI

Now that the VM is created and started, we can wait a few minutes and with any luck we’ll be able to access the GUI via the IP address we assigned to the SBC_IntNI.


 Administration –> WEB & CLI –> Local Users

Setting up the IP Network:

The IP Network on an AudioCodes SBC can be a bit confusing.  v.7.0 and higher make things a bit easier to follow with the improved user interface and high-level map views.


 We’ll use the above diagram for reference.  As you can see, there are two (2) physical ports that we will configure.

 IP Interfaces – This reflects the IP address and application type.

  • OAMP – Operations Administration, Management and Provisioning.  If you want to be able to access the SBC from any of its management tools (embedded Web Server, EMS, or Telnet/SSH), OAMP must be assigned to at least 1 Network Interface.  This is typically assigned to the internal interface and not the external interface.  Since the external interface is exposed to the internet, we don’t want any rogue individuals trying to gain administrative access to our device.
  • Media – RTP Traffic
  • Control – SIP Signaling

VLANS (Ethernet Devices) – Links the IP Interface to the Underlying Ethernet Group.

  • VLAN ID’s can be applied and tagged to the packets at this level if used.

Ethernet Groups – Used for network level high availability.  Groups one ore multiple physical ports together.

  • NONE

Physical Ports – Represents the physical ports that connect the SBC to the VNet.  Think of these as the Azure Network Interfaces.

Step 1: Verify the Physical Ports

The default Physical Port settings should be sufficient. There should be two (2) Physical Ports that reflect that two (2) Azure Network Interfaces that we assigned to the Virtual Machine

Step 2: Verify the Ethernet Groups

The default Ethernet Group settings should be sufficient. Each Ethernet Group should have a single Physical Port associated with it.

Step 3: Configure the Ethernet Devices

A single Ethernet Device exists by default. A second Ethernet Device will need to be created and associated with Ethernet Group 2 (GE_2)

Create New Ethernet Device:


View newly created Eth Device:

Step 4: Configure the IP Interfaces

A single IP Interface exists by default. You’ll notice this IP Interface has an IP address of and says IPv4 Manual. While the Interface Mode shows Manual, it was most assigned by DHCP when the SBC booted. A second IP Interface will need to be created and associated with the newly created Ethernet Device (VLAN 2)

Select New to create a new IP Interface. You may also notice I renamed the default IP Interface to LAN_IF

The IP address that you assign to this IP Interface must match the Azure Network Interface IP address that is assigned to the Virtual Machine. In our case,

Index: 1

Application Type: Media + Control (Since this interface will be exposed to the internet, we don’t want the OAMP assigned)
Ethernet Device: #1 [VLAN 2]

Primary DNS:
Secondary DNS:

IP Address:
Interface Mode:
IPv4 Manual
IP Address:
Prefix Length: 24
Default Gateway:

Don’t forget to select Save after the new IP Interface is created.

 Select Network View and validate the new network appears as expected.


That’s it for Part 4. In this part we converted the VMWare Mediant VE Image from AudioCodes, pre-configured it in Hyper-V, uploaded it to Azure, and setup the network configuration.

Continue the series where next we will setup up our SIP Trunks with IntelePeer and Skype for Business. Part 5: SIP Trunk Setup (IntelePeer – AudioCodes – Skype for Business)

As always, feel free to post any questions or comments.


Leave a Reply

Your email address will not be published. Required fields are marked *