It’s apparently an issue where the Web Conferencing Edge Service had problems talking to the Web Conferencing Service on the Front End for client persistence and the services just needed to be restarted.Yes, you heard me right: I refuse to use Outlook 2013 day to day. I then restarted the Web Conferencing Service on the Front End. I tried restarting the Web Conferencing Edge Service but had the same issue. The last such client which was disconnected is “22.33.44.55:46361″.Ĭause: Failed to process data received from the clientĬheck and make sure that the connection came from a trustworthy client. Over the past 599 minutes Lync Server has disconnected clients 1 time(s) as a result of invalid data being received on client connections. This could indicate an attack being by a rogue client.įailed to process data received from the client This can also be the result of a client attempting to connect to Web Conferencing Server without having the appropriate permissions.Ĭheck to make sure that the Web Conferencing Server and Web Conferencing Edge Server machines and verify that the connection came from a trustworthy client. The last such client which failed validation was “22.33.44.55:50307”.Ĭause: This can occur if the Web Conferencing Server and Web Conferencing Edge Server machine time(s) are out of sync. Over the past 44 minutes Lync Server has failed to validate cookie presented by the clients 5 time(s). I looked at our Web Conferencing Edge and noticed two errors (neither of which you will find any information online about them… I guess I am the lucky one): It’s a Web Conferencing Edge problem, not something with the client to the Reverse Proxy. What I noticed is, I got the same exact errors even when trying to utilize polling or whiteboarding. I tried the other Web Conferencing functionality on the client. This verified the client was really not even getting to the point of trying to communicate with the Reverse Proxy, especially since the Network Monitor logs didn’t even see the request try to go out.Īt this point, I was at a bit of a loss and went back to basic troubleshooting more and sometimes, we often overlook the basics. When I started the Query, I saw absolutely no traffic for Web Conferencing PowerPoint Presentations at all. Once ready to start logging, choose the Start Query Option.
You can easily obtain your Public IP on your client machine by going to Once done, choose Update. Once at the bottom of the dialog, choose Filter By IP and set the Value to your Public IP Address.
I went to the Logs & Reports and modified the filter I wanted to see anything that came into it with my Client IP Address. So I went onto our Reverse Proxy Server which is Microsoft Forefront Threat Management Gateway (TMG). But when I tried uploading a PowerPoint Presentation in an Online Meeting, I never saw a call go out to the Reverse Proxy. Because of this, I knew the Reverse Proxy was functioning just fine, especially since I could also access our Simple URLs ( and from the outside). What I saw is, when I would add a new distribution list to my contact list which is a function of the reverse proxy, I properly saw in the trace the client make a request out to the public IP of our Reverse Proxy Server. The first thing was that I loaded up Network Monitor on my client. I did two things to troubleshoot whether it was the client hitting the reverse proxy and having it not function correctly.
#NOT SEEING SCREENSHARE LYNC WEB APP UPDATE#
#NOT SEEING SCREENSHARE LYNC WEB APP DOWNLOAD#
Enabling remote users to download files from the Address Book service.Enabling external users to expand distribution groups.Enabling external users to download meeting content for your meetings.For those that don’t know what the role of a reverse proxy server is in Lync Server 2010, the Reverse Proxy handles the following traffic for remote users: Immediately, I thought that this was an issue with the reverse proxy. I recently encountered the following issue when a remote user were to try to upload a PowerPoint Presentation while internal users had no problems. The Issue and the Troubleshooting that Ensued
0 kommentar(er)
