When you have an existing Cisco Meeting Server Cluster cms1, cms2 and cms3 have the CallBridge and the Database services co-located with cms1 as the primary database. The CallBridge service once enabled connects automatically to the local database to retrieve the cluster-wide configuration.
In this deployment you want to add fourth node let’s say cms4 with the CallBridge and WebBridge only, in this case we need to do two things:
Connect the cms4 to the primary database node cms1 in order to retrieve the cluster-wide configuration. To achieve this, the database cluster connect <ip address of the primary database node> must be configured on cms4.
The second requirement is to reconfigure the certificates.
There are two options to reconfigure the certificates:
The first option: modify the existing server certificate created for the existing cluster to include the FQDN cms4.lab.local in the Subject Alternative Name SAN, generate the new certificate then modify the certificate chain for example cms-chain for WebBridge, finally reconfigure the CallBridge and the WebBridge on all the CMS (cms1, cms2, cms3 and cms4).
The second option: create a dedicated server certificate for cms4 with the Common Name = FQDN of cms4 (cms4.lab.local), in the SAN attributes, include the Guest URLs for example join.lab.local / meet.lab.local, then create a new trust chain certificate CMS4-Chain, finally configure the new node cms4 with this certificate without modifying anything on cms1, cms2 and cms3.
The caveat is when you have a scheduler already running in the existing cluster, the Scheduler configuration requires the reconfiguration of the certificates so that cms1, cms2, cms3 and cms4 WebBridges will use the same Trust Chain Certificate. Therefore, you must use the first option in order for the scheduler to connect successfully to all webbridges cms1, cms2, cms3 and cms4.
