Skype for Business 2015 Edge Server Deployment

This article is intended for those following along with this series of deployment articles to create a Skype for Business (SfB) 2015 Server environment.

The instruction in this article is without much of the typical in-depth explanation provided alongside most deployment articles on this blog. A much more detailed companion article entitled Skype for Business 2015 Edge Pool Deployment is also available which overlaps with a lot of the concepts and steps in this article. This other article addresses the more complex topic of deploying multiple Edge servers in production-like setting, but also includes additional guidance and can be used as a deeper reference to the topics covered in this shorter article. Basically the other servers as a production deployment reference guide while this is the quick reference guide for lab deployments. Nearly all of the guidance in the companion article related to network configuration and server preparation holds true for either scenario.

Also worth pointing out is that if one is attempting this deployment then a fair amount of Windows server and networking knowledge is assumed. Because the Edge Pool article goes into great depth on topics and step-by-step directions this article will omit some of the basic instructions on how to get to specific windows and focus on just the important aspects.

Preparation

The baseline for this deployment is a new Windows Server 2012 R2 installation that is not joined to any Active Directory domain and is connected to two separate IPv4 networks. These are basic requirements for an Edge Server and must be met in order to move forward with a successful deployment.

The network topology of the lab environment used for all the articles in this deployment series simply consistent of two physically separated network segments.

A single firewall with separate network interfaces provides connectivity for each network segment to the Internet. The two networks do not have access to each other except for any explicitly defined firewall rules. The rules required to allow communications to and from the Edge Server across either network are covered in the Edge Pool article which can be used as a reference. Make sure to open and test the required ports and protocols before attempting to deploy and start the Edge Server services.

Configure Network Interfaces

The existing server has been prepared with two network interfaces connected to two separate IPv4 networks.

In order to allow normal communications typically the internal interface would have been configured with the default gateway set to the router’s IP address for that segment and the external interface would not yet have a default gateway set.

The server cannot have multiple default gateways defined yet moving the server’s default gateway to the external interface might break communications with hosts on other routed internal networks than the one it is directly connected to. To prevent this problem then some persistent static routes are required. This topic is covered in more detail in the Edge Pool deployment article which outlines creating up to three new persistent static routes to tell the server to use the internal router to locate hosts on any of these reserved IP address ranges. This is a normal practice in environments with multiple routed internal networks but unnecessary in a standalone lab environment like what is used in this example.

Review the current IPv4 configuration on both the Internal and External interfaces and configure the default gateways as appropriate.

If Remote Desktop connectivity is lost after moving the default gateways as shown above then connect to the server console and either define a required static route to back to the network where the remote console is, or if that console is actually in the ‘External’ network then check the firewall configuration to allow remote desktop connections to the external interface. Clearly this is safe in a lab environment but if the Edge server’s external interface is to be routed to the Internet than a different approach may be advisable.

Configure Computer Name

As covered in the other article it is critical to set the proper Fully Qualified Domain Name (FQDN) on this server so that the server component installation will function correctly. This is a commonly missed step that leads to troubleshooting installation issues further down the line.

View the server’s System Properties and use the More button under Computer name field to access the following window. Enter the same DNS domain and suffix used by the internal SfB Front End server so that the Edge Server is configured with an FQDN.

Reboot the server to apply the new computer name.

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) and as the Edge server does not contain any web service components then IIS subcomponents will also 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.)

Once the installation is complete a restart will not typically be required, but if prompted to do so then reboot before moving on to the next step.

Windows Updates

Before installation any SfB components make sure to apply the most recent Windows Updates, with one notable exception: do not install the Microsoft .NET Framework 4.6.1 package as this is not currently supported by Microsoft.

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.

Configuration

This section covers updating the SfB Topology and access policies to enable both the deployment of the Edge Server and enable its functionality.

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. edge.jdskype.net) and then select the option for This pool has one server.

On the Enable Federation window select the desired options, in this case only the Enable Federation option is addressed. The Skype Search and XMPP options can be enabled now or later if so desired.

Select the option to Use a single FQDN and IP address.

For this deployment only IPv4 addresses will be utilized, and for any Internet access then Network Address Translation (NAT) will need to be used as the Edge server’s external interface has a private IP address bound directly to it.

In the External FQDNs window the wizard will populate the suggested ports due to selecting the single FQDN and IP address option earlier.

Leave the suggested ports as these are typically the best options available. The Access Edge service will collocate external client and federation traffic on the same port (5061) and it is recommended to leave 443 assigned to the critical A/V Edge role to provide the best chance of successfully negotiating media sessions. The assigned FQDN is typically “sip.<sipdomain>” but in this lab environment a different FQDN is used to avoid potential overlap with the internal sip record. While any name can be used the sipexternal FQDN is one of the legacy Host (A) look records used by many clients and IP phones, so it was selected for that reason primarily.

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 that is assigned to the internal interface.

Enter the External IPv4 address in the proper field for each service and then click Finish.

Enter the Public IPv4 address for the A/V Edge service which will be translated to the server’s actual external IP address. This NAT configuration would be handled by the firewall depicted in the original diagram and is not addressed in this article.

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.

Only remote user access will be enabled in this article. For reference the Edge Pool deployment article discusses the other external communication types.

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 and save the changes to the policy.

Under the Access Edge Configuration page open the default Global configuration and check the Enable remote user access option and save the changes to the configuration.

Export Topology

As briefly discussed earlier the Edge server deployment will require that the SfB topology data is manually exported and imported on the Edge servers which do not have the ability to locate and download this configuration information automatically.

Using the Skype for Business Management Shell run the following Export-CsConfiguration cmdlet to export. (This file will be retrieved in a later deployment step.)

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

Deployment

Due to this being a lab installation then private certificates will be involved. Both the internal and external Edge certificates will be issued from the same AD-integrated Enterprise Certificate Authority (CA) that was used for certificates assigned to the other SfB server roles. If a public certificate is intended to be used on the external interface then the other article covers those configuration steps.

Full step-by-step directions for performing these actions can be found throughout a myriad of other articles covering various options like using the SfB Certificate Wizard, Internet Information Services Manager, the Windows certificate snap-in and even third party tools. For the steps outlined below the popular, free DigiCert Certificate Utility for Windows is utilized.

Create Internal Certificate

Because the SfB Front End server is joined to the domain then it is an ideal host to perform online certificate requests to the AD-integrated Enterprise CA.

Download, install and launch the DigiCert tool on the SfB Front End server.

Fill out the Certificate Details field as appropriate for the Edge Server Internal certificate. The Common Name field should be the FQDN of the Edge Server (e.g. edge.jdskype.net) and the Subject Alternative Name (SAN) should be blank.

Generate the request and then save the request data to a text file on the local server (e.g. C:\Temp\edge_internal.txt).

On the same Front End server launch either the Windows Command Prompt or PowerShell as an administrator and then issue the following certreq.exe command. Supply the name of the text file saved in the previous step which contains the certificate request information and then enter the name of the new certificate file itself to be created (e.g. edge_internal.cer).

Return to the main SSL window of the utility and highlight the newly imported certificate (e.g. edge.jdskype.net) and then click Export Certificate.

Make sure to select the options to Export the Private Key and to Include all certificates in the certification path.

These options are critical as without the private key this certificate is useless to the Edge server. Also the issuing Root CA’s public key needs to be manually imported into the Edge server because it is not a member of the AD domain and has not automatically been provided these root certificates. These options will address both of those requirements.

Define a password (e.g. password) to protect the export file which will contain the certificate’s private key. This step is mandatory and cannot be skipped.

Choose a location and filename to save the exported certificate (e.g. C:\Temp\edge_jdskype_net.pfx). (This file will be retrieved in a later deployment step.)

Create External Certificate

Now that the internal certificate for the Edge Server is ready a second certificate needs to be created for the external interface. Typically this request is sent to a third-party Certificate Authority and the process above can be used to do that. Instead of running the certreq.exe command simple copy/paste the request text into the request field of whatever CA is used.

Repeat all the steps above in this section to request, import, and then export the Edge Server external certificate. The only configuration difference is that the Common Name will need to be set to the Edge Server’ External FQDN that was defined (e.g. sipexternal_jdskype_net.pfx).

Now that all the server and environment preparation steps have been completed then the final processes of actually installing and configuring the Edge Server roles can begin.

Copy Files

The exported files created in the previous certificate topology and certificate preparation steps need to be manually copied from the Front End server to the Edge server.

On the SfB Front End server locate the topology export file (e.g. C:\Temp\topo.zip) and the two exported certificate packages (e.g. C:\Temp\edge_jdskype_net.pfx & C:\Temp\sipexternal_jdskype_net.pfx).

Copy these three files to the Edge Server to prepare for deployment and configuration steps in the next section.

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

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.

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.

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.

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 import and assign the SSL certificates before the individual services can be started and tested.

Assign Certificates

The separate internal and external certificates that were created earlier in this article can now easily be imported into the server and assigned to the proper roles.

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 which was already copied to the Edge server in an earlier section.

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.

On the Certificate Wizard home page highlight the Edge internalrow and click Assign.

On the summary page verify that the desired Certificate Use matches up with the correct certificate as identified by the Friendly Name and Subject Name fields.

Finish the wizard to assign the certificate to the internal Edge service.

Repeat all steps above in this section, but this time select the External Edge certificate.

The Certificate Wizard should now indicate that the chosen certificates have been assigned to the appropriate roles, as indicated by the green checkmarks.

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.

I am setting up Skype for Business 2015 Server Standard so all roles are on the same server.

I have setup a virtual machine with one NIC. It’s IP address is 10.0.10.44. It is behind a firewall. I have setup the appropriate firewall rules to NAT and allow the appropriate ports to that internal IP from an external x.x.x.x.

To the issue. To the ‘define the internal IP address’, I put in 10.0.10.44. Got it. ‘Define the external IP address’, which your article indicates is the internal IP address that the external is NAT’ed to, will not allow me to put in 10.0.10.44, stating it is already in use. If I put in x.x.x.x, it takes it, but doesn’t work.

‘define the public IP address’ takes x.x.x.x with no issue.

So… I guess the question is, do I just add another IP address to my server, let’s say 10.0.10.45 and use that?

The internal and external addresses cannot be the same network, so you need to connect the external interface to a different network. If that is also a private network then that address is NATed to the real public IP on the outside as well.

Hello,
I have tried to implement edge server with single public ip and without RP and public certificate..

When i am trying to check the same from Lync connectivty anayalser i see it is pushing internal edge ssl certificate which has no San name..becasue of that my aceessedge fqdn deosnt matcches the ssl certificate and authentication gets fail..
any idea where i am going wrong
i am using accessedge fqdn :5061 port

I have been able to get the external communication working! however I am getting the message” Analyzing the certificate chains for compatibility problems with versions of Windows.
Potential compatibility problems were identified with some versions of Windows.

Additional Details

The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the “Update Root Certificates” feature isn’t enabled.
Elapsed Time: 3 ms.”
Other than that everything passes without a problem! thanks for your threads!

The various CAs use different terminology but all you need is a standard SSL certificate, usually created for websites. Make sure to get a multiple-SAN certificate for the external Edge interface though, often referred to as ‘UC Certificates’.

Hello, Jeff, I has big probelem with Skype Edge! Ist es richtig dass der Edge Server nich in der Microsoft Domäne ist? I have only taken over the system, however, nothing is described. Can you help me?

These question may have been asked many a time but it not clear in TechNet so would like to post here.

Regarding the Internal certificate for a SfB Edge Pool with 2 servers – we know from the deployment wizard that the Subject Name will be the FQDN of the Edge pool that’s a given. What’s not clear in a Edge Pool scenario if the internal certificate needs to be the same on each server in the poo OR should we follow the same rule as the external certificate and export from one server and import to the other so that the certificate on each is the same.

Lastly what certificate is uses on the Edge to create the AV Authentication token. Is it the Internal or the external certificate?
How would one show which certificate is used in a WireShark trace or Snooper Log from a client.

All Edge certificates should be the same exact cert. So you only request/issue a specific role certificate once, and then export/copy it to all other servers in the pool. That means the internal cert should be identical on all servers in the pool, and the external cert (a different cert) should also be identical between external internals on all servers.

The internal Edge cert is used for AV authentication as that service is only available on the internal interface. The MRAS process is performed between the internal Edge and the Front End servers. Also the AV FQDN should not be included on any certs.