Starting in Lync Server 2010, we added a 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 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
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 ( in MSQM in Lync Server 2010 and in LySS in Lync Server 2013 and above) and then be retried.
If say, for some reason, the organization decided to change it’s course and use either Call Quality Methodology or Call Quality Dashboard, you could use Set-csQoEConfiguration to remove the configuration.
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 >:443
at 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 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 the Network file share, so resources like CPU, RAM and SQL Storage ( this is held in SQL Express ) are not wasted. It could also be possible that the Storage Service may perform a Flush Automatically, under several conditions. You might want to read my blog-post Testing IM and Web-Conferencing Archiving set to Critical to understand the robustness of LYSS.