Author Archive: Jim Johnson

Adobe Connect 9.2 Announced

Last week (12/10) Adobe announced Adobe Connect 9.2, which is due in early 2014.  This release will bring several key enhancements to Adobe Connect including a new filmstrip mode for the video pod, a redesigned workflow for new users, and the ability to register and login to events using your social media profiles.

The Connect blog post around the release is live here. 

The Featured Topic on the Connectusers homepage is now set to reflect the 9.2 announcement. Included on connectusers are the following:

Video tutorial on the integration with social profiles

Tutorial on using the new video pod

What’s New with Adobe Connect 9.2  (overview document)

 

Public MP4 is redirecting to login page on Android and iOS devices

Currently as of Adobe Connect (hosted) 9.1.2, there is an issue with accessing public MP4 recordings on Android and iOS devices.  By design, the public content should not present a login screen to the user.  However, users are getting the login page on those devices when they try to access these public MP4 recordings.  The fix for this has been identified and it is slated to be rolled out in the 9.2 upgrade of the Adobe Connect hosted system.  Until then, the following workaround below should be followed.

The ‘workability’ of it depends on how you provide your users with the link to the MP4s.  iOS users in particular, are most likely not getting these links from the web app (Connect Central) but are instead getting them from an email or other portal that is provided to them.  If that is the case (for either iOS or Android), then you would just need to update the URLs (as indicated below) until we release 9.2 and provide a resolution.  Here is the workaround:

  1. Locate the MP4 in the Content Library.
  2. Click to view the ‘Edit Information’ page for the recording.
  3. Click the ‘Download Content’ link.
  4. Under ‘Download output file(s)’ there is a link to download the file. Copy this URL
  5. Paste the URL to a notepad or document.
  6. You will have a URL that looks something like this example: https://myCompany.adobeconnect.com/localmp4/output/Local-z1.mp4?download=Local-z1.mp4
  7. Remove everything after the ‘?’ and your URL will be something like this example: https://myCompany.adobeconnect.com/localmp4/output/Local-z1.mp4
  8. You can provide the modified URL to your users, and the recording will stream without stopping them to ask for permissions, though it will honor any permissions settings you have on content that is not public.

 Again, this issue is resolved in the upcoming 9.2 Adobe Connect release.

Seminar Session Extensions Explained

In Adobe Connect 9.1.1, when you schedule Seminar Sessions, we allow extensions for a certain period of time should you need to go over your allotted (scheduled) session time.  This is handy if you need to wrap up a session that is obviously running a little later than planned.  If there are no other Seminar Sessions scheduled up against your Seminar Session, you can extend a session (depending on when the next session is scheduled to start).  Best case scenario, the maximum extension time for a session is up to 70 total minutes (technically) if there is enough free time on the Seminar Calendar.  But that is ONLY if the conditions are just right.  That maximum (best case scenario) is 2 x 30 minute extensions + a 10 minute shutdown warning countdown.  Here’s the breakdown of how all this works.

Once your scheduled time of your Seminar Session is up, one of two things can happen if you need to go longer:

1) If there is a Seminar Session that is schedule to start in the open time slot on the Seminar Calendar immediately following your session, you will only get prompted for the 10 minute shutdown.  This means that in 10 minutes, your session will terminate because another session was scheduled to begin immediately after your session was scheduled to end.  So basically it’s no real extension other than the 10 minute warning.

10min2

Once the 10 minutes is up, the session ends and all users are disconnected from the session due to the conflict of the other session being active.

2) If there isn’t a Seminar Session that is scheduled to start in the open time slot on the Seminar Calendar immediately following your session, you will get prompted for a 30 minute extension (as shown below). It is automatic.  The prompt is shown to hosts.

extension1

Once that first 30 minute extension is up, Adobe Connect will check the Seminar Calendar again for a session coming up against your active session.  At this point, one of two things will happen (similar to above):

1) If there is no other upcoming session again on the calendar, it will trigger one more 30 minute extension (as shown below):

extension1

2) If there IS a session on the calendar that is going to start, you will get the 10 minute warning instead.  Meaning that your session was able to go just 40 minutes over the end time (first 30 min extension + 10 minute warning).

10min2

If you did get the second 30 minute extension, after the second 30 minute extension is up (so currently having been extended for 60 total minutes passed your initial end time of the session), you will no longer be given another 30 minute extension option and instead, you will be presented with the 10 minute warning (even if there is no other session coming up on the Seminar Calendar). This means that in total, you would have been granted 70 extra minutes of extension before the session ends (30 + 30 + 10), should the conditions have been just right on the Seminar Calendar.

10 minute

 

Adobe Connect 9.1.2 Licensed (On Prem) Updates Now Available

We have released the 9.1.2 Licensed updates for Adobe Connect.  They can be downloaded directly from:

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

Along with the 9.1.2 update are two additional patches:  9.1.2a and 9.1.2b.

9.1.2a and 9.1.2b should be put on top of 9.1.2 immediately after updating your system to 9.1.2.

9.1.2 needs to be put on top of a system running 9.1 (9.1.1).  Then, once 9.1.2 is applied, proceed with 9.1.2a and 9.1.2b in that order.

9.1.2a resolves the issue in bug: 3670250 –  Which is an issue creating meetings when a user’s profile is something other than German, English, Japanese, Korean, Portugese or Chinese.

9.1.2b resolves the issue in bug: 3653594 - Which is an issue with non-required fields being inadvertently required when creating new users.

 

 

Using the XML API with Enhanced Security

With the release of Adobe Connect 9.0.4 and beyond (view KB here), we have introduced the Enhanced Security feature (documentation) and it is ON by default on our hosted system.  If you are an Adobe Connect Hosted customer, you can toggle the Enhanced Security feature on or off (if you are an Administrator) by logging into your Adobe Connect Hosted account and navigating to: Administration > More Settings.  You will see the following Security Settings:

es

 

If you have ‘Enable Enhanced Security’ checked (and you save the settings), your account will now issue TWO session cookies to a user when they authenticate.  This is crucial to understand and plan for if you are using the XML API to integrate with another system.  Also, if you are a partner or developer who has built an application that integrates with Adobe Connect, you will need to rework your application to account for the possibility of this feature being ON or OFF.

From my experience, it is best to simply code the application to look for the second session cookie all the time (after initially authenticating the user) rather than try to check for the feature being on or off.

Typically in Adobe Connect Hosted accounts before this feature was implemented (and with this setting OFF), your application would first make a ‘common-info’ call as below, to obtain a session cookie before logging a user in:

https://myaccountURL/api/xml?action=common-info

<results>
<status code=”ok”/>
<common locale=”en” time-zone-id=”35″ time-zone-java-id=”US/Eastern”>
<cookie>naXbreezecookie123456789</cookie>
<date>2013-12-02T19:50:38.983-05:00</date>
<host>https://myaccountURL</host>
<local-host>connecthost01</local-host>
<admin-host>naXcps.adobeconnect.com</admin-host>
<url>/api/xml?action=common-info</url>
<version>9.1.2</version>
<tos-version>7.5</tos-version>
<product-notification>true</product-notification>
<account account-id=”12345678″/>
<user user-id=”45678901″ type=”user”>
<name>Jim Johnson</name>
<login>Jim</login>
</user>
<user-agent>
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36
</user-agent>
<mobile-app-package>air.com.adobe.connectpro</mobile-app-package>
</common>
<reg-user>
<is-reg-user>false</is-reg-user>
</reg-user>
</results>

Then you would log the user in:

https://myaccountURL/api/xml?action=login&login=Jim&password=XXXXXXX&session=naXbreezecookie123456789

<results>
<status code=”ok”/>
</results>

That would normally be it.

Then, all subsequent calls, you would normally just append that same session cookie as the ‘session’ parameter and you’d be all set.  However, with Enhanced Security ON, that session cookie you obtained from the first common-info call will NOT work in calls after the login call authenticates the user.  Once the login API is called, you MUST call common-info one more time immediately after the OK response comes back from the login call.  When you run common-info again, you will notice you will get a DIFFERENT session cookie value.  That second cookie value is the session you need to include in your subsequent calls going forward.  If you do not use that second value in your API call, and instead include the value from the first common-info call result, you will get the following error response:

<results>
<status code=”no-access” subcode=”no-login“/>
</results>

So in summary:

Before Enhanced Security the workflow was:

1) common-info API to get cookie session value
2) login API using the cookie session value
3) continue on making API calls with that same session cookie throughout the user session

After Enhanced Security (post 9.0.4):

1) common-info API to get cookie session value
2) login API using the cookie session value
3) common-info API again a second time to get the final cookie session value to use going forward in all other calls
4) continue on making API calls with that NEW session cookie throughout the user session

Again, it is best to code your application to always look for a session cookie again AFTER logging a user in.  That way, even if you are still using the same session (say if the account had Enhanced Security set to OFF), your application will still work fine and in the cases where the account does have Enhanced Security turned ON, it will still continue to work as expected.

Stunnel Support with Adobe Connect 9.x

Up until Adobe Connect 9.0.0.1 (full installer) for on-premise (licensed) deployments, Adobe packaged Stunnel with the Connect application to handle the software SSL.  With the release of 9.0.0.1 of Adobe Connect, we included Stunnel 4.53 but do not unpack and install it with the installer (as we previously had done with Connect 8.x).  If you install (or are running) 9.0.0.1 and are looking for the Stunnel package, you need to navigate into the unpacked Adobe Connect 9.0.0.1 installer folder ({unpacked folder}\Adobe Connect 9.0.0.1\Adobe Connect\Merge_Modules) and look for the stunnel-4.53.zip file.  From there, you can install Stunnel 4.53 for your SSL deployment.

With the release of Adobe Connect 9.1.1, we no longer even ship the Connect installer with the Stunnel bits.  So you will need to obtain the Stunnel installer from either Stunnel’s website or from a 9.0.0.1 installer of Adobe Connect.  The last shipped version of Stunnel (with Connect 9.0.0.1) was 4.53, but again it was not ‘unpacked and installed’ as of 9.0.0.1.

The latest build of Stunnel that Adobe QE has tested with is version 4.56, which at the time of this article, is the latest production Stunnel build.

 

 

 

Adobe Connect Meeting Add-in for 9.1.2 is Now Available

The new Adobe Connect Meeting Add-in is now available.  This latest version of Adobe Connect Add-in is 11.2.392.0 for both Windows and Mac platforms.  Please see the following knowledge base article below for the latest information including the list of issues that have been fixed in this release as well as the links to download both the Windows and Mac versions of the Add-in.

http://helpx.adobe.com/adobe-connect/kb/latest-connect-91-addin.html

Pulling Applicable Logs for Telephony / UV Issues

Typically when on-premise Adobe Connect customers experience telephony issues or UV related issues in their Adobe Connect Meeting rooms, Adobe Support will request specific logs from the customer’s environment.  These logs may come from different places depending on your Connect deployment.  Below is a good guide to understand how to grab just the applicable logs that Connect Support will need.

Typically, for telephony or UV issues these logs will be:

  • application.log
  • core.log (for FMG/UV if applicable)
  • SipLog (for FMG/UV if applicable)
  • TelephonyService.log

and any of the following (‘adaptor logs’ as I’ll refer to it as in this article), depending on the Telephony Integration/Provider you are using:

  • Arkadin_Adaptor.log
  • Avaya_Adaptor.log
  • Intercall_Adaptor.log
  • MeetingOne_Adaptor.log
  • MeetingPlace_Adaptor.log
  • Premiere_Adaptor.log
  • Premiere_EMEA_Adaptor.log

One thing to understand is that if you have a ‘cluster’ of Adobe Connect origin servers, your telephony services for the meeting in question may or may not open on the same server as the meeting itself.  So you could have a meeting running on one node in the cluster, while the actual telephony services are running on another.  Also, if you are running an FMG server (for UV), the FMG services may or may not be on the same server that is running the actual meeting.

Here’s how to collect the applicable logs to submit to Adobe Support if they request the ‘telephony’ logs for a meeting:

For Adobe Connect 9.x:

Application.log (also sometimes referred to as the ‘Meeting log’)

This is the log that contains all the logging for the meeting itself.  It will contain the telephony service connection in which you can identify what server the telephony services actually connected on.  It will also tell you  (if applicable) what server the FMG connection happened on.  This log will also show all the user activity in the meeting (including phone numbers, etc.). This is very crucial for Adobe to obtain when troubleshooting an audio issue in an Adobe Connect Meeting.

It is located in: [Root Connect Install Directory]\logs\support\apps\_defaultVHost_\meetingas3app\7\{sco-id} where ‘sco-id’ is the actual numeric value of the Meeting room’s sco-id.

To find the sco-id of the meeting room, you can log into Adobe Connect’s web manager and navigate to the Meeting Information page in the UI.  The URL of that page will look something like this:

http://myConnectURL/admin/meeting/sco/info?account-id=7&principal-id=11033&sco-id=11115&tab-id=11003

(where the values for principal-id, sco-id-, tab-id are obviously just example values for the sake of this article)

The ‘sco-id‘ from that URL will be the name of the folder you are looking for in the above directory for finding the application.log.

Note: If you have a cluster for Adobe Connect that contains multiple servers, you may have to search every server in the cluster for this file.  You may also notice that if the meeting room in question is used over and over, it will open eventually on all the servers in the cluster, so you may in fact have the sco-id folder present on more than one (or all) of the servers, but the actual application.log for the session you are looking for will only be on one server.  Each session will get it’s own Application.log.  So you will see multiple (eventually) versions of the application.log in this folder over time.  You need to look at the timestamp of the logs to make sure you are getting the right one for the day/time the session in question occurred.  Once you identify the right application.log for the meeting session in question, you need to open it up and look for the following logging looking similar to this:

(you can search the log for the values in red):

2013-11-19	10:21:32	94648	(s)2641173	get-telephony-service API result obtained.	-
2013-11-19	10:21:32	94648	(s)2641173	get-telephony-service API successful	-
2013-11-19	10:21:32	94648	(s)2641173	  .get-telephony-service result object:  [Object]	-
2013-11-19	10:21:32	94648	(s)2641173	    \\	-
2013-11-19	10:21:32	94648	(s)2641173	    .host [Object]	-
2013-11-19	10:21:32	94648	(s)2641173	        \\	-
2013-11-19	10:21:32	94648	(s)2641173	        .external-name [string]= connect01.mycompany.com	-
2013-11-19	10:21:32	94648	(s)2641173	        .ip [string]= 10.11.123.44	-
2013-11-19	10:21:32	94648	(s)2641173	        .name [string]= connecthost01	-
2013-11-19	10:21:32	94648	(s)2641173	        .service-host-id [string]= 15647477	-
2013-11-19	10:21:32	94648	(s)2641173	    .subcode [undefined]	-
2013-11-19	10:21:32	94648	(s)2641173	    .code [string]= ok	-
2013-11-19	10:21:32	94648	(s)2641173	hostName: connecthost01, hostIp: 10.11.123.44	-

where the hostName will be the server in which the telephony services opened on.  The logging snippet will contain that hostName and the hostIP as well as the external name (FQDN) of that meeting server.  The above examples in BLUE are just merely generic values for the sake of this article.

** IF applicable (if you are using UV), also look for the following (you can search the log for the values in red):

 

2013-11-19	10:21:44	94648	(s)2641173	FMGServiceConnector.asc:: get-fmg-service API onResult obtained	-
2013-11-19	10:21:44	94648	(s)2641173	FMGServiceConnector.asc:: get-fmg-service API successful	-
2013-11-19	10:21:44	94648	(s)2641173	FMGServiceConnector.asc:: fmgHostName=fmghost02, fmgHostIp=10.11.123.456	-
2013-11-19	10:21:44	94648	(s)2641173	FMGServiceConnector.asc:: FMG client has already connected, connected ip= 10.11.123.456	-
2013-11-19	10:21:44	94648	(s)2641173	FMGServiceConnector.asc:: Setting connected fmg ip:10.11.123.456	-
2013-11-19	10:21:44	94648	(s)2641173	FMGServiceConnector.asc:: fmgHostName saved = fmghost02	-

where the fmgHostName and fmg ip address will be visible.  The above examples in BLUE are just merely generic values for the sake of this article.

 

Once you identify the server the Telephony Services opened on (and if applicable, UV), move on to getting those logs…

TelephonyService.log

This is the log that contains all the logging for the Adobe Connect Telephony Services.

It is located in: [Root Connect Install Directory]\Breeze\logs\telephony

Note: If you have a cluster for Adobe Connect that contains multiple servers, refer to the info above on making sure you know what server to pull this log from.

{XXXXX}_Adaptor.log

This is the log (depending on your telephony provider) that includes all the logging for the communication between Adobe Connect and the telephony provider’s bridge.  It will contain the communication back and forth and the messages sent to and from the telephony provider using that provider’s API, as well as applicable responses. The ‘XXXXX’ value in the name will obviously be the name of the provider (e.g. Arkadin, PGI, Intercall, etc.).

It is located in: [Root Connect Install Directory]\Breeze\logs\telephony

Note: If you have a cluster for Adobe Connect that contains multiple servers, refer to the info above on making sure you know what server to pull this log from.  It will be the same server that the TelephonyServices.log will come from.

Of course in some circumstances, Adobe Support will also need to work with the telephony provider to obtain logging from their side, should the Adobe Connect logs not yield enough data to continue with the investigation.

core.log 

This is one of two applicable FMG related logs.  If you are using UV, this will be necessary to obtain for support to review the FMG logging.

It is located in: [Root Connect Install Directory]\Flash Media Gateway\{FMG version}\log

Note: If you have a cluster for Adobe Connect that contains multiple servers, refer to the info above on making sure you know what server to pull this log from.

SipLog (this will be date/timestamped in the actual name of the log)

This will be the log that will contain the communication between FMG and the SIP server/service.  If you are using UV, this will be necessary to obtain for support to review the FMG logging.

It is located in: [Root Connect Install Directory]\Flash Media Gateway\{FMG version}\log

Note: If you have a cluster for Adobe Connect that contains multiple servers, refer to the info above on making sure you know what server to pull this log from.

 

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.

Event Module Tutorial Collection

The below is a great collection of Event Module tutorials by both Adobe and our some of our partners.  These cover everything from administration, creation, migration, reporting, best practices, and API integration.

 

Creating an Event in Adobe Connect 9
by video2brain
In this tutorial, you’ll see how to create a new event in Adobe Connect 9 and add it to the Event Catalog

Creating and Editing Event Templates
by Alistair Lee
In this video tutorial, Alistair Lee shows you how to create, edit and manage event templates – new to Adobe Connect 9.

Event Administration in Adobe Connect 9
by Alistair Lee
In this video tutorial, Alistair Lee walks through the new features available to Event Administrators in Adobe Connect 9

Adobe Connect 9: Event Migration Guide
by Alistair Lee, Adobe Systems
This tutorial features a 23-page PDF guide on Adobe Connect 9 events. It highlights the new features introduced in version 9 of Adobe Connect and discusses the impact on events that have migrated.

Creating a Two Person Event Template with Adobe Connect
by Alistair Lee, Adobe Systems
In this tutorial, you’ll see how to quickly create a new event template that features two or more speakers.

Adobe Connect Events Overview
by Alistair Lee, Adobe Systems
In this video, Alistair Lee walks through an overview of the new Adobe Connect Events module.

Adobe Connect best practices for large events and seminars
by Rocky Mitarai, Adobe Systems
This checklist is an invaluable resource for any producers of large webinars and events on Adobe Connect.

Resetting the Default Event Templates in Adobe Connect
by Alistair Lee, Adobe Systems
This tutorial walks through the steps required to reset a default template.

Campaign Tracking in Adobe Connect 9.1
by Alistair Lee, Adobe Systems
In this video tutorial, Alistair walks through some of the new features in Adobe Connect 9.1 that make measuring campaigns and optimizing your promotional channels more intuitive.

Event Registration using Adobe Connect API’s
by Dustin Tauer, Easel Solutions
In this tutorial, Dustin covers how to use the Adobe Connect API’s to register a user for an event.