The Enabling Technologies Blog

Our team of Cloud Strategy Advisors, Solution Architects, Engineers and former C-Suite Executives work diligently to provide our vistors with the most pressing information.

Dave Bergquist /

Skype for Business Server 2015

Forwarding options fail when using Shared Line Appearances

When configuring the Shared Line Appearance (SLA) feature for Skype for Business Server 2015 and referring to the Microsoft documentation, under the “Install Shared Line Appearance” section, it states that you are required to enable the SLA by registering SLA as a “server application” for each pool you plan to use SLA with, as follows:

· New-CsServerApplication -Identity “” -Uri “” -Critical $false -Enabled $true -Priority (Get-CsServerApplication -Identity “”).Priority

If you utilize “https” for the SLA URI as documented, some aspects of SLA will work such as ringing the list of delegates, seeing presence updates, and picking up additional lines. However, what I experienced was “Busy Options” and “Missed Call Options” will not work when using “https” for the URI. For example, I configured the SLA group “” with forwarding options as follows:

  • Set-CsSlaConfiguration -Identity “” -BusyOption Forward -Target “” -MissedCallOption Forward -MissedCallForwardTarget “” -MaxNumberOfCalls 2
  • Add-CsSlaDelegates -Identity “” -Delegate “”

After configuring SLA using the examples above, calls would ring the delegate, but the call would not forward on busy or missed call and the caller would experience a “fast busy” tone. Server-side Skype traces showed that the “forwarding” wasn’t attempted. The last item in the trace was a “DIAGNOSTIC” showing Skype attempting to route to application: “”. No errors were discovered other than the “487 Request Terminated” for the initial call.

After checking all other applications running on the front-end pool, I noticed they were all utilizing “http” as the base URI. I changed the current SLA configuration to utilize “http” as follows:

· Set-CsServerApplication -Identity “” -Uri “”.

After these changes were made, I executed “Update-CsAdminRole” via Skype Management Shell and proceeded to restart the front-end service on all front-end servers in the pool (Stop-CsWindowsService RTCSRV – Start-CsWindowsService RTCSRV). Check the status ensuring all services are running on each front-ends (Get-CsWindowsService).

Now when calling the “MainOffice” group, on busy or missed call scenarios, the call is forwarded to the intended target.

When reviewing the Skype server-side traces, I saw a “DIAGNOSTIC” message routing to the SLA “http” application: “”. You will also notice in the screenshot below the “INVITE” being sent out to the intended “forward” target.





Work with our team of Cloud Computing Consultants who have done this so many times they know all of the “minefields” to prevent missteps.