Plan for Skype for Business Cloud Connector Edition

Skype for Business Server 2015
 

Topic Last Modified: 2017-04-19

Find information on Skype for Business Cloud Connector Edition, a set of packaged Virtual Machines (VMs) that implement on-premises PSTN connectivity with Cloud PBX.

Cloud Connector Edition might be the right solution for your organization if you do not already have an existing Lync Server or Skype for Business Server deployment. If you're still investigating which Cloud PBX solution is right for your business, see Plan your Cloud PBX solution in Skype for Business.

This document describes Cloud Connector Edition requirements and supported topologies, and helps you plan your Cloud Connector Edition deployment. Be sure to read this topic before you configure your Cloud Connector environment. When you are ready to deploy and configure Cloud Connector Edition, see Configure Skype for Business Cloud Connector Edition.

Cloud Connector Edition 1.4.2 is now available. If you have not yet upgraded to 1.4.2, see Upgrade to a new version of Cloud Connector. You can find the installation file at https://aka.ms/CloudConnectorInstaller.

noteNote:
Microsoft supports the current version of Cloud Connector Edition, version 1.4.2. If you configured automatic update, Cloud Connector will update automatically. If you configured manual update, you will need to upgrade to version 1.4.2 within 60 days of its release. Microsoft will support version 1.4.1 for 60 days after the release of 1.4.2 to allow you time to upgrade. Cloud Connector 1.3.8 is no longer supported.

Cloud Connector Edition is a hybrid offering that consists of a set of packaged Virtual Machines (VMs) that implement on-premises PSTN connectivity with Cloud PBX. By deploying a minimal Skype for Business Server topology in a virtualized environment, users in your organization who are homed in the cloud can receive PBX services from the Microsoft cloud, but PSTN connectivity is provided through the existing on-premises voice infrastructure.

Topology diagram showing Cloud PBX Gateway connecting Cloud PBX to an on-premises deployment of Skype for Business.

Consider the following when planning your Cloud Connector Edition deployment:

  • To use Cloud Connector to take advantage of cloud voice solutions, you'll need to sign up for an Office 365 tenant that includes Cloud PBX. If you do not yet have an Office 365 tenant you can learn how to sign up here: Office 365 for Business. Note that you'll need to sign up for a plan that includes Skype for Business Online.

  • Cloud Connector uses the Skype for Business Online dedicated tenant global admin credentials to register Cloud Connector Edition appliances with the Skype for Business Online service and to run various cmdlets.

  • Cloud Connector does not require a full on-premises Skype for Business Server deployment.

    Currently, Cloud Connector cannot co-exist with Lync or Skype for Business on-premises servers. If you want to move existing Lync or Skype for Business users to Office 365 and keep providing on-premises telephony to your users, consider Cloud PBX with on-premises connectivity using an existing Skype for Business Server deployment. For more information, see Plan your Cloud PBX solution in Skype for Business and Plan Cloud PBX with on-premises PSTN connectivity in Skype for Business Server 2015 or Lync Server 2013.

  • Cloud Connector is available worldwide.

  • Your users are homed online.

  • You can keep your current PSTN carrier if required.

  • If you want to provide dial-in conferencing to users hosted on Cloud Connector, you can purchase PSTN conferencing from Microsoft or from audio conferencing provider (ACP) partners.

This topic contains the following sections:

With Cloud Connector Edition, you deploy a set of packaged VMs that contain a minimal Skype for Business Server topology—consisting of an Edge component, Mediation component, and a Central Management Store (CMS) role. You will also install a domain controller, which is required for the internal functioning of Cloud Connector. These services are configured for hybrid with your Office 365 tenant that includes Skype for Business Online services.

Cloud Connector Edition components

Cloud Connector components provide the following functionality:

  • Edge component – Communication between the on-premises topology and the online services goes through the Edge component, which includes the following components:

    • Access Edge – Provides SIP routing between the on-premises deployment and Skype for Business Online.

    • Media Relay – Provides routing of media between the Mediation component and other media endpoints.

    • Media Relay Authentication / MRAS – Generates tokens for access to media relay.

  • Outbound Routing – Provides routing to gateways based on policies. Only global policies which are based on destination (outbound) PSTN numbers are supported.

  • Central Management Store (CMS) role – Includes the configuration store for the topology components, including CMS File Transfer.

  • Central Management Store (CMS) replica – Synchronizes configuration information from the global CMS DB on the CMS role server.

  • Domain controller – Cloud Connector Active Directory Domain Services to store all the global settings and groups necessary to deploy Cloud Connector components. One forest will be created for each Cloud Connector appliance. The domain controller should not have any connections with the production Active Directory. Active Directory services include:

    • Active Directory Domain Services

    • Active Directory Certificate Services to issue internal certificates

  • Mediation component – Implements SIP and Media gateway mapping protocol between Skype for Business and PSTN gateways. Includes a CMS replica that synchronizes configuration from the global CMS database.

For purposes of this discussion, we will refer to PSTN sites. A PSTN site is a combination of Cloud Connector appliances, deployed at the same location, and with common PSTN gateways connected to them. PSTN sites allow you to:

  • Provide connectivity to gateways that are closest to your users.

  • Allow for scalability by deploying multiple Cloud Connector appliances within one or more PSTN sites.

  • Allow for high availability by deploying multiple Cloud Connector appliances within a single PSTN site.

This topic introduces PSTN sites. For more information about planning your PSTN sites, see Plan for Cloud Connector Edition PSTN sites.

You can deploy the following Cloud Connector topologies:

  • A single Cloud Connector Edition appliance per PSTN site. This topology is recommended for evaluation purposes only because it does not provide high availability.

  • Multiple Cloud Connector Edition appliances (up to 4) per PSTN site to provide high availability.

  • Multiple PSTN sites with multiple Cloud Connector Edition appliances to provide scalability with high availability. You can deploy up to 200 sites.

When planning your topology, consider the following:

  • One PSTN site can have up to 4 Cloud Connector appliances—3 appliances plus 1 appliance for high availability.

  • There are two types of hardware configurations tested with Cloud Connector:

    • The larger version is capable of handling up to 500 simultaneous calls and is supported in all types of production environments.

    • The smaller version is capable of handling up to 50 simultaneous calls. The smaller version is intended to run on lower-end hardware and can be used for evaluation purposes or for sites with low call volumes. If you deploy a smaller version of Cloud Connector, you still need to be mindful of production-class hardware requirements (such as dual power supplies).

  • If you deploy the maximum 3 + 1 configuration (with larger hardware), then your PSTN site can handle up to 1500 simultaneous calls. If you deploy the smaller version, the supported limit is 150.

  • If you need to have more calls per PSTN site, you can scale up by deploying additional PSTN sites in the same location.

noteNote:
Unless noted, the diagrams and examples below assume the use of the larger version of Cloud Connector.

The following diagram shows a single Cloud Connector Edition appliance within a single PSTN site. Note that Cloud Connector consists of four VMs installed on one physical host machine that is within a perimeter network for security purposes.

One Cloud Connector with One PSTN Site

For scalability and high availability purposes, you can choose to have multiple Cloud Connector Editions within a single PSTN site as shown in the following diagram. Consider the following:

  • Calls are distributed in random order between Cloud Connectors in one pool.

  • For capacity planning purposes, you should consider the ability to handle the load if one or more Cloud Connectors go offline, based on the following calculations:

    • N+1 boxes. For the larger version of Cloud Connector, N+1 boxes support 500*N concurrent calls with 99.8% availability.

      For the smaller version of Cloud Connector, N+1 boxes support 50*N concurrent calls with 99.8% availability.

    • N+2 boxes. For the larger version of Cloud Connector, N+2 boxes support 500*N concurrent calls with 99.9% availability.

      For the smaller version of Cloud Connector, N+2 boxes support 50*N concurrent calls with 99.9% availability.

Two Cloud Connectors within 1 PSTN Site

You can also choose to have multiple PSTN sites with one or more Cloud Connector Editions in each site. If your PSTN site reaches the limit of 1500 simultaneous calls, you can add another PSTN site to handle the load.

Multiple PSTN sites also allow you to provide connectivity to gateways that are closest to your users. For example, assume you have PSTN gateways in Seattle and Amsterdam. You can deploy two PSTN sites—one in Seattle, one in Amsterdam—and assign users to use the PSTN site that is closest to them. Users from Seattle will be routed to the Seattle PSTN site and gateways, while users in Amsterdam will be routed to the Amsterdam PSTN site and gateways:

Cloud Connector Edition Within 2 PSTN Sites

Before you deploy Cloud Connector Edition, make sure you have the following for your environment:

  • For the host machine - Cloud Connector VMs must be deployed on dedicated hardware running Windows Server 2012 R2 Datacenter edition with the Hyper-V role enabled.

  • For the virtual machines - A Windows Server 2012 R2 ISO image (.iso). The ISO will be converted to VHDs for the virtual machines that will run Skype for Business Cloud Connector Edition.

  • The necessary hardware to support installation of the 4 VMs for each Cloud Connector Edition in your deployment. The following configurations are recommended:

    • 64-bit dual processor, six core (12 real cores), 2.50 gigahertz (GHz) or higher

    • 64 gigabytes (GB) ECC RAM

    • Four 600 GB (or better) 10K RPM 128M Cache SAS 6Gbps disks, configured in a RAID 5 configuration

    • Three 1 Gbps RJ45 high throughput network adapters

  • If you choose to deploy the smaller version of Cloud Connector Edition that supports up to 50 simultaneous calls, you will need the following hardware:

    • Intel i7 4790 quad core with Intel 4600 Graphics (no high end graphics needed)

    • 32 GB DDR3-1600 non ECC

    • 2: 1TB 7200RPM SATA III (6 Gbps) in RAID 0

    • 2: 1 Gbps Ethernet (RJ45)

  • If a proxy server is required on the host machine for browsing the Internet, then you should make the following configuration changes:

    1. To bypass the proxy, specify WinHTTP Proxy settings set with your proxy server and a Bypass-list including the "192.168.213.*” network used by your Cloud Connector Managements services. Otherwise, management connectivity will fail and prevent the deployment of Cloud Connector. Note that you should match the bypass list to the management subnet that is defined in your CloudConnector.ini file. The following is a sample winhttp configuration command: netsh winhttp set proxy "10.10.10.175:8080" bypass-list="*.local;1.*;172.20.*;192.168.218.*'<local>".

    2. Specify proxy settings per machine rather than per user. Otherwise Cloud Connector downloads will fail. You can specify proxy settings per machine with a registry change or with the Group Policy setting as follows:

      • Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings] ProxySettingsPerUser dword:00000000

      • Group Policy: Computer>Administrative Templates>Windows Components> Internet Explorer: Make Proxy settings per machine (rather than per user)

  • Qualified PBX/Trunk or qualified SBC/Gateway (a minimum of two gateways is recommended).

  • A local server administrator account with permissions to install and configure Hyper-V on the host servers. The account must have administrator permissions on the local server where Hyper-V is installed and configured.

  • During the deployment, you will be asked to create a domain administrator account with permissions to create and publish the topology in the Cloud Connector domain.

  • The external DNS records, which are defined in the CloudConnector.ini file included with the installation package:

    • External DNS record for Access Edge service of Edge component; for example, ap.<Domain Name>. You need one record per PSTN site. This record should contain IP addresses of all Edges for that site.

  • An Office 365 tenant with all required DNS and SRV records created.

    importantImportant:
    When you integrate your tenant with Cloud Connector Edition, the use of the default domain suffix, .onmicrosoft.com, as a SIP domain for your organization is not supported.
    You cannot use sip.<Domain Name> as the name of your Cloud Connector Edge Access proxy interface because this DNS record is used by Office 365.
  • A certificate for the external Edge obtained from a public Certificate Authority (CA).

  • Firewall rules to allow traffic through the required ports has been completed.

  • An Internet connection for the host machine and the VMs. Cloud Connector downloads some software from the Internet; therefore, you must provide gateway and DNS server information so that the Cloud Connector host machine and VMs can connect to the Internet and download the necessary software.

  • A tenant remote PowerShell module installed on the host machine.

  • The appropriate Global tenant admin credentials to run remote PowerShell.

noteNote:
Cloud Connector deployment is only supported on the Microsoft Hyper-V virtualized platform. Other platforms, such as VMware and Amazon Web Services, are not supported.
noteNote:
The minimum hardware guidance to run Cloud Connector is based on basic hardware capacity (cores, MHz, gigabytes, and so on) with some buffer to accommodate intangible performance impairments buried in the architecture of any computer. Microsoft has run worst case load testing on commercially available hardware meeting the minimum guidance. Media quality and system performance are verified. Official Cloud Connector appliance partners of Microsoft have specific Cloud Connector hardware implementations on which they have independently tested performance and they stand by the suitability of their hardware to meet load and quality requirements.
noteNote:
Devices produced by AudioCodes and Sonus have modified code and run on Windows Server Standard edition of servers. These devices are supported.

Before you begin your deployment, you need to determine the size of your deployment, the SIP domains that are being serviced, and the configuration information for each PSTN site you plan to deploy. To begin, you will:

  • Identify all the SIP domains that will be served by this deployment based on the SIP URIs in use in your company.

  • Determine the number of PSTN sites that you need to deploy.

  • Ensure you have the hardware necessary to support the four VMs you'll be installing for each Cloud Connector Edition.

For each PSTN site you plan to deploy, you need to:

When defining media port ranges, be aware of the following:

  • Clients always use port range 50000 to 50019 for media traffic—this range is predefined in Skype for Business Online and cannot be changed.

  • The Mediation component, by default, will use port range 49 152 to 57 500 for media traffic. However, connection is established via internal firewall, and, for security reasons, you can limit this port range in your topology. You will need up to 4 ports per call. If you want to limit the number of ports between the Mediation component and the PSTN gateway, then you will also need to configure the corresponding port range on the gateway.

  • You should deploy Cloud Connector in a perimeter network. This means you will have two firewalls:

    • The first firewall is external between the internet and your perimeter network.

    • The second firewall is internal between the perimeter network and your internal network.

    Your clients can be in the internet or in the internal network:

    • Clients in the internet will connect to your PSTN via the external firewall through the Edge component.

    • Clients in the internal network will connect via the internal firewall to the Mediation component in the perimeter network, which will connect traffic to the SBC or PSTN gateway.

    This means you need to open ports in both firewalls.

The following tables describe the ports and port ranges for the external and internal firewalls.

This table shows the ports and port ranges for enabling communication between clients in the internal network and the Mediation component:

Internal firewall

Source IP

Destination IP

Source Port

Destination Port

Cloud Connector Mediation component

SBC/PSTN Gateway

Any

TCP 5060**

SBC/PSTN Gateway

Cloud Connector Mediation component

Any

TCP 5068/ TLS 5067

Cloud Connector Mediation component

SBC/PSTN Gateway

UDP 49 152 – 57 500

Any***

SBC/PSTN Gateway

Cloud Connector Mediation component

Any***

UDP 49 152 – 57 500

Cloud Connector Mediation component

Internal clients

TCP 49 152 – 57 500*

TCP 50,000-50,019

(Optional)

Cloud Connector Mediation component

Internal clients

UDP 49 152 – 57 500*

UDP 50,000-50,019

Internal clients

Cloud Connector Mediation component

TCP 50,000-50,019

TCP 49 152 – 57 500*

Internal clients

Cloud Connector Mediation component

UDP 50,000-50,019

UDP 49 152 -57 500*

* This is the default port range on the Mediation component. For optimal call flow, four ports per call are required.

** This port should be configured on the SBC/PSTN gateway; 5060 is an example. You can configure other ports on your SBC/PSTN gateway.

*** Note that you can also limit the port range on your SBC/Gateway if allowed by the SBC/Gateway manufacturer.

For security purposes, you can limit the port range for the Mediation component by using the Set-CsMediationServer cmdlet.

For example, the following command limits the number of ports that the Mediation component will use for media traffic to 50 000 – 51 000 for audio (in and out). The Mediation component will be able to handle 250 simultaneous calls with this configuration. Note that you also might want to limit this range on the SBC/PSTN gateway:

Set-CSMediationServer -Identity MediationServer:mspool.contoso.com -AudioPortStart 50000 - AudioPortCount 1000

To retrieve the name of the Mediation component and see default ports, you can use the Get-CsService cmdlet as follows:

Get-CsService -MediationServer | Select-Object Identity, AudioPortStart, AudioPortCount

The following table shows ports and port ranges for enabling communication between the Cloud Connector Edge component to the external firewall. This table shows a minimum recommendation.

In this case, all media traffic to the internet will flow via the Online Edge as follows: User end point-->Online Edge-->Cloud Connector Edge:

External firewall - minimum configuration

Source IP

Destination IP

Source port

Destination port

Any

Cloud Connector Edge External Interface

Any

TCP 5061

Cloud Connector Edge External Interface

Any

Any

TCP 5061

Cloud Connector Edge External Interface

Any

Any

TCP 80

Cloud Connector Edge External Interface

Any

Any

UDP 53

Cloud Connector Edge External Interface

Any

Any

TCP 53

Cloud Connector Edge External Interface

Any

UDP 3478

UDP 3478

Any

Cloud Connector Edge External Interface

TCP 50,000-59,999

TCP 443

Any

Cloud Connector Edge External Interface

UDP 3478

UDP 3478

Cloud Connector Edge External Interface

Any

TCP 50,000-59,999

TCP 443

The next table shows ports and port ranges for enabling communication between the Cloud Connector Edge component to the external firewall. This table shows the recommended solution.

In this case all media traffic for the end point in the internet can flow directly to the Cloud Connector Edge component. The media path will be User End Point -> Cloud Connector Edge.

noteNote:
This solution will not work if the user end point is behind a symmetric NAT.

External firewall - recommended configuration

Source IP

Destination IP

Source Port

Destination Port

Any

Cloud Connector Edge External Interface

Any

TCP 5061

Cloud Connector Edge External Interface

Any

Any

TCP 5061

Cloud Connector Edge External Interface

Any

Any

TCP 80

Cloud Connector Edge External Interface

Any

Any

UDP 53

Cloud Connector Edge External Interface

Any

Any

TCP 53

Cloud Connector Edge External Interface

Any

TCP 50,000-59,999

Any

Cloud Connector Edge External Interface

Any

UDP 3478; UDP 50,000-59,999

Any

Any

Cloud Connector Edge External Interface

Any

TCP 443; TCP 50,000-59,999

Any

Cloud Connector Edge External Interface

Any

UDP 3478; UDP 50,000 - 59,999

The Edge component needs to resolve the external names of Office 365 services and the internal names of other Cloud Connector components.

Each Edge component is a multi-homed computer with external and internal facing interfaces. Cloud Connector deploys DNS servers on the Domain Controller component within the perimeter network. You can point Edge Server to the DNS Server within the perimeter for all name resolutions, but you need to enable the Cloud Connector DNS Server to resolve external names by setting a DNS zone containing one or more DNS A records for external queries that refer name lookups to other public DNS servers.

In the .ini file, if you set the FQDN name for gateways from the same domain space as your SIP domain, the authoritative zone for this SIP domain will be created in the DNS Server within the perimeter. If Edge Server is pointed to this DNS Server to resolve names, Edge will never resolve the _sipfederationtls.<yourdomain> DNS record, which is required for call flow. In this case, Microsoft recommends that you provide a DNS Server on the Edge external interface to resolve Internet name lookups, and each Edge component should use a HOST file to resolve other Cloud Connector component names to IP addresses.

noteNote:
For security reasons, we recommend that you do not point the Cloud Connector DNS server to internal servers in the production domain for name resolution.

First you need to define the following common deployment parameters:

 

Item

Description

Notes

SIP domains

SIP URI’s in use by company users. Provide all SIP domains that will be served by this deployment. You can have more than one SIP domain.

 

Number of PSTN sites

The number of PSTN sites you will be deploying.

 

For each PSTN site you plan to deploy, you will need to gather the following information before you begin the deployment. You will need to provide this information when you update the CloudConnector.ini file.

When configuring gateway information, remember the following:

  • If you only have one gateway, remove the section in the .ini file for the second gateway. If there are more than two gateways, follow the existing format to add new ones.

  • Make sure the IP address and the port of the gateway(s) are correct.

  • To support PSTN gateway-level HA, keep the secondary gateway or add additional gateways.

(Optional) To restrict the outbound call numbers, update the LocalRoute value.

 

Site parameters

Description

Notes

Virtual machine domain name

Domain name for the internal components of Cloud Connector. This domain should be different from the production domain. The name can be the same across all Cloud Connector appliances.

Name in .ini file: “VirtualMachineDomain”

.local domain is preferred.

Cloud Connector domain controller name

Name of the domain controller.

Name in .ini file: “ServerName”

Must be 15 characters or less. Enter Netbios name only.

Cloud Connector domain controller IP/subnet mask

IP address of the domain controller.

Name in .ini file: “IP”

 

O365 Online service FQDNs

Should be the default in most cases for the world-wide O365 instance.

Name in .ini file: “OnlineSipFederationFqdn”

 

SiteName

Skype for Business site name; for example, Seattle.

Name in .ini file: “SiteName”

For Release 1.4.1 and later, site name must be different for each site and the name must match the PSTN site, if it exists, defined in Office 365. Note that PSTN sites will automatically be created when registering the first appliance in a site.

 

HardwareType

Release 1.4.1 and later

Type of hardware. The default value is Normal. You can also set to Minimum.

 

Country Code

Country Code for Dialing.

Name in .ini file: “CountryCode”

 

City

City (Optional).

Name in .ini file: “City”

 

State

State (Optional).

Name in .ini file: “State”

 

Base VM IP address

The IP address of the temporary base VM that will be used to create the VHDX for all Cloud Connector virtual machines. This IP should be in the same perimeter corporate network subnet defined in the next step and requires Internet access. Be sure to define the corporate default gateway and the DNS that is routable to the internet.

Name in .ini file: “BaseVMIP”

 

WSUSServer

WSUSStatusServer

Release 1.4.1 and later

The address of the Windows Server Update Services (WSUS)—an intranet server to host updates from Microsoft Update.

You can leave blank if WSUS is not needed.

 

Subnet mask for internal network

Cloud Connector configures an IP network for internal communication between Cloud Connector components. Edge also should be connected to another subnet which allows Internet connectivity.

Name in .ini file: “CorpnetIPPrefixLength” under “Parameters for a pool of VM network”

 

Subnet mask for external network

For the external network of the Edge component.

Name in .ini file: “InternetIPPrefix” under “Parameters for a pool of VM network”

 

Switch name for internal network

Name for switch that will be used for the internal Cloud Connector network.

In most cases the default suggested value can be used.

Name in .ini file: “CorpnetSwitchName” under “Parameters for a pool of VM network

 

Switch name for external network

Name for switch that will be used for the external Cloud Connector network.

In most cases the default suggested value can be used.

Name in .ini file: “InternetSwitchName” under “Parameters for a pool of VM network

 

Default Gateway for internal network

This gateway should provide access to the Internet (Internet also requires setting the DNS server) and will be configured on internal interfaces of Cloud Connector components.

Name in .ini file: “CorpnetDefaultGateway” under “Parameters for a pool of VM network

 

Default Gateway for external interface of Edge component

Will be configured on external interface of Edge component.

Name in .ini file: “InternetDefaultGateway” under “Parameters for a pool of VM network

 

DNS server for internal network

Will be configured on internal interface of temporary VM. Should provide name resolution for Internet names. Without providing a DNS server, internet connection will fail and deployment will not finish.

Name in .ini file: “CorpnetDNSIPAddress” under “Parameters for a pool of VM network

 

DNS Server for external interface of Edge component

Will be configured on external interface of Edge.

Name in .ini file: “InternetDNSIPAddress” under “Parameters for a pool of VM network

 

Management switch name

Management switch is a temporary switch that will be created automatically, and that will be used for configuration of Cloud Connector during the deployment. It will be disconnected automatically after the deployment. It should be a different subnet from any other networks used in Cloud Connector.

In most cases the default suggested value can be used.

Name in .ini file: “ManagementSwitchName” under “Parameters for a pool of VM network

 

Management subnet address/subnet mask

Management subnet is a temporary subnet that will be created automatically, and that will be used for configuration of Cloud Connector during the deployment. It will be removed automatically after the deployment. It should be a different subnet from any other networks used in Cloud Connector.

Names in .ini file: “ManagementIPPrefix” and “ManagementIPPrefixLength” under “Parameters for a pool of VM network

 

Central Management Store (CMS) Machine

Single FQDN used for Central Management Store (CMS). The AD Domain name will be used to generate the FQDN.

Name in .ini file: “ServerName” under “Parameters for Primary Central Management Service

Must be 15 characters or less. Enter Netbios name only.

(CMS Pool Name = Server Name)

CMS Machine IP address

IP address for CMS Server (internal in perimeter network).

Name in INI file: “IP” under “Parameters for Primary Central Management Service

 

File Share Name

File Share Name to be created on CMS server for Skype for Business replication data (for example, CmsFileStore).

In most cases the default suggested value can be used.

Name in .ini file: “CmsFileStore” under “Parameters for Primary Central Management Service

 

Mediation component Pool Name

Pool Name of Mediation component. Enter Netbios name only. The AD Domain name will be used to generate the FQDN.

Name in .ini file: “PoolName” under “Parameters for a pool of Mediation Servers”

Must be 15 characters or less. Enter Netbios name only.

Mediation component name

Component Name of Mediation component 1. Enter Netbios name only. The AD Domain name will be used to generate the FQDN.

Name in .ini file: “ServerName” under “Parameters for a pool of Mediation Servers”

Must be 15 characters or less. Enter Netbios name only.

Mediation component Machine IP address

Internal Corpnet IP for Mediation component (internal in perimeter network).

Name in .ini file: “IP” under “Parameters for a pool of Mediation Servers”

 

Edge pool internal name

Pool Name of Edge component. Enter Netbios name only. The AD Domain name will be used to generate the FQDN.

Name in .ini file: “InternalPoolName” under “Parameters for a pool of Edge Servers”

Must be 15 characters or less. Enter Netbios name only.

Edge Server internal name

Component Name of Edge component. Enter Netbios name only. The AD Domain name will be used to generate the FQDN.

Name in .ini file: “InternalServerName” under “Parameters for a pool of Edge Servers”

Must be 15 characters or less. Enter Netbios name only.

Edge server internal IP

Internal perimeter network IP of Edge component to communicate with other components of Cloud Connector.

Name in .ini file: “InternalServerIPs” under “Parameters for a pool of Edge Servers”

 

Access Pool External Name

Name of Access Edge; for example, AP. This name must match the name provided for the SSL certificate. Enter Netbios name only. The SIP Domain name will be used to generate the FQDN. One external pool name will be used for all Edge components in the pool. One Edge Access pool is required per PSTN site.

Name in .ini file: “ExternalSIPPoolName” under “Parameters for a pool of Edge Servers”

Must be 15 characters or less. Enter Netbios name only.

“sip” is reserved and therefore cannot be used as the name.

The generated FQDN name must match the name provided for the SSL certificate.

External IP of Access Edge

External IP of Edge component – either Public IP if no NAT is available, or translated IP (please specify both addresses if mapped).

Name in .ini file: “ExternalSIPIPs” under “Parameters for a pool of Edge Servers”

 

Media Relay name

Name of Audio Video Media Relay Edge; for example, MR. One external pool name will be used for all Edge components in a pool. One Edge Media Relay pool is required per PSTN site.

Name in .ini file: “ExternalMRFQDNPoolName” under “Parameters for a pool of Edge Servers”

Must be 15 characters or less. Enter Netbios name only.

External IP of Media Relay Edge

Currently only one IP is supported, so this will be the same IP as Access Edge, either public or mapped IP (please specify both addresses if mapped). Can be the same address as Edge component External IP of Access Edge. Note if Edge is behind NAT, you also need to specify the value for the next parameter.

Name in .ini file: “ExternalMRIPs” under “Parameters for a pool of Edge Servers”

 

External IP of Media Relay Edge (if Edge is behind NAT)

If your Edge is behind NAT you also need to specify the public address of the NAT device.

Name in .ini file: “ExternalMRPublicIPs” under “Parameters for a pool of Edge Servers”

 

Voice Gateway 1 Make and Model

Specify the make and model of the SBC/Voice gateway. Note that you can connect a device or SIP trunk from the list of tested devices at https://technet.Microsoft.com/UCOIP.

 

Voice Gateway 2 Make and Model (copy this row if you have more than 2 gateways)

Specify the make and model of Voice gateway. Note that you can connect a device from the list of tested devices at https://technet.Microsoft.com/UCOIP.

 

Voice Gateway 1 Name

Used to generate the machine FQDN with AD Domain. Required if TLS will be used between the Mediation component and Voice Gateway. If you do not plan to use FQDN—for example, TLS is not required or Voice Gateway doesn’t support connection using FQDN (only IP)—please specify.

 

Voice Gateway 2 Name (copy this row if you have more than 2 gateways)

Used to generate the machine FQDN with AD Domain. Required if TLS will be used between Mediation component and Voice Gateway. If you do not plan to use FQDN—for example, TLS is not required or Voice Gateway doesn’t support connection using FQDN (only IP)—please specify.

 

Voice Gateway 1 IP Address

IP Address of Voice Gateway.

 

Voice Gateway 2 IP Address (copy this row if you have more than 2 gateways)

IP Address of Voice Gateway.

 

Voice Gateway 1 Port # (copy this row if you have more than 2 gateways)

Port that the Voice Gateway SIP trunk will listen on, e.g. 5060.

 

Voice Gateway 2 Port #

Port that the Voice Gateway SIP trunk will listen on, e.g. 5060.

 

Voice Gateway 1 Protocol for SIP Traffic

TCP or TLS.

 

Voice Gateway 2 Protocol for SIP Traffic (copy this row if you have more than 2 gateways)

TCP or TLS.

 

External Media port range for traffic to and from Edge component

TCP/UDP port range for media traffic to and from external interface of edge. Must always start from 50 000. Refer to “Ports and Protocols” for more information.

50000 - 59 999

Media port range to communicate to/from the Mediation component via the internal firewall

UDP port range that the Mediation component will use to communicate to clients and gateways (recommendation 4 ports per call).

Media port range to communicate to/from Skype for Business client via internal firewall

For planning purposes, cannot be changed. Ports need to be opened in the internal firewall to communicate between Skype for Business clients within the internal network and with the Mediation component.

50 000- 50 019

Public Certificate password

Must be provided in the script.

 

Safe Mode Administrator Password

Safe mode administrator password for internal CC domain.

 

Cloud Connector Domain Administrator password

Password for Cloud Connector Domain Administrator (different from your production domain). User name is Administrator. You cannot change the user name.

 

Virtual Machines Administrator Password

Will be used to configure management network during the deployment.

User name is Administrator. You cannot change the user name.

 

Enable REFER support

This will define whether SIP REFER support is enabled or disabled on the Trunk Configuration to your IP/PBX. The default value is True. If your IP/PBX Gateway supports REFER support, please leave this as True. If it does not, this value needs to be changed to False. If you are not sure if your gateway supports REFER, please see Qualified IP-PBXs and Gateways.

 

Forward PAI

Release 1.4.1 only

Deprecated in release 1.4.2

Determines whether the PAI (P-Asserted-Identity) header field is forwarded from the Mediation Server to the gateways.

The value can be True or False. The default value is True.

 

Each Edge component requires a certificate from a public certification authority. Certificates must have an exportable private key to copy between Edge components. To meet the certificate requirements, you will need to decide between the following options and provide the Subject Name (SN) and Subject Alternative Name (SAN) for the certificate.

If you have a single SIP domain:

  • Option 1. The Subject Name should contain the pool name that you assigned to the Edge components. Note that the Subject Name cannot be sip.sipdomain.com because this name is reserved for the online Skype for Business Edge component. The SAN should contain sip.sipdomain.com and the access Edge pool name:

    SN = accessedgepoolnameforsite1.sipdomain.com, SAN = sip.sipdomain.com, 
    acessedgepoolnameforsite1.sipdomain.com 
    
    
  • Option 2. If you would like to use a single Wildcard certificate on all Edge pool servers you deploy, then you may use a wildcard SAN entry of *.sipdomain.com instead of the Edge pool name in the certificate. The subject name can be the access Edge pool name of any of the Edge pools that you have deployed:

    SN = accessedgepoolnameforsite1.sipdomain.com, SAN = sip.sipdomain.com, SAN = *.sipdomain.com
    
    
    noteNote:
    You must not create an external DNS entry for sip.<sipdomain>.com because this name belongs to the Office 365 deployment.
noteNote:
If you want to use a single certificate for all Edge pools deployed in your organization and cannot use a wildcard certificate as defined in option 2, then you will need to include the FQDN for all deployed Edge pools in the SAN name in the certificate.

If you have multiple SIP domains:

You will need to add sip.sipdomain.com for every SIP domain and the name of the access Edge pools per domain ( it can be one physical pool but with different names). Below is an example of SN and SAN entries in a multiple sip domain scenario:

  • Option 1. The Subject Name should contain the pool name that you assigned for Edge components. Note that the Subject Name cannot be sip.sipdomain.com because this name is reserved for the online Skype for Business Edge component. The SAN should contain sip.sipdomain.com and the access Edge pool name:

    SN = accessedgepoolnameforsite1.sipdomain1.com, SAN = sip.sipdomain1.com,
     sip.sipdomain2.com, acessedgepoolnameforsite1.sipdomain1.com 
    
    
  • Option 2.If you would like to use a single Wildcard certificate on all Edge pool servers you deploy, then you may use a wildcard SAN entry of *.sipdomain.com instead of the Edge pool name in the certificate. The subject name can be the access Edge pool name of any of the Edge pools that you have deployed:

    SN = accessedgepoolnameforsite1.sipdomain.com, SAN = sip.sipdomain1.com, sip.sipdomain2.com, SAN = *.sipdomain1.com 
    
    noteNote:
    You must not create an external DNS entry for sip.<sipdomain>.com because this name belongs to the Office 365 deployment.

For purposes of deployment, you can use the following table:

 

Option

Description

Notes

Which option will you use for your deployment?

Option 1 or 2

 

SN

Provide the SN for your certificate

 

SAN

Provides the SAN for your certificate

 

If you are using TLS between the gateway and the Mediation Server, you will need to obtain the Root Certificate, or full Certificate chain, for the certificate assigned to the gateway.

Generally, clients in hybrid voice mode can use two types of dial plans: an on-premises dial plan (if you deploy Cloud PBX with on-premises PSTN connectivity via an existing Skype for Business or Lync Server 2013 pool), or an online dial plan (which can be used with either Cloud PBX with on-premises PSTN connectivity via an existing Skype for Business or Lync Server 2013 pool or Cloud PBX with on-premises PSTN connectivity via Cloud Connector Edition).

Cloud Connector Edition does not have an on-premises dial plan because there is no registrar component deployed on premises. Therefore, when deploying Cloud PBX with on-premises PSTN Connectivity via Cloud Connector Edition, you must force the use of an online dial plan as follows:

Connect to your Skype for Business Online Remote PowerShell and run the following cmdlet:

Set-cstenanthybridconfiguration -tenant < TENANT ID > -useonpremdialplan $false

When you deploy Cloud Connector Edition for high availability, you deploy at least two appliances that act as a backup for each other. Each appliance consists of four components: Edge, Mediation, Central Management Store (CMS), and domain controller.

In general, if one component within an appliance goes down, Cloud Connector Edition can continue to handle calls, but you must consider the following:

  • Mediation, CMS, and domain controller component considerations

    Assume the CMS or domain controller component in one appliance goes down. The appliance can still handle inbound and outbound calls—but if you restart a Mediation component when the domain controller or CMS component is not reachable, mediation will not work. The same applies to restarting the CMS component when the domain controller is down.

    Recommendation: Before restarting components, check the availability of the other components in the appliance.

  • Edge component considerations

    If the Edge component in one appliance in not available, behavior for inbound and outbound calls will differ as follows:

    • Outbound call—a call from your user in the Internet to a PSTN network.

      The call distribution mechanism in the cloud will identify that one Edge component is down, and will route all calls to another appliance—so the outbound call is successful.

    • Inbound call—a call from the PSTN network to a user who is either in a local network or in the Internet.

      If the Edge component of the appliance that received the call is not working, the inbound calls to this appliance will not be successful because the Mediation component cannot redirect the call to the Edge component in the other appliance.

    Recommendation: Have a monitoring system in place. After you identify a malfunction of the Edge component, shut down all components in the appliance where the Edge component is not available.

Release 1.4.1 and later provides built-in monitoring and recovery. If you have not yet upgraded to 1.4.2, see Upgrade to a new version of Cloud Connector.

The following diagrams outline the flow of an outbound and inbound call through Cloud Connector Edition. This is useful information for understanding how connectivity is established and for troubleshooting connectivity issues.

In the first diagram, an internal user places an outbound call as follows:

  1. Dave, a user homed online, but now in the internal network, places a call to an external PSTN user.

  2. SIP traffic routes to Skype for Business Online.

  3. Skype for Business Online performs a Reverse Number Lookup of the number. The Reverse Number Lookup fails because this number does not belong to anyone in the Skype for Business organization.

  4. The call is routed to the Edge component (SIP and Media flow via Online Edge first; Media will go to the Mediation component via the internal firewall).

  5. If the route exists, the Edge component relays the traffic to the Mediation component in the perimeter network.

  6. The Mediation component sends the traffic to the PSTN gateway.

Outbound Media flow for Cloud Connector

In the next diagram, an internal user receives an inbound call as follows:

  1. The PSTN gateway receives a call for user Dave who is homed online, but now is in the internal network.

  2. SIP traffic is routed to the Mediation component.

  3. The Mediation component sends SIP traffic to the Edge component, and then it goes to Skype for Business Online.

  4. Skype for Business Online performs a Reverse Number Lookup of the number and finds that this is user Dave.

  5. SIP signaling goes to all Dave's points of presence.

  6. Media traffic will be established between the gateway and Mediation component and between the Mediation component and the end point.

Inbound Media Flow for Cloud Connector

Cloud Connector Edition release 1.4.2 includes bug fixes and enhancements, including new cmdlet functionality for managing Cloud Connector. This release will automatically update all Cloud Connector Edition 1.4.1 appliances that you have enabled for automatic update. Following are the enhancements and updates included with Cloud Connector 1.4.2:

  • Architecture changes to improve the deployment and management experience:

    • Introduction of pinpoint zones for the PSTN Gateway on the DNS Host A record on the Cloud Connector Active Directory DNS Server.

    • Edge is now part of the internal Cloud Connector virtual machine domain.

  • Improved certificate management, including support for multi-tier certificates. The external certificate can be issued from a third party certification authority whose root CA certificate and/or intermediate CA certificate are not trusted by Microsoft.

  • With the Set-CsExternalCertificateFilePath cmdlet, you can now provide a path for a PSTN Gateway/SBC certificate. This allows automatic import of this certificate to the Mediation Server during installation. It’s now required that you specify the -Target parameter when setting the path for the external Edge certificate. If TLS is configured between the Mediation Server and the gateway, then you should run this cmdlet a second time to specify the path to the PSTN Gateway certificate and the target MediationServer. For more information, see Set-CcExternalCertificateFilePath.

  • The Set-CsExternalCertificateFilePath cmdlet may also be used to import new certificates. In the case of the Edge certificate, the cmdlet will handle both importing and assigning the Edge certificate to the External Edge services. Note: This action will place the appliance in maintenance mode. For more information, see Set-CcExternalCertificateFilePath.

  • In addition to changes to the Set-CcExternalFilePath cmdlet, several new cmdlets are provided in release 1.4.2:

    • The Backup-CcCertificationAuthority cmdlet backs up the certification authority service to a file and saves to the CA folder under the site share directory.

    • The Export-CcRootCertificate cmdlet exports the Cloud Connector root certificate so that it can be imported to a PSTN Gateway/SBC.

    • The Renew-CcCACertificate cmdlet renews the Cloud Connector Root CA Certificate.

    • The Renew-CcServerCertificate cmdlet renews Cloud Connector server internally issued certificates.

    • The Remove- CcCertificationAuthorityFile cmdlet removes the certification authority service backup file in CA folder under site share directory.

    • The Remove-CcLegacyServerCertificate cmdlet removes old certificates that have been replaced, including Root and Intermediate certificates.

    • The Reset-CcCACertificate cmdlet resets the Cloud Connector Root CA Certificate which will remove the old certificate and replace with a new certificate.

    For more information, see Cloud Connector cmdlet reference.

  • Several bug fixes, including the following:

    • Resolved the issue where a PSTN call from a Skype for Business mobile client shows the wrong caller number in Cloud Connector.

    • Resolved the issue where a failure occurred during installation if the Domain Admin and Virtual Machine Admin credentials were different when confirming services running on Mediation Server and Edge Server.

    • Resolved the failure to input special characters, like the ampersand (&), often used in passwords.

 
Show: