Adobe Connect Support Blog

Posts in Category "Install"

On-premise Adobe Connect Servers and Java

Posted on January 12, 2015 by Frank DeRienzo | Comments (0)

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

Posted on September 30, 2014 by Frank DeRienzo | Comments (0)

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:

<!– 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”

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

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.

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

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:

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

netsh firewall show config

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

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 LWS: https://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

Posted on July 18, 2014 by Kay Poeppelmeier | Comments (0)

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.

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.

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

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.

Testbuilder Status’ Explained

Posted on July 10, 2014 by Jim Johnson | Comments (0)

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.

Update/Renew your licenses on Connect on premise installation

Upon few requests I’m listing the steps to renew/update your licenses on the Connect server installation.

Conditions in which these steps should be followed :

If you have purchased additional licenses on your existing Connect account and you wish to update them on the server
You have an Adobe Connect server installation on your own premises
You want to update additional license on your existing license key and not a completely new serial key

Please follow the below steps to update your license file on the server :

Goto the Connect server and launch the Admin Console : http://localhost:8510/console
Navigate to the License Settings tab
Click on the First link which says : Download your license file from Adobe
It is necessary to download a fresh copy of your license file after renewal or on purchasing additional licenses to see the refreshed additions.
Once it is downloaded Click on Browse on Step 2 and upload the file just downloaded
Save the page and your license should be refreshed.

If you have a clustered environment setup for the Connect servers, it is not necessary to apply these steps on all the servers.Doing it on any one of them is sufficient as it updates the settings in the DB.

Hope you would find this article useful when you want to update your licenses next time.

What files to download from LWS for Connect server installation/upgrade

Posted on June 5, 2014 by Sushma | Comments (0)

I have received requests from some users to publish what all files are necessary to be downloaded when planning to do an install or upgrade on Adobe Connect server. I know this should have confused many of us, but here I’m listing the required files.

Environment – On Premise

Goto Licenses > Downloads

Choose your product : Connect Lic General

Choose the desired version. I am choosing version 9 here

Click on Connect Lic General hyperlink at the bottom

Download both the highlighted packages for the installation

The All Platform Multilanguage/NA package contains the actuall installer files

The All Platform Package extractor is the extractor utility specially bundled with the installer and only this utility should be used to extract the installer files

I hope this makes the download process simpler for your install/upgrade next time.

Adobe Connect 9.2.2 Patch Now Available

Posted on May 19, 2014 by Jim Johnson | Comments (0)

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).

Connect on-premise Server: Configure additional ports for RTMP traffic

Posted on March 5, 2014 by Kay Poeppelmeier | Comments (0)

By default the meeting server (FMS) in Connect binds to port 1935. Here’s how to add additional ports like port 80 for use with the meeting server.

This should work with all versions of Connect. I am assuming you would like to use port 80 and 443 in addition to 1935 (all in rtmp, no encryption).
As Connect consists of two servers, the application server (Tomcat) and the meeting server (FMS) you need to configure a second IP address and FQDN in order to bind two services to port 80. Make sure your new FQDN resolves to the new second IP address. The second IP and FQDN will be used for the meeting traffic.

I am using these values in my setup:

Application Server: connect912.adobe.com – IP 10.1.1.1
Meeting Server: connect912meeting.adobe.com – IP 10.1.1.2

So here we go:

Make sure you can ping both names and they resolve to the correct IP addresses.
Open the server console and set the new meeting server FQDN in the “external name” field and save your changes.

In my setup this is connect912meeting.adobe.com:

Configure the meeting server to listen on the new IP:Port.

In my setup I am adding port 80 and 443 in addition to the default port 1935.

Open the custom.ini (by deault in C:\Connect\9.1.1\ if running Connect 9.1.x) and add these lines:

DEFAULT_FCS_HOSTPORT=10.1.1.2:80,443,1935
RTMP_SEQUENCE= rtmp://external-host:1935/?rtmp://localhost:8506/,rtmp://external-host:80/?rtmp://localhost:8506/,rtmp://external-host:443/?rtmp://localhost:8506/

Replace 10.1.1.2 with your meeting server IP address and also make sure the RTMP_SEQUENCE is in one line. Save the changes.

Restart the services, FMS and Adobe Connect service.

Once the services are back up and running you should be able to start a new meeting. If there are no firewall restrictions a meeting should connect on the first port listed in the RTMP_SEQUENCE. In this example port 1935.
To test the connection on the other ports, block outgoing connections to port 1935 on your client firewall. If the meeting is still open on your client it should briefly disconnect and reconnect on the next available port. In my setup this would be port 80.

You can check which port you are connected to in a meeting by holding down the shift key and clicking “About Adobe Connect” from the help menu (top right in your meeting).

update (03/04/2014):

It appears that with version 9.2 you also need to specify the IP address the application server binds to. By default it binds on 0.0.0.0:80, so on all available IPs on port 80.With Connect 9.2 I have come across an issue where the application server does not properly create a listener when port 80 is used for the meeting server as well.
The easiest way around this problem is to specify the IP in the application server config so it starts a listener on this one IP only.

In the server.xml in \appserv\conf\ find this section:

    <Connector port=”80″ protocol=”HTTP/1.1″
            executor=”httpThreadPool”
           enableLookups=”false”
               acceptCount=”250″
               connectionTimeout=”20000″
               redirectPort=”443″
               URIEncoding=”utf-8″/>

And add your application server IP address:

    <Connector port=”80″ protocol=”HTTP/1.1″
           address=”10.1.1.1″
           executor=”httpThreadPool”
           enableLookups=”false”
               acceptCount=”250″
               connectionTimeout=”20000″
               redirectPort=”443″
               URIEncoding=”utf-8″/>

Save the change and restart your services once again.

Adobe Connect Database Disaster Recovery Options

Posted on February 26, 2014 by Frank DeRienzo | Comments (0)

Having a good recovery strategy allows for recovery of data in case of unforeseen events such as user error, hardware failure, drone strikes and fecal tsunamis. There are three recovery models:

Simple Recovery
Bulked Logged Recovery
Full Recovery

Simple Recovery is the most rudimentary. When the DB recovery mode is set to simple, the transaction log does not get backed up. It is auto-truncated and you can only ever recover to a full db backup; this builds-in the potential for data loss as a point-in-time recovery is not possible. Generally, the Simple Recovery option is recommended for development or test environments where data recovery is not critical. It is also a good strategy for a novice DBA as you don’t have to worry about a detailed backup and restore plan/jobs. Mission critical databases should never be in simple mode, but for non-mission critical deployments it is a low-overhead alternative.

The Bulk Logged Mode is not very commonly used. When the DB recovery mode is set to Bulk Logged, bulk operations are only minimally logged (Select Into, Create Index, etc.). This results in in reduced log space consumption. The shortfall is that if the last transaction log has bulk operations in it, then point in time recovery is not possible; if it does not have bulk operations in it, then point in time recovery is possible. While it may be prudent to switch full recovery databases temporarily into Bulk Logged Mode for the purpose of re-indexing a very large database, be sure to always switch them back as critical databases probably shouldn’t be in Bulk Logged recovery mode.

Full Recovery Mode is the default recovery model and is the most granular. When the database recovery mode is set to full, everything get’s logged to the Transaction Log resulting in greater log space consumption. Point in time recovery is possible in full recovery mode. This is the recovery model most users should choose for production data. By using this recovery model with regularly scheduled full backups, differential backups and transaction log backups, it allows for quicker point in time recovery.

Choosing a backup and recovery plan is relevant to the following criteria:

How important is the Data? The more important the data, the more likely you will choose full recovery and schedule regular full backups, differential backups and log backups.
How often does the data change? How busy is the Connect server?
If the data only changes frequently during normal business hours, scheduling log backups closer together during these times and further apart during non business hours might work out.
How much space do you have available for backups? This could determine how many backups will you store and how often will you back up.
How quickly do you need to recover data? If recovery speed is not important, but point in time is, you might choose not to do any differential backups and just do Full nightly backups and regular transaction log backups.

Based on the answers to the previous questions, you should be able to determine a backup plan that fits your needs. Remember to test the recovery of your backups regularly. Backing up is useless if backups are corrupt or not working correctly.

Another important consideration is with the timing of backups. Keep in mind that performing backups is resource intensive. To help determine an appropriate schedule of your backups, consider the ongoing activities on the Connect servers.

If you want to focus on recovering data in case of fire or natural disaster then you you should consider storing the backups offsite. Many savvy DBA’s they keep a predetermined number of current backups on site and also ship the backups offsite (tape or network). They might choose to keep five current backups onsite and as many as 30 offsite.

SQL 2008 has backup compression allowing you to save on disk space, but it comes with a cost of speed. Choose the compression level that suits your speed of backup. Third-party products offer backup compression as well.

Consider also the various high availability options:

SQL clustering relies on Windows clustering. It clusters the entire server not just the database. The fail-over is slower than mirroring and doesn’t provide a fail-over against disk failure.
Mirroring (http://msdn.microsoft.com/en-us/library/ms189852.aspx) is a faster fail-over solution. The Connect SQL driver has the ability to choose a fail-over server. This can be done at the DB level.
Log Shipping ships completed transactions to the log shipped database; this can be done on the database level and requires manual intervention to fail-over as the log-shipped db is considered a warm DB

Note: Replication is not a recommended option.

Adobe’s Hosted infrastructure uses a hybrid high-availability strategy. We use database mirroring as the primary fail-over solution.It provides faster fail-over and does not have a single point of failure as does clustering which relies on the single disk. We also use log shipping as a secondary fail-over solution. In the extreme case that all mirrored databases go down, the log shipped database can be used with some user intervention: Break the log shipping, take the database out of standby mode and point the Connect server to it.

Adobe Connect Database Performance and Monitoring

Posted on February 26, 2014 by Frank DeRienzo | Comments (0)

Following SQL database performance best practices and monitoring the health of you Connect database will help to insure a responsive Connect server providing excellent end user experience.

It is best to always place the operating system, data and log directories on separate disk drives; this will result in improved performance. If you must put Connect on the same server as the DB (never a best practice but sometimes a practical necessity), you should ensure that the Connect installation and content directories are on a different disk drive than is the database data. The Temp DB should also be on a separate disk drive. Putting the SQL data on striped disks, provides a tuning benefit as well.

Be sure to aggressively re-index and update statistics. De-fragment the operating system data and log files on a regular schedule. Ensure that there is minimal latency between the Connect server and the SQL Server. Be wary of network maintenance and backups that can produce latency between the Connect server and the SQL server and be sure to avoid heavy Connect use during any such maintenance.

Make sure that the SQL server has plenty of RAM; the more RAM the better. Everything works much faster in memory. The more of the database that you can keep in memory the better off you will be. Only virtualize the DB server if absolutely required.While Connect runs fine on supported VMWare servers, the SQL database server is best run on a dedicated platform

With reference to the use of separate disks, here is a prioritized list of what should have its own disk:

Operating System
Adobe Connect (Separate Server if possible)
SQL database
Data
Log
TempDB
Transaction logs

For best performance, set the initial size of the transaction log file based on estimated use. This avoids unnecessary fragmentation. The transaction log should be on a different drive than is your data file, temp database and operating system. Manually shrink the transaction log files based on monitoring. If you try to do this as a nightly or weekly job, you will end up with unnecessary fragmentation. De-fragment the transaction log file as necessary and consider putting transaction logs on striped disks. Ensure regular backups as transaction log backups empty the space inside the log file and prevent it from continuing to grow.

Manage the memory by setting the minimum server memory for SQL server. Remember to leave enough for the operating system and any other applications running on the server:

SQL Server uses the tempdb database as a working area for temporary tables, sorting, sub-queries etc.; the tempdb should be stored on its own drive away from other DBs whenever possible. The default location is on the SQL install disk. Increase the size of the tempdb database based on expected usage and available space. SQL Server automatically adjusts the size over time, but each change causes a performance hit and causes fragmentation. By increasing the size, you avoid constant growth. SQL 2008 uses the tempdb more than prior versions of SQL. Never try to backup the tempdb.

Monitor the disk space of the data files and log files. Disk space is inexpensive when compared with the benefits it provides when available in abundance. You should aim to keep at least 30% free disk space in case you need to expand the data/log files, or if they are set to autogrow. Sudden increases in size should be cause for investigation.

Monitor the fragmentation levels. If the database and log were set to autogrow at small intervals, there is a high likelihood that they are fragmented. If you regularly shrink the DB data files or log files, that could also lead to fragmentation

Monitor for slow queries; you can see slow queries in the Connect debug log. Just search for Slow Query. Query times are returned in msec. Also look for lock timeouts in the debug log. Generally this is a sign of database problems. A lock timeout is a query that attempts to get a lock on a database resource. It times out because something else is already holding a lock. A lock is usually held until the transaction has completed, so if there is a long running query it could cause lock timeouts. You can also run traces against the database to gather information on long running queries. In SQL 2008 you can query dynamic management views to get this information.

Monitor indexes liberally keeping in mind that re-indexing regularly should decrease the need to monitor indexes. Sometimes re-indexing may start taking too long to complete and you will want to be more selective about what to target. Knowing which tables or indices are most fragmented allows you to only re-index them. You can query dynamic management views in SQL Server to get this information (see SQL Server books online). Many 3rd party products offer monitoring of SQL server and you might consider these products if you want a more automated GUI interface to monitoring indexes. Some of the products offer monitoring for other areas of SQL Server as well.

Windows performance monitor or perfmon is useful; you can use perfmon to monitor SQL counters. Here are 3 common counters which, if they reveal something will warrant further scrutiny.

Pages/sec – How much your SQL server is paging in and out of memory
Disk Queues – If the write or read disk queues are too high, you will need more RAM
CPU Queue length – If the CPU queue is consistently over 2 per CPU for an extended period of time, you might have a CPU bottleneck.

Be aware of load and activity when monitoring with perfmon as database backups and other maintenance activities can cause spikes in these numbers. It is best to connect to the server from a different PC if you intend to monitor it with perfmon.

A good maintenance plan will include scheduled re indexing during off hours. Fragmented indices can cause Connect to become sluggish and might even cause fast-fails in a Connect cluster. If you start to see a lot of slow queries in the debug log, you should ensure that the Connect DB is being re-indexed regularly: Index maintenance is one of the easiest ways to keep your DB healthy and SQL Server provides wizards that help make index maintenance easy.

Open SQL Server Management Studio and open the management folder.