Posts in Category "Application"

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

 

Adding the Passcode Feature for Connect Meetings

You may add a passcode feature as an additional security option for Connect Meeting room access in Connect versions 8 and 9. Each Meeting room can have its own passcode.  The parameter will appear under the Edit Information tab of the Connect Meeting:

pc2.fw

This is a great option. For example, it allows you to pop up a fast ad hoc meeting with full guest access while requiring guests to apply a pass-code to enter:

pc.fw

It also allows an additional layer of security for registered users as well; they also would need to enter a passcode in addition to any permissions (even host-level) granted to the room.

pc1.fw

Once applied, when a users hits the Meeting URL they will be presented with the passcode field:

pc3.fw

To add this feature, simple log onto your on-premise adobe Connect server as a Connect Administrator and enter the following into the URL line in Connect Central:

http://YOURDOMAINNAME/api/xml?action=meeting-feature-update&account-id=7&feature-id=fid-meeting-passcode-notallowed&enable=false

Where “YOURDOMAINNAME” is actually your domain name.

If this executes correctly, you will see the following output when you follow-up by entering this command into the same URL line in Connect Central:

http://YOURDOMAINNAME/api/xml?action=meeting-feature-info&account-id=7

Output: feature-id=fid-meeting-passcode-notallowed

Alternatively you could simply check and see if the feature is available under the Edit Information tab of any Meeting.

Note: Your Meeting passcode can be up to 16 letters or numbers; keep in mind that it is a convenient supplementary security mechanism rather than a primary means. You will see this warning if your passcode is not supported go over that: Your passcode must be between 1 and 16 characters long (letters or numbers, no spaces).

In adding this feature you have invoked the Web Services API in Connect. If you are not familiar with the API see the following document; it is rich with options: http://help.adobe.com/en_US/connect/9.0/webservices/connect_9_webservices.pdf

Note also that with Connect 9.2, in Connect Central under Administration > Users and Groups > Edit Login and Password Policies, there are two relevant check boxes, one to enable and the other one to force the use of the passcode:

passcode.fw

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.

 

 

 

Vantage Point is not just about Bandwidth

Vantage Point from Refined Data works with Connect and provides remote control of Cameras, Microphones, Telephones, Volumes, Tech Support, Motion Detection, Mouse Detection, Continuous attendance tracking and reporting and much more so it’s not just about bandwidth reduction.

On the bandwidth front, Vantage Point publishes streams to Refined Data servers at 100Kbps for each participant in the room; this is less than Connect in most cases, but the Host only consumes as many streams as they can view at one time. The host can see as few as 5 or 6 students at one time or as many as 50 or more depending on their screen resolution, window size, Vantage Point settings, connectivity and bandwidth availability.

This means that even with 100 Participants in a Connect room and one Host the bandwidth consumption looks like this:

  • Participant Load: 100kbps Up (to publish their own camera to Vantage Point), 100kbps down (to view the Host in Connect). This is a small signature on the network.
  • Host Load: 100kbps Up (to publish their own camera in Connect), 2.5mbps down (assuming they view 25 participant cameras in Vantage Point at one time). The Host is the only one who needs a really good connection.
  • Total Load on Adobe Connect: 1 publish stream + 99 subscribers

The host can always reduce their own load simply by viewing fewer simultaneous Video pods in Vantage Point. The bandwidth load for students or participants is not affected at all by class size. Bandwidth load for Hosts rises linearly with class size but can be limited by the host at any time based on the maximum number of cameras they view at one time.

In Connect, the bandwidth load rises with the number of cameras being shared:

  • 4 Cameras: 16 Connections on the Server, each user publishes 100kbps and consumes 300kbps
  • 10 Cameras: 100 Connections on the Server, each user publishes 100kbps and consumes 900kbps
  • 20 Cameras: 400 Connections on the Server, each user publishes 100kbps and consumes 1.9mbps

Even if Connect could technically support 50 or 100 simultaneous web cams in a single meeting (2,500 streams risks significant latency), consider the requirement that participants would need 5-10mbps of bandwidth to support the load, before accounting for VoIP, screen-sharing and basic overhead. Anything above 10 simultaneous web cameras may be difficult for a host to manage and apart from any other considerations, there may not be enough real-estate for content if you are showing 10 or more web cams in the meeting room.

Vantage Point only publishes at 100kbps, most of the time; DSL and Standard quality is already more than twice this load in Connect and can easily rise higher if the room is set to use the Highest video quality at 16:9. With Vantage Point, Adobe Connect saves the server load, participants are not affected by class size, Hosts can see all of their students, all of the time and enjoy unparalleled control of the classroom environment.

Check it out at Refined Data: http://vantagepoint.refineddata.com/

Troubleshooting Caption Colorado Domain Names in Meeting Pod

Issue: Sometimes the Closed Captioning pod fails to connect to Caption Colorado.

Symptom looks like this:

CC.fw

Always make certain you have the correct pod version: http://www.adobe.com/products/adobeconnect/feature-details/closed-captioning.html

There are two names available at Caption Colorado, one is a legacy name for Breeze and the other is for Connect. Both point to the same TCPIP address:

C:\flyfishing\frank>nslookup connect.captioncolorado.com
Server:  dns.adobe.com
Address:  xx.xx.xx.xx
Non-authoritative answer:
Name:    connect.captioncolorado.com
Address:  216.241.103.7
C:\flyfishing\frank>nslookup breeze.captioncolorado.com
Server:  dns.adobe.com
Address:  xx.xx.xx.xx
Non-authoritative answer:
Name:    breeze.captioncolorado.com
Address:  216.241.103.7

Workaround: When either of these domain names (Breeze or Connect) fails to connect, use the other. This is a known issue at Caption Colorado and they are working to resolve it. Simply juxtaposing connect.captioncolorado.com for breeze.captioncolorado.com or visa versa in the pod configuration will solve the connection issue and facilitate closed-captioning.

Meeting Add-in | Mac OS X Mavericks 10.9, 10.8, 10.7 with Safari 6.1 or 7

In case you have not seen, we have published a brief article on the issues with using the Adobe Connect Meeting Add-in with Mac OSX Mavericks and newer versions of  the Safari browser.

Details and instructions (in an additional linked article) on how to suppress the restrictions put in place by the newer browsers can be found here:

http://helpx.adobe.com/adobe-connect/kb/connect-add-in-osx-mavericks-109.html

Connect on VMWare – some deployment tips

Issue: VMWare is ubiquitous in the enterprise and while it opens up huge potential for management of the Connect infrastructure, it must be planned and executed with an eye toward robustness.

This advice is gleaned from conversations with senior persons on our operations team as well as from support cases generated by various customers with on-premise VMWare deployments of Connect.

One of the most important and often overlooked variables about virtualization is to make certain that  VMware is compatible with all the underlying components of the server and network architecture. The infrastructure supporting VMWare must be verified by VMware under their Hardware Certification Program or Partner Verified and Supported Products (PSVP) program; be sure to use certified hardware.

Here is the link to the compatibility reference:  http://www.vmware.com/resources/compatibility

With Connect you must consider both Tomcat and  FMS; the former can run on most anything, while the latter is a bit more demanding; RTMP can be acutely;y affected by latency and packet transmissions. If you notice unpredicted latency or a surprise crash of FMS with Connect 9.1, a good test would be to check the network components; sniff for packet transmission issues – have the vNIC of the guest VMs configured to use VMXNET3; this is a good place to start.

With reference to recommendations and best practices, it really depends on the VMware infrastructure adopted. The following references serve as a guide for an enhanced environment:

Enterprise Java Applications on VMware – Best Practices Guide: http://www.vmware.com/resources/techresources/1087

Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs: https://www.vmware.com/resources/techresources/10220

Performance Best Practices for VMware vSphere 5.1: https://www.vmware.com/resources/techresources/10329

The key with Network Storage is speed. If you lose connectivity to the shared storage then only what is cached on the origins will be available.

Shared storage requirements

  • Disk specs: 10,000–15,000 RPM — Fibre Channel preferred
  • Network link: TCP/IP — 1GB I/O throughput or better
  • Controller: Dual controllers with Active/Active multipatch capability
  • Protocol: CIFS or equivalent

Avoid, virtualizing the Connect database if possible.

I have seen that in some customer-based VMWare environments that are overtaxed, that latency among the servers on 8507 (and 8506), can cause problems. Intra-cluster latency (server to server communication) should never exceed 2-3ms. When it does we see intermittent crashes. I had one customer who had a particularly weak infrastructure and for whom I could predict his crashes; he was doing back-ups and running other tasks at a certain time weekly that would tax and hamper network connectivity for about an hour; these tasks were so all-consuming on the network, they turned every cluster resource into an individual asset on its own island. The log traces bore this out and we knew with precision what was going on. He knew he needed to upgrade his infrastructure and in the meantime we worked out a reaction plan to deal with the issue; it included:

  1. Place a higher than normal percentage of cache on each server to limit invoking shared storage
  2. Set the JDBC driver reconnection string for Database connectivity
  3. Plan Connect usage around these maintenance activities and when possible, do Connect maintenance activities at the same time as well – not very difficult as these were after hours, but being a  global operation, still not a given.