Skype for Business Voice Lab – Part 2

SfB Voice Lab Part 2 – Azure Prep Work

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 1, we highlighted the architecture and goals of this series.

In Part 2, we get the foundation of our Azure based lab ready to go.  If you’re not building this in Azure, feel free to skip over this section.  If you are, you may already have a working Azure environment and can skip over some of this as well.  You may also be able to give me a few pointers!  In the spirit of thoroughness, I figured I would try and document as much as possible for those going through this for the first time.

This is by no means a definitive guide to deploying Virtual Machines in Azure. Similarly, there are a lot of different ways to accomplish the same tasks.  I’ll use both the Portal and PowerShell to walk through the setup and creation of our VMs.

Create the Resource Manager Storage Account

The first thing I did was create a storage account.  This can be done as a standalone step, or this can be done at the time the first VM is built.  I decided to use unmanaged disks because this is only a lab, and quite frankly I wanted to save on cost.

Create the Resource Group

A resource group is required to logically group our resources together.  Again, I’m using a single RG to keep things organized and contained. I created the RG during the Virtual Network setup as you can see below.

Create the Virtual Network

At least one Virtual Network is required so the virtual machines can communicate with each other.  I’m using a single VN with multiple subnets.

  • BackEnd – This subnet represents the internal LAN
  • Perimeter_Ext – This subnet represents the external facing Perimeter Network
  • Perimeter_Int – This subnet represents the internal facing Perimeter Network

Create additional address spaces that will be used for the perimeter Subnets

In order to create the additional subnets, the additional address spaces need to be setup.


Create Additional Subnets that will be used for Perimeter Network Interfaces

Now that the Virtual Network is created, and the additional Address Spaces have been added, we can create the additional Subnets.



Create Virtual Machines in Azure

OK, now onto the fun part.  This is a rinse and repeat step.  I have the screen shots loaded for DC01, but all servers were built using the same logic.

 The following servers were all built using the Server 2016 Datacenter image from the Marketplace.

  • DC01
  • SfB01
  • App01
  • Edge01
  • RP01

Virtual Machine Configurations:

1) Basics

  • Server Name: DC01
  • VM Disk Type: HDD
  • Username: lab-admin
  • Password: ********
  • Subscription: <Valid Subscription Name>
  • Resource Group: RG01
  • Location: East US


2)  Size: Basic A2


3) Settings

  • Use Managed Disks: No
  • Storage Account: Select Storage Account
  • Network: VNet01
  • Subnet: BackEnd (
  • Public IP address: None
  • Network Security Group: (new) DC01-nsg


 4: Summary Review and Validation


Edge01 Network Setup

The SfB Edge will require multiple Network Interfaces in separate Subnets.  This is a Microsoft requirement for SfB Edge servers.  To accomplish this, we can create two Network Interfaces on the existing Virtual Network.

Edge01 Internal Network Interface Setup:

  • Name: Edge01_IntNI
  • Virtual Network: VNet01
  • Subnet: Perimeter_Int (
  • Private IP Address: Dynamic
  • Network Security Group: None (This will be applied later)
  • Subscription: Choose a valid subscription in your tenant
  • Resource Group: RG01
  • Location: East US

 Edge01 External Network Interface Setup:

  • Name: Edge01_ExtNI
  • Virtual Network: VNet01
  • Subnet: Perimeter_Ext(
  • Private IP Address: Dynamic
  • Network Security Group: None (This will be applied later)
  • Subscription: Choose a valid subscription in your tenant
  • Resource Group: RG01
  • Location: East US


Public IP Setup:

Three (3) Public IP’s (“PIP”) will be used for the Skype for Business Edge server, one (1) Public IP will be used by the Reverse Proxy, and one (1) public IP will be used by the SBC.

  • Edge01_AE_IP
  • Edge01_WC_IP
  • Edge01_AV_IP
  • SBC01_PIP
  • RP01_PIP



Associate PIP with Network External Network Interface:

Edge01 Access Edge IP

Edge01 Web Conferencing IP

Edge01 AV Network IP

Network Security Group Setup:

A network security group (NSG) contains a list of security rules that allow or deny network traffic to resources connected to Azure Virtual Networks.  Since I am using a single VNet with separate subnets to distinguish security boundaries, I’m going to setup NSG’s as a way to firewall traffic between these zones.

 First, we’ll create the NSG’s for the Skype for Business Edge server.

 Below is a diagram of the port requirements for the SfB Edge server.


The above diagram was used as a reference for creating the Network Security Groups for the Edge.  Two NSG’s were created.  One for the External interface and one for the Internal Interface.

External Edge NSG:

  • TCP/UDP 5061
  • TCP 443
  • UDP 3478
  • TCP/UDP 50,000 – 59,999
  • TCP 5269


Edge Internal NSG:

  • TCP 3389 – RDP
  • TCP 50,001 – 50,003  – Central Logging Service
  • TCP 23456 –  XMPP
  • TCP 5061 – SIP
  • TCP 5062 – PSOM
  • TCP 3478 – STUN
  • TCP 443 – STUN
  • TCP 4443 – CMS Replication

Assign Network Security Groups to a Network Interface

Once the NSG’s are created, they will need to be applied to the appropriate Network Interface.  In this example, we’ll assign the Network Security Group EdgeInt_NSG01to the Network Interface Edge01_IntNI.

Assign Network Interface to the SfB Edge Server

OK, now that we have the SfB Edge Network Interfaces created, Public IP addresses assigned, and Network Security Groups associated, we’ll need to attach the Network Interfaces to the Edge01 VM.

The first thing to note is that when the SfB Edge server is initially built, there is a default Network Interface assigned to it.  I didn’t want to use that one, because I wanted control over the naming convention (I know it’s silly, but sometimes I like uniformity).  So, I removed the original Network Interface and assigned the two new Network Interfaces I created to the Edge01 VM.  This is done in PowerShell.

Store the current configurations for Edge01 in a variable

Display the current Network Interfaces for Edge01.  This shows a single default Network Interface attached called “edge01828”.

Store the Network Interfaces we will be working with in variables

Attach the two (2) new Network Interfaces to Edge01, and remove the default Network Interface

Display the new Network Interface configurations stored in the variable representing Edge01

Update the Edge01 VM using the new configurations that were stored in the variable

Updated Network Interface Screen Shot


That’s it for Part 2. In this part we readied the foundation of our Azure lab.

Continue the series where next we will build out our Skype for Business 2015 On-Prem Infrastructure. Part 3: Skype for Business 2015 On-Prem Deployment

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


Leave a Reply

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