Posts in Category "Install"

7.x Recordings Not Playing after Upgrading to 9.1.1

If you have recently upgraded an Adobe Connect on premise deployment from version 7.x to 9.1.1 (with various 8.x steps possibly in-between), you may encounter an issue where older recordings no longer launch.  However, newly created recordings open and playback without issue.

If this is the case, please check the following directories…

First check:

[Root Connect Install]\9.1.1\appserv\common\meeting\shell

This directory should contain the following SWF files:

  • BreezeUIComponents.swf
  • CorePodCollection.swf
  • meeting.swf
  • meeting_sgn.swf
  • shell.swf
  • shell_sgn.swf
  • StamperSymbols.swf

If they do NOT exist in that directory (but just the ‘breezeLive’ folder and xml files are the only files present), please download the files from here and place into the directory.

Then check:

[Root Connect Install]\9.1.1\appserv\common\meeting\launcher

This directory should contain the following SWF files:

  • listener.swf
  • openmeeting.swf
  • openmeetingversioncheck.swf

If they do NOT exist in that directory, please download the files from here and place into the directory.

After confirming these files are now in those directories, retry launching an older Connect recording.  No restart is required.

Upgrade to Adobe Connect 9.1 causes Avaya Adaptor to be broken

Problem :

If you’ve upgraded your Adobe Connect server to version 9.1 and you already have Avaya adaptor configured, you might find it broken after the upgrade.

You might also run into this issue if you have a fresh installation of 9.1 and you are configuring Avaya adaptor for the first time

Reason :

The adaptor path is incorrect in the telephony configuration files in version 9.1

Environments Affected : Connect 9.1.1 Licensed

Solution :

  • Locate the following folder on your Adobe Connect 9.1.1 root installation : {Connect-Root}\9.1.1\TelephonyService\conf
  • Create a backup copy of  telephony-settings.xml file
  • Open the file in a text editor and locate the following lines for Avaya adaptor : <telephony-adaptor class-name=”com.macromedia.breeze_ext.telephony.AvayaAdaptor” enabled=”true” id=”avaya-adaptor”>
  • Replace the line with the following : <telephony-adaptor class-name=”com.macromedia.breeze_ext.telephony.Avaya.AvayaAdaptor” enabled=”true” id=”avaya-adaptor”>
  • Save the file and reopen the file with IE to make sure there are no errors.
  • Next, Create a backup copy of  telephony-capabilities.xml file
  • Open the file in a text editor and locate the following lines for Avaya adaptor : <telephony-adaptor class-name=”com.macromedia.breeze_ext.telephony.AvayaAdaptor” enabled=”true” id=”avaya-adaptor”>
  • Replace the line with the following : <telephony-adaptor class-name=”com.macromedia.breeze_ext.telephony.Avaya.AvayaAdaptor” enabled=”true” id=”avaya-adaptor”>
  • Save the file and reopen the file with IE to make sure there are no errors.
  • Restart the Adobe Connect & Telephony services.

 

Connect on VMWare – some deployment tips

Issue: VMWare is ubiquitous in the enterprise and while it opens up huge potential for management of the Connect infrastructure, it must be planned and executed with an eye toward robustness.

This advice is gleaned from conversations with senior persons on our operations team as well as from support cases generated by various customers with on-premise VMWare deployments of Connect.

One of the most important and often overlooked variables about virtualization is to make certain that  VMware is compatible with all the underlying components of the server and network architecture. The infrastructure supporting VMWare must be verified by VMware under their Hardware Certification Program or Partner Verified and Supported Products (PSVP) program; be sure to use certified hardware.

Here is the link to the compatibility reference:  http://www.vmware.com/resources/compatibility

With Connect you must consider both Tomcat and  FMS; the former can run on most anything, while the latter is a bit more demanding; RTMP can be acutely;y affected by latency and packet transmissions. If you notice unpredicted latency or a surprise crash of FMS with Connect 9.1, a good test would be to check the network components; sniff for packet transmission issues – have the vNIC of the guest VMs configured to use VMXNET3; this is a good place to start.

With reference to recommendations and best practices, it really depends on the VMware infrastructure adopted. The following references serve as a guide for an enhanced environment:

Enterprise Java Applications on VMware – Best Practices Guide: http://www.vmware.com/resources/techresources/1087

Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs: https://www.vmware.com/resources/techresources/10220

Performance Best Practices for VMware vSphere 5.1: https://www.vmware.com/resources/techresources/10329

The key with Network Storage is speed. If you lose connectivity to the shared storage then only what is cached on the origins will be available.

Shared storage requirements

  • Disk specs: 10,000–15,000 RPM — Fibre Channel preferred
  • Network link: TCP/IP — 1GB I/O throughput or better
  • Controller: Dual controllers with Active/Active multipatch capability
  • Protocol: CIFS or equivalent

Avoid, virtualizing the Connect database if possible.

I have seen that in some customer-based VMWare environments that are overtaxed, that latency among the servers on 8507 (and 8506), can cause problems. Intra-cluster latency (server to server communication) should never exceed 2-3ms. When it does we see intermittent crashes. I had one customer who had a particularly weak infrastructure and for whom I could predict his crashes; he was doing back-ups and running other tasks at a certain time weekly that would tax and hamper network connectivity for about an hour; these tasks were so all-consuming on the network, they turned every cluster resource into an individual asset on its own island. The log traces bore this out and we knew with precision what was going on. He knew he needed to upgrade his infrastructure and in the meantime we worked out a reaction plan to deal with the issue; it included:

  1. Place a higher than normal percentage of cache on each server to limit invoking shared storage
  2. Set the JDBC driver reconnection string for Database connectivity
  3. Plan Connect usage around these maintenance activities and when possible, do Connect maintenance activities at the same time as well – not very difficult as these were after hours, but being a  global operation, still not a given.

Presenter 9.0.2 Now Available

Presenter 9.0.2 is now available as an updater here:

http://www.adobe.com/support/downloads/product.jsp?product=153&platform=Windows

This is the update for existing Presenter 9.0 customers.

The full installer for Adobe Presenter 9.0.2 will be made live on November 18th – which means the existing build of Presenter 9.0 will be replaced on the Adobe online store, trial downloads, our Licensing system, and DVDs, with Presenter (9.0 + 9.0.2) consolidated installer.

The normal Presenter release notes have therefore been updated to include Presenter 9.0 PLUS Presenter 9.0.2 features and is live now. View the release notes here.

Release notes specific to Presenter 9.0.2 are found here and point out Presenter 9.0.2 details separately.

You can also download and install the update directly from inside of Adobe Presenter 9 by going to the Adobe Presenter > Help > Updates menu (pictured below).

 

presenter902

 

 

In the end (after updating), you should see the following version when going to: Adobe Presenter > Help > About Adobe Presenter…

presenter902a

 

 

Issue with upgrading CQ (Events) on standalone server

Note:

This article is for On-Premise (Licensed) Adobe Connect customers with the Events module who may be thinking of upgrading to 9.1.

This only applies to customers who meet ALL of the following criteria:

  • Customers who have installed CQ at the Adobe Connect 9.0 level (officially 9.0.0.1) and who are upgrading to 9.1 (officially 9.1.1)
  • Customers who have installed CQ on a standalone machine (so not on the same server or servers as Adobe Connect)
  • Customers who have installed CQ on a drive other than C:/.  

We have uncovered an issue with upgrading CQ (Events Module) from 9.0 version to 9.1 version on a standalone server where you would have installed CQ on a drive other than the C:/ drive.

With Adobe Connect 9.0.0.1 (the full 9.0 installer’s actual version), we introduced Adobe CQ as the backend for the Events module in Adobe Connect.  This required you to install CQ on either the same server as Adobe Connect, or on it’s own dedicated (preferred) server or servers (if in a cluster).  A typical workflow would have been to install the CQ application for both the Author and the Publisher instances of CQ on a drive other than the C:/ drive on the server (or servers).  The full installation of the original 9.0 version of CQ would have given  you the option of installing CQ wherever you wanted (say for this example, the ‘E:/’ drive).

With the latest (as of October, 2013) version of Adobe Connect and CQ (9.1.1 officially), we introduced a new version of CQ.  So customers who already installed CQ at version 9.0, would have already had CQ on a machine and would be upgrading CQ by running the new 9.1 .1 Adobe Connect installer on that server.  This is where the problem is.  The installer, for an upgrade to CQ will not give you the option to choose the installation folder/location. It just goes through and installs in the C:/ drive, which is obviously not correct if you installed in another location.

There is a workaround for this.

For now, you can work around this problem by adding a property value – USER_INSTALL_DIR=<old Installation directory> to the file <INSTALLER_ROOT>\Standard_DVD\Connect\9.1.1\Disk1\InstData\VM\cps.properties. Any valid installation path can be provided but format of the old installation path has to be either E:/Connect or E:\\CONNECT (or whatever drive letter you are using).

Note: Again, the full installation of 9.1 will allow you to choose the installation directory. The issue detailed above is only for upgrades from 9.0 to 9.1 CQ.

This issue with the installer will be addressed in Adobe Connect 9.2, which will be coming in Q1 of 2014.

 

Connect On-Premise Installer for 9.1.1 on the Adobe LWS – Version Questions

Issue: There was an earlier version of 9.1 that looks very similar to the current (9.1.1), but the earlier version is missing some important updates. This will be fixed with the release of Connect 9.1.2

Solution: The normal way to check the Connect version is to poll the version.txt file at any Connect account domain name. To see an example, check this Adobe Connect hosted account for one of our training partners:

http://reximedia.adobeconnect.com/version.txt

The output from this shows the versions of all components of the release: package=9.1.1.80.20130729.1194934… patch=CPS_9.1.1.55_9.1.1.59, patch=CPS_9.1.1.59_9.1hotfix.12

This normal means of checking the build will not work with the 9.1.1 released installer. See the output from its version.txt:

package=9.1.1.92.20130804.1194934….

The version.txt is missing the patch numbers.

Workaround technique to find the version:

Look in the downloaded zip installer for versionInfo.xml

  • The date should read: 2013/09/27:08:12:57
  • The build should read: 9.1.1.5.20130924.1215873

This is valid as of the writing of this tech-note. It is safe to say that if you see a later date and build number on a full installer download, then you are not going to see this problem and your version.txt will be correct.

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:

https://my.adobeconnect.com/common/help/en/support/meeting_test.htm

Firefox and IE should look like this:

FFMT.fw

Chrome looks like this; notice the absence of an addin:

ChromeMT.fw

To drill deeper, click on the Send Results link:

FFMTSendResults.fw

And then click on the Details link

FFMTSendResultsDetails.fw

FFMTSendResultsDetailsPV.fw

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:

FFMTDownloads.fw

Note that the Flash-player download link is also available:

FFMTDownloadsAddinFP.fw

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:

.tunneljpgOctagon

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:

no-tunnel-star.fw

Stunnel does not Startup with Connect

Problem: stunnel does not start up with Connect

Although stunnel can be installed as a service, it doesn’t load the stunnel.conf file(!) one workaround is to not setup the services to run automatically but to auto-run these batch files at startup:

Note: This tech-note assumes stunnel is installed in c:\Connect\9.0.0.1\; be sure to adapt the scripts accordingly.

Origin server startup.bat:

@ECHO ON
net start FMS
net start FMSAdmin
net start ConnectPro
net start CPTelephonyService
c:\Connect\9.0.0.1\stunnel\stunnel.exe stunnel.conf
@ECHO OFF Origins stop.bat:

@ECHO ON
net stop ConnectPro
net stop CPTelephonyService
net stop FMSAdmin
net stop FMS /y
@ECHO OFF

If you have remote Edge servers, use these; they includes cache clearing maintenance.

Edges start.bat:

@ECHO ON
net start fms
ping 1.1.1.1 -n 1 -w 10000>nul
net start fmsadmin
c:\breeze\edgeserver\stunnel\stunnel.exe stunnel.conf
@ECHO OFF

Edges stop.bat:

@ECHO ON
net stop fmsadmin
ping 1.1.1.1 -n 1 -w 10000>nul
net stop fms
ping 1.1.1.1 -n 1 -w 20000>nul
del /Q /S c:\breeze\edgeserver\win32\cache\http\*.*
ping 1.1.1.1 -n 1 -w 10000>nul
@ECHO OFF

Run > gpedit.msc
Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown)
Batch files are assigned as startup & shutdown scripts. This is in addition to being available to be run manually.

Providing Diagnostic Data to Expedite Solutions for Connect Meeting Issues

Issue: Anything that may happen during a meeting which has a pejorative effect on end-user experience.

Solution: In Connect 9.1 we have a great diagnostic option in the meeting room. You can immediately pull logs from any meeting to diagnose:

If you click Help>About Adobe Connect, while holding down the Ctrl key, the debug logs will appear int he meeting room and you will have the option to copy them to your clipboard.

log-mtg.fw

 

log-mtg1.fw

Sending me these, along with the RTMP string  Help> About Adobe Connect, while holding down the Shift key – this will be most helpful from the client experiencing the extreme latency.

rtmp-mtg.fw

Now if you want to take it even one step further and provide a client-side view of the meeting:

The instructions for enabling client-side logging are here: http://helpx.adobe.com/adobe-connect/kb/enable-logging-acrobat-connect-professional.html

Providing all this data along with the date and time (including timezone) and Meeting URL of any issue, will greatly expedite analysis and solution.

Resource Constraints cause Connection Read Error in Logs on Clustered Connect Servers

Issue: FCSj_IO:4 (x) – Connection read error: -1 LP: 5345 RP: 8506 URI: rtmp://localhost:8506/meetingapp/7/12345678

I have seen that in some VMWare environments that are very overtaxed for resources, latency between/among the clustered Connect servers on ports 8507 (and also 8506 though 8506 does not cause this error), can cause problems. Intra-cluster latency should never exceed 2-3ms. When it does we see intermittent errors and can also see crashes.

I had one unnamed customer who had a particularly weak infrastructure and  I could predict his crashes; he was doing back-ups and running other tasks at a certain time weekly that would severely hamper network connectivity for about an hour; these tasks were so all-consuming on the network, they turned every Connect cluster resource into an individual asset on its own island. The Connect logs bore this out and we knew with precision what was going on and could predict his call or email based on his maintenance schedule. He knew he needed to upgrade his infrastructure and in the meantime we worked out a reaction plan to deal with the issue; it included:

  • Place a higher than normal percentage of cache on each server to limit invoking shared storage during maintenance (see page 57)
  • Set the JDBC driver reconnection string for Database connectivity robustness
  • Plan heavy Connect usage around network and server maintenance activities and when possible, do your Connect server maintenance activities at the same time as well.