Microsoft is no longer onboarding new customers for any version of the Lync Hosting Pack. Customers are encouraged to look at the Office 365 Multi-tenant offering as an alternative.

For existing versions of the Lync Hosting Pack, support information is as follows:

• Lync Hosting Pack for Lync Server 2010 is OUT of mainstream support, as Lync Server 2010 is end of life as of 4/12/2016
• Existing customers of Lync Hosting Pack for Lync Server 2013 are supported until Lync Server 2013 mainstream support EOL (end of life), which is currently scheduled for 4/10/2018
• Customers and partners can no longer add domains to the list of approved, federated domains for any version of the Lync Hosting pack

What is happening?

The user interface on the Skype for Business 2016 C2R (click to run) client will have some changed visual elements. Some of the examples of these changes are:

On the main window, you’ll notice the new look to the following elements:

When you hover over a contact’s photo, you’ll notice the modality icons have changed as well:

When you open a conversation window, you’ll notice several changes:

Why is this happening?

The new client visuals are part of a large amount of work (both visual and internal) Microsoft has done to make Skype for Business 2016 more accessible so that it can be enjoyed by more people around the world.  One example of this effort is the slight variation in color changes which provides greater text-to-background contrast to empower those with low vision to more easily distinguish parts of the interface.  We also improved screen reader support, simplified keyboard navigation and made the keyboard focus easier to see in many places.  For more information on the overall goal of Microsoft to enable all users go to: https://www.microsoft.com/enable/

When will this happen?

All dates are an estimate and subject to change.

Early Adopters on the Current Channel and First Release for Deferred channel will see these changes in early November, 2016, whereas organization members on the Deferred Channel will see these changes in February, 2017. 

For more information on how the update channels for Office 365 ProPlus work, please see the following page: https://technet.microsoft.com/en-us/library/mt455210.aspx

I would encourage you to provide your feedback and submit questions in the Skype for Business Tech Community at the following address: https://techcommunity.microsoft.com/t5/Skype-for-Business/ct-p/SkypeForBusiness

Author: Martin Rinas – Sr. Customer Engineering Architect, Microsoft

I received an email recently ‘Hey Martin, I wanted to call Bob on his mobile phone from Skype for Business this morning. The call didn’t complete, gave me an error. I was at my hotel at that point in time, can you tell me why this call didn’t go through? I’m travelling right now with no coverage, love to hear from you what was going on. Thanks, Joe.’ So far so good, now I need to explain that Joe is the CIO of that company and wanted to call Bob, the CEO. He’s travelling so I won’t be able to get any further details from him, nor will I have access to his machine to get any client-side logs for troubleshooting. It would be just too easy to go to the EventLog of that machine and find an event Source=Lync, EventID=11 highlighting the exact reason. *(see end of blog post)

To start troubleshooting I need logfiles to understand what is going on. I have no chance to get client-side logs as I cannot contact him, what about server-side logs? In an on-premises environment we could leverage the Centralized Logging Service (CLS) to retrieve call details from the Always On scenario. Remember, this scenario is designed to run always so that you access to the log files after an issue occurred without the need to reproduce the scenario. See https://technet.microsoft.com/en-us/library/jj687958.aspx for more details on this.

Joe is hosted online leveraging Cloud Connector Edition for PSTN connectivity, so CLS logger won’t help here. But there’s something similar that I can do, I can retrieve logs from the service by leveraging the Get-CsUserSession cmdlet.

Let’s see what I have, I know the user (Joe) and the time (this morning) and I am a Skype for Business admin in that tenant, that’s all I need.

Collect Sessions

To collect logs, I need to start a PowerShell and connect to the tenant. This article has all the details if you haven’t seen this already: https://technet.microsoft.com/library/dn362831.aspx

$creds = Get-Credential

$s = New-CsOnlineSession -Credential $creds

Import-PSSession $s -AllowClobber

I can now run the Get-CsUserSession cmdlet to retrieve Joe’s logs from this morning:

get-csusersession -User joe@my-uclab.de -StartTime (Get-Date).AddHours(-4)

Instead of specifying a specific date I used the Get-Date cmdlet and subtracted four hours as Joe’s failed call is less than four hours ago. I did not specify the -EndTime parameter to limit the amount of data further.
This cmdlet returns SIP signaling that Joe initiated:

Analyse Session

Now that is great but a pretty long list. So let’s store everything in a variable for easier processing.

$sessions = get-csusersession -User joe@my-uclab.de -StartTime (Get-Date).AddHours(-4)

To find the event I am interested in I need to find the call that Joe was trying to start. To do so, I use the MediaTypesDescription Parameter. Let’s see what MediaTypes are available for my set of logs:

$sessions.MediaTypesDescription

Joe reported that he wanted to place an audio call, so let’s get details for the audio call:

$sessions | where {$_.MediaTypesDescription -eq “[Audio]”}

Okay, that’s better. I can see that Joe tried to place a call to +49 151 4406 3xxx. But I don’t know why this call failed, so let’s check the ErrorReports for details:

$sessions | where {$_.MediaTypesDescription -eq “[Audio]”} | select -ExpandProperty ErrorReports

Okay, so the call was in process but the Gateway responded with a 403 forbidden. After checking the gateway configuration associated to his Cloud Connector Edition it turns out that outbound call routing wasn’t setup correctly to support the number associated with Germany (+49). After fixing this configuration issue Joe, can place outbound calls to Germany.

Other things you can do with Get-CsUserSession

The other interesting thing is that this also allows you to access the QoEReport (aka VQReport) that is sent after every call, just find the QoEReport property of a completed audio call. This is useful in a scenario where you need to troubleshoot quality or call reliability issues for a specific user.

Things to be aware of

The Get-CsUserSession cmdlet is very powerful to troubleshoot issues of an individual user. Some PII data (like phone numbers in this example) is masked and you can only query for data of a single user at any point in time. But this cmdlet does expose quite sensitive information, therefore only Skype for Business admins have access to this cmdlet. Very like access to CLS or CDR/QoE database access for an on-premises environment.

There’s only a short lag of usually less than 5 minutes before the data is available and data is available for up to 365 days (starting from August 2016 onwards).

Where can I find more?

Please see the Skype Operations Framework website for this and more information on troubleshooting and practical guidance for successful deployments all together. https://www.skypeoperationsframework.com/Offers/?pageState=Supportthesolution

Get-CsUserSession on Technet: https://technet.microsoft.com/library/mt715516.aspx

*Shortcut

Here’s the shortcut if I had access to Joe’s machine with ‘Also collect troubleshooting info using Windows Event Logging’ being turned on in the Skype for Business General settings. Please note that Joe has a PC with German language installed, but as you can see the error message itself is still English.

This readiness content is presented by Skype Academy www.skypeoperationsframework.com/academy

Please check out the official announcement for the new Microsoft Teams over at blogs.office.com!

I am happy to announce our first update for the new Skype for Business on Mac client just 3 weeks after the announcement of general availability. The enhancements in this update will include:

– Contact group management features for Office 365 / Skype for Business Server 2015 customers

– Contact tagging for status changes

– Improvements to meetings reliability, sign-in, and chat

Microsoft is committed to enhancing the Skype for Business on Mac client at a regular pace. To read more about these updates, see (and save as a favorite!) our What’s New Office article.

We have made some changes to how Single/Tabbed Windows now work in the client – in some cases we allowed users to configure even when your architecture did not support it.  This often lead to message delivery failures. We made the decision to remove this capability for those customers affected with this update.  Some of you may not have the Single/Tabbed Window experience available now. We know this is a high interest feature – the team continues to work on this for future updates. Stay tuned.

To learn more about this or other items, please check known issues.

For customers who have already installed the client, The Microsoft AutoUpdate (MAU) will offer the update to you. If this is the first time you are installing, the client on the download center will be updated in the next few hours.

Please visit us at the Microsoft Technical Community to discuss this news as well as other Skype for Business on Mac client topics.

– Paul Cannon, Product Marketing Manager – Skype Experiences

Please visit the Microsoft Tech Community to learn more about the new Meeting Migration Service (MMS).

“Meeting Migration Service automatically sends meeting updates to all meeting invitees when an admin moves the user who is hosting the meeting from on-premises to online or when those users are enabled for Cloud PSTN Conferencing. The new service removes the need for users to run the Meeting Migration tool locally to send meeting updates for all future meetings.”

Visit the Skype Operations Framework & Skype Academy Community site to learn more!

Please visit the TechCommunity to learn more about these exciting new updates to Meeting Invites!

Thanks!

Many times in my support role here at Microsoft, I write out the steps for customers to collect Lync or Skype Client logs.  I thought that writing a script might make it easier.  Here is a sample script that I like to use.

To download the sample script, visit the TechNet Gallery and save it to your desktop or some other familiar location

Once you have downloaded the script, right click on the script and select “Run with PowerShell”.

NOTE:  You may get a prompt similar to this in PowerShell.  If you still wish to run the script, type ‘Y’ and hit enter:

Here I am again with another Script.  This time I have tried to simplify the log collection with via PowerShell.  It allows you to leverage the power of CLS logging without having to install the Debugging Tools for either Lync or Skype for Business.  Also, it simplifies the complex Cmdlet by only requiring 3 switches.  Scenario, Pools, OutputFolderPath.

The nice thing about this is that you don’t have to remember what time you started and stopped the logging and how to get the output.  Sometimes the Search-CsClsLogging cmdlet is confusing.  What LogLevel, do I MatchAll or MatchAny, etc.  The script uses the basic settings to get the data you need.  Now, I will say that this script doesn’t handle all of the possibilities of gathering CLS Logging, but it will allow you to get logging against a pool or multiple pools for a scenario easier than running the cmdlets manually.

Well, Lets get to it.

Let us say that you need to get some SIP logging to find out why a federated partner cannot get your IMs.  For this I would use the ImAndPresence scenario. (If you need to find the correct scenario, see my blog on Listing CLS Scenarios in HTML.  If you need a custom scenario, see my blog on Creating Custom CLS Scenarios.)  This scenario gets the SipStack and UserServices component.  Then we need to think about the environment.  I will presume you know which pool the user homed on that is having the issue.  For this example, I will use KI-Sfb-FE’s FQDN and the KI-Edge FQDN since my test user is homed on this FE and will go through this Edge for federation.

The syntax that I would use is:

.\Collect-CsClsLogging.ps1 -Scenario ImAndPresence -Pools ki-sfb-fe.kaosupport.info,ki-edge.kaosupport.info -OutputFolderPath c:\temp

If the OutputFolderPath doesn’t exist, it will ask you if you wish to create the path or not.

If you choose “No” then the script will stop, so I am going presume that you selected “Yes”

Next, it will contact the agents to start the logging and notify you when you you can start to Repro your issue. (Note: The screenshots I am showing you are from Skype for Business PowerShell.  Lync 2013 PowerShell will be slightly Different.)

So LyncTest1@kaosupport.info tries to send an IM to the federated contact…wait for the failure to show in the client (or what ever error you are trying to repro).  When the Repro is complete, hit the enter key in the PowerShell window to stop the logging and create the output file.

Note the path and filename.  When you browse out to that folder, if you have Snooper installed, you simply have to double click on the file to start your analysis.  Or, you can upload the files to your support engineer for them to analyze the data, but as far as gathering the logs, that is it.

The nice part about this is if you have to repro this several times because something went wrong, you can just hit the up arrow in PowerShell and re-run the script and it will adjust the start and stop times automatically.  This way, you know you captured the data for the correct time frame without going over or under.

DOWNLOAD

To download this script, click here.

REQUIREMENTS:

1. Windows PowerShell 3.0
2. Must be run from a Front End server
   1. This is needed because the CLS .Net assemblies have to be available and are only available on front end servers (From what I have found)
3. Lync/Skype on premises administrator with RTCUniversalServerAdmins, CsServerAdministrator, or CsAdministrator rights.
   1. This is required by the Lync/Skype Cmdlets to collect CLS Scenarios without throwing access errors.
4. PowerShell opened in “Run as Administrator” mode
   1. This is required by the script Cmdlets to gather the correct information without throwing access errors.

I am continually needing to create custom scenarios for logging components in CLS Logging (Centralized Logging Service).  Typically, this is because either the “Canned” Scenarios don’t have the combination of components that I need, or they don’t have the Flags or Levels that I need.   So, I put together a script so that I can create custom scenarios quickly and easily.  Since I like to share and I know others run into the same dilemma, I am writing this post for you. 

If you need to find a list of scenarios and which components, levels and flags are in each, see my blog on Listing CLS Scenarios in HTML 

Now, you might be familiar with the TechNet Cmdlet articles that show what you need or Richard Schwendiman’s Article on the subject.  I am not trying to take away from any of these.  In fact, Richard’s article is great and explains things in more detail than I will do here.  There isn’t any reason to reinvent the wheel.

My main purpose for this article and script is to give you the ability to create a custom scenario quickly and get to logging your problem fast.

This script should help you create a custom scenario by putting some logic and validation into it.  It validates that the components that you chose are valid components and found in the default.xml used by the CLS Logging service and also verifies that you don’t already have a scenario with this name.  Here are examples of this logic:

Invalid Component:

As you can see, these have some misspellings in the component names and that it gives you the option of listing the components so that you can easily correct this.

Scenario Already Exists:

Not only does it show you that this Scenario name already exists, it lists the components in the scenario just in case it has everything you need.  It also gives you the syntax to remove the scenario in the event you need to create it again with new parameters.

By Default, the script will create the scenario setting the Level to Verbose and the Flags to All.  This may create larger log output files, but are sometimes necessary to get the data you need.  It also, by default, creates the scenario in the Global scope.  I have a Scope parameter you can pass if you need to create a scenario that is Site specific.

Something else that will come in handy is the ability to run the script with the -ListComponents parameter switch that will list all of the available components for logging.  This way, you can go down the list (Like you used to do in the Lync Server Logging Tool) to find the names of the components you need for your scenario.

.\Create-CsClsCustomScenario.ps1 -ListComponents

So, lets jump into creating a custom scenario.  One scenario that isn’t in the “Canned” scenarios is PersistentChat.  So, we will use that as an example.  There are 4 PChat Components: ChatCommon, ChatEndpoint, ChatServer, ChatWebService.  To create this scenario you would use the following syntax:

.\Create-CsClsCustomScenario.ps1 -Scenario Custom_Pchat -Components ChatCommon,ChatEndpoint,ChatServer,ChatWebService

One thing I want to point out is the scenario name.  You can call it whatever you want, but I like to start all of my custom scenarios with Custom_ .  I do this so that I can tell the difference between the “Canned” and the Custom scenarios.

The above syntax will create the following output:

You will notice the Yellow line.  I put this here to save on confusion.  It is said that you need to open a new PowerShell window to use the new scenario.  I have found this to be true unless I wait a period of time.  I believe this is due to replication and/or the CLS Agent awareness of the new scenario.  Regardless, if you want to use the scenario immediately, please open a new PowerShell session.

So that is the way to create a custom scenario with this script.

There are a couple other parameters that are optional in the event that you need to create the scenario in a scope other than global and/or if your default.xml file isn’t in the typical locations. (C:\Program Files\Common Files\Skype for Business Server 2015\Tracing [it also checks the similar path for Microsoft Lync Server 2013]).  If you installed Lync or Skype server on a different drive or other location, you will have to use the -DefaultComponentFile parameter.  You would see something similar to this:

To Correct this, you would use the syntax similar to this:

.\Create-CsClsCustomScenario.ps1 -Scenario Custom_Pchat -Components ChatCommon,ChatEndpoint,ChatServer,ChatWebService -DefaultComponentFile “D:\Program Files\Common Files\Skype for Business Server 2015\Tracing\default.xml”

To use the -Scope parameter, you simply add the Topology Site name.  In my lab, it is MainSite.  I don’t recommend using the scope parameter unless you need to.  Most scenarios run best under the Global scope.  Here is the syntax for Scope:

.\Create-CsClsCustomScenario.ps1 -Scenario Custom_Pchat -Components ChatCommon,ChatEndpoint,ChatServer,ChatWebService -Scope MainSite

Once you create a custom scenario, check out my blog on gathering logs easily

I really hope this script helps you.  Enjoy.

DOWNLOAD

To download this script, visit the TechNet Gallery

REQUIREMENTS

1. Windows PowerShell 3.0
2. Must be run from a Front End server
   1. This is needed because the CLS .Net assemblies have to be available and are only available on front end servers (From what I have found)
3. Lync/Skype on premesis administator with RTCUniversalServerAdmins, CsServerAdministrator, or CsAdministrator rights.
   1. This is required by the Lync/Skype Cmdlets to create CLS Scenarios without throwing access errors.
4. PowerShell opened in “Run as Administrator” mode
   1. This is required by the script Cmdlets to gather the correct information without throwing access errors.

When I am trying to troubleshoot a situation in Skype or Lync with the Centralized Logging Service (CLS), one of the biggest challenges is knowing which scenario to use.  I found that it was cumbersome to search with the Cmdlets every time I needed to gather logs for something new.  Sometimes I would need to check which components a scenario used and their levels and flags and other times I knew a component but not which scenario it was in.  So, I wrote a script that would allow me to quickly find either of these things.  I am sure you may find more ways to use it than I did.

The way I use it is to create a shortcut on my taskbar to the HTML file.  That way the information is easy to access and quick to search.  When it is open, I simply press Ctrl + F and start typing what I am looking for.

Let’s look at the Output

Here are a couple of sample shots to see what it will look like:

As you can see, it lists the Scenario Name, Components with each of their Levels and Flags.  This will allow you to check to see if the scenario you are running will gather the correct information.  If it doesn’t, you can always run my Create-CsClsCustomSceneario.ps1 script found here with the corresponding NextHop blog found here.

How to Use

This one is not too complex.  Just run the script with the –OutputFolder parameter and point it to the folder you wish to save the output.  If the folder doesn’t exist, it will stop the script.

.\List-CsClsScenariosHtml.ps1 –OutputFolder C:\Temp

Once the script is done, it will launch the browser and open the file.

To start collecting CLS Logging, check out my blog on Collecting CLS Logging easily.

Download

To Download this script, visit the TechNet Gallery

REQUIREMENTS

1. Windows PowerShell 3.0
2. Must be run from a Front End server
   1. This is needed because the CLS .Net assemblies have to be available and are only available on front end servers (From what I have found)
3. Lync/Skype on premises administrator with RTCUniversalServerAdmins, CsServerAdministrator, or CsAdministrator rights.
   1. This is required by the Lync/Skype Cmdlets to create CLS Scenarios without throwing access errors.
4. PowerShell opened in “Run as Administrator” mode
   1. This is required by the script Cmdlets to gather the correct information without throwing access errors.

Author: Steve Schiemann

You record a meeting, so the content can be published internally for later use. After the recording has been completed, a pop-up dialog Box appears from Skype for Business Recording Manager. You chose appropriate options and then select Publish.

When reviewing the published video, you realize that the video quality is sub-par or deteriorated, when compared to the video that participants in the meeting were observing. If your meeting allows for HDVideo, we will allow for video resolution to be upto 720p and upto 30 fps. The content by itself is saved in the same configuration on the local.

The Skype for Business Recording Manager, in-order to optimize the recording ( file size generated) will encode the video from 30 fps to 15 fps, which can cause the rendered video to be choppy/ flaky / in-consistent, depending on the amount of motion in the source video. This was deliberate design, to allow for smaller files that can be saved and published for later use.

Resolution:

Skype for Business Recording Manager has an option to publish the video at 30 fps. This can be done by modifying the registry key called VideoFrameRate from Decimal 0 to Decimal 30 at the following location(s):

For Skype for Business 2016 clients:

 \HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Lync\Recording

For Lync 2013 / Skype for Business 2015 clients

\HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync\Recording

While this is a great action to perform before the meeting has occurred, the same registry key can also be used AFTER the meeting has been published as well. If a registry key is modified and the video is re-published ( on the same machine, where the original meeting recording occurred and where the video was published), the newly published video will be at 30 fps.

Starting with Skype for Business Cloud Connector (Cloud Connector) 1.4.1, we introduced an automated update process: Cloud Connector automatically updates based on the update schedule that administrators have configured for their Cloud Connector Hybrid PSTN Sites.

Auto update handles both Cloud Connector Edition updates, and Windows operating system updates for all Cloud Connector virtual machines and the host appliance.

For details on understanding how auto updates work with Cloud Connector, please our Microsoft Tech Community blog: Understanding Cloud Connector Edition Auto Update.

On .NET Framework 4.6.2 and Skype for Business/Lync Server Compatibility

Author: Steve Schiemann

Contents:

1.) SDN Definition and Short History

2.) Considerations Before Deploying

3.) Versions

4.) Architecture

5.) Installation/Configuration

6.) Command-line/PowerShell options

7.) Performance

8.) Troubleshooting and Data Collection

9.) Other Resources

10.) Conclusion

SDN Definition and Short History

What is Software Defined Networking?

At a high level, SDN uses open protocols (XML in our case) to apply software control to network hardware. This hardware/firmware can receive and understand application-specific data, and make adjustments to optimize network traffic.

Short History

Consider this a primer for the Skype for Business Software Defined Networking Application Programming Interface. Later versions are simply called the Skype for Business SDN Interface.

There is no programming involved with installation/configuration. It provides an interface to a third-party network controller or monitoring application. The controllers are made by Cisco, Aruba, Nectar, HP, or other providers.

The SDN API sends Lync/SfB diagnostic data, Quality of Experience to the controller(s), which then can optimize network traffic and security. Administrators can view records of Unified Communications call quality, or even see a problem in real time and address it quickly. The controllers themselves can respond to media stream quality data, and prioritize network traffic for real-time vs. non-real-time data, UC-related data vs. web browsing data. Lync/SfB media steams are encrypted, but the SDN API allows the controllers to see what type of media stream is involved, and adjust the network accordingly, per policies, without seeing the data contents.

The Microsoft Skype for Business SDN Interface is a RESTful (Representational state transfer) interface through which subscribed systems (“subscribers”, a.k.a. the third-party controllers) receive active call data, and the end-to-end measured quality of media streams.

Big Picture: Software Defined Networks began in the mid-1990s-early 2000’s, A.K.A “Active Networking”. AT&T had one of the first implementations of this idea. The Microsoft Lync/SDN API is one of many SDN Applications written by various vendors for other applications.

Considerations Before Deploying

1.) We recommend that installation/configuration is done in a lab first.

2.) Microsoft recommends using the latest version of the SfB SDN Interface that is compatible with Lync/SfB Servers, and the third-party controllers. What version does the controller manufacturer recommend? Keep in mind that there are various schemas available in the interface for compatibility purposes, so if a particular schema is needed, perhaps a later version of the SDN Interface can be used with a non-default schema.

3.) Is this a new deployment, or perhaps an upgrade from a previous version? Read the Help and Release notes that come with each version of the Interface.

Versions

Version 1.0 was released in 2012, and 1.2 was released in late 2013. Neither of these versions are publicly available now. Versions 2.1.1, 2.2, 2.4, 2.4.1, and 3.0 are in use by customers today.

Version 3.0 just released on Feb 2, 2017 https://www.microsoft.com/en-us/download/details.aspx?id=54685&WT.mc_id=rss_alldownloads_all It is not compatible with Lync 2010.

Improvements in later versions include but are not limited to sending in-call quality updates as opposed to just begin/end-call updates, fully load-balanced and redundant pools, SDN Managers shared database, move some computations from Listener to Manager. Check the release notes for each version for more information. The release notes are available in the same group of download files for each SDN version.

Versions prior to 3.0 work with Lync 2010, 2013, and SfB 2015

Whatever operating system the Lync Server Front End servers use will be used by the API, since one component (Listener) is required to be installed on all FE servers.

Architecture

Components

Conceptually, the Skype for Business SDN Interface consists of the following components:

· The Dialog Listener that captures signaling and quality observations about media traffic between Skype for Business endpoints.

· The SDN Manager that collects the data from one or more Dialog Listener and distributes to third-party network management systems.

· A data store that maintains the shared state among all SDN Managers in a single pool. The data store could be a SQL database, Redis, or local memory cache.

· One or more subscribers, generally network management systems, also known as network controllers, or ITPro tools that support a RESTful web service to receive and analyze the call- and media-quality data posted from the SDN Manager.

Data Flow

The data flow looks like this:

Clients → (Front Ends / Lync Dialog Listener (LDL)) → Lync SDN Manager (LSM) → third-party controller

There should be a Listener on each front-end server (FE) to receive data from users homed on them, and one or more Managers to send (XML) data to the controller. The diagram below shows the Skype for Business/Lync clients in the upper left, sending data to the Listener component which is installed on each FE. The Listeners then send data to the Manager(s), who send it on to the controllers (Network Management System).

Installation/Configuration

For the most part, customers install each component on appropriate servers, configure it, and it just works. The primary configuration steps are done in the installation wizard; some environments may require more customization.

Pre-installation tasks include but are not limited to planning your deployment (how many listeners/managers?), Activating QoE recording, setting up DNS service location record, setting up a database (Redis, or SQL), and/or installing certificates.

We recommend that you run SkypeforBusinessSDNManager.msi before you run the SkypeforBusinessDialogListener.msi. This will ensure that the SDN Manager is running and ready when the Dialog Listener attempts to connect to the SDN Manager.

You should install SDN Manager on a separate application server to maximize the performance of the Skype for Business Server front end.

Installing LDL and LSM on same FE is not recommended, but in a lab environment it can work.

Screen shots and details of Manager (LSM) component setup can be found at https://msdn.microsoft.com/en-us/library/office/dn785203.aspx.

Screen shots and details regarding the Listener (LDL) component can be found at https://msdn.microsoft.com/en-us/library/office/dn785202.aspx.

Command-line/PowerShell options

You can use the command line or PowerShell to view or modify SDN settings, or even perform unattended setup.

Command Line

Details regarding command line options are described at https://msdn.microsoft.com/en-us/library/office/mt148356(v=office.16).aspx. Below is an example of changing the submituri parameter via command line. I customized my installation path, so yours may not be exactly the same.

The ‘p’ means “put” or change something, the ‘l’ means listener, “sfb.contoso.com” is where a standard edition or enterprise pool is referenced, and “submituri=…” is the parameter being changed. This change is saved in the database being used by the API, not the config files used by LSM or LDL components. Earlier versions used the config file for everything. Config file parameter are still important but are not now used for Listener, Subscriber and Manager configuration.

C:\Program Files\Microsoft Skype for Business Server\Microsoft Skype for Business SDN Manager 3.0>sdnmanager p l sfb.contoso.com submituri=http://webapps.contoso.com:9333/LDL

Response code: SUCCESS Detail: Merged 1 parameters, Timestamp: 2017-02-27T17:22:45.7550618Z

Response code: SUCCESS Detail: TimeStamp: 2017-02-27T17:22:45.7550618Z

<Configuration Version=”2.0″ culture=”en-US” Kind=”Listener” Identifier=”SFB.CONTOSO.COM”>

<parameter key=”submituri”>http://webapps.contoso.com:9333/LDL</parameter>

<parameter key=”alternativeuri”></parameter>

<parameter key=”clientcertificateid”></parameter>

<parameter key=”submitqueuelen”>1000</parameter>

<parameter key=”maxbackoff”>30</parameter>

<parameter key=”maxdelaylimit”>5</parameter>

<parameter key=”maxopen”>100</parameter>

<parameter key=”maxretry”>100</parameter>

<parameter key=”maxretrybeforefailover”>10</parameter>

<parameter key=”requester”>sfb.contoso.com</parameter>

</Configuration>

PowerShell

Details regarding PowerShell options can be found at https://msdn.microsoft.com/en-us/library/office/mt642927%28v=office.16%29.aspx/ Version 2.4 and later have the option of using Powershell cmdlets. Here is an example of using PS to get Manager (LSM) settings from my Standard Edition SfB 2015 Server:

PS C:\Users\Administrator.CONTOSO> Get-CsSdnManager -SdnPoolUri http://localhost:9333/Settings

<Configuration Version=”2.0″ culture=”en-US” Kind=”Manager” Identifier=”DEFAULT

” LastModified=”2017-02-24T22:02:05.9356561Z”>

<parameter key=”calltimeout”>1.00:00:00</parameter>

<parameter key=”endedtimeout”>00:00:15</parameter>

<parameter key=”invitetimeout”>00:03:00</parameter>

<parameter key=”maxcachesize”>20000</parameter>

<parameter key=”qoetimeout”>00:00:05</parameter>

<parameter key=”timeouthandlerperiod”>00:00:10</parameter>

<parameter key=”hidepii”>True</parameter>

<parameter key=”applicationsharing-AppliedBandwidthLimitAcceptable”>500000</parameter>

<parameter key=”applicationsharing-AppliedBandwidthLimitOptimal”>1000000</parameter>

Performance

Our data store (SQL, Redis, or local cache) only maintains configuration data, and info for all concurrently ongoing calls. So the databases should be fairly small, relative to the call volume. No historical data is preserved.

Regarding the Manager component, from the SDN API 2.2 help file, SkypeForBusiness_SDNInterface_2.2.chm

“The SDN Manager is also a lightweight Windows service that we recommend you run on a separate virtual or hardware application server that uses Windows Server 2008 or later… The SDN Manager is responsible for processing the various events received from the Dialog Listener. It maintains state of the individual real-time streams—including whether the stream has started, ended, updated, and more in the associated data store (either Redis, local cache, or SQL Server database)—and sends the resulting XML data to the configured data receivers. The SDN Manager requires .NET Framework 4.5 or a later.”

“Performance Benchmarks” are found in the SkypeForBusiness_SDNInterface_2.2.pdf that was downloaded with the 2.2 API. They have not changed for later versions:

Sample machine configuration:

Stand-alone SDN Manager server: Windows Server 2012 R2

CPU: 8 Cores, 8GB of memory

Hard drive: 1 TB

From the SkypeForBusiness_SDNInterface_2.2.chm that is downloaded with the API,

Applies to: Lync Server 2010 | Lync Server 2013 | Skype for Business 2015

Version 2.2 of the Skype for Business SDN Interface was tested in a production environment and in lab setups but no formal scalability testing has been conducted. Nevertheless, the following performance data should give you an idea what you can expect. Please consider these numbers as example only.

Performance benchmarks

• A pool of three SDN Manager servers can support the traffic from 48 Skype for Business front-end servers, with separate REDIS/SQL clustered DB servers. This configuration may be able to support up to 80,000 users in one continent.
• Memory consumption is fairly low and stable.
• Sample machine configuration:
  • Stand-alone SDN Manager server: Windows Server 2012 R2
  • CPU: 8 Cores, 8GB of memory
  • Hard drive: 1 TB
• In lab scenarios, we execute load of 400 audio calls per minute against two front-end servers and two SDN Manager instances. These topologies consist of virtual machines only with not more than two cores and 8 GB of memory each.
• Bandwidth includes the RTCP stream, which may use a different port.

If a pool configuration is used around a database, the SQL Server is expected to be production level server with state-of-the art memory and CPU. Similarly, a REDIS cache server must be configured to handle the load.

Troubleshooting and Data Collection

Logging is on by default, but debug logging can be enabled via the config files for each component. The config file for the Listener component is found by default at C:\Program Files\Microsoft Skype for Business Server\Microsoft Skype for Business Dialog Listener\ DialogListener.exe.config. The Manager component config file is at C:\Program Files\Microsoft Skype for Business Server\Microsoft Skype for Business SDN Manager\SDNManager.exe.config.

To enable debug logging, search for the <loggingConfiguration> section and make appropriate changes to entries under the component elements.

For example, change the switch value from “Off” to “All”.

<add switchValue=”Off” name=”Debug”>

<listeners>

<add name=”LNEAppLog” />

</listeners>

</add>

Basically, you want to verify that the listener is getting data from the clients, and sending it to the manager. Then, verify that the manager is sending data to the subscriber (controller) in the correct format. That’s it.

The SDN API is quick and easy to install in a lab. As previously mentioned, both components can be co-located on an FE server.

Info on listener logging:

https://msdn.microsoft.com/en-us/library/office/dn439303.aspx

Info on manager logging:

https://msdn.microsoft.com/en-us/library/office/dn775151.aspx

Other Resources

Getting ready to install Skype for Business SDN Interface

https://msdn.microsoft.com/en-us/library/office/dn785199(v=office.16).aspx

Software-Defined Networking: An Overview for Unified Communications

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/OFC-B343

Software-Defined Networking: The New Norm for Networks

https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf

Open Networking Foundation (ONF)

http://www.OpenNetworking.org

The International Mulitmedia Telecommunications Consortium

http://www.imtc.org/

The Road to SDN: An Intellectual History of Programmable Networks

https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistory.pdf

Conclusion

This writing is not intended to cover advanced topics. I hope it is useful to those new to the SfB SDN Interface. The Help that comes with each version of the Interface is extensive, and covers most questions that customers have about the product. But if your questions are not answered, open a support ticket and we’ll be glad to help.

Expected release date for this is 3/20/2017 pending final testing. Look for release announcement here.

This update is important, as it is the first to automatically update all existing installed Skype for Business Cloud Connector 1.4.1 appliances, based on the update schedule that administrators have configured for their Cloud Connector Hybrid PSTN Sites. For managing auto update, see Understanding Cloud Connector Edition Auto Update.

For details on understanding how to prepare for Cloud Connector Edition Release 1.4.1, please our Skype for Business Hybrid Voice Team blog.

Often a Lync Administrator will see EVENT ID 56208 – Insertion of an error report was throttled to prevent flooding of the Call Detail Recording (CDR) Database on their Front-End Servers, potentially on other server roles like a Mediation Server too.

While most administrators chose to ignore this alert, this blog-post sheds light on what this alert represents and when is it safe to ignore the same,

A CDR report is generated by each party that is in a Peer-to-Peer IM Session, Multi-Party IM Session, and/or Conferencing Session. In case of PSTN calls, the mediation server will generate a CDR report.

Since CDR reports are generated by by P2P conversations and by conferences, lets first focus on conferences.

P2P and Multi-Party IM Conversations – Each party will generate a CDR Report, when the session is ended (I.e user closes their active tab or the session is timed-out, due to inactivity).

Conferences typically start at the top of the hour or at the 30 minute mark and then conclude at the end/top of the hour or at the 30 minute mark.  This means that at every hour and 30 minute interval after the same, during core-business hours, CDR reports are expected to be generated at higher volumes.

Conferences / Meetings also present a unique scenario where people may either be walking to a conference room, switching from one Wireless Access Point to another and/or not responding to IM sessions that are already in progress, as they are just joining/exiting a meeting causing a session timed-out due to inactivity.

In case of a session involving audio and/video, a Quality of Experience (QoE) report is also generated, but the volume of QOE reports is often much lesser than the volume of CDR reports.

Both in Lync Server 2013 and Skype for Business Server 2015, we have a throttle set to on the monitoring server to only allow for only 10 reports with a particular MS-Diagnostic ID to be inserted into the LcsCDR database per second. This throttle was deliberately introduced to distribute the load on the server over a longer period of time, so that report creation isn’t impacted, if the monitoring and reporting servers are collocated.

The above mentioned throttle can be seen in the dbo.MSDiagMetaData table in the LCSCDR database. One common example would be

The way our product is designed, these reports are held in SQL LyncLocal instance in the LYSS database., and are retried again and again until the messages are eventually committed to the Monitoring servers.

In rare instances, mostly either in very large environments that use a centralized Monitoring Server or in environments, where the Monitoring Server has been offline for a considerable period, we have see issues where the threshold hasn’t necessarily worked.

Generally speaking it is safe to ignore EVENT 56208. However, if EVENT ID 56208 is fired during periods of low business activity (weekends or holidays), it is certainly concerning.  In such a case focusing on EVENT ID 56206 and EVENT ID 56207 can help understand, if the aggregate volumes are increasing or decreasing. If the volumes are decreasing, we recommend to wait till the queues drain out. It is suggested to prevent additional load on the monitoring server, not to generate reports on your reporting server.

If there are indeed issues in the environment, based on the type of issue, you may see other events in the LYNC Server event log from source LS Storage Service. Also, it could be possible that your reporting server reports will not have data for the current or prior day. In such cases, we would recommend that you engage Microsoft Support.

Skype for Business Cloud Connector Version 1.4.2 Release

This is an important update as it is the first update that will automatically update all existing installed Skype for Business Cloud Connector (Cloud Connector) 1.4.1 appliances based on the update schedule that administrators have configured for their Cloud Connector Hybrid PSTN Sites. For details please refer to Understanding the automatic update process for Cloud Connector Edition.

Be sure to read Prepare for Cloud Connector Edition Release 1.4.2 prior to your update schedule to insure a successful update.

If you are running version 1.3.8, please refer to the manual update instructions Upgrade a single site to a new version in the Cloud Connector Edition configuration guide. Also, be sure to export a new sample Cloud Connector configuration file after 1.4.2 has been installed and update your existing configuration file with new parameters, e.g., HardwareType and WSUS Server.

For more details on this release, please see posting in our Skype for Business Hybrid Voice blog: https://blogs.technet.microsoft.com/sfbhybridvoice/2017/03/20/skype-for-business-cloud-connector-version-1-4-2-release/

Monitoring and Archiving has undergone major changes since Lync Server 2010. For Lync Server 2010 and prior versions, we had Message Queuing (MSMQ), have messages stored on a communications server, which were transported to the Monitoring Server and the Archiving Server, using MSMQ, and then were consumed into respective server roles using an Agent. In Lync Server 2013, we introduced  Lync Server Storage Service (LySS), as a replacement for Message Queuing(MSMQ). The LySS database is part of the LyncLocal Instance on all servers.

LySS can have different types of data, but mostly has the following types of data

1. Monitoring Data ( CDR & QoE Reports) which are sent to your Monitoring Server, defined in the topology
2. Archiving Data ( for Content Archiving if enabled) , which are sent to the Archiving Server, defined in the topology

Since LySS is an SQL Express Instance it has some of the limitations of SQL Express Installation like 1 GB Maximum RAM Utilization, 1 CPU Max Utilization, and 10 GB Max DB Size. These limitations, generally speaking, work extremely well with LySS, as there is little data on the database, before it gets committed to the respective back-end servers, like a monitoring server or an archiving server. In the unlikely event that your Monitoring or Archiving Server is/are offline for an extended period of time ( or not configured correctly) , the 10 GB Max DB limit may certainly be a challenge.

Each LyncLocal instance can expand up to 10 GB in size, which can queue-up several hundred thousand messages, given most CDR/QOE reports are very small, Archiving data is fairly small too. Additionally, there are fail-safe mechanisms in place, to export the content from SQL Express to the either a Web service file share (for example \\contoso.com\LyncFileShare\1-WebServices-1\StorageService\DataArchive\20161122\LyncStd01.contoso.com\), if access to the file-share is available,  while the other possibility is the local Application Data directory of each front-end server ( for example C:\ProgramData\Microsoft\Skype for Business Server 2015\StorageService ).

The resource Kit for for Lync Server 2013 and Skype for Business Server 2013 have a tool called ImportStorageServiceData that can be used to re-import these files into the local LyncLocal instance.

In-order to help troubleshoot, we also have a built-in scenario called MonitoringAndArchiving, which will collect relevant logs from the servers, where the scenario has been running.

A friendly note to all Lync Administrators, since this Database can have Content Archiving, which may be required for legal / regulatory / compliance purposes in your organization, before you scorch a server or delete this database, always take a back-up.The UDCAgent is an application that is responsible to transfer messages from LySS database to the appropriate back-end database.