Posts in Category "Application"

Monthly Maintenance Releases

Adobe Connect continues to see growth with more meeting minutes each month.   As usage grows, Adobe endeavors to be even more responsive to customer support requests and reduce issue resolution time.  To accomplish this, we’ve moved to a monthly cadence for double-dot releases (e.g. 9.5.7).  To keep you informed of these regular releases account administrators will be receiving email notifications on the updates and bugs fixes for the release and the time of each maintenance window.  Thanks for your continued and growing use of Connect.

Adobe Connect Unified Voice and Cisco Call Manager

Most Unified Voice (UV) integration is between Adobe Media Gateway (AMG/FMG) and an external Session Initiation Protocol (SIP) server as depicted in the diagram below:

Connect_FMG_Flow

In the case of Cisco Call Manager (CCM), the AMG/FMG connection is commonly internal on the Local Area Network (LAN) based rather than external on the Wide Area Network (WAN) based as depicted below:

c9sslclusterss-aem-fmg

The LAN based flow is very similar to the WAN based flow. AMG/FMG to SIP for UV is simply replaced by AMG/FMG to CCM. Port 5060 must be opened between AMG/FMG and CCM for SIP communication and rort range 5000 – 6000 must be opened for the Real-time Transport Protocol (RTP) voice packets. DTMF mode RFC 2833 must be supported by CCM as well as by its carrier.

Specific CCM integration steps:

  • Create a username and password based SIP account on CCM
  • Login into CCM and navigate to Device -> Phone -> Add new
  • Select Third Party Basic Device
  • Select SIP profile as the Standard SIP Profile
  • Select Digest User as the LDAP ID of a User X
  • Check the block for  Media Termination Point Protocol

ccm1

  • Navigate to User Management > End User
  • Search for the LDAP User ID of the SIP account
  • The user-id, LDAP User is the CCM SIP user
  • The pin is the password for the CCM-based SIP

ccm2

Configure the Connect UV SIP account settings using the username and password of the SIP account. For additional help with setting up UV in Connect see the video tutorial: Audio in Adobe Connect Meetings

Connect 9.5 Bandwidth Utilization Estimates Illustrated

Introduction:

Adobe Connect bandwidth utilization will vary based on use case. Variables such as Meeting size, Connect features employed, disposition of clients and type of Connect server hosting, all have an effect on the network bandwidth utilized and as well as on where the bandwidth on a network will be most affected.

This article focuses on bandwidth and not on latency: Latency and bandwidth are different topics that are often confused or inappropriately lumped together. Although in some cases there may be a correlation between bandwidth and latency as when exceeding available bandwidth will drive up latency, nevertheless, the relationship between them is often inappropriately overstated. Bandwidth refers to the size of the network pipe while latency refers to the speed over the network or the time it takes for the data to travel. Connect clients with excess bandwidth may still experience latency with Connect for reasons unrelated to bandwidth such as network distance, transmission errors, resource performance (server, DB or client), maintenance schedules and imposed constraints such as QoS or blocking the RTMPS protocol and thereby forcing inefficient tunneling of RTMPS encapsulated in HTTPS.

Resources:

For information on latency see the following articles:

Tunneling with RTMP encapsulated in HTTP (RTMPT) should be avoided as it causes latency

Connect Meeting RTMP VS/VIPs on Load-Balancers

Adobe Connect Database Performance and Monitoring

 Connect on VMWare – some deployment tips

Below are some references on the topic of Connect bandwidth; these are often referred to as a general guide; the examples sited later in this article however are from baseline testing described herein:

Estimating Bandwidth Consumption in Connect Meetings

Best Practices for Adobe Connect

Adobe Connect best practices for large events and seminars

VoIP Bandwidth and Microphones

The Connect Cluster:

The context of the Connect bandwidth utilization is important and should be included among pre-deployment architectural considerations when rolling out Connect. There are basically two primary Adobe Connect deployment models for consideration: In the cloud and on-premise. The disposition of the clients attending the meeting has an effect where the on the network bandwidth will be utilized for any Connect Meetings or Webinars. To support these two broad deployment paradigms of cloud or local on-premise, there are three basic Adobe Connect licensing models.

  1. Adobe Connect Multi-tenancy Hosted
  2. Adobe Connect Managed Services (ACMS) single domain hosting
  3. Adobe Connect On-Premise licensed single domain

Note: An Adobe Connect on-premise license need not only be deployed within the customer’s LAN infrastructure. Adobe Connect Partners offer Managed ISP hosting options and an on-premise license deployment can be cloud-based as well.

Cloud or LAN:

For the purposes of considering the relationship of bandwidth to architecture, an Adobe Connect cloud-based deployment and an on-premise deployment within a customer’s LAN present different concerns with reference to the disposition of bandwidth rather than with the specific license type.

Primary differences with reference to bandwidth when comparing cloud-based Connect server clusters with on-premise based Connect server architecture is with the handling of external clients and the direction of the network traffic. There will be less internal network traffic on the LAN when external users (with possible lower-impact exceptions such an SSO server) remain external. Note that VPN users in remote offices are considered internal users.

See the following diagrams comparing a 2-server cloud-based cluster with a 2-server on-premise cluster hosted on a customer LAN. Both assume the need for internal and external users to participate in Meetings.

Cloud-based:

With a cloud deployment, the external users have little or  no impact on the internal LAN of the Connect account owner. The biggest bandwidth hit is at the cloud-based hosting facility. The primary concerns for the Connect owner’s IT will be routing RTMPS around third-party proxy servers and making sure client profiles and other internal restriction, limitations and constraints do not prevent or enervate Connect usage:

two-server-cloud

LAN-based:

With a LAN-based on premise deployment, internal Connect users will normally have great performance on the average corporate back-plane by avoiding any mitigating and often unpredictable WAN variables. External users may be hosted on a reverse proxy Connect Edge server in the local DMZ to meet security requirements. All external traffic is terminated in the DMZ where the remote Edge server does all the heavy lifting. The Edge connections to the internal cluster consolidate the external connections and reduce the overall internal impact of external users by limiting them to the external firewall and DMZ:

EdgeDMZAbbrev

Connect Meeting Features and Bandwidth:

Screen-sharing and the use of multiple live web cameras are the two most bandwidth intensive activities in any Connect Meeting or Webinar. The latter requires that a Meeting Host or Presenter project the client screen up to the Connect servers and then back down to each user in the Meeting. The more users with cameras, the more upload and download activity.

The features employed in any Connect Meeting determine the amount of bandwidth utilized.  Depending on the Connect use case, you could use between 5 to 10 Mbps per 100 participants. These general rules apply:

    • The typical average is 50 kbps per user
    • It depends on what Connect Meeting users are doing
    • For example, on the high end one client measured regularly uses 20 Mbps for 150 users in a Connect Meeting room.
    • More typically there is a max of 100 Mbps at the firewall (outgoing, incoming is never that high)
    • With just over 1000 users a safe estimate is < 100kbps per user totaling 12 MB
    • 5 Mbps per 100 is the low average (or 6MB per 1000 users using best practices for large Webinars).
    • Things like video and screen sharing tend to use more bandwidth
    • A one-to-many broadcast of an uploaded PowerPoint deck uses less bandwidth
      • PPTX should always be uploaded to the Meeting room
      • Do not present a PPTX using screen-sharing as it wastes bandwidth

Bandwidth Utilization Use Case Baseline Tests:

The following tests corroborate these guidelines listed above and offer a model to test bandwidth utilization for any Meeting or Webinar use case; it is prudent to do these type of tests with your specific use Webinar case as part of your rehearsals to get accurate bandwidth utilization baselines:

First bandwidth test: I uploaded a 15.5 MB PPTX to a Connect Meeting room and advanced thru all the slides while monitoring the download stream to each client; the average for each client was 50 kilobits; see below:

4clients.fw

Second bandwidth test: I then tested with a camera pod set to the highest quality and wide screen option: Meeting>Preferences>Video; see my host camera settings below:

videopref.fw

The average download stream at each client when I had the camera pod sized small in the upper corner of the meeting while flipping slides was under 200 kbps (kilobits); The host screen capture below corroborates; my host client in the Connect addin is pushing 121 kilobits up to the server; see below:

cambndwdthtrun

The average when I expanded the camera pod and moved around create some activity on screen (waving etc.) was 300kbps download streaming to each client; see below my upload from host client to server is 381 kbps; see below (wow- my hair is getting thin):

cambndwdthlrgtrun

Third bandwidth test: I then tested screen-sharing a slide deck from my desktop to simulate application sharing live demonstrations and found a significant variance based on the screen resolution of the host sharing the screen:

  • Host screen-sharing at 1920×1080 resulted in an average  download to each participant of 700 kbps
  • Host screen-sharing at 1288×768 resulted in an average download to each participant of 200 kbps
  • The participant experience was very similar. I see no reason to waste the bandwidth on the higher host screen-resolution: Lower screen resolution resulting in very economical bandwidth utilization while sharing the screen
  • See the bandwidth indicator while I share my screen flipping through multiple jpegs at 1288×768. I am pushing up 338 kbps to the Connect server while actively changing jpeg images on a second monitor that I am sharing.

hostss1280.fw

Fourth bandwidth test: Video – I created an mp4 using the following settings: Appropriate quality settings are a major variable determining the amount of bandwidth used and the playback experience of mp4 video in Connect:

  • I used: H.264, 720×404, Frame Rate 30, bitrate CBR, target rate 1Mbps, Key Frame Dist 90.
  • Best practice encoding for video in Connect imperative: Rehearsal and testing of any Video used is prudent prior to any Meeting or Webinar. It is easy to test playback experience and bandwidth consumption per client participant. Note also here (in the highlighted bandwidth indicator) how my remote office client experiences some latency albeit manageable  (595kbps down) that not affect the video playback experience – no choppiness at all watching the pups wrestle (the Jack-Russell ends up winning although this capture shows him as the underdog):

video

Bandwidth Utilization Use Cases:

Using the baselines from these tests, here is a list of potential use cases from a recent customer inquiry with the predicted overall account-wide bandwidth usage estimates running Connect 9.5.

Case 1: A 1500 user seminar room with a PowerPoint and a desktop share:

Estimate: 1500 users x 50 kilobits each for the PPTX use case =75000 kilobits or 9MB. Add to that a desktop share with conservative screen-resolution (1280×768) 1500×200=300000 kilobits or 37MB. Add them together (75000+300000) for an average of 375000 kilobits or 47MB. Realistically it will be less at any given time because it is rare to simultaneously do both activites at once in a meeting. It is more common to share either flip PPTX slides or share an application thereby lowering the actual bandwidth utilized at any given time.

 Note: There is an important caveat with reference to an initial spike caused by the PPTX SWF download of 1000 kbps per client participant for a few seconds each. This affects every use case with SWF content is a share pod. Assuming 1/3 at a time as participants enter the layout with the PPTX on stage in a share pod even if downsized in a corner or hidden behind another pod, and assuming that there will not be any screen-sharing initially during the downloading: 1500/3 = 500x1000kbps for a few seconds each = 50000 kilobits or 62.5MB. A worst case spike scenario of all entering at once due to host error or a late upload due to last minute editing (this should be avoided if possible): 1500×1000=1500000 kilobits or187MB Spike for up to 10 seconds depending on latency effects on the initial SWF download. This spike may be missed in testing if you rely on the Meeting room bandwidth indicator as it may happen too fast to register; it is better measured using Wireshark on a client in the Meeting.

Case 2: A 1500 user seminar room with a PowerPoint and a 10 minute MP4 Video played:

Estimate: 1500 users x 50 kilobits each for the PPTX=75000 kilobits or 9MB. Assuming a medium quality MP4 (as discussed above) uploaded to the meeting room and meted out at an average 600 kbps per participant with intermittent spikes to 1200 kbps: 1500×1000=1500000 kilobits or187MB + 9 = 196MB while the video is being played with the PPTX still onstage visible in another pod. Note: Until the Video is played, this room is at 9MB just meting out PPTX SWFs after the initial SWF downloads are complete.

 Note: PPTX download spike variables as described in case # 1 above applies.

Case 3:  A 1500 user seminar room with a PowerPoint and two, 3 minute videos played:

Estimate: Same as case 2 above assuming that the videos are played one at a time.

Case 4: Two 1500 user seminars with just PPTs for content (uploaded to the Meeting room and not screen-sharing) and jpeg pictures for Presenter head-shots in lieu of a camera:

Estimate: 1500 users x 50 kilobits for the PPTX=75000 kilobits or 9MB x 2 seminar rooms = 18MB

 Note: Assuming the seminars will not start both at the same time and will nevertheless overlap, the brief PPTX download spike variables as described in case # 1 above applies albeit multiplied by two: 126 MB for 1/3rd and worst case of both seminars doing a last minute deck upload at the start of the Meeting: 274MB until initial SWF downloads complete. Staggering slightly the start of each seminar will mitigate the overall spike as will allowing users to trickle into a prepared room with assets on stage.

Case 5:  Two 1500 user seminars with just PPTs for content (uploaded to the Meeting room and not screen-sharing) and PPTs for headshots shared, PLUS 100 separate Connect meetings of 20 users each, with 10 of those meeting rooms sharing one web camera:

Estimate: 1500 users x 50 kilobits each for the PPTX=75000 kilobits or 9MB x 2 = 18MB, plus 90 meeting rooms with 20 users each doing the same activity, 1800×50 kilobits=90000 kilobits or 11MB, plus the 10 meetings with cameras added 10 x 20 users each x 200 kilobits=40000 kbps or 5MB; also add the upload for each camera 10 cameras x 200 kilobits =2000 kbps or .25MB. Total =.28000 kilobits or 35MB.

Note: Assuming the various meetings will be starting at different times the spike estimates for #4 above apply.

Case 6:  Two 1500 user seminars with just PPTs for content and PPTs for headshots shared, PLUS 100 separate Connect meetings of 20 users each, with 10 of those meeting rooms sharing one web camera, PLUS one 500 user seminar with a PowerPoint shared(uploaded to the Meeting room and not screen-sharing).

Estimate: Add 500 users x 50 kilobits each = 25000 kilobits or 4MB. Add this to use case 5 depicted above: 35MB+4=39MB.

Note: Assuming the various meetings will be starting at different times the spike estimates for use cases #4 and #5 above apply here.

Case 7: Two 1500 user seminars with just PPTs for content and PPTs for headshots shared,  PLUS 50 separate Connect meetings of 20 users each with 10 of those meeting rooms sharing one web camera, and one 500 seminar with just a PowerPoint shared (uploaded to Meeting room and not screen-sharing):

Estimate: 1500 users x 50 kilobits each  for the PPTX=75000 kilobits or 9MB x 2 = 18MB, plus 40 meeting without cameras x 20 users each=800x50kbps= 40000kbps or 5MB, add the 10 meetings with cameras 10 meetings x 20 users x 200 kilobits=40000 kbps or 5MB; also add the upload for each camera 10×200=2000 kbps or .25MB. Total= 232000 kilobits or 29MB.

 Note: Assuming the various meetings will be starting at different times the spike estimates for use case #4, #5 and #6 above apply.

Conclusion:

It is easy to avoid both overestimating and underestimating the bandwidth needed account-wide for Connect deployments on-premise or in the cloud. For large Webinars, a quick rehearsal with a small sample audience of external and internal users as appropriate is prudent. Best practices in large Meetings make a substantial difference in the amount of bandwidth utilized: Proper camera use, screen-sharing and video-encoding are all very important considerations.  Although it may at this point seem like a mantra, a basic best practice that so many Connect users miss is to upload a PowerPoint to the Meeting room share pod rather than use screen-sharing to run through a slide-deck. Maybe some Presenters are just overly possessive and have an innate refusal to let their work upload – whatever the reason, I will surely be in a Meeting today and some Presenter will share a PowerPoint from their desktop via screen-sharing and I will need to avert my eyes to maintain my light grasp on sanity. Used properly, Adobe Connect is the best means to deliver rich collaboration experiences while minimizing the impact on bandwidth utilization.

Adobe Connect 9.5.3 On-Premise Servers on Windows 2003

Note: This article applies only to Connect on-premise customers running Connect on Windows 2003 servers.

For on-premise Adobe Connect customers running Windows 2003, it is vital to upgrade the servers to at least 2008 (or higher) prior to upgrading Connect to 9.5.3. The Connect command-line converter will not run on Windows 2003 and will fail with the following error in the Connect debug logs:

CreateProcess error=193, %1 is not a valid Win32 application

The release notes for Connect 9.5.3 are here: https://helpx.adobe.com/adobe-connect/release-note/adobe-connect-9-5-3-release-notes.html

The 9.5.3 updater is here: https://helpx.adobe.com/adobe-connect/kb/connect-90-patches.html

Connect Meeting RTMP VS/VIPs on Load-Balancers

This article applies to on-premise Adobe Connect servers running behind hardware-based load-balancing devices or SSL accelerators.

A common cause of performance problems in Adobe Connect Meetings stems from the improper configuration of the Virtual Server (VS) Virtual IP Address (VIP) handling Real Time Messaging Protocol (RTMP) traffic in on-premise Connect deployments.

An Adobe Connect Meeting Server is at least two servers in one (possibly more if AEM/Events and UV telephony are incorporated); it is at least always a Tomcat-based HTTP application server and an Adobe Media Server (AMS) using RTMP. The two servers are fully integrated to work together in tandem to support Adobe Connect Meetings.

The most popular load-balancing and SSL acceleration  option in the Adobe Connect on-premise enterprise is the F5 BIG-IP Local Traffic Manager (LTM). This tech-note will illustrate the proper configuration of an RTMP VIP supporting Adobe Connect Meeting on an F5 LTM. The concepts apply to any load-balancing device and SSL accelerator.

The first thing to note is that the general configuration of a Connect server or cluster running behind an SSL accelerator or load-balancing device always requires more then one VIP. There are no exceptions to this rule and any attempts at shortcuts will result in delayed deployments and support cases. Attempts to place all traffic on a single VS/VIP are as common as they are incapacitating. General Connect cluster architecture tech-notes are here:

Adobe® Connect™ server pools/clusters and hardware-based load-balancing devices with SSL acceleration

Adobe Connect Servers and Hardware-based Load-balancing Devices

A simple diagram of an Adobe Connect server behind an F5 LTM follows; see the two VS/VIPs and Fully Qualified Domain Names (FQDNs) for each on the LTM:

C9SSL

Below we add a server to show a basic Connect cluster VIP configuration; see how each Connect Meeting server has its own VS/VIP while one VS/VIP servers both HTTPS application servers.

C9SSLa

Note: Neither of these basic diagrams depicts advanced configurations such as the integration of the Adobe Experience Manager (AEM) Events module. This article focuses on the performance of the Adobe Connect Meeting RTMP VIP in its basic context.

There is usually not an option for RTMP in the VIP profile of a hardware-based load-balancing device. A basic TCP profile is the correct choice. Here it is depicted on an F5 BIP-IP LTM:

f5.fw

With detail:

f5a.fw

f5b.fw

f5c.fw

Note that the symptom for an improperly configured VS/VIP is either the inability to launch a Connect Meeting or excessive latency in the Meeting due to RTMP tunneling (RTMPT) encapsulated within HTTP when the RTMP VIP is blocked or inoperable.

The presence of a capitol “T” in the latency indicator of an Adobe Connect Meeting indicates tunneling as depicted in this tech-note:

Tunneling with RTMP encapsulated in HTTP (RTMPT) should be avoided as it causes latency

Further diagnosis is usually warranted by using the Connect Meeting Addin in logging mode as depicted here:

Enable Logging in the Meeting Addin

Also here:

Troubleshooting Verbose Meeting Addin Logging

When the RTMP VS/VIP profile is improperly configured, the Connect Meeting addin verbose log will show it clearly, particularly when it is compared with the server-side debug log.

Example snippet from a Connect Meeting addin verbose log:

18:51:55    16844    PLAYER_TRACE    SSL connection closed.
18:51:55    16844    PLAYER_TRACE    SSL DoSSLHandshake WaitHandshake not in ssl_active state. (State is 0.) Failing.
18:51:55    16844    PLAYER_TRACE    SSL DoSSLHandshake WaitForSocket not in ssl_active state, failing.
18:51:55    16844    PLAYER_TRACE    SSL Receive socket read error 0x0.
18:51:55    16844    ACTION_TRACE    5/10/2016 14:51:55.101 [DEBUG] breezeLive.main.FCSConnector [attempt 1 of 60] Trying fallback tunneling connection rtmps://onlinemeeting.connectexample.com:443/?rtmp://localhost:8506/meetingas3app/7/1234567/
18:51:55    17179    PLAYER_TRACE    NetConnectionIO::DoConnect rtmps protocol, HTTP(S) tunneling, tunnel open succeeded.

The corresponding snippet in the server debug log as well as the application logs will read: RTMPT and often reconnect=true:

               Line 23456: 2016-01-17  14:25:06              32260    (s)2641173          Asc-Room               IA_CONNECT      [dID:32, ticket:123456789xyz, phase:, uID:, name:]             New client connecting:  { ip=127.0.0.1, protocol=rtmpt, player=MAC 11,9,971,247, savedConnectionSpeed=undefined, reconnect=true }                        –

[11-05 15:08:05] FCSj_Worker:18 (INFO) params: {bytesdown=0, protocol=rtmpt, ticket=123456789xyz, status=C, reconnect=true, nickname=John Doe, action=register-client, role=v, bytesup=0, session-timeout=12}

Correct configuration of the RTMP VS/VIP is extremely important; a Connect Meeting VS/VIP must have a dedicated FQDN.  It must have its own SSL certificate if SSL is accelerated through the load-balancing device and the VS/VIP must not have an HTTP profile; a TCP profile is needed.

For some additional information about troubleshooting Connect architecture with reference to hardware-based load-balancing devises and SSL accelerators, see the following tech-notes:

The Adobe Connect Deployment Guide on the F5 Website needs Updating

Configuring application-level health monitors for Connect on BIG-IP Local Traffic Manager

Publishing PowerPoint Presentations in Connect Meetings

There are different techniques that a Connect content author or Connect Meeting Host may employ to publish PowerPoint content in Adobe Connect Meetings. This article discusses them and how they differ and how to choose the correct option and avoid common pitfalls. The four basic techniques are:

  • Direct upload or drag and drop into a Connect Share Pod
  • Upload to the Connect Content Library and then link to the Meeting Share Pod
  • Publish to the Connect Content Library using Adobe Presenter and then link to the Meeting Share Pod
  • Publish locally using Presenter to a zip package and upload to Connect

I will summarize each of these and then compare them and offer some tips to help make sure that the published converted SWF closely matches the original PPTX.

The first and perhaps most commonly used option by Meeting Hosts is to upload a PPTX directly to a Meeting room Share Pod. The ease and simplicity of this approach certainly accounts for its popularity: You can simply drag and drop a PPTX presentation into the Share Pod or navigate to the source PPTX and upload it.

pptxa.fw

pptxb.fw

Drag and drop is pictured above. As the PPTX is dropped into the Share Pod from the local client, the boarder around the Share Pod will appear with a yellow highlight.

pptx3.fw

File conversion begins as soon as you drop the file into the Share Pod.

pptx5.fw

The PPTX is converted and ready for viewing as shown above.

pptx.fw

You may also browse to the PPTX file locally from the Share Pod menu drop-down: As a Connect Meeting Host or Presenter, click the down arrow in a Connect Meeting Share Pod and choose “Share Document” as shown above.

pptx1.fw

Choose “Browse My Computer” (We will discuss content in the shared library anon).

pptx2.fw

Browse to the PPTX locally and select it.

pptx3.fw

The size of the file and bandwidth available will determine the amount of time it takes to upload.

pptx4.fw

Likewise with conversion.

pptx5.fw

The PPTX is converted and ready for viewing.

 

Uploading to the Content library is also a common method of Publishing a PowerPoint to Connect. This technique provides a URL for on-demand playback of a the PPTX as well as a single source for use in multiple Connect Meeting rooms. Multiple Connect Meeting rooms may share a presentation from the same source in the Content Library thereby simplifying editing and version control.

pptx6.fw

Browse to the Content Library in Connect Central and choose “New Content” as shown above. Note that a Meeting Host will have access to “My Connect” by default but may need to request access to “Shared Content” and “User Content” folders depending on prior account-wide administrative permissions set.

pptx7.fw

Browse to the desired PPTX on your client or share.

pptx8.fw

Select the desired PPTX upload.

pptx9.fw

Name the Presentation in Connect Central, create a custom URL and summarize the content for administrative reference if desired.

pptx10.fw

There will be a delay while the content is processed; see the spinning wheel in the upper left.

pptx11.fw

Once completed, the active URL and summary will be displayed.

pptx12.fw

To use the Presentation uploaded to the Content Library in a Connect Meeting, simply point the share pod to the Content Library and link it to the meeting.

pptx5.fw

It will appear instantaneously in the Connect Meeting as it is already uploaded to the Connect server.

 

The third means of uploading a presentation to Connect employs Adobe Presenter. This is the richest and most accurate PowerPoint conversion option. Presenter integrates with Connect, in fact, Connect had its start as Presenter: Presidia and Breeze 3.0 were originally based on PowerPoint on-demand content publishing to SWF. The integration of Flash Communication Server in Breeze 3.0.8 led eventually to the current Adobe Media Server and the Tomcat Application server platform along with such feature rich integration as Adobe Media Gateway for telephony and Adobe Experience Manager for Events management. Presenter has a long history and it is a very rich on-demand learning tool: http://www.adobe.com/products/presenter.html

pptx14.fw

Once installed, Presenter appears as a menu option in PowerPoint and you can drive publishing to Connect in a number of ways.

pptx28a.fw

pptx15.fw

Out of necessity, here I will be intentionally terse and ignore a plethora of Presenter features and focus only on using Presenter to publish PowerPoint content for use in a Connect Meeting. The dialog above is under Adobe Presenter>Presentation menu items in PowerPoint with Adobe Presenter installed.

pptx16.fw

The dialog above shows Presenter publishing options, among them is Adobe Connect which pushes the published Presentation to the Adobe Connect Content Library. Presenter is able to publish to any Connect server to which the author has access and permissions by its domain name.

pptx17.fw

Presenter launches a browser to log into the Connect Central Content Library.

pptx10.fw

By default Presenter will log into the Connect Central “My Content” folder belonging to the Presenter Author.

pptx19.fw

Fill in the customer URL option if desired and the summary fields.

pptx21.fw

Publishing may take a few minutes depending on the size of the PPTX file.

pptx22.fw

pptx23.fw

Once complete the active URL is available along with the summary.

pptx25.fw

It is now available as on-demand content and can be used from the Content Library in a Connect Meeting.

pptx26.fw

From the Connect Meeting room, choose the Share Pod drop down option and browse to the Content Library. Here I am using the “My Content” folder as the repository.

pptx27.fw

The published presentation is available in the Connect Meeting Share Pod.

 

The fourth method of publishing a PPTX to Connect is to first publish locally as a zip package using Presenter and then upload it to Connect.

pptx28a.fw

pptx15.fw

pptx28.fw

Within PowerPoint under Adobe Presenter >Presentation, choose “Publish” and set the publishing options to “My Computer” and the Output options to “Zip package”. Click “Publish”.

pptx29.fw

The conversion process may take a few minutes.

pptx30.fw

By default it will publish the zip package to: \Documents\My Adobe Presentations\

pptx31.fw

In the Connect Central Content Library, choose New Content.

pptx32.fw

See that among the supported upload file types, a zip package is listed.

pptx33.fw

Browse to the locally published zip package; in this case it is: \Documents\My Adobe Presentations\Large\Large.zip

pptx34.fw

Add the details in the Connect Central Content Library and click Save to begin the upload.

pptx35.fw

The published active URL allows access to the on-demand Presentation.

pptx35a.fw

pptx25.fw

In the Meeting Share Pod the Presentation is accessible from the Content Library.

You may also directly upload the Presenter published zip package from the author’s client to the Connect Meeting Share Pod and ignore the Content Library as shown below:

pptx35b.fw

pptx36.fw

pptx25.fw

The presentation is available for use in the Connect Meeting Share Pod.

 

Choosing the best presentation publishing option:

Once the PowerPoint presentation is selected, converted, and uploaded by whichever means, it is prudent to review it to check for any delta between the uploaded content and the original PPTX. Deltas are usually in one of two forms:

  • Select fonts do not match
  • Tables or bullet formatting does not line up as expected

With reference to custom fonts such as certain esoteric mathematical symbols, this article may help: Tips on Mitigating Connect Server-side PowerPoint Publishing Deltas

Using Adobe Presenter to publish, effectively eliminates any font discrepancies as all publishing is done on the author’s client where presumably all fonts are installed and are available to facilitate accurate conversion.

When uploading a PPTX to the Connect Central Content Library without Presenter, a Connect server-side version of Presenter, called Producer, facilitates the conversion process invoking the fonts available server side. If a font is used in the PPTX that is not available on the server, Producer will choose the closest font available on the Connect server to the original font.

Note: Adobe Connect hosted and ACMS customers who wish to have proprietary fonts installed on their Connect accounts  should contact the Connect Support Team to discuss the process.

When uploading a PPTX directly to a Connect Meeting room Share Pod, server-side Producer is not invoked. The client-side is leveraged and Microsoft Office should be installed on the client as PowerPoint client-side helps facilitate the conversion.

This warning message may appear when uploading a PPTX to Connect:

pptx42.fw

This warning is most common when Mac users who do not have Microsoft Office installed on their clients, attempt to upload a PPTX directly to an Adobe Connect Meeting room. There are not any client-side assets to facilitate conversion.

This tech-note is relevant: Best Practices for Sharing PPTX Files on Adobe Connect

With specific reference to portions of tables missing from graphs, often this can be mitigated by saving a PPTX as  PPT and re-uploading it to Connect.

A PPTX may also be locked down and further editing prohibited. This will affect conversion of the PPTX because conversion to SWF in Connect is a form of editing.

pptx37.fw

pptx38.fw

pptx41.fw

PowerPoint menu options to Protect the Presentation prior to uploading may cause a delta in the converted uploaded Presentation.

 

Conclusion:

The surest way to have the richest and most accurate PPTX to SWF conversion is by using Adobe Presenter on the author’s client. The next most accurate is to upload to the Connect Content library and invoke server-side Producer for conversion. The quickest way is to simply upload directly to the Meeting Share pod but be sure to have Microsoft Office  installed on the client to help mitigate any delta. Be sure to upload and test well in advance of the Adobe Connect Meeting.

9.5 Connect Edge Proxy Server Full Installer

The new 9.5 Connect Edge Proxy Server full installation procedure follows.

Note: This article applies to on-premise Connect customers who have purchased Edge Proxy servers and must install or upgrade to Connect version 9.5. The only possible exception to on-premise exclusivity may be for those who are hosted by a managed ISP that supports external Enterprise Proxy Edge Servers (this latter model is uncommon).

Step 1: Download the Connect Edge Server installer from the URL location provided by the Adobe Connect Support or Customer Service team;  extract and install it with local administrative permissions.

edgeintro.fw

edgeextract.fw

The first installation screen option allows language selection among the following:  English, French, German and Japanese. Click OK to proceed or x (in the upper right) to quit.

edge1a.fw

Step 2 displays the Welcome window in your selected language. Click ‘Next’ to proceed or ‘Quit’ to exit.

edge2a.fw

Note: If you have a previous version installed, this pop-up message will display:

edge2a.fw

Step 3 displays the License Agreement: The administrator conducting the installation must accept the agreement to proceed. Click ‘Previous’ to go to the previous panel, ‘Next’ to proceed or ‘Quit’ to exit.

edge3a.fw

Step 4 displays the option to Select Destination: This panel offers a browse button and facilitates choosing an installation directory. Choose the installation destination, click ‘Previous’ to go to the previous panel, ‘Next’ to proceed or ‘Quit’ to exit.

edge4a.fw

Note: If the destination directory for the installation selected in this panel already exists then the below warning will appear. Click ‘Yes’ to continue or ‘No’ to quit.

edge5a.fw

Note: If the target directory does not exist, this screen will display:

edge2b.fw

Step 5 presents Shortcut Creation options: This screen will facilitate creating the shortcuts in the Start menu. Click ‘Previous’ to go to the previous panel, ‘Next’ to proceed or ‘Quit’ to exit.

edge6a.fw

Step 6 presents a Summary: Click ‘Previous’ to go to the previous panel, ‘Next’ to proceed or ‘Quit’ to exit.

edge7a.fw

edge7a.fw

Step 7 presents a progress screen: This will occur when the installation starts. The installer will extract the files and will try to take a backup of any previous installation. During this panel a command prompt will occur if there were initially any edge services installed. It will create a backup in the same location where it originally existed, but will append “_backup” in the directory name. Wait for the processes to complete.

Note: A clean installation is highly recommended rather than any attempt at installing over older versions of the Edge.

edge8a.fw

After the processes are completed, click Next to proceed:

edge9a.fw

Step 8 offers a GUI, Edge Server Setup Configuration: This panel writes the Edge Server FQDN, the Connect server FQDN, the Cluster ID and the server ports into the Edge server configuration.

edge10b.fw

Example entries follow based on the sample deployment diagram below:

Edge Server Hostname: edge.company.com
Connect Server Hostname: connect.company.com
Edge cluster ID: edge.dmz-edge
Connect Server Normal Port: 80
Connect Server Secure Port: 443

 

95EdgeDMZstunnelOriginstunnel

Step 9 presents the Finish Panel: The installation has completed. Click ‘Done’ to finish the installation:

edge11a.fw

Post installation, the Edge config.ini file, based on our example will contain these relevant entries:

FCS_EDGE_HOST=edge.company.com
FCS_EDGE_REGISTER_HOST=connect.company.com
FCS_EDGE_CLUSTER_ID=edge.dmz-edge=1
FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=connect.company.com:80
FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=connect.company.com:443

Note: Prior versions of the Connect Edge often employed (although never required) a custom.ini file in the Connect Edge server installation root directory for these entries. The custom.ini would then override the config.ini file in the \conf directory. Placing a custom.ini in the root installation directory is still an option as well as a hazard should one contain stale or wrong entries. The new Edge installer writes directly to config.in through the screen illustrated in step 8.

Once the Connect Edge Server is installed, it must be registered with the origin server or cluster for which it serves as proxy:

On the origin server, register the Edge server by adding the Edge server unique name into the host mappings section of the Connect Management Console; the settings will propagate throughout an origin server cluster from any one of the origin servers:

Start > Programs > Adobe Connect Server > Configure Adobe Connect Server

If the Edge is communicating with the origin server, then you will see a preregistration configuration under the server settings tab:

edgereg1.fw

Add the same unique Edge name into the host mapping fields as follows to register the Edge; this is a manual security mechanism to prevent unauthorized pirate Edge server registration:

edgereg2.fw

Note: The common identification variable in the custom.ini on the origin and the config.ini on the Edge is the cluster ID; following our example is dmz-edge=1 indication the first zone by name; add this to the custom.ini file on the origin(s).

Note: Even a single Edge server warrants its own cluster ID.

edge.dmz-edge=1

For additional information on Edge server deployments including maintenance and troubleshooting, see the articles on the Connect Users Community. Note that the custom.ini file is used in these articles to configure the Edge by overriding the config.ini. As aforementioned, while the new 9.5 installer writes directly to the config.ini, the custom.ini, when used as described will override the config.ini.

The first tutorial listed below discusses the reverse proxy use of the Edge and the second discusses the enterprise proxy use:

Adobe Connect Edge Server Deployment Options: part 1
Adobe Connect Edge Server Deployment Options: part 2

Generating Server-side Logs to Troubleshoot On-premise Connect Deployments

In order to diagnose unexpected behavior within Adobe Connect, it may be necessary for the Adobe Connect Support team to examine server-side logs from an on-premise Connect deployment. The logs directory is located in the Connect (or Breeze – it is not uncommon for Connect upgrades to reside in legacy Breeze directories) directory:

logsdir.fw

Within the logs directory there are sub-directories containing various logs:

logsdir1.fw

The most commonly requested log by the support team, is the debug.log. It can be found in the logs>support directory. With the services running, the current debug log will appear without a date at the top of the debug.log file list. The default rollover is 12 hours generating AM and PM logs each day:

logsdir2.fw

In order to make the debug.log file more useful for purposes of diagnosis, you can enable verbose logging by adding entries to the custom.ini file located in the Connect or Breeze version sub-directory. Here you see it located in a 9.3.1 directory under the Breeze root installation/upgrade directory:

logscustomini3.fw

Before editing the custom.ini file, be sure to create a backup copy of it. Add the following lines in order to enable verbose logging:

HTTP_TRACE=true
DB_LOG_ALL_QUERIES=true

Note that for versions of Connect 9.2 and prior, use yes instead of true:

HTTP_TRACE=yes
DB_LOG_ALL_QUERIES=yes

Save the custom.ini file (be careful not to accidentally change the file type to .txt) and during a scheduled maintenance window, cycle the Connect and AMS/FMS services in order to load the changes and begin verbose logging (note this will bring Connect down while the services cycle):

logssvcs4.fw

There are occasions when it may be prudent to provide more than one log for a more complete diagnosis. To provide a full sample of the various Connect logs without sending a massive historical sample of log files, you may simply stop the Connect services (during scheduled downtime as this will bring down Connect) and rename the entire log directory to log.old. Then upon starting the services back up, recreate the issue being diagnosed and then stop the services.

This activity will generate a new small log directory isolating the issue under scrutiny that you just reproduced in Connect: Zip/compress this new abbreviated log directory with all its fresh abbreviated sub-directories and provide it to the the Adobe Connect Support team to help expedite more exhaustive server-side log analysis. This option is particularly helpful when examining a cluster as each server will have a set of logs. When providing cluster logs, always label each compressed log folder to easily identify the server from which it came.

Note that often when diagnosing unexpected behavior in Adobe Connect Meetings, it may also be prudent to enable client-side Connect addin verbose logging as well.  The relevant client-side logging tech-notes are here:

Enable logging | Meeting Add-in

Troubleshooting Verbose Meeting Addin Logging

SQL Update Warning Message in 9.5.2 Patch can be Safely Ignored

While applying the SQL update in the 9.5.2 patch,  you might encounter a warning message as depicted below:

sql3

This is a general message and can be safely ignored while applying the patch. It is not expected to cause any unexpected inconsistencies in the environment later although full function testing is always prudent after and updates.

Here is the SQL update file that is used in the 9.5.2 patch for your reference :

sql2

Environment :  Adobe Connect Licensed Upgrade

 

New Adobe Connect Support Blog Subscription Option

Now you can stay on top of the new articles and posts by subscribing to the Adobe Connect Support Blog. Simply go to the Adobe Connect Support Blog home page and enter your email address and check off the categories about which you would like to be notified. Click “Subscribe me” and you will begin receiving  regular updates:

subscribe.fw