Skype for Business 2015 Edge Server Deployment

March 28, 2016 by · Leave a Comment 

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.

image

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.

image   image

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.

image

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

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_thumb[102]

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

image

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.

image

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

image_thumb[69]

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

image

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

image

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

image

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.

image

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

image

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

image

  • Select the desired Next hop pool from the drop-down menu (e.g. fe.jdskype.net).

image

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

image

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_thumb[84]

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.

image

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

image

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

image_thumb[86]

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.

image

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

image

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

certreq -submit -attrib certificatetemplate:WebServer edge_internal.txt edge_internal.cer

  • When prompted to select a Certificate Authority highlight the desired CA (in this environment there is only a single Enterprise Root CA).

image

  • Select OK and if the process is successful the end result should be reported as Issued.

image

  • Use the Import option in the certificate tool to import the issued certificate file (e.g. edge_internal.cer) into the server.

image

  • Enter a descriptive Friendly Name (e.g. Edge Internal Cert) to complete the certificate creation process.

image

  • 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

image

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

image 

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

image

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

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

image_thumb[90]

  • 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_thumb[93]

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

image_thumb[95]

  • 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_thumb[104]

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

image_thumb[114]

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.

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.

  • On the Certificate Wizard home page highlight the Edge internal row and click Assign.
  • Select the desired certificate (e.g. Edge Internal Cert) and click Next.

image

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

image

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

image

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

Skype for Business 2015 Edge Pool Deployment

March 28, 2016 by · 1 Comment 

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.com sip.jdskype.net 5061 Open Federation
SRV _xmpp-server._tcp.jdskype.com 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.104
242.42.5.107
External client/server Web Conferencing data Inbound
A/V Edge Any Any UDP 3478 242.42.5.104
242.42.5.107
External client/server media Inbound
A/V Edge 242.42.5.104
242.42.5.107
Any UDP 3478 Any External client/server media Outbound
A/V Edge Any Any TCP 443 242.42.5.104
242.42.5.107
External client/server media Inbound
A/V Edge 242.42.5.104
242.42.5.107
Any TCP 443 Any External client/server media Outbound
A/V Edge Any Any TCP 50000-59999 242.42.5.104
242.42.5.107
External client/server media Inbound
A/V Edge 242.42.5.104
242.42.5.107
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

Polycom Phones with Skype for Business Online

February 29, 2016 by · 6 Comments 

As of the end of January 2016 many currently available Polycom IP handsets and conference phones are now supported with Skype for Business Online with Office 365.  This functionality was first added to the VVX IP handset models back in September 2015 as covered in this previous article.  Direct registration support was just added to the new RealPresence Trio 8800 last month as introduced in the firmware release table here.

This brief article reviews the basic requirements for each family of phones along with the few steps needed to successfully register a device.  Some of this content has already been made available in previous articles but is revisited here for the sake of providing a single referenceable article.  This can help clear up any confusion that long-time users of these phone may have, as well as provide a starting point for the various administration which may be completely new to these products as they move to the new voice capabilities provided in Office 365.

Background

To recap Microsoft has begun providing voice service directly in Skype for Business Online to new and existing tenants of their Office 365 cloud offering.  This new functionality has been called Cloud PBX and is comprised if a few different topologies and options.  Primarily the simplest option is for tenants to purchase additional licenses for their online users to provide PSTN Conferencing and PSTN Calling capabilities.  PSTN Conferencing provides one or more telephone numbers to be added to the user’s Skype Meetings to allow for any PSTN telephone user to dial-in to a meeting from their phone.  PSTN Calling simply means that the users will be assigned a real telephone number and can place and receive calls with any PSTN phone in the country or worldwide, depending on the purchased call plan.  This can now all be done with absolutely no Microsoft servers or services deployed on-premises.

The secondary option is to allow for a tenant to bridge their own on-premises IP-PBX or SIP trunks directly to their online tenancy.  This hybrid technology can be provided by either leveraging a small deployment of Lync or Skype for Business servers on-premises or by using the upcoming Cloud Connector.

At present the following list of devices are supported for use directly with Skype for Business Online as well as Exchange Online using the same set of credentials.  This provides both SIP registration to SfB Online and mailbox connectivity via Exchange Web Services for features like the calendar, calls logs, voice mail, etc.

  • CX600, CX3000
  • VVX 201, VVX 300/301, VVX 310/311, VVX 400/401, VVX 410/411, VVX 500/501, VVX 600/601
  • RealPresence Trio 8800

CX Phones

These two devices in the CX family of IP handsets include a Type A USB port and run Microsoft’s Lync Phone Edition software.

image

At present only the CX600 and CX3000 models are supported; the CX500 is not.  This is due to the fact that the CX500 Common Area Phone does not include a Type A USB port and thus cannot be used with the Better Together method of registering the phone.  Only the PIN Authentication method can be used with the CX500 model and this capability is currently available with Skype for Business Online.

Prerequisites

The only requirements of the phone itself is that the installed firmware be upgraded to at least the minimum supported version for Skype for Business Online.  The following version, or newer, must be installed onto the phone prior to attempting to register it to Skype for Business Online. 

Microsoft Lync Phone Edition for Polycom CX500, Polycom CX600 and Polycom CX3000

Version: 4.0.7577.4463
Released: 5/6/2015
Download: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=23866

As of the publishing of this article Microsoft has released a newer version of this firmware (4.0.7577.4487).  This is the version that is currently available from the download link above and is also supported with Skype for Business Online.

Using a firmware version older than the .4463 release may result in a failure to register the phone and there is no way to upgrade a Lync Phone Edition device without it  first registering successfully.  For those familiar with this device there is a way to support an unregistered device update but that approach is only applicable for on-premises Lync for Skype for Business deployments.  It cannot be used with Skype for Business Online registration.  In the event that a device is still using older firmware then it must be upgraded to at least the .4463 version using some other environment first.

Registration

  • Using a USB cable connect either the CX600 or CX3000 to a Windows desktop PC running either Lync or Skype for Business clients.

  • Enter the appropriate user credentials when prompted. 

image

For most Office 365 users account the the User name will be identical to the Sign-In address.  In hybrid environments with Directory Synchronization in place then it’s possible that the User name will be in different string, but the format must be entered as a User Principal Name (UPN) and the legacy DOMAIN\username format cannot be used with online account.

Management

Only in-band provisioning information is leveraged by Lync Phone Edition devices, no differently than when registered to an on-premises server deployment.  Devices registered to online accounts do not leverage all of the same parameters which are available with traditional on-premises server deployments, but this list is growing over time.  Skype for Business MVP Adam Jacobs has an article which calls the supported commands today.

VVX Phones

These devices include all of the previously and currently available VVX Business Media Phones which run Polycom’s Unified Communications Software (UCS).

image

As of the end of 2015 Polycom has started a hardware refresh on these models which includes newer faster processing internals.  These newer modes are denoted by ending in a ‘1’ instead of the previous models ending with a ‘0’.  So while a brand new VVX 501 may have updated internals over the older VVX 500 the software capabilities today are the same.  Any and all of these models support the same firmware, thus the same software features and capabilities with Skype for Business.

Prerequisites

As with the CX phones the only requirement is that the minimum supported firmware version is installed on the device.  The following version, or newer, must be installed onto the phone prior to attempting to register it to Skype for Business Online. 

Polycom UC Software 5.4.0A

Version: 5.4.0.10182
Released: 9/25/2015
Download: Latest Polycom UC Software Release

As of the publishing of this article there are newer firmware releases for the VVX phone which still support Skype for Business Online but have also added new functionality..  Reference this updated article for the latest recommended firmware version to be used with Skype for Business platforms.

Registration

The various ways to sign into a VVX phones as covered by many other article on this blog are all still applicable, with the exception of PIN Authentication as explained earlier.  For any of the user credential methods the same formatting guidance as what is mentioned above holds true.  The UPN format is required for online registration, thus the Domain field must be left blank.

Enable Lync Base Profile, if it is not already enabled.

  • This can be controlled directly on the phone from the Settings > Advanced > Administration Settings > Network Configuration > Base Profile menu. Or by using the web management UI at Simple Setup > Base Profile.

  • Use either the handset interface (pictured below) or Web Management UI (pictured below), or the Better Together over Ethernet (BToE) application (which looks the same as the CX process above).

  • Enter the appropriate user credentials.

image

image

Management

The VVX platforms supports a variety of in-band provisioning information like the the Lync Phone Edition devices in additional to a large amount of out-of-band options.  These other options can be managed by a variety of options today like basic a provisioning server or third-party applications like Event Zero’s UC Commander.

Trio 8800

The brand new RealPresence Trio 8800 is the only model in this family thus far and runs on the same UCS platform as the VVX phones.  This solution is the subject of a separate in-depth article which will be posted online shortly.

image

Prerequisites

Again the only requirement is that the minimum supported firmware version is installed on the device.  The following version, or newer, must be installed onto the phone prior to attempting to register it to Skype for Business Online. 

Polycom UC Software 5.4.1AA

Version: 5.4.1.17597
Released: 1/29/2015
Download: Latest Polycom UC Software Release for Trio

Registration

As the Trio uses the VVX platform then the registration capabilities are nearly identical.  While the BToE method is not currently supported with the Trio 8800 the other two options are the same.  The web interface looks identical is what was shown above and the user interface directly on the Trio looks like the following.

Enable Lync Base Profile, if it is not already enabled.

  • This can be controlled directly on the phone from the Settings > Advanced > Administration Settings > Network Configuration > Base Profile menu. Or by using the web management UI at Simple Setup > Base Profile.

  • Use either the handset interface (pictured below) or the Web Management UI also (which looks the same as the VVX process above).

  • Enter the appropriate user credentials.

image

Management

The Trio supports all the same management models as the VVX in addition to one new functionality, USB Provisioning. This concept is covered in detail in the new Trio article but basically it’s the ability to copy a provisioning server-like directory to a USB disk and the phone will treat it identical as to how it would read from a centralized network server.  This method allows for quick one-off changes to be applied to a few devices manually.

CX5500

This device is a bit unique as while it is categorized in the CX family it does not run Lync Phone Edition software.  Instead the 5500 model includes an embedded version of UCS just like that found on the VVX phones.

image

Prerequisites

Note that support for direct registration to Skype for Business Online is not yet available in the CX5500 product.  When the supported firmware is release then this article will be updated to reflect that.  That being said the device can be used with SfB Online users via USB tethering, just not yet using the embedded line registration capabilities of the VVX software.

Registration

As the Trio uses the VVX platform then the registration capabilities are nearly identical.  When connected via USB the desktop client’s own registration is used and this device simply acts as a microphone, speaker, and video camera.  The individual line registration over its Ethernet connection is still available.

Management

The CX5500 supports all the same management models as the VVX because it runs the VVX software.

Winter 2016 SkypeUG Meetings

January 26, 2016 by · 2 Comments 

The next round of quarterly Skype for Business Users Group meetings has been announced and scheduled starting this month.

newlogo_title

Latest News

As of last quarter’s events our group has made a few exciting changes.  First and foremost is the rebranding from the Lync Users Group to the Skype for Business Users Group. For discussing and sharing event information on social media keep an eye out for @SkypeUG and #SkypeUG.

This change also includes a brand new web site which will be used for all member registrations, for all locations, going forward.  The events will transition away from the individual Meetup.com pages over the next few quarters.  The new site gives us the ability to roll out new features and content for all event locations uniformly and will allow us to grow as additional cities are added over time.

Event Details

This quarter’s event will be conducted in our familiar two-session format:

The first session, presented by Polycom, will cover an array of available video and audio conferencing products as well as video interoperability solutions for Skype for Business.  A Microsoft Solutions Architect from Polycom will be on-hand to lead the discussion and address any technical questions from the group

The second session will provide an in-depth look at the new features and capabilities of the recently launched Cloud PBX solution in Skype for Business Online.  A local subject matter expert will be leading this presentation.

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Skype for Business.  Food, beverages and additional door prizes will be provided courtesy of the Skype for Business Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

 

For a full schedule of regional events the Skype for Business Users Group Meetups page lists all planned event locations with links to the associated registration page for each regional group.  For anyone who is not yet a member and would like to participate simply visit the site listed above and register for your local group, this will automatically create a new user account for you to use again for all future event registrations..


Chicago Event

As usual I will be hosting the Chicago event downtown.  Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Thursday, January 21th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

 

Additionally I am attending the following events this quarter to provide the sponsor presentations in-person:

  • Jan 26 – Cincinnati, OH
  • Jan 27 – Milwaukee, WI
  • Jan 28 – Kansas City, MO
  • Feb 04 – Boise, ID
  • Feb 10 – Portland, OR
  • Feb 11 – Seattle,WA
  • Feb 16 – Detroit, MI
  • Feb 18 – Charlotte, NC
  • Mar 02 – Atlanta, GA

The remaining events are being handled by regional experts including Dustin Hannifin, Randy Wintle, Adam Jacobs, Jose Mateo, and Paul Gurman.

Updating Trio 8800 Firmware

December 28, 2015 by · 27 Comments 

On the heels of the recent release of the Polycom RealPresence Trio 8800 comes the first firmware upgrades.  In the same fashion as previous articles on this blog covering various Lync and Skype for Business devices like the VVX desktop phones or the CX5500 RoundTable camera this article outlines the various ways that the Trio 8800 can be upgraded.  This article will also be updated over time to include the latest available release along with a documented history of all firmware releases pertinent to Lync and Skype for Business platforms.

image

Firmware Versions

The following table lists Lync-qualified UCS releases which support native device updates and will continue to be updated as future releases are posted online, including links to both Release Notes and the software packages.  The .cab format links are the correct firmware packages for using with the Lync and Skype for Business Device Update Service, while the .ld format is for use with a USB drive or a traditional provisioning server deployment.

Additional releases in the same version will often include an letter revision code (e.g. Rev AB) to indicate a newer version, in addition to the last five digits of the full version number being incremented. 

Version Date Details Links
5.4.0
(5.4.0.12197)
11/20/2015 Initial public firmware release Release Notes
Firmware (.cab)
Firmware (.ld)
5.4.0 Rev AA
(5.4.0.12541)
12/8/2015 Maintenance release including hotfixes and the following enhancements:
* Audio-only participant indicator in conference calls
* New parameter to hide the Sign Out button when already registered
Release Notes
Firmware (.cab)
Firmware (.ld)
5.4.0 Rev AB
(5.4.0.12856)
12/22/2015 Maintenance release including hotfixes and the following enhancements:
* Corrected hardware ID of devices shipped from factory as Lync Base Profile enabled
Release Notes
Firmware (.cab)
Firmware (.ld)
5.4.1 Rev AA
(5.4.1.17597)
1/29/2016 Release including hotfixes and the following enhancements:
* Skype for Business 2015 Server and Online registration and provisioning support
* USB audio device support for Lync 2013 and Skype for Business 2015 clients
* Smart Login which hides PIN Authentication option on non-configured networks
Release Notes
Firmware (.cab)
Firmware (.ld)
5.4.2 Rev AB
(5.4.2.5400)
4/6/2016 Release including hotfixes and the following enhancements:
* Added Forward Error Correction (FEC) for Lync/SfB video calls over X-H264UC
* Support for sharing RDP content in Lync/SfB multiparty conference calls
Release Notes
Firmware (.cab)
Firmware (.ld)

 

Also be aware that currently the firmware releases for Trio are not lock-step with the existing VVX releases, nor with the CX5500 releases.  While each of these platforms are currently using versions in the 5.4.x branch the actual release versions may or may not have the exact same build number between the different platforms.  Note that it is not possible to load the wrong firmware on a device in the event that the software packages are somehow mixed up between these various products.

Update Processes

From a software standpoint the Trio platform is based on the same Unified Communications Software (UCS) platform that the entire line of modern VVX phones use, thus the majority of upgrade options are the same.

Web Management Interface

As covered in various other VVX articles this process is unchanged in the Trio.  The same steps listed at the beginning of this recent article can be used to upgrade the phone firmware if not already familiar with it.  If the Lync Base Profile is currently enabled on the Trio then the web management interface will be disabled by default.  This must first be re-enabled either manual from the phone or via a centralized provisioning configuration before the UI can be accessed remotely on the phone to perform the upgrade process.

Provisioning Server

As previously covered in this article a centralized provisioning server can be deployed, or an existing deployment designed for other Polycom SIP phones can be leveraged by the Trio.  In fact there is nothing else which must be configured is the environment is already setup to support existing VVX phones.  As stated because the Trio uses the same base UCS platform then the Trio will adhere to any existing DHCP, LLDP, or other network configuration parameters specific to the IP phones.

  • To prepare the provisioning server with the the latest firmware release for the Trio simply download the desired .ld package from the table at the top of this page and then extract the 3111-65290-001.ld file into the appropriate directory on the central provisioning server.

Also note that Microsoft partner Event Zero includes a Provisioning: Polycom module for their popular UC Commander solution that uses this same model.

Device Update Service

The Microsoft native firmware update process that was added to Lync Server 2010 to support Lync Phone Edition devices has been supported by Polycom VVX phones for over two years now, as of the initial 5.0 firmware release.  Both Lync Server and Skype for Business Server platforms include this in-band firmware updating service and leveraging this capability is inherently available in the Trio as well.  This previous article outlines exactly how to configure VVX phones to utilize this and the same configuration applies to the Trio.

  • To prepare the Lync/SfB device update service with the latest firmware release for the Trio simply download the desired .cab package from the table at the top of this page and then extract the package as outlined in the article linked above.

USB Flash Drive

While the Trio can be updated in all the same ways that VVX phones already support there is a new capability provided with the Trio: using the local USB port.  In fact this is a very similar process to what the CX5100/5500 also supports for firmware upgrading.  (Note that while the some VVX desktop phone models do include a standard USB port they do not currently support this USB upgrade method.)

While most any USB flash drive should work for this process it is recommended to use a USB 2.0 drive.  And because the firmware is only a few hundred megabytes then pretty much any available USB drive can be used.

  • Format the USB drive as FAT32

image

  • Download the desired firmware version from the table at the top of this article.  Use the .ld link to download the proper package format needed for the USB process.  (The .cab file format is not valid for this procedure.)

  • Extract the master configuration file (000000000000.cfg) and the Trio firmware file (3111-65290-001.sip.ld) .

image

  • Save these files to the root of the USB drive.

image

  • Insert the USB drive into the USB Type A port on the left side of the phone’s front leg, as shown in the photo below.

image

The Trio will recognize that the inserted drive contains firmware information and will automatically display the USB Provisioning menu on the unit’s screen.

  • Enter the device administrator password. (The default password is 456 which is the same as the VVX phones.)

  • Tap Yes to confirm and immediately begin the USB firmware update process.

image     image

Once confirmed the notification icon of a spinning gear should appear in the upper right corner of the display.  In addition if the USB drive contains an activity LED then it should be flashing to indicate that the phone is currently reading the files from the disk.

image

After a few minutes the USB drive activity light should stop flashing which means the files are finished copying to the phone.  The gear icon should continue to rotate for a few more minutes though as the Trio is still processing the firmware files.

  • Leave the phone alone for a few more minutes and it will automatically reboot upon completion of the firmware update.

The entire process after confirming the administrator password should take less than 10 minutes, so as long as the gear icon is still spinning do not reboot the phone, just wait for the eventual reboot.

  • After the Trio is back online the new version number can be verified from the following menu: Home > Settings > Status > Platform > Application > Main

image

Troubleshooting

On some early models of the Trio the USB process may not work as described above. If after inserting the USB drive the phone does not appear to recognize the firmware package and does not automatically prompt for the administrator password then an additional manual step may be required.

  • Rename the “3111-65290-001.sip.ld” firmware file on the USB drive to simply “Trio8800.sip.ld” and then reinsert the USB drive into the phone.

The affected models should now successfully recognize the firmware file and trigger the update process. Once the 5.4.0 Rev BB release has been applied to the phone then this manual step will no longer be required for future updates as the phone will now recognize the correct firmware file names automatically.

Skype for Business and Exchange UM Integration

October 30, 2015 by · 1 Comment 

This article covers the configuration steps for introducing voice mail support into a Skype for Business (SfB) Server 2015 environment by integrating with Exchange Server 2013 Unified Messaging (UM).  Note that this series of Exchange integration articles leverages Exchange Server 2013 and will continue to do so for continuities’ sake.  Microsoft has recently released to the public the installation package for Exchange Server 2016 for use in on-premises deployments.  These articles also apply when using Exchange Server 2016, with one exception related to Instant Messaging integration which will be the next topic addressed in a future article.

The guidance provided here is a more detailed look at what is partially covered in the official TechNet documentation.  The following configuration covers generally the same approach used to integrate previous version of Lync Server and Exchange Server which was outlined in this older article.  Unfortunately the official documentation is partially incomplete and is also split across the separate product guides for SfB and Exchange Server, making it difficult to understand what is needed for a successful integration.  This article will tie all steps into a single set of instructions which can be completed linearly.

One caveat to be aware of is the recommendation to configure UM integration before enabling Instant Messaging (IM) integration with Outlook Web Access.  Configuring UM first will enable automatic discovery of the Exchange environment in Skype for Business using the configured SIP domain namespace.  Establishing this first will mean that when the IM integration is tackled there will be no need to defined the Exchange Server as a third-party Trusted Application in the SfB topology.  If these are configured in the opposite order, meaning that the Instant Messaging integration is performed first, then the setup of Unified Messaging can break the IM integration due to duplicate, conflicting entries for the Exchange Server in SfB.  Thus is is recommended to start with UM integration and follow these articles in the order they were posted.

The sections in this article are outlined in the following configuration steps.  The steps in red are part of the Exchange Server configuration and the steps in blue are performed on the Skype for Business side.

image

Confirm Prerequisites

Assumptions made for the environment used with this article are that Exchange Server 2013 has been deployed with a relatively recent service pack or cumulative update applied.  The version used in this guide is Exchange Server 2013 CU8 (15.00.1076.009).

Partner Application

The prerequisites steps included in this previous article must be completed first to insure that the Partner Application relationship has already been established between Skype for Business and Exchange.  Other SfB features provided by Exchange like High Resolution Photos or the Unified Contact Store can be enabled in any order, only after the Partner Application relationship is established.

Exchange Certificate

A long standing best practice surrounding the Exchange Server Certificate has to do with how Lync Server parsed the SSL certificate presented to it by the Exchange Server during establishment of TLS communications.  The Lync Server would ignore the certificate’s Common Name (CN) and look at only the Subject Alternative Name (SAN).  With further changes coming on how third parties issue SSL certificates it is becoming more common to focus on the SAN field as the CN field will start to become optional, and eventually even defunct.  That being said the same best practice to making sure to always duplicate the CN value in the SAN still holds true.  Using the Exchange Server certificate wizard to create requests will allow this type of configuration.  At this point it is unknown if this limitation has been addressed in Skype for Business Server 2015 but using a properly formatted certificate makes this a moot point.

  • Using the Exchange Management Shell validate that the existing certificate will be sufficient for use with Skype for Business with the following Get-ExchangeCertificate cmdlet.

Get-ExchangeCertificate | fl

image

As highlighted above the Certificate Domains field lists all of the Subject Alternative Names on this certificate which includes the Exchange Server’s FQDN which is critical for UM integration to function.  In this example the Subject field shows that the certificate’s Common Name is set to mail.jdskpye.net which is also duplicated in the SAN field.  Regardless of what the CN is set to make sure that value is duplicated in the SAN (as per general best practices) and that the server FQDN is included in the SAN field.

This configuration is the most common and allows a single SSL certificate to be used for all roles on the Exchange Server.  In more complex environments with separate Exchange UM servers or other configuration it is possible, but not necessary, to use a separate dedicated certificate on the UM service.

Also make note of the Thumbprint value for the desired certificate as it will be used during the configuration in the next section.


Configure UM Dial Plan

The steps in this section are all performed on the Exchange Server using either the Exchange Management Shell or Management Console.

Create New UM Dial Plan

  • Using the Exchange Management Shell create a new UM dial plan with the following New-UMDialPlan cmdlet and the desired plan Name (e.g. Chicago).

New-UMDialPlan -Name "Chicago" -VoIPSecurity "Secured" -NumberOfDigitsInExtension 4 -URIType "SipName" -CountryOrRegionCode 1

image

In this deployment the VoIP Security option Secured is used so that both SIP signaling traffic and RTP media traffic will be transmitted between SfB and Exchange using an encrypted TLS communications.  Alternatively opting to use the SIP Secured setting would only encrypt the signaling traffic while all media traffic would be transmitted unencrypted.

Additionally a value of 4 is selected for the number of digits in extension numbers on the pattern 312-555-xxxx where the last four digits are treated as the user’s extension.

  • Using the Exchange Management Shell run the following cmdlet to set the following recommended parameters.

Set-UMDialPlan "Chicago" -ConfiguredInCountryOrRegionGroups "Anywhere,*,*,*" -AllowedInCountryOrRegionGroups "Anywhere"

    Configure UM Services

  • Assign the the UM server to the new UM dial plan and configure support for both TCP and TLS connections with the following cmdlet.   The Identity parameter is the Fully Qualified Domain Name (FQDN) of the Exchange Server (e.g. exch.jdskype.net).

Set-UmService -Identity "exch.jdskype.net" -DialPlans "Chicago" -UMStartupMode "Dual"

image

Now that TLS is enabled for the UM service the Exchange Server certificate needs to be assigned to the service to support TLS communications for signaling and media.

  • Enter the following cmdlet using the Thumbprint value of the same certificate that was queried in the earlier prerequisites steps to insure that the proper certificate is assigned to the UM service.

Enable-ExchangeCertificate -Server "exch.jdskype.net" -Thumbprint "372EDC073A1C21C91FE2C6045FD70B26AD5E239C" -Services "UM"

image

  • To commit these changes and enable TLS communications on the UM service it needs to be restarted, which can be performed quickly from PowerShell using the following cmdlet.

Restart-Service MSExchangeUM

  • Next perform the same configuration as above on the UM Call Router service with the following cmdlet.

Set-UMCallRouterSettings -Server "exch.jdskype.net" -UMStartupMode "Dual" -DialPlans "Chicago"

image

  • The UM Call Router service also need to be assigned to the same certificate as the UM service.

Enable-ExchangeCertificate -Server "exch.jdskype.net" -Thumbprint "372EDC073A1C21C91FE2C6045FD70B26AD5E239C" -Services "UMCallRouter"

image

  • Just like the UM service the UM Call Router service needs to be restarted to enable the new configuration.

Restart-Service MSExchangeUMCR

Customize UM Dial Plan

When the new UM dial plan was created the Exchange Server will have automatically created a default UM Mailbox Policy.  This object will be named with the label ‘Default Policy” appended to the dial plan’s name (e.g. Chicago Default Policy).

The TechNet documentation seems to omit this fact and instructs the creation of another UM mailbox policy.  A simpler approach is to just modify the default object using the following cmdlet.

  • To configure the recommended AllowedInCountryOrRegionGroups parameter use the following cmdlet.

Get-UMMailboxPolicy | Set-UMMailboxPolicy -AllowedInCountryOrRegionGroups "Anywhere" -MinPINLength "4" -AllowCommonPatterns $true

As only a single policy exists then instead of querying for and entering the name of the default mailbox policy use the Get-UMMailboxPolicy cmdlet to automatically pass the results to the cmdlet as shown above.  Additionally some optional parameters were configured to allow for a four digit PIN to be defined instead of the default 6 digit length.  While not recommended for production environments this can be a welcome time saver in lab or test environments.

Define Attendants

The next step to be performed on the Exchange Server is to define and configure the Auto Attendant and Outlook Voice Access (formerly referred to as ’Subscriber Access’) numbers.

  • Using the Exchange Admin Center navigate to the Unified Messaging > UM Dial Plans section and then open the dial plan that was created earlier (e.g. Chicago).

  • Click the Configure button to edit the dial plan and then select the Outlook Voice Access section.
  • Enter the desired phone number to be assigned to the Outlook Voice Access attendant in the proper +E.164 format (e.g. +13125551001) and then add it to the configuration using the ‘+’ button.

image

  • Click Save to return to the main dial plan window and then scroll down to the UM Auto Attendants section.

  • Click the ‘+’ button to create a new Auto Attendant and then enter a unique Name (e.g. ExchangeAA), enable the auto attendant, and then enter another unique phone number (e.g. +13125551000).

image

Traditionally Exchange does not do well with spaces in auto attendant names and thus it is still recommended to follow that guidance.

  • Click Save to and then Close to commit these changes to the server.

Enable Users

To validate that the UM configuration is functional then at least one user account must be enabled for Unified Messaging.  This process can be completed from either the management console or shell.

  • To enable the first account launch the Exchange Admin Center which should default to the Recipients > Mailboxes section.

  • Highlight the desired user account and then select Enable under the Unified Messaging section in the right-hand window pane.

  • In the Enable UM Mailbox window browse for and select the default mailbox policy (e.g. Chicago Default Policy) and then advance to the next window.

image

  • Define a four digit Extension Number if one is not already populated and then, if desired, enter a custom PIN and unselect the option to force the user to change this PIN after they sign in.

image

In this example the users extension was pre-populated due to the existence of a defined telephone number in the user’s Active Directory object.  Because the dial plan policy was created to use 4-digit extensions then Exchange will automatically take the last 4 digits of the user’s phone number (e.g. 1100).

  • Complete the wizard to save the changes and enable this account for Unified Messaging.

Alternatively the same steps can be performed using Exchange PowerShell cmdlets, so a second account configuration using this process is also covered as an example.

  • Using the Exchange Management Shell enter the following cmdlet to perform roughly the same exact configuration on another existing Exchange user. 

Enable-UMMailbox -Extensions 1101 -SIPResourceIdentifier "steve@jdskype.net" -Identity "JDSKYPE\steve" -UMMailboxPolicy "Chicago Default Policy"

image

Make sure to enter a unique extension or to omit that parameter if the account’s phone number is already populated with the desired information.  The PIN was not manually set on this account which means Exchange will have automatically assigned a random PIN and then sent an email to the user’s mailbox with that information.

Configure UM IP Gateway

This step is handled by a script which creates the UM IP Gateway and IP Hunt Group as well as grants permissions to Skype for Business Server to read specific UM-related objects in Active Directory.

Make sure to allow for any outstanding AD replication to complete before running this script so that the newly created UM dial plan and any other changes are read by the script in their updated state.  If run too soon then sometimes the Dial Plans listed in the last line of the script output will display as “not found” even though the configuration is correct up to that point.  If that happens it is safe to simply re-run the script, even multiple times if needed, as it will identify any previously successful configuration and thus report that no new changes were applied in those cases.

  • Using the Exchange Management Shell execute the ExchUCUtil.ps1 script located in the Exchange Server’s Scripts directory, as shown in the path below.

cd "C:\Program Files\Microsoft\Exchange Server\V15\Scripts"

C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\ExchUCUtil.ps1

image

Note that in this example the Skype for Business Front End server shown at the bottom of the script output displays “{(not found)}” for the DialPlans field.  The value should be displayed as the UM Dial Plan name (e.g. Chicago).  As mentioned above this can usually be resolved by going back and re-executing the script after a few minutes have passed.

  • If this issue appears then repeat the previous step until the results successfully report the expected dial plan as shown below.

image

To validate the creation of the UM IP Gateway open the Exchange Management Console and then navigate to the Unified Messaging > UM IP Gateways section.  Refresh the page if the new gateway does not appear at first.

image


Create Attendant Contacts

With the configuration now complete on the Exchange Server the remainder of the steps in this article are performed on the Skype for Business Front End server.

The OcsUmUtil.exe utility is still used to create the Active Directory contact objects for Skype for Business Server to resolve and locate the Exchange Outlook Voice Access and Auto Attendant services.

In older versions of Exchange Server it was required to create an Enterprise Voice Dial Plan in OCS/Lync that matched the exact FQDN of the Exchange UM Dial Plan.  Since the release of Exchange Server 2010 SP1 this is no longer required as indicated by the informational text at the bottom of the utility.  The UM Dial Plan will be automatically discovered and thus no additional Enterprise Voice configuration is required on the SfB Server to enable UM integration.

  • Launch the OcsUmUtil.exe program located in the Skype for Business Server’s Support directory, as shown in the path below.

C:\Program Files\Common Files\Skype for Business Server 2015\Support

  • Click Load Data and the Active Directory forest name should appear in the Exchange UM Dial Plan Forest field.

image

  • Click Add to create the first contact for Outlook Voice Access, which is still referred to as the Subscriber Access number in this tool.

  • Select the desired AD Organizational Unit to save the new contact object and then enter a unique Name for the contact (e.g. ChicagoSA).

image

While the remainder of the fields can be left with the default entries it is a common practice to change the SIP Address to a less confusing SIP URI.  In this examples the default value (e.g. Chicago.jdskype.net@jdskype.net) has been changed to a simpler string (e.g. ChicagoSA@jdskype.net).

  • Click OK to save the configuration for the Subscriber Access contact.

  • Click Add to create the second contact for the Auto Attendant.

  • Change the Contact Type to Auto-Attendant and then enter a unique Name for the contact (e.g. ChicagoAA).  The same Organizational Unit value as defined for the previous contact should already be populated.

image

Just as before either retain the default SIP address or edit it to use a customized address as shown in this example (e.g. ChicagoAA@jdskpye.net).

  • Click OK to save the configuration for the Auto Attendant contact.

  • Close the Exchange UM Integration Utility and then open Active Directory Users and Computers to browse to the target OU and validate that the new contacts were successfully created.

image

Verify Integration

Now that the integration on both server platforms is complete the final step is to test UM connectivity between Exchange and Skype for Business.

  • Sign into a Skype for Business client with one of the UM-enabled user accounts (e.g. jeff@jdskype.net) then search for the SIP URI of the Auto Attendant and place a Skype Call to the contact.

image

At this point one of two things will occur: the call will work or it will not.  If the integrated voice response is “Thank you for calling Microsoft Exchange auto attendant” then the integration was successful.  If not then the following common issues could be the root cause.

Call Failure

If the call fails without any response from the Exchange UM Server then one of the most common reasons, other than a simple configuration mistake, could be that the Exchange UM IP Gateway configuration script did not complete as mentioned earlier in this article.

  • Check the Lync Server event log on the Skype for Business server to see if the following error message was reported at the same time as the attempted call.

Log Name:      Lync Server
Source:        LS Exchange Unified Messaging Routing
Event ID:      44008
Task Category: (1040)
Level:         Error
Keywords:      Classic
Computer:      FE.jdskype.net

Description:
Dial Plan Unknown

Dialplan [Chicago.jdskype.net] is not recognized by routing application
Cause: Dial plan does not exist, or Skype for Business Server 2015 does not have permission to read the relevant Active Directory objects.

Resolution:
If the dialplan is valid, then run exchucutil.ps1 in appropriate Exchange forest to give permission to Skype for Business Server 2015. If the dialplan is not valid, then clean up proxyAddresses attribute for the affected users.

If this message exists then this is an indication that the ExchUmUtil.ps1 script that was run earlier did not configure the UM IP Gateway correctly.  As pointed out earlier the script may have failed to associate the UM Dial Plan to the gateway, thus causing this error on the Skype for Business server.  Return to that step to re-run the Exchange script and validate that the dial plan is displayed correctly, which should clear this error and then allow for calls to reach the UM attendant services.

Unexpected Response

If the call successfully connects to the attendant but an unexpected response is heard then this could point to a different issue.  If the interactive voice response was “Please call back later. Goodbye.” then this typically occurs when the UM configuration is brand new and the server has not yet had a chance to generate the grammar speech files.  As documented in this blog article the pending generation process can be expedited by restarting the Exchange Mailbox Assistants service.

  • Using PowerShell enter the following cmdlet to quickly stop and restart the Mailbox Assistant service.

Restart-Service MSExchangeMailboxAssistants

  • View the Application Event Log on the Exchange server to verify that the following entry has been logged after the service has been running for a few minutes.

Log Name:      Application
Source:        MSExchange Unified Messaging
Event ID:      1613
Task Category: UMCore
Level:         Information
Keywords:      Classic
Computer:      EXCH.jdskype.net

Description:
Speech grammar generation started for "Enterprise". Run ID: "7a97b157-b74f-4a21-b667-faf56e85f047", Recipient type: "User"

At this point a call to the Auto Attendant should result in the proper welcome message.

This concludes the setup of Exchange Unified Messaging with Skype for Business Server 2015.  If following along with this entire series of Exchange Server integration articles for Skype for Business 2015 then at this point the Partner Application has been established and leveraged to enable High Resolution Photos and now Unified Messaging.

Future articles will address Instant Messaging integration with Outlook Web Access as well as other features like IM archiving and enabling the Unified Contact Store.

October 2015 Lync Users Group

October 19, 2015 by · 6 Comments 

The next round of quarterly Lync Users Group meetings has been scheduled and announced for this month.

image

Event Details

This meeting will be conducted in our familiar two-session format:

The first session, presented by Integrated Research, will be a deep dive into Monitoring Applications in Skype for Business.

The second session will start with a review of existing and newly launched Skype for Business Qualified Devices to be followed by an Open Discussion Forum (time permitting). 

Industry Experts will be on-site to deliver these presentations and help answer any questions related to Lync.  Food, beverages and additional door prizes will be provided courtesy of the Lync Users Group and its official sponsors.

Western U.S.

Central U.S.

Southern U.S.

Eastern U.S.

 

For a full schedule of regional events the Lync Users Group Locations page lists all planned event locations with links to the associated Meetup.com page for each regional group.  For current members if your region’s event is not yet scheduled just make sure that your notification options are configured so that you’ll get an alert when the new event is posted.  For anyone who is not yet a member and would like to participate simply create a new Meetup account (or use an existing one) and join your local group.


Chicago Event

As usual I will be hosting the Chicago event downtown.  Food will be ready at 5:30 so come early if you can to spend time socializing with the group before the presentations begin at 6:00.

Date Location Address
Tuesday, October 20th
5:30PM – Food and Networking 
6:00 PM – Presentation Kickoff
Chicago UC Users Group Microsoft Technology Center 
200 East Randolph Drive, Suite 200 
Chicago, IL 60601

High Resolution Photos in Skype for Business

October 6, 2015 by · 5 Comments 

This basic article covers a few ways for users and administrators to import and manage contact photos in Skype for Business Server, once the required Exchange Server integration has been completed.  Without leverage Exchange Server for storing contact photos then the only options available

Prerequisites

In order to use the Skype for Business Server 2015 functionality described in this article an Exchange Server must first be deployed in the environment and configured as a Partner Application.  This prerequisite configuration must be performed successfully prior to attempting the steps shown in this article.

Outlook Web Access

There are multiple ways for a user to go about changing their own photo, given that the capability has not been specifically disabled by an administrator.  The original approach which is still available is to use the menu option available in Outlook Web Access.

  • From any server or workstation connect to the Exchange Server Outlook Web Access URL and sign-in with the desried user’s credentials.

http://mail.jdskype.net/owa

  • Click on the user’s name in the upper-right hand corner and from the drop-down menu click the Change link below the photo placeholder.

image

  • Click the Folder Icon and select the desired photo file.  For the best image quality make sure to use a file that matches the maximum supported resolution of 648×648 pixels.  Smaller resolutions can be used as Exchange Server will scale them accordingly, but make sure that the photo’s aspect ratio is perfectly square (1:1).

  • Click Save to assign this as the current photo to the Skype for Business user.  The new photo should appear in the menu now.

image

  • Now sign in with the same user account to a Skype for Business client to see if the new photo appears as expected.

image

Skype for Business Client

An even easier method first made available in the Lync 2013 client is also still available in the Skype for Business client user interface.  It is basically the same process because OWA is used to import the photo but is accessed from a different page.

  • In the Skype for Business client click on the circle headshot  icon where the user’s own photo would appear.  This is a shortcut that simply opens the client Options window and goes directly to the My Picture section.

image

  • If not already enabled select the Show my picture option and then click on the Edit or Remove Picture button.

image

This action will open the photo page on the user’s Account Information page in the Exchange Control Panel (ECP) website.  This is a slightly different page then what was used in the previous section but will work just the same.

  • Sign into Outlook Web Access if prompted and then select the desired photo and click Save.

image

Administrator Approach

Alternatively to import photos for other Skype for Business users an administrator can use the following set of commands on the server, as outlined in this TechNet article.

  • Using the Exchange Server Management Console run the following two commands to import a file of the same size and format requirements as used above into the desired user account.

$photo = ([Byte[]] $(Get-Content -Path "C:\temp\photo2.jpg" -Encoding Byte -ReadCount 0))

Set-UserPhoto -Identity "JDSKYPE\steve" -PictureData $photo -Confirm:$False

image

Note that the official documentation shows utilizing three separate cmdlets to store, import, and then save the photo.  But when using on Exchange Server 2013 CU3 or newer it appears that the third command to save the change is no longer applicable.  Attempting to execute it as shown in the documentation will result in the error “No photo with class ‘IPM.UserPhoto.Preview’ exists.”  The photo is already applied and saved with the second command so the third appears to have been made redundant.

  • To validate that the image was successfully imported go to the following URL in a web browser and the photo should appear in the window.  Enter the SMTP address of the desired user account in the URL where indicated in red.

https://mail.jdskype.net/ews/Exchange.asmx/s/GetUserPhoto?email=steve@jdskype.net&size=HR648x648

Now that Exchange Server has been successfully integrated with Skype for Business Server then additional features beyond this can be deployed.  More articles covering other Exchange Server integration steps can be found here.

Comparison

While the small contact photos used throughout Skype for Business clearly do not seem to take advantage of the higher resolution image, there is place where the quality (or lack there of) of a photo can be clearly evident.

  • From a different Skype for Business client place a call to the user with the new photo and then maximize the call window.  The called user’s photo will occupy the majority of the window by default.

image

The edited image above shows the difference in a low resolution and high resolution photo.  On the right side is a 48×48 pixel photo stored in in the user’s Active Directory object which was been upscaled by the Skype for Business client.  The left portion shows the same call in the same window size but with the 648×648 pixel photo as provided by Exchange Server.

Additional articles in this series focusing on Exchange Server 2013 integration capabilities with Skype for Business 2015 can be found here.

Video Based Screen Sharing in Skype for Business

October 2, 2015 by · 17 Comments 

Video Based Screen Sharing (VBSS) is a new Skype for Business client capability that has for the most part flown in under the radar.  There is currently very little information available about this new functionality, and as with anything not well understood it seems to be creating more confusion than warranted.  Most of the questions have been centered around the topic of video interoperability, thanks in part to some generalized statements.

This article will explain what this new functionality is, as well as what it is not.  With a more complete understanding of VBSS and its potential roadmap then the answers to various interoperability questions should be quite clear.

The Office 365 Roadmap currently lists this feature under the In Development section, but it is now available with the release of the Skype for Business 2016 client that is included in Office 2016.

image_thumb[8]

Background

Up until now there have been only a few places that this new feature has been discussed in the public realm, and most of that was before there was even a name for it.  Generically speaking it was communicated as some level of native support for “H.264 content sharing” coming to the Skype for Business platform.  Obviously companies looking to address interoperability scenarios with SfB and their standards-based video conferencing systems would sit up and take notice to these claims.

Unfortunately the problem with that simple statement is it can be interpreted differently depending on whom is reading it.  For those with a foundational understanding in the traditional video conferencing world that statement can sound odd.  The H.264 standard is simply a video codec which could include anything in the actual image.  The transmitted pixels could be arranged to display a smiling face captured by a camera, or instead show the familiar view of a user’s PowerPoint application captured by a video output device of some sort.  While a standard H.323 or SIP call can support sending a second stream of video displaying this content the actual standard that makes this possible are not H264 itself.

A call established using the H.323 call control platform will actually use the H.239 standard for establishing content sharing, where as a call that instead leverages a standard video SIP platform will use Binary Floor Control Protocol (BFCP) for establishing content.  In the Microsoft world content sharing has leveraged Remote Desktop Protocol (RDP) since this ability was first provided in Office Communications Server 2005.

The most significant difference between these two workflows are the lines of communications that are established, and how they are established, even though the resulting experiences are very similar.  For example:

  • On one side a Skype for Business call will use Microsoft’s SIP platform to setup and negotiate a call or conference, leverage X-H264UC as the codec for the video streams, maybe opt for SILK as the audio codec, and then utilize RDP to share the desktop from one participant.  Each of each lines of communications are separately established connections between the same endpoints, with their own streams and bandwidth utilization.

  • In comparison the same scenario in the video conferencing world might utilize H.323 to establish the call signaling, H.264 AVC as the video codec, G.722 as the audio codec, and then leverage H.239 to send the desktop screen of a computer in a conference room connected to a VGA cable.

The delivery mechanisms for sharing content in these two worlds are very different though.  While the traditional video conferencing systems use H.239 or BFCP to control the transport of the content, the actual content itself is encoded using a video codec and is sent within the same allowed bandwidth defined for the specific call.  The content essentially steals bandwidth away from the main video when needed.  Normally the content is encoded as an H.264 AVC video stream, but could in some cases fall back to a legacy H.263 stream.

Yet on the Lync/SfB side an additional session is created for content outside of any established video or audio sessions (if they even exist) and will transmit RDP as media over TCP, consuming additional bandwidth on top of whatever the audio and video sessions are already using.  A content sharing session can be established all by itself in the Lync/SfB world, but with traditional video conferencing a video call must first be placed and then content can be added to that existing call.

These inherent differences in content encoding and transport are why traditional video content sharing has always been able to provide smoother motion, include audio in the stream, and use less overall bandwidth.  Comparatively content sharing in Lync/SfB has been of much sharper quality and resolution but severely limited in frame rate and typically more costly on the network.

In an initial step to improve the content streaming quality of RDP the July 2013 cumulative update for Lync Server 2013 introduced a new parameter (EnableHighPerformanceP2PAppSharing) for peer to peer application sharing.  This optional  setting still utilized RDP for the data stream but boosted the frame rate a bit (as well as the bandwidth usage). A side-by-side comparison of the default and high performance RDP options can be seen in this blog article by Skype for Business MVP Michael LaMontagne.  While the frame rate was slightly improved it was still very short of the frame rate needed to display video or other moving animations sufficiently.

Seeing that RDP has been stretched to its limits in terms of providing quality streaming another approach was taken with the Skype for Business client.  The addition of Video Based Screen Sharing helps address some of these limitations while at the same time not negatively impacting the overall image quality that RDP has provided to date.

VBSS

The primary change here is that Skype For Business clients can now utilize something other than RDP to share content between clients.  Understand that currently this capability is only provided in the Office 2016 version of the Skype for Business 2016 client, starting with the public release of the 16.x client version (e.g. 16.0.4266.1003).  The rebranded Lync 2013/Skype for Business 2015 15.x client installations do not include this capability and will continue to share content using RDP.

VBSS is also only available in peer-to-peer SfB sharing sessions and is only utilized on the Present Desktop sharing option.  Selecting any of the other sharing options like Present Program or Present PowerPoint Files will still behave the same as in previous clients.  The PowerPoint File sharing option leverages the Office Web Apps Server which does not actually stream the content and thus VBSS is not applicable here.  The Present Program option does not currently take advantage of VBSS so RDP at a low frame rate is still used.

The Application Sharing service on the SfB Front End Server does not support this feature so content shared into Skype for Business meetings will also continue to use RDP regardless of the individual client versions.

Additionally in the single use-case where VBSS can be used the content sharing is provided as view-only.  If remote control is requested by or given to the receiver then the content stream will seamlessly fall back to using RDP.  This switch is invisible to the user except that the frame rate of the content will immediately drop as VBSS is replaced with RDP for delivery of the content.  Releasing control will not upscale the content back to using VBSS, it will remain as RDP for the duration of the sharing session.  Stopping and restarting the sharing session will allow VBSS to be used again.

Interoperability

Just as the addition of X-H264UC as the primary video codec in Lync 2013 did not magically remove all video interoperability hurdles with Lync, using this same codec for content streaming is no different.  As stated previously this is not standards-based H.264 content sharing, just like video in Lync/SfB is not the same as H.264 AVC payloads.

In the field most video interoperability solutions available today are focused on conferences, not individual peer to peer calls.  Simply stated, VBSS is no different than the addition of SILK to some of the Lync and SfB clients.  These clients can choose to utilize the newer codec when negotiating peer calls between each other, but when involved in larger multiparty conferences are still limited to the codecs supported by the server.

That is not to say is there are no inherent benefits here.  Clearly any improvements built on top of this workflow could be leveraged by additional development by third parties. For example video conferencing systems which already include native support for RDP content sharing could in theory be updated to support VBSS to further improve quality.

Comparison

The following video clips were recorded with a camera showing the actual display of a Windows workstation receiving the same shared content in two separate tests.

  • In the first video the typical RDP experience is shown which is clearly evident by the very low frame rate.
  • The second video shows the same YouTube video being streamed from the same SfB user but this time VBSS is used and the frame rate improvement is obvious.

  

These embedded videos may be muted by default but if the playback audio is heard understand that the camera used to capture these clips has picked up the sound from the source (sharing) PC’s speakers located in the same room.  The content sharing in SfB is still limited to video only and does not deliver any audio from the sharing client to the receiving client.  To perform the same side-by-side tests simply switch between using Present Desktop (which uses VBSS) and Present Program (which uses RDP).

Using some basic math and monitoring tools the following behavior was observed when sharing a full motion video at full screen for an elapsed time of 4 minutes.

  • The RDP session averaged 2.83 Mbps with 85MB of data transmitted
  • The VBSS session averaged 3.5 Mbps with 105MB of data transmitted

Based on these numbers VBSS consumed roughly 25% more bandwidth than when RDP was used, yet increased the frame rate by much more than that percentage.  The RDP session displayed about 3 frames per second at best while VBSS could provide 7.5, 15, or 30fps streams based on X-H264UC specifications.  Note that only a single Temporal Layer is transmitted as this is a P2P session and multiple frame rates would not be applicable.

Under the Hood

When selecting the Present Desktop option in the Skype for Business 2016 client a SIP invitation message will be sent to the other party including the following Session Description Protocol (SDP) messaging.

  • The initial SDP data will look no different than what was seen in the past.  This is because the first portion of the SDP messaging always includes the legacy ICE v6 declaration for communicating with Office Communicator 2007 and older clients, as denoted by the ms-proxy-2007fallback string,  Clearly these old clients cannot support VBSS so there is no need to advertise any new capabilities here.  Only a single media session (m=application) is declared here and the media type advertised is RDP (a=rtpmap:127).

Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <2c1ace88f86f32a5cccffd4177e8a2a1@jdskype.net>
Content-Disposition: session; handling=optional; ms-proxy-2007fallback

v=0
o=- 0 0 IN IP4 123.45.67.89
s=session
c=IN IP4 123.45.67.89
b=CT:53980
t=0 0
m=applicationsharing 58323 TCP/RTP/AVP 127
a=ice-ufrag:lbTM
a=ice-pwd:RFjNRfTU4UkaOAKa0Xivn64+

<candidate and crypto data snipped>

a=setup:active
a=connection:new
a=rtcp:58323
a=mid:1
a=rtpmap:127 x-data/90000
a=rtcp-mux
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:rdp
a=x-applicationsharing-contentflow:sendonly

  • The next grouping of SDP data is what will be used if the receiving client is running at least Office Communicator 2007 R2 or newer.  Note that the Content-Disposition parameter no longer includes the fallback string; this section leverages ICE v19.  The differences highlighted below outline how this new capability is advertised.

Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-ID: <2c1ace88f86f32a5cccffd4177e8a2a1@jdskype.net>
Content-Disposition: session; handling=optional

v=0
o=- 0 1 IN IP4 123.45.67.89
s=session
c=IN IP4 123.45.67.89
b=CT:53980
t=0 0
a=x-mediabw:applicationsharing-video send=10000;recv=10000
m=applicationsharing 58323 TCP/RTP/AVP 127
a=ice-ufrag:lbTM
a=ice-pwd:RFjNRfTU4UkaOAKa0Xivn64+

<candidate and crypto data snipped>

a=setup:active
a=connection:new
a=rtcp:58323
a=mid:1
a=rtpmap:127 x-data/90000
a=rtcp-mux
a=x-applicationsharing-session-id:1
a=x-applicationsharing-role:sharer
a=x-applicationsharing-media-type:rdp
a=x-applicationsharing-contentflow:sendonly

m=video 58167 RTP/AVP 122 123
c=IN IP4 123.45.67.89
a=x-ssrc-range:4246247680-4246247779
a=rtcp-fb:* x-message app send:src,x-pli recv:src,x-pli
a=rtcp-rsize
a=label:applicationsharing-video
a=ice-ufrag:TRWS
a=ice-pwd:mZjxk9kd1NNgv+IgKl49XmCk
a=x-mediasettings:applicationsharing-video=required

<candidate and crypto data snipped>

a=rtcp:55154
a=sendonly
a=rtpmap:122 X-H264UC/90000
a=fmtp:122 packetization-mode=1;mst-mode=NI-TC
a=rtpmap:123 x-ulpfecuc/90000
a=rtcp-mux

First, a new session level attribute a=x-mediabw is included under the m=application section.  This is what the SfB 2016 clients can use to identify and use VBSS for the sharing session between them.  If both parties do not support this new capability then it will not be used and RDP will be leveraged instead just as it has been.

Secondly, an additional media session is advertised to negotiate a video stream under the familiar m=video string, including two new attributes: a=label:applicationsharing-video and a=x-mediasettings.  Note that the media payload type here is the same X-H264UC (a=rtpmap:122) that has been used for video since the release of Lync 2013.  For added measure the out-of-band Forward Error Correction (a=rtpmap:123) codec used with SVC video is also included.

While not visible above because the candidate details were clipped for easier reading the RDP session only advertises TCP candidates while the VBSS session will advertise a full set of UDP (preferred) and TCP (fallback) candidates.  The fact that content sharing with VBSS can now utilize the stateless UDP communication protocol is already an advantage in improving streaming.  Also not represented is the communication between clients within the RTCP channel for Video Source Requests (VSR) in which the two clients negotiate resolution, frame rate, and other parameters of the video channel in-session.

As both the RDP and VBSS capabilities are advertised in the messages above then the clients will negotiate both sessions even though the content will actually flow through the VBSS session.  In the event that RDP needs to be used (e.g. for remote control) then the clients can quickly switch to using RDP as a legacy fallback option.

Because all of this new functionality is embedded directly into the clients then the underlying infrastructure does not seem to be relevant to its functionality.  As long as both parties have the Skype for Business 2016 client then it will be leveraged even if one or both of them are homed on a Lync Server, or even on different servers via federation.  In fact the example SIP data shown above was captured from a peer call between a 2016 client registered to Skype for Business Online and a federated contact registered to a separate Lync 2013 on-premises environment.

Update

Since posting this article Microsoft has added a a registry key to control the the VBSS behavior in the 16.x clients.  Using either of these two registry settings can be used to to disable this default behavior by setting the value to zero.  The first parameter is used with the 64-bit Skype for Business application running on a 64-bit Windows operating system.  The second parameter is used if the 32-bit application is installed on a 64-bit OS.

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\16.0\Lync]
"EnableP2PScreenSharingOverVideo"=dword:00000000

Polycom UCS 5.4 for VVX Phones

September 28, 2015 by · 39 Comments 

The latest release of the Polycom VVX 5.4 UCS firmware branch is now available for Lync and Skype for Business environments.  While the initial 5.4.0 release (5.4.0.5841) was published a few months ago that was only intended for Open SIP applications.  The recent 5.4.0A release (5.4.0.10182) is fully supported for Lync and Skype for Business (SfB) 2015 Server environments.

Additionally this release introduces the capability to register directly to Skype for Business Online and Exchange Online as provided by Microsoft’s Office 365 cloud environment.  This sets the stage for the planned launch of the voice features later this year.  As official support for voice and IP phones with Skype for Business Online is coming later this year then the registration outlined in this article is at this moment unsupported, but is functional.  For any hybrid environments with an on-premises Lync or Skype for Business deployment paired with Exchange Online this version also resolves connectivity issues previously seen in 5.3 with Exchange Online.

Upgrade Firmware

As covered in various other articles this process is unchanged.  The same steps listed at the beginning of this recent article can be used to upgrade the phone firmware if not already familiar with it.

The new firmware is now available directly from the public Polycom Hosted upgrade server, and it identified as “SFB-Lync Only” so that customer using VVX phones on Open SIP platforms do not use this specific release.

image

As usual the entire release package can also be downloaded from this page and then loaded on to a custom provisioning or distribution server.

  • Before advancing verify that the phone is upgraded to the proper firmware version by pressing the Home button and then then selecting Settings > 4 > 1 > 2 > 1 to quickly navigate to the Status > Platform > Phone > Main menu.

image

Office 365 Registration

Registering the phone to an existing on-premises or third-party hosted environment is performed the same as in previous releases.  Given that registration to Office 365 is a new feature for leveraging Skype for Business Online and Exchange Online then this article will walk through these steps below.

Note that some of the steps shown here are new, which are a result of improving the first-time sign in process for users.  These improvements are seen when registering to any Lync or Skype for Business environment, on-premises or hosted.

Select Base Profile

The VVX phone in use may already have this step configured by default, depending on the specific SKU that was used to purchase the phone.  Regardless of the part number and what was pre-staged at the factory any VVX phone can be moved between the Generic and Lync Base Profiles.

  • Depress and hold the 1, 4, and 9 keys on the phone’s keypad and keep them held for for at least 3 seconds.

  • When prompted enter the Administrator password (factory default is 456).
  • Select Lync if it is not already the default configuration.  If the phone was previously set to Generic then it will automatically reboot when Lync is selected.

image

Sign-In

Any of the methods detailed in the recent article Lync Registration on VVX Phones can be used.  The only difference for O365 registration would be the format the user credentials are entered in.  As SfB Online does not utilize legacy Windows NetBIOS formats then only the User Principal Name format can be used.

A touch-enabled VVX 600 model is used for the examples shown in this article, but the steps are identical between all VVX models.  For non touch-screen models entering the user credentials using the keypad could be a slow process and thus utilizing BToE or the Web Management UI are faster, easier methods of registering the phone.

The example below will show the process as performed directly on the phone itself.

  • Select the Sign In soft key displayed on the home screen of the phone.

Another improvement in the sign-in process with this release is that in the event the phone does not discover any Lync/SfB certificate provisioning services URL from either the network (DHCP Option 43) or a dedicated provisioning server (STSURI) then PIN Authentication support will be automatically disabled on the phone.  For Office 365 tenants or users of other hosted Lync/SfB environments where that authentication option is not currently supported this will simplify the sign-in process by defaulting directly to the User Credentials option.

  • Using the on-screen keyboard enter the desired Office 365 user credentials as shown in the following screenshot.  Only the Sign-In Address, User, and Password fields should be populated.  The Domain field should be left blank.

image

  • Select Sign-In and wait for the phone to complete registration.

image

  • Once sign-in is reported as successful press the Next key to move on and pick a time zone, or press Done to skip right to the home screen.

image

If Next was selected in the previous step then the Time Zone menu will have appeared.

  • Select the desired time zone and then either select Next or Done

image

If Next was selected then additional menus will provide the ability to change the default Time Format from 12-hour to 24-hour, and then configure the desired Date and Time Format.

If Done was previously selected then the wizard will complete and the phone will display the home screen and along with it any currently pinned Favorites in Lync or SfB, just as it always has.

image

  • To validate a successful connection to Exchange Online press the Home key and then select the Calendar icon.  Any scheduled meetings should be displayed as shown.

image

When using either of the other documented registration processes the same requirements apply in terms of how to populate the user credentials.

  • If using the Lync SignIn feature available the phone’s web management UI then the credentials are entered in the same as as shown in the steps above, omitting the Domain field.

image

  • If using Better Together over Ethernet (BToE) pairing the Lync/SfB client prompt for sign-in credentials should be populated as shown below.  (There is no separate Domain field to skip in this format.)

image

Customization

While this new wizard which mimics the behavior of Lync Phone Edition can be beneficial to unmanaged phones meant for hosted Skype for Business tenants current customers may already be handling time zone settings via DHCP or a provisioning server configuration.  In these scenarios it would be ideal to disable this setup wizard to streamline the user sign-in process even further.

  • To disable the user setup wizard simply configure the following three attributes on the phones using a supported provisioning server model.

device.set=”1”

device.lync.timeZone.set=”1”

device.lync.timeZone=”0”

Next Page »