Skype for Business 2015 Edge Pool Deployment

March 28, 2016 by · 44 Comments 

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

About Jeff Schertz
Site Administrator

Comments

44 Responses to “Skype for Business 2015 Edge Pool Deployment”
  1. WWWScotty says:

    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. Markus Johansson says:

    Great article Jeff as always. Keep up the good work

  3. Ruslan says:

    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.

  4. WWWScotty says:

    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.

  5. Melanie says:

    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

  6. Jojhar Sethi says:

    Jeff- Some of your external records end in *.net and *.com. Typo? Thanks.

  7. Dragan says:

    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!

  8. yacoob says:

    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

    • Jeff Schertz says:

      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.

  9. Howie C. says:

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

  10. Femi Shakur (@femiabdul) says:

    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.

  11. Batti says:

    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 ^^

  12. John says:

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

    • Jeff Schertz says:

      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.

      • Dragan says:

        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 🙂

  13. Alex says:

    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.

  14. Enrique says:

    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?

  15. WWWScotty says:

    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

  16. Yoda says:

    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! 🙂

  17. Ramesh says:

    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.

    • Jeff Schertz says:

      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.

      • Ramesh says:

        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.

  18. Mario says:

    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

    • Jeff Schertz says:

      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.

  19. Mark says:

    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?

    • Jeff Schertz says:

      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.

  20. sofyane says:

    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

    • Jeff Schertz says:

      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.

  21. 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

    • Jeff Schertz says:

      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.

  22. Mark H says:

    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.

  23. Deepu says:

    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

  24. Sahil says:

    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..

    • Jeff Schertz says:

      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.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!