Moving on with this series of deployment articles the next major component of the core Skype for Business (SfB) infrastructure to address is the Edge Server role.  This server role, from a deployment and architecture standpoint, is basically unchanged from previous Lync Server product releases.  These articles have all focused on a simple Skype for Business topology starting with a single Standard Edition server deployment.  The driving force for selecting that topology was primarily that the much-improved official documentation from Microsoft already covered the deployment of an Enterprise Edition Front End server pool.

For those following along with these deployment articles to create a lab environment then a simpler companion article entitled Skype for Business 2015 Edge Server Deployment is also available which quickly addresses adding a single Edge Server to this example environment.

But for this article a different, much more verbose approach has been taken.  The Server deployment article linked above only covers the unique, individual steps to quickly deploy an Edge Server in a lab with private certificates. This article covers in-depth best practices and explanations of each step along the way to deploying a pair of servers in an Edge Pool leveraging a more realistic scenario using public IP addresses and third-party certificates.  Basically this article is the production deployment reference guide and the other is the lab quick reference guide.  Nearly all of the guidance in this article related to network configuration and server preparation holds true for either scenario.

Background

A functional Front End server deployment is required before one or more Edge servers can be deployed into the environment.  This means successfully completing the configuration detailed in at least these three articles: Part 1, Part 2, and Part 3.  Note that following those articles verbatim only covers the deployment of a single Standard Edition Front End Server, which actually is sufficient to perform this deployment.  The Edge Server article mentioned above is meant for environments built specifically to those articles, while this article basically assumes that there is already at least one Skype for Business Enterprise Edition Front End Pool deployed in the environment.  But if desired, it is officially supported (albeit a bit unorthodox) to mix a resilient Edge Pool with a single Standard Edition Front End Server.

A Reverse Proxy solution is also not covered yet.  This role will be addressed after the completion of Edge server deployment, but leveraging some of the legacy behavior that is still supported in even the latest Skype for Business clients will allow for at a minimum of external connectivity from Windows Desktop clients and many IP desk phones.  To support the myriad of newer clients and platforms the Lyncdiscover service will need to be published using a reverse proxy model of some sort.  A future article will cover this topic in some capacity.

Two virtual servers will be used for this deployment and have already been installed with Windows Server 2012 R2 and prepared using the same methods as the other servers in the environment.  The key difference is that these two servers are located in a Perimeter Network or Demilitarized Zone (DMZ) and thus are not joined to the same Active Directory domain that the rest of the internally-located server roles are.  In fact these two new servers are not joined to any domain and are simply in the default Workgroup mode.

The network configuration used for this environment leverage the best practice model of two separate perimeter networks on different IP address subnetworks.  The internally-facing segment contains a dedicated internal private Class A IPv4 addressing scheme that is routed without the use of any Network Address Translation (NAT) to all of the internal servers.  The externally-facing perimeter network contains a fully-routable public IPv4 subnet.  The best practice approach of leveraging DNS Load Balancing will also be applied to this Edge pool, there will be no complicated Hardware Load Balancers (HLB) to address.


Preparation

Deploying an Edge Server is a complicated venture as it touches some of the most complex parts and concepts of networking in general.  This article by no means is intended to be a single reference on this topic but is meant to show at least one end-to-end deployment scenario by example.  Additional guidance and various accepted best practice guidance is also intermixed throughout where appropriate.  Any deviation from the example instructions warrants reading through the official Microsoft planning documentation to make sure that a supported, functional scenario is selected.

Also the details covered here in the preparation stage are reviewing an already staged environment, the actual Windows Server deployment and configuration steps will not be covered in detail here.  The various items required for the actual Edge Server role deployment are identified and outlined but basic Windows Server administration knowledge is assumed.

Network Configuration

The following diagram shows a typical network topology for a pair of Edge Servers.  Each server has two network interfaces which are connected to separate networks which cannot route traffic directly between them outside of the dual-homed Edge servers themselves.

image

  • The Public DMZ is using a full Class C with a natural subnet mask (this is a random network and the individual IP address were just made up for this example).  Each Edge Server has three individual public IP addresses assigned directly to a single external interface connected to this network.
  • The Private DMZ uses a reserved Class A segment with one IP address assigned to the internal interface on each Edge Server connected to this network.  

  • The Internal network includes a SfB Front End pool with three individual servers assigned one IP address per host in a naturally masked Class C network.  Also depicted is a pair of internal DNS servers assigned which will be leveraged by the Edge servers for resolving hosts in any network. (It is assumed this internal DNS server also handles requests for any public hosts by using root hints or forwarding.)

As covered in a various articles (like this) only a single default gateway should be defined on the server, and only on the external interface.  The default gateway setting on the internal interface must be left blank.  This insures that connections to undefined networks will always go out toward the Internet.  To allows these servers to find and communicate with internal hosts there is a standard accepted practice of defining static routes for all reserved subnet ranges to utilize the internal interface as the target route.

Understand that while IPv4 addresses in these ranges cannot be routed to the Internet there may be cases where some of these subnetworks are actually in use inside the external firewall.  So any connections to hosts on any subnets within these ranges which can only be reached via the external interface can be handled in one of two ways.  Either define only the internal networks that exist in the environment below instead of including the entire ranges, or use the configuration below to include all ranges and then add additional static route for the specific external networks and assign the external gateway as the destination for those custom routes..

  • To configure all private reserved networks as internally reachable then on each Edge Server run the following netsh commands as an administrator in the Windows Command Prompt or in PowerShell

netsh interface ipv4 add route 10.0.0.0/8 "Internal" 10.222.4.1
netsh interface ipv4 add route 172.16.0.0/12 "Internal" 10.222.4.1
netsh interface ipv4 add route 192.168.0.0/16 "Internal" 10.222.4.1

The ‘Internal’ string is unique to the server as it is the actual name of the network interface.  This name can be found in the Network Connections properties or by using the ‘netsh interface ipv4 show interfaces’ command.

  • To validate that the above commands completed successfully use the following netsh command to list all defined persistent routes.

PS C:\> netsh interface ipv4 show route store=persistent

Publish  Type      Metric    Prefix               Idx  Gateway/Interface Name
——-  ——–  ——-   ——————-  —  ———————-
Yes      Other     100       10.0.0.0/8             0  10.222.4.1
Yes      Other     100       192.168.0.0/16         0  10.222.4.1
Yes      Other     100       192.16.0.0/12          0  10.222.4.1

Yes      Other     Default   0.0.0.0/0             15  240.42.5.1

The default gateway that was configured on the external interface will be displayed in this list but is identified with a Metric value of Default.  The three other entries highlighted above reflect the three static routes used to locate any hosts which might be on the reserved IPv4 address ranges which are not routable over the public Internet.

DNS Configuration

With the prerequisite IP addresses already configured on the Edge servers then the next step is to select Fully Qualified Domain Names (FQDN) to be used in the deployment and then create the required DNS records. This is a good step to perform early as when dealing with public DNS servers it can take several hours for these requests to be created and propagate throughout the Internet.

As shown in the diagram each Edge server is assigned 4 unique IP addresses, three on the external network and one on the internal network.  These address will be assigned to separate server roles as shown in the following table.

External DNS Records
Type FQDN IP Address Host Service Purpose
A sip.jdskype.net 242.42.5.104
242.42.5.107
Access Edge Service
A webconf.jdskype.net 242.42.5.105
242.42.5.108
Web Conferencing Service
A av.jdskype.net 242.42.5.106
242.42.5.109
A/V Edge Service
SRV _sip._tls.jdskype.net sip.jdskype.net 443 Client Autodiscover (Legacy)
SRV _sipfederationtls._tcp.jdskype.net sip.jdskype.net 5061 Open Federation
SRV _xmpp-server._tcp.jdskype.net sip.jdskype.net 5269 XMPP Gateway Service
  • These records are to be added to a publically available DNS server available on the Internet.
  • The Host (A) records highlighted in blue are mandatory and their creation is critical to providing the functionality of each external Edge service.  The FQDN values selected for are commonly used suggestions but are not requirements.  It is a best practice to utilize ‘sip’ for the Access Edge record but a different name can be selected if desired as well as for the other roles.

  • The Service Locater (SRV) records highlighted in green are optional but if created their names must be used in the exact format shown above and cannot be altered or they will not provide the designed functionality.  It is still a best practice to deploy the autodiscover record to support and clients and device which do not yet utilize the Lyncdiscover process.  More importantly for this specific article is that because there is no reverse proxy deployed yet then the web-based Lyncdiscover process will not yet be available to external clients, meaning that they must use the legacy fallback discovery process in order to successfully register.  The other service records can be created or omitted based on whether Open Federation and/or XMPP discovery is desired.
Internal DNS Records
Type FQDN IP Address Purpose
A edge1.jdskype.net 10.222.4.204 Internal Edge Server Interface
A edge2.jdskype.net 10.222.4.207 Internal Edge Server Interface
A edgepool.jdskype.net 10.222.4.204
10.222.4.207
Internal Edge Pool
A dc1.jdskype.net 192.168.0.100 Internal DNS Server
A dc2.jdskype.net 192.168.0.101 Internal DNS Server
A fe1.jdskype.net 192.168.0.151 Internal Front End Server
A fe2.jdskype.net 192.168.0.152 Internal Front End Server
A fe3.jdskype.net 192.168.0.153 Internal Front End Server
  • The records in the top three rows are to be added to the internal DNS server which houses records for both the Internal network zone and the Private DMZ zone.
  • Because the Edge servers are not domain joined then the server host records will not typically be created automatically via Dynamic DNS, so it is common to create these server records manually in the internal DNS zone that the rest of the SfB and Active Directory servers also utilize.

  • The bottom rows highlighted in gray are only in included for reference and will not need to be created manually. These host records for the DNS and Front End servers will already be in the internal DNS database due to the Dynamic DNS behavior of domain-member servers. 

Firewall Configuration

Now that the servers are properly configured on the network then next critical task is getting the proper ports and protocols opened on each firewall.  The critical steps are making sure that the internal firewall will allow the needed communication between the internal Edge interface and all Front End server(s).  This previous article outlines in detail the traffic requirement for Lync Server 2010.  Skype for Business Server 2015 includes some new services which add to the list of needed ports and protocols so those unique items will be addressed below.  Otherwise the rest of that article still applies and can be used as a resource for understanding and troubleshooting port connectivity.

The following diagram depicts the required ports and protocols used by the Skype for Business 2015 Edge Server.  To keep things simple on the actual port numbers and network protocols are shown, more detail on what type of traffic is carried over these lines of communication will be cover shortly.

image

The following tables will incorporate the rules above along with the example IP addresses assigned to each server role to show an completed table that outlines all of the specific rules needed.  The individual table rows are color-coded to match the separate lines in the diagram above to assist matching up the different rules.

External Rules
Server
Role
Source
IP
Source
Port
Protocol Destination Port Destination
IPs
Communication
Type
Direction
Access Edge Any Any TCP 443 242.42.5.104
242.42.5.107
External client SIP signaling Inbound
Access Edge 242.42.5.104
242.42.5.107
Any TCP 443 Any Skype Consumer Directory Search Outbound
Access Edge Any Any TCP 5061 242.42.5.104
242.42.5.107
Federation SIP signaling Inbound
Access Edge 242.42.5.104
242.42.5.107
Any TCP 5061 Any Federation SIP signaling Outbound
Access Edge Any Any TCP 5269 242.42.5.104
242.42.5.107
XMPP Proxy service Inbound
Access Edge 242.42.5.104
242.42.5.107
Any TCP 5269 Any XMPP Proxy service Outbound
Windows OS 242.42.5.104
242.42.5.107
Any TCP 53 Any Queries to external DNS servers Outbound
Windows OS 242.42.5.104
242.42.5.107
Any TCP 80 Any Certificate validation and revocation checking (CRL) Outbound
Web Conf Edge Any Any TCP 443 242.42.5.105
242.42.5.108
External client/server Web Conferencing data Inbound
A/V Edge Any Any UDP 3478 242.42.5.106
242.42.5.109
External client/server media Inbound
A/V Edge 242.42.5.106
242.42.5.109
Any UDP 3478 Any External client/server media Outbound
A/V Edge Any Any TCP 443 242.42.5.106
242.42.5.109
External client/server media Inbound
A/V Edge 242.42.5.106
242.42.5.109
Any TCP 443 Any External client/server media Outbound
A/V Edge Any Any TCP 50000-59999 242.42.5.106
242.42.5.109
External client/server media Inbound
A/V Edge 242.42.5.106
242.42.5.109
Any TCP 50000-59999 Any External client/server media Outbound
Internal Rules
Server
Role
Source
IP
Source
Port
Protocol Destination
Port
Destination
IP
Communication
Type
Direction
Internal Edge 10.222.4.204
10.222.4.207
Any TCP 5061 192.168.0.151
192.168.0.152
192.168.0.153
Server-to-Server MTLS Inbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 5061 10.222.4.204
10.222.4.207
Server-to-Server MTLS Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 5062 10.222.4.204
10.222.4.207
Media Relay Authentication Service Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 4443 10.222.4.204
10.222.4.207
CMS Replication Service
Skype Consumer Directory Search
Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 23456 10.222.4.204
10.222.4.207
XMPP Proxy Service Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 50001-50003 10.222.4.204
10.222.4.207
Centralized Logging Service Outbound
Internal Edge 192.168.0.151
192.168.0.152
192.168.0.153
Any TCP 8057 10.222.4.204
10.222.4.207
Internal client/server Web Conferencing data Outbound
Windows OS 10.222.4.204
10.222.4.207
Any TCP 53 192.168.0.100
192.168.0.101
Queries to internal DNS servers Inbound
Internal Edge Any Any UDP 3478 10.222.4.204
10.222.4.207
Internal client/server media Outbound
Internal Edge Any Any TCP 443 10.222.4.204
10.222.4.207
Internal client/server media Outbound

The following clarifications and observations can be made about the information shown above:

  • Solid lines denote required items.  Excluding any of these from the firewall configuration can result in partial to no connectivity. Dashed lines indicate optional rules.  For the purposes of this article only the XMPP gateway services are identified as optional, as this is not a common deployed feature and will not be part of this deployment.  All other capabilities provided by the Access Edge service will be desired in most if not all deployments.
  • Traffic labeled as Inbound is always from the Internet to the Internal network (left to right on the diagram), and outbound is the reverse direction. It should not be visualized as the Edge Server being the center of focus.

  • The gray lines labeled as TCP 53 and 80 are simply indicating that the Edge server will need the ability to (1) query external DNS servers on the Internet to successfully perform autodiscovery processes for establishing open federation communications, and (2) download the Certificate Revocation Lists (CRL) hosted by trusted third party certificate authorities as part of TLS and MTLS communication setup.  These are commonly used ports for any type of server and these types of outbound connections to the Internet are typically open already allowed.  In the case they are not then they need to be included as part of the firewall configuration for each Edge server.

  • Pay special attention to the arrowheads as these indicate which types of communication are bidirectional which often require the creation of two separate rules in most firewall policies.  Notice that in the internal side with the exception of 5061 TCP all traffic is all coming from the internal network to the Edge server.  The Edge server does not need to initiate new connections to any internal hosts other then for server-to-server MTLS communications over port 5061. On the external side of the coin it’s a completely different story as nearly all of the rules require inbound and outbound connections to be allowed.  This has more to do with the fact that the external side is made up of external clients and federated servers.

  • All rules on the external side typically are setup to allow traffic in from any IP and to be established outbound to any IP.  For the set of internal rules the allowed sources and destinations depend on the type of traffic.  For a detailed list of which ports and used by Front End servers, Director servers, and/or Survivable Branch Appliances (SBA) see the official Microsoft documentation.  For the purposes of this deployment there is only the single Front End server and not directors or SBAs.

  • In some environments it is normal to see all outbound connections from more trusted networks to less trusted networks to be allowed by an existing policy.  In these cases that means only the rules denoted as Inbound would need to be configured in the firewall as all outbound traffic would already be allowed..  For example on the internal side of the diagram only inbound rules for 5061 TCP to internal SfB servers and. 53 TCP to internal DNS servers would be needed.

  • This topic has been figuratively beaten to death but it still warrants a brief note.  The range of 10,000 ports (50,000-59,999) used by the A/V Edge service is still a best practice to allow outbound (at minimum).  Realistically it is still opened bi-directionally but these are not active listening ports.  A few of them are dynamically opened at the exact time an ICE client needs to relay media and this is done securely.  The one exception here is that ports 50001, 50002, and 50003, which are used by the Centralized Logging Service (CLS) is programmed to actively listen on these ports.  Unfortunately on an Edge server this service will open these listening ports on both interfaces, meaning that those 3 of the 10,000 ports opened from the Internet to the Edge external interface will be actively listening. The workarounds are either to limit the open inbound range to 50004 and above, or block those external ports directly on the server as outlined in this blog article from fellow Skype for Business MVP James Cussen.

  • With one exception all traffic types are transported as TCP.  The only rules that can utilize UDP are for handling audio and video streams.  All A/V media connections will prefer to use UDP for delivery and only fall-back to TCP if a UDP connection is unsuccessful.  Application sharing media (RDP) is limited to using TCP only.

  • All ports labeled on the diagram are destination ports.  When traffic in either direction is to be established it will leave from a dynamically assigned random high port on the source host, headed for the specific listening port on the destination host.  This is why all source ports are listed as ‘Any’ in the table above.

Using the diagrams and details above should provide a clearer picture of exactly what ports are used to carry what types of data and where that traffic needs to flow between.

Certificate Configuration

Deploying Edge servers typically involves purchasing at least one certificate from a public Certificate Authority (CA) which is usually not an immediate process. Thus it is ideal to have a defined plan before starting the actual server deployment and in some cases even perform the requests to third party CAs several days in advance.

An older article on Lync Edge Serve Best Practices covers a lot of detail on how to select and configure certificates, nearly all of which is still unchanged since Lync 2010.  The last section on Edge Pools outlines the requirement that a single standard SSL certificate, with no SAN field and only the pool FQDN (not the server FQDN) is used for the internal Edge role.  This is one of the more commonly misunderstood requirements in multiple server Edge pool deployments.

There are two different certificates which need to be created for application to the new Edge Server:

  • A single SSL certificate will be requested from a private internal Windows Enterprise CA during the deployment.
  • A single SSL UC certificate will be requested from a public third party trusted CA.

Because the internal certificate will be issued by an Windows AD-integrated Enterprise CA this process can be started as part of the environment preparation in a simpler method than using the certificate wizard on the Edge server itself.  The external certificate request will be addressed later in this article but it can also be performed ahead of time as the desired configuration is already known.

  • Connect to the existing SfB Front End server and launch Internet Information Service Manager (inetmgr.exe) and then highlight the local server object.
  • Open the Server Certificates feature listed under the IIS group.

  • Select the Create Domain Certificate action and then enter the Edge Pool FQDN as the Common Name (e.g. edgepool.jdskype.net).  Fill out the remaining fields as desired.

image

As mentioned above this certificate which will be bound to the Internal Edge service on both servers must contain only the shared pool name.  Unlike a Front End server, the individual Edge server hostname should not be included on the certificate.  (This concept is discussed in more detail in this article.)  By contrast If this was a single standalone Edge server then the server’s own hostname would be used here, but not when dealing with multiple computer pools.  Other server and clients communicating with Edge Servers in a pool need to be presented the exact same certificate by either server as to not break the secure communications channel during an Edge server failure event.

  • On the next window use the Select button to enter the desired AD-integrated Enterprise CA (e.g. jdskype-RootCA\DC.jdskype.net) and then enter a descriptive Friendly Name for the new certificate (.e.g. Internal Edge Pool Cert).

image

  • Click Finish to perform an immediate online request, which once successful will also automatically import the certificate into the local server and pair it with the private key.

While IIS Manager is a great tool for creating quick basic SSL certificates it is not ideal for exporting these certificates as it will not include the CA chain.  To export the certificate so that it can be easily imported in the Edge Server a different tool should be used.

  • On the same server open a new Microsoft Management Console (mmc.exe) window and select File > Add/Remove Snap-in.
  • Add the Certificates snap-in and  then select Computer account.

image

  • Select Next, Finish, and then OK to return to the main console window.
  • Expand Certificates (Local Computer) > Personal > Certificates and then highlight the certificate which was just created (e.g. edgepool.jdskype.net).

image

  • Select Action > All Tasks > Export to open the Certificate Export Wizard.
  • Select Yes, export the private key on the Export Private Key page.

image

The previous step is critical as without the private key as part of the export then the certificate would be useless on the Edge Server.  As of equal importance is the next step which ensures that the Root CA’s public certificate is also included in the export file as the Edge servers do not currently trust the internal CA as they are not part of the internal AD domain.

  • Leave the default settings on the Export File Format page but ensure that the Include all certificates in the certification path if possible option is enabled.

image

As this export file will include the all-important private key portion of this certificate then it must be secured.  Because it will be copied to computers that are not domain members then the Group or user names option cannot be selected.  A password must be created and set on this export file.

  • Enter and confirm a password (e.g. password) to protect this export file.

image

  • Select a name and location to save the file (e.g. C:\Temp\internaledge.pfx)

image

  • Click Finish to complete the export wizard and then copy this file to both of the Edge Servers.  The certificate will be imported into the server’s store in a later step.

Configuration

At this point the core Windows Server is prepared and ready for the SfB installation to begin.  Just as with any other server role the first step in the deployment is updating the Topology.  But where this server role differs is how that is performed.  With all other internal server roles these are places on domain member servers which typically will have network access to the existing servers, meaning that during the actual server installation the SfB Central Management Store is reachable.

But when looking at the traffic rules above there is no path opened for the replication service to reach the internal servers.  Because the database replication model is push-only for Edge servers then that is why the 4443 TCP entry is only outbound.  This means that during the initial Edge Server deployment the topology information will need to be manually imported into the Edge Server.  This process is covered in the steps below, but otherwise the deployment process of this server is very much like any other SfB server.

Define Edge Pool

  • Open the Skype for Business Server Topology Builder tool on the existing SfB Front End server, then download and save the current topology to a text file.
  • Navigate to the desired site, expand the Skype for Business 2015 container, highlight Edge Pools and then select the New Edge Pool action. 

  • Enter the desired Pool FQDN (e.g. edgepool.jdskype.net) and then select either option to create a multiple server or single server pool.  As explained at the front of this article a multiple computer pool will be covered in this configuration.

image

  • On the Enable Federation window select desired options  In this example only Lync/SfB Federation will be configured.  Skype consumer search capabilities will be added later and potentially addressed in a future article.  As mentioned earlier the XMPP gateway will not be used.

image

  • Do not enable the option to Use a single FQDN and IP address as multiple Edge servers and separate dedicated IP addresses have already been allocated for this deployment.

image

  • For this deployment only IPv4 addresses will be utilized, and there will be no Network Address Translation (NAT) used as the Edge server’s external interfaces have public IP addresses bound directly to them.

image

  • In the External FQDNs window enter the previously selected hostnames (e.g. sip.jdskype.net, webconf.jdskype.net, av.jdskype.net) for each of the three external Edge services, retaining the default port selection of 443 for each.

image

  • At the Define the computers in this pool window click Add to launch the Add server to Edge pool wizard.
  • Enter the Internal IPv4 address and FQDN of the first Edge server and then click Next.

image

  • Enter the three External IPv4 addresses in the proper field for each service and then click Finish.

image

  • Repeat the two steps above and enter the unique information for the second Edge server.  When complete the Define New Edge Pool window should include two entries as shown below.  Click Next to advance.

image

  • Select the desired Next hop pool from the drop-down menu (e.g. fe.jdskype.net).
  • At the Associate Front End or Mediation Pools step select the desired Front End server or pool, which in most cases is the same as what was just selected in the previous step (e.g. fe.jdskype.net).

Publish Topology

Now that the new pool has been created the next step is to save and publish these changes to the Central Management Store.

  • In Topology Builder expand the newly created Edge Pool and double-check the configuration on the pool and each computer object to make sure there are no mistakes.
  • From the Action menu select Topology > Publish to launch the Publish Topology wizard.  If all goes as planned then the result should be reported as successful on all steps.

image

Enable External Access

While the majority of the environment preparation is handled in the topology this is a critical step which must be performed before any external communications will be allowed.  The three major types of communications supported by the Access Edge service are Remote User Access, Federated User Access, and Public Provider Access.  To enable one or more of these feature follow these example steps.

At minimum remote user access will be enabled in order to later test Edge functionality by attempting to sign in externally, via the Edge Server, with a Skype for Business enabled user account.

  • Using the Skype for Business Server Control Panel browse to the Federation and External Access section
  • Under the External Access Policy page open the default Global policy and check the Enable communications with remote users option.

image

Going back to the introduction of the Edge Server this functionality has always been poorly named.  Reading that option as it is written makes it seem like it controls the ability for externally registered users to communicate with internally registered users, which is completely incorrect.  This feature really should be called “Enable external user registration” as that is exactly what it does.

  • If federation and public IM connectivity are also desired then these options can also be selected, but will not be addressed in this article.

Note that steps above are the simplest way to enable these features for use with all users in the environment.  If a more granular approach is preferred then it is recommended to instead create new User or Site Policies and then users can be enabled automatically by their site association or by manually assigning them to the newly created policy.

  • Save the changes and the main window should now reflect the desired external access policy settings.

image

That first step simple enables the policy to allow these types of communications in the environment.  Next the actual Edge server configuration must also be defined to handle these actions.

  • Under the Access Edge Configuration page open the default Global policy and check the Enable remote user access option.  If federation was also enabled in the previous policy then make sure to enable the desired, related settings here as well.

image

  • Save the changes and the main window should now reflect the desired Access Edge configuration.

image

Export Topology

As briefly discussed earlier the Edge server deployment will require that the topology, which now includes the new configuration steps performed in this section, to be manually exported and imported on each Edge server.  During the deployment of these servers they do not have the ability to directly access the internally-stored configuration information so it must be provided manually during deployment.  The following steps will prepare this data for use in the later server installation process.

  • Using the Skype for Business Management Shell run the following Export-CsConfiguration cmdlet to export.

Export-CsConfiguration -FileName c:\temp\topo.zip

image_thumb86_thumb

  • Copy the exported file (e.g. topo.zip) and save it to a convenient location on both Edge servers for use later in this article.

Deployment

As with any Windows servers which will have SfB server components installed there are various prerequisite packages which must be installed or enabled first.

Add Server Features

The Windows 2012 R2 operating system used on these servers already includes some of the require components by default (like PowerShell 3.0), but as the Edge server does not contain any web service components then IIS subcomponents will not be installed on these servers.

  • If the server does not have Internet connectivity then mount the Windows Server 2012 installation media on the server to an available drive letter as some of the components to be installed will need to be read from the installation media as provided by the Source parameter in the following cmdlet (e.g. D:\sources\sxs).
  • Launch Windows PowerShell by selecting ‘Run As Administrator’ and enter the following cmdlet to quickly install the .NET Framework package, the Remote Server Administrative Tools, and all additional prerequisites followed immediately by a required server reboot.  (The Telnet client is also installed as it helpful for testing/troubleshooting port connectivity issues with the Edge server.)

Add-WindowsFeature RSAT-ADDS, NET-Framework-Core, NET-Framework-45-Core, NET-Framework-45-ASPNET,  Web-Net-Ext45, NET-WCF-HTTP-Activation45, Windows-Identity-Foundation, Telnet-Client –Source D:\sources\sxs

image

After installing these components make sure to run Windows Update to apply any new .NET 3.5 and 4.5.2 updates.  At the time of posting this article .NET Framework 4.6.1 is not supported for use with Skype for Business Server so make sure to avoid installing that update.  If that package has already been mistakenly updated then this article shows how to remove it before.performing advancing further.

  • Run Windows Update and hide the package for Microsoft .NET Framework 4.6.1 for Windows Server 2012 R2 for x64 (KB3102467).
  • Install any other pending recommended updates.

Validate Hostname

Another critical step that is sometimes missed when deploying Edge servers is configuring the local computer name correctly.  The server hostnames have all been shown as FQDN so far but by default a Windows server that is not joined to a domain will not be configured as such.  If an administrator does not manually configure the FQDN on the server then the deployment steps in the next section will not do anything because the local server hostname (e.g. edge1) does not match anything in the imported topology (e.g. edge1.jdskype.net).

  • To configure/validate that the proper FQDN on the Edge Server open Server Manager and then select Local Server.
  • Click on the Computer Name value (e.g.edge1) to open the System Properties window.  Click Change.

If the Full Computer Name looks like the example below then this will need to be fixed to include the proper FQDN.

image

  • Click the More button and then enter the proper DNS domain and suffix in the field shown below and save the change.

image

Now the desired FQDN should appear as the Full computer name.  Save this configuration and reboot the server to apply the new hostname.

image

Install Server Components

The steps in this section address the installation of the actual SfB Server components using the deployment wizard.  These steps can be performed on both servers simultaneously or one server at a time.

  • Mount the Skype for Business Server 2015 installation media on the first Edge server and then open the mounted drive to trigger autoplay of the deployment wizard.

The deployment wizard will automatically (if needed) install Visual C++ 2013.

image

  • When that package installation is complete then select the option at the next window to skip checking for any updates. Leave the default Installation Location.  Click Install to advance.

image

  • Accept the licensing agreement and then wait while the deployment wizard automatically installs the Core Components.

image

Install Local Configuration Store

  • Once the main screen appears select the option to Install or Update Skype for Business Server System.
  • On the Install or update member system window click Run on Step 1: Install Local Configuration Store.

  • The next window will be limited to a single option because this server is not a member of any Active Directory domain.  Browse to the location where the exported topology file (e.g. topo.zip) was copied to in the previous section and click Next.

image

The local configuration store installation process will begin immediately by loading the local installation files and then performing a check against the various prerequisite components currently installed on the server.  Assuming none of the prerequisites are missing and no problems occur with the installation of the SQL Express components then after some time that Task Status should be reported as Completed.

image

Install Server Components

  • Return to the Install or update member system window and click Run on Step 2: Setup or Remove for Business Server Components.

image

This concludes the server components installation process and all that remains is to setup the SSL certificates before the individual services can be started and tested.

Import Internal Certificate

The internal Edge certificate which was created during the preparation steps at the beginning of this article will now be imported into the Edge servers.

  • Click Run on Step 3: Request, Install, or Assign Certificates to launch the Certificate Wizard.
  • Click the Import Certificate button and then enter the location of and the password for the export file that was created earlier on the Front End server and then copied to this Edge server.

image

  • On the Import Certificate Summary page confirm that the Contains Private Key value is displayed as True, indicating that the import file is a complete certificate, and then click Next to complete the process.

If completed successfully then the wizard will have imported the certificate, its private key, and the CA chain (in this case a single Root CA certificate) into the local server.  The wizard will place the certificate in the proper place in the local repository so how any certificates issued by the internal CA will be trusted by this computer.

Assign Internal Certificate

Now that the certificate has been imported into the Windows server it can be selected by the SfB deployment wizard and assigned to the appropriate service.

  • Highlight the Edge internal section of the Certificate Wizard and then click Assign.

image

  • Select the newly imported certificate (e.g. Internal Edge Pool Cert) which might very well be the only certificate option shown on the server at this point.
  • Advance to the Certificate Assignment Summary page and confirm that the Certificate Use is reported as Edge internal.

image

  • Complete the wizard and verify that the Task Status is reported as Completed.

image

  • Return to the Certificate Wizard’s main window to verify that the certificate is now reported as assigned to the Edge Internal service.

image

Request External Certificate

For the external certificate an offline request will be issued against a third party certificate authority.  Where IIS was previously used on a different server to create the internal interface the external certificate will instead be dealt with directly on the Edge server using the SfB Deployment Wizard.

  • On the Certificate Wizard home screen highlight the External Edge certificate (public Internet) section of the Certificate Wizard and then click Request.

image

  • Select the option to Prepare the request now, but send tit later (offline certificate request).

  • Enter a path to save the certificate signing request file that this process will create (e.g. C:\Temp\externaledge.req).

  • Do not enable the option to use an alternate template; the default Web Server SSL certificate templates used by any third party CA is desired for this request.

  • Enter a descriptive Friendly Name (e.g. External Edge Pool Cert) and leave the Bit Length at 2048.  Insure that the option to Mark the certificate’s private key as exportable is enabled as this is a critical step!  If this certificate’s private key cannot be extracted from the first Edge server then it cannot be copied to the second Edge server.

image

All Edge servers must have the exact same certificate installed on the external interfaces to function properly, they cannot use separately issued certificates even if the user-defined fields are set to the same values.  The certificates keys would not be the same and thus communications between the pool and various client connections would be adversely impacted

  • Enter the desired Organization and Geographical information in the next two windows.
  • The Subject Name (SN) and Subject Alternative Name (SAN) fields should already be populated with the external FQDNs which were defined earlier in the topology (e.g. sip.jdskype.net and webconf.jdskype.net), These names were included of the configuration data initially provided to this Edge server with the topology export file.

image

Note that the SN value is duplicated in the SAN field as this is an accepted best practice for all SSL certificates.  Make sure to be aware of this as some third party CAs will charge more for each individual SAN entry that is to be included on the certificate.

  • Leave the default settings for the remaining steps and complete the wizard.

At this point the certificate request data is saved in the specific .req file and can be submitted to a third party CA.

  • The following example shows requesting a SAN certificate from DigiCert by directly submitting the CSR data.

image

  • Submit the request and when the certificate file is provided from the CA then use the Import Certificate button on the SfB Certificate Wizard home screen to install the new server certificate as well as import the chain that may be provided from the CA.
  • Once imported then the new public certificate highlight the External Edge certificate (public Internet) section and then click Assign.

Start Services

The final step is to start the SfB Edge Server services.  The new Start-CsPool cmdlet provided in SfB Server 2015 only applies to Front End pools and cannot be used with Edge Servers.  Thus the services can either be started manually or the server can be rebooted to leverage the automatic startup procedure.

  • Restart the Edge server and when it comes back online monitor the status of the individual services to validate that all have started successfully.

image_thumb22

By Jeff Schertz

Site Administrator

113 thoughts on “Skype for Business 2015 Edge Pool Deployment”
  1. Great in-depth article and consolidation of useful information – Thanks Jeff!

    After carefully following all of these steps and double checking the work, including the use of a couple of MySkypeLab tools (Port Tester & DNS/IPRoute Tester), our edges are not receiving CMS replications.

    Here’s the rub – we are in a side-by-side migration scenario (Lync2010–>S4B2015) and the CMS is still on the 2010 FE.

    Is there anything in particular we need to configure to accommodate this? It’s been very difficult to find articles that discuss the intricacies of migration, especially testing and troubleshooting.

    Any guidance is appreciated.

  2. Hi Jeff,
    my be you can help me, I install S4B but cannot create Group or Queue in “Response Group” section.

    Error: No workflows are assigned to current manager.

    I already in security groups: CSResponsegroupAdministrator and CSResponseGroupManager.

    P.S. via PowerShell i can create this group.

  3. Jeff – it appears your External Firewall Rules table is incorrect. In particular, the WebConf and A/V sections. You have everything routing to the Access Edge IPs (242.42.5.104 & .107) and not to the WebConf and A/V IPs (242.42.5.105 & .108 and 242.42.5.106 & .109).
    For example, A/V Edge TCP 50000-59999 Inbound should route to 242.42.5.106 & .109, not to 242.42.5.104 & .107.

  4. Hi Jeff,
    would if we have two remote sites accessible through two different DMZs?
    Could we imagine two different edge pools, one for each DMZ? pointing to one single front end pool?
    Many thanks
    Melanie

  5. External FQDNs are configured as sip.jdskype.net, webconf.jdskype.net and av.jdskype.net.
    But External Certificate SAN with only sip.jdskype.net and webconf.jdskype.net.

    What about av.jdskype.net? Shouldn’t that be included in the Certificate too?

    Huge thanks for the whole blog!

  6. Thanks for the very detailed info.
    One question about the external traffic / firewall settings.
    Let’s assume the AccessEdge/WebConf/AV services are configured to use one IP address and different (not default 443) ports.
    External inbound traffic for A/V shall use this port instead of 443 (assume it is 995), that I understand.
    But what about the external outbound traffic?
    Should it be (as in your case above) IP 242.42.5.104/107 port Any to IP Any port 443?
    Or IP 242.42.5.104/107 port 995 to IP Any port Any?

    Also shouldn’t DNS queries be UDP?

    FW settings for Lync/SfB were always somehow complicated for me 😉
    TIA

    1. Outbound traffic can come from randomly selected ports on the server so you are only dealing with destination ports here. The inbound rule would need changed to 995 as you state, but the outbound rule would need to stay at 443 as that is the ports that everyone else’s Edge Servers would use.

  7. Hey Jeff,
    Quick question how would I handle certs and names in the case of split DNS?
    I have it working internally.

  8. hmmmm, am just speechless on what to say or how to thank you for this great article. Thank you for the great work. A big fan of yours from Nigeria.

  9. Hello,

    Thank u for this great article !

    I have a question: can i use only one edge server ?

    To connect to my SFB server on external (with my android using the application), it is necessary to have edge server and reverse proxy deployed? both are needed or one of both or it is possible with only standard edition server and public dns records that point directly my server on lan using NAT ?

    Thank you

    Sorry for bad english ^^

    1. Yes, you must have a reverse proxy published in order to use any mobile client as those are clients leverage the web services (and not the Edge Server) for discovery and registration.

  10. Really excellent series of articles. Just one thought, will there be further articles regarding publishing S4B to the Internet?

    1. Thanks. I may create one for reverse proxy if I have the time, but there are a few others out there already covering older platforms like TMG and newer guidance like IIS.

      1. And if you do, please consider also at the same time to shed some light on the famous 502.3 timeout error that is causing mobile client call drops after few minutes (probably other issues too). Default setting in ARR for proxy timeout is 30. Then some sources suggest to configure it to 180 or 200. Others to configure it to 960 (works for us) and more. To add to a confusion, in two very similar small production environments different “server farm” needs that configuration. In one it is Web External (webext.domain01.com) proxy timeout value, in another it is Meet (meet.domain02.com) proxy timeout value. Thank you for all the answers and thanks to failed request tracing 🙂

  11. Hello Jeff,
    Many thanks of your rich document.
    would you please let me know that for Skype Edge External Certificate, should we add AV.domain.com or no need to use it! and sip.domain.com and webconf.domain.com are enough!

    Thanks again.

  12. Hi Jeff,
    Great article. I have a configuration where I have SfB in co-existence with Lync 2010. I have configured the SfB pool to use the Lync 2010 Edge until I migrate everyone over. I am having a problem where users are unable to establish media connections with anyone remote or external (going through the edge). Internally, media connections are established as normal and users can share desktop, use SfB voice and video. Lync 2010 users do not have this problem and can use media with external and remote users just fine.

    The snooper Ms-Client-Diagnostics field shows “A federated call failed to establish due to a media connectivity failure” and the users see the call start and 10 seconds later are disconnected with the message there were network issues. Any ideas?

  13. Hi Jeff,
    Any information available on deploying edge pools in multiple central sites (for large deployments)? Particularly how to configure certificates.
    For example, a large, globally dispersed company may have a central site in the Americas, in Europe, and in Asia. Each central site has an edge pool. Do all the edge pools need to use the same external certificate? If so, how do we accommodate the different external FQDNs?
    We’re having difficulty finding documentation on large deployments..
    Thanks,
    –Scotty

    1. No they don’t use the same cert. Each Edge pool uses different certs and different external pool names e.g. sip-eu.sipdomain.com, sip-us.sipdomain.com etc.

  14. Hey Jeff.
    Always appreciate your very professional and informative articles!
    Have done almost every installation in several SME with your documentation.
    Thanks a lot for your reference book and also thanks for saving mit time!
    Best regards and go on like this! 🙂

  15. Hi Jeff,

    In need of your guidance, we have complete Cisco Telepresence environment registering to CUCM & egress out to VCS for public internet,

    The requirement is to interOp with Skype4Business online users:
    I am trying to setup S4B edge & Frond end server & setup SIP trunk to dedicated VCS installed with LIC-EXP-MSFT interop key, And that VCS would have neighbor zone with production VCS,
    Can this architecture be supported?

    As i see in cisco document that it would support the Lync 2013 deployment & not S4B 2015,
    Ref: http://www.cisco.com/c/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-7/Cisco-VCS-Microsoft-Lync-Deployment-Guide-X8-7.pdf

    If you can throw some light with your expertise suggestion apart from VIS to direct CUCM it would be really helpful as VIS server has limitation that content sharing & S4B towards VTS dialing is not supported in this model hence trying to avoid that model.

    Await to hear from you, Thanks Much in advance for your support.

    1. You cannot utilize mediation service-based SIP trunks in Lync or SfB with any Telepresence Systems. The SIP trunk you create between Lync/SfB and CUCM will strip all the video information from the SDP data in your SIP invitations. This is by-design in the Microsoft platform. Outside of leveraging VIS you’re only options are to use a third party solution as outlined in this past article: http://blog.schertz.name/2015/01/video-interoperability-in-skype-for-business.

      1. Hi Jeff,

        Thanks for your quick response

        Can we build the Lync 2013 server which actually supports the SIP trunk b/w Cisco VCS to Lync Front End server?
        If yes can this version supports getting federated to Office 365 cloud so that federated Skype for business users can be dialed in or dialed out from Cisco endpoints.

  16. Hi Jeff,
    Excellent article. We have 4 different edge pools deployed in three different sites. I included the external names of the reverse proxy and edge servers in one single certificate as SANs. I installed this single certificate on all edge server pools and reverse proxy. I am wondering how good is this practice? I noted that Desktop Sharing does not work very well, so I am thinking if the list of SANs is not too long, I would appreciate you advice on this matter. I can order separate certs for the different edge pools and reverse proxy…

    Thanks

    1. I suppose this should work and as long as TLS is accepted I do not see why Desktop Sharing would be impacted while other workload function. It is typically recommended to use a unique certificate for each pool though.

  17. Hi Jeff,

    Excellent article which we have used in our Lync 2013 migration. Just wanted to get your take on wildcard certificates as they are not mentioned in this article yet Microsoft appears to have changed their guidance here:

    https://technet.microsoft.com/en-us/library/gg398920%28v=ocs.15%29.aspx?f=255&MSPPError=-2147217396

    They are saying now that wildcards are ok to use unless OCS compatibility is still a requirement. Do you have any comment or experiences in that area?

    1. Wildcards are still not supported on the external interfaces, but it looks like they are now supported on the internal Edge interface. Given that the internal Edge interface only requires a single FQDN (either the Server name in a single server deployment or the pool name in a multiple server pool) then this seems moot as normally an internal CA issues the certificate used on the internal Edge server anyway.

  18. Hello jeff,
    great article , many thank’s.

    i have two Central Site , in each site we have : two FE ,et one Edge, i want to force users to use they EGDE when they connect with the external and when they uses the meet conference with external users.
    also i how to force the users in each site to connect throught theire egde to connect on (when they are outside).

    thank’s in advance

    1. You cannot force users to use a specific Edge server in different call scenarios, if that is what you are asking. Your clients will always use the Edge server/pool assigned as the Next Hop for the Front End pool their account is homed. External clients will always route their signaling traffic through these same Edge servers/pools. Media traffic though will be directed to/through the Edge server/pool that makes the most sense at the time of the session establishment. This hard-coded behavior is automatic and you cannot change it.

  19. Hi,
    I need a clarification about the network diagram.
    Using 2 edge server Microsoft says that the servers must have pubblic interface and internal interface.
    Btw, the pubblic interface can be with a private ip address associated to the NAT on the firewall?
    ex:
    EDGE 1:
    external nic -> 172.0.0.1 – > nat 2.2.2.2
    internal nic -> 10.0.0.1
    EDGE 2
    external nic -> 172.0.0.2 -> nat 2.2.2.3
    internal nic -> 10.0.0.2

    Thanks in advance

    1. Yes, you can place non-routable private IP addresses on the external Edge server interfaces and then use NAT to translate the addresses on an external firewall. That is another supported topology that I did not cover in this article.

  20. Hi Jeff,
    Your articles have been lifesavers!
    What are the pros and cons of using NAT on the external Edge interfaces? We have always used NAT for ours, but this does add some complexity to the deployment and I wonder if it might be contributed to some intermittent connection issues we see, particularly with application/desktop sharing.

  21. Jeff,
    I have deployed an FE (fe-01.ampcus.loca) in the center of excellence and have also deployed a single Edge server (phlab2.ampcus.local). Following are the URLs used:
    meet 70.182.185.14 > 10.1.22.53 (web conferencing)
    dialin 70.182.185.15 > 10.1.22.54 (a/v edge)
    sip 70.182.185.18 > 10.1.22.52 (accessedge)
    I imported the SSL cert issued by the provider and started the Edge services. I get the following error/s:
    A serious problem related to certificates is preventing Skype for Business Server from functioning.

    Access Edge Server external edge FQDN cannot be located in the certificate configured for its external edge.
    ====================================================================
    “External FQDN: ‘sip.ampcus.info’.
    Make sure the certificate configured on the external edge of Access Edge Server matches its external FQDN.

    Cause: The Skype for Business Server failed to initialize with the configured certificate.
    Resolution:
    Review and correct the certificate configuration, then start the service again.
    =========================================================================
    The protocol stack reported a critical error: code 0xC3E93C62 (Configuration failure prevented the server from starting up). The service has to stop.
    ========================================================================
    The protocol stack reported a critical error: code 0xC3E938F5 (SIPPROXY_EVENT_EP_EXTERNALFQDN_MISMATCH). The service has to stop.
    =============================================================================

    I have checked and re-checked the SANs on my cert; the common name is sip.ampcus.info, alternate names include dialin.ampcus.info, sip.ampcus.info and meet.ampcus.info.

    I need your help and advice since I also need to deploy this architecture in the prod env soon.

    Appreciate your time.

    Deepu

    1. meet and dialin are usually used on the Reverse Proxy. Double check your Topology Builder for meet URLs and the names on your Edge Server

      1. Hi Rick,

        How and on which Server to check Topology Builder for meet URLs and the names on your Edge Server? Will you please share URLs List that need to be checked since I verified from my end but still above error as I Assign Certificate.

        Need urgent help

  22. Our SIP address and SMTP addresses are different.
    Domain name is xyz.local ,
    SIP address is:  xyz.local  
    SMPT address: ABC.com

    I am configuring Skype for Business Edge server. I have got external IP : 212.12.X.Y. Should my access edge be sip.xyz.local?

    I am stuck as I don’t know what DNS name should I use so my clients can communicate with each other and use IM/AV skype functionality.  
    What is the best way forward? 
    Thanks for you help..

    1. Correct, the SIP domain is used so your Access Edge should be sip.xyz.local. But understand that a .local domain is not supported for external Edge services so I’ll assume that is just an example you are using. Otherwise, you cannot use .local domains on the Internet so your SIP domain will need to be something like ABC.com for any of this to work.

  23. Quick one — instead of using mmc to get to the Local Computer certificates you can go straight to it with certlm.msc, skips a few steps.

  24. Hi there,

    I have a strangs issue. I’m able to login external and internal from my laptop or computer but i’m not able to login with my mobile phone

    The external certificate is NOT a wildcard but a multiply domain SHA256 certificate. I’m also using an edge server to federate the request in my inside network

    In the logfile it only says:

    2017-01-19 22:04:57.511 SfB[5856:1ab591c40] INFO APPLICATION CAlertReporter.cpp:64 Alert received! Category 1, Type 201, level 0, error E_AuthError (E2-3-2), context ”, hasAction=false

    2017-01-19 22:04:57.512 SfB[5856:1ab591c40] INFO APPLICATION CAlertReporter.cpp:116 Alert cleared of Category 1, Type 201, cleared 0 alerts

    2017-01-19 22:04:57.512 SfB[5856:16ec77000] INFO UTILITIES CHttpStreamPool.cpp:599 Releasing stream 0x703081f0.

    2017-01-19 22:04:57.512 SfB[5856:1ab591c40] INFO APPLICATION CTransportRequestRetrialQueue.cpp:735 Response received for req. GET-AuthenticatedUserGetRequest(0x104a552b0): E_AuthError (E2-3-2) (RemoteNetworkPermanentError); Done with req.; Stopping resend timer

    Do you know what this is

    Many thank for your help

  25. Setup an Edge following your excellent article, but running into a strange problem;

    Mobile users can IM INTERNAL users and vice versa just fine.

    External desktop users can IM a mobile user, and the mobile user receives the message but then the desktop client says “The action couldn’t be completed. Please try again later”.

    The external desktop user NEVER receives a reply from the mobile user.

    Any tips on what this might be would be greatly appreciated!

  26. Hi there

    Do you have information, how the configuration should look like, if I want to use one Edge Pool, with two Frontend Pools in the same topology? You wrote a blog (http://blog.schertz.name/2012/07/lync-edge-server-best-practices/) with a complex Environment. Unfortuantly there were no information about DNS and certificate requierements. If I want to use the same Edgepool for the 2nd Frontendpool, you get the error message, that the Name is already in use. If you create a new a record that is pointing to the same IP address and change the certificate it works, but the replicationstatus is false, since the new created a-record is not the fqdn of an edge server.

    1. It’s not clear where you are seeing this error but you can definitely have multiple FE pools behind a single Edge pool; this is one of the most common deployment topologies out there. The ‘name already in use’ error sounds to me like you are trying to define something new in the Topology that does not need to be. You simply select the existing Edge Server FQDN as the next-hop for both pools. If you are trying to do all this at once I suggest starting with a single FE and Edge pool deployment and once that is operational then go back and deploy the second pool.

  27. Jeff, I have a question about 50000-59999. We enabled all those ports from in to out. However, my understanding was that we those ports needs to ne open from out in only for OCS servers

    1. That port range is never required. It’s recommended to allow inbound connections but if it is not open then media sessions will fallback to establishing over 443 TCP and 3478 UDP. It’s more efficient to allow external connections to directly hit their own dedicated ports instead of all sharing the same port.

    1. That port range is never required. It’s recommended to allow inbound connections but if it is not open then media sessions will fallback to establishing over 443 TCP and 3478 UDP. It’s more efficient to allow external connections to directly hit their own dedicated ports instead of all sharing the same port.

        1. Mainly because opening outbound ports is a much easier battle than opening inbound ports. In fact many firewalls already allowed all traffic out from a more trusted to less trusted network, but not in. Ideally opening both ranges offers the most flexibility, but allowing that range opened inbound was universally denied by more network administrators. Microsoft is moving towards simplification of this by soon not even recommending that the 50k-59k port range is opened even outbound, for SfB Online users. Eventually all media will be tunneled over 443/TCP and 3478/UDP for Office 365 clients. Keep any eye out for a future article outlining this. You can find some info on this change here: https://techcommunity.microsoft.com/t5/Skype-for-Business-Preview/Simplifying-port-requirements-for-O365/m-p/41022/highlight/true#M364

  28. Hello Jeff,

    Thanks so much for the in-depth clarification on SFB, however i need some clarifications on the networking side.
    I currenlty run server 2012 in my environment.

    Platform is visualized with Citrix Xen Server.

    just to clarify;
    should i assign two network adopters? one internal and other external
    internal = Lan IP eg 10.20.20.3
    external=public IP (3 public IPs) on the same adopter???

    If so; is the server not at risk? to public/hackers?
    please advice.

    thanks.

    1. Ideally no, you do not want to connect the Edge server directly to an internal LAN. It should be connected to a Perimeter (DMZ) network and then traffic is routed to the internal LAN through a firewall.

  29. Hello Jeff

    I’m setting up Skype for Business 2015 Edge pool in our enterprise. This is a new domain that we have built to migrate what was once two separate companies in two separate domain in to one domain. These two companies are in two different geographical locations with a metro-e link connecting there two separate logical networks. I have created two sites in the SFB topology, one for each geographical location, both sites use the same SIP domain. Each site has its own DMZ. I have deployed two Edge servers and one revers proxy in each sites DMZ (total of 4 edge and 2 RP servers). My question is how do I set it up so that communication originating from a federated partner knows which set of edge servers (DMZ) to use the pair at site A or the pair at site B, based on the user whom they contacting’s location.

    Thanks

    1. Typically only a single Edge pool in a topology can be set as the destination for inbound federation traffic, either Open or Closed. The signaling will always travel to the same single Edge Pool, but media sessions established as part of the same connection (e.g. Federated user peer call) with traverse the preferred Edge pool, depending on the location of the external (federated) and internal user.

      You could look into uses a GeoDNS approach to align the DNS records geographically so that the local Edge Pools are used for inbound federated connections.

  30. Hey Jeff great article.

    I know you only assign default gateway to external nic, but what DNS servers do you assign to the external NICs?

    I assume you assign internal DNS servers to internal NICs.

    Do I need to allow port 53 inbound to the external NICs as well?

    Our dns team says the forward any non authorative request.

    1. Depends on your DNS solutions. Typically I see an internal (or perimeter) DNS server used and then that server. You can’t really use an external DNS server as it would be missing the internal SfB server hosts needed by Edge server to locate the internal servers. So define internal DNS server on internal NIC and leave external DNS servers blank on the external NIC. You do not need to open 53 on the external side if all DNS requests are flowing to the internal side.

  31. Hi Jeff,
    Excellent article, thanks for taking the time to write it.
    We’re trying to deploy an Edge pool (a load-balanced pair of Edge servers). The main goal of this is to provide resilience; capacity is not a problem with 1 server.
    We are using NAT to hide our Edge servers behind a firewall; there is no prospect of placing the Edge servers’ external NICs on the Internet, we are a very security-conscious shop. Also, I’m perfectly happy to admit that I’m just a network architect and my knowledge of Skype is very limited.

    Where I get confused with load balancing is, how do we ensure that media streams from inside and outside are routed via the same Edge server? For example:
    EXTERNAL user connects to a load-balancer VIP, and is then forwarded (round-robin), on to EdgeServer1.
    INTERNAL user connects to a load-balancer VIP, and is then forwarded (round-robin), on to EdgeServer2.

    Does that matter with Skype? Will the 2 media streams reach their recipients or do they need to route via the same EdgeServer?
    Or, does EdgeServer1 initiate the connection to the INTERNAL user, ensuring symmetry for the return traffic?

    Further compounding my confusion is this:
    External user connects into a load-balancer VIP for SIP.contoso.com, and lands on EdgeServer1.
    The same External user later sends his/her a/v stream to a load-balancer VIP for AV.contoso.com, and this time lands on EdgeServer2.
    Surely this will break?

    Whether the load balancing is done by hardware or DNS, I cannot understand how this works.
    I have read that HLB is not available unless the Edge server has a publicly routable External IP address. Can you confirm this please?

    1. Jamie, honestly I gave up on the last HLB Edge deployment I attempted. The Microsoft documentation is not accurate and I could never get it to work 100% reliably. For a while now I’ve recommended using DNS Load Balancing on both sides of an Edge Pool. It’s ultimately easier to deploy and manage and there are very few unsupported clients or OCS deployments still out there which might have issues during a single-point-of-failure event.

      You can use HLB on the external Edge side with either private (NAT) or public IP address, but like I mentioned it’s ultimately more of a mess.

  32. Hi Jeff,

    This page is fantastic to explain all the firewall rules needed! Its helping me unravel the mess!

    I have noticed a difference in the firewall rules for AV you state:
    Server Role | Source IP | Source Port | Protocol | Destination Port | Destination IPs | Communication Type | Direction
    A/V Edge | 242.42.5.106, 242.42.5.109 | Any | TCP | 50000-59999 | Any | External client/server media | Outbound

    Should it not be 50000-5999 source ports rather than destination ports?
    I’ve noticed our firewall dropping connections that have a 5xxxx range source port and random destination port. It looks like the planning tool indicated 50000-59999 source.

    Your guides are the best!

    Thanks,
    Finn

    1. I have those broken up into two rows in the table. The first row covers inbound connections to the 50k range on the Edge server, which is optional and no longer really recommended. The second row is for connections outbound from the Edge server to other Edge servers, hence the 50k range as destination ports.

  33. Hi Jeff, this blog post was enormously helpful to me in deploying Skype for Business in a greenfield. However, I have one question that is a mystery to me. I am seeing traffic from my internal clients to the AV IP’s on the public side of my edge pool. Since they don’t have DNS resolution to those IP’s, I’m not sure why I’m seeing that in the 50000-59999 port range?

    1. That is normal. The clients are performing connectivity checks to all the IPs listed in the SDP candidate list during ICE media negotiation. They will never actually attempt to send media to them though as if they decide they need to use the Edge server for TURN (relay) then the internal clients are hardcoded to establish connectivity to the Edge server’s internal IP address(es).

  34. Hi Jeff, great in depth explanation. Only one thing missing is when for instance a refresh of new external certificates on the edge servers need to take place. Can they (sip.domain.com) simply be be imported (replaced) on the personal certificate store on the edge servers? And do all edge servers (in this case 2) need to have the sip certificate imported? Thanks for your answer. Really appreciated.

    1. If you are talking about updating the certificate chain (CA certs) then those are simply imported into the Computer Store into the proper containers. If you mean issuing new certificates to the Edge Server roles itself then you need to re-run the Certificate Wizard and run through the initial process again. The new certs need to be imported and assigned to each service and duplicated to all servers in the pool. Make sure to reboot each Edge server after completing these tasks.

  35. Hi Jeff,

    Need some info in my environment have Skype for Business 2015-Front End server deployed and running smoothly but it is operating on Window Server 2008 R2 Enterprise so what is procedure to upgrade Operating system form Server 2008 to Server 2012 without impacting Front End Server.Any Disadvantage.

    My second concern is about IP required is that essential to be Live IP or we can go for NAT or some shared network for Edge Server Deployment.

  36. Hi Jeff,

    Great article, thanks for taking the time to pull it together and publish. Just wanted to let you know of a potentialy gotcha, and ask if you’ve come across it yet?

    A new internal cert was issued to an Edge pool from a template with the ‘client authentication’ EKU added, as per workaround one from https://support.microsoft.com/en-us/help/4023993/ls-data-mcu-41026-41025-and-41024-after-may-2017-net-framework-update , in order to stop error 41025 appearing on the Edges and FEs.

    Generating a single domain cert via IIS manager as per your guide caused the RTCMRAUTH and RTCMEDIARELAY services on the Edges to fail to start, with the error .

    Generating a single offline cert request on one Edge server using the SfB deployment wizard, then exporting that cert and private key to the other Edge caused the second Edge to fail to start RTCMRAUTH and RTCMEDIARELAY, while the first Edge that requested the cert could start services without issue.

    Generating offline cert requests using the SfB deployment tool individually for each Edge is the only combination tried that allows RTCMRAUTH and RTCMEDIARELAY to start.

    Obvious issue with this is that the certificates are no longer the same on each Edge internal interface, which point out in your other excellent article http://blog.schertz.name/2012/07/lync-edge-server-best-practices/ , may lead to dropped sessions in a failover scenario.

    Wondering if you have a reference for that, as I can’t seem to find any reference to it on TechNet – best I can find is https://technet.microsoft.com/en-us/library/jj205399(v=ocs.15).aspx , which doesn’t appear to mention a requirement for the internal interface certificate to be the same on all Edges in a pool.

    Thanks for your time!

    Al.

    1. D’oh, forgot to post the errors, 19005:

      LS Audio/Video Authentication service could not be started.

      Exception: Microsoft.Rtc.MRAS.MRASException: PrivateKey not accessible
      at Microsoft.Rtc.MRAS.Crypto.GetValidCertificate(String issuerName, String serialNumber, Boolean isBankCert)
      at Microsoft.Rtc.MRAS.Core.GetTlsCertificate()
      at Microsoft.Rtc.MRAS.Core.Initialize()
      at Microsoft.Rtc.MRAS.Core..ctor(ServiceStopHandler serviceStop, RoleName roleName)
      at Microsoft.Rtc.MRAS.Server.OnStart(RoleName roleName)
      Cause: Internal error.
      Resolution:
      Examine the details in the associated event log entry to determine the potential cause and report to Product Support Services.

      …and 19008…

      Private key for server certificate not found by the LS Audio/Video Authentication service or the service does not have sufficient permissions to access the certificate.

      Certificate Serial Number: ‘1xxxxxxxxxxxE’ Issuer:’CN=some internal ca, DC=some, DC=domain’
      Resolution:
      Install a certificate with the private key in the local machine store, check if the configuration parameters have the correct server certificate serial number. Check if the service has sufficient permissions to access the certificate.

  37. Hi,

    thanks for the clear guild…however I seem to have been lost at the federation config bit.

    we have 2 separate domains domain1.doiman.com and domain.com,
    domain1.doiman.com want to federate with domain.com

    what is configured on the Nics and specifically what is the DNS requirement (SRV and A records)

    any host records?
    and by the way the edge is domain joined……its all internal , no internet so no risk to outside world

    regards
    ablerto

    1. I don’t quite follow your question as Federation has nothing to do with the Edge Server’s network interface configuration. You simply enable Federation by adding the foreign SIP Domains and Edge Server external SIP FQDN to each side.

  38. Hey Jeff – excellent series! I have been using this to build a lab and got to the point of building the Edge server but found the link to your “simpler companion article”: http://blog.schertz.name/2016/02/skype-for-business-2015-edge-server-deployment fails with a 404 error. I was hoping to build the entire environment on a single server NATted through my firewall since I only have a single IP….is that possible and do you have an article to complete the process?

    Thanks again!

  39. Hi Jeff, GREAT Articles; what are your thoughts on removing DNS Round Robin and using a hardware LB (HAProxy) appliance in front of the Edge Pooled servers? What is your recommendation on providing HA to Edge servers (2+) from a firewall entry point, instead of having multiple Ip’s in FW, use a VIP?

    1. Recommend DNS Load Balancing (technically it’s not Round Robin). Using HLBs for anything other than HTTP/HTTPS is ultimately more complicated and difficult to deploy, manage, and troubleshoot.

  40. I’m quite new when it comes to Lync 2013/Skype for business server 2015. As present we are running single server internally on 192.168.81.0/24 server network with the following roles

    ComponentName Version
    ————- ——-
    Skype for Business Server 2015, Administrative Tools 6.0.9319.0
    Skype for Business Server 2015, Application Host 6.0.9319.0
    Skype for Business Server 2015, Audio Test Service 6.0.9319.0
    Skype for Business Server 2015, Bandwidth Policy Service 6.0.9319.0
    Skype for Business Server 2015, Call Park Service 6.0.9319.0
    Skype for Business Server 2015, Conferencing Server 6.0.9319.102
    Skype for Business Server 2015, Core Components 6.0.9319.235
    Skype for Business Server 2015, Core Management Server 6.0.9319.0
    Skype for Business Server 2015, Front End Server 6.0.9319.235
    Skype for Business Server 2015, Mediation Server 6.0.9319.0
    Skype for Business Server 2015, Performance Counter Cumulative Update 6.0.9319.235
    Skype for Business Server 2015, Reach Fonts 6.0.9319.0
    Skype for Business Server 2015, Response Group Service 6.0.9319.235
    Skype for Business Server 2015, Skype for Business Web Application 6.0.9319.102
    Skype for Business Server 2015, Web Components Server 6.0.9319.235
    Skype for Business Server 2015, Web Conferencing Server 6.0.9319.0
    Skype for Business Server 2015, XMPP Translating Gateway 6.0.9319.0

    The requirement here is to allow users in our organization to use Skype for Business to contact people in specific businesses outside of our organization.

    With what I have read we will need a reverse proxy and edge server in the permiter network. I am trying to understand the functionlaity for both the edge server and the reverse proxy here.

    What step by step method can I use to deploy the edge server role. Does this require certificates can I use wild card certificate for this.

    Please advise

    1. You can use the Edge ‘Server’ blog linked at the beginning on this for single server deployments. You should not use a Wildcard certificate on the Edge Server, but you can use one on the Reverse Proxy, with restrictions.

  41. Hi Jeff,

    Thanks for the great article one question, how do I integrate SFB with exchange 2010 I am doing a side by side deployment from lync 2010. exchange 2010 doesn’t have the configure trusted app powershell script like 2013 does.
    and no plan yet to go exch 2013 any help would be much appreciated.

  42. Hello Jeff,

    My configuration is Lync server 2013, single Edge, web apps and proxy server.
    Have a problem with federation A/V and share, all the other features work ok
    All features for internal users of Lync domain is correct, internal / external, external / external, work 100% (including AV and sharing)

    Can you help me ?

  43. Hi Jeff, great article. We’ve been doing a lot with GEO DNS SRV records where we can hand back the list of SRV hostnames with different priority and weight based on the end-user location. This helps reduce latency by directing the user to the closest hostname in the SRV list of servers. This is very useful in geographically distributed environments where there are multiple Skype endpoints in different countries

    Our solution detects the local users IP/subnet using EDNS0 (client-IP) and then determines what DNS SRV list to hand back based on the rules set by the admin. I hope you check it out

  44. Hi Jeff,

    did you write a faulty DNS SRV records for _sip._tls.sipdomain.com ?

    @ External DNS part of your post, you writed: _sip.tls.jdskype.net

    and thanks for sharing your experience 🙂

    David

  45. Very informative article.

    I recently ran into two issues and wanted to see if you have seen these.

    First, internal LYNC FE was working great. After we ran that for a bit we decide to implement A Reverse Proxy (Windows 2016). That went smooth as well. We were using WIldcard CERTS both internally and for the Reverse Proxy without issue. Next we decided to deploy edge.

    Everything seemed to work but we are having an odd issue:

    – Externally we can connect to our SKYPE 2015 Environment from home machines. We can even send IM’s, etc. People on the inside get the info we send and see our status updates etc. However, NONE of these updates are going back out to the home desktop clients. Essentially they just sit there…

    If we sign out of SfB on our Home PC and log back in we see out status updates but again no responses to IMs we receive. It is like we only get the initial update and no others.

    When I went through the config I realized we used a * cert on EDGE but I am not sure if this is the problem. All the ports seem to be open and working properly.

    Any ideas?

  46. We have two Pools deployed, we are planning to deploy July 2018 Skype for Business CU update,
    Which Pool first need to update
    Primary pool where all users are hosted or site resilence pool where users are not hosted.
    When need to run install-csdatabase command? after update all Skype for Business server or update each pool?

    Need urgent details on this.

  47. Hi Jeff,

    Thanks for your great article.
    My question is very simple. I would like to know if it’s possible to make an av conference or call from mobile devices, from outside the edge server without the AV and Webconf record setup, only with sip record.

    Thanks

    Alain NGATCHOU

    1. No, those records and associated Edge services are required for meetings, regardless of the client type. The AV FQDN is critical to leveraging ICE for negotiating media streams from all clients, even the mobile clients. In fact the mobile devices do not even use the SIP service on Edge, so you’d literally have the opposite configuration than what is needed for those clients.

  48. Hello,
    i’m stuck at the part of Network cards, the thing is :
    we have 2 Networkcards ( internal + External ), the internal must be connected to the same switch with Skype Front end Server and the external must be connected to the internet ( router, switch with router ) and must have other subnet of Front end server, thats mean is that okay if Front End Server doesnt have internet right ? i really cant understand that part

  49. Hello Jeff,
    I have just deployed SfB Edge server and I am facing a strange problem. I have imported and assigned public certificate but I cant get the RTCSRV service started. It fails and Event log displays following error:

    The protocol stack reported a critical error: code 0xC3FC7D95 (LC_E_VALIDATION_CERT_NO_KEYEXCHANGE). The service has to stop.

    Certificate itself should be okay, it has a private key, its whole chain is trusted.
    Please, is there anything you can advise? Maybe you have seen this before?

    Many thanks,
    Tomas+

  50. Hello Jeff,
    First of all, thanks for the article, it has helped me a lot during SfB deployment. But I have an issue I cannot figure out by myself.
    I have just deployed SfB Edge server and I am facing a strange problem. I have imported and assigned public certificate but I cant get the RTCSRV service started. It fails and Event log displays following error:

    The protocol stack reported a critical error: code 0xC3FC7D95 (LC_E_VALIDATION_CERT_NO_KEYEXCHANGE). The service has to stop.

    Certificate itself should be okay, it has a private key, its whole chain is trusted.
    Please, is there anything you can advise? Maybe you have seen this before?

    Many thanks,
    Tomas+

  51. Great write-up on this. I now have my edge up and running. Do you have an article on the reverse proxy for skype for business?

  52. It’s a pity you don’t have a donate button! I’d certainly donate
    to this outstanding blog! I guess for now i’ll settle for bookmarking and adding your RSS feed to my Google account.
    I look forward to new updates and will share this site with my Facebook group.
    Chat soon!

  53. Hallo Jeff,
    successfuly installed front end and edge server in our company.
    But is there any document on the web what to do to integrate/configure external access ( SFB Web App; Plugin; IIS )
    and so on.
    Regards
    Rainer

  54. Jeff,

    Noting that the question is not on topic.

    I’ve got a scenario where I need to connect a Linux based xmpp server to a SfB15 edge server and then have that edge relay the requests from the users in the Linux domain across the edge server to the internet.

    I can connect the Linux xmpp server as unencrypted and not federated – that works.

    I can’t find anything that would tell if that’s possible.

  55. Thanks Jeff for the great article, but as a matter of fact I’d like to say (and know about your idea and comment) on this:

    I think wildcard certificate (whether supported and/ or suggested or not) works on Skype 2015 and 2019. I tested on both and all services are up and running.

    BUT, you need to consider this: the edge FQDN should not be on Internal edge cert. Therefore, use wildcard cert on external and for internal, get edge server name FQDN certificate from domain CA. That’s all.

  56. Hello Jeff, Telnet to external few domain on port 5061 is failing from 1 out of 2 S4B2015 edge server, packets are passing through firewall. (for few other domains telnet works fine from same server)
    no issues from External domain end, NIC Teaming is done between public IP’s of both edge server, we notice issue when we reboot the servers.
    please suggest if any troubleshooting

Leave a Reply

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