Adobe Connect Support Blog

Adobe Connect Edge Server Deployment On-premise

Introduction:

There are two errors concerning the deployment of Adobe Connect Edge servers on-premise; the first is to attempt to inappropriately deploy them where they will not add value and the second is not to consider them as an option in those cases where they may be beneficial. The purpose of this article is to describe the limitations and uses of Adobe Connect Edge servers and how to best deploy them when appropriate.

There are five sections to the article. The first three sections discuss reverse proxy deployments and the fourth discusses enterprise proxy deployments and the fifth section describes additional deployment considerations and offers tips on troubleshooting common configuration problems.

The difference between reverse proxy and enterprise proxy Adobe Connect Edge deployments is that the former assumes a need to split external traffic from internal traffic bound for the same Adobe Connect Meetings, while the latter assumes a need to reduce round-trip time or network distance for remote concentrations of internal clients by consolidating connection streams to mitigate bandwidth consumption.

Edge servers are only an option for a subset of Adobe Connect on-premise server deployments. Adobe Connect hosted and Adobe Connect Managed services do not use Adobe Connect Edge servers (one reason is that in the cloud, there is no need for a reverse proxy for split traffic accommodation). For details on mitigating the effects of latency for cloud-based deployments see the following tech-note: https://blogs.adobe.com/connectsupport/network-distance-and-adobe-connect-meeting-latency/

The first three sections focus on reverse proxy deployments and are written in the order of recommended on-premise options:

  • The first suggests hardware-based load-balancing and SSL acceleration as the all-around best practice:
    • Both the internal Adobe Connect cluster and the external Adobe Connect Edge cluster use hardware in this model.
    • This is the most robust of the three models, but it requires more resources than the other two options.
  • The second employs stunnel on a reverse proxy Edge while employing SSL acceleration and hardware-based load-balancing for the internal clients.
    • This second option is a popular way to save on resources.
    • In those cases where the preponderance of Connect end-users is internal and where less external traffic is needed for a smaller population of external end-users.
  • The third reverse proxy option is for a small population of end users both internal and external who do not require redundancy.
    • It employs stunnel for SSL on a single reverse proxy Edge and a single Connect origin/application server.
    • This option offers no redundancy.

Section four addresses Adobe Connect Edge servers in an enterprise proxy configuration. An internal concentration of end users in a remote office with limited bandwidth to a home office may warrant enterprise proxy deployments. These Edge servers would not only consolidate connections, but also limit the network distance traveled by individual clients in a remote office by caching the meeting or on-demand content close to the concentration of remote users.

  • By acting as clients to the Connect origin/application cluster, enterprise proxy mode consolidates traffic between offices and mitigates bandwidth usage.
  • 100 participants in a remote office who are in a single meeting will produce one connection between an Edge and its origin/application cluster rather than 100 individual connections.
  • Under certain circumstances discussed in this article, an enterprise proxy Edge deployment could result in some economizing of bandwidth between or among office locations.

Section five addresses common configuration problems and troubleshooting tips.

All sections are example-based with detailed diagrams depicting each deployment model. Each example diagram is extensively described in outline form to serve as a clear and concise checklist to assist with both planning and deployment.

Caveats:

Requirements:

  • Adobe Connect server or cluster with which to integrate an Edge server or an Edge server cluster
  • Adobe Connect Edge server licenses
  • Familiarity with SSL, networking and load-balancing
  • Reason to deploy an Adobe Connect Edge proxy on-premise; the two basic reasons are:
    • to allow external access to an internal Adobe Connect deployment through a DMZ
    • to consolidate the connections of a geographically distributed remote concentration of internal Adobe Connect participants or trainees

Prerequisite knowledge:

If you installed your Adobe Connect on-premise deployment, then adding Edge proxies will not be difficult. You will need some savvy with DNS, routing and SSL.  Use this tutorial along with the primary installation documentation: https://helpx.adobe.com/adobe-connect/installconfigure/topics.html

Table of Contents:

Section 1: Connect Edge cluster with hardware-based load-balancing and SSL acceleration

Section 2 Single reverse proxy Connect Edges deployment combining stunnel and hardware-based SSL acceleration

Section 3 Single reverse proxy Connect Edge deployment using stunnel for SSL

Section 4 Enterprise proxy Connect Edge deployment considerations

Section 5 Additional Connect Edge deployment consideration

 

Section 1: Connect Edge cluster with hardware-based load-balancing and SSL acceleration:

A redundant model for reverse-proxy Adobe Connect Edge server deployment with SSL acceleration and hardware-based load-balancing is depicted here:

1. Rather than immediately discussing the reverse proxy Adobe Connect Edge servers in the upper left corner of the diagram above, let’s review the diagram beginning in the center at the Adobe Connect on-premise origin/application server cluster and BIG-IP Local Traffic Manager (LTM). Notice that all internal clients are hosted directly on this cluster.

a. The HTTPS traffic goes through a virtual IP address (VIP) on the LTM and is distributed via a round-robin algorithm without any session-awareness or sticky load-balancing options on the LTM.

i. This may seem odd with reference to HTTPS.
ii. In most cases, SSL accelerated server pools require session-awareness on the load-balancing device, not so with Connect.

b. To login, internal Connect users resolve to 192.167.21.75, connect.company.com, on either 80 or 443.

i. If a client inadvertently connects via HTTP on 80, LTM can redirect them to 443.
ii. The IP address of the VIP cannot be used directly in the browser URL; you must use a fully qualified domain name, following our example, connect.company.com

2. LTM will use the round-robin algorithm to channel the client session to one of the two Connect origin/application servers in the Connect server pool to allow the client to log in:

a. Following our example: 192.167.21.75:443,80 connect.company.com – round-robin non-session-aware pool= 192.166.22.176:8443, 192.166.22.177:8443
b. The Connect server pool listens on 8443 for unencrypted traffic from the LTM – everything in front of LTM is encrypted and everything behind LTM is unencrypted

3. When the internal user chooses to enter a Connect meeting room, the real time management protocol is securely invoked (RTMPS). RTMPS is encrypted at separate VIPs on the LTM: 192.167.21.76:443 connectmtg01.company.com and 192.167.21.77:443 connectmtg02.company.com

a.Following our example: 192.167.21.76:443, connectmtg01.company.com – pool= to 192.166.22.176:1935
b. Following our example: 192.167.21.77:443 connectmtg02.company.com – pool= to 192.166.22.177:1935
c. Each individual Connect server has a built-in Flash Media Server that listens on 1935 for unencrypted traffic from the LTM – as with HTTPS, for RTMPS, everything in front of LTM is encrypted and everything behind LTM is unencrypted
d. Each RTMP VIP, whether listening on 443, 1935 or 8506, should not have an HTTP profile on any hardware-based load-balancing device. RTMP is a streaming protocol and an HTTP profile can interfere with functionality; use a TCP profile. On F5 BIG-IP, LTM, also make sure the OneConnectProfile is enabled and Nagle’s Algorithm disabled.
e. For more details on RTMPS VIPs, see the following tech-note: https://blogs.adobe.com/connectsupport/connect-meeting-rtmp-vsvips-on-load-balancers/

4. You will notice that each Connect server is listening on port 8507: This is for server to server communication among the Connect servers themselves. For more information on server to server traffic, see the following tech-note: http://blogs.adobe.com/connectsupport/make-certain-that-content-is-replicated-across-all-servers-in-a-connect-cluster/

5. This document is best used a supplement to the installation documentation for Connect origin/application servers; here you will see that there are specific configuration files referenced and shown with portions edited to support the example configuration in the diagram:

a. The custom.ini file, located in the root Connect directory on each origin/application server must contain the following to support the SSL accelerator and Connect fail-over:

#SSL SETTINGS IN ORIGIN CUSTOM.INI
ADMIN_PROTOCOL=https://
SSL_ONLY=yes
RTMP_SEQUENCE=rtmps://external-host:443/?rtmp://localhost:8506/
#For Cluster fail-over add the following
MEETING_TIMEOUT=0
MEETING_CONNECT_BACK_TIME=1
#Make sure that the admin host name reflects the Connect URL rather than the server machine name
ADMIN_HOST=connect.adobe.com

b. The custom.ini file on each Adobe Connect origin/application server must also contain the following to properly identify the Edge servers that will register with the origin/application cluster; this variable will match the cluster ID in the Edge server custom.ini: FCS_EDGE_CLUSTER_ID=dmz-edge

# EDGE SERVER SETTINGS IN ORIGIN CUSTOM.INI
edge.dmz-edge=1

c. The server.xml file, located in the \appserv\conf directory, must have the following sections uncommented to support the SSL accelerator:

namePrefix=”https-8443-”
maxThreads=”350″
minSpareThreads=”25″/>

enableLookups=”false”
acceptCount=”250″
connectionTimeout=”20000″
SSLEnabled=”false”
scheme=”https”
secure=”true”
proxyPort=”443″
URIEncoding=”utf-8″/>

Note: the following tech-note has helpful details about SSL configuration: https://blogs.adobe.com/connectsupport/adobe-connect-ssl-guide/

d. Name resolution among the servers can be problematic. It is prudent to put the following hosts file on each origin/application server: \%systemroot%\system32\drivers\etc. Note that the text editor must be run with administrator privileges:

192.168.22.32 edge01.company.com
192.168.22.33 edge02.company.com
192.167.21.76 connectmtg01.company.com
192.167.21.77 connectmtg02.company.com
192.167.21.75 connect.company.com

6. There are two other VIPs depicted on the internal LTM. These are to support the registration and caching communication between the reverse proxy Edge servers and the origin/application servers.

a. Following our example, this connection is for the Edge servers to register with the origin/application servers: the reason we use a separate VIP is to avoid the encryption rules of the HTTPS VIP which listens on 80 for end users (who may forget the “S” their HTTPS URL) and reroutes them to 443:

192.167.21.78:80 – round-robin non-session-aware pool = 192.166.22.176:80,192.166.22.177:80

b. Following our example, this next connection is for the Edge servers in the DMZ to cache content from the origin/application servers; the reason these are separate VIPs is to avoid the RTMPS internal user encryption rules:

192.167.21.76:8506 -connectmtg01.company.com – pool= 192.166.22.176:8506
192.167.21.77:8506 -connectmtg02.company.com – pool= 192.166.22.177:8506

7. By looking in detail at the origin/application cluster and the LTM, we have seen how the connections from the Edge servers look. Let’s now look directly at the Edge cluster itself beginning with the external users:

a. To login, external Connect users resolve to 216.104.214.168, connect.company.com, on either 80 or 443.

i. If a client inadvertently connects via HTTP on 80, LTM can redirect them to 443.
ii. The IP address of the VIP cannot be used directly in the browser URL; you must use a fully qualified domain name, following our example, connect.company.com

8. LTM will use the round-robin algorithm to channel the client session to one of the two Connect Edge servers in the Connect server pool to allow the client to log in:

a. Following our example: 216.104.214.168:443,80 connect.company.com – round-robin non-session-aware pool= 192.168.22.30:8443, 192.168.22.31:8443
b. The Connect Edge server pool listens on 8443 for unencrypted traffic from the LTM – everything in front of LTM is encrypted and everything behind LTM is unencrypted

9. When the external user chooses to enter a Connect meeting room, the real time management protocol is securely invoked (RTMPS). RTMPS is encrypted at separate VIPs on the LTM: 216.104.214.136:443 edge01.company.com and 216.104.214.137:443 edge02.company.com

a. Following our example: 216.104.214.136:443, edge01.company.com – pool= 192.168.22.32:1935
b. Following our example: 216.104.214.137:443 edge02.company.com – pool= 192.168.22.33:1935

10. This document is best used a supplement to the installation documentation for Connect Edge servers; you will see that here there are specific configuration files referenced and shown in their edited form to support the example configuration in the diagram:

a. Following our example, the custom.ini file in each Edge server root installation directory must contain the following to support the Edge server connection with the Connect origin/application servers:

#Edge01 custom.ini
FCS_EDGE_HOST=edge01.company.com
FCS_EDGE_REGISTER_HOST=192.167.21.78:8443
#FCS_EDGE_REGISTER_HOST= registerconnect.company.com
FCS_EDGE_CLUSTER_ID=dmz-edge
FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=connect.company.com:80
#FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=192.167.21.75:80
FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=connect.company.com:443
#FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=192.167.21.75:443
FCS_EDGE_EXPIRY_TIME=60000
FCS_EDGE_REG_INTERVAL=30000
#DEFAULT_FCS_HOSTPORT=:1935,80,-443

#Edge02 custom.ini
FCS_EDGE_HOST=edge02.company.com
FCS_EDGE_REGISTER_HOST=192.167.21.78:8443
#FCS_EDGE_REGISTER_HOST= registerconnect.company.com
FCS_EDGE_CLUSTER_ID=dmz-edge
FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=connect.company.com:80
#FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=192.167.21.75:80
FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=connect.company.com:443
#FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=192.167.21.75:443
FCS_EDGE_EXPIRY_TIME=60000
FCS_EDGE_REG_INTERVAL=30000
#DEFAULT_FCS_HOSTPORT=:1935,80,-443

b. Following our example, the HttpCache.xml file, located in [root_install_dir]\edgeserver\win32\conf\ on each Edge server root installation directory must contain the proper host-name tag to support the Edge server connection with the Connect origin/application servers. Note that by putting the FCS_EDGE_HOST variable in the HttpCache.xml file under the host-name tag, you are pointing to the custom.ini variable noted above; following our example, instead of using this variable, you may use the individual unique Edge server names: edge01.company.com on the first and edge02.company.com on the second. The key is to designate the unique, fully qualified Edge server name:

i. Using the variable from the custom.ini on both Edge servers (recommended):

${FCS_EDGE_HOST}

ii. Using the unique name on edge01 (optional approach):

edge01.company.com

iii. Using the unique name on edge02 (optional approach):

edge02.company.com

c. In the DMZ, name resolution with reference to the Edge servers will be problematic. Use a hosts file on each Edge server to make certain that it resolves names properly: \%systemroot%\system32\drivers\etc. Note that with 2008 (or a Windows 7 client), the text editor must be run with administrator privileges; following our example, the host file on each Edge would contain:

192.168.22.32 edge01.company.com
192.168.22.33 edge02.company.com
192.167.21.76 connectmtg01.company.com
192.167.21.77 connectmtg02.company.com
192.167.21.75 connect.company.com

d. The Edge server will need a maintenance script to clear old cache and keep them fresh; run the following .bat file as a scheduled task on each Connect Edge server; feel free to edit this file to reduce or prolong the ping-induced delays. The key is to allow enough time between each command for services to stop and start. Different servers respond differently, some requiring more time and some less time. By stopping the services, it unlocks the cache for thorough deletion:

@ECHO OFF
REM ——CONNECT SERVICE AUTOMATIC CYCLING—————
REM
REM This batch file stops and starts Connect and AMS
REM
REM ————————————————————
@ECHO ON
net stop amsadmin
ping 1.1.1.1 -n 1 -w 10000>nul
net stop ams
ping 1.1.1.1 -n 1 -w 200000>nul
del /Q /S d:\breeze\edgeserver\win32\cache\http\*.*
ping 1.1.1.1 -n 1 -w 10000>nul
net start ams
ping 1.1.1.1 -n 1 -w 10000>nul
net start amsadmin
@ECHO OFF

Note: This script is not needed after the NGINX workaround is implemented: http://blogs.adobe.com/connectsupport/remote-edge-server-intermittently-hangs-or-freezes/

e. Register the Edges with the Connect origin/application servers by adding the Edge server unique names into the host mappings section of the Application Management Console on either of the Connect origin/application; the settings will propagate throughout the origin/application cluster from either of the origin/application servers:

i. Start > Programs > Adobe Connect Server > Configure Connect Enterprise Server

1. If the Edge is communicating with the origin/application servers, then you will see them in a pre-registration configuration under the server settings tab:

2. Add the same unique Edge names into the host mapping fields as follows to register the Edges; this is a security mechanism to prevent rouge Edge registration:

Note: The common identification variable in each custom.ini is the cluster ID; following our example: dmz-edge. If you had multiple zones, then you would have multiple cluster IDs. We will address this when we discuss Enterprise proxy Edge servers. Generally, with reverse proxy Connect Edge servers, you are only working with one cluster ID. The exception would be if you wanted to scale beyond a 500 external-user concurrency: For example, a second pair of Edges here could bear the cluster ID or dmz2-edge and increase the external concurrency to 1000 with redundancy. This is rarely done and is not a best practice; when the external audience is large, it is best practice to either use the Adobe hosted or managed services, a managed ISP or to locate your origin/application cluster for direct external access.

 

Section 2: Single reverse proxy Adobe Connect Edge deployment combining stunnel and hardware-based SSL acceleration:

For clients with a small or secondary external audience: A Single Connect Edge server deployment using stunnel on the Edge while using SSL acceleration and hardware-based load-balancing for the internal Connect origin/application cluster is depicted here:

1. In this example, the internal cluster is identical to that in our first example with the exception of the hosts file entries for the Edge servers; rather than reiterating that configuration here, simply refer to steps one through six in the previous example where we see the origin/application cluster configuration and the VIPS and pools on the LTM; when you come to step 5c, simply delete or comment out the entry for edge02 from the hosts file example and change the name of edge01 as appropriate: following our example, it is edge.company.com. Let’s look directly at the reverse proxy Edge server itself beginning with the external users:

a. To login, external Connect users resolve to 216.104.214.168, connect.company.com, on 443.

b. The IP address cannot be used directly in the browser URL; you must use a fully qualified domain name, following our example, connect.company.com

2. Network Address Translation (NAT) is depicted to channel the client session to the Connect Edge server to allow the client to log in:

a. Following our example: 216.104.214.168:443,80 connect.company.com maps to 192.168.22.30:443

b. The Connect Edge server running stunnel listens on 443 for encrypted traffic and passes the traffic to port 8443

3. When an external user enters a Connect meeting room the Real Time Management Protocol is securely invoked (RTMPS). RTMPS is encrypted by stunnel running on the Edge server:

a. Following our example: 216.104.214.136:443, edge.company.com maps to 192.168.22.32:1935

b. This URL is invisible to the end user unless she clicks: Help > About Adobe Connect while holding down the shift key in a meeting room.

4. This document is best used a supplement to the installation documentation for Connect Edge servers; you will see here that there are specific configuration files referenced with snippets shown edited form to support the example configuration in the diagram:

a. In particular, see the tech note: https://blogs.adobe.com/connectsupport/adobe-connect-ssl-guide/

b. Following our example, the stunnel.conf file on the Edge server (located in [root_install_dir]\stunnel) is edited as shown in the snippet below to create VIPs:

[https-vip]
; incoming vip for https (to secure Web)
; ip address of the server with stunnel on it (can be on same server as Acrobat Connect)
; listens on port 443
accept =192.168.22.30:443
; ip of the connect server
; send the unencrypted request to port 8443
connect =127.0.0.1:8443
; Certificate info for Connect cert key in stunnel root
cert = company.com.cert.pem
key = company.com.key.pem
[rtmps-vip] ; incoming vip for fms (to secure Meeting)
accept = 192.168.22.32:443
; ip of the fms server
; Send unencrypted request to 1935
connect = 127.0.0.1:1935
; Certificate info for Connect cert key in stunnel root
cert = company.com.cert.pem
key = company.com.key.pem

Note: the following tech-note has helpful details with stunnel configurations: https://blogs.adobe.com/connectsupport/adobe-connect-ssl-guide/

c. Following our example, the custom.ini file in each Edge server root installation directory must contain the following to support the Edge server connection with the Connect origin/application servers:

#Edge custom.ini
FCS_EDGE_HOST=edge.company.com
FCS_EDGE_REGISTER_HOST=192.167.21.78:8443
FCS_EDGE_CLUSTER_ID=dmz-edge
FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=connect.company.com:80
#FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=192.167.21.75:80
FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=connect.company.com:443
#FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=192.167.21.75:443
FCS_EDGE_EXPIRY_TIME=60000
FCS_EDGE_REG_INTERVAL=30000
#DEFAULT_FCS_HOSTPORT=:1935,80,-443

d. Following our example, the HttpCache.xml file, located in [root_install_dir]\edgeserver\win32\conf\ on each Edge server root installation directory must contain the proper host-name tag to support the Edge server connection with the Connect origin/application servers. Note that by putting the FCS_EDGE_HOST variable in the HttpCache.xml file under the host-name tag, you are pointing to the custom.ini variable noted above; following our example, instead of using this variable, you may use the individual unique Edge server names: edge01.company.com on the first and edge02.company.com on the second. The key is to designate the unique, fully qualified Edge server name:

i. Using the variable from the custom.ini on both Edge servers (recommended):

${FCS_EDGE_HOST}

ii. Using the unique name on the edge (optional approach):

edge.company.com

e. In the DMZ, name resolution with reference to the Edge servers will be problematic. Use a host file on each Edge server to make certain that it resolves names properly; following our example, the host file on each Edge would contain:

192.168.22.32 edge.company.com
192.167.21.76 connectmtg01.company.com
192.167.21.77 connectmtg02.company.com
192.167.21.75 connect.company.com

f. The Edge server will need a maintenance script to clear old cache and keep them fresh; run the following .bat file as a scheduled task on the Connect Edge server; feel free to edit this file to reduce or prolong the ping-induced delays and to change the target directory as appropriate. The key is to allow enough time between each command for services to stop and start. Different servers respond differently, some requiring more time and some less time. By stopping the services, it unlocks the cache for thorough deletion:

@ECHO OFF
REM —-CONNECT SERVICE AUTOMATIC CYCLING ————
REM
REM This batch file stops and starts Connect and FMS
REM
REM ———————————————————-
@ECHO ON
net stop fmsadmin
ping 1.1.1.1 -n 1 -w 10000>nul
net stop fms
ping 1.1.1.1 -n 1 -w 200000>nul
del /Q /S d:\breeze\edgeserver\win32\cache\http\*.*
ping 1.1.1.1 -n 1 -w 10000>nul
net start fms
ping 1.1.1.1 -n 1 -w 10000>nul
net start fmsadmin
@ECHO OFF

Note: This script is not needed after the NGINX workaround is implemented: http://blogs.adobe.com/connectsupport/remote-edge-server-intermittently-hangs-or-freezes/

g. Register the Edge with the origin/application server by adding the Edge server unique name into the host mappings section of the Application Management Console on either origin/application server; the settings will propagate throughout the origin/application server cluster from any one of the origin/application servers:

i. Start > Programs > Adobe Connect Server > Configure Connect Enterprise Server

1. If the Edge is communicating with the origin/application server, then you will see it a pre-registration configuration under the server settings tab:

2. 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 rouge Edge registration:

Note: The common identification variable in each custom.ini is the cluster ID; following our example: dmz-edge. And yes, a single Edge server warrants its own cluster ID.

Section 3: Single reverse proxy Connect Edge deployment using stunnel throughout for SSL:

For clients with a small Connect audience comprised of both external and internal clients without the need for redundancy: Single Connect Edge server deployment using stunnel on the Edge along with a single internal Connect origin/application server running stunnel:

1. In this example, the internal origin/application server runs stunnel. Let’s look directly at the origin/application server configuration and the internal users first, then move on to cover the configuration of the reverse proxy Edge:

a. To login, internal Connect users resolve to 192.167.21.75: connect.company.com on port 443

b. The IP address cannot be used directly in the browser URL; you must use a fully qualified domain name, following our example, connect.company.com

c. The Connect origin/application server running stunnel listens on 443 for encrypted traffic and passes the traffic to port 8443

2. When the internal user chooses to enter a Connect meeting room, the Real Time Management Protocol is securely invoked (RTMPS). RTMPS is encrypted by stunnel running on the origin/application server:

a. Following our example: 192.167.21.76:443 connectmtg.company.com traffic is encrypted by stunnel and passed locally to FMS on port 1935

b. This URL is invisible to the end user unless she clicks: Help > About Adobe Connect while holding down the shift key in a meeting room.

3. This document is best used a supplement to the installation documentation for Connect servers; you will see that in this article there are specific configuration files referenced and shown in their edited form to support the example configuration in the diagram:

a. For complete instructions around stunnel and Connect, see the tech note: Configure software-based SSL http://kb2.adobe.com/cps/878/cpsid_87809/attachments/Adobe_Connect_8_SSL.pdf for details assumed here

b. Following our example, the stunnel.conf file on the origin/application server (located in [root_install_dir]\stunnel) is edited as depicted with the VIP details:

[https-vip] ; incoming vip for https (to secure Web)
; ip address of the server with stunnel on it (can be on same server as Acrobat Connect)
; listens on port 443
accept =192.167.21.75:443
; ip of the connect server
; send the unencrypted request to port 8443
connect =127.0.0.1:8443
; Certificate info for Connect cert key in stunnel root
cert = company.com.cert.pem
key = company.com.key.pem
[rtmps-vip]
; incoming vip for fms (to secure Meeting)
accept = 192.167.21.76:443
; ip of the fms server
; Send unencrypted request to 1935
connect = 127.0.0.1:1935
; Certificate info for Connect cert key in stunnel root
cert = company.com.cert.pem
key = company.com.key.pem

c. The custom.ini file, located in the root Connect directory on each origin/application server must contain the following to support the SSL accelerator:

#SSL SETTINGS IN ORIGIN CUSTOM.INI
ADMIN_PROTOCOL=https://
SSL_ONLY=yes
#HTTPS_PORT=8443 (comment out for Connect 8 & 9)
RTMP_SEQUENCE=rtmps://external-host:443/?rtmp://localhost:8506/
#Make sure that the admin host name reflects the URL rather than the server machine name
ADMIN_HOST=connect.adobe.com

d. The custom.ini file on each origin/application server must also contain the following to properly identify the Edge server that will register with the origin/application server; this variable will match the cluster ID in the Edge server custom.ini: FCS_EDGE_CLUSTER_ID=dmz-edge

# EDGE SERVER SETTINGS IN ORIGIN CUSTOM.INI
edge.dmz-edge=1

e. For Adobe Connect origin servers, the server.xml file, located in the \appserv\conf directory, must have the following uncommented to support stunnel SSL:

namePrefix=”https-8443-”
maxThreads=”350″
minSpareThreads=”25″/>

enableLookups=”false”
acceptCount=”250″
connectionTimeout=”20000″
SSLEnabled=”false”
scheme=”https”
secure=”true”
proxyPort=”443″
URIEncoding=”utf-8″/>

Note: the following tech-note has helpful details with SSL configurations: https://blogs.adobe.com/connectsupport/adobe-connect-ssl-guide/

4. There are ports listening on the Connect origin/application server to support the registration and caching communication between the reverse proxy Edge server and the origin/application server.

a. Following our example, this connection is for the Edge server to register with the origin/application server and avoid stunnel on 443 whether directly or redirected from port 80:

192.167.21.75:8443 connect.company.com

b. Following our example, this connection is for the Edge servers in the DMZ to cache content from the origin/application servers:

192.167.21.76:8506 connectmtg.company.com

5. Name resolution among the servers can be problematic. It is prudent to put the following hosts file on each origin/application server: \%systemroot%\system32\drivers\etc. Note that with 2008 (or a Windows 7 client), the text editor must be run with administrator privileges:

192.168.22.32 edge.company.com
192.167.21.76 connectmtg.company.com
192.167.21.75 connect.company.com

6. Let’s look now at the reverse proxy Edge server beginning with the external users:

a. To login, external Connect users resolve to 216.104.214.168, connect.company.com, on 443.

b. The IP address cannot be used directly in the browser URL; you must use a fully qualified domain name, following our example, connect.company.com

7. Network Address Translation (NAT) is depicted to channel the client session to the two Connect Edge server to allow the client to log in:

a. Following our example: 216.104.214.168:443,80 connect.company.com maps to 192.168.22.30:443

b. The Connect Edge server running stunnel listens on 443 for encrypted traffic and passes the traffic locally to port 8443

8. When the external user chooses to enter a Connect meeting room, the Real Time Management Protocol is securely invoked (RTMPS). RTMPS is encrypted by stunnel running on the Edge server:

a. Following our example: 216.104.214.136:443, edge.company.com maps to 192.168.22.32:1935

b. This URL is invisible to the end user unless she clicks: Help > About Adobe Connect while holding down the shift key in a meeting room.

9. This document is best used a supplement to the installation documentation for Connect Edge servers; you will see that there are specific configuration files referenced and shown in their edited form to support the example configuration in the diagram:

a. In particular, see the tech note: Configure software-based SSL http://kb2.adobe.com/cps/878/cpsid_87809/attachments/Adobe_Connect_8_SSL.pdf for details assumed here

b. Following our example, the stunnel.conf file VIP configuration on the Edge server (located in [root_install_dir]\stunnel) is edited as depicted in this snippet:

[https-vip] ; incoming vip for https (to secure Web)
; ip address of the server with stunnel on it (can be on same server as Acrobat Connect)
; listens on port 443 accept =192.168.22.30:443
; ip of the connect server
; send the unencrypted request to port 8443
connect =127.0.0.1:8443
; Certificate info for Connect cert key in stunnel root
cert = company.com.cert.pem
key = company.com.key.pem [rtmps-vip]
; incoming vip for fms (to secure Meeting)
accept = 192.168.22.32:443
; ip of the fms server
; Send unencrypted request to 1935
connect = 127.0.0.1:1935
; Certificate info for Connect cert key in stunnel root
cert = company.com.cert.pem
key = company.com.key.pem

c. Following our example, the custom.ini file in each Edge server root installation directory must contain the following to support the Edge server connection with the Connect origin/application servers:

#Edge01 custom.ini
FCS_EDGE_HOST=edge01.company.com
FCS_EDGE_REGISTER_HOST=192.167.21.75:8443
#FCS_EDGE_REGISTER_HOST=registerconnect.company.com:8443
FCS_EDGE_CLUSTER_ID=dmz-edge
FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=connect.company.com:80
#FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=192.167.21.75:80
FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=connect.company.com:443
#FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=192.167.21.75:443
FCS_EDGE_EXPIRY_TIME=60000
FCS_EDGE_REG_INTERVAL=30000
#DEFAULT_FCS_HOSTPORT=:1935,80,-443

d. Following our example, the HttpCache.xml file, located in [root_install_dir]\edgeserver\win32\conf\ on each Edge server root installation directory must contain the proper host-name tag to support the Edge server connection with the Connect origin/application servers. Note that by putting the FCS_EDGE_HOST variable in the HttpCache.xml file under the host-name tag, you are pointing to the custom.ini variable noted above; following our example, instead of using this variable, you may use the individual unique Edge server names: edge01.company.com on the first and edge02.company.com on the second. The key is to designate the unique, fully qualified Edge server name:

i. Using the variable from the custom.ini on both Edge servers (recommended):

${FCS_EDGE_HOST}

ii. Using the unique name on the edge (optional approach):

edge.company.com

10. In the DMZ, name resolution with reference to the Edge servers will be problematic. Use a host file on each Edge server to make certain that it resolves names properly: \%systemroot%\system32\drivers\etc. Note that with 2008 (or a Windows 7 client), the text editor must be run with administrator privileges: following our example, the host file on each Edge would contain:

192.168.22.32 edge.company.com
192.167.21.76 connectmtg.company.com
192.167.21.75 connect.company.com

11. The Edge server will need a maintenance script to clear old cache and keep them fresh; run the following .bat file as a scheduled task on the Connect Edge server; feel free to edit this file to reduce or prolong the ping-induced delays. The key is to allow enough time between each command for services to stop and start. Different servers respond differently, some requiring more time and some less time. By stopping the services, it unlocks the cache for thorough deletion:

@ECHO OFF
REM ——–CONNECT SERVICE AUTOMATIC CYCLING ———-
REM
REM This batch file stops and starts Connect and FMS
REM
REM ——————————————————-
@ECHO ON
net stop fmsadmin
ping 1.1.1.1 -n 1 -w 10000>nul
net stop fms
ping 1.1.1.1 -n 1 -w 200000>nul
del /Q /S d:\breeze\edgeserver\win32\cache\http\*.*
ping 1.1.1.1 -n 1 -w 10000>nul
net start fms
ping 1.1.1.1 -n 1 -w 10000>nul
net start fmsadmin
@ECHO OFF

Note: This script is not needed after the NGINX workaround is implemented: http://blogs.adobe.com/connectsupport/remote-edge-server-intermittently-hangs-or-freezes/

12. Register the Edge with the origin/application server by adding the Edge server unique name into the host mappings section of the Application Management Console on the origin/application server.

a. Start > Programs > Adobe Connect Server > Configure Connect Enterprise Server

1. If the Edge is communicating with the origin/application server, then you will see it a pre-registration configuration under the server settings tab:

2. 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 rouge Edge registration:

b. Note: The common identification variable in each custom.ini is the cluster ID; following our example: dmz-edge. And yes, in case you are wondering, a single Edge server warrants its own cluster ID even though it is a lone proxy server.

Section 4 Enterprise Proxy Connect Edge deployment considerations:

Enterprise-proxy Connect Edge server deployments are used when there are remote concentrations of internal Connect meeting participants. To depict this configuration, let’s consider a redundant pair of Edge servers in a remote Boston-based office pointing to a four-server origin/application server cluster in a primary London-based office. Both clusters will utilize hardware-based load-balancing and SSL acceleration. Smart DNS is also depicted to insure proper routing of participants along the shortest network distance path. Following our example outlined below, before the implementation of the enterprise proxy Adobe Connect Edge server cluster, a user in Boston would open a browser to the URL http://connect.company.com to start a Connect session on the servers based in London: 100 Boston-based users may initiate and utilize 100 connections. Depending on the Connect use case, you could use from 5 to 10 Mbps per 100 participants. The typical average is 50 kb per user; the amount of bandwidth utilized depends on what is being presented and how it is being presented. On the high end, a customer might use 20 Mbps for 150 users in meetings, but that is very high. More typically, it is normal to assume a max of 10 Mbps (when external this would be outgoing, incoming is never that high) for just over 100 users; 5 Mbps per 100 is the low average. Activities like video and screen sharing tend to use more bandwidth while a one-to-many broadcast uses less bandwidth. Connect is very efficient with the metering out of converted PPTXs and PDFs from a Meeting. The Meeting rooms can operate with 1-5 kbps of output when not much is going on; the estimates can be low but are use-case dependent. Even screen resolution is a factor. The enterprise proxy Adobe Connect Edge server will take those 100 users and reduce their bandwidth signature from 100 connections to a single connection between Boston and London for each meeting in session:

1. Rather than immediately discussing the Enterprise Proxy Edge servers in the upper left corner of the diagram above, let’s review the configuration beginning in the center at the Connect on-premise origin/application server cluster and BIG-IP Local Traffic Manager (LTM). Notice that all local internal clients are hosted directly on this cluster while remote internal clients are not. I have not depicted any external clients, but adding them would simply be a matter of following the relevant reverse proxy Connect Edge procedure outlined previously in this article.

a. The local internal HTTPS traffic goes through a virtual IP address (VIP) on the LTM and is distributed via a round-robin algorithm without any session-awareness or sticky load-balancing options on the LTM.

i. This may seem odd with reference to HTTPS.

ii. In most cases, SSL-accelerated server pools require session-awareness on the load-balancing device, not so with Connect.

b. To login, local internal Connect users resolve to 192.167.21.74, connect.company.com, on either 80 or 443.

i. If a client inadvertently connects via HTTP on 80, LTM can redirect them to 443.

ii. The IP address of the VIP cannot be used directly in the browser URL; you must use a fully qualified domain name, following our example, connect.company.com

2. LTM will use the round-robin algorithm to channel the client session to one of the two Connect origin/application servers in the Connect server pool to allow the client to log in:

a. Following our example: 192.167.21.74:443,80 connect.company.com – round-robin non-session-aware pool= 192.166.22.176:8443, 192.166.22.177:8443, 192.166.22.178:8443, 192.166.22.179:8443

b. Each server in the Connect server pool listens on 8443 for unencrypted traffic from the LTM – everything in front of LTM is encrypted and everything behind LTM is unencrypted

3. When the internal user chooses to enter a Connect meeting room, the real time management protocol is securely invoked (RTMPS). RTMPS is encrypted at separate VIPs on the LTM: 192.167.21.76:443 connectmtg01.company.com, 192.167.21.77:443 connectmtg02.company.com, 192.167.21.78:443 connectmtg03.company.com and 192.167.21.79:443 connectmtg04.company.com

a. Following our example: 192.167.21.76:443, connectmtg01.company.com – pool= to 192.166.22.176:1935

b. Following our example: 192.167.21.77:443 connectmtg02.company.com – pool= to 192.166.22.177:1935

c. Following our example: 192.167.21.79:443 connectmtg03.company.com – pool= to 192.166.22.178:1935

d. Following our example: 192.167.21.79:443 connectmtg04.company.com – pool= to 192.166.22.179:1935

e. Each individual Connect server has a built-in Flash Media Server that listens on 1935 for unencrypted traffic from the LTM – as with the HTTPS, with RTMPS, everything in front of LTM is encrypted and everything behind LTM is unencrypted

4. You will notice that each Connect server is listening on port 8507: This is for server to server communication among the Connect servers themselves.

5. This document is best used a supplement to the installation documentation for Connect origin/application servers; you will see here that there are specific configuration files referenced and shown in their edited form to support the example configuration in the diagram:

a. The custom.ini file located in the root Connect directory on each origin/application server must contain the following to support the SSL accelerator and fail-over for Adobe Connect:

#SSL SETTINGS IN ORIGIN CUSTOM.INI
ADMIN_PROTOCOL=https://
SSL_ONLY=yes
#HTTPS_PORT=8443 (comment out for Connect 8)
RTMP_SEQUENCE=rtmps://external-host:443/?rtmp://localhost:8506/
MEETING_TIMEOUT=0
MEETING_CONNECT_BACK_TIME=1

b. The custom.ini file on each origin/application server must also contain the following to properly identify the Edge servers that will register with the origin/application cluster; this variable will match the cluster ID in the Edge server custom.ini: FCS_EDGE_CLUSTER_ID=dmz-edge

# EDGE SERVER SETTINGS IN ORIGIN CUSTOM.INI
edge.ent-edge=1

c. For Connect 8 & 9 servers, the server.xml file, located in the \appserv\conf directory, must have the following un-committed to support the SSL accelerator:

namePrefix=”https-8443-”
maxThreads=”350″
minSpareThreads=”25″/>

enableLookups=”false”
acceptCount=”250″
connectionTimeout=”20000″
SSLEnabled=”false”
scheme=”https”
secure=”true”
proxyPort=”443″
URIEncoding=”utf-8″/>

6. There are two other VIPs depicted on the internal local LTM. These are to support the registration and caching communication between the Enterprise Proxy Edge servers and the origin/application servers.

a. Following our example, this connection is for the Edge servers to register with the origin/application servers: the reason we use a separate VIP is to avoid the encryption rules of the HTTPS VIP which listens on 80 for end users (who may forget the “S” their HTTPS URL) and reroutes them to 443:

192.167.21.75:80 – round-robin non-session-aware pool = 192.166.22.176:80, 192.166.22.177:80, 192.166.22.178:80, 192.166.22.179:80

b. Following our example, this connection is for the Edge servers in the DMZ to cache content from the origin/application servers; the reason these are separate VIPs is to avoid the RTMPS internal user encryption rules:

  1. 192.167.21.76:8506 connectmtg01.company.com – pool= 192.166.22.176:8506
  2. 192.167.21.77:8506 connectmtg02.company.com – pool= 192.166.22.177:8506
  3. 192.167.21.78:8506 connectmtg01.company.com – pool= 192.166.22.178:8506
  4. 192.167.21.79:8506 connectmtg02.company.com – pool= 192.166.22.179:8506

7. By looking in detail at the origin/application cluster and the LTM, we have seen how the connections from the Edge servers look. Let’s now look directly at the Edge cluster itself beginning with the external users:

a. To login, internal remote Connect users resolve to 192.168.22.40, connect.company.com, on either 80 or 443.

i. If a client inadvertently connects via HTTP on 80, LTM can redirect them to 443.

ii. The IP address of the VIP cannot be used directly in the browser URL; you must use a fully qualified domain name, following our example: connect.company.com

8. LTM will use the round-robin algorithm to channel the client session to one of the two Connect Edge servers in the Connect server pool to allow the client to log in:

a. Following our example: 192.168.22.40:443,80 connect.company.com – round-robin non-session-aware pool= 192.168.22.30:8443, 192.168.22.31:8443

b. The Connect Edge server pool listens on 8443 for unencrypted traffic from the LTM – everything in front of LTM is encrypted and everything behind LTM is unencrypted

9. When the internal remote user chooses to enter a Connect meeting room, the real time management protocol is securely invoked (RTMPS). RTMPS is encrypted at separate VIPs on the LTM: 192.168.22.42:443 edge01.company.com and 192.168.22.43:443 edge02.company.com

a. Following our example: 192.168.22.42:443, edge01.company.com – pool= 192.168.22.32:1935

b. Following our example: 192.168.22.43:443 edge02.company.com – pool= 192.166.22.33:1935

c. Each RTMP VIP, whether listening on 443, 1935 or 8506, should not have an HTTP profile on any hardware-based load-balancing device. RTMP is a streaming protocol and an HTTP profile can interfere with functionality; use a TCP profile. On F5 BIG-IP, LTM, also make sure the OneConnectProfile is enabled and Nagle’s Algorithm disabled.

10. This document is best used a supplement to the installation documentation for Connect Edge servers; you will see that there are specific configuration files referenced and shown in their edited form to support the example configuration in the diagram:

a. Following our example, the custom.ini file in each Edge server root installation directory must contain the following to support the Edge server connection with the Connect origin/application servers:

#Edge01 custom.ini
FCS_EDGE_HOST=edge01.company.com
#FCS_EDGE_REGISTER_HOST= registerconnect.company.com
FCS_EDGE_REGISTER_HOST=192.167.21.75:8443
FCS_EDGE_CLUSTER_ID=ent-edge
#FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=connect.company.com:80
FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=192.167.21.74:80
#FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=connect.company.com:443
FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=192.167.21.74:443
FCS_EDGE_EXPIRY_TIME=60000
FCS_EDGE_REG_INTERVAL=30000
#DEFAULT_FCS_HOSTPORT=:1935,80,-443

 

#Edge02 custom.ini
FCS_EDGE_HOST=edge02.company.com
#FCS_EDGE_REGISTER_HOST= registerconnect.company.com
FCS_EDGE_REGISTER_HOST=192.167.21.75:8443
FCS_EDGE_CLUSTER_ID=ent-edge
#FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=connect.company.com:80
FCS.HTTPCACHE_BREEZE_SERVER_NORMAL_PORT=192.167.21.74:80
#FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=connect.company.com:443
FCS.HTTPCACHE_BREEZE_SERVER_SECURE_PORT=192.167.21.74:443
FCS_EDGE_EXPIRY_TIME=60000
FCS_EDGE_REG_INTERVAL=30000
#DEFAULT_FCS_HOSTPORT=:1935,80,-443

b. Following our example, the HttpCache.xml file, located in [root_install_dir]\edgeserver\win32\conf\ on each Edge server root installation directory must contain the proper host-name tag to support the Edge server connection with the Connect origin/application servers. Note that by putting the FCS_EDGE_HOST variable in the HttpCache.xml file under the host-name tag, you are pointing to the custom.ini variable noted above; following our example, instead of using this variable, you may use the individual unique Edge server names: edge01.company.com on the first and edge02.company.com on the second. The key is to designate the unique, fully qualified Edge server name:

i. Using the variable from the custom.ini on both Edge servers (recommended):

${FCS_EDGE_HOST}

ii. Using the unique name on edge01 (optional approach)

edge01.company.com

iii. Using the unique name on edge02 (optional approach):

edge02.company.com

c. In the DMZ, name resolution with reference to the Edge servers will be problematic. Use a host file on each Edge server to make certain that it resolves names properly; following our example, the host file on each Edge would contain:

192.168.22.32 edge01.company.com
192.168.22.33 edge02.company.com
192.167.21.76 connectmtg01.company.com
192.167.21.77 connectmtg02.company.com
192.167.21.78 connectmtg03.company.com
192.167.21.79 connectmtg04.company.com
192.167.21.74 connect.company.com
#192.167.21.75 connect.company.com

d. The Edge server will need a maintenance script to clear old cache and keep them fresh; run the following .bat file as a scheduled task on each Connect Edge server; feel free to edit this file to reduce or prolong the ping-induced delays. The key is to allow enough time between each command for services to stop and start. Different servers respond differently, some requiring more time and some less time. By stopping the services, it unlocks the cache for thorough deletion:

@ECHO OFF
REM ——–CONNECT SERVICE AUTOMATIC CYCLING———-
REM
REM This batch file stops and starts Adobe Connect and FMS
REM
REM ——————————————————————-
@ECHO ON
net stop fmsadmin
ping 1.1.1.1 -n 1 -w 10000>nul
net stop fms
ping 1.1.1.1 -n 1 -w 200000>nul
del /Q /S d:\breeze\edgeserver\win32\cache\http\*.*
ping 1.1.1.1 -n 1 -w 10000>nul
net start fms
ping 1.1.1.1 -n 1 -w 10000>nul
net start fmsadmin
@ECHO OFF

Note: This script is not needed after the NGINX workaround is implemented: http://blogs.adobe.com/connectsupport/remote-edge-server-intermittently-hangs-or-freezes/

e. Register the Edges with the origin/application servers by adding the Edge server unique names into the host mappings section of the Application Management Console on either origin/application server; the settings will propagate throughout the origin/application server cluster from any one of the origin/application servers:

i. Start > Programs > Adobe Connect Server > Configure Connect Enterprise Server

1. If the Edge is communicating with the origin/application servers, then you will see them in a pre-registration configuration under the server settings tab:

2. Add the same unique Edge names into the host mapping fields as follows to register the Edges; this is a security mechanism to prevent rouge Edge registration:

Note: The common identification variable in each custom.ini is the cluster ID; following our example: ent-edge. If you had multiple zones, then you would have multiple cluster IDs. To add and additional zones you must number them in the custom.ini of both the Connect Edges and the Connect origin/application servers.

f. Note: Optionally, to add a reverse proxy Connect Edge server cluster in addition to the enterprise proxy Connect Edge server cluster, you must add another cluster ID to both custom.ini files (Edge and origin). For example, edge.dmz-edge in the Edge custom.ini would correspond with edge.dmz-edge=2 in the origin/application custom.ini to segregate and identify the corresponding Edge cluster into a different zone from the enterprise proxy Edge cluster. You might even want to add an additional zone to a DMZ if you wanted to scale beyond a 500 external-user concurrency. For example, a second pair of Edges in a DMZ could bear the cluster ID of edge.dmz2-edge in the custom.ini on the Connect Edge servers and edge.dmz2-edge=3 would be the corresponding entry in the origin/application custom.ini files. This additional reverse proxy cluster in an additional zone would increase the external concurrency to 1000 with redundancy in concert with the pair of Edge servers bearing the cluster ID: edge.dmz. This is rarely done and is not a best practice; when the external audience is large, it is best practice to either use the Adobe hosted or managed services, a managed ISP or to locate your origin/application cluster in a presentation layer for direct external access.

11. DNS considerations are a primary concern when employing an enterprise proxy Adobe Connect Edge cluster. Following our example, the end users in Boston need to resolve to the enterprise proxy Edge cluster in Boston rather than make the round trip to the origin/application servers in London. There are many ways to do this. The diagram above depicts smart DNS in the form of the F5 Global Traffic Manager (GTM). Another options include DNS subnet prioritization or the use of hosts files on the clients. Note that with BIND DNS, subnet prioritization is referred to as resolver’s address-sorting feature. BIND is integrated with F5 Global Traffic Manager (GTM) via ZoneRunner.

a. Smart DNS: Detects availability and network round trip time to various Edge or origin resources bearing the same name. It is better than DNS Subnet prioritization because it will find the best available resource to enhance performance for end users and will not send users to any resources that are not available. It provides redirection and failover capabilities via application-level health monitoring.

b. DNS Subnet Prioritization:

i. With DNS Subnet Prioritization, you add a list of assets into the DNS server and DNS chooses the subnet based on the network location of the client. Most DNS servers support this, but some early BIND versions may not. The following link points to an active directory option: http://technet.microsoft.com/en-us/library/cc961422.aspx If the DNS system is not centralized and replicated to share the mappings table then subnet prioritization is not necessary as each regional DNS server can be configured individually. This is rare. Most enterprise network infrastructures use centralized DNS.

1. Continuing with our example, there would generally be a DNS server in Boston that shares the centralized DNS mappings with London.

a. If centralized, all the DNS servers share the same mapping table and no matter where a user is located, connect.company.com would resolve to 192.167.21.74.

b. Once the Edge servers are installed, the Boston based user must resolve to the same name, connect.company.com, at a different IP address: 192.168.22.40 using the centralized DNS system which shares the same mapping table.

2. With DNS Subnet Prioritization configured, the centralized DNS system will return a list of IP addresses relative to the location of the client (user).

a. Following our example, a user in Boston who browses to connect.comany.com will get a list prioritized by network distance as the DNS servers parse the subnet mask: 192.168.22.40; 192.167.21.74: (Boston; London)

b. A user in London will get the list reversed: 192.167.21.74; 192.168.22.40 (London; Boston)

c. DNS Subnet Prioritization solves the network distance problem in a rough and unintelligent way insofar as the DNS servers are not application aware, but it works this much: Boston and London users are directed to their local servers. Other (presumably smaller concentrations of) internal remote clients would go to the origin/application servers directly in London.

d. One caveat worth noting is that we have seen, in cases where DNS is centralized, but with various versions intermingled, instances where the accuracy rate of the connections using DNS subnet prioritization was as low as 70% and one client who experienced this chose to use GTM.

3. Note that if a client tries to resolve connect.company.com and there is not a DNS entry for that specific client’s subnet, when DNS returns the IP to the client it will use the last listed IP address in the mappings table.

a. If the Boston enterprise proxy Connect Edge server is added after DNS was configured for resolution to the London cluster, you must delete and re-add the DNS entry for London so it will be the last entry.

b. The round-robin load-balancing algorithm must not be used with DNS subnet prioritization: http://support.microsoft.com/kb/842197.

c. SMS or scripted host-file push: This is as stated. Simply push hosts files to clients based on network location. Host files override DNS. Of course, this will not work with external clients that cannot be touched and configured by SMS. It is an internal solution requiring access to:

\\\ADMIN$\system32\drivers\etc

 

Section 5 Additional Connect Edge deployment considerations and troubleshooting steps:

When designing or troubleshooting a Connect deployment, the following factors are important to consider.

1.To avoid freezing of the AMS service on the Adobe Connect Edge, employ the NGINX caching workaround: http://blogs.adobe.com/connectsupport/remote-edge-server-intermittently-hangs-or-freezes/

2. In some circumstances, it may be prudent, if not required, to secure the traffic between a remote Edge server and an origin on port 8506. By default, the traffic between an external edge and an origin server is unencrypted.

a. To encrypt RTMP between servers on port 8506, begin on the remote Edge servers.

i. Edit: /breeze/edgeserver/win32/conf/_defaultRoot_/_defaultVhost_/vHost.xml:

1. Replace: <RouteTable protocol="">

with

<RouteTable protocol="rtmps">

2. Replace:
<RouteEntry><!--RouteEntry>
with
<RouteEntry protocol="rtmps">*:*;*:*<!--RouteEntry>

3. Keep the closing tag in place:

b. Secure the 8506 traffic at the origin server on 8506 as though it were client RTMP traffic inbound to port 1935 except in this case you will use port 8506:

i. In the stunnel.conf file on the origin servers (or on the SSL accelerator in front of the origin servers), encrypt the inbound edge to origin traffic on port 8506. In the stunnel.conf file on an origin server, for example, you would add an entry for the RTMP traffic on the meeting server VIP:

accept = 192.168.22.32:8506
; ip of the fms server
; Send unencrypted request to 1935
connect = 127.0.0.1:8506

ii. One caveat resulting from this technique of doing SSL, is that when you view the RTMP sequence from within a meeting room (Help > Shift > About Adobe Connect) the second leg of the RTMP sequence will read RTMP even though it is actually RTMPS; the first leg reads RTMPS and adjudicates both legs.

3. Hosts and presenters, when possible, should connect directly to the origin/application servers rather than through remote Edge servers. The Connect Edge servers chunk data in their communication with the origin/application servers. While this allows for a uniform experience for participants, consider that if the hosts or presenters are driving content for a meeting through a connection to an Edge server, the data flow would look like this:

a. With reference to our previous examples of reverse proxy Edge deployments and of enterprise proxy Edge deployments, the proximity of the hosts and presenters to the origin/application servers might be managed as follows:

i. External hosts who would normally connect through a reverse proxy Edge may want to consider the following options:

1. Rehearse and coordinate the meeting activities to be driven by an internal presenter assistant

2. Coordinate and test the meeting administration through a VPN connection to make the host connection internal to the origin/application servers

3. Connect to the origin/application servers through an alternate proxy only if RTMPS passes directly unimpeded and caching is not a mitigating variable

ii. Hosts in close proximity to an enterprise proxy Edge server may want to consider the following options:

1. Use smart DNS source routing to direct the presenter client connection directly to the origin/application servers

2. Use a hosts file to point the presenter client directly to the origin/application servers

3. The enterprise proxy Edge will still be used in either case to consolidate bandwidth as the majority of users will still connect at the Edge

iii. This can be overstated as when a remote Edge is used, the local Edge that is co-located on the origin server is eliminated from the connection path. There is not any stacking of Edge servers to create any additional hop or superfluous processing of RTMP. The caution outlined here is only to ameliorate any potential effects of the servers to server connection on port 8506:

4. Troubleshooting the Connect Edge server system error:

a. If you see a server error in the browser of your test client, Scrutinize the HttpCache.xml file in edgeserver\win32\conf\ for accuracy and to be sure it is not corrupted

i. Open the HttpCache.xml file in a browser and make sure the browser does not indicate an XML coding error

ii. Make sure the hostname is either the unique name of the Connect Edge or the FCS_EDGE_HOST variable and not the Connect hostname; these examples are from our single reverse proxy Edge HttpCache.xml file; either approach will work:

b. Scrutinize the cluster ID and zone variables in the custom.ini files on both the Edge servers and the origin/application servers to make sure they correspond.

i. Check the cluster ID, zone configurations and the name of each cluster. Each edge server cluster must have a unique ID. Each computer within the cluster must have the same ID

ii. Following our enterprise proxy example, each Edge custom.ini should have: FCS_EDGE_CLUSTER_ID=ent-edge iii. Following our enterprise proxy example, each origin/application server custom.ini should have: edge.ent-edge=1 iv. If we were to add a reverse proxy cluster to the enterprise proxy example configuration, it would look like this:

1. On each enterprise proxy Edge: FCS_EDGE_CLUSTER_ID=ent-edge

2. On each reverse proxy Edge: FCS_EDGE_CLUSTER_ID=rev-edge

3. On each origin/application server: edge.ent-edge=1 edge.rev-edge=2 v. The key is to have unique cluster names and zone numbers for clusters, but not unique server names unless they are in their own cluster as with a single Edge server. vi. Zone 0 is reserved for the origin/application server cluster.

c. Use the diagnostic command netstat –an from the command prompt of the origin/application server to make certain that the origin/application server is listening on all the correct ports: 80, 443, 8506

d. Use telnet to test the connection from Edge to the origin/application server on port 8506

e. After connecting to the Edge, look in the edgeserver\win32\cache\http folder to see if the folder appserv is there. The presence of the folder appserv indicates that users are connecting to the Edge f. Look in the access.00.log file in the edgeserver\logs\access folder to see if users are IP addresses are logged indicated their connection to a meeting

5. If the Connect Edge will not register, then the registered name of the Edge will not appear under the server setting tab in the origin/application server configuration wizard:

a. This is what it will look like if the Edge is registering with the origin/application server:

b. You complete this process by adding the names into the fields manually; this prevents a rogue Edge from registering:

c. If the Edge will not register then look in the master00.log on the Edge in edgeserver\logs\ for a registration error ending in: _defaultRoot_:local:registerapp: experienced 1 failure[s]!

i. If SSL is enabled on the origin/application server, depending on how you are registering, you may need to edit the main.asc file in edgeserver\apps\registerapp\

1. For SSL, change the connection to https: NetServices.createGatewayConnection(“https://” + ADMIN_HOST + “/servlet/gateway”);

2. For NTLM add a trailing slash: NetServices.createGatewayConnection(“http://” + ADMIN_HOST + “/servlet/gateway/”);

ii. Try alternating in the Edge custom.ini register host variable between the hostname and the IP address; both are included in the sample files for troubleshooting purposes; one should be commented out:

#FCS_EDGE_REGISTER_HOST= registerconnect.company.com FCS_EDGE_REGISTER_HOST=192.167.21.75:8443

iii. Use telnet from the Edge server to test the connection on port 80 to the origin/application server. iv. Try connecting to the origin/application server from the Edge using the Edge as a regular Connect meeting client. In all of the reverse proxy examples above, 443 is depicted as open on the internal firewall for the purposes of troubleshooting in this manner.

Conclusions – The Adobe Connect Edge Server:

In the introduction, I alluded to two equal yet opposite errors concerning the deployment of Connect Edge servers; the first being to not consider the option and the second to deploy them where they will not add value. Throughout this five chapter article I have outlined the best practice examples for employing Adobe Connect Edge servers to intercept and consolidate Adobe Connect session traffic in example-based enterprise scenarios. With consideration for limiting factors in various infrastructure examples, it is important to consider that the Adobe Connect Edge does not create bandwidth or accelerate session traffic; where latency between the origin/application server and Edge is greater than 50 milliseconds and the available bandwidth is less than 500 kbps, the Connect Edge technology may not add value.

The best use of the Adobe Connect edge is in either a one-to-many or small meeting collaborative use case where the hosts and presenters are connected to the origin/application servers from which they drive the content for participants who are connected to Edge proxies. The addition of remote or external participants may warrant the employment of Adobe Connect Edge server technology. Generally whenever a third-part proxy server is used with Adobe Connect, RTMPS should bypass that proxy completely; never try to cache an RTMP stream or treat  Adobe Connect as you would a typical HTML web server.

Clustering, Edge Server, General