Adobe Connect Server Installations with the Adobe Transmuxing Server, ACTS

This tech-note addresses on-premise Adobe Connect installations that use the optional HTML5 Standard View in the browser client option for Meeting access.

Note: This article contains illustrations. You may need to refresh your browser to render them viewable. I have noticed that Firefox has been particularly problematic with this WordPress blog.

The Adobe Connect Transmuxing Server (ACTS) is a proxy for Adobe Connect Meeting Server (AMS) that converts Meetings to HTML5 for access by a browser client. The HTML5 Standard View in the browser session is hosted from the ACTS server which pulls and converts content from the Adobe Connect AMS Meeting server.

To install the ACTS server with Adobe Connect it is often required and always prudent that it be distributed onto a separate server VM running at least Windows Server 2019. The exception to this distributed recommendation is if a single lab Adobe Connect Server has multiple IP addresses (and ideally multiple NICs) along with the necessary CPU, disc and memory resources to host all three servers on one VM platform. This is never recommended in production although it can accommodate limited load.

Note Win 2016 is no longer supported; ACTS will not run on Win 2016.

When setting up a simple Adobe Connect single test server in a lab without implementing SSL, it may be deceptive to see that with all the services installed on one VM, ACTS will work with Meetings on a server with just one IP address. Don’t be deceived by this, as soon as SSL is introduced, which is obviously required in all production environments, the server resource requirements change. Multiple VIPs are required (if offloading SSL to a load-balancing device) and multiple IPs on the server itself if stunnel is used is for encryption of the three services, AMS, CPS and ACTS.

Even when the SSL is fully offloaded to an SSL accelerator, if the pool is a single server, you cannot have only one IP on that server to support ACTS, AMS and CPS on the same server. It will not work.

One reason that ACTS will not work when collocated on a single server with Adobe Connect is the need for back-end server to server communication on unique machine-names in order to register ACTS as active in the PPS_SERVICE_HOST SQL table in the Connect database. With a single IP, there can only be a single machine-name. The registration of ACTS may appears to work when the registration API is invoked, but the ACTS server will be marked down with “X” status in SQL instead of “A” for active. A host file entry for the ACTS machine name is often needed on the Adobe Connect server to facilitate the needed back-end communication for ACTS full registration.

• API for ACTS Registration: http://localhost:8510/api/xml?action=acts-host-register&acts-host-name=acts1&external-name=acts.adobe.com
  • Where acts1 is the internal machine name and acts.adobe.com is the ACTS external FQDN
• API to list ACTS servers: http://localhost:8510/api/xml?action=acts-host-list
• healthCheck directly on server (case sensitive): http://app1:8080/healthCheck
• Entry in custom.ini for WSS: ACTS_PROTOCOL=wss:443
• ACTS update is needed; this backwards compatible 12.8 version is patched and runs on Windows 2022 and is available here: https://platinum.adobeconnect.com/acts128/default/acts.zip

A second complicating variable with a single server installation on a single IP is that the ACTS server must also communicate with the Meeting server on the external Meeting name. ACTS must interact with Adobe Connect Meetings on the back-end and on the front-end, on the internal server machine-name and on the external Meeting name parsed by clients in order to operate as a the Meeting proxy for HTML5 Standard View browser sessions.

The need for ACTS to resolve the external Meeting name may require some routing and security group configuration behind the LTM if not an additional internal VIP to facilitate the proxy connection to AMS Meeting. See the diagram here below where connectmtg.domain.com represents the external Meeting name that ACTS must resolve:

See in blue an optional an internal VIP on the LTM load balancing device. It basically is a mirror of the RTMPS external Meeting VIP except it is internal on the LTM to allow for less complex routing of ACTS to the external Meeting name. With a hosts file added to the ACTS server to resolve this internal VIP dedicated to ACTS for communication with the AMS server, it facilitates server to server communication for the proxy. I note this VIP as optional because it may not be needed; as long as the ACTS can get to the external AMS VIP, then it will serve as a proxy for HTML5 Standard View browser clients without need for the internal VIP. If ACTS cannot get out to the Meeting VIP and come back into the Connect Meeting server then the internal VIP will serve as an alternative route. It is not uncommon that an enterprise cannot change security groups, routing etc. to allow the ACTS server proxy traffic to go out and come back in through the LTM to proxy AMS traffic for conversion to HTML5 on ACTS and to give HTML5 Standard View browser clients access to Meetings on and through ACTS.

The diagram above illustrates the following flow pattern:

• LTM VIP for Meeting RTMPS traffic: 443 to a pool of 1935 on the Connect Meeting/AMS server.
• LTM VIP for Connect HTTPS traffic: 443 to a pool of 8443 for content and Connect Central.
• LTM VIP for ACTS HTTPS: 443 to a pool of 9002 for HTML5 browser proxy; port 9002 serves only web-socket requests, rest HTTP requests will get 404 response. The healthcheck for this VIP may point to 8080 as described above.
• Optional LTM VIP for the ACTS server to gain access to the external Meeting server name: 443 to a pool of 1935.
• Along with this, there is server to server traffic behind LTM on ports 1935, 443, 1000-1009, 8507, 8506 and others if considering connections to the SQL DB, LDAP, Shared storage etc.
• Note that the Meeting AMS server must be secured with SSL for the ACTS server to work. A mixture of HTTPS and RTMP traffic will not work, RTMPS must be configured.

To test the Standard View browser connection, enable the HTML client in Adobe Connect Central and append ?html-view=true to the Meeting room URL in the client or choose the continue in browser option during Meeting invocation:

Make sure the follow settings are in place in Adobe Connect Central:

Under the Administrative options In Adobe Connect Central either force Standard View or let the hosts decide:

Under Compliance options In Adobe Connect Central make sure you are not forcing the thick client:

Under the Meeting information in Adobe Connect Central allow the browser connection:

Scaling into a cluster:

When scaling the ACTS servers into a cluster with Adobe Connect, the VIP to pool structure is similar to that of the Meeting servers. Each ACTS server needs its own VIP resolving the external ACTS FQDN. A three-server Connect cluster with two ACTS servers might look like this: