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.

• 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

• 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

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

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

Internal Rules

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.

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

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

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

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

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.

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.

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

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

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

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

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

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

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

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

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

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

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.

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.

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.

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

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

• 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

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.

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

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

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.

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

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

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.

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.

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.

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.

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

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

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

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

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.

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

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.

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.

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