Cisco Meeting Server v2.8 Single Server Simplified Lab v1

Lab Guide
Cisco dCloud
Cisco Meeting Server v2.8: Single Server

Simplified Lab v1
Created in Partnership with Solutions Readiness Engineers

Last Updated: 14-JANUARY-2020
About This Lab

This guide for the preconfigured demonstration includes:
About This Lab
Requirements
About This Solution
Topology
Session Users
Get Started
Scenario 1. Configuring the IP Interface for Admin and A Interface
Scenario 2. Setting a Hostname
Scenario 3. Setting the MMP
Scenario 4. Upgrading Software (If Necessary)
Scenario 5. Obtaining and Assigning a License
Scenario 6. Configuring the Network Time Protocol (NTP) Server
Scenario 7. Generating Certificates for the Meeting Server
Scenario 8. Enabling Call Bridge Service
© 2020 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 75
Lab Guide
Cisco dCloud
Scenario 9. Enabling the Web Admin Service
Scenario 10. Configuring Basic Call Settings
Scenario 11. Configuring Incoming Call Rules
Scenario 12. Configuring Outgoing Call Rules
Scenario 13. Creating a Test Space
Scenario 14. Unified CM: Adding Calling Rules to the Call Control for the Meeting Server
Scenario 15. Enabling the Web Bridge
Scenario 16. Configuring the User Import Feature
Scenario 17. Cisco Meeting Management
What’s Next?
Lab Guide
Cisco dCloud
Limitations
There are no limitations associated with this lab.
Requirements
The table below outlines the requirements for this preconfigured lab.
Required Optional
Laptop Router, registered and configured for Cisco dCloud®
Cisco AnyConnect®
The following requirements have already been configured:
• DNS A Record – A record has already been created for the Meeting Server IP address, i.e. cms1.dcloud.cisco.com –
198.18.1.42
• DNS A Record – A record has already been created for Cisco Meeting Management, i.e. cmm.dcloud.cisco.com –
198.18.1.43
• DNS SRV record for XMPP – An SRV record for xmpp-client._tcp.dcloud.cisco.com for TCP port 5222
• SIP Domain for Meeting Server
Lab Guide
Cisco dCloud
About This Solution

The Cisco Meeting Server (Meeting Server) brings video, audio, and web communication together to meet the collaboration
needs of the contemporary workplace. The Cisco Meeting App allows anyone to create, join, and run meetings easily either
from room or desktop video systems, mobile clients, or browsers. The Meeting Server helps ensure that everyone gets a
consistent, familiar meeting experience, whether they’re joining a meeting using Cisco or third-party video endpoints, a Cisco
Jabber® client, Cisco Meeting App (native or via a WebRTC-compatible browser), or Skype for Business. Any number of people
can join a meeting up to the limit of the available underlying hardware. In addition, the Meeting Server optimizes bandwidth
usage in order to reduce cost. In short, the Meeting Server provides an optimal user experience that is simple, intuitive, and
easy.
The Meeting Server is also optimized for deployment with Cisco Unified Communications Manager, Cisco Expressway, Cisco
TelePresence® Video Communication Server (VCS) for call control, Cisco Expressway for firewall traversal, and Cisco
TelePresence Management Suite for scheduling (third-party on-premises infrastructure is also supported). It scales easily for
small or large deployments, allowing capacity to be added incrementally as needed. The all-in-one, user-based licensing model
allows you to buy the services you need today and add more licenses as your organization grows. The combination of the
Meeting Server and its licensing model provide you with the flexibility to meet the changing needs of your organization.
This guide covers a simplified deployment of the Meeting Server that is intended to reduce the time and simplify a basic stand-
alone installation. This deployment implements a stand-alone conference bridge integrated with a Unified CM or
Expressway/VCS call control shown in the figure below. It is also enhanced with the Meeting Server Web Bridge functionality
that enables browser-based clients to connect to your conferences using the Cisco Meeting App.
Topology
This lab includes several server virtual machines. Most of the servers are fully configurable using the administrative level
account. Administrative account details are included in the lab guide steps where relevant and in the server details table.
dCloud Topology
Lab Guide
Cisco dCloud
Equipment Details
Description Version IP Address Username Password
Cisco Unified Communications 12.5 198.18.133.3 administrator dCloud123!

Manager (Admin)
Cisco Unity Connection Server 12.5 198.18.133.5 administrator dCloud123!
Cisco Unified IM and Presence 12.5 198.18.133.4 administrator dCloud123!

Server (Admin)
Cisco Meeting Manager 2.8 198.18.135.77 administrator C1sco12345
Cisco Meeting Server 2.8 198.18.1.42 admin dCloud123!
Microsoft Active Directory 2012 198.18.133.1 administrator C1sco12345
Microsoft Exchange 2016 198.18.135.52 administrator C1sco12345
Cisco TelePresence Management 15.9 198.18.133.158 administrator C1sco12345

Suite
Cisco TelePresence Management 5.9 198.18.135.36 administrator C1sco12345

Suite XE
Cisco TelePresence Video 12.5.6 198.18.1.5 admin dCloud123!

Communication Server Expressway
Cisco TelePresence Video 12.5.6 198.18.133.152 admin dCloud123!

Communication Server Control
VMWare vCenter 6.7 198.18.1.40 administrator@vsphere.local C1sco12345!
Workstation1 Windows 10 Pro 198.18.1.36 DCLOUD\amckenzie dCloud12345!
Workstation2 Windows 10 Pro 198.18.1.37 DCLOUD\aperez dCloud12345!
Session Users
The table below contains details on preconfigured users available for your session.
User Details
User Name User ID Password Endpoint Devices Phone Email or Extension
Adam McKenzie amakenzie dCloud12345! N/A N/A Cisco Jabber
Anita Perez aperez dCloud12345! N/A N/A Cisco Jabber
Lab Guide
Cisco dCloud
Get Started
Follow the steps to schedule a session of the content and configure your presentation environment.
1. Initiate your dCloud session. [Show Me How]
NOTE: It can take up to 30 minutes for your session to become active.
2. For best performance, connect to the workstation with Cisco AnyConnect VPN [Show Me How] and the local RDP client on
your laptop [Show Me How]
• Workstation 1: 198.18.1.36, Username: amckenzie, Password: dCloud12345!
Lab Guide
Cisco dCloud
Scenario 1. Configuring the IP Interface for Admin and A Interface

Steps
1. RDP to Workstation 1 (198.18.1.36), log in with the following credentials:

a. Username: Adam McKenzie (dcloud\amckenzie)
b. Password: dCloud12345!
NOTE: Ignore any certificate warning.
2. From the desktop, launch Internet Explorer or Firefox. From the home page, navigate to Collaboration Admin Links >
vCenter.
3. Log into the VMware vCenter with these credentials:
a. Username: administrator@vsphere.local
b. Password: C1sco12345!
4. Press Login.
5. In the center-left window panel, expand dCloud_Datacenter > 198.18.1.41
6. Power on the Cisco Meeting Server (CMS) virtual machine and open the virtual console for the machine:
a. Click CMS1.
b. Click the Power On green arrow on the toolbar.
c. Click Launch Web Console.
d. Select Web Console option, click OK. This will open another tab in your browser with a console session into Cisco
Meeting Server.
7. When the Meeting Server console start up is complete, the Meeting Server login prompt displays. Log in with these
credentials:
a. User Name: admin

b. Password: admin (See NOTE below to set new password, if prompted)
Lab Guide
Cisco dCloud
NOTE: If this is the first time logging into the machine, you will be prompted to enter a new password and confirm it. Set the
new password for the admin account to dCloud123!
ATTENTION: The password automatically expires after 6 months. Password policies, including strength and expiration rules can
be customized using the user rule MMP commands. Please see the Password Rules section of the most recent Cisco Meeting
Server MMP Command Reference Guide for more information.
8. After successful login, a command prompt displays. This is the Meeting Server MMP interface and is accessible via the local
machine console SSH after the network interface has been configured.
NOTE: Meeting Server enforces an inactivity timer on all management interfaces. After approximately 30 seconds of inactivity
on any management interface, the software will automatically log you out. You must log back in with your credentials to
continue with your scenarios.
Interface A Configuration
NOTE: A virtual instance of Meeting Server can have up to four network interfaces labelled as a, b, c, and d. For this lab, you will
only use the A interface. The A interface must be configured with the IP address information to match the connected network.
1. To set the network interface speed duplex and auto-negotiate parameters, use the iface command. For example, to
display the current configuration on the A interface in the MMP, enter iface a. By default, you will observe the following
on the interface:
Lab Guide
Cisco dCloud
2. Set the network interface speed, duplex, and auto negotiation parameters using the iface (admin |a|b|c|d)
<speed> (full|on|off) commands.
a. Set the interface to: 1GE
b. Set the full duplex to: iface a 1000 full
3. Switch auto negotiation to on or off using the iface a autoneg <on|off> command.
NOTE: For this lab, use the following command: iface a autoneg on
4. Use the iface a command to confirm your changes.
NOTE: The A interface is initially configured to use DHCP. To view the existing configuration, type: ipv4 a. Use the ipv4 add
command to add a static IP address to the interface with a specified subnet mask and default gateway.
5. Add address 198.18.1.42 with a prefix 16 (netmask 255.255.0.0) with gateway 198.18.1.1 to interface A:
a. Type: ipv4 a add 198.18.1.42/16 198.18.1.1
b. The MMP interface is now be accessible via SSH to the IP address 198.18.1.42
6. From the desktop, open PuTTy [ ].
7. Check that you can connect with your preferred SSH client Workstation 1 installed via PuTTy using this Hostname (or
IP Address) 198.18.1.42. Click Open and click Yes to accept the security alerts.
8. Return to the Meeting server interface (CMS).
9. Log on to the Meeting Server with these credentials:
a. Username: admin
10. You can now minimize or close the VMware vSphere client.
Lab Guide
Cisco dCloud
NOTE: To remove the IPv4 address, type: ipv4a del
DNS Configuration
The Meeting Server requires DNS lookups for many of its activities, including looking up SRV records, and is required for a
simplified deployment. To view your current DNS configuration, type: dns. By default you will see the following message:
To set the application DNS server, complete these steps for the: dns add forwardzone <domain name> <server IP>
command.
1. RDP to Workstation 1 (198.18.1.36), log in as:
2. From the desktop, open PuTTy [ ]
3. From PuTTy, SSH onto the MMP using these credentials:
a. Hostname (or IP Address): 198.18.1.42
b. Click Open.
4. Log into the Meeting Server (CMS) with the following credentials:
a. Username: admin
5. To set the DNS to dcloud.cisco.com, type dns add forwardzone dcloud.cisco.com 198.18.133.1
Lab Guide
Cisco dCloud
6. Type dns to confirm the change of dns. The Meeting Server returns the status as running.
NOTE: A forward address zone is a pair consisting of a domain name and server address. If a name is below the given domain
name in the DNS hierarchy, then the DNS resolver can query the given server. Multiple servers can be given for any particular
domain name to provide load balancing and fail over. A common usage will be to specify “.” as the domain name, for example,
the root of the DNS hierarchy that matches every domain name.
Lab Guide
Cisco dCloud
Scenario 2. Setting a Hostname

Steps
The Meeting Server requires the hostname to be configured in order to identify the server in logs and messages.
1. If required, RDP to Workstation 1 (198.18.1.36).
2. Log into Workstation 1 using these credentials:

a. Username: Adam McKenzie dcloud\amckenzie
4. From PuTTy, SSH onto the MMP using:
b. Click Open
5. Log on to the Meeting Server with the following credentials:
a. Username: admin
6. To set the hostname, use the command: hostname cms1 for hostname <name>.
7. A reboot is required after issuing the hostname command. Type reboot in the command line.
NOTE: Allow a few minutes for the server to restart.
Lab Guide
Cisco dCloud
Scenario 3. Setting the MMP

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

3. At the PuTTy command line, complete the following steps:
a. Type the hostname (or IP Address): 198.18.1.42
b. Click Open
4. Log into the Meeting Server with the following credentials:
a. Username: admin
5. Create a new user with the admin permissions with the command: user add <name> admin.
6. Type: user add jbloggs admin
7. You are prompted to supply a password and confirm the password. For this scenario, use dCloud123!
NOTE: The first time the new user logs in, they are prompted to set their own password. Re-enter: dCloud123!
NOTE: You may need to close the existing PuTTy session and re-open a new session using the new credentials that you created
above.
NOTE: Any MMP user accounts at the admin level can also log into the Web Admin interface of the Call Bridge. You cannot
create users through the Web Admin Interface.
Lab Guide
Cisco dCloud
Scenario 4. Upgrading Software (If Necessary)

Steps
NOTE: It is recommended that before upgrading your Meeting Server, you should make a backup of the current configuration
on each server. Do not use the automatic backup file that is created during the upgrade process.
Use the MMP command: backup snapshot <name>.
Save the backup safely to a local server. See the MMP Command Reference guide for full details.
NOTE: It is also recommended to save the cms.lic and certificate file to the local server and to use the Web Admin interface
to check the database cluster status, all call (SIP and clients) are working, and no faults conditions are listed.
NOTE: In order to pull files from the Meeting Server, and add a file to it, an SFTP client is required. SFTP is used to copy backup
files, install licenses, upgrade the server, pull CSRs, and add signed certificates. We will be using WinSCP to transfer files;
however, however any SFTP client can be used (for example. FileZilla).
To check which version the Meeting Server is running:
3. To SSH onto the MMP at the PuTTy command line:

b. Click Open

a. Username: admin
5. At the prompt, type: version
6. Open the WinSCP client icon on the desktop.
Lab Guide
Cisco dCloud
7. Use the following credentials to log in:
a. Host name: 198.18.1.42

b. Port Number: 22
c. Username: admin
d. Password: dCloud123!
8. Click Login. Click Yes at the warning screen prompt.
9. Navigate to the local site C:\Users\amckenzie\Desktop\CMS Software\Cisco_Meeting_Server_2_8_vm-upgrade\ or by

selecting Desktop from the dropdown list, and then navigate through the folders.
Lab Guide
Cisco dCloud
NOTE: To upgrade to another version, first download and extract the appropriate software from the Cisco Website. Click on this
link, then click on the appropriate Meeting Server listed in the right-hand column of the web page and follow any instructions
displayed with the download link.
10. Highlight the upgrade.img file from the folder and drag them over to the Meeting Server under the Remote Site root file.
11. Once the file has been transferred, minimize or exit out of WinSCP.
12. On the desktop, open PuTTy [ ] with the following credentials:
b. Click Open
a. Username: admin
14. To complete the upgrade, type: upgrade Cisco_Meeting_Server_2_8_vm-upgrade.img
15. Allow a few minutes for the server to upgrade.
16. To verify that the upgrade was successful, SSH into the MMP using PuTTY.
17. Login with these credentials:
a. Username: admin
18. Type this command: version.
Lab Guide
Cisco dCloud
Scenario 5. Obtaining and Assigning a License

Steps
NOTE: You need license files specific to your Meeting Server instance to complete any deployment. Meeting Server licenses are
delivered using Cisco’s Product Activation Keys (PAK) and fulfilled using Cisco’s License Registration Portal.
NOTE: For detailed information on different Meeting Server licensing models, see the licensing chapter in the larger
deployment guides.
This lab already has the license that is required for the Meeting Server.
1. Open the WinSCP client using the icon located on the desktop.
2. Login using the following credentials:
a. Host name: 198.18.1.42
b. Port Number: 22
c. Username: admin
3. Click Login.
4. Navigate to the local site: C:\Users\amckenzie\Desktop\CMS Certs and License\ or by selecting Desktop from the
dropdown list, and then navigate through the folders.
Lab Guide
Cisco dCloud
5. Highlight the cms.lic file from the folder and drag the file over to the Meeting Server under the Remote Site root file.
7. Open PuTTY from the desktop [ ].
b. Click Open
a. Username: admin
9. To check the license status, type license.
10. If updated with the new license, Call Bridge may need to be restarted.
NOTE: If the license has been updated, then you do not need to use the callbridge-restart command.
11. Optional: If you need to restart Call Bridge, type callbridge restart.
Lab Guide
Cisco dCloud
Scenario 6. Configuring the Network Time Protocol (NTP) Server

Steps
NOTE: Sharing a common view of time is important for multiple reasons. Time synchronization is necessary when checking for
certificate validity and to prevent replay attacks.
1. If required, RDP to Workstation 1 (198.18.1.36), log in as Adam McKenzie (dcloud\amckenzie with password:
dCloud12345! From the desktop, launch PuTTy [ ].
2. Within PuTTy, SSH onto the MMP:
b. Click Open
3. Log on to the Meeting server with the following credentials:
a. Username: admin
4. To set up an NTP server, enter the command: ntp server add 198.18.133.1
5. To check the status/configured NTP status, type: ntp status
Lab Guide
Cisco dCloud
Scenario 7. Generating Certificates for the Meeting Server

Meeting Server uses x.509 certificates to configure secure (TLS) connections in its services and for some authentication
scenarios. In this lab, certificate configuration is required for the Call Bridge, XMPP, Web Bridge and Web Admin services.
Certificates can be self-signed or signed by internal or external certificate authorities. For a full explanation of certificate uses
and requirements, please see the Certificate Guidelines.
File names are restricted on Meeting Server, so your files must use common file extensions such as .crt, .cer, .key, .pem or .der
For this simplified lab, we will use one x.509 certificate with the correct attributes signed by an internal CA. Using a self-signed
certificate here is possible but is not recommended as it can cause errors to be seen in web pages and prevents you from
incorporating Meeting Server into Unified CM as a conference bridge.
For this lab, our certificate should have the server FQDN as the Common Name (CN) and must have the domains in the Subject
Alternate Name (SAN) attribute of the certificate, for example. XMPP, Join (WebRTC) etc.
To generate a Certificate Signing Request (CSR) and private key locally, the following command is used:
Pki csr <key/cert basename> <CN:value> [OU:<value>] [O:<value>] [ST:<value>] [C:<value>]
[subjectAltName:<value>]
The CN value should always be part of the SubjectAltName (SAN) list. The Meeting Server pki csr command adds the CN to
the SAN list automatically so you do not have to list it separately.
Steps
1. If required, RDP to Workstation 1 (198.18.1.36) and login using these credentials.

3. In PuTTy, SSH onto the MMP:

b. Click Open
4. Log into Meeting Server with the following credentials:

a. Username: admin
5. Open the CMS Certs and License folder on the desktop. Open the PKI CSR file to copy and paste the following: pki csr
singlecert CN:cms1.dcloud.cisco.com OU:dcloud O:Cisco L:Richardson ST:Texas C:US
subjectAltName:webbridge.dcloud.cisco.com,xmpp.dcloud.cisco.com,callbridge.dcloud.cisco.com,j
oin.dcloud.cisco.com,webadmin.dcloud.cisco.com
Lab Guide
Cisco dCloud
NOTE: The output from this command generates a private key file with the extension of a key and a Certificate Signing request
(CSR) file with the extension .csr on the local file system. See below.
6. Open the WinSCP client located on the desktop.
7. Login using the following credentials:

a. Host name: 198.18.1.42
b. Port Number: 22
c. Username: admin
8. Click Login, then click Yes at the warning screen prompt.

9. Navigate to the local site: C:\Users\amckenzie\Desktop\CMS Certs and License\ or by selecting Desktop from the
dropdown list, and then navigate through the folders.
Lab Guide
Cisco dCloud
10. Highlight the singlecert.csr file under the Remote Site root folder and drag it over in to the Meeting Server Certs and
License folder.
11. When the file has been transferred, minimize or exit out of WinSCP.
12. From the desktop, open the CMS Certs and License folder.
13. Open the singlecert.csr file you downloaded from the Meeting Server into Notepad.
14. Open the file by following these steps:
a. Select Edit > Select All
b. Select Edit > Copy
c. Close Notepad
15. Open Internet Explorer from the toolbar. Go to https://ad1.dcloud.cisco.com/certsrv/
16. Log in with these credentials:

a. Username: administrator
b. Password: C1sco12345
17. From the list of tasks, select Request a certificate. Click Advanced certificate request.
18. Select Submit a certificate request by using the base-64-encoded CMS or PKCS 10 file.
Lab Guide
Cisco dCloud
19. Populate the Certificate request or Renewal Request form with the following Information:
a. Base-64 encoded Certificate request field: Paste (CTRL-V) the singlecert.csr content that you copied from Notepad into
the field.
b. Certificate Template: ClientServer.
20. Click Submit and select Yes to any warnings.
21. The certificate has now been issued. Select Base 64 encoded radio button and Download certificate.
22. Select the Save option.
Lab Guide
Cisco dCloud
23. Save the certificate to the CMS Certs and License folder.
24. Rename the certificate to singlecert.cer.
25. Close the Internet Explorer window.
26. From the desktop, open the WinSCP client using the icon on the desktop.
27. Log in using these credentials:
a. Host name: 198.18.1.42
b. Port Number: 22
c. Username: admin
28. Click Login. Click Yes at the warning screen prompt.
29. Navigate to the local site: C:\Users\amckenzie\Desktop\CMS Certs and License\
Lab Guide
Cisco dCloud
30. Highlight the singlecert.cer and CA-bundle.cer file from the folder and drag the file over to the Meeting Server under the
Remote Site root file.
Lab Guide
Cisco dCloud
Scenario 8. Enabling Call Bridge Service

The Call Bridge is the component on the Meeting Server. The Call Bridge exchanges audio and video streams so that participants
can see and hear each other. This service must be activated before any calls can be placed. The Web Interface will show licenses
are not installed when this service is disabled, even if licenses are in fact installed. Call Bridge service is also required for CMA
and WebRTC to operate.
Steps
NOTE: The Call Bridge service must be configured with the certificate to use and which network interface to listen on.


b. Click Open
3. Log on to the Meeting Server with these credentials:

a. Username: admin
4. To view the list of certificates generated in the previous task, type the command: pki list in the command line.
NOTE: The command callbridge listen <interface> allows you to configure a listening interface (chosen from a, b, c, or
d). By default, the Call Bridge listens on no interface.
5. In PuTTy, type the command: callbridge listen a
NOTE: The Call Bridge must be listening on a network interface that is not NAT’d to another IP address. This is because the Call
Bridge is required to convey the same IP that is configured in the SIP messages when talking to remote sites.
6. To configure the Call Bridge to use the certificate, key and bundle verified in step 4, then use the callbridge certs
<keyfile> <certificatefile> <ca bundle> command: callbridge certs singlecert.key singlecert.cer CA-bundle.cer.
Lab Guide
Cisco dCloud
NOTE: The Call Bridge interface needs to be restarted with the command: callbridge restart to apply the changes.
Lab Guide
Cisco dCloud
Scenario 9. Enabling the Web Admin Service

The Web Admin Interface is the browser-based interface to the Meeting Server and the Call Bridge service. Before it can be
enabled, the Web Admin service must be configured with the correct certificate to use as well as the correct interface to listen
on. By default, Web Admin listens on the standard HTTPS port of 443. However, in this deployment we will enable the Web
Bridge for conference users and want that service to be available on the default HTTPS port. To enable both services to co-exist,
we will configure Web Admin to listen on port 445 and require administrators to supply the extra port information when
browsing to the Web Admin interface.
Steps
b. Click Open
4. Log into Meeting Server with the following credentials:
a. Username: admin
5. Type webadmin listen a 445, the MMP command webadmin listen <interface> <port> to instruct Web Admin to
listen on interface a port 445.
6. To configure Web Admin with the certificate file, type: webadmin certs singlecert.key singlecert.cer CA-bundle.cer, for the
webadmin certs <keyfile> <certificatefile> <ca bundle> command.
7. Enable Web Admin service with the command: webadmin enable.
8. When successful, you get SUCCESS lines returned stating Web Admin is correctly configure for network and certificate
values.
9. If not successful, type: webadmin.

a. Check for any typing errors with the files specified.
b. Correct any errors before enabling the service before proceeding.
10. Check by opening Internet Explorer, then type: https://cms1.dcloud.cisco.com:445
Lab Guide
Cisco dCloud
Scenario 10. Configuring Basic Call Settings

The Call Bridge service is now running; however, it is using only the system defaults. In this scenario, we will configure some
common settings needed before making test calls.
Steps

2. From the desktop, open Internet Explorer and from the home page navigate to Collaboration Admin Links > Cisco Meeting
Server.
3. Log into the Meeting Server Web Admin Interface with these credentials:
a. Username: admin
4. Press OK.
5. Select Configuration > Call settings.

6. Complete the Call settings Configuration as follows:
a. SIP media encryption, select: allowed
NOTE: The SIP Media encryption setting must be compatible with your existing call control and endpoints. The setting
recommended for most usage is Allow. This setting allows both encryption and non-encryption connections. Take care before
setting to Required if you want to specify encryption is required before calls can connect – a mismatch of encryption between
the Meeting Server and the devices will prevent a call from connecting.
b. SIP call participants labels, select: enabled
NOTE: The SIP call participants labels enables site names to be display overlaid on video images. Enabling participant’s labels is
encouraged for those migrating from MCU’s that use this feature.
7. Click Submit.
NOTE: Customize the maximum bandwidth per call to use for different call types. Bandwidth numbers are bits/sec. We
recommend leaving the bandwidth values at their default settings.
Lab Guide
Cisco dCloud
Scenario 11. Configuring Incoming Call Rules

The Configuration > Incoming calls page determines how the Meeting Server handles incoming SIP calls. Any call routed to the
meeting Server will have the alias being called checked against the rules in the Call Matching table to determine where the
Meeting Server should look for potential matches. Each rule can be set to match for any combination of users, spaces, IVR’s or
Microsoft Skype/Lync lookups. Meeting Server matches incoming calls by checking the value after the “@” symbol with the
values in the domain column.
The Call Matching figure shown below seeks to match all incoming calls on the meet.company.com domain to both Cisco
Meeting App, users, and spaces.
Steps
NOTE: We recommend that rules are created for every domain expected for incoming calls. With some call control solutions the
domain in the alias may be the IP address or hostname of the Meeting Server.
Rules with a higher priority value are matched first. In case where multiple rules have the same priority, matching occurs based
on the alphabetical order of the domain.
After a rule is matched and executed, rules further down the list are ignored for the call. If all Call Matching rules fail, the next
table (Call Forwarding) is checked.
NOTE: Call forwarding is not covered in this lab.
2. From the desktop, open Internet Explorer.
a. Username: admin
4. Select Configuration > Incoming calls.
Lab Guide
Cisco dCloud
5. Complete the configurations as follows:
a. Domain name: a.dcloud.cisco.com

b. Priority: 100
c. Target spaces, Target users and Target IVR’s: yes
6. Click Add New to save the changes.
Lab Guide
Cisco dCloud
Scenario 12. Configuring Outgoing Call Rules

To make outgoing calls from the Meeting Server, calls must be directed via the Outbound Call Rules to a destination, such as the
Unified CM or Expressway/VCS. Similar to the incoming call rules, all routing is based on the domain of the dialed alias. Rules are
processed from the highest priority to the lowest, and if matched, the Meeting Server attempts to send the call to the defined
SIP proxy. The Behavior setting is a rule that controls whether further rules are processed or if the rule matches, but the remote
proxy rejects the call. For this lab deployment, we will route all outbound calls to our singular call control (Unified CM or
Expressway/VCS).
Steps
2. From the desktop open Internet Explorer.
3. In your browser, navigate to https:cms1.dcloud.cisco.com:445
4. Click Ok.
a. Username: admin
6. Select Configuration > Outbound calls.
7. Enter the following information under Outbound calls:
a. Domain: dcloud.cisco.com
b. SIP Proxy: cucm1.dcloud.cisco.com
c. Local contact domain: leave blank
d. Local from domain: leave blank
e. Trunk Type: Standard SIP
f. Behavior: Stop
g. Priority: 100
h. Encryption: Auto
Lab Guide
Cisco dCloud
8. Click Add New to save the changes.
Lab Guide
Cisco dCloud
Scenario 13. Creating a Test Space

Once the call control has been configured in this scenario, creating a test space allows you to verify your configuration. Aliases
defined in this table will only include the left-hand side of the SIP URI. The incoming call rules table handles matching on the
right-hand side of the alias.
Steps
3. In your browser, navigate to https:cms1.dcloud.cisco.com:445
4. Click Ok.
a. Username: admin
6. Select Configuration > Space.
7. Use an empty row to create a new space. Enter the following information in these fields:
a. Name: Test Meeting

b. URI user part: test
c. Call ID: 1001
8. Click Add New [ ], located on the right side of the table, to save the new values.
Lab Guide
Cisco dCloud
Scenario 14. Unified CM: Adding Calling Rules to the Call Control for the
Meeting Server
This scenario will cover tasks required to set up a Cisco Unified CM example. In the previous scenario you configured the
Meeting Server to listen to incoming Calls and to send calls. In this scenario, you will configure your Call Control to identify calls
intended for the Meeting Server and configure their destination.
In this lab, the Meeting Server listens for SIP calls on the A network interface when the Call Bridge is listening on TCP ports 5060
or 5061. Now, you will configure your Call Control to identify which alias patterns are intended for the Meeting Server and the
trunks/zones of where to send calls.
This scenario adds a dial plan configuration to an existing Cisco Unified CM to route SIP URIs and E.164 dial patterns to the
Meeting Server using SIP TLS. While using the TLS is usually described as a best practice, using SIP TCP port 5060 is also valid.
NOTE: SIP TCP configuration is not covered in this guide. See Cisco Meeting Server 2.x with Cisco Unified Communications
Manager Deployment Guide for more details.
Steps
Creating a SIP Trunk Security Profile
The Cisco Unified Communication Manager applies a default security profile called a No Secure SIP Trunk. Creating a SIP Trunk is
used for TCP.
To use TLS, or something other than the standard security profile, follow these steps:

3. Navigate to the Cisco dCloud Hompage (http://ad1.dcloud.cisco.com/dCloud/default.html).
4. Select Collaboration Admin Links > Cisco Unified Communication Manager.
5. Log into the Cisco Unified Communication Manager with these credentials:
a. Username: administrator
6. Select System > Security > SIP Trunk Security Profile.
7. Click Add New.
Lab Guide
Cisco dCloud
8. Enter the following information in these fields:
a. Name: dCloud_TLS_Security_Profile_CMS
b. Select the Device Security Mode: Encrypted
c. Select the Incoming Transport Type: TLS
d. Select the Outgoing Transport Type: TLS

e. X.509 Subject Name: cms1.dcloud.cisco.com
f. Incoming Port: 5061
g. Select the boxes for:
• Accept presence subscription
• Accept out-of-dialog refer
• Accept unsolicited notification
• Accept replaces header
9. Click Save.
Lab Guide
Cisco dCloud
Creating a SIP Trunk
When you create a SIP Trunk for TCP, the Cisco Unified Communication Manager applies a default security profile called the No
Secure SIP Trunk.
To use TLS, or something other than the standard security profile, follow these steps:
1. Select Device > Trunk.

2. Click Add New.
3. Configure these fields:
a. Select Trunk Type: SIP Trunk
b. Device Protocol: SIP (selected by default)
c. Trunk Service Type: None (selected by default)
4. Click Next.
5. Configure the Device Information for the following fields:
a. Device Name: dCloud_SIP_Trunk_CMS
b. Device Pool: Select dCloud_DP
c. Common Device Configuration: dCloud Common Device Configuration
d. Media Resource Group List: dCloud_MRGL
e. Location: dCloud_Location
f. Select the box for SRTP Allowed
Lab Guide
Cisco dCloud
6. In the Inbound Calls screen, select dCloud_CSS.
7. Configure SIP Information screen with the following information:

a. Destination Address: Enter cms1.dcloud.cisco.com
b. Destination Port: Enter 5061 for TLS
c. SIP Trunk Security Profile: Select the security profile that you previously created - dCloud_TLS_Security_Profile_CMS
d. SIP Profile: dCloud Standard SIP Profile
e. Normalized Script: Select cisco-meeting-server-interop
8. Click Save.
9. Click Ok to accept the warning that a trunk rest reset is required.
10. Click Reset, Reset again, and Close.

11. At the top right of the screen, click Go at Related Links - Back to Find/List. After a few minutes, verify from the Trunk List to
confirm the trunk is in service.
Lab Guide
Cisco dCloud
Configuring Route Patterns
You can configure domain-based routing, for example, Meet.Company.com, and/or number-based routing, for example,
86XXXX, to the Meeting Server through the Cisco Unified Communication Manager Interface.
Configuring Domain-Based Route Patterns
To configure domain-based routes, follow these steps:
1. In your browser, select Call Routing > SIP Route Pattern.

2. Click Add New. The Status window opens.
3. In the Status window, enter or select the following information:
a. Pattern Usage: Domain Routing
b. IPv4 Pattern: a.dcloud.cisco.com
c. Description: anything you want to enter
d. Route Partition: dCloud_PT
e. SIP Trunk/Route List: Select the trunk you configured in the previous section, which is dCloud_SIP_Trunk_CMS
4. Click Save. The domain-based route is configured.
Configuring Numeric-Based Route Patterns
1. In your browser, select Call Routing > Route/Hunt > Route Pattern. A list of existing Route Patterns is displayed.
2. Click Add New.
Lab Guide
Cisco dCloud
3. In the Status window, enter or select the following information:
a. Route Pattern: 860000

b. Route Partition: dCloud_PT
c. Description: any appropriate text
d. Gateway/Route List: dCloud_SIP_Trunk_CMS
4. Click Save.
5. Click OK at the notification warnings.
Testing Route Pattern Configurations
Now that the call control is configured, you can dial into the test conference created in Scenario 13 to validate the configuration
for this scenario. With an endpoint registered to this session or with one of the Cisco Jabber clients on the workstations, dial the
SIP URI of the test meeting that was created earlier.
1. If required, RDP to Workstation 1 (198.18.1.36).
2. Log in with these credentials:
3. From the desktop, launch Cisco Jabber client. If required, login with these credentials:
a. Username: amckenzie
Lab Guide
Cisco dCloud
4. Once the client is ready and connected, within the Search or Call field, enter test@a.dcloud.cisco.com and click Call. You
are now in the Test conference meeting space.
5. End the call and then minimize or exit out of Cisco Jabber and Internet Explorer.
Lab Guide
Cisco dCloud
Scenario 15. Enabling the Web Bridge

To support the Web Bridge functionality, the XMPP service must also be deployed. This scenario has three phases:
1. Enable the XMPP service.
2. Configure the XMPP service to work with the Call Bridge.
3. Enable the Web Bridge.
Steps
Enabling the XMPP Service
3. At the PuTTy command line, complete the following steps:

b. Click Open
a. Username: admin
5. Enter xmpp listen a for the MMP command xmpp listen <interface whitelist> to instruct XMPP Server to
listen on interface a.
6. Enter xmpp certs singlecert.key singlecert.cer CA-bundle.cer to configure XMPP with the certificate file,
using the xmpp certs <keyfile> <certificatefile> <ca bundle> command format.
7. You will define the XMPP domain for the deployment with the command xmpp domain <domain name> by entering
xmpp domain dcloud.cisco.com.
8. Enable the XMPP service by entering xmpp enable. The screen will show a message that XMPP is correctly configured and
enabled.
Adding the Call Bridge to the XMPP Server
In the second phase, the Call Bridge requires a set of credentials to connect to the XMPP server. These credentials are created in
the XMPP server and subsequently added to the Call Bridge configuration.
Lab Guide
Cisco dCloud
Complete these steps to add the Call Bridge to the XMPP server:
3. At the PuTTy command line, SSH into the MMP with these credentials:
a. Hostname (or IP Address: 198.18.1.42
b. Click Open
a. Username: admin
5. Enter xmpp callbridge add dCloud_Component for the MMP command xmpp callbridge add <component
name> to provide a component name for the Call Bridge for authentication.
6. A secret is generated in alphanumeric format.
NOTE: Make sure you document the domain, component name, and secret generated because they are required when you use
the Web Admin interface to configure the Call Bridge access to the XMPP server.
NOTE: If you lose the details, use the MMP command xmpp callbridge list to display them.
Lab Guide
Cisco dCloud
Enabling the Web Bridge on Interface A
Complete these steps to enable the Web Bridge interface A:

3. At the PuTTy command, line SSH into the MMP with these credentials:
b. Click Open
a. Username: admin
5. Type webbridge listen a:443 for the MMP command webbridge listen <interface[:port]> to instruct the
Web Bridge to listen on interface a port 443.
6. Type webbridge certs singlecert.key singlecert.cer CA-bundle.cer to configure the Web Bridge with the
certificate file, using the webbridge certs <keyfile> <certificatefile> <ca bundle> command.
7. For the Call Bridge to instruct the Web Bridge to trust connections from the Call Bridge, type webbridge trust
singlecert.cer for the MMP command webbridge trust <certfile>
8. To enable the Web Bridge service, type webbridge enable. The screen will show a success message that the Web Bridge
is configured properly.
Configuring XMPP Server Settings via the Web Admin Interface
Complete these steps to configure XMPP Server via the Web Admin interface:
3. In your browser, navigate to https://cms1.dcloud.cisco.com:445

Lab Guide
Cisco dCloud
4. Click OK.
a. Username: admin
6. Select Configuration > General.

7. In the General Configuration screen, complete these steps to configure the Active Directory:
a. Unique Call Bridge name (this is the component name previously set up, no domain part is required):
dCloud_Component
b. Domain (this is the XMPP server domain set up previously): dcloud.cisco.com
c. Server Address (this is the IP address or hostname of the XMPP): cms1.dcloud.cisco.com

d. Share the secret (generated during the XMPP server configuration): click change link, populate the secret key in this
field and confirm the shared secret field
8. Enter Submit to save your configuration.
9. Select Status > General to verify the server connection. You should see details similar to the following in the XMPP
Connection field.
Lab Guide
Cisco dCloud
Configuring the Web Bridge for the Call Bridge
To enable Guest access to the Web Bridge, the Call Bridge must be configured to locate the Web Bridge.
Complete these steps to configure the Web Bridge to connect with the Web Bridge:
1. If required, RDP to Workstation 1 (198.18.1.36) and login using these credentials:

3. In your browser, navigate to https://cms1.dcloud.cisco.com:445
4. Click OK.
a. Username: admin
6. Select Configuration > General.
7. Set the Guest account client URI to the HTTPS URL for your Meeting Server by typing https://join.dcloud.cisco.com
8. Type dcloud.cisco.com to set the Guest Account JID domain to your XMPP domain.
9. Set the IVR numeric ID by entering 860000
10. Set the Web Bridge URI-to go to External Access and enter the HTTPS URL https://join.dcloud.cisco.com for your Meeting
Server.
11. Click Submit to save your changes.
12. Confirm the Call Bridge is not reporting any errors for the Web Bridge by selecting Status > General and checking there are
no alarms in the Fault conditions panel.
Test: Web Bridge Functionality
2. From the desktop, open Chrome.
Lab Guide
Cisco dCloud
3. Navigate to https://join.dcloud.cisco.com. Sign in and join the meeting as a Guest and follow these steps:
NOTE: Ensure you Sign In and Join Meeting as a Guest.
a. Click the Join Meeting option.
b. Enter 1001 for the meeting ID, which was set up in Scenario 13.
c. Click Join meeting (no password was set up).
d. Enter a name for the guest user (Any name) and click Join meeting.
e. Accept the default Camera, Microphone, and Speaker settings, click Join meeting.
f. The WebRTC app will load and allow your user into the Test space.
4. RDP to Workstation 2 (198.18.1.37), login using these credentials:
a. Username: Anita Perez (dcloud\aperez)
5. From the desktop, launch Cisco Jabber Client. If required, login using these credentials:
a. Username: aperez
6. Once the client is ready and connected, within the Search or call field enter test@a.dcloud.cisco.com. Click Call. You are
now in Test conference meeting space.
7. You can now end the call within the browser on Workstation 1 and Jabber client on Workstation 2.
Lab Guide
Cisco dCloud
Scenario 16. Configuring the User Import Feature

Importing users from an LDAP directory allows conference participants to log into Cisco Meeting App using their own account to
manage their spaces and join meetings. Participants can also join meetings as ‘guest users’, however, guest users cannot
manage meetings or create/manage spaces.
The LDAP import in Meeting server allows you to specify which users to target from an existing directory, and the values to use
for the resulting accounts. The import also 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, we will import all users from Active
Directory, set their login that they will use and create a space for each user.
Steps
1. If required, RDP to Workstation 1 (198.18.1.36), log in with these credentials:
2. From the desktop launch Internet Explorer. Browse to https://cms1.dcloud.cisco.com:445. Click Ok.
3. Log in to the Meeting Server Web Admin Interface using these credentials:
a. Username: admin
4. Navigate to Configuration > Active Directory.
5. Complete the Active Directory configuration as follows:

a. Active Directory Server Settings:
• Address: ad1.dcloud.cisco.com
• Port: 389
• Username: cn=administrator,cn=users,dc=dcloud,dc=cisco,dc=com
• Password (Click change): C1sco12345
• Confirm Password: C1sco12345
b. Import Settings:
• Base distinguished name: dc=dcloud,dc=cisco,dc=com
• Filter: telephoneNumber=*
c. Field Mapping Expression:
• Display name: $cn$
• Username: $sAMAccountName$@dcloud.cisco.com
• Space name: $cn$’s Meeting Space
• Space URI user part: $sAMAccountName$.space
• Space call ID: $ipPhone$
Lab Guide
Cisco dCloud
6. Click Submit. This will save the changes.
7. Then click Sync now to start the LDAP import.
8. After a minute or two, navigate to Status > Users. It should display the user created by the LDAP import.
Lab Guide
Cisco dCloud
9. The navigate to Configuration > Spaces. It should display the spaces that were created from the imported users.
NOTE: If the user list is empty, navigate to Logs > Event Log. Locate the entries starting with LDAP sync operation: Any errors
about attributes missing or duplicate entries means you Field Mappings or search criteria needs adjusting to avoid errors. Go to
Configuration > Active Directory and modify your import settings, click Submit and Sync now to retry the import.
Test – Confirm Web Bridge Logins
1. RDP to Workstation 1 (198.18.1.36), log in with these credentials:

2. Launch Chrome from the desktop.
3. Browse to https://join.dcloud.cisco.com. The welcome screen should display Sign In and Join Meeting as guest options.
4. Click Sign In. This will allow you to log in with an account that was included in the LDAP import:
a. Meeting ID: Enter the call ID amckenzie@dcloud.cisco.com
5. Click Sign in.
Once logged in successfully, the WebRTC app will load and the user can open their existing space, dial out to remote
participants, or have other participants dial into the space.
Lab Guide
Cisco dCloud
Scenario 17. Cisco Meeting Management

The goal of the scenario is to configure Unified CM, TMS, and CMS to demonstrate features including Call Bridge, recording, and
live streaming. Additionally, you will get to use the enhancements for CMS edge service in Expressway (Unified Edge), and Cisco
Meeting Management (CMM). CMM is a tool that will initially allow control of active meetings, but will ultimately grow to cover
control, configuration, and management of the CMS system.
This scenario consists of a preconfigured standalone Unified CM and TelePresence Management Suite (TMS), two clustered
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 following tasks will be accomplished for the CMM in this scenario:
• Install and Configuration in VMware
• Login to CMM and Configure
• Add a CallBridge to CMM
• Ad-hoc Conferencing
CMM is a 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

• Licensing and Utilization
Lab Guide
Cisco dCloud
Steps
Install and Configuration of CMM in VMWare
The CMM OVA is already deployed on the Vsphere VM.
1. RDP to Workstation 1 (198.18.1.36) and, if necessary, log in with the following credentials:
2. Using any browser, click Collaboration Admin Link and click Vcenter.
3. Log in with the following credentials:
a. Username: administrator@vsphere.local
b. Password: C1sco12345!
Lab Guide
Cisco dCloud
4. Click through the following path:
a. vc1.dcloud.cisco.com
b. dcloud_Datacenter
c. IP address
5. Hover over CMS. Notice it is on.

6. Click CMM.
7. Click the green arrow to power on the CMM VM.
Lab Guide
Cisco dCloud
8. Click Launch Web Console.
9. Select Web Console in the pop-up screen. Click OK.
Lab Guide
Cisco dCloud
10. Click in the main screen and press Tab key. This will highlight Next. Press the Enter key to go to the next screen.
Lab Guide
Cisco dCloud
11. Enter the following data:
a. Hostname: CMM
b. Address acquisition: Manual
c. IP address: 198.18.1.43
d. Subnet mask: 255.255.0.0

e. Gateway: 198.18.1.1
f. DNS Server: 198.18.133.1
Lab Guide
Cisco dCloud
12. Select Done. The CMM will start to initialize.
13. CMM is ready to use when you receive the message screen below. Make note of the generated Administrator credentials.
NOTE: This is an example. Your password will be different.
Lab Guide
Cisco dCloud
14. In any browser, type https://cmm.dcloud.cisco.com. Accept any security warnings.
15. Enter the generated Administrator username and password. Click Sign In.
16. You will be prompted to change the password. Change the password to dCloud123! and click Save.
Lab Guide
Cisco dCloud
17. You will see the main CMM Overview page.
Login to the CMM and Configure
1. RDP to Workstation 1 (198.18.1.36) and, if necessary, log in with the following credentials:
2. Using any browser, navigate to Collaboration Admin Links and select Cisco Meeting Manager.
Lab Guide
Cisco dCloud
3. Login with these credentials:
a. Username: admin
4. The Overview will be the single place to view the status of you entire CMS system (single, cluster, distributed) and shows
information such as the number of active calls, total spaces, and number of meetings.
Lab Guide
Cisco dCloud
5. In the left column, click Settings [ ]. Confirm Network Settings: Hostname, DNS Servers, and IPv4 information. (Scroll
down the Settings window for more information.)
Lab Guide
Cisco dCloud
6. Click NTP to confirm the NTP Status. At least one IP address has sys-peer (green) status. If no IP address is green, click Add
NTP server and follow the steps below to edit the server IP addresses.
7. Add both IP addresses and click Add:
• 198.18.133.1
• 198.18.128.1
Lab Guide
Cisco dCloud
8. Notice the servers are added. Click Restart now at the top of the page.
9. After CMM restarts, NTP should be synchronized to one IP Address.
Lab Guide
Cisco dCloud
10. Click CDR. Add the CMM FQDN: cmm.dcloud.cisco.com and click Save.
11. Click Restart now at the top of the page to assign the CMM as the CDR receiver. Click Restart when prompted, “Are you
sure you want to restart Meeting Management now?”
Lab Guide
Cisco dCloud
12. Click Users to confirm User Group Details and LDAP Configuration.
NOTE: We are not using the Local and Local Configuration, so they will not be configured.
13. To add a Local User to the Local group, click Local. Click Add Local User.
14. Add the following:
a. Username: jdaniels
b. First Name: Jack
c. Last Name: Daniels

d. Keep Role as Administrator
e. New password: dCloud123!
Lab Guide
Cisco dCloud
15. Click Add.
16. Confirm Jack Daniels has been added to Local User group.
Lab Guide
Cisco dCloud
OPTIONAL: If you want to test the Jack Daniels account, sign out of CMM and re-login with jdaniels credentials. See the
screenshot below.
Add a CallBridge to CMM
1. Click Servers to add a Callbridge to CMM. Click Add Call Bridge.
Lab Guide
Cisco dCloud
2. Add the following information:
a. Server Address: cms1.dcloud.cisco.com

b. Port: 445
c. Username: admin
e. Display name: dcloud-CMS1
f. Add check mark: Use trusted certificate chain to verify
Lab Guide
Cisco dCloud
3. Click Upload certificate. This will take you to the computer’s Directory. Navigate to the CMM Certificate: Desktop > New CA
Certs > CMM > Certificates. Select the CMM-Certificate-chain.cer file and click Open.
Lab Guide
Cisco dCloud
4. Click Add to upload the certificate to the CMM.
5. Confirm the upload was successful. A green box with a check will appear and display the newly added Callbridge to CMM.
Lab Guide
Cisco dCloud
Then the green box will disappear and CMM Server section look like below.
NOTE: Most notications warning/errors will have disappeared with adding the CMS Callbridge successfully. We do have SSL
Certifcate for the CMM that has expired. We are using the certificate that is native the dCloud certificate.
Ad-hoc Conferencing
Ad-hoc Conferencing uses the CMS Spaces with Workstation 1 and Workstation 2 dialing into Anita Perez’s Space.
1. At Workstation 1, Adam McKenzie Jabber client dials aperez.space@a.dcloud.cisco.com. Adam’s Jabber client joins Aperez
Space as a participant.
2. At Workstation 2, Anita Perez Jabber client dials aperez.space@a.dcloud.cisco.com. Anita’s Jabber client joins Aperez
Space as a participant.
3. Go to the CMM. Click Meetings and click Active to view active meetings on CMS.
4. Click Anita Perez’s Meeting Space to expand the list of participants, status, and meeting options available for this space.
Lab Guide
Cisco dCloud
5. Click the ellipses [ … ] for any participant’s name. You will see options available as individual participants 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 Call information and Stats. Some action items include:
a. If you hover over the Actions section, you can see the call controls for controls to audio/video or drop the participants
items.
b. If you select a participant in the meeting details, a side panel with call information and individual control will open.
Scroll down to see call stats.
c. If you select Layout, you can change the video layout for all participants who are dialing in from a SIP Endpoint.
Changing of the layout will only affect participants in the meeting and can subsequently change their layouts.
Lab Guide
Cisco dCloud
6. Click the X to close out this field. (See graphic above.)
7. Click on any participants to change their layout, or mute/unmute participants, stop/start video of participants.
8. Disconnect all participants by pressing End Meeting icon. Click End when prompted, “Are you sure you want to end this
meeting? This will disconnect all participants.”
9. Notice all participants change from green check marks to red X next to the their names.
Lab Guide
Cisco dCloud
10. Notice eventually all participants associated to the Anita Perez Space will disappear and no Active meeting will be shown.
Lab Guide
Cisco dCloud
What’s Next?
Ready to learn more? Try the CMS intermediate lab:
Cisco Meeting Server 2.6.1 Intermediate Features Hands-On Lab v1

Cisco Meeting Server v2.8 Single Server Simplified Lab v1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco Meeting Server v2.8 Single Server Simplified Lab v1

Uploaded by

Copyright:

Available Formats

Lab Guide

Cisco Meeting Server v2.8: Single Server

Created in Partnership with Solutions Readiness Engineers

About This Lab

About This Lab

About This Solution

Scenario 1. Configuring the IP Interface for Admin and A Interface

Scenario 2. Setting a Hostname

Scenario 3. Setting the MMP

Scenario 4. Upgrading Software (If Necessary)

Scenario 5. Obtaining and Assigning a License

Scenario 6. Configuring the Network Time Protocol (NTP) Server

Scenario 7. Generating Certificates for the Meeting Server

Scenario 8. Enabling Call Bridge Service

Scenario 9. Enabling the Web Admin Service

Scenario 10. Configuring Basic Call Settings

Scenario 11. Configuring Incoming Call Rules

Scenario 12. Configuring Outgoing Call Rules

Scenario 13. Creating a Test Space

Scenario 15. Enabling the Web Bridge

Scenario 16. Configuring the User Import Feature

Scenario 17. Cisco Meeting Management

There are no limitations associated with this lab.

Laptop Router, registered and configured for Cisco dCloud®

The following requirements have already been configured:

• SIP Domain for Meeting Server

About This Solution

Description Version IP Address Username Password

Cisco Unified Communications 12.5 198.18.133.3 administrator dCloud123!

Cisco Unity Connection Server 12.5 198.18.133.5 administrator dCloud123!

Cisco Unified IM and Presence 12.5 198.18.133.4 administrator dCloud123!

Cisco Meeting Manager 2.8 198.18.135.77 administrator C1sco12345

Cisco Meeting Server 2.8 198.18.1.42 admin dCloud123!

Microsoft Active Directory 2012 198.18.133.1 administrator C1sco12345

Microsoft Exchange 2016 198.18.135.52 administrator C1sco12345

Cisco TelePresence Management 15.9 198.18.133.158 administrator C1sco12345

Cisco TelePresence Management 5.9 198.18.135.36 administrator C1sco12345

Cisco TelePresence Video 12.5.6 198.18.1.5 admin dCloud123!

Cisco TelePresence Video 12.5.6 198.18.133.152 admin dCloud123!

VMWare vCenter 6.7 198.18.1.40 administrator@vsphere.local C1sco12345!

Workstation1 Windows 10 Pro 198.18.1.36 DCLOUD\amckenzie dCloud12345!

Workstation2 Windows 10 Pro 198.18.1.37 DCLOUD\aperez dCloud12345!

User Name User ID Password Endpoint Devices Phone Email or Extension

Adam McKenzie amakenzie dCloud12345! N/A N/A Cisco Jabber

Anita Perez aperez dCloud12345! N/A N/A Cisco Jabber

1. Initiate your dCloud session. [Show Me How]

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

• Workstation 1: 198.18.1.36, Username: amckenzie, Password: dCloud12345!

Scenario 1. Configuring the IP Interface for Admin and A Interface

1. RDP to Workstation 1 (198.18.1.36), log in with the following credentials:

NOTE: Ignore any certificate warning.

3. Log into the VMware vCenter with these credentials:

5. In the center-left window panel, expand dCloud_Datacenter > 198.18.1.41

b. Click the Power On green arrow on the toolbar.

c. Click Launch Web Console.

a. User Name: admin

a. Set the interface to: 1GE

b. Set the full duplex to: iface a 1000 full

4. Use the iface a command to confirm your changes.

a. Type: ipv4 a add 198.18.1.42/16 198.18.1.1

6. From the desktop, open PuTTy [ ].

8. Return to the Meeting server interface (CMS).

9. Log on to the Meeting Server with these credentials: