CMS 2 6 1 Intermediate Lab v2

Lab Guide
Cisco dCloud
Cisco Meeting Server 2.6.1

Intermediate Features Hands-On Lab
Last Updated: 04-July-2019
About This Lab

This lab consists of a preconfigured standalone Cisco® Unified Communication Manager (Unified CM) and
Cisco TelePresence® Management Suite (TMS), two cluster-combined Cisco Meeting Server (CMS), and a third
CMS instance to be used for recording and streaming. Each CMS server has the core components
preconfigured with self-signed certificates installed. The goal of the lab is to configure the Unified CM, TMS,
and CMS to demonstrate new features including Active Control, Callbridge groups, recording, and live
streaming. Additionally, you will get a preview of upcoming enhancements including support for CMS edge
service in Expressway™ (unified edge), and Cisco Meeting Management (CMM). CMM is a new tool that will
initially allow control of active meetings, but will ultimately grow to cover control, configuration, and
management of the CMS system.
NOTE: CMS PMP and SMP licenses are both included on the servers used in this lab.
Each scenario in this preconfigured lab is standalone and can be completed in any order. This guide includes:
About This Lab
Resources
Requirements
About This Solution
Topology
Session Users
Get Started
Scenario 1. Database Clustering

© 2019 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 129
Lab Guide
Cisco dCloud
Scenario 2. Cluster Callbridges
Scenario 3. XMPP Clustering
Scenario 4. Expressway Unified Edge
Scenario 5. Cisco Meeting Management
Scenario 6. Configure CMS as Meeting Recording and Streaming Server
Appendix A.Generate Database Certificates and Get Them Signed
What’s Next?
Lab Guide
Cisco dCloud
Resources
For more information:
• Visit the Cisco dCloud help page: https://dcloud-cms.cisco.com/help.
• Access all available Cisco dCloud content: https://dcloud.cisco.com.
• Contact the Technical Lead or the Business Development Manager for your region: https://dcloud-
cms.cisco.com/help/dcloud-collaboration-contacts.
Requirements
The table below outlines the requirements for this preconfigured demonstration.
Required Optional
Laptop with Cisco AnyConnect® None
About This Solution

Cisco Meeting Server (CMS) is the lead offer of Cisco on premise video conferencing solution that brings video,
audio and web communication together to meet the collaboration needs of the modern workplace. CMS is the
next generation conferencing platform that brings greater scale and interoperability as well as improved
conferencing capabilities. Participants can join meetings hosted on CMS using standard SIP endpoints (Cisco
room or desktop video systems or third-party video endpoints) or Cisco Meeting App (CMA). CMA consists of
mobile, desktop and WebRTC native or compatible browsers clients.
With v2, Cisco Meeting Server is now optimized to be deployed with Cisco Unified CM for call control. This
enables customers with Cisco UC deployment to fully integrate with our latest conferencing capabilities such as
distributed conferencing, and existing UC features such ad-hoc conference escalation, scheduled conferences
using Exchange and personal Spaces. The objective for this session is to understand the latest features and
innovations included in the CMS platform, and deploy them as part of the Cisco UC platform to create the best
collaborative video experience for customers.
Benefits of migrating to the CMS solution:
• One software solution for audio, video and web conferencing
• Rich interoperability with support for standards based endpoints, WebRTC, and Skype for Business
• Scalable conferencing with WAN bandwidth optimization
• Integration with other workplace tools via API
• Support for immersive Cisco TelePresence endpoints
Multiparty licensing is the primary licensing model used for CMS. Multiparty licensing is available in two
variations: Personal Multiparty plus (PMP plus) licensing, which offers a named host license, and Shared
Lab Guide
Cisco dCloud
Multiparty plus (SMP plus) licensing, which offers a shared host license. Both Personal Multiparty plus and
Shared Multiparty plus licenses can be used on the same server.
Personal Multiparty Plus License
Personal Multiparty plus (PMP+) provides a named host license assigned to each specific user who frequently
hosts video meetings. This can be purchased through Cisco UWL Meeting (which includes PMP+). Personal
Multiparty plus is an all-in-one licensing offer for video conferencing. It allows users to host conferences of any
size (within the limits of the Cisco Meeting Server hardware deployed). Anyone can join a meeting from any
endpoint, and the license supports up to full HD 1080p60 quality video, audio, and content sharing.
Shared Multiparty Plus License
Shared Multiparty plus (SMP+) provides a concurrent license that is shared by multiple users who host video
meetings infrequently. It can be purchased at a reduced price when purchased with room endpoints (SX / MX /
RMK), or it can be purchased separately. Shared Multiparty plus enables all employees who do not have Cisco
UWL Meeting licenses to access video conferencing. It is ideal for customers that have room systems deployed
that are shared among many employees. All employees, with or without a Cisco UWL Meeting license have the
same great experience, they can host a meeting with their space, initiate an ad-hoc meeting or schedule a
future one. Each shared host license supports one concurrent video meeting of any size (within the limits of the
hardware deployed). Each Shared Multiparty plus license includes one Rich Media Session (RMS) license for the
Cisco Expressway, which can be used to enable business-to–business (B2B) video conferencing.
Lab Guide
Cisco dCloud
Topology
This content includes preconfigured users and components to illustrate the scripted scenarios and features of
the solution. Most components are fully configurable with predefined administrative user accounts. You can see
the IP address and user account credentials to use to access a component by clicking the component icon in
the Topology menu of your active session and in the scenario steps that require their use.
Session Details
Name Description Host Name (FQDN) IP Address Username Password
CUCM1 Cisco Unified Com m u nica tions Ma nager u cm 1.dclou d.cisco.com 198.18.133.3 a dm inistra tor dClou d123!
12.5
IM & P IM & Presence 12.5 im p1.dclou d.cisco.com 198.18.133.4 a dm inistra tor dClou d123!
CUxN Cisco Unity Connection 12.5 cu c1.dclou d.cisco.com 198.18.133.5 a dm inistra tor dClou d123!
TMS TelePresence Ma nagem ent S uite 15.9.0 tm s1.dclou d.cisco.com 198.18.133.158 a dm inistra tor C1sco12345
TMSXE TMS Excha nge Extension 5.9 Tm sxe.dclou d.cisco.com 198.18.135.36 a dm inistra tor C1sco12345
Exp-C Expresswa y-C (Core) X12.5.2 exp-c-1.dclou d.cisco.com 198.18.133.152 a dm in dClou d123!
cms1 Cisco Meeting S erver 2.6.1 cm s1.dclou d.cisco.com 198.18.2.175 a dm in dClou d123!
Lab Guide
Cisco dCloud
db1 Cisco Meeting S erver 2.6.1 db1.dclou d.cisco.com 198.18.2.150 a dm in dClou d123!
cmm Cisco Meeting Ma na ger 2.6.0 cm m .dclou d.cisco.com 198.18.135.77 a dm in dClou d123!
rev1 vBrick REV 7.25 rev1.dclou d.cisco.com 198.18.135.46 a dm inistra tor dClou d123!
dme1 vBrick Distribu ted Media Engine dm e1.dclou d.cisco.com 198.18.135.47 a dm in dClou d123!
hap1 vBrick HA Proxy ha p1.dclou d.cisco.com 198.18.135.43 vbrick dClou d123!
openfiler O penFiler NFS open- 198.18.135.39 openfiler dClou d123

nfs1.dclou d.cisco.com
Exp-E Expresswa y-E (Edge) X12.5.2 exp-e-1.dclou d.cisco.com 198.18.1.5 a dm in dClou d123!
Exchange Microsoft Excha nge 2016 m a il1.dclou d.cisco.com 198.18.135.52 a dm inistra tor C1sco12345
AD1 AD (2012) a nd DNS server a d1.dclou d.cisco.com 198.18.133.1 a dm inistra tor C1sco12345
Workstation 1 Windows 10 wkst1.dclou d.cisco.com 198.18.1.36 a m ckenzie dClou d12345!
Session Users
The table below contains details on preconfigured users available for your session.
Endpoint
User Name User ID Password Devices Phone Extension Workstation
Adam McKenzie a m ckenzie dClou d12345! Ja bber +1 408 555 6016 6016 wkst1
Monica Cheng m cheng dClou d12345! Ja bber +1 408 555 6030 6030 wkst3
Anita Perez a perez dClou d12345 Ja bber +1 212 555 6017 6017 wkst2 (O UTS IDE)
Lab Guide
Cisco dCloud
Get Started
BEFORE PRESENTING
Cisco dCloud strongly recommends that you perform the tasks in this document with an active session
before presenting in front of a live audience. This will allow you to become familiar with the structure of the
document and content.
It may be necessary to schedule a new session after following this guide in order to reset the environment to
its original configuration.
PREPARATION IS KEY TO A SUCCESSFUL PRESENTATION
Follow the steps to schedule a session of the content and configure your presentation environment.
1. Browse to dcloud.cisco.com, select the location closest to you, and log in with your Cisco.com credentials.
2. Register and configure your router if this is the first time you will use the router with dCloud. [Show Me
How]
3. Schedule a session. [Show Me How]
4. Test your connection. [Show Me How]
5. Verify that the status of your session is Active in My Dashboard > My Sessions.
NOTE: It may take up to 30 minutes for your session to become active.
6. Click View to open the active session.

7. For best performance, connect to the lab with Cisco AnyConnect VPN [Show Me How] and the local RDP
client on your laptop [Show Me How]
NOTE: You can also connect to the workstation using the Cisco dCloud Remote Desktop client [Show Me How].
The dCloud Remote Desktop client works best for accessing an active session with minimal interaction.
Lab Guide
Cisco dCloud
Scenario 1. Database Clustering

In this chapter, we will set up a database cluster between the three CMS nodes. Each Callbridge will connect to
the master database. The slave database’s are in place for resilience. All certificates for this scenario have been
created and prepositioned on the CMS servers. If you wish to go through the optional process of manually
generating the certificates, the procedure can be found in Appendix A.
If not already connected, use Cisco AnyConnect to VPN into your lab session. The login credential will be
provided by your proctor or displayed on the session details tab for your active session. Create an RDP
connection to Workstation 1 (198.18.1.36) and login with:
• Username: dcloud\amckenzie
• Password: dCloud12345!
Task 1. Set up the Database Cluster
We will start setting up the database cluster here. We specify which database client and server certificates to
use.
1. Launch Putty from the desktop and connect to cms-db1 (db1.dCloud.cisco.com), login with:
• Username: admin
NOTE: SYNTAX database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt> where
you specify first the database server private key and certificate, next the database client private key and
certificate. <ca_crt> is the certificate bundle containing the intermediate and root certificates from the CA who
signed the certificates. Creating a bundle is explained more in detail in the Certificate Guide under section 1.2.4
Certificate bundles.
2. From the db1> prompt, enter the following commands:

database cluster certs dbSERVER.key dbSERVER.cer dbCLIENT.key dbCLIENT.cer CABundle.cer
NOTE: Beware that names of certificates are case sensitive. You can issue pki list to review the exact file
names.
3. Specify which interface to use for the database clustering:

database cluster localnode a
4. Initialize the master database:

database cluster initialize
WARNING!!!
Are you sure you wish to initialize this node as a new database cluster? (Y/n)
5. Respond to dialog by pressing shift-Y.
Lab Guide
Cisco dCloud
NOTE: The dialog is waiting for you to respond on to initialize the cluster. The response is a capital “Y”, if you
just press a lowercase “y”, the dialog will just sit and wait for a “Y” or “n”.
Output:
The contents of this node's database will become the master version of the database in the new cluster.
The callbridge and web administration will restart at the end of this procedure.
Server certificate/key validated..
Client certificate/key validated..
Please wait...
Initialization started...
6. Verify that this is now the master database.

database cluster status
Output:
Status : Enabled
Nodes:
198.18.2.150 (me) : Connected Master
Node in use : 198.18.2.150
Interface : a
Certificates
Server Key : dbSERVER.key
Server Certificate : dbSERVER.cer
Client Key : dbCLIENT.key
Client Certificate : dbCLIENT.cer
CA Certificate : CABundle.cer
Last command : 'database cluster initialize' (Success)
Task 2. Attach Cisco Meeting Server (CMS) to the master Database Cluster
1. Launch Putty from the desktop and connect to cms1 (cms1.dCloud.cisco.com), login with:
• Username: admin
2. From the cms1> prompt, specifying the database client and server certificates from the previous task (step
2), enter the following commands.
database cluster certs dbSERVER.key dbSERVER.cer dbCLIENT.key dbCLIENT.cer CABundle.cer
3. Specify the interface to use:

database cluster localnode a
4. Connect to the master database.
NOTE: SYNTAX database cluster join <hostname/IP> where <hostname/IP> would refer to the master database.
database cluster join db1.dcloud.cisco.com
Lab Guide
Cisco dCloud
5. Respond to dialog by pressing shift-Y.

Output:
WARNING!!!
Are you sure you wish to join this node to an existing database cluster? (Y/n)
The contents of this node's database will be destroyed!
The callbridge and web administration will restart at the end of this procedure.
Server certificate/key validated..
Client certificate/key validated..
Please wait...
Join started...
6. Verify the status of the database cluster.

Output:
database cluster status
Status : Enabled
(Started 8 seconds ago)
Nodes:
198.18.2.150 : Connected Master
198.18.2.175 : Connected Slave ( In Sync )
Node in use : 198.18.2.150
Interface : a
Certificates
Server Key : dbSERVER.key
Server Certificate : dbSERVER.cer
Client Key : dbCLIENT.key
Client Certificate : dbCLIENT.cer
CA Certificate : CABundle.cer
Last command : 'database cluster join db1.dcloud.cisco.com' (Success)
7. Repeat steps 1-6 to join cms2.dcloud.cisco.com and cms3.cfbdcloud.cisco.com to the database cluster
as well.
Lab Guide
Cisco dCloud
Scenario 2. Cluster Callbridges

In this scenario, the Callbridges will be clustered. This will allow the conferences to be established on multiple
nodes and linked via distribution links.
Task 1. Set up Callbridge
The Callbridges have already been set up in your lab. You can review the configuration and certificates to
ensure they are correct.
1. On Workstation 1, Launch Putty from the desktop and connect to cms1 (cms1.dCloud.cisco.com), login
with:
• Username: admin
2. From the cms1> prompt, enter the following commands.
cms1> callbridge
Listening interfaces : a
Preferred interface : none
Key file : OneCert.key
Certificate file : OneCert.cer
Address : none
CA Bundle file : CABundle.cer
NOTE: A cluster certificate was already created on the setup, which you can reuse for the Callbridge. If you
would like to review this certificate, you can use: pki inspect <file>
3. Repeat step 1 for cms2 and cms3 to verify their configurations.
Task 2. Configure the Cluster
1. On Workstation1, click in a browser tab and navigate to Collaboration Admin Links > Cisco Meeting
Server – 1.
2. Click Cisco Meeting Server – 1 and login with
• Username: admin
3. On the web GUI of the CMS navigate to Configuration > Cluster.
4. Under the section Call Bridge Identity, enter a Unique name for this Callbridge: cms1.
5. Click Submit.
6. Open additional tabs in the browser and repeat steps 1 to 5 for cms2 and cms3, entering their respective
names into the Unique name field and Submit.
Lab Guide
Cisco dCloud
7. On cms1 still within the Cluster configuration page, under the section Clustered Call Bridge, add each Call
bridge unique name to the cluster including this node. Configure the following parameters, but leave Peer
link SIP domain empty.
Unique name Address
cms1 https://198.18.2.175:445
cms2 https://198.18.2.185:445
cms3 https://198.18.2.147:445
NOTE: This is only done on cms1 since all nodes share the same database.
Task 3. Create the Distribution Links
Now the Callbridge cluster is created; however, when a conference needs to be extended over multiple
Callbridge, CMS needs to be able to reach the other nodes as per the outbound call rules.
1. On Workstation1, click in a browser tab to navigate to Collaboration Admin Links > Cisco Meeting Server
– 1.
2. Click Cisco Meeting Server – 1 and login with:
• Username: admin
3. On the web GUI of the CMS navigate to Configuration > Outbound calls.
Lab Guide
Cisco dCloud
4. Add New outbound call rule for each Callbridge. Configure the following parameters, leaving other settings
as default.
Domain SIP proxy to use Priority
198.18.2.175 198.18.2.175 100
198.18.2.185 198.18.2.185 99
198.18.2.147 198.18.2.147 98
5. Navigate to Configuration > Incoming calls.

6. Add New inbound call rule for the FQDN of each CMS. Configure the following parameters, leaving other
settings as default. This will allow us to make calls directly to a specific CMS for testing.
Domain name Priority
cms1.dcloud.cisco.com 10
Task 4. Configure CUCM for Calls towards CMS
In this task, you configure the call routing and ad hoc conferencing on CUCM).
1. On Workstation 1, In a new browser tab navigate to Collaboration Admin Links > Cisco Unified
Communications Manager.
2. Click Cisco Unified Communications Manager and login within:
• Username: administrator
Lab Guide
Cisco dCloud
3. The SIP Trunk Security profiles should already be in place. On the web GUI of the UCM, navigate to System
> Security > Sip Trunk Security Profile, then click Find.
4. Click dCloud_TLS_Security_Profile_CMS and verify that the X.509 Subject Alternative Name entries for
CMS2 and CMS3 are included in the SIP Security Profile.
Name = dCloud_TLS_Security_Profile_CMS
Device Security Mode = Encrypted
Incoming Transport Type = TLS
Outgoing Transport Type = TLS
X.509 Subject Name = cms1.dcloud.cisco.com,cms2.dcloud.cisco.com,cms3.dcloud.cisco.com
Incoming port = 5061
Accept Replaces Header = check the box ( As we will use the bridge for Call Bridge grouping)
NOTE: The X.509 Subject Name value needs to correspond to the subject CN or SAN value as seen in the CMS
Callbridge certificate. On the CLI for CMS, you can check this by first issuing the callbridge command to see
the configured certificate file. Next, use the pki inspect <file> command to inspect the file and check what is
the CN= value set under Subject.
REMARK: If it is successfully configured, the trunk status in CUCM would go to Full Service. This can take a
moment to show.
5. Create a sip route pattern so you can route calls from CUCM directly to each CMS. For this, navigate to Call
Routing > Sip Route Pattern and click Add New.
6. Configure the following parameters from below.
Pattern Usage = Domain Routing
IPv4 Pattern = cms1.dcloud.cisco.com
Description = CMS1
Route Partition = dCloud_PT
SIP Trunk/Route List = dCloud_SIP_Trunk_CMS1
7. Click Save.
8. Repeat steps 5 and 7, to add a SIP Route Pattern for cms2 and cms3, entering in their respective domain
name in the IPv4 Pattern, description field and corresponding SIP trunk
9. In order to allow for ad-hoc video conferencing, you must also add CMS as a conference bridge on CUCM.
Navigate to Media Resources > Conference Bridge. Click Add New.
10. Configure the new conference bridge with the following parameters.
Conference Bridge Type = Cisco Meeting Server
Conference Bridge Name = cfb_cms1
Description = CMS1
Sip Trunk = dCloud_SIP_Trunk_CMS1
Username / Password = admin/dCloud123!
HTTPS Port = 445
NOTE: Remember that the webadmin on CMS runs on port 445. CUCM will reach out to the webadmin in order
to enable ad hoc video conferencing.
11. Click Save, Apply Config, and Reset once completed.
Lab Guide
Cisco dCloud
12. Now the conference bridge should show as Registered with cucm1.dcloud.cisco.com.
13. Repeat steps 9 to 11, to add a Conference Bridge for cms2 and cms3, respectively changing the name for
the Conference Bridge Name, Description fields, and selecting the respective SIP Trunk.
14. Add the conference bridges to the media resource group dCloud-CMS_CFB, navigate to Media Resources
> Media Resource Group.
15. In Devices for this Group section, highlight the previously created conference bridges in the Available
Media Resources section (may need to scroll down) and click the down arrow to move to Selected Media
Resources.
NOTE: The Media Resource Group is already part of the Media Resource Group List – dCloud_MRGL
Task 5. Test Calling into CMS Space and Distribution Links
1. If required, RDP to Workstation 1 (198.18.1.36) and log in with these credentials:

2. From the desktop, launch Cisco Jabber® client.
3. RDP to Workstation 2 (198.18.1.37), log in with these credentials:
• Username: dcloud\aperez
4. From the desktop launch Cisco Jabber client.
5. On Workstation 1, make a call to amckenzie.space@cms1.dcloud.cisco.com using the Jabber® client.
6. In a new browser tab navigate to Collaboration Admin Links > Cisco Meeting Server – 1.
7. Click Cisco Meeting Server-1, login in with the following credentials:
• Username: admin
8. On the web GUI of the CMS, navigate to Status > Calls.
9. Check that you can see this active call.
10. On Workstation 2, make a call to amckenzie.space@cms2.dcloud.cisco.com using the Jabber client.
Lab Guide
Cisco dCloud
11. On Workstation 1, return to the browser tab in step 9 and check the call status.
12. You will observe the distribution link is active between CMS 1 and CMS2.
13. You may end the calls.
Task 6. Test Ad Hoc Meeting Configuration
1. Test ad hoc meetings by placing a call between the Jabber clients on Workstations 1, 2, and 5.
2. (198.18.1.40), log in with these credentials:
• Username: dcloud\cholland
3. From the desktop, launch the Cisco Jabber client.
4. On Workstation 1, make a call to aperez@dcloud.cisco.com using the jabber client.
5. On Workstation 2, answer the incoming call from Adam McKenzie.
6. Conference Charles Holland into the active call between Adam and Anita.
7. On Workstation 1 in a new browser tab, navigate to Collaboration Admin Links > Cisco Meeting Server –
1.
8. Click on Cisco Meeting Server-1, login in with the following credentials:
• Username: admin
9. On the web GUI of the CMS navigate to Status > Calls.
Lab Guide
Cisco dCloud
10. Check that you see this call is active.
11. You may end the call.
Lab Guide
Cisco dCloud
Scenario 3. XMPP Clustering
Task 1. Creating the XMPP Cluster
1. Create an RDP connection to Workstation 1 (198.18.1.36) and log in with:

2. Launch Putty from the desktop and ssh to cms1.dCloud.cisco.com, login with:
• Username: admin
3. From the cms1> prompt, enter the following commands to remove the current XMPP configuration.
cms1> xmpp disable
cms1> xmpp reset
4. Set the XMPP domain and specify the interface to use.

cms1> xmpp domain dcloud.cisco.com
cms1> xmpp listen a
5. Specify the certificate that will be used by the XMPP service.

cms1> xmpp certs OneCert.key OneCert.cer CABundle.cer
cms1> xmpp cluster trust OneCert.cer
6. Repeat steps 2-5 for cms2 (cms2.dcloud.cisco.com) and cms3 (cms3.dcloud.cisco.com).
7. Return back to ssh session to cms1. Enable the XMPP service.

cms1> xmpp enable
SUCCESS: Callbridge activated
SUCCESS: Domain configured
SUCCESS: Key and certificate pair match
SUCCESS: certificate verified against CA bundle
SUCCESS: XMPP server enabled
8. Add each of the Callbridges. Copy the secrets to a text file (Notepad) for each Call bridge as they are
required later.
cms1> xmpp callbridge add cms1
Success : true
Callbridge : cms1
Domain : dcloud.cisco.com
Secret : X0OWYaMMW2GFhxFFAb1
Success : true
Callbridge : cms2
Secret : k1EyHepeCHUJqiYsAb1
Success : true
Callbridge : cms3
Secret : LrctbWOEXoX3suMrAb1
Lab Guide
Cisco dCloud
9. Disable XMPP again.

cms1> xmpp disable
10. Enable and initialize the cluster.

cms1> xmpp cluster enable
cms1> xmpp cluster initialize
11. Enable XMPP again.

cms1> xmpp enable
12. Review the cluster status.

cms1> xmpp cluster status
State: LEADER
List of peers
198.18.2.175:5222 (Leader)
Last state change: 2018-Mar-23 12:02:05
Key file : cluster.key
Certificate file : cluster.cer
Trust bundle : cluster.cer
13. Connect with putty to cms2 to add this node to the XMPP cluster.
14. Enable XMPP.
cms2> xmpp enable
15. Add for each Callbridge the secret to this XMPP. When prompted for the secret, use the value which was
created on cms1.
cms2> xmpp callbridge add-secret cms1
Enter callbridge secret
Success : true
Callbridge : cms1
Secret : X0OWYaMMW2GFhxFFAb1
Success : true
Callbridge : cms2
Secret : k1EyHepeCHUJqiYsAb1
Success : true
Callbridge : cms3
Secret : LrctbWOEXoX3suMrAb1
Lab Guide
Cisco dCloud
NOTE: Copy and Paste these values to Notepad for the XMPP Call bridges that got generated on cms1, you will
require them when updating the call bridge configuration for XMPP cluster in the next task. You can review
them by entering on cms1 xmpp callbridge list
16. Disable XMPP again.

cms2> xmpp disable
17. Enable the cluster.

cms2> xmpp cluster enable
18. Enable XMPP.

cms2> xmpp enable
19. Join this node with the XMPP server on cms1.

cms2> xmpp cluster join 198.18.2.175
Success
Current configuration:
Configuration 1:
- 11446069191905766969: 198.18.2.175:5222
Attempting to change cluster membership to the following:

205328030957580545: 198.18.2.185:5222 (given as 198.18.2.185:5222)
11446069191905766969: 198.18.2.175:5222
Membership change result: OK
Current configuration:
Configuration 1466:
- 205328030957580545: 198.18.2.185:5222
- 11446069191905766969: 198.18.2.175:5222
20. Review the cluster status.

State: FOLLOWER
List of peers
198.18.2.175:5222 (Leader)
198.18.2.185:5222
Last state change: 2018-Mar-23 12:11:05
Key file : OneCert.key
Certificate file : OneCert.cer
Trust bundle : OneCert.cer
21. Repeat steps 13-20 for cms3 (cms3.dcloud.cisco.com).
Task 2. Update the Callbridge Configuration for an XMPP Cluster
1. On Workstation 1, open a new browser tab and navigate to Collaboration Admin Links > Cisco Meeting
Server – 1.
Lab Guide
Cisco dCloud
2. Click Cisco Meeting Server – 1 and login with:

• Username: admin
3. On the web GUI of the CMS, navigate to Configuration > General.
4. Update the values for the XMPP server settings.
5. Set a Unique Call Bridge name to be the value as defined on the XMPP server in the previous step for this
cms, when the Callbridge got added using the xmpp callbridge add <cb_name> command. You can review
the name using the command xmpp callbridge list. (For example, refer to Step 8 and 15.)
6. Set Domain to dcloud.cisco.com.
7. Leave Server address empty.
NOTE: By leaving it empty, the Callbridge will leverage the _xmpp-component SRV record to discover the
xmpp server for this domain.
8. Update the shared secret to be what was defined on the XMPP server in the previous task. Click change to
unlock the field.
NOTE: You can review the XMPP secret by entering on the mmp interface: xmpp callbridge list
9. Click Submit.
10. Navigate to Status > General to review the status of the XMPP connection.
11. Repeat steps 1-10 for cms2 (cms2.dcloud.cisco.com) and cms3 (cms3.dcloud.cisco.com).
Task 3. LDAP
Importing users from an LDAP directory allows conference participants to log into the Cisco Meeting App using
their own account to manage their spaces and to join meetings. Participants can also join meetings as guest
users, however, guest users cannot manage meetings or create/manage spaces.
The LDAP import in the Meeting Server allows you to specify which users to target from an existing directory,
as well as the values to use for these accounts. In addition, the import feature optionally supports creating a
personal space for each imported user. Which users and specific values to import is a deployment-specific
decision. As an example configuration exercise, we will import all users from the Active Directory, set their login
that they will use, and then create a space for each user.
Lab Guide
Cisco dCloud
Currently on CMS2 and CMS3, there is no LDAP configuration set. This would make authentication fail.
1. On Workstation 1, in new browser tab (if required) navigate to Collaboration Admin Links > Cisco
Meeting Server – 2 and login with:
• Username: admin
2. On the web GUI of the CMS, navigate to Configuration > Active Directory.
3. Configure the following parameters for the Active Directory configuration settings:
a. Active Directory Server Settings:
i. Address: ad1.dcloud.cisco.com
ii. Port: 389
iii. Username: cn=administrator,cn=users,dc=dcloud,dc=cisco,dc=com
iv. Password (Click Change): C1sco12345
v. Confirm Password: C1sco12345
b. Import Settings:
i. Base distinguished name: dc=dcloud,dc=cisco,dc=com
ii. Filter: telephoneNumber=*
c. Field Mapping Expression:
i. Display name: $cn$
ii. Username: $sAMAccountName$@dcloud.cisco.com
iii. Space name: $cn$’s Meeting Space
iv. Space URI user part: $sAMAccountName$.space
v. Space call ID: $ipPhone$
Lab Guide
Cisco dCloud
4. Save your changes by clicking Submit.

5. Satert the LDAP import by clicking the Sync now.
6. After a few minutes, select Status > Users. It will display the users created by the LDAP import. If the user
list is empty select Logs > Event Logs, any errors about attributes missing or duplicate entries means your
Field Mappings or search criteria need adjusting/correcting.
7. Repeat the same on CMS3.
NOTE: Instead of setting up LDAP identically on each server, you can also opt to remove the LDAP configuration
from CMS1 Web admin and instead program the LDAP settings using the API. More info about this can be
found in the API guide under chapter 11 LDAP Methods.
Task 4. Testing the XMPP Cluster
In this task you can check and verify that XMPP cluster is configured correctly.
1. On Workstation 1, launch Putty from the desktop and ssh to cms1.dCloud.cisco.com, login with:
• Username: admin
2. From the cms1> prompt, enter the following commands to check the current XMPP leader.
State: LEADER
List of peers
198.18.2.147:5222
198.18.2.185:5222
198.18.2.175:5222 (Leader)
Lab Guide
Cisco dCloud
3. On Workstation 2, launch the Cisco Meeting App located in the taskbar.

4. Click Sign In and login with the following credentials:
• Username: amckenzie@dcloud.cisco.com
5. Try to call to Adam’s space by clicking Join meeting.
6. This should work okay. Disconnect the call to the space.

7. On Workstation 1, within your ssh session to cms1 restart the XMPP service.
cms1> xmpp restart
8. Check which is the new leader.

State: FOLLOWER
List of peers
198.18.2.147:5222
198.18.2.185:5222 (Leader)
198.18.2.175:5222
9. On Workstation 2, try to call Adam’s space again. This should work okay.
10. You can disconnect the the call and log out of the Cisco Meeting App.
Lab Guide
Cisco dCloud
Scenario 4. Expressway Unified Edge

In order to collapse edge services into a single Unified Edge using Expressway instead of a CMS edge server,
Cisco Expressway X8.9 supports traversal of SIP traffic at the edge of the network, to and from the Cisco
Meeting Server. This allows collaboration using Cisco Meeting Spaces between on-premises Cisco Meeting
App or SIP endpoint users, and users external to the network who are using standards-based SIP endpoints,
Microsoft Skype for Business or Microsoft Office 365. Cisco Expressway does not currently support traversal
for external Cisco Meeting App users. Cisco Expressway X12.5.2supports a Cisco Meeting Server web proxy
to enable off-premise users to join meetings held in spaces using a web browser supporting WebRTC. This
feature is being enhanced in each release of CMS and Expressway. Detailed deployment options are covered in
the document: Cisco Expressway options with Cisco Meeting Server and/or Microsoft Infrastructure
Deployment Guide.
For this Scenario, the following tasks will be accomplished:
Task 1: Configure Expressway E
Task 2: Configure Expressway C
Task 3: Configure Turn Servers with Postman
Task 4: Test WebRTC
The following graphic is examples of the communications scenarios possible when using Expressway Edge.
Lab Guide
Cisco dCloud
Task 1: Configure Expressway E
To configure the Expressway E, this will require enabling the Turn Services, creating a local database username
and password and changing the Web Administrator port to 445, which require a re-start on the Expressway E.
1. On Workstation1, click in a browser tab navigate to Collaboration Admin Links > Cisco Expressway – E.
2. Click Cisco Expressway - E and login with:
• Username: admin
3. Accept any security exceptions.
4. On the web GUI of the Expressway E, navigate to Configuration > Traversal > Turn.
5. Change the Turn Services from Off to On.
6. Change the Authentication Realm from vcseadmin to dcloud.cisco.com. Click Save when done.
Lab Guide
Cisco dCloud
7. Notice after saving, the Status will go from Inactive to Active and the Listening Address will be the
Expressway E IP address of 198.18.1.5:3478.
8. On the web GUI of the Expressway E, navigate to Configuration > Authentication > Devices > Local
Database.
9. Select New to enter username and password.
Lab Guide
Cisco dCloud
10. Enter the following:

• Name: turnserver
11. Click Create Credential.
12. Verify the new credentials have been added to the local database.
13. On the web GUI of the Expressway E, navigate to System > Administration Settings to change the Web
Administrator port on the Expressway E.
Lab Guide
Cisco dCloud
14. Locate the Web Server configuration sections and change Web Administrator port from 443 to 445 and
click Save.
15. After pressing Save, you will need to restart the Expressway E to set this change. Click Restart and confirm
the restart by pressing OK.
Lab Guide
Cisco dCloud
NOTE: Once the Expressway reboots, due to changing the Web Administrator port to 445, you are required to
enter the port 445 in the web browser with FQDN or IP address of the Expressway E. During this process,
please clear all Security Exceptions in the web browser in order to access the Expressway E login page.
Task 2: Configure Expressway C
Configuring the Expressway C will require enabling CMS meeting server web proxy and changing the guest
account client URI.
1. In a new browser tab navigate to Collaboration Admin Links > Cisco Expressway – C.
2. Click Cisco Expressway - C and login with:
• Username: admin
3. Accept any security exceptions. On the web GUI of the Expressway C, navigate to Configuration > Unified
Communications > Cisco Meeting Server.
4. Change the Meeting Server Proxy from Disable to Enable.
Lab Guide
Cisco dCloud
5. Enter DNS A Record Type URI for Join from the Details section in the dCloud Session. This URI will not be
the same for all dCloud sessions and will change based on the certificate that is generated for each
session.
6. Make sure these match for this configuration.
Lab Guide
Cisco dCloud
7. Click Save. Ensure the guest account client URI is associated and resolves to the CMS IP address.
Task 3: Configure TurnServers with Postman
Using Postman
The Postman app will use RESTful API commands to configure the Turn Server relays on the CMS with the
required parameters and confirm it is operational.
1. On Workstation 1, double-click on the Postman Application located on the desktop. Wait until the
following screen appears.
Lab Guide
Cisco dCloud
2. In the Filter section, type “turn” to view the list for TurnServers.
3. Click Get List TurnServers and then click Send to view turnservers that are already configured. If there are
no turnservers configured, ignore the following sub-steps to delete them. If there are turnservers
configured, proceed to the next step.
a. Click the TurnServer ID and using Postman, copy and paste this string ID into the API command field.
Make sure the backslash is included prior to pasting in the TurnServer ID.
b. Click the Get pulldown and select Delete.
Lab Guide
Cisco dCloud
4. Click Send.
5. Click Post CreateTurnServer.
6. Click Body to display the parameters that need to edited or added.
Lab Guide
Cisco dCloud
7. Configure the following parameters to these values:

• ServerAddress: 198.18.1.5
• ClientAddress: xxx.xxx.xxx.xxx
NOTE: This is public NATed IP of the Expressway E and can be found in the Session Details of this lab and it will
be listed in the Public Address section, see below.
• Username: turnserver
• Type: expressway
• tcpPortNumberOveride: 3478
8. Click Send to set parameters values.
Lab Guide
Cisco dCloud
9. To confirm these parameters values were set, there should be a Status of 200 OK.
10. Click on the Get List TurnServers and click Send. Verify there is a turnServer created as configured above.
Lab Guide
Cisco dCloud
11. Click on the turnServer id and, using Postman, copy and paste this string id into the API command field.
Make sure the backslash is included prior to pasting in the turnServer id.
Lab Guide
Cisco dCloud
12. Click Send to return the parameters of this TurnServer ID. This will confirm the parameters were set on the
Post command.
13. To get the Status of this TurnServer ID, add the “/status” to the end the API command field and click Send.
Lab Guide
Cisco dCloud
14. Verify the return has Success, it is reachable, and mapped to the CMS.
Task 4: Test WebRTC
1. On your personal laptop or device with a network connection (that is not behind this session VPN
connection), use Google Chrome, Mozilla Firefox, or Apple Safari web browser and enter the DNS Record
Type A guest account client URI for Join. This will be in the Details section in the dCloud Session. This URI
will not be the same for all dCloud sessions and will change based on the certificate that is generated for
each session. Eventually, the WebRTC login will appear.
As of CMS 2.6.1 release, the following browsers and devices are supported for WebRTC application:
• Google Chrome (Windows macOS and Android) version 66 or later
• Mozilla Firefox (Windows macOS and Android) version 60 or later
Lab Guide
Cisco dCloud
• Apple Safari for macOS version 11.1 or later

• Apple Safari for iPads, running the latest version of iOS, iOS 11.0 is the minimum supported release
• Apple Safari for iPhones, running the latest version of iOS, iOS 11.0 is the minimum supported release. (this
is beta quality in version 2.5.0)
NOTE: We have tested the WebRTC app using the Safari browser on iPad Air 2 and iPad Pro 12.9 inch (gen 2)
with iOS 11.4.1, iPad (gen 6) with iOS 12.0.1, iPhone 6 on iOS 12, iPhone 7 on iOS 12 and 12.1, iPhone 8 Plus
on iOS 12 and 12.1, and iPhone X on iOS 11.41.
NOTE: As of this testing with CMS 2.6.1, Apple Safari for iPhones and iPads does work. The dCloud public
certificate that this lab uses does have a SAN with join.cbXXX.dc-YY.com as a trusted domain. These trusted
certificates are on rotation and it is at random if the pod you are using will have the proper trusted certificate for
the iPhone and iPads to work.
2. Click Join meeting and enter the following information:

• Meeting ID: 6017
• Passcode: leave blank
Lab Guide
Cisco dCloud
3. Click Join Meeting.

4. Enter your name in the field provided and click Join meeting.
5. Once connected, click Allow for the browser to use the local camera and microphone.
6. Click Join Meeting and this will launch the WebRTC app into the Anita Perez space on the CMS.
7. Using Workstation 1, launch the Jabber client from the desktop.

8. Using the Jabber client, call aperez.space@a.dcloud.cisco.com.
9. This will join the WebRTC client and the Jabber client into the Anita Perez Meeting space and confirm
WebRTC functionality.
10. When done with testing, disconnect all callers.
11. On a mobile device that meets the requirements we support, using the web browser, enter the Guest
account client URI that we used previously. Eventually, the WebRTC login will appear and follow the
previous steps to join meeting as a guest.
Lab Guide
Cisco dCloud
12. Confirm the mobile device has the below following video layout with Adam Mckenzie’s picture and WebRTC
client.
13. All participants can disconnect from the Anita Perez Meeting Space.
Lab Guide
Cisco dCloud
Scenario 5. Cisco Meeting Management

Cisco Meeting Management (CMM) is a new on premises management solution for Cisco Meeting Server
(CMS). It is a set of management services built around CMS and its APIs. CMM compliments and extends the
feature set of CMS and together, CMS and CMM form a complete video solution. TMS continues to provide
scheduling services and endpoint management.
One of the aims of CMM is to enable customers to move from legacy products to CMS. Without CMM, there is a
feature gap that prevents customers from moving to CMS. CMM will make things easier for our customers,
partners and resellers and will eventually be a single pane of glass in front of CMS that can offer the following
features.
• Managing and monitoring meetings
• Security and auditing
• Account management and permissions
• Diagnostics and troubleshooting
For this Scenario the following tasks will be accomplished:

Task 1: Login into CMM – Review and confirm initial setup
Task 2: Add CallBridges to CMM
Task 3: Ad-hoc Conferencing (XMPP has to be configured and enabled, see Scenario 3 for the procedure)
Task 4: TMS Scheduled Conferencing
Task 5: Test and Verify TMS Schedule Conferencing
Task 6: Configure Recording Service on CMS1
Task 7: Test and Verify Ad-hoc Recording with a Schedule Conference
Task 8: Configure TMS Scheduled Conference with Auto Record Feature
Task 9: Test and Verify TMS Scheduled Conference with Auto Record Feature
Lab Guide
Cisco dCloud
The figure below shows the solution architecture for CMS and CMM deployments. CMM runs as a separate VM.
CMS servers are added to CMM via the GUI.
Task 1: Login into CMM
1. On Workstation1, click in a browser tab to navigate to Collaboration Admin Links > Cisco Meeting
Manager.
2. Click Cisco Meeting Manager and login with:
• Password: C1sco12345
3. You are taken to the Overview dashboard. The Overview will be the single place to view the status of your
entire CMS system (single, cluster, distributed) and will show information such as the number of active
calls, total spaces, and number of meetings.
Lab Guide
Cisco dCloud
Traditionally, a typical install would consist of the following:

• Deploy OVA
• Install Meeting Management
• Configure IPv4 and/or IPv6
• Add DNS and NTP Servers
• Create Self-signed certificates
• Set-up LDAP
• Sign in with single-use password
• Supply LDAP details
• Add Administrator group
• Complete Configuration
• Sign in with LDAP
• Edit settings and set-up CDR Receiver
• Add CallBridges, log servers and user groups
• Create a Backup
4. Confirm the Network and NTP: These were preconfigured when the CMM overlay was launched during the
install. CDR was preconfigured due to the certificate it uses. Once the certificate is installed, it cannot be
deleted. Users is traditionally installed during initial configuration of launching the CMM application. There
are three steps to linking/binding the AD/LDAP directories that, when configured correctly, bring over the
users’ emails and assign them a space on the CMS (username.space@dcloud.cisco.com). Due to the time
and length of this lab and logistics of dcloud POD assignments, this section is preconfigured.
Lab Guide
Cisco dCloud
5. Confirm Settings > Network: Hostname, DNS Servers, and IPv4 information.
Lab Guide
Cisco dCloud
6. Confirm NTP Status: At least one IP address has sys-peer (green) status.
7. Confirm CDR : The CMM FQDN is listed as the receiver and the certificate is assigned.
Lab Guide
Cisco dCloud
8. Confirm Users: User Group Details and LDAP Configuration.
NOTE: We are not using the Local and Local Configuration, so they will not be configured.
9. Confirm Administrators group.
Lab Guide
Cisco dCloud
10. Confirm LDAP Server configuration.
Lab Guide
Cisco dCloud
Task 2: Add Call Bridges to CMM
1. In a browser tab navigate to Collaboration Admin Links > Cisco Meeting Manager.
3. On the web GUI of the Cisco Meeting Manager, navigate to Servers.
4. Click Add Call Bridge.
Lab Guide
Cisco dCloud
5. Configure the following parameters for CMS1:

• Server Address: cms1.dcloud.cisco.com
• Port: 445
• Username: admin
• Display name: dcloud-CMS1
• Add a check to Use trusted certificate chain to verify
6. Click Upload certificate to view the PC Directory.
Lab Guide
Cisco dCloud
7. Navigate to the CMM certificate at Desktop > CA Certs > CMM . Select CMM-Certificate-chain.cer. Click
Open.
8. Click Add to upload the Certificates to the CMM. If successful, a green box with check will appear and will
display the Callbridge that has been added to the CMM.
Lab Guide
Cisco dCloud
9. If successful, notice the green popup box informing the Callbridge has been added.
10. The green popup box will disappear and the CMM Server section look like below.
11. After adding CMS1 Callbridge, CMM has auto-discovered two additional Callbridges.
12. Repeat steps 3—11 to add CMS2 (cms2.dcloud.cisco.com) and CMS3 (cms3.dcloud.cisco.com).
Lab Guide
Cisco dCloud
13. Click the Overview option.
14. You will notice the License status for the dCloud-Cluster is in compliance.
NOTE: Most notification warnings/errors will disappear by adding the CMS Callbridge successfully. We do have
SSL Certificate for the CMM that has expired.
Task 3: Ad-hoc Conferencing
Here you will create ad-hoc conferencing using the CMS Spaces with a Workstation 1, Workstation 5, and
WebRTC client dialing into Anita Perez’s Space.
NOTE: If XMPP has not been configured, please see Scenario 3 to set up XMPP Clustering.
1. On Workstation 1, the Adam McKenzie Jabber client dials aperez.space@a.dcloud.cisco.com, The Jabber
client joins the aperez Meeting space as only a participant.
2. On a network-connected laptop using a Google Chrome, Mozilla Firefox, or Apple Safari web browser,
enter the guest account client URI. This will bring up the http link we used in the previous steps in Scenario
4, Task 2, step 5. Eventually, the WebRTC CMA login page will appear.
3. Click Join Meeting.
Lab Guide
Cisco dCloud
4. Enter Meeting ID 6017 and click Join Meeting.

5. Enter your name and click Join meeting.
6. The Anita Perez’s Meeting Space will appear. Ensure the laptop’s microphone and camera is enabled, then
click Join Meeting. This will launch the desktop into Anita Meeting Space with Adam McKenzie.
7. On Workstation 1, click in a browser tab to navigate to Collaboration Admin Links > Cisco Meeting
Manager.
8. Click Cisco Meeting Manager and login with
9. On the web GUI of the Cisco Meeting Manager, navigate to Meetings. This will display the active meetings
on the CMS.
10. Click on the Anita Perez Meeting Space to show the list of participants, status, and meeting options
available in this space.
Lab Guide
Cisco dCloud
11. Click the ellipse (…) for any other the participants’ section. This expands to all options available as
individual participant in this meeting. Some of these features and options are: Mute Audio, Stop Video, drop
the participant, change your layout on device (if device has the capabilities), and call information and stats.
12. If you hover over the icons in the Actions section, you can view the call controls for audio/video or to drop
the participants.
13. If you select a participant in the meeting details, a side panel and with call information, an individual control
will open. Scroll down to see call stats.
Lab Guide
Cisco dCloud
14. If you select Layout, you can change the video layout for all participants who are dialing in from a SIP
Endpoint. Changing the layout will only affect participants in the meeting and can subsequently change their
layouts.
NOTE: You cannot change layouts for Lync/Skype for Business clients or for Meeting Apps; these applications
will use their native layouts during video calls.
15. Click X to close out this field.
NOTE: To add another participant to this ad-hoc conference, you will need to RDP to Monica Cheng on
Workstation 3.
16. RDP into Workstation 3 (198.18.1.38) and log in as Monica Cheng and leave this desktop open.
• Username: dcloud\mcheng
17. The Skype for Business client will launch. Login with Monica Cheng.
18. On Workstation 1, in CMM Anita Perez’s Meeting Space, click Add Participants to add another caller to
this space.
Lab Guide
Cisco dCloud
19. Add the S4B client Monica Cheng by entering mcheng@s4b.dcloud.cisco.com and click Add. This will
launch a call to the Monica Cheng S4B Client on the Workstation 3 desktop.
20. On Workstation 3, a pop-up box will appear on the desktop. Click the Video icon.
Lab Guide
Cisco dCloud
21. On the desktop, the S4B video displays appears. Select the video icon to join in the ad-hoc conference call.
Lab Guide
Cisco dCloud
22. On Workstation 1, within the CMM browser tab, Monica Cheng S4B Client will appear as a participant in
the Aperez Meeting Space and will have the same features and options available as the other participants
have.
23. Click the ellipse (…) for any other the participant’s section. This expands to all the options available as
individual participants in this meeting. Some of these features and options are: Mute Audio, Stop Video,
drop the partiicpant, change your layout on device (if device has the capabilities), and Call information and
Stats. Compare the Cisco client to the MSFT S4B feature sets.
24. Click on any participants to change their layout, or mute/unmute participants, and/or stop/start video of
participants. If you want to add other participants into this space, you will need to access the workstation
for those Jabber accounts and log in into them.
Lab Guide
Cisco dCloud
25. Disconnect all participants by clicking End Meeting.
26. Click End.
Lab Guide
Cisco dCloud
27. All participants change from a green check mark to a red X next to the their names.
28. Notice eventually participants associated to the Anita Perez Meeting Space will disappear and no meeting
will show as Active.
Task 4: TMS Schedule Conferencing
Using TMS to Schedule a conference with CMS Spaces using Automatic Connect to dial out to Jabber client.
Once the conference is established we will have the WebRTC application join the conference using the SIP
Lab Guide
Cisco dCloud
conference ID URI. TMS and CMM work independently of each other, and CMM pulls it’s information directly
from the CMS. This means that you might see different details for schedules meetings in TMS and CMM.
1. On Workstation 1, In a new browser tab navigate to Collaboration Admin Links > Cisco Meeting Manager.
3. On the web GUI of the Cisco Meeting Manager, navigate to Settings > TMS.
4. Verify the following screens appears as below:
• Check the box Use TMS with Meeting Management
• At TMS address, enter IP address: 198.18.133.158
• Select HTTP
• Enter Username: dcloud\administrator
• Enter Password: C1sco12345
5. Click Save.
Lab Guide
Cisco dCloud
6. Verify Save is complete. The Setting updated successfully green box displays.
7. Restart CMM by clicking Restart now.
Lab Guide
Cisco dCloud
8. Confirm you want to restart CMM by clicking Restart.
9. After the restart of CMM, within the Overview page, there will be a new notification informing you that the
TMS has been configured but no clusters are associated with it.
Lab Guide
Cisco dCloud
10. Navigate to Servers and click Associate cluster with TMS.
11. Select dCloud-CMS1 from the Connected Call bridge pull down.
Lab Guide
Cisco dCloud
12. You need to add the TMS System ID. Follow the steps below to find this ID.
13. In a new browser tab, navigate to Collaboration Admin Links > Cisco TelePresence Management Suite.
14. Click Cisco TelePresence Management Suite and login with:
15. On the web GUI of the TMS, navigate to System > Navigator > Infrastructure and select
CMS1.dcloud.cisco.com.
Lab Guide
Cisco dCloud
16. Click Settings and note the TMS System ID is 2009.
17. Return to CMM and the Associate Cluster with TMS PAGE, enter 2009 for the TMS System ID and click
Done.
Lab Guide
Cisco dCloud
18. Verify TMS settings are updated with green box indication.
Task 5: Test and Verify TMS Scheduled Conferencing
1. Use TMS to schedule a conference with CMS Spaces using Automatic Connect to dial out to Jabber client.
Once the conference is established, we will have the WebRTC guest join the scheduled conference.
2. (If required) In a new browser tab, navigate to Collaboration Admin Links > Cisco TelePresence
Management Suite.
3. Click Cisco TelePresence Management Suite and login with:
4. On the web GUI of the TMS, navigate to Booking > New Conference.
Lab Guide
Cisco dCloud
5. Change Type from One Button to Push to Automatic Connect and click Add Participants.
NOTE: If video device endpoints are being use, the One Button to Push (OBTP) can be used. For this lab
environment, we are only using desktop or mobile devices/clients (Jabber & WebRTC), which are not managed
by TMS and can not support OBTP.
Lab Guide
Cisco dCloud
6. Select the MCU tab, click cms1.dcloud.cisco.com and add to the Selected Participants list by clicking the
> to move the CMS to the conference list.
Lab Guide
Cisco dCloud
Lab Guide
Cisco dCloud
7. Click the External tab and enter the following:

• Direction: Change to Dial Out
• Protocol: Change to SIP
• Name: amckenzie@sip.dcloud.cisco.com
8. Click the > to move the SIP dial out participant to the conference list.
Lab Guide
Cisco dCloud
9. Repeat previous steps to add Charles Holland’s (cholland@sip.dcloud.cisco.com) Jabber client.
Lab Guide
Cisco dCloud
Lab Guide
Cisco dCloud
10. Click the External tab. Enter the following for WebRTC client:
• Direction: Change to Dial In
• Protocol: Change to SIP
11. Click the > to move the SIP dial in participant to the conference list.
Lab Guide
Cisco dCloud
12. Verify the SIP Dial In moved over in the Selected Participants section. Click OK to save the participants list.
Lab Guide
Cisco dCloud
13. In TMS, verify the participants are listed on the Participants tab (two dial-out Jabber clients and one dial-in
WebRTC client). Use the scroll bar up and down on the far right to see list, if needed.
14. In the Basic Settings section, enter the following information:

• Title: Test 1
• Duration: 00:10, this will be a10-minute call
• Start Time: Enter a time that is 4-5 minutes ahead of the current time, use the server time as a
reference found towards the bottom right of the page.. This automatically adjusts the End Time
based on the specified duration time.
15. Click Save Conference.
Lab Guide
Cisco dCloud
The New Conference information will display with the conference title, invited participants, and calling/routing
information.
NOTE: Of the SIP URI being used (SIP: 86000X@a.dcloud.cisco.com), the 86000x will be used later in this call
scenario (see the starred orange box).
16. On Workstation 1, Go to the CMM browser tab, navigate to Meetings > Section, filter on Scheduled tabs.
By now, TMS should have updated CMM with the upcoming meeting Test 1 information prior to launching
the call. There may be a minutes delay before the meeting will appear.
17. On Workstations 1 and 5, amckenzie and cholland Jabber client will have incoming calls. Click the green
Answer button to have them join this conference call.
Lab Guide
Cisco dCloud
18. On Workstation 1, within the CMM browser tab, you can verify the participants Adam Mackenzie and
Charles Holland Jabber clients appear as participants in the Test 1 Space. (You might need to change the
filters to include Active status within the Meetings option.)
19. Select Test 1 meeting.
20. Click Checklist > Scheduled Participants. This will expand to show the same information seen in the TMS
Conference Participant list.
21. Notice all the features CMM can offer for controlling a scheduled conference. To control a specific
participant, these are available in the Participants - Actions section, which includes muting/unmuting
Lab Guide
Cisco dCloud
audio, starting/stopping video, make importance, and calling and dropping the participant. If you need to
pin a participant, select the pin icon, that participant will rise to the top of the Participants list.
22. On your personal laptop or device, with a network-connection, using Google Chrome, Mozilla Firefox, or
Apple Safari web browser, enter DNS A Record guest account client URI for Join from the Details section
in the dCloud Session. This URI will not be the same for all dCloud sessions and will change based on the
certificate that is generated for each session. Eventually, the WebRTC login will appear.
Lab Guide
Cisco dCloud
23. Click Join meeting as a guest.
24. TMS when it scheduled the conference, provided a Meeting ID for dial in participants.
Lab Guide
Cisco dCloud
25. Enter the Conference ID 86000X in the Meeting ID field. This is dependent on the schedule space that is
used in TMS.
26. Click Join meeting.

28. Once connected, click Allow the browser to use the local camera and microphone.
Lab Guide
Cisco dCloud
29. Click Join meeting to launch the WebRTC app into the Anita Perez Space on the CMS.
NOTE: Make sure the Microphone has activity to confirm it is connected to the device client.
30. Verify the layout of the WebRTC client is similar to the picture below with Adam and Charles as participants.
31. Confirm all participants have video.

32. On Workstation 1,within the CMM browser tab, the WebRTC client has just joined Test 1 Space as the third
participant with Adam and Charles Jabber clients.
33. Click Test 1 to expand the list of participants in the conference.
Lab Guide
Cisco dCloud
34. Click the WebRTC client in the Participants name. The WebRTC client does not support layout control, but
has other features and options available as the other participants have.
Lab Guide
Cisco dCloud
35. Click Mute All. Notice all participants are muted.
36. You may leave the call active and perform the next task, an active conference call is required for testing for
Task 7.
Task 6: Configure Recording Service on CMS1
1. In order to demonstrate how recording works with ad-hoc and TMS scheduling, the recording service on
CMS1 has to be configured and enabled. To store MP4 files that are created from the recording, we will use
a Network Files Storage (NFS). The NFS is located at 198.18.135.39 and has been pre-configured to allow
access to the CMS1-3.
2. We need to configure the Recorder for listening ports and certificates and then enable it. On Workstation 1,
open Putty from the desktop and SSH to CMS1 and login with the following credentials:
• Username: admin
3. At the cms1> prompt:
cms1>recorder
Lab Guide
Cisco dCloud
4. Verify the certs and the listening interface are not assigned and the Recorder is not Enabled.
5. At the cms1> prompt, enter the following.

recorder listen a:8443 lo:8443
recorder certs OneCert.key OneCert.cer CABundle.cer
recorder trust OneCert.cer
recorder nfs open-nfs1.dcloud.cisco.com:/mnt/dcloud/dcloud-vg/CMSDataStoreFolder/
recorder resolution 1080p
recorder
6. Confirm the configuration.
7. At the cms1> prompt, enter: recorder enable
Lab Guide
Cisco dCloud
8. At the cms1> prompt, enter: recorder
9. Verify the certs, listening interface, NFS, and resolution are configured, and the recorder is enabled.
10. On Workstation 1, launch the Postman App from the desktop. This will allow the CMS API to use RESTful
API commands to configure the Record Service.
11. To configure the Record Service on the CMS, we will need to Post/Create Recorder with the required
parameters and confirm it is operational using the GET Recorder ID and status.
12. In the Filter section, type “record”. The list for Recorder methods displays.
13. Select GET > List Recorders and click Send. Verify there are no recorders assigned.
14. Select POST > Create Recorders and select the Body tab.
Lab Guide
Cisco dCloud
15. Check URL and change Value to https://cms1.dcloud.cisco.com:8443 and click Send.
16. Verify the Status of 200 OK appears. (See figure above.)

17. Select GET > List Recorders, then click Send.
18. Copy the Recorder ID string and paste it in the GET string after “/recorders”. Make sure the backslash is
included prior to pasting string.
Lab Guide
Cisco dCloud
19. Enter “/status” and click Send.
20. Verify the status is success and active recording = 0. This confirms the NFS is connected to the CMS1
Callbridge and is ready to record.
Lab Guide
Cisco dCloud
Task 7: Test and Verify Ad-hoc Recording with a Scheduled Conference
1. If you have ended the active conference call after completing Task 5, then re-schedule a new TMS
conference. Perform the steps in Task 5 (steps 1 to 30) and establish a conference call between Adam
Mckenzie (Workstation 1), Charles Holland (Workstation5) and a WebRTC user (on your personal laptop or
device, with a network-connection).
2. On Workstation 1, within the CMM browser tab, navigate to Meetings, the WebRTC client has just Joined
Test 1 Space as the third participant with Adam and Charles Jabber clients.
3. Click Test 1 to expand the list of participants in the conference.
Lab Guide
Cisco dCloud
4. Click Recording to add an ad-hoc recording to this scheduled conference. After a couple of seconds the
Recording button will stop cycling and go to a solid red dot. The green box will appear indicating the
Recording started.
5. Click the Meetings option. You’ll see a confirmation that Test 1 meeting is being recorded within the
Activity field.
6. Confirm participants receive the recording indicator in their video displays.

• For the WebRTC client, the recording indicator will be located in the middle on the left side.
• For Jabber client, the recording indicator will be located in the upper-left corner.
Lab Guide
Cisco dCloud
7. Go back to the CMM browser tab, click Test 1 to expand the list of participants in the conference.
8. Click the Recording tab to stop recording. The green box will appear stating the recording stopped.
Lab Guide
Cisco dCloud
9. The WebRTC client has the capability of turning the recording On/Off. Click the Meeting Control Icon on
the right-hand side of the video screen.
Lab Guide
Cisco dCloud
10. This will expand to show the Recording and Streaming Control. Click Recording.
11. After a couple of seconds, notice the Record button will go to a solid red dot to indicate the recording has
started.
Lab Guide
Cisco dCloud
12. Go back to the CMM browser tab. Notice the CMM Meeting Space shows the recording has started with the
Recording button is a solid red dot.
13. In new browser tab, navigate to Collaboration Admin Links > Cisco Meeting Server – 1.
14. Click Cisco Meeting Server -1 and login with:
• Username: admin
This is just another way to confirm the recording call leg is connected to the Test 1 Meeting Space.
Lab Guide
Cisco dCloud
16. At the WebRTC client, turn off the Recording. Click the Meeting Control icon and click on the Recording
(solid red dot). This will gray out when recording has stopped.
17. Go back to the CMM browser tab and select Meetings, the Activity red dot will disappear indicating the
recording has stopped at CMM.
Lab Guide
Cisco dCloud
18. Select Test 1. Notice the recording indicator is grayed out, showing the record has stopped here as well.
19. On your mobile device with a network-connection, open web browser, enter DNS A Record guest account
client URI for Join from the Details section in the dCloud Session. This URI will not be the same for all
dCloud sessions and will change based on the certificate that is generated for each session. Eventually, the
WebRTC login will appear.
Lab Guide
Cisco dCloud
20. Click Join meeting as a guest.
21. TMS when it scheduled the conference, provided a Meeting ID for dial in participants.
Lab Guide
Cisco dCloud
22. Enter the Conference ID 86000X in the Meeting ID field. This is dependent on the schedule space that is
used in TMS.
23. Click Join meeting.

25. Once connected, click Allow to allow the browser to use the local camera and microphone.
26. Click Join meeting to launch the WebRTC app into the Anita Perez Space on the CMS.
Lab Guide
Cisco dCloud
27. Confirm the mobile device has the similar video layout with the Adam Mckenzie picture and WebRTC client
as in Figure below. To enable Record capabilities, click the Meeting Controls icon on right side of the
display screen.
Lab Guide
Cisco dCloud
28. Click the Recording button. It cycles a bit until turning a solid red button.
Lab Guide
Cisco dCloud
29. Notice the Recording icon will appear on the left side of the display screen to indicate recording is active.
30. On Workstation 1, go back to the CMM browser tab and select Meetings. The Activity red dot will
disappear, indicating the recording has stopped at CMM.
31. Notice on CMM, the Recording button is solid red, indicating the recording is active and reflecting the
controls of the participants in the conference.
Lab Guide
Cisco dCloud
32. Disconnect/hang up all participants in the Test 1 conference. The CMM will show the participant count to
zero when all participants have disconnected from the conference.
Task 8: Configure TMS Scheduling with Auto Record Feature
Within the TMS Scheduling with Auto Record feature, setting the Call Profile recording mode to Automatic
allows recording starts at the system or space level when the conference is initiated from TMS. Once the
conference has been started, the recording cannot be stopped. If attempted, a recording error will be displayed
in CMM. This is similar to how the Content Server operates for recording—either Record is on or off.
1. On Workstation 1, re-launch the Postman App from the desktop.
2. In the Filter section, type “callprofiles”.
3. In Postman app in ListcallProfiles, navigate to Get List > callProfiles and click Send.
Lab Guide
Cisco dCloud
4. Verify callProfile id string.
5. Copy the callProfile id string and paste it in the GET string after callProfiles and add “/” before it.
6. Also open Notepad and paste the callProfile id string in it.
Lab Guide
Cisco dCloud
7. Click Modify callProfiles and expand the sections under PUT until Body appears.
8. Cursor down until the attribute recordingMode appears.

9. Enter a check for recordingMode and change the Value from Manual to Automatic. Click Send.
10. Verify the status of 200 OK appears. (See Figure above.)

11. Click GET > callProfiles. Click Send.
Lab Guide
Cisco dCloud
12. Verify the recordingMode = automatic.
13. In the Filter section, type “systemprofile”.

14. Click GET > SystemProfiles. Click Send.
15. Verify only the calllegProfile id exists.
16. Click PUT > Modify SystemProfiles, expand the section under PUT until Body appears. Scroll down until
the attribute callProfile appears.
Lab Guide
Cisco dCloud
17. Enter a check for callProfile and paste in the callProfile id string from Notepad. Click Send.
18. Verify the status of 200 OK appears.
19. Click GET > List SystemProfiles, then click Send.
Lab Guide
Cisco dCloud
20. Verify callProfiles and callProfiles id appears.
Task 9: Test and Verify TMS Scheduling with Auto Record Feature
1. Schedule a new TMS conference. Perform the steps in Scenario 4 Task 5 (steps 1 to 35) and establish a
conference call between Adam Mckenzie (Workstation 1), Charles Holland (Workstation5), and a WebRTC
user (on your personal laptop or device with a network-connection).
2. On Workstation 1 within the CMM browser tab, navigate to Meetings, check to see if your meetings
appears in the Scheduled and Upcoming.
3. On Workstation 1 and Workstation 5, answer the incoming calls on the Jabber client.
Lab Guide
Cisco dCloud
4. As soon as meeting starts, return to the CMM browser tab and the red dot should appear in the Activity
section indicating the recording has started.
5. In new browser tab, navigate to Collaboration Admin Links > Cisco Meeting Server – 1.
6. Click on Cisco Meeting Server -1 and login with:
• Username: admin
8. Confirm the recording call leg is connected to Test 2.
Lab Guide
Cisco dCloud
9. In CMM tab, attempt to stop recording for Test 2 by clicking the Recording button. The red box Recording
error should appear indicating recording cannot be modified for the meeting.
10. In the WebRTC client, confirm the Meeting Control is not available on the right side of the video display.
11. Re-launch the Postman App from the desktop.

12. In the Filter section, type “recorder”.
Lab Guide
Cisco dCloud
13. Click GET > List Recorders. Click Send.

14. Verify recorder id and the URL is https:cms1.dcloud.cisco.com:8443.
15. Click GET > List Recorders and add the recorder id string/status. Click Send.
16. Confirm the status is success and activeRecording = 1.
17. End all calls.
Lab Guide
Cisco dCloud
Scenario 6. Configure CMS as Meeting Recording and Streaming Server

The Recorder component was added to CMS in v1.9. The Recorder component provides the capability of
recording meetings and saving the recordings to a document storage such as a network file system (NFS). The
recording is automatically converted to MP4 and saved onto the NFS at the end of recording the meeting.
The Recorder should be hosted on the CMS server that is remote to the server hosting the Callbridge. If the
Recorder is hosted on the same server as the Callbridge (local), then it should only be used for testing
purposes or for very small deployments. It is recommended to deploy the Recorder and NFS in the same
physical locality as the target file system to ensure low latency and high network bandwidth. It is expected that
the NFS is located within a secure network.
One Callbridge can support multiple Recorders or multiple Callbridges can use the same Recorder (see Figures
below). If multiple Recorders are used, then the solution load balances recordings between all recording
devices and no knowledge of the physical location of recording devices is known. Every Callbridge will use
every Recorder.
The recorder is an XMPP client and XMPP server is required for the deployment.
Lab Guide
Cisco dCloud
This lab consists of three CMS servers: cms1, cms2, and cms3. cms2 and cms3 have been pre-configured
with all of the necessary services. We will configure the recording service on cms1 and set the system to use
cms1 or cms2 as the recording device.
To configure the recorder, use CLI commands to enable the recorder on CMS, specify which Callbridges within
the deployment will work with the recorder, and where to save the recordings.
Here are the high-level tasks to setup this scenario:
Task 1: Configure Recorder Service on cms1 Using MMP
Task 2: Configure the Recorder Objects on CMS1
Task 3: Test Recording and Streaming
NOTE: If you have completed other modules of the CMS Advanced Lab, XMPP, and Recording services may
have already been configured. If you have already set these services up, you can skip to the next task.
Task 1: Configure Recorder Service on cms1 Using MMP
Enable Recorder
1. Log on to Workstation1 as amckenzie.
2. Open Putty and SSH to 198.18.2.175 (cms1).

3. Login with:
• Username: admin
4. At the cms1> prompt, type xmpp and press Enter. If the output is as follows, you have already configured
xmpp and can proceed to step 6. Otherwise, continue with the next step.
Lab Guide
Cisco dCloud
5. At the cms1> prompt, enter the following commands.

xmpp listen a
xmpp certs OneCert.key OneCert.cer CABundle.cer
xmpp enable
6. At the cms1> prompt, type recorder and press Enter. If the output is as follows, you have already
configured the recorder and can proceed to step 8; otherwise, continue with the next step.
7. At the cms1> prompt, enter the following commands.

recorder listen a:8443 lo:8443
recorder certs OneCert.key OneCert.cer CABundle.cer
recorder trust OneCert.cer
recorder nfs open-nfs1.dcloud.cisco.com:/mnt/dcloud/dcloud-vg/CMSDataStoreFolder/
recorder enable
Lab Guide
Cisco dCloud
NOTE: Enabling the streamer is very similar to the recorder. Since we do not use the streaming server on
CMS1, we will not configure it now. We will use the streamer services on CMS2 and CMS3, which are already
configured for this lab.
8. At the cms1> prompt, type xmpp callbridge list and press Enter. If the output is as follows, you have
already configured the xmpp Callbridge and can proceed to Task 2. If not, complete Scenario 3 – XMPP
Clustering.
Task 2: Configure the Recorder Objects on CMS1
Create Recorder Objects
1. If disconnected from Workstation 1, RDP to (198.18.133.36) login with:

2. If it is not already running, use the desktop shortcut to launch the Postman application.
Lab Guide
Cisco dCloud
3. In the upper right corner of Postman, verify SEVT 2019 CMS1 is selected for the environment. If it isn’t,
select it from the drop-down list.
4. In the upper left corner of postman in the Filter box, type “record”.
5. From the resulting list of API requests, select GET > List Recorders and click Send. If the results are similar
to the Figure below, you have already configured the recording object for the CMS1 recorder for the CMS1
Lab Guide
Cisco dCloud
Callbridge. Continue to the step of creating the recording object on CMS1 for the recorder on CMS2 using
the following steps.
6. Select POST > Create Recorder.

7. On the right panel of Postman, this will load the recorders POST request URL. Click the Body tab to display
its key/value pairs as shown below.
8. Verify the URL key is selected as shown above and enter the value: https://cms1.dcloud.cisco.com:8443. If
the URL value for cms1 was present in the List Recorders output before, only enter the URL for cms2 here:
https://cms2.dcloud.cisco.com:8443
Lab Guide
Cisco dCloud
9. Click Send. If successful, you will see a Status: 200 OK in the output section of Postman.
10. If needed, repeat the previous two steps to add the CMS2 URL value: https://cms2.dcloud.cisco.com:8443
11. Select GET > List Recorders and click Send. Verify there are two recorder objects pointing to CMS1 and
CMS2, respectively, as shown below.
12. Highlight and copy the Recorder ID for CMS1 and paste it after the / followed by ”status” the click Send.
Lab Guide
Cisco dCloud
13. Verify the status is Success and Active recording = 0. This confirms the NFS is connected to the CMS1
Callbridge and is ready to record. You can repeat the previous step with the Record ID for cms2 to check
that it is connected as well.
Create Streamer Objects
1. In the upper left corner of Postman in the filter box, type “streamer”.
2. From the resulting list, select POST > Create Streamer.
3. On the right panel of Postman, this will load the Streamer POST request URL. Click the Body tab to display
its key/value pairs.
4. Verify the URL key is selected as shown and enter the value: https://cms2.dcloud.cisco.com:8445
5. Click Send.
Lab Guide
Cisco dCloud
6. There is a rogue ID in the POST method for the streamer that needs to be removed. Delete “ID” before
proceeding to the next step.
7. Repeat the previous steps for cms3 and enter the value: https://cms3.dcloud.cisco.com:8445 for the URL.
Create A Call Profile
1. In the left panel, type “callprofile” in the Filter box.

2. Click GET > List callProfiles and click Send. Copy the existing callProfile ID to Notepad.
3. In the left panel of Postman, click PUT > callProfiles. On the right panel of Postman, click the Body tab.
Paste the callProfile ID you copied earlier to the end of the URL and add a / as shown. (NOTE: REMOVE THE
LETTERS ID FROM THE END OF THE STRING FIRST.)
Lab Guide
Cisco dCloud
4. Select and configure the recordingMode attribute to Automatic and the streaming mode to Manual. Click
Send.
5. Change the PUT method in Postman to GET and click Send to verify the callProfile has been modified.
Lab Guide
Cisco dCloud
Create a DTMF Profile
A DTMF Profile identifies DTMF Key sequences to control system functions, such as Start and Stop streaming.
1. In the upper left of Postman, type “DTMF” and select POST > Create DTMFProfile from the resulting list.
2. On the right panel of Postman, this will load the dtmfProfiles POST request URL. Click the Body tab to
display its key/value pairs as shown below.
3. Select both startStreaming and stopStreaming keys and enter the values **2 and **3, respectively.
4. Click Send and verify that Status: 200 OK is returned.
NOTE: We are using **2 to start recording and **3 to stop streaming.
5. Click GET from the list in the left pane. This will load the GET request in the right-hand panel in Postman.
6. Click Send. The system will return the ID of the newly created DTMF profile as shown below.
7. Copy the DTMF Profile ID and save it in Notepad for later use.
Lab Guide
Cisco dCloud
Modify System Profile
1. In the upper left corner of Postman in the Filter box, type “System”.
2. Select GET > List SystemProfiles from the resulting list and click Send. Verify only one SystemProfile
exists.
3. Click the PUT > Modify SystemProfiles, select the Body tab.
4. From Notepad, copy the callProfile attribute and paste it in the callProfile id string.
5. From Notepad, copy the dtmfProfile key and paste it in the dtmfProfile id string and click Send.
6. Verify the status of 200 OK appears.
Lab Guide
Cisco dCloud
Task 3: Test Recording and Streaming
1. From Adam Mckenzie’s desktop via RDP, open Jabber and search for aperez. Select Anita Perez CUCM
and then the space URI.
2. You will connect to the meeting and will hear “This meeting is being recorded”.
3. Go back to Postman and type “record” in the search Filter. Select GET > List Recorders and click Send.
4. Copy the Recorder ID for CMS1 and paste it to the end of the GET URI proceeded by “/status” and click
Send.
Lab Guide
Cisco dCloud
5. In Postman, verify status is Success and there is an Active Recording.
6. End the call on Jabber.

7. From the RDP session on Adam Mckenzie’s desktop, if it isn’t running already, launch Putty and log into
CMS1.
8. From the CMS1> prompt, enter recorder disable
9. Relaunch the Jabber call as above. What are the results?

10. Repeat the steps to get CMS1 recorder status as above. Do you see the same results?
11. Using the above steps, change the recorder ID to CMS2 and repeat the status check. You should now see
the recording has moved to the recorder on CMS2.
Lab Guide
Cisco dCloud
Appendix A. Generate Database Certificates and Get Them Signed

Certificates have been already been installed on all of the CMS servers and the pre-installed certificates will be
used to complete the lab. You can still complete this task if you would like to see how certificates are created
and installed on CMS servers.
1. From Workstation 1, Adam McKenzie, connect using Putty to the cms1.dcloud.cisco.com.
2. We will need to create a client and server certificate for the database cluster. For this we will generate two
certificate signing requests (CSRs). At the cms1> prompt, enter the following.
pki csr MYdbSERVER CN:cms1.dcloud.cisco.com subjectAltName:cms2.dcloud.cisco.com,cms3.dcloud.cisco.com
3. Observe the following output if successful.

.......................
Created key file MYdbSERVER.key and CSR MYdbSERVER.csr
CSR file MYdbSERVER.csr ready for download via SFTP
4. Next from the cms1> prompt, enter.

pki csr MYdbCLIENT CN:postgres
Output:
..............
................
Created key file MYdbCLIENT.key and CSR MYdbCLIENT.csr
CSR file MYdbCLIENT.csr ready for download via SFTP
NOTE: In any production environment, you must use encryption on database traffic. This is achieved by using
certificates. However, for testing (and only for testing) you can skip using certificates. If you do not use
certificates then there is no security nor access control for the database.
NOTE: We will create two certificates:

1) Database server certificate: You can use the same certificate on all of the servers in the database cluster;
specify the FQDN of one of the servers in the CN field and specify the FQDN of the other servers in the SAN
field. If using Extended Key Usage, ensure Server Authentication is allowed for the database server.
2) Database client certificate: The Common Name (CN) for a database client must equal postgres. If using
Extended Key Usage, ensure Client Authentication is allowed for the database client.
5. Use WinSCP client from Adam McKenzie’s desktop to connect to cms1.dcloud.cisco.com. Copy the .csr
and .key files for both requests to the desktop.
6. Open the .csr file with Textedit so you can copy the contents.
-----BEGIN CERTIFICATE REQUEST-----
MIICxjCCAa4CAQAwIDEeMBwGA1UEAwwVY21zMS5kY2xvdWQuY2lzY28uY29tMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtzeeENKBfpQPH6DpSkmjs376
TD8JSbcUzxbameDhcHjAtTzN5pumuwoZyUWipD/dApn7MKfIjsD1dZJ+7dm4rFwz
lg0riLgV3IH1OUV+vX5n+igoHUVwcKkg2KdZLRDI/yj3XJQke7VgTncpPHArK/8w
HZwise+zOkjYyH2KWgv2J4537iMkNOAlEmFWT557tSWmMYE1YepkCPzUaYwHN1OQ
9kfb40VGRHLPp7Lynjp+VsOMq0qxLR50pMC4boREKgpbZ0Gc2r21qQkhnm9HQ4En
Lab Guide
Cisco dCloud
aHEpJSIzAmRYkwhmt3ffqxo1fvNS/XaMCOWoSkRBQ46XLF8BoE4/oASgI34wRwID
AQABoGEwXwYJKoZIhvcNAQkOMVIwUDBOBgNVHREERzBFghVjbXMxLmRjbG91ZC5j
aXNjby5jb22CFWNtczIuZGNsb3VkLmNpc2NvLmNvbYIVY21zMy5kY2xvdWQuY2lz
Y28uY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAU0czvK7xmdRNK7eCMK1vqRXiIGQRk
MtY0o2Okg8thupNxO20mLlQYeA6lzAU0cLq7TBU3UNwXOtkmRPa9SPcaBE9R4aNE
E4p26EoRo/Rk3tnFyZCipxryi/GSSyfjiM7LFcm0J1lBH0jKcJiRGlhGS+EI2n3X
9o4s/477sj6KlC+FCinqZUyniFLazWd8FdzZpgZSMVVBlroTWNNjZONzt+9gVJt7
t2/7yVJC+VhT5ybTW/9zLXpjhbxDp5+O5ohaXGabo0r/v86MbCKy2TefzKVdFwMe
Bl+IyT5o77pVlK8d7j+rrRJbihE7byaHfTH4TrI4xekKnN2HKXC3emLY
-----END CERTIFICATE REQUEST-----
7. You need to get the CSR signed by the CA server. For this, connect from Firefox on Workstation 1 to:
https://ad1.dcloud.cisco.com/certsrv/. Login with Domain Administrator credentials, if prompted.
8. Click Request a Certificate. Click Advanced Certificate Request and click Submit a Certificate Request
by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-
encoded PKCS #7 file.
9. Paste the contents of your CSR from step above in the Saved Request field. For Certificate Template,
select ClientServer. Click Submit.
10. Select Base 64 encoded. Click Download certificate.
11. Give the file the name <basename>.cer, where <basename> is the same as the filename of the CSR key.
Repeat from the step above to get the client certificate signed as well.
12. Upload both the database client and server certificate and key files to db1, cms1, cms2, and cms3 using
WinSCP.
Lab Guide
Cisco dCloud
What’s Next?
Be on the lookout for the upcoming CMS Advanced Lab on dCloud.

CMS 2 6 1 Intermediate Lab v2

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CMS 2 6 1 Intermediate Lab v2

Загружено:

Авторское право:

Доступные форматы

Lab Guide

Cisco Meeting Server 2.6.1

Last Updated: 04-July-2019

About This Lab

About This Lab

About This Solution

Scenario 1. Database Clustering

Scenario 2. Cluster Callbridges

Scenario 3. XMPP Clustering

Scenario 4. Expressway Unified Edge

Scenario 5. Cisco Meeting Management

Scenario 6. Configure CMS as Meeting Recording and Streaming Server

Appendix A.Generate Database Certificates and Get Them Signed

Laptop with Cisco AnyConnect® None

About This Solution

Personal Multiparty Plus License

Shared Multiparty Plus License

Name Description Host Name (FQDN) IP Address Username Password

hap1 vBrick HA Proxy ha p1.dclou d.cisco.com 198.18.135.43 vbrick dClou d123!

openfiler O penFiler NFS open- 198.18.135.39 openfiler dClou d123

Workstation 1 Windows 10 wkst1.dclou d.cisco.com 198.18.1.36 a m ckenzie dClou d12345!

NOTE: It may take up to 30 minutes for your session to become active.

6. Click View to open the active session.

Scenario 1. Database Clustering

Task 1. Set up the Database Cluster

2. From the db1> prompt, enter the following commands:

3. Specify which interface to use for the database clustering:

4. Initialize the master database:

5. Respond to dialog by pressing shift-Y.

6. Verify that this is now the master database.

Last command : 'database cluster initialize' (Success)

3. Specify the interface to use:

4. Connect to the master database.

database cluster join db1.dcloud.cisco.com

5. Respond to dialog by pressing shift-Y.

6. Verify the status of the database cluster.

Last command : 'database cluster join db1.dcloud.cisco.com' (Success)

Scenario 2. Cluster Callbridges

Task 1. Set up Callbridge

3. Repeat step 1 for cms2 and cms3 to verify their configurations.

Task 2. Configure the Cluster

Task 3. Create the Distribution Links

5. Navigate to Configuration > Incoming calls.

Task 4. Configure CUCM for Calls towards CMS

11. Click Save, Apply Config, and Reset once completed.

Task 5. Test Calling into CMS Space and Distribution Links

1. If required, RDP to Workstation 1 (198.18.1.36) and log in with these credentials:

Task 6. Test Ad Hoc Meeting Configuration

10. Check that you see this call is active.

11. You may end the call.

Scenario 3. XMPP Clustering

Task 1. Creating the XMPP Cluster

1. Create an RDP connection to Workstation 1 (198.18.1.36) and log in with:

4. Set the XMPP domain and specify the interface to use.

5. Specify the certificate that will be used by the XMPP service.

6. Repeat steps 2-5 for cms2 (cms2.dcloud.cisco.com) and cms3 (cms3.dcloud.cisco.com).

7. Return back to ssh session to cms1. Enable the XMPP service.

9. Disable XMPP again.

10. Enable and initialize the cluster.

11. Enable XMPP again.

12. Review the cluster status.

16. Disable XMPP again.

17. Enable the cluster.