Posts in Category "Administration"

XML API Tips: Modification of Help / Support Links

In Adobe Connect (both On Prem and Hosted accounts), there are methods to modify existing support and help links using the XML API.  This was implemented to provide the capability to replace the in product support / help links and details with partner or organization-specific links / contact information.

Use Case

Say a partner or organization wants to be able to replace the help / support links embedded in the Connect meeting client or Connect web app with links to their own version of the help documentation / support information or support portal. They need to provide a combined cohesive help / support channel to their customers or their users.

The following undocumented APIs are provided to modify the support or help link customization on a per-account basis. Here is how it works:

Link 1 – Contact Support (In Meeting)

First, the ‘Contact Support’ link in the Meeting interface itself (as seen below):

contactsupport
To modify this, use the XML API call: account-support-link-update to enable or disable the account feature and modify the support link.

The default support link is: http://helpx.adobe.com/adobe-connect.html

XML API Call Info:
account-support-link-update
parameters:
account-id = the account-id of the account you are modifying the links for
enable = true or false – enables (true) or disables (false) this feature
support-link = link to partner or customer support site (must be http link)
- if enable is true, must provide support-link
- if enable is false, remove support-link for the account

To enable a custom link:

https://{AccountURL}/api/xml?action=account-support-link-update&enable=true&support-link=http://mySupportsiteURL

Results:

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

</results>

To verify it is now active (aside from testing in a new meeting session), you can run the ‘feature-info’ API call which will return that feature as part of account information if the feature is enabled on the account.

Example:

https://{AccountURL}/api/xml?action=feature-info&account-id=XXXXXXXX

<results>
<status code=”ok”/>
<disabled-features>
….snip snip….
<feature account-id=”XXXXXXXX” feature-id=”fid-non-partner-support-link“>
<date-begin>2013-10-29T16:53:09.533-04:00</date-begin>
<date-end>2999-12-31T19:00:00.863-05:00</date-end>
<recordcreated>2013-10-29T11:53:09.553-04:00</recordcreated>
</feature>
….snip snip….
</disabled-features>
</results>

Note: it’s deceiving, but it WILL be listed in the ‘disabled-features’ XML node if it is ENABLED.  If it is NOT enabled, it will NOT show up in the results of this call.

To disable (or set back to the original default setting):

https:{AccountURL}/api/xml?action=account-support-link-update&enable=false

Results:

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

Note: For meetings that are still active and have not unloaded from memory yet, the links will not change until it fully shuts down.  For new meeting sessions, the link will immediately be updated/reflected to show the intended webpage.

Link 2 – Help Link (Login Page)

Second, the ‘Help’ link on the login page (as seen below):

help

The default value will take you to: http://helpx.adobe.com/adobe-connect.html

XML API Call Info:
account-custom-help-link-update
parameters:
account-id = the account-id of the account you are modifying the links for
field-id = the field-id of the help link you are trying to modify. Values are:
- account-login-help-link
- account-webapp-help-link
value = link to partner or customer support site (The help link must start with either ‘http://’ or ‘https://’.  No javascript urls are allowed as values.)

 

To enable a custom link (use the ‘account-login-help-link’ field-id above):

https://{AccountURL}/api/xml?action=account-custom-help-link-update&account-id=XXXXXXX&field-id=account-login-help-link&value=http://mySupportURL

Results:

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

Link 3 – Help Link (Connect Central Page)

Third, the ‘Help’ link on the top of the Connect Central page (as seen below):

central

The default value will be: http://help.adobe.com/en_US/connect/9.0/using/index.htm

XML API Call Info:
account-custom-help-link-update
parameters:
account-id = the account-id of the account you are modifying the links for
field-id = the field-id of the help link you are trying to modify. Values are:
- account-login-help-link
- account-webapp-help-link
value = link to partner or customer support site (The help link must start with either ‘http://’ or ‘https://’.  No javascript urls are allowed as values.)

 

To enable a custom link (use the ‘account-webapp-help-link’ field-id above):

https://{AccountURL}/api/xml?action=account-custom-help-link-update&account-id=XXXXXXX&field-id=account-webapp-help-link&value=http://mySupportURL

Results:

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

To REMOVE any of these link customizations, simply leave the VALUE param empty:

https://{AccountURL}/api/xml?action=account-custom-help-link-update&account-id=XXXXXXX&field-id=account-webapp-help-link&value=

Results:

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

And:

https://{AccountURL}/api/xml?action=account-custom-help-link-update&account-id=XXXXXXX&field-id=account-webapp-help-link&value=

Results:

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

To view any custom help links set on the account:

XML API Call Info:
account-custom-help-links
parameters:
none.

https://{AccountURL}api/xml?action=account-custom-help-links

If NO help links have been customized, you will see only an ‘ok’ result returned.

Results if no help links:

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

 Results if help links are customized:

<results>
<status code=”ok”/>
<custom-help-links>
<links>
<login-help-link>http://www.mysupport.com</login-help-link>
<webapp-help-link>http://www.mysupport.com</webapp-help-link>
</links>
</custom-help-links>
</results>

Using the FMS API for On-Prem Adobe Connect

For monitoring purposes, you can build an application which utilizes additional API calls that hook directly into the Flash Media Administration Server services.  This is undocumented but may help you with additional monitoring or statistics on the FMS side.

A full list of FMS/FCS API entries for the 9.1 version of FMS (which is version 4) can be found here:
http://help.adobe.com/en_US/flashmediaserver/adminapi/WSa4cb07693d12388431df580a12a34991ebc-8000.html

Previously, as an Adobe Connect administrator, you probably have always had the additional FMS service (Flash Media Administration Server) shut off.  In order to utilize the API, you need to make sure this service is running:

fmsadmin

In order to hit the API for FMS, you need to use the FMS admin username and password.

This can be found in:

[install drive]:\Connect\9.1.1\comserv\conf

# An administrator for the server. Users.xml
DEFAULT_FCS_USER=XXXXXX
# Password for this vhost administrator. Users.xml
DEFAULT_FCS_PASSWORD=XXXXXX

In order to use all the calls (or a select few, depending on your desire), you need to modify one additional FMS file (see below).

Continue reading…

XML API Tips: User Manager Associations

A common workflow for Adobe Connect admins is to associate users to managers via the UI.

In the UI, you can navigate to the Administration > Users and Groups > {select a user} > Edit Team Members area to select users who will be direct reports of that manager.

This information will show up in the ‘My Profile‘ > Organization area for the user, where they will be able to see their Manager information (if they have a manager set) and their Team Members (if they are a manager themselves).

But with the XML API, this process is undocumented. Here’s how you accomplish this:

How do I associate a user to a Manager?

http://connectURL/api/xml?action=user-manager-update&manager-id=XXXXXXX&principal-id=XXXXXXX

Where:
action=user-manager-update
manager-id= principal-id of user who is going to be the manager
principal-id= principal-id of the user who is being assigned a manager

Note:
The user-manager-update call is UNDOCUMENTED.

Results:

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

How do I disassociate a user from a Manager?

http://connectURL/api/xml?action=user-manager-update&manager-id=XXXXXXX&principal-id=XXXXXXX

Where:
action=user-manager-update
manager-id= the account-id (’7′ if an on-prem/Licensed customer or a longer numeric value for an Adobe Hosted customer)
principal-id= principal-id of the user who is being assigned a manager

Note:
The user-manager-update call is UNDOCUMENTED.

Results:

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

 

The below IS documented, however it is applicable to this post, so I will include it:

How do I list all direct reports of a Manager?

http://connectURL/api/xml?action=principal-list&filter-manager-id=XXXXXX

Where:
action=principal-list
filter-manager-id= the sco-id of the user who is the manager

Results:

<results>

<status code="ok"/>
<principal-list>
<principal principal-id="XXXXXXXXX" account-id="XXXXXXXXX" type="user" has-children="false" is-primary="false" is-hidden="false" manager-id="XXXXXXXXX" training-group-id="">
<name>USER NAME (FIRST AND LAST)</name>
<login>USER LOGIN VALUE</login>
<email>USER EMAIL VALUE</email>
<display-uid>USER LOGIN VALUE</display-uid>
</principal>
</principal-list>
</results>

 

Using the XML API and Microsoft Excel to obtain additional reporting from Adobe Connect

Sometimes customers need a custom report that is not included in the normal reports in the Adobe Connect UI.   They can obtain this data by running an API call, however the results get displayed in a browser (in an XML result set) and is not in a user-friendly format as-is.  In lieu of actually building an application that can parse and display the XML in a nice format for the user to be able to display in a useful manner, we can simply use Microsoft Excel to display the data in a nice tabbed report format.

An example of this would be as follows:

Say, you want to report on what users are in a particular group within Adobe Connect, and there is no good established report to actually display this data (other than in the datagrid in the Users and Groups area)…

Here’s what you can do.

Log into the account in a browser, as an admin.

Run the following API (or any API you need to run to obtain the data you are looking for):
http://connectURL/api/xml?action=principal-list&group-id=XXXXXXX&filter-is-member=true

Where:

action=principal-list
group-id= principal-id of group you want to report on
filter-is-member=true

 The results will get returned in the browser in XML format (as seen in the screenshot below):

Save the current page as an XML file by going into the browser options and select ‘Save As’ and make sure you save the page as ‘.xml’.

xml-1

 

After saving the XML locally, open up Microsoft Excel (on Windows) and select Data > From XML Data Import.

xml-2

 

Click OK through all the next pop ups that show up after selecting the XML file and just select the defaults:

xml-3 xml-4

 

Once the data loads in the worksheet, it will be formatted in a nice tabbed display as you see below:

xml-5

Passing a user into an Adobe Connect Meeting without the Login Page

Periodically customers want to be able to pass in Guest users into an Adobe Connect Meeting without having those users actually have to pass in a guest name in the Meeting login page.  The scenario here may be that organizations may have an external registration system where users put in their email address, first name, last name, and other data, into a form on their registration portal and they do not want users to have to register (externally) for a Meeting and then put their name or login value in again a second time, on the Meeting login page.  Also, the organization may want to keep close tabs on how the guest name is entered, so it will match their own registration system, for reporting later.  For this, we have a quick and simple solution.

If the meeting is setup for public access (‘Anyone who has the URL for the meeting can enter the room‘) or for the default access level (‘Only registered users and accepted guests may enter the room), then you can simply append ‘?guestName=XXXXXXX‘ to the end of the meeting URL (where ‘XXXXXXX’ would be the value of their name that you want to display in the Attendee List Pod when they are in the meeting).  It would look something like this: https://{connectDomain}/{meetingURL}?guestName=Jim Johnson

The behavior will be:

For access level: ‘Only registered users and accepted guests may enter the room’: the user will be let right into the room’s lobby (without seeing the login page) and will see the message: ‘This is a private meeting. Your request to enter has been sent to the host. Please wait for a response.’  Then a host can accept them and they will be let into the meeting as whatever value was appended to the ‘?guestName=’ parameter.

For access level: ‘Anyone who has the URL for the meeting can enter the room’: the user will be let right into the room itself, as they normally would, but they never see the login page and their name value in the Attendee List Pod is whatever was passed in in the ‘?guestName=’ parameter.

 

From the integration perspective, the external registration system which mines the user data (name, email, etc.) you’d need to programmatically set this guestName value in the URL for each user.  This can be done in the application which presents the URL to the end users from the registration system and you can put the first name + last name, email address, or whatever other value you want to set in there.

 

Meeting Room Access Improvements in Connect 9.1

Issue: In Adobe Connect 9.1, we’ve made a number of changes to the way you enter an Adobe Connect Meeting room. This article will explain what changed with reference to meeting room accessibility in Connect 9.1 over against 9.0 and how the 9.1 changes are an improvement.

We solved two key entry issues:

1. The first issue addressed was the ambiguous message received by a participant who clicks a meeting room URL before the host opens a meeting room.  The ambiguous default message in Connect 9.0 reads, The Host has ended this meeting. Thank you for attending. This can be confusing as it refers to a previous meeting rather than the one about to start. Many confused participants, upon seeing that message, thought they missed the meeting; certainly, for someone new to Connect, this stark message often left the eager, early, overachieving (probably a bit anal-retentive) participant in the confused position of hitting a wall with no apparent gate through which to enter the upcoming meeting.

Untitled-3.fw

We fixed this ambiguity in Connect 9.1; now when a participant clicks the meeting room URL before the host reopens the new message reads, The meeting has not yet started. You will be able to access the meeting once the host arrives. Please wait.

Untitled-6.fw

Note: This message is clearer; participants now know to wait until the meeting is opened by the host. You can overlook that it uses the noun access as though it were a verb.

2. The second issue addressed with reference to meeting room accessibility in Connect 9.1 is that of eliminating some confusion around closing the meeting. There are two common ways that hosts close meetings, the first is to simply close the browser or addin and the second is to use the meeting room menu option to end the meeting.

Untitled-4a.fw

In Connect 9.1, both of these options (End Meeting… or close browser) place the concluded meeting into the same state based on which of the three options the host chose under the meeting properties when creating the meeting room; Connect offers three access settings for meetings:

  • Only registered users may enter the room (guest access is blocked)
  • Only registered users and accepted guests may enter the room
  • Anyone who has the URL for the meeting can enter the room

These option are found under the Edit Information tab; a quick way to get to the Edit Information tab from any open meeting is by clicking Manage Meeting Information under the Meeting menu item:

Untitled-1.fw

Note: The option Only registered users and accepted guests may enter the room, is the default choice.

If you choose to set either the first or second option listed, then in Connect 9.1 it does not matter how you close or end a meeting room. If the meeting room is closed, then the meeting users will need to request entry before joining.

If your meeting is set to the third option, Anyone who has the URL for the meeting can enter the room, then there is a change that may confuse those hosts who are used to Connect 9.0 and prior versions of Connect and Breeze. Participants will now be able to enter a meeting room whether the the host closed the browser or whether the host used the meeting menu option to end the meeting. The setting under the meeting properties adjudicates; a meeting room deliberately set up to be open, will now remain an open room: With Connect 9.1 participants will be able to enter rooms set up with open permissions. It is prudent to carefully consider when to choose the option, Anyone who has the URL for the meeting can enter the room. And if you do choose this option, it is prudent to consider what is left in the meeting room to see, whether old chat messages or something in the share pod keeping in mind that a participant cannot navigate within the room, but may only see what is on stage.

3. There is another way to block entry to a meeting.  Connect has a feature to block meeting access and make sure users request entry.

In the menu bar, select Meeting > Manage Access and Entry > Block Incoming Attendees:

Untitled-7.fw

To allow incoming attendees to request entry to the meeting, select the option, Incoming attendees can request entry:

Untitled-8.fw
Note that in the text box, you have the option to edit and save a message for incoming attendees.

Conclusion: While initially, the new meeting room access improvements in Connect 9.1 may cause confusion, the changes with reference to meeting room accessibility in Connect 9.1 over against 9.0, offer a more intuitive and consistent workflow. And while old habits dies hard, I think you will agree that the 9.1 changes are warranted to allow hosts to better manage Connect 9.1 meeting access.

Seminar Room Information Access for Seminar Hosts

In Adobe Connect 9.1, there seems to a misconception sometimes among Seminar Hosts that a user in the Seminar Host group can view and modify any Seminar Room (and their recordings, etc.) on the system. This is actually not the case.  Here is a summary of the permissions and scenarios in which a user who is in ONLY the Seminar Hosts group can view and modify Seminar Room information and related content/recordings.

When the permission of a Seminar Room itself is changed to:

a) Only registered users may enter the room (guest access is blocked) 

Or

b) Anyone who has the URL for the meeting can enter the room

Then we explicitly set “denied” or ”view-hidden” permission for All Users in the database for this Seminar. In that case, a Seminar Host or user performing the operation no longer has any more permissions (as he is also part of All Users) unless that user is explicitly part of the Participant list either as host or presenter OR has Administrator or Limited Administrator permissions.

What this means is that if you select any of the two above access levels for the Seminar Room when you create it (so NOT ‘Registered Users AND Accepted Guests’), then ONLY admins, limited admins, and users who have been added to the meeting as a Host or Presenter can actually edit that meeting (and change recording access levels, etc.).

The bottom line is the person who is modifying Seminar Room access should be either part of Seminar Participants or should have Administrator / Limited Administrator permissions.

So in a nutshell, these are the scenarios where Seminar Host Group members can change recording access for a seminar:

  • Creators of the Seminar Room (who are obviously the host) – no matter what the access level of the room is set to.  If they created it, they can edit/change things in that Seminar Room.
  • A Seminar Host Group member who has been added to a room (that they didn’t create) ‘s Participant List as a Host or Presenter of the room – no matter what the access level of the room is set to.
  • A Seminar Host Group member who doesn’t have any Host permissions for the room but if the room is set to ‘Only registered users and accepted guests may enter the room’.
  • A Seminar Host Group member who is also a Limited Administrator.
  • A Seminar Host Group member who is also an Administrator.

Here are the scenarios where a Seminar Host Group member can NOT edit a room or change recording access, etc.:

  • A Seminar Host Group member who is NOT also in Limited Admins Group or Admins Group and who is not a Participant (Host) in the room and the room is set to “Only registered users may enter the room (guest access is blocked) “
  • A Seminar Host Group member who is NOT also in Limited Admins Group or Admins Group and who is not a Participant (Host) in the room and the room is set to “Anyone who has the URL for the meeting can enter the room”

Brad’s Short-list for Connect Cluster SaaS Monitoring Options

There are many options on the monitoring theme that are worth considering when trying to decide how to keep trach of Connect server resources in a cluster. Articles describing clustered environments are on the Connect Users Community : http://www.connectusers.com  Simply search the User’s Community using the keywords: cluster, pool, edge, SSL, etc.

To effectively monitor your Connect cluster SaaS options can sometimes be cost effective than home-spun solutions; here are some staff picks with some commentary:

Sumologic- It resembles Splunk. The main difference is that Sumologic is hosted and managed externally and Splunk is hosted and managed on-premise. With Sumologic, there is not any need for software licensing, hardware investments or internal administrator expertise.  Splunk offers a similar service called splunk>storm, but it is not as mature as Sumologic and lacks some of the alerting capability found in Sumologic.

Loggly - An alternative to Sumologic could be Loggly which offers a similar service; it seems that the alerting service is not exactly built in.  It requires a little more work and is called AlertBirds.

Note: It is possible to take an on-premise option like Cacti and port it to Sumologic, so you could effectively kill 2 birds with one stone.  You can setup a forwarder in 30 seconds and be searching the logs in no time at all.

Monitis – Provides capabilities similar to those of Nagios along with external monitoring.  The Monitis community writes custom monitors thereby enriching the options.

LogicMonitor – An alternative to Monitis could be something like LogicMonitor.  You may be able to port your existing Nagios checks over to it (check and verify).  This si a simple solution, installing the monitor and having basic checks like CPU, Memory, Bandwidth, Disk Usage, Disk IO and external ping, http, https and udp monitors setup would take all of 20 minutes.

Pingdom- An alternative to RedAlert at a lesser cost.  It is trusted by millions and is easy to use and has more endpoints than comparable options.  It takes five minute setup.

The beauty of a SaaS monitoring solution is that you do not need to worry about scaling your monitoring solution every time you scale your Connect architecture.  You can have a single solution for 20 Connect Clusters vs having to add Cacti servers, Nagios servers, Splunk architecture and licensing to handle the additional monitoring needs commensurate with expansion.  With a SaaS solution, there in not any build-out time.  You can literally have 20 monitors up and running in under an hour, and work on adding additional ones at your leisure in between casts with your new Deceiver 8 Fly Combo.

With reference to basic on-premise monitoring, make sure you use standard perfmon counters for things like CPU, Memory etc. For meeting count and meeting user monitoring you may use the FMSAdmin API with scripts to make various calls and then parse the data and pass it to an option such as Cacti.  To insure robustness, the FMSAdmin service should be restarted routinely. You could also use similar counters to pull data directly from the Connect database, but this is not without risk as Connect updaters and upgrades can introduce changes that may require rework of your custom counters.

Changing Log Rotation Options on Connect Servers

Issue: By default, the Connect server logs will rotate every 7 days. In some cases this value may need to be adjusted for the administrative or security or compliance reasons:

For Connect versions 8 and 9 save a backup copy of \appserv\conf\log4j.xml and edit the MaxNumberOfDays and MinNumberOfLogs variables as appropriate for each type of log. See the example j4log.xml snippet below. As always in these cases of editing XML fileson the Connect server, save the file and test it for syntax problems by simply opening it in any browser. Cycle the Connect and FMS services to put the new settings into production. If you experience any problems then revert to the backup log4j.xml file and contact Adobe Connect support.

\appserv\conf\log4j.xml

<!– All messages go to debug.log –>

<appender File=””class=”com.macromedia.breeze.log4j.DailyRollingAndCleaningFileAppender” name=”DEBUGLOG”>

<param name=”Threshold” value=”INFO”/>

<param name=”File” value=”${application.home}/../../logs/support/debug.log”/>

<param name=”Append” value=”true”/>

<param name=”DatePattern” value=”‘.’yyyy-MM-dd-a”/>

<param name=”MaxNumberOfDays” value=”5“/>

<param name=”MinNumberOfLogs” value=”10“/>

<layout>

<param name=”ConversionPattern” value=”[%d{MM-dd HH:mm:ss}] %.25t (%p) %.2048m%n”/>

</layout>

</appender>

<!– All messages go to api.log –>

<appender File=”” class=”com.macromedia.breeze.log4j.DailyRollingAndCleaningFileAppender” name=”APILOG”>

<param name=”Threshold” value=”INFO”/>

<param name=”File” value=”${application.home}/../../logs/support/api.log”/>

<param name=”Append” value=”true”/>

<param name=”DatePattern” value=”‘.’yyyy-MM-dd-a”/>

<param name=”MaxNumberOfDays” value=”5“/>

<param name=”MinNumberOfLogs” value=”10“/>

<layout class=”org.apache.log4j.PatternLayout”>

<param name=”ConversionPattern” value=”[%d{MM-dd HH:mm:ss}] %.25t %m%n”/>

</layout>

</appender>

 

Note: For legacy Connect version, 7.x, add and adjust the values of use the following entries in the custom.ini file, save the file and  and cycle the services:

ACCESS_LOG_ROTATE_DAYS=0.25

ACCESS_LOG_ROTATE_KEEP=7

LOG_ROTATE_DAYS=0.25

LOG_ROTATE_KEEP=7

ERROR_LOG_ROTATE_DAYS=0.25

ERROR_LOG_ROTATE_KEEP=7

API_LOG_ROTATE_DAYS=0.25

API_LOG_ROTATE_KEEP=7

 

 

 

Connect Training Course does not Produce Completion Report

Issue: When a course is started and left open, perhaps while multitasking or looking up additional references, etc., it may timeout and work of the trainee in the course can be lost.

How to approach this – As with many symptoms, there is often more than one ameliorating approach; two are offered below:

One very quick way to help with  this is to increase the session time-out value in Connect

  •  At the top of the Connect Central administrative window, click Administration.
  • Click Account.
  • Click Session Settings.
  • Enter a timeout length in minutes that is long enough to cause fewer instances of timeouts.
  • Click Save.

Another way to approach this is to use Adobe Presenter 9 to create the training content. Presenter 9 handles sessions and bookmarking that is not supported in previous versions of Presenter.