This post has been republished via RSS; it originally appeared at: Skype for Business Blog articles.
First published on TECHNET on Sep 27, 2017 (Updated 11-JUN-2019)
Starting in Lync Server 2010, we added functionality to enable our partners to provide insights into Call Quality by means of a sending a copy of the Voice Quality Report (VQReport) directly from the server. At that time, I knew of a handful of companies that would allow you to configure QoEConfiguration, so they could generate some reports and provide insights about your network and configuration. Over time, with Call Quality Methodology and later with Call Quality Dashboard , and also integrating CQD Online some of the same functionality was available for free. With Skype for Business Server 2019, Microsoft introduced "Call Data Connector" to allow for data in Hybrid Environments to be analyzed and for insights to be gained
To send your QoE Reports to a third party, all you had to do within Lync was to Run
Set-CsQoEConfiguration -EnableExternalConsumer $true –ExternalConsumerName <Friendly Name of the Third Party Consumer> -ExternalConsumerURL "HTTPS URL Provided by the third party "
As soon as replication was complete, and presuming DNS, Certificates, Firewall was in order, all new QoE Reports would also be sent to the third-party. If the third-party was busy or unavailable, the messages would be queued-up and then be retried. The queues would be MSMQ in Lync Server 2010 and in LySS Database on the SQL Instance LyncLocal on each Front-End Server, in versions Lync Server 2013 and above .
If say, for some reason, the organization decided to change its course and use either Call Quality Methodology or Call Quality Dashboard , you could use Set-csQoEConfiguration to set EnableExternalConsumer $False
It could be possible that over time, with all the changes, the strategy may have changed, but the configuration has existed, and the 3rd party provider has chosen to block connection from your organization, or a new pool is deployed, and outbound connections to port 443 to the external consumer is no longer accessible, in such cases, you could see EVENT ID 56416 occur in your organization.
Time: 5/2/2017 2:49:54 PM
ID: 56416
Level: Error
Source: LS Data Collection
Machine: SKYPESTD01.contoso.com
Message: Failed to post QoE report to External Consumer.
Error: System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond <IP Address of the Provider >:443at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
--- End of inner exception stack trace ---
at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
at System.Net.HttpWebRequest.GetRequestStream()
at Microsoft.Rtc.Server.UdcAdapters.QoE.HttpSender.SendReports(LyncMessageDetails msgDetails)
at Microsoft.Rtc.Server.UdcAdapters.QoE.QoEProcessor.ProcessQueueItems(LyssQueueItem queueItem)
Cause: Configurations for the external reports consumer are not set correctly.
Resolution:
Check the External Consumer configurations. If the problem persists, notify your organization's support team with the relevant details.
Depending on the cause, and if the intent is to send the data to third-party then updating it would be a matter of checking why a connection to port 443 is failing and correcting the same. Once the connection issue has been resolved, it’s just a matter of waiting for all the VQReports to be delivered to the third-party. It may take a couple of hours, depending on the robustness of the third-party system, and the time for which you have been experiencing the failure.
If the intent is no longer to send the data to the third-party, then, you may want to run Invoke-csStorageServiceFlush to move all the data from the existing queues to the Network file share, so resources like CPU, RAM and SQL Storage are not wasted in retrying and failing and then move the XML files that were generated.
If the issue is only for a period of time, and your contract/connection with the External QOE Provider is expected to be reinstated, then you could use Set-CsStorageServiceConfiguration to configure EnableAutoImportFlushedData to $False, so data isn't imported automatically and then run Invoke-csStorageServiceFlush to move all the data from the existing queues to the Network file share, so resources like CPU, RAM, and SQL Storage are not wasted in retrying.
To understand the robustness of LYSS See: Testing IM and Web-Conferencing Archiving set to Critical