In this article I am going to share with you: how to deploy a cluster of three Cisco Meeting Server CMS1, CMS2 and CMS3 with the Database, CallBridge, WebBridge, Recorder and Streamer, Scheduler services and a requirement in the future: extension of the existing solution by adding a new CallBridge/WebBridge node. This scenario is based on a real deployment so that it can help you to plan your certificates when additional nodes need to be added.
Requirements:
- CMS1, CMS2 and CMS3 are planned to run a cluster database, CallBridge and WebBridge.
- CMS1 must be enabled with Scheduler service.
- CMS4 must be added with the CallBridge and WebBridge services to the existing deployment.
- CMS5 must be configured with the Recorder and Streamer services.
- Cluster Database Configuration between cms1 cms2 and cms3
- WebAdmin CallBridge and WebBridge Certificates
- Enabling the Web Admin Service
- Enabling the CallBridge service
- Enabling the WebBridge 3 service
- CallBridge cluster configuration
- Active Directory integration
- Cisco Unified Communication Manager Dial Plan
- Cisco Meeting Server Dial Plan
- Integration of new node cms4 with CallBridge and WebBridge without the database
- Enabling the Recorder and Streamer services on a dedicated server
- Enabling the Scheduler service
Cluster Database Configuration between cms1 cms2 and cms3
For database we need to generate two CSRs with the corresponding private keys, the client and the server.
Use one CMS to generates these two CSRs, once you get the server and client certificates from your CA, copy the two certificates with their private keys to all nodes using WinSCP.
For Server certificate use the following command, give a name for example dbcert, it is important to put the CN to the FQDN of the Master Database cms1 and the FQDN of the slaves in the SAN. For example: cms1.lab.local in the Common Name, cms2.lab.local and cms3.lab.local in the SAN.
cms1>pki csr dbcert CN:cms1.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:cms2.lab.local,cms3.lab.local
For Client certificate use the following command, give a name for example dbclt.
cms1>pki csr dbclt CN:postgres
On CMS1.
Configure the database client and server certificates created previously and named dbcert and dbclt. The Root-CA certificate is added to verify the validity of the client/ server certificates. Specify which interface to use for the database clustering and initialize the master database.
cms1>database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer
cms1>database cluster localnode a
cms1>database cluster initialize
On CMS2 and CMS3.
Configure the database client and server certificates created previously and named dbcert and dbclt. The Root-CA certificate is added to verify the validity of the client/ server certificates, specify the interface to use, connect cms2 and cms3 to the master database cms1.
cmsx>database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer
cmsx>database cluster localnode a
cmsx>database cluster join cms1.lab.local
On both cms1, cms2 and cms3, Verify the status of the database cluster.
WebAdmin CallBridge and WebBridge Certificates
Certificate configuration is required also for the Call Bridge, Web Bridge and Web Admin services.
For WebAdmin, CallBridge and WebBridge3 services we need either separate Certificates for each node or single certificate for all nodes using the Multi-SAN certificate. We call it Server certificate or Entity certificate.
To generate a single server certificate for all nodes, we need to generate a Certificate Signing Request (CSR) and private key locally, the following command is used, give a name cmscert. Use the domain name as the Common Name lab.local and the certificate must have the Subject Alternate Name (SAN) attributes, for example: guest URLs such as join.lab.local and meet.lab.local, the FQDN of the CMS nodes cms1.lab.local, cms2.lab.local and cms3.lab.local.
cms1>pki csr cmscert CN:lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:cms1.lab.local,cms2.lab.local,cms3.lab.local,join.lab.local,meet.lab.local,lab.local,10.1.5.61,10.1.5.62,10.1.5.63,10.1.5.0/24
A bundle CA chain certificate is required to trust the cmscert certificate when you will enable WebAdmin, CallBridge and WebBridge.
To create a bundle CA chain certificate, you need:
- The Root CA or the CA’s certificate (Downloaded from the CA Server).
- A Subordinate CA’s certificate with the Common Name : lab.local.
To get a Subordinate CA’s certificate, we need to generate a CSR.
You can use openssl tool or one cms node to generate a CSR with Common Name : lab.local as follow:
cms1>pki csr adcert CN:lab.local OU:CCNP O:Collaboration L:lab ST:local C:US
To create the Bundle CA chain certificate, in txt file Past the Subordinate certificate first and then past the Root CA certificate at the end, save the file with .cer extension. Name it for example Bundle-CA.cer.
Since CMS 3.0, we need to use Certificate trust chains or full chain trust. It is a single file (with an extension of.cer) holding a copy of the Root CA’s certificate, all intermediate certificates in the chain and the Entity or Server certificate.
When you build a certificate trust chain, as required for Web bridge 3, it is built with the Entity certificate (cmscert.cer) on top, and intermediate in the middle (adcert.cer), and root CA (Root-CA.cer) at the end. Save the file with a name cms-chain.cer.
Copy the certificates cmscert.cer with the private key, Bundle-CA.cer and cms-chain.cer to all nodes using WinSCP.
Enabling the Web Admin Service
By default, Web Admin listens on HTTPS port of 443. However, we will enable the Web Bridge for conference users and this service will be available on the default HTTPS port 443. To enable both services to co-exist, we will configure Web Admin to listen on port 445.
On cms1, cms2 and cms3, specify the interface and HTTPS port 445 for the web interface.
For the certificate to be used, specify the certificate cmscert created previously with the relevant key, route HTTP requests to HTTPS, finally activate the web admin service.
Enabling the CallBridge service
Configure callbridge on cms1, cms2 and cms3 to listen on the interface a, specify the certificate cmscert created in previously with the relevant key, restart the callbridge
Enabling the WebBridge 3 service
On cms1, cms2 and cms3, enter the following commands to enable the webbridge3 and c2w connection between the webbridge and callbridge.
On cms1, cms2 and cms3 verify the WebAdmin status.
On cms1, cms2 and cms3 verify the CallBridge status.
On cms1, cms2 and cms3 verify the WebBridge status.
CallBridge cluster configuration
On the web GUI of the cms1 navigate to Configuration > Cluster.
Under the section Call Bridge Identity, enter a Unique name for this Callbridge: cms1.
Click Submit.
Under the section Clustered Call Bridge, add each Call bridge unique name to the cluster including this node. In our scenario add cms1 in Unique name section. Under the Address section add https://10.1.5.61:445. Add cms2 in Unique name section. Under the Address section add https://10.1.5.62:445. Add cms3 in Unique name section. Under the Address section add https://10.1.5.63:445.
Repeat the same steps for cms2 and cms3.
CallBridge to WebBridge connection C2W configuration
On cms1 GUI navigate to Configuration > API.
In the Filter section, type “webbridges”. Click Create New. Populate the url field with the following: url: c2w://cms1.lab.local.com:9999, then click Create.
Repeat the same configuration for url: c2w://cms2.lab.local.com:9999, c2w://cms3.lab.local.com:9999, https://join.lab.local.com and https://meet.lab.local.com.
On cms2 and cms3, verify that the replication is successful.
Active Directory integration
In the Single Combined Server deployment, you can configure the integration with Active Directory using the Active Directory page on the Web Admin interface. However, this page only allowed you to specify one instance of Active Directory server and one directory and filter. What happens if you are deploying a cluster of Cisco Meeting Server in an environment where there are multiple Active Directory servers or users are in different directories on the same server? Also, the Active Directory configuration must be done manually in each node. Configuring via the API allows you to specify multiple Active Directory server, directories, and mapping templates to give you complete flexibility to match any environment.
On cms1 GUI, navigate to Configuration > API, locate the ldapServer instance. Configure the following parameters to connect and authenticate the callbridge service to Active Directory.
Locate the ldapMapping instance. Configure the following attributes for spaces creation.
LDAP Source setting brings together the LDAP server and LDAP mapping objects to define an LDAP source. It is on the LDAP source that you define which LDAP server, LDAP mapping template, directory, and filters that need to be applied to extract and create the user accounts. locate the ldapSource instance. Configure the search directory, associate the LDAP Server and the LDAP Mapping.
LDAP Syncs initiates the synchronization to the LDAP/AD server. The equivalent of clicking the Sync button on the Active Directory Configuration page on the Web Admin. Click the Create new button and associate the LDAP Source then click the Create button.
On cms1 GUI, navigate to Status > Users. It will display the users imported from Active Directory.
Navigate to Configuration > Spaces. It should display the spaces that were created from the imported users.
On cms2, verify that the AD synchronization is fine.
On cms3, verify that the AD synchronization is fine.
Cisco Unified Communication Manager Dial Plan
On BR-CUCM, create a SIP Trunk toward cms1 10.1.5.61, named SIP_Trunk_To_CMS1.
In the SIP Information, enter the IP address 10.1.5.61 of CMS1, and select the Trunk_SIP_Security_Profile_CMS and Standard SIP Profile CMS. In Normalized Script, Select cisco-meeting-server-interop. In the Rerouting Calling Seach Space, select CMS-CSS, this CSS is mandatory for CallBridge Group feature.
Create a SIP Trunk toward cms2 10.1.5.62, named SIP_Trunk_To_CMS2.
In the SIP Information, enter the IP address 10.1.5.62 of CMS2, and select the Trunk_SIP_Security_Profile_CMS and Standard SIP Profile CMS. In Normalized Script, Select cisco-meeting-server-interop. In the Rerouting Calling Seach Space, select CMS-CSS, this CSS is mandatory for CallBridge Group feature.
Create a SIP Trunk toward cms3 10.1.5.63, named SIP_Trunk_To_CMS3.
In the SIP Information, enter the IP address 10.1.5.63 of CMS1, and select the Trunk_SIP_Security_Profile_CMS and Standard SIP Profile CMS. In Normalized Script, Select cisco-meeting-server-interop. In the Rerouting Calling Seach Space, select CMS-CSS, this CSS is mandatory for CallBridge Group feature.
Create a Route Group named RG-CMS, in the Available Devices, select the SIP Trunks created previously (SIP_Trunk_To_CMS1, SIP_Trunk_To_CMS2 and SIP_Trunk_To_CMS3). In the Distribution Algorithm section, select Circular.
Create a Route List named RL-CMS, click Add Route Group button and add the RG-CMS Route Group.
Create a sip route patterns so you can route calls from BR-CUCM when users dials to conference using URIs. For this, navigate to Call Routing > SIP Route Pattern and click Add New.
Configure the following parameters:
- Pattern Usage: Domain Routing
- IPv4 Pattern: ipdemystify.com
- SIP Trunk/Route List: RL-CMS
Cisco Meeting Server Dial Plan
On cms1 GUI, navigate to Configuration > Incoming calls.
Add two incoming rules with Domain name ipdemystify.com and demo.com. Ensure that the Targets spaces is set to Yes.
The domain name ipdemystify.com and demo.com will be used by users in the host portion of URI to dial into a conference or space.
On cms2 and cms3, verify that the replication of the incoming and outgoing rules are replicated successfully.
Integration of new node cms4 with CallBridge and WebBridge without the database
Currently the three nodes cms1, cms2 and cms3 have the CallBridge and the Database services co-located. The CallBridge service once enabled connects automatically to the local database to retrieve the cluster-wide configuration.
We want to add the cms4 with the CallBridge and WebBridge only, in this case we need to 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 server certificate cmscert created previously to include the FQDN cms4.lab.local in the Subject Alternative Name SAN, generate the new certificate then modify the certificate chain 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 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.
In this scenario, we use the second option, we will create a dedicated certificate for cms4.
First, ssh to cms4 and generate a CSR with the following informations:
cms4> pki csr cms4cer CN:cms4.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:cms4.lab.local,join.lab.local,meet.lab.local,lab.local
Using the CA, submit the CSR in order to generate the certificate.
Below the certificate of cms4 generated using the CSR created previously.
SSH to cms1 to display the certificate cmscert used for cms1, cms2 and cms3. The SAN does not include the FQDN of cms4, this is why we need a dedicated certificate for cms4.
Create a Trust Chain Certificate for cms4, put the Entity certificate (cms4cert.cer) on top, and intermediate in the middle (adcert.cer), and root CA (Root-CA.cer) at the end. Save it with a name CMS4-Chain.cer.
Copy the certificates cms4cert.cer and CMS4-Chain.cer to cms4 using WinSCP.
Now the server certificate cms4cert.cer and the trust chain certificate CMS4-Chain.cer are ready.
Enable the WebAdmin, CallBridge and the WebBridge services.
Configure the cms4 to connect to the primary database node using the following command.
First copy the server and client database certificates with their private keys to cms4 using WinSCP.
- database cluster certs dbcert.key dbcert.cer dbclt.key dbclt.cer Root-CA.cer
- database cluster connect cms1.lab.local
Verify the synchronization between the database cluster and cms4.
Add the cms4 to the CallBridge cluster, navigate to Configuration > Cluster. In the Call Bridge identity section, configure a Unique name cms4, in the Clustered Call Bridges section, add the Unique name cms4 with the Address https://10.1.5.64:445.
On cms1, cms2 and cms3, verify that the replication is successful and the status shows a message connection active.
Configure the c2w connection between the webbridge and the CallBridge cms4 with the url c2w://cms4.lab.local:9999.
Integrate the new CallBridge cms4 with BR-CUCM.
On BR-CUCM, create a SIP Trunk toward cms3 10.1.5.64, named SIP_Trunk_To_CMS4.
In the SIP Information, enter the IP address 10.1.5.64 of CMS4, and select the Trunk_SIP_Security_Profile_CMS and Standard SIP Profile CMS. In Normalized Script, Select cisco-meeting-server-interop. In the Rerouting Calling Seach Space, select CMS-CSS, this CSS is mandatory for CallBridge Group feature.
Edit the Route Group named RG-CMS, in the Available Devices, add the SIP Trunk SIP_Trunk_To_CMS4.
Enabling Recorder and Streamer services on a dedicated server
SSH to cms-str-rec, generate a CSR with the Common Name the FQDN of the streamer/recorder server cms-str-rec.lab.local.
cms-str-rec>pki csr cms CN: cms-str-rec.lab.local OU:CCNP O:Collaboration L:lab ST:local C:US subjectAltName:10.1.5.65
Using the CSR, generate a certificate, name it cms.cer.
Enable the Recorder. Access the CLI of cms-str-rec, enter the following commands to configure cms-str-rec as recorder, specify the certificate cms.cer and the NFS server.
Verify the configuration using the recorder command.
Enable the streamer. Configure the listening interface of the streamer and the SIP TCP and TLS ports to listen on using the following command.
Configure the certificates to be used for the SIP streamer. Specify the key file, certificate, and CA trust bundle.
Enable the streamer. All message must show "SUCCESS" as below displayed below.
Verify the streamer configuration.
On the web GUI of cms1, navigate to Configuration > API. In the Filter section, type “callprofile”
Click the Create new button and enter the following informations:
- recordingMode: manual
- sipRecorderURI: record@recorder.com
- streamingMode: select manual from the drop menu
- sipStreamerURI: streamer@streamer.com
Return to object field.
In the Filter section, type “system”. Click on the arrow to select /api/v1/system/profile
Click the View or edit button for system profiles.
Then select Choose for callProfile, and then Select the callProfile previously created.
Click Modify.
Navigate to Configuration > Outbound calls.
Configure an outbound Dial Plan rule to match the domain used in recorderUri to route.
- Domain: recorder.com
- SIP proxy to use: 10.1.5.65:8443
- Encryption: Auto
- click And New
Configure an outbound Dial Plan rule to match the domain used in streamerUri to route.
On cms1 GUI navigate to Configuration > Outbound calls.
Create a new Outbound rule with the following informations:
- Domain: cms-str.lab.local
- SIP proxy to use: 10.1.5.65:6000
- Encryption: Unencrypted
- click And New
- Domain: cms-str.lab.local
- SIP proxy to use: 10.1.5.65:6001
- Encryption: Encrypted
- click And New
In the Filter section, type “cospace”.
Click the object ID for jdoe Meeting Space.
Modify the space to add “StreamURL”. The 'streamURL' in the following format: rtmp://a.rtmp.youtube.com/live2/y9vy-58dp-krbu-rh1m-6vd9
Click Modify.
From the jdoe-pc, open a web browser and type the Guest URL https://join.lab.local.
Click the Join a meeting button.
Enter the Meeting ID 11011 of the space named Webex Meeting created previously.
Click the Meeting Control Icon. You should see the Recording and Streaming Control. Click the Streaming and the Recording button.
The Streaming and the Recording buttons will go to a solid blue dot to indicate the streaming and the recording have started.
Access the Cisco Meeting Management, under the Meetings section, you should see that the Streaming and the Recording are launched for the meeting named Webex Meeting.
Access the cms1 GUI. Navigate to Status > Calls, verify that in addition to jdoe call, the sip streaming and sip recording calls are also connected.
In the youtube channel, the meeting is streamed.
Enabling the Scheduler service
The Scheduler configuration requires the reconfiguration of the certificates so that cms1, cms2, cms3 and cms3 WebBridges will use the same Trust Chain Certificate.
Generate a new CSR for server certificate including the FQDNs of cms1, cms2, cms3 and cms4 and in addition the URLs guest join.lab.local and meet.lab.local. Name it onecert.cer.
Using the Bundle-CA and the onecert certificates, create a Trust Chain Certificate that the WebBridge will use. Name it onecert-chain.cer.
Configure the cms1, cms2, cms3 and cms4 to use the new certificate.
On cms1.
On cms2.
On cms3.
On cms4.
Enabling the Scheduler
Configure the scheduler to use the certificate.
The scheduler has its own HTTPS interface which if enabled, can be used to configure scheduler meetings using the scheduler APIs.
Access the cms1 GUI. Configure the scheduler to use the certificate.
- Configure a certificate key pair for C2W.
- Configure the scheduler to be able to trust each Web Bridge it connects to.
- Configure the HTTPS server listen interface.
- Configure a certificate key pair for HTTPS.
To enable the Scheduler to send email notifications via the SMTP with Auth Login, configure the email server to listen on a specified port for the SMTP protocol, enable the SMTP server to support Auth Login, and configure a user account for authentication. This account configured on the MMP must have appropriate permissions to be able to send emails on behalf of web app users.
Configure the email server and port, and et the email protocol to SMTP.
From version 3.4 meeting invites can be sent to all the participants from a common email
address. The MMP command scheduler email common-address <address@mail.domain> "<Display name>" configures the common email address and a display name on the Meeting Server. The Scheduler sends the meeting invites from the common email address to the participants.
If the common email address is left blank, the Scheduler sends the email invites from the organizer’s email address.
To enable the Scheduler to send email notifications via the SMTP, configure the email server to listen on a specified port for the SMTP protocol.
Set the username to be used for authentication.
Enable the Scheduler.
Verify the scheduler configuration.
Verify the status of the schedule. The output should show the webbridges cms1, cms2, cms3 and cms4 with the state CONNECTED.
From the jdoe pc, open a web browser, type the Guest URL https://join.lab.local, login with the username jdoe@lab.local, you should see the Option Schedule Meeting displayed.
