Posts in Category "Meeting"

Connect Meeting or Event Email is not received by Gmail Users

Problem:
Meeting invitation emails are not received by users of Gmail.

Environment:
Adobe Connect version – 9.3 and above
Email domain- Gmail

Reason:
There are a number of reasons why Connect email messages may not arrive in your inbox. Some of them are mentioned below:
– Emails from domain ‘admin@adobeconnect.com’ are marked as SPAM
– Filters are created in the GMAIL account settings forcing the Meeting invitation emails sent to Trash and deleted automatically.
– Forwarding is enabled in GMAIL account Settings > Forwarding and POP/IMAP.

Solution:
Check to make sure that GMAIL is not blocking Connect email:
1. Ensure email from domain ‘admin@adobeconnect.com’ are not marked as SPAM:
   -Sign in to Gmail.
-Click the down arrow in your search box. A window appears to specify your search criteria.
-Fill in the search field with email address ‘admin@adobeconnect.com‘.
– At the top of the search window, click on the drop-down menu under “Search”> select Mail & Spam & Trash.
– Click Search Mail button.
-Look for the message in the search results displayed.

2. Disable Forwarding or if it is enabled, then ‘Keep Gmail’s copy in the inbox’ is selected:
   -Sign in to Gmail.
-Click the drop-down arrow of the wheel icon 5 >Click settings > Click ‘Forwarding and POP/IMAP‘> Click the radio button ‘Disable forwarding‘.
6

-Note: If ‘Forward a copy of incoming mail to‘ is selected, then select ‘Keep Gmail’s copy in the inbox’

7

 

-Click 8 button.

3. Ensure that if POP is enabled, then ‘Keep Gmail’s copy in the inbox’ is selected:
   -Sign in to Gmail.
-Click the drop-down arrow of wheel icon 5 >Click settings > Click ‘Forwarding and POP/IMAP‘> Click radio button ‘Disable forwarding‘.
-UnderWhen messages are accessed with POP‘ select ‘Keep Gmail’s copy in the inbox’
10
4. Ensure there are no filters created in the GMAIL account settings forcing the Meeting invitation emails sent to Trash:
   -Sign in to Gmail.
-Click the drop down arrow of the wheel icon 5 >Click settings > >Click ‘settings‘ > Click ‘Filters’.
-Select any Filter created with the email address ‘admin@adobeconnect.com‘> Click Delete.
12

Adobe Connect Meeting Hangs on Connecting in the Safari Web Browser

Problem:
Adobe Connect Meeting hangs on connecting in Safari Web Browser.

Environment:
Operating system- Mac OS X 10.7.4, 10.8, 10.9 & Windows 7, 8, 8.1
Adobe Connect version – 9.3 and above
Web Browser- Safari

Reason:
When safe mode is enabled in the Safari Web Browser it prevents the Adobe Connect Add-in from launching. This is a Sandbox restriction. The respective Adobe Connect domain should be enabled in order to launch the addin in Unsafe Mode.

Solution:
In order to disable the sandbox restriction, refer to the steps mentioned below:
1. With the website open (e.g., akash.adobeconnect.com), Choose Preferences from the Safari menu.

  1. Select Manage Website Settings in the Security tab of the Preferences panel.
  2. Select your website (e.g., akash.adobeconnect.com) from the list of “currently open websites.”

4

 

    4. Select Run in Unsafe Mode from the pop-up menu.

    5. In the subsequent alert, click Trust.

    6. Click Done, and close the Preferences panel.

We recommend stopping Safari and launching it again after making the Security Preferences change.

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,

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>

Troubleshooting Microphone and Camera Issues in Connect Meetings

When both the web camera and the microphone do not work in an Adobe Connect Meeting, it is often caused by a restriction setting in the mms.cfg file.

The mms.cfg file it is found in the following directories:

  • Windows 32: C:/Windows/system32/Macromed/Flash (32-bit Windows)
  • Windows 64: C:/Windows/SysWOW64/Macromed/Flash (64-bit Windows)
  • MAC: MainDisk:Library:Application Support:Macromedia

Renaming or deleting the mms.cfg to mms.old is one way to solve the issue, but often it is more prudent (less intrusive) to edit the file. Open the mms.cfg in any text editor and look for the line:

AVHardwareDisable

Delete the setting AVHardwareDisable from mms.cfg and save the file. This setting deliberately prevents the Meeting SWF from gaining access to cameras and microphones on the Meeting client.

Verifying the Installation of the Adobe Connect Add-in

The Adobe Connect Add-in is a modified Flash Player that enables enhanced features for Adobe Connect Meeting. The add-in is not required unless the following functionality is needed in any Adobe Connect Meeting:

  • Screen sharing a client desktop, window or application
  • Offline recording downloadable to the client in the FLV format
  • Sharing any supported file by dragging and dropping onto a Meeting share pod
  • Toast windows for Meeting management are enabled within the add-in
  • The add-in provides greater real-estate for the Meeting by eliminating the browser and actual room itself

If you are in a Meeting room using the browser and the standard Flash Player instead of the Meeting add-in, you will see the following appended to the meeting room URL: ?launcher=false

FP.fw

If you are in the add-in, the URL line is not even seen as that real-estate is allocated top the Meeting room:

addin.fw

The add-in is always launched from a browser:

brow-addin-launch.fw

To force the installation and invocation of the add-in, append the following to any Meeting URL: ?lightning=true

If while using the browser in any Meeting, you invoke a feature that is only supported in the add-in, the lightning add-in installer will quickly offer you the option to install the add-in. The process is very fast and seamless. By default, the add-in is installed from the following external URL: http://www.adobe.com/go/adobeconnect_9_addin_win

Within any Meeting room you may also go to Help>Downloads and see links for the add-in among many other resources:

help-about.fw

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

dwnlds.fw

If your organization does not allow clients to download software from external servers, you can host Adobe Connect Add-in on-premise.

The add-in installs to the client’s user profile so it does not require local administrative privileges to install. It is safe to say that if a user has the required permissions to download the standard Adobe Flash Player and install it, the Meeting add-in will not present any problems as it only requires standard user rights. There are, of course enhanced security requirement enforced in many infrastructures that will prevent a user from downloading and installing the add-in and where the add-in will need to be rolled out by an internal IT or client/network administration team as part of a standard image.

The addin is installed to the following under the user directory:

  • Windows: %appdata%\Macromedia\Flash Player\www.macromedia.com\bin\adobeconnectaddin
  • Mac: ~/Library/Preferences/Macromedia/Flash Player/www.macromedia.com/bin/

If installation is successful, within the Adobe Connect addin installation directory there will be four files:

  • adobeconnectaddin.exe  (the primary executable file)
  • digest.s (the file used by Flash Player to verify that the add-in has not been modified)
  • meetingconvertor.dll  (the file used to manage PPTX file fidelity)
  • connecthook.dll  (the file used to manage screen sharing)

A partial or corrupted installation of the add-in will be missing some or all of these files.

On occasion, the mms.cfg file will cause problems with the add-in it is found in the following directories:

  • Windows 32: C:/Windows/system32/Macromed/Flash (32-bit Windows)
  • Windows 64: C:/Windows/SysWOW64/Macromed/Flash (64-bit Windows)
  • MAC: MainDisk:Library:Application Support:Macromedia

Renaming the mms.cfg to mms.old and reinstalling the add-in solves installation problems in some cases. For information about the mms.cfg file and how it can be used for troubleshooting issues within an Adobe Connect Meeting, see the following technote: http://helpx.adobe.com/adobe-connect/kb/enable-logging-acrobat-connect-professional.html

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.

Adobe Connect Add-in Compatibility with the Google Chrome Browser

Updated January 27, 2015:

Note: This article only applies to Adobe Connect on-premise server deployments. Adobe Connect hosted clients are unaffected.

The Google Chrome browser is currently shipping with two versions of the Flash plugin.  The default PPAPI and also the NPAPI Flash plug-in. The following versions of Adobe Connect installations are incompatible out of the box with the default PPAPI plug-in:

  • 9.1.2
  • 9.1.1
  • 9.0.1 – 9.0.4
  • 9.0.0.1
  • 8.2.2.4
  • 8.2.2

PPAPI plug-in incompatibility results in the Adobe Connect Add-in not being detected and launched in Chrome when invoked in a Connect Meeting. Even if the Add-in is installed, the meeting opens in the browser and not in the Connect Add-in. Upon attempting to share ones screen (a Connect feature supported in the Add-in but not in the browser), the following message appears:

chrome-addin.fw

Google Chrome, with the release of Version 40, will no longer use their whitelist to allow NPAPI  plugins to run without requiring approval: http://googleappsupdates.blogspot.com/2015/01/upcoming-changes-to-npapi-support-in.html Chrome users will not be able to use the Adobe Connect Add-in for the above listed versions of Connect. To address this problem, Adobe is patching the following Connect versions for use with Chrome:

  • 9.1.2
  • 9.1.1
  • 9.0.4
  • 8.2.2

These patches will fix the incompatibility problems with the PPAPI plug in. Adobe Connect servers that are not running one of these versions (or a later version) will need to be upgraded to the nearest later version to the one currently installed and then apply the appropriate Connect PPAPI patch.

There should not be any change in the behavior for Flash Player NPAPI in January because Flash Player is not listed among the applications  that are going to be removed in January:  http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

Workarounds until the patches are available:

  • You can attend Adobe Connect Meetings without the Adobe Connect Add-in, however the Add-in is required for enhanced functionality like screen sharing and making offline recordings.
  • Turn off auto-upate in Chrome so that you do not upgrade to a version of Chrome that is problematic.
  • Alternatively you can use any browser other than Chrome with Adobe Connect.
  • Manually enable NPAPI by clicking on the “Plug-in blocked” message in the URL bar and choosing “Always allow plug-ins on [website]” http://www.chromium.org/developers/npapi-deprecation

 

chrome-enable.fw

Note: In April 2015, this will no longer be an option as NPAPI support will be disabled by default in Chrome and Google will un-publish extensions requiring NPAPI plugins from the Chrome Web Store. Google will however provide an override for advanced users in the form of an ‘enable-npapi’ flag and enterprise policy to temporarily re-enable NPAPI.

XML API TIPS: Moving Virtual Classrooms to Meetings

You may have a situation arise where you want to move Virtual Classrooms (VCs) over to the Meeting area of Adobe Connect.  You may notice that if you try to move Virtual Classrooms, you only have the ability to move them within the confines of the Training module and not out to the Meetings area if you are using the UI.  There is an option however.  The API can be used to move VC’s either one by one or an easier way is to put them all into folders inside of the training area (in either Shared or User training folder) and then move the folders themselves (which in turn will move all the VCs inside of it).

The API process for doing this is:

https://{connect domain} /api/xml?action=sco-move&sco-id=xxxxxxx&folder-id=xxxxxxx

where:

sco-id = the sco-id of the VC (or folder that contains all the VCs you want to move)
folder-id = the folder-id of the destination folder you want to move the VC to.

** DO NOT move any main User Training folder or the Shared Training folder itself. ONLY move user-created folders or individual VCs themselves.

 

The process is not done however.  For each VC you move, you have to do one more step.  You need to change the icon of the VC to a meeting icon.  If you do not do this, the VC’s will NOT launch.  You won’t even be able to get to the information page for the VC once it’s moved.  The link to the VC information will simply refresh the meeting list page if you do not change the icon.

To finish the process change the icon by making this call:

https://{connect domain} /api/xml?action=sco-update&sco-id=xxxxxxx&icon=meeting

where:

sco-id = the sco-id of the VC you just moved.
icon=meeting

 

Now, the VC link will work and you will be able to get into the information page and access the links, content, reports, and archives.

Your application can handle building a list of VCs to move by using the sco-contents or sco-expanded-contents API calls (filtering on ‘icon=virtual-classroom’) to list out all VC’s in a specific folder or across the account as a whole, should you want to move everything for example.  Then your application would loop through and not only move the VCs but then also loop through each and change the icon.  If you only want to move one or two, you can simply do this in the browser with the API calls above.

It’s important to note that the uploaded content and any archives associated with this will be retained, HOWEVER in the reports, you will notice you are missing the ‘By Course’ report.  That is LOST with the move.  ‘By Course’ report is essentially the difference between a meeting and a VC.  So if you move VCs to meetings, that report is gone.  You still will have ‘By Attendees’ , ‘By Session’, and ‘By Questions’ (which are poll pod questions, not courses) reporting that will be retained.

Of course moving meetings to training will work the opposite way.  You finish that process off by changing the icon from ‘meeting’ to ‘virtual-classroom’.

 

Connect Meetings do not inherit the properties from its base template.

We have optimized meeting utilization of available bandwidth in Connect Version 9.2.2c and made some changes to retain these settings.

Earlier than 9.2.2c:

New meetings retained their preference settings (for ex., Bandwidth configuration LAN/DSL/MODEM) from its base template).

9.2.2c and above:

New meetings do not retain their preference settings (bandwidth settings in 9.2.2c and video settings in 9.3+) from base templates.

Example:

On Connect 9.2 and previous versions:
1.       Create a template and change the Room bandwidth to Modem.
2.       Moved the meeting in shared template folder.
3.       Create a new meeting using the above template and the Room bandwidth should be Modem.

Test with Connect 9.2.2c
a.      Created a new Room with base template as Step 1 above.
b.      Now, the room bandwidth will be DSL (default setting).
c.      Note: preferences in the Template created in Step 1 are still set to Modem

Bandwidth settings are removed from the User Interface in Connect 9.3.  Video and screen-share settings can be adjusted according to bandwidth/requirement.