Posts in Category "Application"

On-premise Adobe Connect Servers and Java

The question occasionally comes up: May I freely update Java on my Adobe Connect on-premise server?

And actually this question should be split into two questions:

  • What version of Java may I use?
  • What update of that version may I use?

It is important to keep these two questions separated because going from 1.6.0_37 to 1.6.0_45 is different from (more trivial than) moving from Java 6 to Java 8 (whereby compatibility issues could result).

With reference to the shipping version with Connect, our standard is Java 7, and has been since 9.1.1. Since we make every effort to keep Adobe Connect up to date with its surrounding infrastructure,we will evaluate a move to Java 8 going forward, as eventually public Java 7 updates will come to an end.

With reference to the updaters, Oracle releases quarterly Critical Patch Updates (see http://www.oracle.com/technetwork/topics/security/alerts-086861.html), and we have been striving to keep up with these (although our release cycle does often mean that we are one or two quarters behind so as to allow for time to fully test). The version being packaged with 9.4 is 1.7.0_71, the Critical Patch Update from Oct 2014.

While we  don’t believe there is any particular compatibility issue with moving from JRE 6 to JRE 7, nevertheless we do not recommend that customers update the JRE separately from Connect itself. There are multiple reasons for this:

  • We have uncovered JRE bugs in the past during our performance/longevity tests.
  • We also moved from 32-bit JRE to 64-bit JRE and this necessitated sizing changes (heap size etc.).

Heap size is an important variable that warrants performance testing to ensure that the sizing is adequate for the target JRE version. All this is due diligence is done as part of our packaged Connect builds; by updating outside of our quality assurance and performance testing cycles, you add unnecessary risk. It is best to take full advantage the battery of testing accomplished by the Adobe Connect engineering team; by upgrading the JRE separately, you will create an infrastructure with variables that have not been fully tested and thereby assume commensurate risk.

Last Minute Managing of Large Adobe Connect Hosted Seminars

Currently, as of Connect 9.3.1, Adobe Connect hosted Seminars may launch on regular Connect Meeting server instead of their designated Webinar servers. If Seminar preparation keeps the Seminar room open for an extended period just prior to to the actual Seminar itself, the Seminar may remain on a Meeting server that is not rated for a large capacity Seminar. Simple precautions will avoid this from happening.

In order to avoid this, on the day of the scheduled Webinar, be sure to open the Seminar room only 30 minutes prior to the start of the Seminar session. By opening the Seminar earlier and keeping it open for final editing right up to the start of the Seminar session, you can lock the seminar onto a regular Connect Meeting server rather than on a Webinar server designed for large capacity sessions. While you can certainly spend as much time as needed to prepare your seminar room in advance of the actual session, you should close the Seminar room for at least seven minutes prior to the actual scheduled Seminar session. Seven minutes is the time it takes the Seminar room to process garbage collection from editing and preparation activities before opening up for the real event.

Adobe is looking at ways to automate the transition from a regular Meeting server to a Webinar server with an eye toward  future release. In the interim, just be sure to time your final Seminar preparation to allow for transition to a Webinar server where large Seminar concurrency is supported with robustness.

Adobe Connect Add-in Compatibility with the Google Chrome Browser

Updated January 27, 2015:

Note: This article only applies to Adobe Connect on-premise server deployments. Adobe Connect hosted clients are unaffected.

The Google Chrome browser is currently shipping with two versions of the Flash plugin.  The default PPAPI and also the NPAPI Flash plug-in. The following versions of Adobe Connect installations are incompatible out of the box with the default PPAPI plug-in:

  • 9.1.2
  • 9.1.1
  • 9.0.1 – 9.0.4
  • 9.0.0.1
  • 8.2.2.4
  • 8.2.2

PPAPI plug-in incompatibility results in the Adobe Connect Add-in not being detected and launched in Chrome when invoked in a Connect Meeting. Even if the Add-in is installed, the meeting opens in the browser and not in the Connect Add-in. Upon attempting to share ones screen (a Connect feature supported in the Add-in but not in the browser), the following message appears:

chrome-addin.fw

Google Chrome, with the release of Version 40, will no longer use their whitelist to allow NPAPI  plugins to run without requiring approval: http://googleappsupdates.blogspot.com/2015/01/upcoming-changes-to-npapi-support-in.html Chrome users will not be able to use the Adobe Connect Add-in for the above listed versions of Connect. To address this problem, Adobe is patching the following Connect versions for use with Chrome:

  • 9.1.2
  • 9.1.1
  • 9.0.4
  • 8.2.2

These patches will fix the incompatibility problems with the PPAPI plug in. Adobe Connect servers that are not running one of these versions (or a later version) will need to be upgraded to the nearest later version to the one currently installed and then apply the appropriate Connect PPAPI patch.

There should not be any change in the behavior for Flash Player NPAPI in January because Flash Player is not listed among the applications  that are going to be removed in January:  http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

Workarounds until the patches are available:

  • You can attend Adobe Connect Meetings without the Adobe Connect Add-in, however the Add-in is required for enhanced functionality like screen sharing and making offline recordings.
  • Turn off auto-upate in Chrome so that you do not upgrade to a version of Chrome that is problematic.
  • Alternatively you can use any browser other than Chrome with Adobe Connect.
  • Manually enable NPAPI by clicking on the “Plug-in blocked” message in the URL bar and choosing “Always allow plug-ins on [website]” http://www.chromium.org/developers/npapi-deprecation

 

chrome-enable.fw

Note: In April 2015, this will no longer be an option as NPAPI support will be disabled by default in Chrome and Google will un-publish extensions requiring NPAPI plugins from the Chrome Web Store. Google will however provide an override for advanced users in the form of an ‘enable-npapi’ flag and enterprise policy to temporarily re-enable NPAPI.

The Adobe Connect API Accepts Special Charaters (+,$,# etc) if Executed with Encoded Values

Description : The Adobe Connect Web Services API accepts special characters such as (+,$,# etc) if you encode the characters. For example:

If a user Login employs the credentials shown below on the User Interface, it will work without issue.
User Name :- abc+def@adobe.com
Password :- Passw0rd

However, when the user uses the following API “/api/xml?action=login&login=abc+def@adobe.com&password=Passw0rd”

The plus sign is interpreted as though it were a space and the Login looks like this “abc def@adobe.com” resulting in the following:

  • <results>
  • <status code=”no-data”/>
  • </results>

In order to employ these special characters, you must encode them and then execute the API.  For instance in the above case we will execute an API as shown below :

/api/xml?action=login&login=abc%2Bdef@adobe.com&password=Passw0rd

Special character encoding reference information is found under URL :- w3schools  This reference is useful for those users who are trying to run API with special characters.

PDF document does not upload into Adobe Connect

Problem: Adobe Connect could not process this document for viewing. (Either the full document does not upload or some pages of within a document do not upload)

NA5

Environment:

Adobe Connect Hosted/Licensed

Resolution:-

Use the “Sanitize Document” Feature to get rid of all the following types mentioned in the image attached below. Depending on the version of Acrobat you are running, you may need to install a trial version of Adobe Acrobat Pro to use this feature.

 

image001

Make Certain that Content is Replicated Across All Servers in a Connect Cluster

Occasionally a specific piece of content may be intermittently available in a cluster. It could be Presenter or Captivate published on-demand content or even content within a Meeting room. Sometimes in these cases, the content published on one server is not replicated to all servers in the cluster. There are a few quick things to check:

First: Note that with Adobe Connect 9, the installer includes a cluster option. If you begin with a single server installation and expand later to a clustered environment by adding a server or servers, you will need to manually make the following change in the /appserv/conf/server.xml file in order to enable communication over port 8507 among clustered servers. It is prudent to double check this in the server.xml file after installing even if the cluster option was selected during installation:

<Executor name=”clusterThreadPool”
namePrefix=”cluster-8507-” maxThreads=”150″
minSpareThreads=”5″/>

<!– Define a non-SSL HTTP/1.1 Connector on port 8507 –>
<!– Used for HTTP access for intra-Cluster communications. –>
<!– Equivalent to JRun CLUSTER_PORT –>
<!– Uncomment for clustered deployments
<Connector port=”8507″ protocol=”HTTP/1.1″
executor=”clusterThreadPool”
enableLookups=”false”
acceptCount=”100″
connectionTimeout=”20000″
URIEncoding=”utf-8″/>

Second: Test the 8507 port communications on each server: From a command prompt on each server, type netstat –an|find “8507” and check to be sure that 8507 is active and listening on each.

netstat -an|find “8507”

netstat.fw

Use telnet to test connectivity on  8507 between Connect servers. Use telnet to check both IP and machine-name as well.

telnet server-machine-name 8507

telnet 8507.fw

Note: The machine name appears to the left of the FQDN under the Connect Servers Setting on port 8510 locally on any server in the cluster; here I have artificially designated them as server1 and server2.

serversettings

Be sure to check telnet connectivity from and to every server in the cluster:

telnet 8507.fw

If the IP works with telnet and the machine-name does not work, it may be necessary to add entries in DNS or add hosts files to each server:

etc-host.fw

Check the software-based firewall on the server to see if it is potentially blocking replication traffic:

netsh firewall show config

firewallsftwr.fw

win-firewall-svc.fw

Note: Connect does not support dual stack ipv6 and ipv4 on the same server.

Note: If problems are noticed in the Meeting rooms, check port 8506; it is used for Meeting communication among the servers.

Third: Examine the Connect logs: Look first in the debug.log under the \logs\support directory and search on the string: cluster-  If replication is taking place, you will see this repeating cluster- entry logging the replication activity. Absence of these log entries will indicate that replication is not working:

[10-1 12:00:00,009] cluster-8507-630 (INFO) CLUSTER Sent file: \7\xxx-xxxx\fcs-meeting\public\all\224_XXX_4.fso 9978 bytes 12 ms 6371 kbps to: server1

cluster-debug.fw

Check for any error messages in these replication log entries. Search also for the word lucene. If you see a preponderance of lucene lock errors, contact Adobe Enterprise Support: entrsupp@adobe.com and provide a log snippet to expedite diagnosis.

Also check the error.log files for the entry  CLUSTER_CON_BROKEN

2014-10-02 15:28:48 “Server server1 unable to reach server2 on port 8507 to perform cluster operations.” CLUSTER  CLUSTER_CON_BROKEN

Fourth: Check the timing of active anti-virus scanning of the content directories \content\7\ on each server; compare the directory sizes on each server to see is there if a significant size delta. Antivirus software can impede replication in manner that is not uniform across servers; active scanning of the content directory during replication may lock the content files. Active scanning after hours or during a window when publishing is unlikely is prudent.

Fifth: Check the updater page. Make sure you are on the latest patches servers-side. http://helpx.adobe.com/adobe-connect/kb/connect-90-patches.html Keep in mind that 9.2 is a full installer and not a patch. For full installers, use LWShttps://licensing.adobe.com

These steps will solve most replication problems that you encounter. If problems persist, contact our  Enterprise Support Team.

Testbuilder Status’ Explained

When setting up an application-level health monitor (blog) on your LTM, you would point to the testbuilder diagnostic page at:

/servlet/testbuilder

As the previous article explains, ‘the testbuilder page will send back the “status-ok” string.  If there is any problem with the Connect server application, then testbuilder will not report the “status-ok” string’.  Expanding on this a little bit, the following (below) are the actual status’ and possible scenarios you may see:

STATUS_OK = 0;
STATUS_CRITICAL = 2;
STATUS_MAINT = 3;
STATUS_TEST = 4;

 

STATUS_OK = 0;
This means the server is fit to work (status-ok). Server status in PPS_ENUM_DATA_HOST table is neither ‘X’, ‘M’ nor ‘T’ and server is initialized.
This is what load balancers should look for health check.

STATUS_CRITICAL = 2;
Server is not fit to work (status-critical). Server is not yet initialized (during start up), or has server status of ‘X’ in PPS_ENUM_DATA_HOST table.
This is also triggered if no connection to database can be made.

STATUS_MAINT = 3;
Server is in maintenance mode (status-maintenance). Has server status of ‘M’ in PPS_ENUM_DATA_HOST table.
Active server can be put to maintenance mode and vice versa.  No new meetings will be run on this server, but currently active meetings will run until ended.

STATUS_TEST = 4;
Server is in “server isolation” mode (status-testing). Has server status of ‘T’ in PPS_ENUM_DATA_HOST table.
Used to put server in separate zone from other servers in cluster. This is hosted feature that is not actively used in production.

Connect Reports Never Returning Data in Firefox

reports
The Adobe Connect Reports module is Flex based and for longer queries (reports on courses or curricula with large enrollments for example), sometimes the report can take many minutes to return data back to the browser.  Previously we have worked on issues with the reporting module in which the busy cursor (spinning wheel) continues to spin indefinitely and doesn’t return data because the query took too long to return.  We have made adjustments to the DB views and code to fix the performance of the reports in the latest versions of Adobe Connect and up until recently, we had solved this problem for users running the latest versions of the application.

However recently we have seen with newer versions of the Firefox web browser, the reports once again spin indefinitely and not return data in the Flex based reports in some instances where the queries are large.  Investigation into this lead us to determine that after a period of 5 minutes, we saw a socket write error in the debug log like the one below:

[05-29 10:15:30,623] http-80-15 (INFO) Exception caught in Rows.parse(), e= org.xml.sax.SAXException

ClientAbortException:  java.net.SocketException: Software caused connection abort: socket write error

After changing various FireFox timeout settings to no avail, we noticed the following newer setting ‘network.http.response.timeout’, which was introduced in Firefox 29 (the current version is 30). The default value for this timeout is 300 seconds (5 minutes).  In previous versions there was no default value.

After changing it to a longer value, the reporting now works in our testing. With the current implementation of the reporting module, there is no way for Flex to detect that the http response has timed out. Until we can address this in the Flex code and provide a warning, we just have to be mindful of this setting in FireFox.

To change this setting, you simply type this in the Firefox browser address bar: about:config and hit enter.

You will see a page with all of the configurable settings.  Search for ‘network.http.response.timeout‘ to isolate just the one setting you need to change (there are a lot of settings to scroll through otherwise).  The default value is 300 seconds (5 minutes).  If you are running into the situation where your reports are not coming back with data (and you are running the latest version of Adobe Connect , 9.2 and above), you can adjust this setting to see if it helps (if you are using Firefox as a browser).  If you anticipate users having to run large queries (like curriculum reports with large enrollments in the 1000s of users), you will need to adjust this setting.

ffsetting1

Type ‘about:config’ in the address bar. Then search for ‘network.http.response.timeout’

ffsetting2

Modify the value by clicking on the 300 value itself and then entering the new value when prompted.

 

 

Adobe Connect 9.2.2 Patch Now Available

The Adobe Connect 9.2.2 On Premise (Licensed) patch is now available for download at:

http://helpx.adobe.com/adobe-connect/kb/connect-90-patches.html

This download includes deployment instructions. It is intended for installation on Adobe Connect servers already running 9.2, as this is a patch (not a full install).

 

 

Ensuring that Email Generated by Adobe Connect Servers is Received

There have been more than a few incidents reported on the topic of email messages from Adobe Connect servers not getting delivered. These include messages generated by the Adobe Connect Events module as well as system email messages such as that generated by changing a password.

The first thing to avoid to prevent this problem is that of using special characters in the host’s name. This is scheduled to be fixed in Connect 9.3, but currently, in 9.2, if you place a comma in the Event host’s name such as Frank D., El Presidente’  it will cause an error identified in our server logs by a messaging exception.

The second thing to avoid is inviting over 20,000 participants to an Event. This generates an operation size error and causes problems with email messages being sent out. We also plan to address this ceiling tentatively in Connect 9.3.

With specific reference to Adobe Connect Hosted accounts, we just made the following change to ameliorate email problems: As of April 28th, 2014, administrative email notifications sent from Adobe Connect servers will now be coming from admin@adobeconnect.com instead of admin@acrobat.com This will help by disassociating Connect-generated email from that of the Acrobat domain which could be potentially blocked by virtue of its identification with document storage. We also made some internal changes to the way the Connect servers handle email and we worked with our Web infrastructure partners to insure that Connect generated email was not being treated as SPAM on the Web.

There is a bit of a conundrum here. If Adobe Connect Events email invitations are sent out in massive mailings to those who perceive the email as SPAM, then the Adobe Connect servers could be tagged as producing SPAM by those end-user recipients. An overzealous Events manager may cause Gmail and other providers to treat Adobe Connect email as SPAM. When an Event that is capped at 500 participants sends out 5000 email invitations, it is expected that many recipients will at best ignore the inbound email traffic and many more may consider the traffic to be a nuisance. We are investigating possible approaches to ameliorate this problem and plan in 9.3  to add an opt-out option for Events invitations that will offer a convenient alternative to any SPAM reply option for recipients to invoke.

We love large Events and Adobe Connect handles them very well; this is a case when our success can potentially lead to some problems. Currently the Adobe Hosted Service is green for SPF record checks.  We pass all major email providers and are not blacklisted according to common checker tools on the internet.  This should resolve the lion’s share of current email issues and the upcoming changes in 9.3 will serve to harden this capability for future Events.