Posts in Category "Database"

Changing the License Serial Key in Connect

This article applies to on-premise and managed ISP Connect users. It does not apply to multi-tenancy hosted or ACMS.

On rare occasions it may be necessary to change the serial key in Adobe Connect. Here are the steps:

  1. Navigate to: \Connect_installation_directory\appserv\conf\config.ini and change the value of  SERIAL_KEY=  to reflect the new serial number
  2. In \Connect_installation_directory\custom.ini,  if there’s a serial key value listed (SERIAL_KEY=), replace it there as well.
  3. Using MSSQL Studio Express (or your choice of SQL editing options), view the serial key currently being used by Connect by running this command: SELECT * from pps_accounts WHERE name=’Enterprise Account’
  4. To get Connect to accept the new license you must change the serial key that is currently in the database by running this SQL command: UPDATE pps_accounts SET serial_key = ‘NEW_SERIAL_NUMBER’ WHERE serial_key = ‘OLD_SERIAL_NUMBER’
  5. Restart the services: Application Server (Connect) and the Meeting Server (AMS or FMS depending on the version of Connect) services.fw
  6. Open the Administration Console (port 8510 locally on any Connect server)

connconfig.fw

7. Go to License Settings and upload the new license file.

connconfiglic.fw

8. Restart the AppServer (Connect) and the Meeting server (AMS or FMS depending on version) again and the  new license file will be applied

services.fw

Troubleshooting: If there are any problems, do the following to troubleshoot:

  • Shut down the Connect and AMS or FMS Services
  • Open and verify \Connect_installation_directory\appserv\conf\config.ini and update the entry for SERIAL_KEY
  • Open and verify  \Connect_installation_directory\custom.ini and update  the entry for SERIAL_KEY
  • Open SQL Server and choose the Connect database and run the following script (replacing the text as appropriate):

“Input New Serial Key Here” with the New Serial Key but leaving the quotes.
DECLARE @NEW_SERIAL VARCHAR(32)
SET @NEW_SERIAL=’Input New Serial Key Here’

UPDATE PPS_CONFIG
SET VALUE = @NEW_SERIAL
WHERE SECTION=’cps’ AND NAME=’serial_key’

UPDATE PPS_ACCOUNTS
SET SERIAL_KEY = @NEW_SERIAL
WHERE ACCOUNT_ID=7

UPDATE PPS_ENUM_DATA_HOSTS
SET LICENSE = @NEW_SERIAL
WHERE HOST_ID > 0

db.fw_

  • Start the Connect and FMS services

Problems will ensue when the license is reducing the allowed usage of Connect (if you are downsizing) and you leave an overage in place. For example, if you have 100 meeting hosts assigned, and you are changing to a license that only allows 50 named meeting hosts then when you  apply the license you will get an error unless you have reduced the number to accommodate the new licensed restriction.

On-premise Connect without Webinars Throws an Error when Moving Meetings

On-premise Connect customers running version 9.5 who do not have the Webinar option enabled will see an error when trying to move meetings via the GUI in Connect Central:

Webinar95Bugon-prem.fw

This will be fixed in an upcoming release and in the meantime we have two workaround options:

Adobe Connect ID’s are changing from INT to BIGINT

UPDATE: THIS ARTICLE IS FOR XML API DEVELOPERS ONLY.  If you are not using the XML API with Adobe Connect to write your own custom built applications that integrate with Adobe Connect, please do not worry about the message below as it will not apply to you.


Due to the growing popularity of Adobe Connect, more and more customers rely on Adobe Connect for their collaboration needs and this naturally requires that we make adjustments to accommodate the growth.  We want to make you aware of an upcoming adjustment to the ID values in Adobe Connect databases to support longer values which will accommodate growing customer use of Adobe Connect.

What is being changed?

Starting with release 9.5.2, Adobe Connect will migrate the ID values in Connect databases from INT to BIGINT/Long.

What is the impact?

This change will impact any applications using Adobe Connect Web Service APIs.

How will Adobe Connect Web Service APIs be affected?

The change is for those APIs which consume/return id values i.e. which have a parameter in request/response which is an Id. (examples: sco-id, account-id, folder-id, etc).  The id fields in such APIs would return/accept larger values. The support and behavior of existing APIs remains same.

What does this mean for you?

In case you are interpreting ids as integers the new values might overflow. We strongly recommend using strings to represent id values. In case you still need to represent/store ids as a numeral please use integral data type with higher capacity. (Preferably 64 bit)

What is the timing?

We expect to release Connect 9.5.2 in the first quarter of 2016, so the change should be made as soon as possible in order to be ready prior to the release.

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.

Configuring Secure SQL with Connect

It may be prudent to secure the connection between the Adobe Connect application servers and the SQL database.

Begin with the SQL server and then move onto the Connect server(s); if your SQL server is shared then begin with a change request to the DBA who has charge over the shared SQL environment. If your SQL database is already secure, you may skip Part I.

Part I. Securing the MS SQL Database Server:

First open the Certificates snap-in:

1. Open the MMC console, click Start, and then click Run; In the Run dialog box type:  MMC
2. From the  File menu, click Add/Remove Snap-in….
3. Click Add, and then click Certificates. Click Add again.
4. You are prompted to open the snap-in for the current user account, the service account or for the computer account. Select the Computer Account.
5. Select Local Computer, and then click Finish.
6. Click Close in the Add Standalone Snap-in dialog box.
7. Click OK in the Add/Remove Snap-in dialog box. Your installed certificates are located in the Certificates folder in the Personal container.

Use the MMC snap-in to install the certificate on the server:

  1. Click to select the Personal folder in the left-hand pane.
  2. Right-click in the right-hand pane, point to All Tasks, and then click Request New Certificate….
  3. The Certificate Request Wizard dialog box opens. Click Next. Select Certificate type is “computer”.
  4. In the Friendly Name text box you can type a friendly name for the certificate or leave the text box blank, and then complete the wizard. After the wizard finishes, you will see the certificate in the folder with the fully qualified computer domain name.

You are done now with installation of certificate on the SQL server, next you will need to export the certificate so that the same can be imported in the Connect application server.

  1. Open MMC, and then locate your certificate in the Personal folder.
  2. Right-click the certificate name, and then click Open.
  3. Review the Certification Path tab. Note the top most item.
  4. Navigate to the Trusted Root Certification Authorities folder, and then locate the Certificate Authority noted in step 3..
  5. Right-click CA, point to All Tasks, and then click Export.
  6. Select all the defaults, and then save the exported file to a location where the Connect application server can gain access to it.

Configure SSL encryption in the MS SQL instance:

1. On the SQL server start menu open Microsoft SQL Server>Configuration Tools> SQL Server Configuration Manager:

SQLsecure1.fw

2. Expand SQL Server Network Configuration, then right-click Protocols for MSSQLSERVER, and choose Properties. Select the Flags tab and change the Force Encryption setting to Yes.

sqlserverencryptionstep2

3. Under the Certificate tab, choose the certificate created earlier from the drop down list:

SQLsecure4

The database is now ready for secure connection with the Connect application server.

Part II. Configure the Connect application server to support a secure SQL connection:

Importing the certificate onto the Connect application server

  1. Copy the certificate from MS SQL Database server to the Connect application server(s) or to an accessible share.
  2. Navigate the Connect application sever by using the MMC snap-in, and then browse to the Trusted Root Certification Authorities folder.
  3. Right-click the Trusted Root Certification Authorities folder, point to All Tasks, and then click Import.
  4. Browse, and then select the certificate (.cer file) that you copied in step 1. Select the defaults to complete the remaining part of the wizard.

Create a Trust Store

1.  Be sure to have java installed on your Connect application server; at the command prompt, navigate to the bin directory of your JRE, and execute the following command:

keytool -import -file  <certificate file path> -alias firstCA -keystore <any name for trust store>
Note: This step will queue for a password, create and record a password for future reference.

2. In the ConnectProSvc.conf in the appserv\conf directory, add the following entries in the list of JAVA arguments:

wrapper.java.additional.28=-Djavax.net.ssl.trustStore= <path of Trust Store file created in step 1>
wrapper.java.additional.29=-Djavax.net.ssl.trustStorePassword=<password you created in step 1>

Configure the secure connection in Connect:

1. In custom.ini file under the root Connect installation directory, add the following entries:

DB_ENCRYPTION_METHOD=SSL
DB_VALIDATE_SERVER_CERTIFICATE=true

2. Cycle the services or reboot the server:

Adobe Connect Service
Flash Media Service

Note: For secure LDAP or LDAPS with Connect and for additional granularity around the paths and keystore see the following tech-note: Configure Connect Directory Services to use LDAPS

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.

Deleting Corrupted Ghost Meetings on Adobe Connect On-premise Servers

Deleting Corrupted Ghost Meetings on Adobe Connect On-premise Servers

Perhaps due to network outages or hardware failures, etc., there are rare occasions when the Adobe Connect database may become disconnected from the Adobe Connect server while active Meeting sessions are ongoing. It is prudent to avoid database outages while Connect is in use and to publish maintenance schedules so that Meetings are not in session when the database is taken offline for administrative reasons. In most cases when the database is disconnected, once it is reconnected, Connect will be fine and all Meetings will be functional upon full recovery of all systems. In the rare instance, that a Meeting is corrupted through a database outage and cannot be deleted through the Connect Central GUI, you may need to manually delete the Meeting room from the content library directory structure and possibly also from the database itself. If you see displayed at the corrupted Meeting URL, a gray window without any menu or pods, or if you see the following error when you hit a corrupt Meeting URL, you may need to manually delete the Meeting:

Request Not Processes” – “For further assistance, please refer to the Adobe Connect support center or contact Adobe Connect support

If the Meeting cannot be deleted through the Connect Central GUI, delete the content folder for the corrupted Meeting. You can identify it by its sco ID in the Connect\content directory:

content.fw

Restart the Connect and FMS services. If that fails to remove remnants of the corrupt Meeting from the database, try recreating the folder mentioned, (even with empty content), then attempt to delete the room again. If that fails, you may need to delete the Meeting references from the database manually:

sco: update pps_scos set disabled = getUTCdate() where SCO_ID=XXXXX

Note: XXXXX represents the actual sco ID of the meeting.

XML API Tips: Internal-error When Executing Reporting Calls

Periodically when executing a reporting API call, you may get an unexpected return as shown below:

<results>
<status code=”internal-error”>
<exception>java.sql.SQLNonTransientConnectionException: [Macromedia][SQLServer JDBC Driver][SQLServer]Cannot open database “XXXXXXXXX” requested by the login. The login failed.</exception>

</status>
</results>

Where the ‘XXXXXXXXX’ would be the database name of the database your request was trying to hit.

This is expected if you are making one of the ‘reporting database API calls‘ during the exact time that the db is locked for a small restore.  As previously discussed, the reporting database is not real-time. It is synched occasionally and can be behind by as much as 24 hours.   That error (you would see it in the logs and in your response) is thrown when the DB is being restored.  When the db is being restored, the DB is locked down and the result will be a failed login (internal-error).  The reporting DB is log shipped every 15 minutes.  So every 15 minutes there will be a small restore.  All you’re application needs to do is retry when you get that message.  It could be as much as a minute of downtime, but most of the time is less.

 

XML API Tips: Reporting API Calls and the Reporting Database

One common question from API developers revolves around the existence of our reporting database vs our production database on Adobe’s Hosted platform.  There are a few API calls that will hit the reporting database rather than production, to retrieve information.  This is by design and is to prevent some of the more expensive APIs from being run on a multi-tenant environment’s production database.  The current calls that are redirected to our reporting database and not to our production (real-time) database are:

/api/xml?action=report-bulk-consolidated-transactions
/api/xml?action=report-bulk-objects
/api/xml?action=report-bulk-questions
/api/xml?action=report-bulk-users
/api/xml?action=report-bulk-slide-views

As you can see, these are all the ‘bulk’ API calls.  There is one additional call that is currently (as of Adobe Connect 9.2.2) being directed to the reporting database rather than production, and that is:

/api/xml?action=report-quiz-results

This action will be shifted to the production database in the next major release of Adobe Connect.

The reason this is important is that the reporting database is not real-time like production.  It is delayed, sometimes up to 24 hours.  So it is recommended that if you need to have real-time information in your application, you avoid making the calls above and use other APIs to retrieve the desired data.

DB_PING_TIMEOUT Value Change

Recently we have discovered that a newer setting for on-premise (licensed) Adobe Connect servers may lead to a memory leak on the system in certain rare circumstances.  Here is some history and recommendations in case you believe you may be running into a memory leak problem in your Adobe Connect licensed environment and you are running a version newer than 9.0.3.

The DB_PING_TIMEOUT value was introduced back in Connect 7 (2008 timeframe).  It enables invalidated DB connections to be recognized quickly. In the absence of a reasonable value for this timeout, we have had instances in the past where critical CPS threads (e.g. the scheduler sweeper thread) have waited on a stale DB connection for too long, causing fastfails. This value had since always been set to ‘0’ which means there is no time out.  Since the default host health check time out value is 40 seconds, it is recommended that the DB_PING_TIMEOUT default value be set to 30 seconds, so that it is under the limit that causes potential server fast-fails. This was a fairly minor change in the config.ini, where the DB_PING_TIMEOUT value was changed from 0 to 30.  This was done at the Connect 9.0.3 version.  So every version above 9.0.3 will have the default set to 30.  [Important note – this value is in seconds, not milliseconds]

Recent longevity tests in version 9.2 suggested that this might be triggering a memory leak in the driver. The going theory for why that behavior wasn’t seen in previous longevity tests (between 9.0.3 and 9.2) is that we only upgraded to JRE 7 in 9.2. So the setting we were running with previously suddenly seemed to be a problem once we also upgraded to 1.7.

That value of 30 was introduced for a reason, so we don’t suggest turning it off without knowing that it causes a problem. On the Adobe hosted clusters, we have made the decision to do so since there were signs of memory issues even previously and we didn’t want to compound that.

That said, there are known issues with our driver and JRE 1.7, but only under some circumstances. In the case of Adobe Connect system administrators observing  (continuous) increases in heap memory usage, this parameter value should be set back to 0.

This can be done by changing this value either in the config.ini  from 30 to 0 (DB_PING_TIMEOUT=0)  or by adding this value in the custom.ini (it won’t be there by default, but if you add it, it will take precedence over what is in the config.ini)