Meeting Connection Test Page Fails at Step Two
Issue: Meeting test page fails at step 2; there are many possible causes for this:
1. If it is failing when you attempt to connect through a remote edge but does not fail when you connect directly to an origin, then the most likely culprit is name resolution. Audit your remote Edge name-resolution against these tutorials:
Adobe Connect Edge Server Deployment Options: part 1
Adobe Connect Edge Server Deployment Options: part 2
2. MS Patch MS12-006 (installed on client workstation) has been problematic:
MS Update MS12-006 (http://technet.microsoft.com/en-us/security/bulletin/ms12-006) causes step two of the meeting test page to fail; more details on the Patch regarding TLS/SSL can be found here: http://support.microsoft.com/kb/2643584
3. Other network and client-side constraints and configuration issues can cause this test to fail. In order to troubleshoot, try the following tests and gather the data from them:
For on-premise customers who are experiencing a failure at step two, try hitting the test page on the Adobe hosted service:
Firefox and IE should look like this:
Chrome looks like this; notice the absence of an addin:
To drill deeper, click on the Send Results link:
And then click on the Details link
Note: Currently, as of the writing of this blog entry, in Connect 9.1, there is a known bug that prevents the addin version from appearing in the the meeting test-link output. In the screen capture above, you only see the Flash-player version. This is scheduled, tentatively to be fixed in Connect 9.2.
You may copy and paste the output from the details link to assist the Adobe Customer Care team with diagnosing meeting connection issues. Do not use the Send Results link on the meeting connection test page, but manually copy and paste the results into an email.
On the meeting test page, if you find that you need the addin, (excluding Chrome) simply click on the Downloads link:
Note that the Flash-player download link is also available:
The meeting test link has some limitations, for example, it will not diagnose tunneling RTMP(S) over HTTP(S). To figure out if you are tunneling and thereby experiencing additional latency and connection drops caused by something on the network blocking RTMP, (usually a proxy or firewall), look in the upper left corner of a live meeting room and see if there is a “T” in the output when you click on the green connection indicator:
All of this information is vital when trying to diagnose meeting connection issues.
Look for an upcoming blog article on diagnosing and traversing sources of network blockages of RTMP(S) resulting in tunneling RTMP(S) over HTTP(S) and causing increased latency in a meeting. You should have a lightening fast connection and it is very doable with the right configuration: