On-premise Server: Add user-agent info to access logs

If you run your own Connect server you may want to add user-agent information to the tomcat access logs.

Here’s how to add the information:

1.  Take a backup copy of the server.xml located in \Connect\9.x\appserv\conf\.

2.  Open the file in an XML friendly editor and locate the line:

 

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”../../logs/tomcat”
prefix=”tomcat_access.” suffix=”.log” pattern=’%h %l %u %t %m “%U” %{BREEZESESSION}c %s %b %T’ resolveHosts=”false”/>

 

3.  Edit the line to include %{User-Agent}i . It should look like this:

 

<Valve className=”org.apache.catalina.valves.AccessLogValve” directory=”../../logs/tomcat”
prefix=”tomcat_access.” suffix=”.log” pattern=’%h %l %u %t %m “%U” %{BREEZESESSION}c %s %b %T %{User-Agent}i‘ resolveHosts=”false”/>

 

4. Restart the Connect service and load any page of Connect.

The log output in \Connect\logs\tomcat\tomcat_access.-date-.log should now include user-agent information:

127.0.0.1 – – [23/Feb/2015:11:39:45 +0000] GET “/common/help/en/support/meeting_test.htm” breezbreezhvc7xdcgu5h3cqwm 200 16703 0.017 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0

 

Enjoy logging!

The Connect Meeting Add-in with Chrome is not recognized on the Meeting Test Page

When running the Connect Meeting test link from the troubleshooting option under the help button in any Connect Meeting, there are times when the Connect Meeting Add-in with Chrome is not recognized:

chromeaddin.fw

https://platinum.adobeconnect.com/common/help/en/support/meeting_test.htm

chromeaddin1.fw

chromeaddin2.fw

chromeaddin3.fw

If you place your mouse over the highlighted icon, you will see the oddly stated message: An unsandboxed plug-in was allowed to run running on this page.

chromeaddin4.fw

Allow the add-in and place its domain into the exception list in Chrome and refresh the browser.

chromeaddin5.fw

The reason for this behavior is that the Chrome PPAPI and Adobe Connect interaction (even after the Connect PPAPI patch as well as with the non-affected Connect versions later than 9.1.2) is changed nonetheless. See the related blog article: http://blogs.adobe.com/connectsupport/adobe-connect-add-in-compatibility-with-the-google-chrome-browser/ The PPAPI plugin blocks the communication between swfs and other Unsandboxed applications.

The granting of access permissions is domain-based. The setting is called Unsandboxed Plug-in Access; when you launch the Meeting test page it fails to detect the Addin. If you had installed the Addin from that test page then in the process of the installation, Chrome would also prompt for permission and it will save it once you allow it. Any subsequent launch of test page or any page from that domain will always identify the Adobe Connect Addin correctly. If you again open the Meeting test page from some other Adobe Connect domain then it will fail to detect the Addin even if Addin is installed because this new domain may not have Unsandboxed Plug-in Access.

Once a domain is allowed Unsandboxed Plug-in Access, then any page from that domain will detect and launch the Adobe Connect Meeting add-in.

Note: One customer wrote code to automatically install the latest Adobe Connect Meeting add-in in the browser. It worked for all browsers except Chrome. See this tech-note for details: https://helpx.adobe.com/flash-player/kb/unsandbox-localconnection-chrome.html

Resolved: CSO – DATE (5 FEB 2015) – InterCall Telephony Outage Affecting Connect Audio

This is resolved as of 1705 EST 15Feb2015

We are actively working with our partners at InterCall to solve an intermittent telephony outage.

This issue is causing InterCall based audio conferences to fail to start in Adobe Connect Meetings.

The root cause is under investigation by InterCall.

You may check http://status.acrobat.com/ for updates.

Stop Sharing Button On IE Is Not Available Any More.

Description : We use to get this button on IE when we share the screen.

StopSharinghowever now this button is no longer available.

Reason being it interfaces with the DWM (Glass effect of windows 7+).

DWM : Stands for Desktop Window Manager Click here

We used to support Windows XP which had no Glass effect and thus it was not a problem. On windows 7 we used to switch the DWM off before starting the screen share. Window 8 onwards the DWM cannot be programmatically switched off and thus this button was causing problems. Many applications change the Glass area and IE is one of them. Others include Chrome, FireFox, Office etc. In case the applications change the Glass area then it’s a matter of timing to Display the button or the custom title bar the application draws.

This was actually a bug 2943337 due to which the button

StopSharing

Intermittently disappears. The bug is only reproducible with the applications which have custom title bars. Ex. Real Player/Office Apps/Live messenger and media players. With the Office 2007 applications the title bar is custom drawn and thus it intermittently draws over the button and it disappears. This only happens with skinned title bars, Skinned apps try to redraw their title bars so button disappears until we redraw again.

The “Red Button” never worked for 64 bit processes. This will also not work for any apps which have skinned title bar as i said earlier. Moreover this feature will not work if the process in question is sandboxed (Acrobat for example).

Yes downgrading IE will help probably but it’s not something we can recommend in good faith as it will expose the users to all kinds of security bugs. (Not recommended)

o    Windows 8 and onwards the button is not even an option as DWM can’t be switched off by programs programmatically and the button itself has issues when DWM is on

o    As of today this button has been disabled permanently.

Hope this helps those users who are expecting the red buttons on their IE when sharing the Application or Windows and not desktop using Adobe Connect Meeting Room,

Thanks,

Users Already Registered In An Events Can Still Register In The New Event.

Description :- User registered in the system can still register in a new event. In other words, this user can re-fill the registration form for any new event even though he have already registered once in the past event. We have seen many users confused about why they keep getting an error stating that you have registered with us before and sometimes they don’t get that message. Here i will explain the workflow and why this happens.

On a Generic Registration page, which looks like as shown below:

Registration Page Template

User will Enter his email address and create a password for this Event. Let say this event is Event A. Now if this user wants to access another event and fills up the same details on registration page as shown above, there will be two scenarios which he/she will confront.

  1. Scenario 1:-  If the user uses the same email address and same password to register, as a result he will be registered successfully and receives a message stating “Thank you for your registration request. Your information has been submitted to the event host. Please check your inbox for more details about this event.”Just like as shown below :ThankYouForRegisteration

  2. Scenario 2:- If the user  uses the same email address and different password to register, as a result he will received a message stating “Email ID abc@abc.com is already registered with us . Please use your existing password to continue or use the forget password link to reset your password.” Just like as shown below :

    EmailAddressAlreadyExist

You probably have noticed that on the registration page when you register for an event you will see it indicates a message stating, “If you have registered with us before, please Click Here” as shown below :

Registration Page 2

If you click on this link you are redirected towards this page, which indicates “Enter your login/e-mail address and password below if you have previously registered with us. If you haven’t previously set the password or don’t remember it, please click forgot password link.” as shown below:

Registration page 3

Remember : If you have registered with us before on an event which did not set your password. In other words, where on the registration page it was just asking your Email address, First Name and Last Name as shown below :

RegisterwithoutPassword-2

This means that the host who have created this event have set the property to register without setting a password on this event. At the time of creating this event he left this check box checked “Register Without Password”:

RegisterwithoutPassword

Now in this case a user can register only by using his/her email address. Also, if he comes back later and try to access the Event B where password needs to be set, he will have to click on “Forget Password” to set his password because if he try to register by filling all the information again, on the reregistration page he will encounter the message as shown below :

EmailAddressAlreadyExist

This indicates that he has already registered with us before.

Understand the workflow here :

Basically when someone registers for an event consequentially a user is created in Connect system– so this means that login is from that point, is reserved in the system to identify that particular user. Afterwords, if the same user, same login, wants to register to another event he need to provide a password to match his username which is existing in the system.

When user registered in the past for Event B and now wants to register for Event A he should click on the link (click here). This will redirect him to the login form where he can initiate a forgot password workflow if needed. As a shortcut, if user missed the string above registration form, he may go ahead and enter his credentials (the same he used for EventB) and he will be approved to register so it ends in successful registration.

In simple words :

  • User registers on Event B form with same email address and same password, which was created on Event A in the past. Result : Successfully Registration.
  • User Registers on Event B form with same email address and Different password. Result : Already Existing in the system, cannot register successfully.

 

Hope this would help a lot of our users to understand the work flow of Event Registration System.

Thanks,

Remove “Review” message in training content (on-premise installs)

Once a training is completed you can review it. When in review mode a message is displayed at the top of the browser window and in the window title.

Here’s a screenshot of the message showing on a training item in review mode:

reviewMode

Here’s how to remove the message and window title on your on-premise server (tested with 9.3.1c).
The change will remove the review message and title from the content window. It will not remove the review button shown under “my training” within Connect central.

Find the file: C:\Connect\9.3.1\appserv\apps\system\content.xsl and take a backup copy of it.

Open it in an xml friendly text editor such as notepad++ and find the following section and comment it out:

<xsl:variable name=”is-review”>
<xsl:choose>
<xsl:when test=”/results/extra/is-review”><xsl:value-of select=”/results/extra/is-review”/></xsl:when>
<xsl:otherwise><xsl:text>false</xsl:text></xsl:otherwise>
</xsl:choose>
</xsl:variable>

Commented:

<!–
<xsl:variable name=”is-review”>
<xsl:choose>
<xsl:when test=”/results/extra/is-review”><xsl:value-of select=”/results/extra/is-review”/></xsl:when>
<xsl:otherwise><xsl:text>false</xsl:text></xsl:otherwise>
</xsl:choose>
</xsl:variable>
–>

Add the following just below:

<xsl:variable name=”is-review”>
<xsl:choose>
<xsl:when test=”/results/extra/is-review”><xsl:text>false</xsl:text></xsl:when>
<xsl:otherwise><xsl:text>false</xsl:text></xsl:otherwise>
</xsl:choose>
</xsl:variable>

Apply the change to all nodes in your cluster and restart the Adobe Connect service for the change to take effect.

Please note: This is an unsupported change. I tested it on a 9.3.1c on-premise install, but should you encounter any issues with the training module or with other features in Connect, please restore the original file and restart the services.

Empowering Your Seminar Hosts to Create Seminar Rooms

The question comes up on occasion, “Why can’t my Seminar Hosts create seminar rooms?”

The answer is that they have been affected by an intermittent bug, which we realize may cause some confusion, if not chagrin. There is a workaround available, which we’ve outlined below.

Workaround:

As an Administrator, create a typical account with Meeting and Seminar Host permissions (as a test):

sem

Log in with that account and this is what you may see in the Shared Seminars directory. There is no ability to create a Seminar and the Seminar license is not viewable:

sem1

If you switch back to the administrative account log-in, you will see the Seminar license sub-directories:

sem2

sem3

Resetting the permissions on the Seminar license sub-folder using the to “Reset to Parent” button in the Connect Central GUI has no effect on the permissions. You must manually add the folder permissions to the Seminar license sub-folder instead of using the “Reset to Parent” option:

sem4

Once the Seminar license sub-folder permissions are manually edited, the Seminar Host is able to view and manage the Seminars including the ability to create new Seminar rooms under the Seminar license sub-folder:

sem5

The workaround is very easy so this is a low priority bug and we will address it in a future release. At the time of the writing this tech-note, the shipping Connect release is 9.3.1.d.

XML API TIPS: Moving Archives That Have Been Repaired

One common workaround that customers do (or Adobe support may do on behalf of customers) to fix recordings that have some sort of sync or playback issue, is to download the archive (recording) zip, potentially run it through a repair tool, and then re-upload the zip package back to Connect as a content object in the ‘Content’ directory.  A common request may be to move that archive from the Content directory, to another location or even back underneath the Meeting’s ‘Recording’ directory.  The problem is that with failed recordings (recordings that didn’t fully process) and/or re-uploaded recordings, they will not have a ‘date-end’ parameter for the sco, like normal recordings do.  So when you try to (for example) move the archive to the original Meeting’s Recordings directory (which can really only be done using the API), you will get the following error:

API Call = Sco-Move:

/api/xml?action=sco-move&sco-id=xxxxxxx&folder-id=xxxxxxx

where sco-id = the sco-id of the re-uploaded archive
where folder-id = the sco-id of the original meeting (which is also the sco-id of the Recordings directory for that meeting)

Result:

<results>
<status code=”invalid”>
<invalid field=”sco-id” type=”string” subcode=”recording-is-in-progress“/>
</status>
</results>

This is because the sco does not have a date-end param/value.  You can see this by running the sco-info call on the sco-id.  You will see no date-end.

What you need to do before you can move the sco, is set a date-end param using the sco-update API.  You would set the date-end value to some date in the past.

Here is an example:

/api/xml?action=sco-update&sco-id=xxxxxxxx&date-end=2015-01-01T12:00:00.000-04:00

Result:

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

Now, when you do a sco-info on that sco you should see the date-end param and value.

You can now also move the recording to it’s desired location (say back to the Meeting’s recording directory):

/api/xml?action=sco-move&sco-id=xxxxxxx&folder-id=xxxxxxx

Result:

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

Microphone Stops Transmitting Audio After Running the Audio Setup Wizard in a Meeting

Problem: Microphone stopped transmitting audio after running audio set up wizard in an Adobe Connect Meeting.

Note: This is being tracked by Adobe engineering under case: 3916223. It will be fixed in a future release.

Here are the steps that will make the problem occur:

  1. Open the Meeting room.
  2. Enable the microphone within the Meeting room.
  3. Select the microphone and checked that microphone  is working.
  4. Now run the Audio Setup Wizard.
  5. You will noticed that microphone is highlighted however there is no audio emitting.

Result: The microphone stops working after running the Audio Setup Wizard

The expectation: Microphone should not stop working,

This is a bug with Flash Player 11.9 which the Adobe Connect Add-in uses. This has been fixed by the Flash Player Team in its later releases and we need to integrate that fix into the Adobe Connect Add-in.

There are two instant workarounds:

  1. Right-click and open flash player microphone settings -simply opening the microphone settings causes the microphone to work again.
  2. Mute and again unmute the microphone by clicking on the microphone icon in the meeting client.