Archive for December, 2013

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)

 

Connect on-premise server: Warning messages in Event viewer, registry connection rejected

On some installations of Connect on-premise in combination with FMG you might observe a large number of regular warning messages for the FMS Edge process in the Windows Event viewer as well as the servers edge.log file.

The message in \Connect\logs\support\diagnostic\edge.00.log would look like this:

Connection rejected by server. Reason : [ Server.Reject ] : Registry connection rejected, this adaptor is _defaultRoot_ and the registry only accepts connections on originhost -

In the Event Viewer you would see this in regular intervals:

event_viewer_registryConnectionRejected

 

If you see these in the logs on your Connect server machine and FMG is hosted on the same machine, do the following:

1. Browse to: C:\Connect\9.1.1\Flash Media Gateway\2.0.1.19_8x8\conf\

or if you run 9.0.x browse to:   C:\Connect\Flash Media Gateway\2.0.1.15\conf\

2. Take a backup copy of the rtmp.xml

3. Open the file rtmp.xml in an XML friendly editor like Notepad++ or Textpad.

4. Locate this section at the top:

<Registrations>
<LegService>
<!-- List of FMS & service names for LegService registry connnections                    -->
<!-- Format is <Server host = "Flash Media server IP/hostname">servicename</Server>        -->
<!-- Please refer to documentations for applicable restriction on the values            -->
<Server host = "localhost">telephony</Server>
</LegService>
<ControlService>
<!-- List of FMS & service names for ControlService registry connections    -->
<!-- Format is <Server host = "server IP/hostname">servicename</Server>        -->
<!-- Sample entry:                                                            -->
<Server host = "localhost">telephony_control</Server>
</ControlService>
</Registrations>

5.  In the above section, modify these two lines:

<Server host = “localhost”>telephony</Server>

<Server host = “localhost”>telephony_control</Server>

to include a port number:

<Server host = “localhost:8506“>telephony</Server>

<Server host = “localhost:8506“>telephony_control</Server>

6. Save the changes and restart the FMG service.

 

 

 

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.

 

 

Connect 9.1 on-premise Server – Audio Provider selected by default when creating a new meeting.

With Connect 9.1 when creating a new meeting the option to use an audio profile is preselected if one or more exist under “My Profile” >> “My Audio Profiles”.
This means, if you setup a new meeting it is assumed you also want to use your existing audio profile.

You can read about this change here: What’s new in Adobe Connect 9.1

If you prefer the old behavior and do not want to preselect an audio profile due to various reasons you can change this in the server configuration files.

audio_conference_settings

Please note, this change means you need to modify a file on your server, so please create a backup.

To go back to the behavior of Connect 9.0 and earlier versions follow these steps:

1. Log on to your server machine.
2. Browse to the Connect install directory.
3. Locate the directory \Connect\9.1.1\appserv\apps\meeting\.
4. Take a backup copy of the file “sco_edit.xsl”.
5. Open sco_edit.xsl in an XML friendly text editor such as Notepad++ or Textpad.
6. Go to the end of the file and replace these two lines:


</xsl:template>
</xsl:stylesheet>

with this:

<script>

            document.getElementsByName("inherit-telephony-settings")[0].checked=true;

            noTelephonySettings();

   </script>
</xsl:template>
</xsl:stylesheet>

 

script_view_in_editor

 

7. Save the changes and restart the Adobe Connect Service
8. Verify the changes by setting up a new meeting.

Please note, these changes might be overwritten when you install an upgrade or patch.

 

 

 

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.

Adobe Connect Server Licensing for Disaster Recovery

This question is commonly asked: Does my license for On-Premise Adobe Connect allow me install Adobe Connect servers for disaster recovery purposes?

First let’s define the terms: Disaster Recovery Environment refers to your technical environment designed solely to allow you to respond to an interruption in service due to an event beyond your control that creates an inability on your part to provide critical business functions for a material period of time. That is to say, it refers to a secondary site that would not be utilized in production unless the primary site went offline due to a natural or human-inflicted disaster that is beyond your control. Use of Adobe Connect servers in Disaster Recovery Environments is within the scope of your license and no additional fees are due to Adobe Systems Incorporated. For example, for the architecture depicted here, you would need four Adobe Connect server licenses. 

 

Connect_DR_cluster

 

However, adding one or more Adobe Connect servers to a local cluster is outside the scope of your license, and you will need to purchase additional licenses from Adobe Systems Incorporated to accomplish this.  Additional licenses are needed when adding any Adobe Connect servers that increase scalability in the form of:

  • Availability — What percentage of time is Connect available to geographically distributed users?
  • Reliability — How often does Connect experience problems that affect availability?
  • Performance — How fast does Connect consistently and qualitatively respond to user requests?
  • Concurrency – How many users can a Connect deployment handle concurrently?

Information around cluster expansion is here: Adobe® Connect™ server pools/clusters and hardware-based load-balancing devices with SSL acceleration

If you were to geographically distribute an active Connect cluster by placing Adobe Connect servers into two separate data centers, that would also require additional licensing. Connect servers in a cluster cannot have more than 2-3ms of latency between and among Connect servers.  Generally you would not geographically distribute Adobe Connect servers into different data centers, however, there is a chapter in the aforementioned clustering article on the topic. With that said, the architecture depicted below, is an example of a distributed active Adobe Connect cluster that is is spread between two local data-centers with nominal latency between those data-centers (less than 3ms of latency). All four servers are in production and all are actively hosting meetings and serving on-demand content.  This Connect architecture example depicted in the diagram below requires a four-server Connect cluster license:

 

Cross-DC-CLUSTER