Posts in Category "Install"

Troubleshooting On-premise Server Upgrade error: could not find public key

Upon upgrade, if you choose a new installation directory (such as changing a breeze directory to a connect directory) and then cannot start the Connect services, check the debug log for the following error message:

[07-28 09:19:39,957] cps-startup (ERROR) ConfigProperty.initPublicKey(), could not find publickey in C:\breeze\9.3.1\appserv\keys\

There is a database entry in the pps_config table that corresponds to the \appserv\keys\ directory. You may need to manually edit it:

select * from PPS_CONFIG where NAME = ‘config-keys-path’

upgrdkey.fw

upgrdkey1.fw

Find the actual location of the \appserv\keys\ directory and make sure the database points to it:

upgrdkey1a.fw

upgrdkey1b.fw

After updating pps_config, attempt to start the services and gain access to the console.

On-premise Connect Installation Hangs Connecting to the Database

Symptoms: Installing with clean images on servers, the Connect Installation with the appropriate local Administrator permissions seemed to be successful but upon clicking “Done” its hangs indefinitely. Restarting the services does not help and the Connect Configuration Console on the local Connect server will not come up. Rebooting the VM will not bring Connect up. In the error.log, it reads:

“Start up error: java.lang.Exception: invalid backup folder: \\connectsharedstorage\connect.” START_UP    START_UP_ERROR….

Note: replace connectsharedstorage\connect with your UNC path to shared storage.

Solution: This error indicates that shared storage is expected by the database but is not configured on the Connect server. This may inadvertently be overlooked during an upgrade instance when a new server (perhaps with a new OS) replaces an older server. The fresh Connect installation, upon pointing to an existing upgraded database that has possibly been updated by script or maybe by the older server image, is expecting shared storage to be in place, but it is not yet configured on the new Connect server. To get past this, edit the Shared Storage entry in the PPS_Config table of the Connect Database to “NULL” and restart the services.

Migrate existing Adobe Connect database to a new SQL server

You may please follow this workflow to migrate your existing SQL database/embedded database to a separate SQL database server on a different computer.

Prepare for the Migration  :

Prepare for the migration by stopping all the Connect services

  •  Stop Adobe Connect service
  •  Stop Flash Media Server service
  •  Stop any other Connect pro services installed(Telephony/FMG/CQ)
  •  Take a backup of all existing contents folder(Backing up entire Connect installation folder is recommended)
  •  Take a backup of the existing database(You may refer Pg 87, Install Guide if needed)

Prepare new DB server

  •  Copy the DB backup file created in above step from existing server to the new server hosting SQL server.
  •  Restore the DB on the new SQL server(Refer Microsoft instructions for details)

Reflect new DB changes on Connect server

  •  Enter the SQL Server database information in the Application Management Console on the server hosting Adobe Connect.
  •  Make sure all Connect services are started
  •  Choose Start  > Programs  > Adobe Connect Server  > Configure Adobe Connect Server
  •  Go to Database Settings
  •  Modify the Db hostname, DB name , login  and password information and Save.

Connect 9.4 Upgrade Licensing Issue

We’ve identified customers may run into this issue following an upgrade from a 9.3.x to 9.4 if you use an on-premise licensed environment.

Problem : 

After a 9.4 upgrade you might not be able to upgrade your license file to a 9.4 compatible version as specified under Step 7 of the Patch Deployment Instructions Document.

Reason : 

We have identified an issue with our Licensing servers which might prohibit you from downloading the correct license file for 9.4.

Additional Information  :

We are actively working on this issue with our Licensing team and Operations to sort this out as soon as possible.

If you are an affected customer, please do contact Support to let us know your information so we could inform you as soon as we have a fix applied. You may alternatively keep tracking this page for latest updates as we’ll post an update here as soon as we release a fix.

https://helpx.adobe.com/adobe-connect/connect-support.html

Affected Environments :

9.3.x  to  9.4 Upgrade On-Premise

Update  :  Our Licensing servers have been updated with the fix now so this issue should be resolved. If you still come across any problems, please report your concern to our Support teams.

 

 

 

Connect on-premise: Seminar licenses show as expired following an upgrade to version 9.3.1

Some customers may run into this issue following an upgrade from Connect 9.0.0.1 to 9.3.1 if you use seminar licenses.

After the successful upgrade all seminar licenses show as expired. Re-applying the license file in the console does not help and you see the following message in the debug.log:

[03-03 13:41:48,526] http-80-24 (ERROR) Exception caught in DBRows.populate(), e=java.sql.SQLException: [Macromedia][SQLServer JDBC Driver][SQLServer]Ambiguous column name ‘DATE_END’.
[03-03 13:41:48,527] http-80-24 (INFO) 1ms spid:64 com.macromedia.airspeed.db.SQLServerUtilityQueries.setIsolationLevel(Disable Isolation)
[03-03 13:41:48,527] http-80-24 (ERROR) Exception thrown
java.sql.SQLException: [Macromedia][SQLServer JDBC Driver][SQLServer]Ambiguous column name ‘DATE_END’.
at macromedia.jdbc.sqlserverbase.ddcg.b(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddcg.a(Unknown Source)
at macromedia.jdbc.sqlserverbase.ddcf.b(Unknown Source)

[…]

To resolve this, run the following query on your database to change the SQL compatibility level:

sp_dbcmptlevel ‘breeze’, 90

If your Connect database is named something other than “breeze”, then put the correct name of the database in the query.

Now re-install your license file one more time.

 

This is also the solution to a related issue: http://blogs.adobe.com/connectsupport/licensed-after-upgrading-to-connect-9-1-exception-occurs-when-clicking-on-meeting-tab/

Please contact Support if you still encounter issues.

On-premise Server: Add user-agent info to access logs

If you run your own Connect server you may want to add user-agent information to the tomcat access logs.

Here’s how to add the information:

1.  Take a backup copy of the server.xml located in \Connect\9.x\appserv\conf\.

2.  Open the file in an XML friendly editor and locate the line:

 

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”../../logs/tomcat”
prefix=”tomcat_access.” suffix=”.log” pattern=’%h %l %u %t %m “%U” %{BREEZESESSION}c %s %b %T’ resolveHosts=”false”/>

 

3.  Edit the line to include %{User-Agent}i . It should look like this:

 

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”../../logs/tomcat”
prefix=”tomcat_access.” suffix=”.log” pattern=’%h %l %u %t %m “%U” %{BREEZESESSION}c %s %b %T %{User-Agent}i‘ resolveHosts=”false”/>

 

4. Restart the Connect service and load any page of Connect.

The log output in \Connect\logs\tomcat\tomcat_access.-date-.log should now include user-agent information:

127.0.0.1 – – [23/Feb/2015:11:39:45 +0000] GET “/common/help/en/support/meeting_test.htm” breezbreezhvc7xdcgu5h3cqwm 200 16703 0.017 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

 

Enjoy logging!

Verifying the Installation of the Adobe Connect Add-in

The Adobe Connect Add-in is a modified Flash Player that enables enhanced features for Adobe Connect Meeting. The add-in is not required unless the following functionality is needed in any Adobe Connect Meeting:

  • Screen sharing a client desktop, window or application
  • Offline recording downloadable to the client in the FLV format
  • Sharing any supported file by dragging and dropping onto a Meeting share pod
  • Toast windows for Meeting management are enabled within the add-in
  • The add-in provides greater real-estate for the Meeting by eliminating the browser and actual room itself

If you are in a Meeting room using the browser and the standard Flash Player instead of the Meeting add-in, you will see the following appended to the meeting room URL: ?launcher=false

FP.fw

If you are in the add-in, the URL line is not even seen as that real-estate is allocated top the Meeting room:

addin.fw

The add-in is always launched from a browser:

brow-addin-launch.fw

To force the installation and invocation of the add-in, append the following to any Meeting URL: ?lightning=true

If while using the browser in any Meeting, you invoke a feature that is only supported in the add-in, the lightning add-in installer will quickly offer you the option to install the add-in. The process is very fast and seamless. By default, the add-in is installed from the following external URL: http://www.adobe.com/go/adobeconnect_9_addin_win

Within any Meeting room you may also go to Help>Downloads and see links for the add-in among many other resources:

help-about.fw

https://platinum.adobeconnect.com/common/help/en/support/downloads.htm

dwnlds.fw

If your organization does not allow clients to download software from external servers, you can host Adobe Connect Add-in on-premise.

The add-in installs to the client’s user profile so it does not require local administrative privileges to install. It is safe to say that if a user has the required permissions to download the standard Adobe Flash Player and install it, the Meeting add-in will not present any problems as it only requires standard user rights. There are, of course enhanced security requirement enforced in many infrastructures that will prevent a user from downloading and installing the add-in and where the add-in will need to be rolled out by an internal IT or client/network administration team as part of a standard image.

The addin is installed to the following under the user directory:

  • Windows: %appdata%\Macromedia\Flash Player\www.macromedia.com\bin\adobeconnectaddin
  • Mac: ~/Library/Preferences/Macromedia/Flash Player/www.macromedia.com/bin/

If installation is successful, within the Adobe Connect addin installation directory there will be four files:

  • adobeconnectaddin.exe  (the primary executable file)
  • digest.s (the file used by Flash Player to verify that the add-in has not been modified)
  • meetingconvertor.dll  (the file used to manage PPTX file fidelity)
  • connecthook.dll  (the file used to manage screen sharing)

A partial or corrupted installation of the add-in will be missing some or all of these files.

On occasion, the mms.cfg file will cause problems with the add-in it is found in the following directories:

  • Windows 32: C:/Windows/system32/Macromed/Flash (32-bit Windows)
  • Windows 64: C:/Windows/SysWOW64/Macromed/Flash (64-bit Windows)
  • MAC: MainDisk:Library:Application Support:Macromedia

Renaming the mms.cfg to mms.old and reinstalling the add-in solves installation problems in some cases. For information about the mms.cfg file and how it can be used for troubleshooting issues within an Adobe Connect Meeting, see the following technote: http://helpx.adobe.com/adobe-connect/kb/enable-logging-acrobat-connect-professional.html

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.

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.

Connect 9.2.1 and higher, on-premise: Deployment Options during install

When running the installation of Connect 9.2.1 (and higher) when you get to the step “Select Deployment Options” you can specify to deploy the services under “Local System Account” or to specify an existing user account.

 

InstallDeployOptions

One common reason to specify a user account is when using shared storage. The Connect service needs to have access to the network share specified in a later step during installation.

It is necessary to grant this user account “log on as a service” rights, otherwise the Connect, FMS, FMG services set to run under this user account will not start.

Here’s how to grant a user “log on as a service” right.

  1. Go to “Control Panel”, “Administrative Tools”
  2. Expand “Local Policies”
  3. Expand “User Rights Assignment”
  4. Find the Policy called “Log on as a service” and double click on it.
  5. Select “Add User or Group” and add the user account under which you want to deploy the services.

LocalSecurityPolicy LogOnAsService_addUser

 

Alternatively you could also install with the local system account option first, then go to the windows services and change the account under which the service runs from there. This way Windows would automatically assign the missing “Log on as a service” right.

To do so, go to “Server Manager”, “Configuration” and “Services”. Find the “Adobe Connect Service”. Right-click the service name and select “Properties”. Specify the user account / password under the tab “Log On”, when you hit apply you’ll get a message that “Log On as a service” right has been granted to the user account.

viaWindowsServices