Les 1000 Verites Scientifiques Du Coran 1

Cisco dCloud
Cisco Preferred Architecture for Enterprise Collaboration 11.6

Lab v1 dCloud: The Cisco Demo Cloud
Last Updated: 01-SEPTEMBER-2017
About This Demonstration

This preconfigured demonstration includes:
 Requirements
 About This Solution
 Topology
 Session Users
 Get Started
 Scenario 1: Certificate Management
 Scenario 2: Call Control
 Scenario 3: Conferencing
 Scenario 4: Collaboration Edge
 Scenario 5: Bandwidth Management
 Scenario 6: Security
 Appendix A: UC CA Certificate Installation
 Appendix B: Adding Client Server Template to Certificate Services
 Appendix C: Unified CM and Unity Connection Licensing with Prime License Manager
 Appendix D: Common Phone Profile Configuration
 Appendix E: Collaboration Edge Pre-Configuration
 Appendix F: Installing a Unified Communications Application on an ESXi Host
Requirements
The table below outlines the requirements for this preconfigured demonstration.
Table 1. Requirements
Required Optional
 Router, registered and configured for Cisco dCloud (required for physical endpoints)  None
 Laptop
 Any Cisco video endpoint that can be registered to Unified CM: See Note below.
© 2017 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 187
Cisco dCloud
NOTE: Although any video endpoint capable of registering to Unified CM will work in this lab, the Preferred Architecture for
Enterprise Collaboration CVD lists preferred endpoints for optimal features, functionality, and user experience. Scroll to the
Collaboration Endpoints section of the CVD Introduction section linked above. dCloud: The Cisco Demo Cloud
About This Solution

In recent years, many new collaboration tools have been introduced to the market, enabling businesses to enhance
communications and extend collaboration outside the walls of their business. Organizations realize the benefits collaboration
applications bring to their businesses through increased employee productivity and enhanced customer relationships. Significant
advances in the collaboration space simplify deployment, improve interoperability, and enhance the overall user experience.
Today's collaboration solutions offer organizations the ability to integrate video, audio, and web participants into a single, unified
meeting experience. The guidelines within the Preferred Architecture for Enterprise Collaboration Cisco Validated Design (CVD)
guide are written with the overall collaboration architecture in mind. Subsystems are used for better organization of the content,
and the recommendations within them are tested to ensure they align with recommendations in related subsystems. This lab is
based on the Cisco Preferred Architecture for Enterprise Collaboration CVD.
The CVD for the Enterprise Collaboration Preferred Architecture incorporates a subset of products from the total Cisco
Collaboration portfolio that is best suited for the enterprise market segment. This Preferred Architecture deployment model is
prescriptive, out-of-the-box, and built to scale with an organization as its business needs change. This prescriptive approach
simplifies the integration of multiple system-level components while also enabling an organization to choose the features, services,
and capacities that best address its business needs.
The Enterprise Collaboration Preferred Architecture provides end-to-end collaboration targeted for deployments larger than 1,000
users. For smaller deployments, consult the Preferred Architecture Design Overview and CVDs for Midmarket Collaboration.
The CVD for Enterprise Collaboration Preferred Architecture provides high availability for critical applications. The architecture
supports an advanced set of collaboration services that extend to mobile workers, partners, and customers through the following
key services:
 Voice communications
 Instant messaging and presence
 High definition video and content sharing
 Rich media conferencing
 Enablement of mobile and remote workers
 Business-to-business voice and video communications
 Unified voice messaging
Because of the adaptable nature of Cisco endpoints and their support for IP networks, this architecture enables an organization to
use its current data network to support both voice and video calls. In general, it is a best practice to deploy a collaboration solution
with proper Quality of Service (QoS) configured throughout the network. Voice and video IP traffic is classified and prioritized to
preserve the user experience and avoid negative effects such as delay, loss, and jitter. For more information about LAN and WAN
QoS, see the Cisco Collaboration Solution Reference Network Designs (SRND).
Cisco dCloud
This Cisco Preferred Architecture Enterprise Training lab includes:
 Scenario 1: Certificate Management
o Generate certificate signing request (CSR) for tomcat dCloud: The Cisco Demo Cloud
o Generate a CallManager CSR
o Downloading the tomcat and Call Manager CSR
o Issue and sign tomcat certificate using Enterprise Microsoft Certificate Authority (CA) (ad.1dcloud.cisco.com)
o Download the Enterprise CA Certificate

o Upload Enterprise CA and signed tomcat and CallManager certificates to Unified CM
o Review Certificates on Subscriber, IM&P, and Unity Connection
o Manage Cisco Meeting Server Certificates for Secure Service Interfaces
o Review Enterprise CA signed server certificate on Expressway-E Server

o Review Enterprise CA signed server certificate on Expressway-C Server
 Scenario 2: Configuration of Call Control:
o Node Name
o Dial Plan
o Classes of Services and Calling Search Spaces
o Calling Party Information Display on Phones
o Lightweight Directory Access Protocol (LDAP) Provisioning
o Endpoint Provisioning
o Intercluster Lookup Service (ILS) Configuration for Multi-Cluster Deployments
o User Data Service (UDS) Certificate Configuration for ILS
o Global Dial Plan Replication (GDPR) Configuration
 Scenario 3: Configuration of Conferencing:
o Configure SIP Profile
o Configure SIP Trunks

o Configure Media Resources for CMS Bridge
o Create a Media Resource Group List
o Enabling Clustering and Redundancy
o Create Call Bridge Cluster
o Configure Outbound rule for CallBridge
o Configure TMS for Scheduled Conferences
 Scenario 4: Configuration of Collaboration Edge:
o Mobile and Remote Access (MRA)
o Business-to-Business Communications (B2B)
o Cisco Unified Border Element (CUBE)
Cisco dCloud
 Scenario 5: Configuration of Bandwidth Management:

dCloud: The Cisco Demo Cloud
o Endpoint QoS
o Application Server QoS
o WAN QoS
 Identification and Classification
 Queuing and Scheduling
o Enhanced Locations Call Admission Control (CAC)
 Device Mobility for Mobile and Remote Access (MRA)
 Scenario 6: Security
o Unified CM / Endpoints (Call Control)
 LDAP Encryption configuration (LDAPS) for directory sync and authentication
o CAPF enroll Hardware Endpoints
o Move Unified CM Cluster to Mixed-Mode via CLI (soft e-token) Method
o Unified CM CAPF Enrollment for Jabber
o Create Secure Phone Security Profile and Apply to On-Premise Endpoints
o Confirm Secure Calling (Phone to Phone, Jabber to Phone)
o Cisco Meeting Server Secure Integration
o Secure Unified CM Integration with Unity Connection Next Generation Encryption
Cisco dCloud
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 script steps where relevant and in the server details table.
Topology Overview
Table 2. Server Information
Name Description Host Name (FQDN) IP Address Username Password
TMS TelePresence Management Suite 15.4 198.18.133.158 administrator C1sco12345

tms1.dcloud.cisco.com
Unified CM Pub (US) Communications Manager 11.5(1)(SU2) (Call Control) ucm-pub.dcloud.cisco.com 198.18.133.3 administrator dCloud123!
Unified CM Sub (US) Communications Manager 11.5(1)(SU2) (Call Control) ucm-sub1.dcloud.cisco.com 198.18.133.219 administrator dCloud123!
IM & P IM & Presence 11.5(1)(SU2) (Presence and Chat) imp-pub.dcloud.cisco.com 198.18.133.4 administrator dCloud123!
UC Unity Connection 11.5(1)(SU2) (Voicemail) cuc1.dcloud.cisco.com 198.18.133.5 administrator dCloud123!
Unified CM Pub (EMEA) Communications Manager 11.5(1)(SU2) (Call Control) ucm1-pub.dcloud.cisco.com 198.18.1.13 administrator dCloud123!
CMS1 Cisco Meeting Server 2.1.7 cms1.dcloud.cisco.com admin dCloud123!

198.18.134.185
CMS2 Cisco Meeting Server 2.1.7 cms2.dcloud.cisco.com 198.18.134.147 admin dCloud123!
Exp-C Expressway-C (Core) X8.9(2) exp-c-1.dcloud.cisco.com admin dCloud123!

198.18.133.152
Exp-E Expressway-E (Edge) X8.9(2) exp-e-1.dcloud.cisco.com 198.18.1.152 admin dCloud123!
US-CUBE CSR1000V us-cube.dcloud.cisco.com 198.18.133.226 admin C1sco12345
PSTN CSR1000V 198.18.133.227 admin C1sco12345

pstn.dcloud.cisco.com
AD1 Internal AD and DNS server ad1.dcloud.cisco.com 198.18.133.1 administrator C1sco12345
AD2 Mock External DNS server ad2.dcloud.cisco.com 198.18.2.11 administrator C1sco12345
Exchange Exchange 2010 mail1.dcloud.cisco.com 198.18.133.2 administrator C1sco12345
Workstation 1 Windows 7 wkst1.dcloud.cisco.com 198.18.133.36 amckenzie C1sco12345
Workstation 2 Windows 7 wkst2.dcloud.cisco.com 198.18.133.37 cholland C1sco12345
Cisco dCloud
Session Users
This content includes preconfigured users and components to illustrate the features of the solution. Most components are fully
configurable with predefined administrative user accounts. You can see the IP address and account credentials to use to access a
component by clicking the component icon in the Topology menu of your session and in the scenarios that require their use.
Table 3. Demonstration User Information To Be Configured
User Name User ID Password Endpoint Devices Site Phone Self-Service User ID
Adam McKenzie amckenzie C1sco12345 Any Demonstration Endpoint RCD +1 972 555 5016 19725555016
Charles Holland cholland C1sco12345 Any Demonstration Endpoint RCD +1 972 555 5018 19725555018
Anita Perez aperez C1sco12345 Any Demonstration Endpoint RCD +1 972 555 5017 19725555017
Kellie Melby kmelby C1sco12345 Any Demonstration Endpoint RCD +1 972 555 5050 19725555050
Lucy Abbot labbot C1sco12345 Any Demonstration Endpoint SJC +1 408 555 4006 14085554006
Jim Li jli C1sco12345 Any Demonstration Endpoint SJC +1 408 555 4019 14085554019
Mukul Kumar mkumar C1sco12345 Any Demonstration Endpoint SJC +1 408 555 4021 14085554021
Monica Cheng mcheng C1sco12345 Any Demonstration Endpoint SJC +1 408 555 4030 14085554030
Alice Roberts aroberts C1sco12345 Any Demonstration Endpoint RTP +1 919 555 1055 19195551055
Kathryn Seo kseo C1sco12345 Any Demonstration Endpoint RTP +1 919 555 1020 19195551020
Neela Patel npatel C1sco12345 Any Demonstration Endpoint RTP +1 919 555 1023 19195551023
Taylor Bard tbard C1sco12345 Any Demonstration Endpoint RTP +1 919 555 1026 19195551026
Get Started
BEFORE DEMONSTRATING
We strongly recommend that you go through this process at least once, before presenting in front of a live audience. This will
allow you to become familiar with the structure of the document and the demonstration.
PREPARATION IS KEY TO A SUCCESSFUL CUSTOMER PRESENTATION.
Follow the steps below to schedule your demonstration and configure your demonstration environment.
1. Initiate your dCloud session. [Show Me How]
NOTE: It may take up to 45 minutes for your session to become active.
2. If you are connected to the demo from behind a router, please continue to the next step. If you are connecting directly to the
session from a stand-alone laptop or other device, install and access Cisco AnyConnect on your laptop, using the
AnyConnect credentials in the Cisco dCloud UI. [Show Me How]
3. 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]
Cisco dCloud
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. However, many users experience
connection and performance issues with this method. dCloud: The Cisco Demo Cloud
 Workstation 1 – IP Address: 198.18.133.36, Username: dcloud\amckenzie, Password: C1sco12345
Cisco dCloud
Scenario 1: Certificate Management

 Generate certificate signing request (CSR) for tomcat
 Generate a CallManager CSR
 Downloading the tomcat and Call Manager CSR
 Issue and sign tomcat certificate using Enterprise Microsoft Certificate Authority (CA) (ad.1dcloud.cisco.com)
 Download the Enterprise CA Certificate
 Upload Enterprise CA and signed tomcat and CallManager certificates to Unified CM
 Review Certificates on Subscriber, IM&P, and Unity Connection
 Manage Cisco Meeting Server Certificates for Secure Service Interfaces
 Review Enterprise CA signed server certificate on Expressway-E Server
 Review Enterprise CA signed server certificate on Expressway-C Server
In this section, you will generate different certificates. Some of them are preconfigured for you. Certificates are critical in a Cisco
Collaboration deployment. They allow individuals, computers, and other services on the network to authenticate and are required
when establishing secure connections. Implementing good certificate management provides a good level of protection while
reducing complexity.
Generate Multi-server (SAN) certificate signing request (CSR) for tomcat in Call Manager
1. On Workstation 1, open Firefox, and browse to Cisco Unified CM Publisher at https://198.18.133.3/cmplatform. Log in as
administrator with password: dCloud123!.
2. Choose Security > Certificate Management. Perform a new certificate search for certificates that ‘begins with’ tomcat. As
shown below, the tomcat certificate per best practice recommendations is signed by the enterprise CA (dCloud-AD1-CA).
Unified CM tomcat / tomcat-trust self-signed certificates
Because we have multiple nodes in our Unified CM cluster, we will generate and sign multi-server SAN
certificates for use by all our cluster nodes.
3. Click Generate CSR. In the next window, ensure tomcat is selected in the “Certificate Purpose” drop down menu (default
value). To generate a multi-server SAN CSR for tomcat, choose Multi-server(SAN) from the “Distribution” drop down. Notice
that when you choose multi-server, the common name changes to ucm-pub-ms.dcloud.cisco.com and both the Unified CM
nodes (ucm-pub.dcloud.cisco.com and ucm-sub1.dcloud.cisco.com) and the Unified CM IM & P node (imp-
pub.dcloud.cisco.com) FQDNs are added as SANs to the CSR.
Cisco dCloud
4. Leave all other values as the defaults, including length and hash algorithms, set to 2048 and SHA256 respectively, and then
click Generate.
Unified CM: Generate a tomcat Multi Server Certificate Signing Request dCloud: The Cisco Demo Cloud
Cisco dCloud
5. Once the CSR is created, click Close. You should now see the tomcat CSR you just generated, when the certificate list
reloads.
Unified CM: tomcat CSR dCloud: The Cisco Demo Cloud
NOTE: You may need to click Find to reload the certificate list.
Multi-server SAN certificates streamline the certificate signing process. With multi-server certificates, multiple nodes within the
same cluster will use the same CA signed certificate, reducing the number of certificates to be signed and distributed. In this lab, a
single multi-SAN CA-signed tomcat certificate (ucm-pub-ms.dcloud.cisco.com) is used across the three Unified CM / IM &
Presence cluster nodes: Unified CM Publisher/Subscriber/TFTP (ucm-pub.dcloud.cisco.com), Unified CM Subscriber/TFTP
(ucm-sub1.dcloud.cisco.com), and Unified CM IM & Presence Publisher/Subscriber (imp-pub.dcloud.cisco.com). These three
nodes share the multi-server tomcat certificate.
Table 4 below shows the Enterprise Collaboration PA recommendation regarding CA-signed multi-server SAN certificates for
collaboration application nodes.
Table 4. Recommended CA-Signed Multi-Server SAN Certificates
Product Certificate Notes
Unified CM and Unified CM IM &

tomcat Shared certificate across all Unified CM and Unified CM IM & P cluster nodes
Presence
Unified CM CallManager Shared certificate across all Unified CM nodes running CallManager service
Unified CM IM and Presence cup-xmpp Shared certificate across all Unified CM IM & P cluster nodes
Unified CM IM and Presence cup-xmpp-s2s Shared certificate across all Unified CM IM & P cluster nodes
Unity Connection tomcat Shared certificate across both Unity Connection cluster nodes
NOTE: Once the multi-server SAN certificate CSR is generated and the signed multi-server SAN certificate is uploaded to the
relevant publisher node, if additional nodes are added to the cluster in the future, the multi-server SAN certificate must be
regenerated (new multi-server SAN CSR, new signed multi-server SAN certificate).
Cisco dCloud
Generate a CallManager CSR
1. On the Certificate List page at Security > Certificate Management, search for certificates that ‘begins with’ CallManager.
Unified CM CallManager / CallManager-trust self-signed certificates
Cisco dCloud
Notice that the CallManager certificate is self-signed. As indicated previously, signing the CallManager certificate with a public or
private CA is a best practice, so you want this certificate signed by the enterprise CA.
In this lab, a single multi-SAN CA-signed CallManager certificate (ucm-pub-ms.dcloud.cisco.com) is used across
dCloud: Thethe two
Cisco Unified
Demo Cloud
CM cluster nodes: Unified CM Publisher/Subscriber/TFTP (ucm-pub.dcloud.cisco.com) and Unified CM Subscriber/TFTP (ucm-

sub1.dcloud.cisco.com). These two nodes share the multi-server CallManager certificate
2. Click Generate CSR. This time, choose CallManager in the “Certificate Purpose” drop down.
3. To generate a multi-server SAN CSR for CallManager, choose Multi-server(SAN) from the “Distribution” drop down. Notice
that when you choose multi-server, the common name changes to ucm-pub-ms.dcloud.cisco.com and both the Unified CM
nodes (ucm-pub.dcloud.cisco.com and ucm-sub1.dcloud.cisco.com) and the Unified CM IM & P node (imp-
pub.dcloud.cisco.com) FQDNs are added as SANs to the CSR.
4. Leave all other values as the defaults ensuring that the key length and hash algorithms are set to 2048 and SHA256.
Generate CallManager Multi Server CSR
Cisco dCloud
5. Click Generate. Once the CSR is created, click Close. The certificate list reloads and you will see the CallManager CSR you
just generated.
CallManager CSR dCloud: The Cisco Demo Cloud
NOTE: You may need to click Find to reload the certificate list.
Downloading the tomcat CSR
1. Click Download CSR and in the Download Certificate Signing Request window, ensure tomcat is selected in the “Certificate
Purpose” drop down.
Download tomcat CSR
Cisco dCloud
2. Click Download CSR in the Download Certificate Signing Request window. In the Open with / Save File dialog, choose ‘Open
with’, click Browse, and then choose Windows Wordpad Application (or Notepad) and click OK.
Downloading and Opening the tomcat CSR dCloud: The Cisco Demo Cloud
Cisco dCloud
3. Click OK, to open the CSR with Wordpad (or Notepad). Once the file opens, select the contents of the file and copy to the
clipboard (Ctrl-C).
Copying the CSR Text dCloud: The Cisco Demo Cloud
NOTE: The certificate request string shown above may be different in your CSR.
4. Close the Download CSR window before proceeding.
Issue and sign tomcat certificate using Enterprise Microsoft Certificate Authority (CA) (ad1.dcloud.cisco.com)
1. Using the Firefox web browser on Workstation 1 (198.18.133.36), navigate to http://ad1.dcloud.cisco.com/certsrv, or open a
new tab and choose dCloud Certificates > AD1 Certificate Services. Log in administrator with password: C1sco12345
when prompted to authenticate.
Cisco dCloud
2. Click on Request a certificate.
Request a Signed Certificate from the Enterprise CA

3. On the next screen, choose ‘Or, submit an advanced certificate request’.
Enterprise CA Advanced Certificate Request
Cisco dCloud
4. Paste (Ctrl-V) the contents of the clipboard (copied from the CSR in the previous step) to the Base-64-encoded certificate
request field. Choose the ClientServer Certificate Template and click on Submit > as shown below.
Submit Certificate Request dCloud: The Cisco Demo Cloud
NOTE: The certificate request string shown above may be different in your CSR.
Cisco dCloud
5. On the next screen, choose DER encoded (default) or Base 64 encoded and then Download Certificate.
Save the Signed tomcat Certificate

6. Click Save File and click Ok. Go to Downloads folder and rename certificate certnew to tomcat-ms
NOTE: Repeat the steps above (beginning with “Download tomcat CSR” sub-section, page 14) to download the CallManager CSR,
return to http://ad1.dcloud.cisco.com/certsrv/ to sign the CSR, and save the certificate as CallManager-ms.cer
7. Close the Download CSR window and the Wordpad application windows on Workstation 1 before proceeding.
Cisco dCloud
Download the Enterprise CA Certificate
1. Before leaving the Enterprise Certificate Authority, return to http://ad1.dcloud.cisco.com/certsrv/. You can navigate there by
clicking the “Home” link in the upper right-hand corner. Choose Download a CA certificate, certificate chain, or CRL.
Download the Enterprise CA Certificate (1 of 2)
2. On the next screen, ‘Current [dcloud-AD1-CA]’ is selected by default and the encoding method is set to DER by default. Click
Download CA Certificate.
Download the Enterprise CA Certificate (2 of 2)
3. Click Save File and click Ok. Go to Downloads folder and rename certificate certnew to dCloud_CA_DER
Cisco dCloud
Upload Enterprise CA and signed tomcat and CallManager certificates to Unified CM
Now that the tomcat and CallManager certificates have been issued and signed, these certificates along with the CA certificate
must be uploaded to Unified CM.
1. Return to the Unified CM Operating System administrative interface (https://ucm-pub.dcloud.cisco.com/cmplatform/) and log in
(if required) as administrator with password: dCloud123!.
2. Choose Security > Certificate Management and then click Upload Certificate/Certificate chain.
Upload CA Certificate, CA -signed tomcat, and CA-signed CallManager Certificates
3. Start by uploading the Enterprise CA certificate to trust stores: tomcat-trust and CallManager-trust. Choose tomcat-trust from
the Certificate Purpose dropdown and enter “dCloud-AD1-CA” for the Description field.
4. Next, browse and choose the DER encoded certificate you saved previously: dCloud_CA_DER.cer (located at
C:\Users\amckenzie\Downloads).
5. Click Open. Click Upload.
Upload the CA Certificate to tomcat-trust
Cisco dCloud
NOTE: A message indicating the Cisco Tomcat service needs to be restarted will be displayed. In order to save time, you should
wait to restart the Cisco Tomcat service as well as CallManager and TFTP services until the end of this section.
6. Once the CA certificate is uploaded to the tomcat-trust store successfully, repeat the above steps and dCloud:
uploadThe
theCisco
CA Demo Cloud
certificate to the CallManager-trust store by choosing CallManager-trust from the Certificate Purpose drop down.
7. Upload the CA-signed tomcat and CallManager certificates. This time, choose tomcat from the “Certificate Purpose” drop
down. Then click Browse and choose the certificate saved previously – tomcat-ms.cer (located at
C:\Users\amckenzie\Downloads). Click Open. Click Upload.
Upload the CA-Signed tomcat Certificate
NOTE: Wait to restart the Cisco Tomcat, Cisco CallManager, and Cisco TFTP services until the end of this section.
The message in the upload window (“Certificate upload operation successful for the nodes ucm-pub.dcloud.cisco.com,ucm-
sub1.dcloud.cisco.com,imp-pub.dcloud.cisco.com”), states the multi-server tomcat certificate is automatically pushed from the
cluster publisher node to all other applicable cluster nodes. Once the signed tomcat multi-server certificate is uploaded to the
publisher node (ucm-pub.dcloud.cisco.com) it is automatically uploaded to the subscriber node (ucm-sub1.dcloud.cisco.com) and
theUnified CM IM & P node (imp.dcloud.cisco.com), which were added as SANs when you generated the multi-server SAN CSR. If
there were additional Unified CM or Unified CM IM & P nodes in the cluster running the tomcat service, these nodes would also
automatically upload the tomcat multi-server certificate. These other cluster nodes would have been auto-populated in the SAN
window when generating the CSR.
8. Repeat the above process to upload the CallManager certificate. Choose CallManager from the Certificate Purpose drop
down and choose CallManager-ms.cer as the upload file.
Cisco dCloud
9. Click Close and then on the Certificate List page at Security > Certificate Management, search for certificates where ‘begins
with’ is blank, then click Find. Note that the CA-signed tomcat and CallManager certificates just signed are listed along with
the enterprise CA certificate in the tomcat-trust and CallManager-trust stores. You can also see that the tomcat-ms certificate
has been automatically uploaded to the tomcat-trust store.
CallManager and tomcat multi-server CA-Signed Certificates and CA Certificate Uploaded to CallManager-trust and tomcat-trust
Before moving to the next section, you need to restart Cisco TFTP, Cisco CallManager, and Cisco Tomcat services since you
uploaded new CA-signed certificates and the enterprise CA certificate.
10. Browse to the Unified CM Serviceability portal at https://ucm-pub.dcloud.cisco.com/ccmservice/ and log in as administrator
with password: dCloud123!.
11. Navigate to Tools > Control Center – Feature Services, choose the ucm-pub.dcloud.cisco.com – CUCM Voice/Video
server from the drop down, and click Go. On the next screen, click the Cisco TFTP radio button and click Restart. Click OK to
confirm restart. After the TFTP service restarts and you see the message “Cisco Tftp Service Restart Operation was
Successful”, click the Cisco CallManager radio button and click Restart again. Click OK to confirm restart.
12. Repeat the same steps for ucm-sub1.dcloud.cisco.com. Navigate to Tools > Control Center – Feature Services, choose
the ucm-sub1.dcloud.cisco.com – CUCM Voice/Video server from the drop down, and click Go. On the next screen, click
the Cisco TFTP radio button and click Restart. Click OK to confirm restart. After the TFTP service restarts and you see the
message “Cisco Tftp Service Restart Operation was Successful”, click the Cisco CallManager radio button and click Restart
again. Click OK to confirm restart.
Cisco dCloud
13. Finally, to restart the Cisco Tomcat service on Unified CM, SSH to our Unified CM publisher (ucm-pub.dcloud.cisco.com)

command line interface by using PuTTY on Workstation 1 (198.18.133.36). Double-click the Putty icon to launch.
Enter ucm-pub.dcloud.cisco.com in the “Host Name (or IP Address)” field. Click Open.
14. Click Yes to cache the ssh-rsa2 key.
Key Cache Confirmation for SSH to Unified CM
15. Log in as administrator with password: dCloud123!. Enter the command utils service restart Cisco Tomcat at the
command line. The Cisco Tomcat service will restart. Once the service has started again, type exit to close the SSH session.
Restarting the Cisco Tomcat Service on Unified CM
Cisco dCloud
16. Restart the Cisco Tomcat service on the other cluster nodes. Repeat steps 13-15 above to restart the Cisco Tomcat service
on the Unified CM subscriber (ucm-sub1.dcloud.cisco.com). Do the same for the Unified CM IM & P publisher node (imp-
pub.dcloud.cisco.com
NOTE: It can take up to 15 minutes for all server node web interfaces to return to service after a Cisco Tomcat restart. Be patient.
Examine the existing certificates on Unified CM Subscriber cluster node (ucm-sub1.dcloud.cisco.com)
1. Using Firefox on Workstation 1 (198.18.133.36), open a new tab and go to the Unified IM and Presence Operating System
administrative interface: https://ucm-sub1.dcloud.cisco.com/cmplatform. Log in as administrator with password: dCloud123!.
2. Choose Security > Certificate Management and then click Find.
Unified CM Subscriber Certificate List
The collaboration application security best practice from the Enterprise Collaboration PA is to install certificate authority (CA)
signed certificates on the system rather than relying on the default self-signed certificates.
The tomcat multi-server certificate signed by the enterprise CA previously has automatically uploaded.
As mentioned previously, multi-server SAN certificates simplify certificate management. In this case, both the Unified CM nodes
(ucm-pub.dcloud.cisco.com and ucm-sub1.dcloud.cisco.com) are using the same CA signed CallManager certificate. Likewise,
both the Unified CM nodes and the Unified CM IM & Presence node (imp-pub.dcloud.cisco.com) are using the same CA signed
tomcat certificate.
Cisco dCloud
Examine the existing certificates on Unified CM IM & P cluster node (imp.dcloud.cisco.com)
administrative interface: https://imp-pub.dcloud.cisco.com/cmplatform. Log in as administrator with password: dCloud123!.
2. Click Security > Certificate Management and then click Find.
The Figure below shows the Unified CM OS Certificate Management interface and a list of the system certificates.
Unified CM IM & P Certificate List
The Cisco Unified CM IM and Presence security best practice from the Enterprise Collaboration PA is to install certificate authority
(CA) signed certificates on the system rather than relying on the default self-signed certificates. A public CA or private enterprise
CA should sign the following certificates:
 tomcat
 cup-xmpp
 cup-xmpp-s2s
The tomcat multi-server certificate previously signed has automatically uploaded. Further, the cup-xmpp certificates have already
been signed for you with the enterprise CA and the enterprise CA certificate (dCloud-AD1-CA) has already been uploaded to the
cup-xmpp and tomcat trust stores.
Multi-server SAN certificates simplify certificate management. The Unified CM nodes and the Unified CM IM & Presence node are
using the same CA signed certificate for tomcat connections.
Cisco dCloud
Examine the existing certificates on Unity Connection cluster node (cuc1.dcloud.cisco.com)
administrative interface: https://cuc1.dcloud.cisco.com/cmplatform. Log in as administrator with password: dCloud123!.
2. Click Security > Certificate Management and then click Find.
Shows the Cisco Unified OS Certificate Management interface and a list of the system certificates.
The tomcat certificate has already been signed for you with the enterprise CA and the enterprise CA certificate (dCloud-AD1-CA)
has been uploaded to the tomcat-trust stores
Manage Cisco Meeting Server Certificates for Secure Service Interfaces
In this task, you generate a server certificate signing request (CSR) at the Cisco Meeting Server command line interface and then
sign with the enterprise CA. Then you download the signed server certificate. This certificate is used to secure both the web
administration (webadmin) interface as well as the call bridge service (callbridge), which handles conferencing capabilities.
Generate Server CSR on Cisco Meeting Server
1. RDP to Workstation 1 (198.18.133.36) as DCLOUD\amckenzie with password: C1sco12345.
2. Double-click the Putty icon to SSH to Cisco Meeting Server (cms2.dcloud.cisco.com) and access the command line
interface of the Cisco Meeting Sever. Enter cms2.dcloud.cisco.com in the “Host Name (or IP Address)” field. Click Open.
3. Click Yes to cache the host key.
SSH Key Cache Warning
Cisco dCloud
4. Log in to the command line as username admin with password: dCloud123!. Once logged in, at the command prompt, enter
pki csr webadmin CN:cms2.dcloud.cisco.com to generate a server CSR.
Cisco Meeting Server: Generating a Certificate Signing Request (CSR) dCloud: The Cisco Demo Cloud
Open the Cisco Meeting Server CSR
5. Click the WinSCP client in the taskbar on Workstation 1
Launching WinSCP for Cisco Meeting Server File Access
6. Open an SFTP session to cms2.dcloud.cisco.com with username admin and password dCloud123!. Click Login.
WinSCP: Start SFTP Session to Cisco Meeting Server
Cisco dCloud
7. Click Yes to cache the Cisco Meeting Server host key and complete the login.
WinSCP: Caching the Cisco Meeting Server Hostkey

8. Once connected, you should see the newly generated CSR file (webadmin.csr) on the right-hand file list window. Right click
the webadmin.csr file and click Edit > Edit to view the CSR.
Viewing Server Certificate Signing Request (CSR) – webadmin.csr
Cisco dCloud
9. When the CSR opens in the text editor, copy the text and use it to request the signed certificate in the next step.
Copying Cisco Meeting Server webadmin CSR

Issue and sign Cisco Meeting Server certificate using Enterprise Microsoft Certificate Authority (CA)
(ad1.dcloud.cisco.com)
1. Navigate to the enterprise CA at http://ad1.dcloud.cisco.com/certsrv. Log in as administrator with password: C1sco12345.

Once logged in, click the Request a certificate link. On the next screen, click the ‘Or, submit an advanced certificate
request‘ link.
Request a Signed Certificate from the Enterprise CA
Cisco dCloud
2. Paste the CSR text from webadmin.csr to the Saved Request window. Choose ClientServer from the ‘Certificate Template’
drop down menu and then click Submit >.
Enterprise CA Certificate Signing: webadmin.cer dCloud: The Cisco Demo Cloud
3. On the next screen, leave encoding set to DER encoded and click the Download certificate. Click Save File and click Ok.
Go to Downloads folder and rename certificate certnew to webadmin
Saving the Newly Signed webadmin.cer
4. Close the webadmin CSR text editor window before proceeding to the next section.
Cisco dCloud
Upload CA and CA-Signed Certificate and Associate to Web Admin and Call Bridge Services
In this task, you will upload the enterprise CA-signed server certificate and CA certificate to Cisco Meeting Server. You will then
associate the certificate to the web administration and call bridge services.
Upload CA-Signed Server Certificate and Enterprise CA Certificate
1. Return to the WinSCP client on Workstation 1. If required, log in to cms2.dcloud.cisco.com as admin with password:
dCloud123!.
2. In the left-hand window, navigate to C:\Users\amckenzie\Downloads by double-clicking . Then click Downloads.
3. Copy the recently downloaded CA-signed certificate and the CA certificate to the Cisco Meeting Server file system by dragging
and dropping webadmin.cer (CA-signed certificate) and dCloud_CA_DER.cer (CA certificate) to the right-hand side of the
window.
Copying CA-Signed Certificate and CA Certificate to Cisco Meeting Server File System
4. You should now see the webadmin.cer and dCloud-AD1-CA.cer certificates in the right-hand window.
5. Disconnect the SFTP session and close the WinSCP client before proceeding to the next step by clicking Session >
Disconnect. Then click Close.
Cisco dCloud
Associate Server Certificate to Web Admin and Call Bridge Services
6. Next, enable the Cisco Meeting Server web administration interface with the new enterprise CA-signed certificate. Use the
Putty client on Workstation 1 to SSH to Cisco Meeting Server at cms2.dcloud.cisco.com. Click Yes dCloud:
to cacheThethe ssh-rsa2
Cisco Demo Cloud
key and log in as admin with password: dCloud123!. Once authenticated, associate the new CA-signed certificate
(webadmin.cer) and the CA certificate (dCloud_CA_DER.cer) along with the original key created when we generated the
CSR (webadmin.key) to the Web Administration service with the commands:
webadmin listen a 445
webadmin certs webadmin.key webadmin.cer dCloud_CA_DER.cer
webadmin enable
Cisco Meeting Server CLI: Associating CA-Signed Certificate and CA Certificate to Web Administration Service
7. Verify the certificate has been successfully associated to the Web Administration interface by browsing to the Cisco Meeting
Server administrative web interface https://cms2.dcloud.cisco.com:445/. Click Ok to log in as admin with password:
dCloud123!, and then click Submit. Finally, click Ok acknowledge login is successful.
Logging into Cisco Meeting Sever Web Administration Portal
Cisco dCloud
8. Once login is complete, the System status page is displayed confirming that Cisco Meeting Server now has a web server
certificate. Notice you received no certificate warning from the browser since the web server certificate (webadmin.cer) is
signed by the enterprise CA, which is a trusted CA.
Cisco Meeting Server Web Administration Interface After Log In
9. Return to the Cisco Meeting Server CLI interface (SSH session) to associate the CA-signed certificate to the Call Bridge
service interface. You will use the same Web Administration CA-signed certificate to secure the Call Bridge service. Associate
the Web Administration CA-signed certificate to the Call Bridge service with the commands:
callbridge certs webadmin.key webadmin.cer dCloud_CA_DER.cer
callbridge restart
Cisco Meeting Server CLI: Associating CA-Signed Certificate and CA Certificate to Call Bridge service
Cisco dCloud
Configure the web bridge
1. Enter the following commands at the cms2 command line prompt:

webbridge listen a
webbridge certs webadmin.key webadmin.cer dCloud_CA_DER.cer
webbridge trust dCloud_CA_DER.cer
webbridge enable
NOTE: For webbridge to communicate with callbridge, webbridge must trust the certificate from callbridge.
PuTTY Commands and Success Message
2. Type exit in the SSH window to close the SSH session to cms2.dcloud.cisco.com before proceeding to the next section. This
ends configuration of the certificates on the CMS.
Cisco dCloud
Confirm that signed server certificates are in place on Expressway servers and review the contents.
Before proceeding, confirm that the signed Expressway server certificates are in place and briefly review the certificate content.
1. On Workstation 1, open a new browser tab. From the Cisco dCloud homepage, choose Collaboration Server Links > Cisco
Expressway-C. Log in as admin with password: dCloud123! and go to the Server certificate page at Maintenance >
Security Certificates > Server certificate. Under Server certificate data, you should see that the “currently loaded” certificate
is valid and no expired expiration date is 2 years since the day it was signed. Click on the Show (decoded) button to display
the certificate details.
Figure 41.Trusted Enterprise CA Signed Expressway-C Server Certificate
Cisco dCloud
NOTE: The serial number, validity dates, and keys above may not match the ones in your certificate.
2. View the issuer information (dcloud-AD1-CA) and certificate attributes subject name (CN) of exp-c-1.dcloud.cisco.com,
organization, unit, country, and state. Confirm you see the certificate Subject Alternative Names (SANs): exp-c-
1.dcloud.cisco.com, and UDT-Encrypted-NullString.dcloud.cisco.com, UDT-Encrypted-AuthString.dcloud.cisco.com,
UDT-Encrypted-LSC.dcloud.cisco.com, and UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com.
3. Open a new tab and go to Collaboration Server Links > Cisco Expressway-E. Log in as admin with password:
dCloud123!. Navigate to the Server certificate page at Maintenance > Security Certificates > Server certificate. Under
Server certificate data, click Show (decoded) to review the Enterprise CA-signed Expressway-E server certificate.
Trusted Enterprise CA Signed Expressway-E Server Certificate
Cisco dCloud
NOTE: The serial number, validity dates, and keys above may not match the ones in your certificate.
4. View the issuer information (dcloud-AD1-CA) and certificate attributes subject name (CN) of exp-e-1.dcloud.cisco.com,
organization, unit, country, and state. Confirm you see the certificate SANs: exp-e-1.dcloud.cisco.com and
dcloud.cisco.com.
Note: In the case of the Expressway-E, Cisco’s best practice recommendation is to sign the Expressway-E server
certificate using a commonly trusted third party public CA. For ease of use, we have not followed the best practice
recommendation of signing Expressway-E server certificates using a public CA, and instead we signed the certificate with the
Enterprise CA as we did for the Expressway-C server.
5. Close both Expressway certificate decode windows before proceeding.
6. Return to the Expressway-C browser tab and navigate to the Server certificate page at Maintenance > Security Certificates
> Trusted CA Certificate.
Note that the Enterprise CA certificate has been uploaded to the Expressway-C and Expressway-E trust stores. Figure 43 shows
the enterprise CA certificate (dCloud-AD1-CA) in the Expressway-C trusted CA certificate list.
Enterprise CA Certificate Uploaded to Expressway-C
Cisco dCloud
Scenario 2: Call Control

In this scenario, you configure sections of the Call Control chapter in the PA CVD. Other parts of this chapter of the CVD have
been pre-configured for you to save time. Call control is the core element for any communications deployment. It provides endpoint
registration and call processing. Call control design considerations include the enterprise dial plan, endpoint addressing scheme,
calling party presentation, codec selection, PSTN connectivity, general trunking requirements, and other factors.
Initial Cisco Unified CM Configuration
Immediately after installing the Unified CM cluster, perform the following basic configuration tasks.
 Node Name Configuration
 Enterprise Parameter Settings
 Service Activation
 Service Parameter Settings
These settings have all been configured for you in the lab, however, as an example view the Node Name configuration. Feel free
to look through the other configurations as well.
Node Name Configuration
To allow for correct certificate validation and to ensure that references to Unified CM cluster members can always be resolved
correctly, set the node names under System/Server in the Unified CM administration GUI to fully qualified domain names (FQDNs)
for all cluster members.
1. RDP to Workstation 1 (198.18.133.36), log in as Adam McKenzie (dcloud\amckenzie with password: C1sco12345), and
launch Firefox.
2. From the Cisco dCloud homepage, choose Collaboration Server Links > Cisco Unified CM Publisher (US).
3. Click the Cisco Unified Communications Manager link.
4. Log in with Username: administrator and password: dCloud123!.
5. Navigate to System > Server and click Find.
Notice in the lab there are three servers in this cluster: two Unified CM servers (Pub and Sub) and one IM & Presence server. All
are showing their FQDN. At first install, they would either have shown their hostname minus the domain name or IP address. You
can change them all from this same page by clicking on each of the links and modifying the Fully Qualified Domain Name/IP
Address* box. Since this is completed for you already, there is no configuration you need to make.
Dial Plan Configuration
A structured, well-designed dial plan is essential to successful deployment of any call control system. The design of an enterprise
dial plan needs to cover these main areas:
 Endpoint addressing
 General numbering plan
 Dialing habits
 Routing
 Classes of service
Cisco dCloud
The recommend dial plan design approach is documented in the Dial Plan chapter of the Cisco Collaboration System 11.x SRND.
Again, some of this has been pre-configured for you. To aid in the help of understanding how the dial plan is configured we will
configure one of the Calling Search Spaces required for the lab. dCloud: The Cisco Demo Cloud
Classes of Service and Calling Search Spaces (CSSs)
A CSS is a list of partitions that defines which partitions, and thus patterns, a calling entity using the CSS can access. In this
document we use a dial plan approach that uses only the line CSS to define class of service. Table 2-17 in the CVD lists the
classes of service considered in this design. The classes of service chosen for this design are only examples. If further classes of
services are required, then these can be defined equivalently. We will configure the RCD International CSS and apply it to the line
of each of the four pre-configured RCD lines.
1. Navigate to Call Routing > Class of Control > Calling Search Space and click Find.
These are all the CSSs that have been pre-configured for the three sites SJC, RCD, and RTP. The International CSS for RCD
needs to be configured to complete the configuration.
2. Click Add New.
3. Enter RCDInternational as the Name.
4. Using the table below, highlight each of the partitions in the Available Partitions box and click the down arrow [ ] to bring
them into the Selected Partitions box.
Table 1. RCDInternational Partitions
Partition Description
DN Holds all +E.164 directory numbers and other local on-net +E.164 destinations (for example, pilot numbers reachable from the PSTN).
All +E.164 patterns are provisioned as urgent patterns.
Directory URI System Partition where all auto-generated URIs are put. This partition does not need to be created. It is listed here for reference to
introduce the partition, which is used again later in this document.
URI Holds manually provisioned URIs.
ESN Holds all Enterprise Specific Numbers (ESNs). This includes ESN directory numbers (for example, for non-DID phones) as well as
dialing normalization translation patterns transforming from abbreviated inter-site dialing of DIDs to +E.164.
onNetRemote Holds all patterns of remote on-net destinations. In environments with multiple Unified CM clusters, this includes all remote number
ranges learned via Global Dial Plan Replication (GDPR).
RCDIntra Site-specific intra-site dialing. For example: RCDIntra. Holds dialing normalization patterns to transform site-specific abbreviated intra-
site dialing to DIDs, or non-DIDs to +E164 or ESN, respectively.
USToE164 Holds dialing normalization translation patterns to transform US specific habitual PSTN dialing (for example, 91- <10 digits>) to
+E.164. To support other countries, and thus other country-specific dialing habits, a country appropriate xxToE164 partition (where
xx represents the country; for example, DEToE164, UKToE164, ITToE164) also needs to be provisioned, which then holds the
dialing normalization translation patterns required to transform the country specific habitual PSTN dialing to +E.164.
USPSTNNational Holds +E.164 route patterns required to provide PSTN access to national destinations in the US. To support other countries, and thus
other country-specific dialing habits, a country appropriate xxPSTNNational partition (where xx represents the country; for example,
DEPSTNNational, UKPSTNNational, ITPSTNNational) also needs to be provisioned, which then holds the +E.164 route patterns
required to provide PSTN access to national destinations of that country.
The reason we differentiate between international PSTN access (see Table 2-13 ) and national PSTN access is that we need to be
able to build differentiated classes of service allowing calls to reach national only, or national and international destinations.
PSTNInternational Holds +E.164 route patterns required to provide PSTN access to international destinations.
B2B_URI Holds SIP route patterns required for business-to-business (B2B) URI dialing through the Internet.
USEmergency Holds route patterns required to provide access to emergency calls using the US specific emergency dialing habits.
Cisco dCloud
NOTE: The order of the partitions listed in the calling search space serves only to break ties when equally good matches occur in
two different partitions.
5. Click Save.
Apply the CSS to the RCD configured lines using Bulk Administration.
6. Navigate to Bulk Administration > Phones > Add/Update Lines > Update Lines.
7. Change the drop-down menu that reads begins with to contains.
8. In the box next to contains, enter 972, click Find, and then click Next.
9. Under the Directory Number Settings section, check the box next to Calling Search Space and choose RCDInternational
from the drop-down list box.
10. Scroll down to the bottom of the page and click the radio button next to Run Immediately. Click Submit.
Calling Party Information Display on Phones
Because all directory numbers are provisioned as +E.164 numbers for calls originating from these +E.164 directory numbers,
calling party information is in +E.164 format automatically. To simplify and provide consistent calling party presentation for all
possible call flows, all calling party information received from outside networks such as the PSTN is normalized to +E.164 as
discussed earlier. When a call is presented to a phone or to an outside network, the calling party information presented for that call
sometimes needs to be transformed. It can be transformed to the format expected by the network in case of the call being sent to a
gateway or to the format expected by the user in case of the call being sent to a phone.
On certain phones, sometimes +E.164 is not the preferred calling party display format, even though keeping this information as
+E.164 simplifies the deployment and is preferred format for enterprise deployments. In that case, the desired format typically
depends on both the calling and called entities. Table 2-37 in the CVD shows an example of the expected calling party display on a
phone in the SJC site for calls from various sources. This is what you will configure now for the SJC site.
1. Navigate to Call Routing > Transformation > Transformation Pattern > Calling Party Transformation Pattern and click
Find.
2. As you can see, some transformations have been pre-configured. You will finish by configuring for SJC site. Click Add New.
3. Use the table below to create two new Calling Party Transformation Patterns (CPTP) for the SJC site. You will need to
configure each one at a time. Click Save after inputting the settings below for the first CPTP. After the creation of the first
CPTP, click Add New to configure the second pattern in the table below and then click Save again.
Table 5. SJC Calling Party Transformation Patterns
Pattern Partition Description Calling Party Transformation Mask
81405XXX SJCPhLocalize SJC phone intra-site 5XXX
\+14085554XXX SJCPhLocalize SJC phone intra-site 4XXX
Now you will assign this CPTP to the SJC device pool to apply it to the phones assigned to it.
4. Navigate to System > Device Pool and then click Find.
5. Click the link for SJCPhoneVideo.
Cisco dCloud
6. In the Device Mobility Related Information change the drop-down menu for Calling Party Transformation CSS to
SJCPhLocalize then click Save.
User Provisioning with LDAP Synchronization
Synchronization of Unified CM with a corporate LDAP directory allows the administrator to provision users easily by mapping
Unified CM data fields to directory attributes. Critical user data maintained in the LDAP store is copied into the appropriate
corresponding fields in the Unified CM database on a scheduled basis. The corporate LDAP directory retains its status as the
central repository. Unified CM has an integrated database for storing user data and a web interface within Unified CM
Administration for creating and managing user accounts and data. When LDAP synchronization is enabled, the local Unified CM
database is still used, and additional local end-user accounts can be created. Management of end-user accounts is then
accomplished through the interface of the LDAP directory and the Unified CM administration GUI.
LDAP System Configuration
There have been some local users pre-configured in the lab. We will look at what is there now.
1. Navigate to User Management > End User and click Find.
Notice there are 12 users configured in the lab already, four users per site (SJC, RCD, and RTP). In the User Status column, each
user should have the description of Enabled Local User. Once you are finished with the LDAP configuration this user status will
change. You will come back and verify this change later. For now, you will configure LDAP.
Before defining the actual synchronization agreements, confirm the LDAP system has been enabled.
2. Navigate to System > LDAP > LDAP System.
3. Verify the box next to Enable Synchronizing from LDAP Server is checked. This is not checked on a default install.
LDAP Custom Filter
If a Unified CM based directory search is used on phones, then it makes sense to synchronize the full corporate LDAP directory to
Unified CM. In that case, we need the ability to differentiate between users who actually use UC services of the local cluster and
users who are synchronized only to reflect the complete corporate LDAP directory on Unified CM.
To achieve this goal, custom LDAP filters can be used to define two groups of users: local and remote. Remote here means that
these users do not use any UC services on the local Unified CM cluster. For the lab, you will configure a filter for the US local
cluster. The remote filter for the EMEAR cluster has been pre-configured for you.
1. Navigate to System > LDAP > LDAP Custom Filter and click Find. You will see that the Remote LDAP filter is already
configured. We will create the Local LDAP filter.
2. Click Add New.
3. Use the table below to configure the Local LDAP filter. Be sure to enter the filter exactly as it is shown below.
Table 6. Local LDAP Filter
Filter Name Filter
Local (&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))(telephoneNumber=+1*))
4. Click Save and then OK.
Cisco dCloud
Both LDAP filters are extensions of the default LDAP filter for Microsoft Active Directory. Default LDAP filters for other directory
types can be found in the chapter on Directory Integration and Identity Management in the Cisco Collaboration System 11.x SRND
and in the Unified CM online help for the LDAP directory settings.
The LDAP filter uses the beginning of the phone number as the criteria to determine whether the individual user is a local or a
remote user.
When using multiple LDAP synchronization agreements, you have to make sure that the LDAP filters used by these
synchronization agreements are distinct so that no single user is matched by both filters.
LDAP Synchronization Agreements
To synchronize all local users to Unified CM, an LDAP synchronization agreement needs to be configured. The Remote agreement
has already been pre-configured for you. You will configure the Local agreement.
1. Navigate to System > LDAP > LDAP Directory and click Add New.
2. Use the table below to configure the Local LDAP Agreement.
Table 7. LDAP Agreement for Local Users
Setting Input
LDAP Configuration Name Local
LDAP Manager Distinguished Name cn=administrator, cn=users, dc=dcloud, dc=cisco, dc=com
LDAP Password C1sco12345
Confirm Password C1sco12345
LDAP User Search Base ou=demo users, dc=dcloud, dc=cisco, dc=com
LDAP Custom Filter for Users Local
Under Standard User Fields To Be mail

Synchronized: Directory URI
Access Control Groups Standard CCM End users and Standard CTI Enabled (Click Add to Access Control Group to add)
Under LDAP Server Information: Host 198.18.133.1

Name or IP Address for Server
3. Click Save.
4. Click Perform Full Sync Now and then OK.
User Authentication with LDAP
The LDAP authentication feature enables Unified CM to authenticate LDAP synchronized users against the corporate LDAP
directory. Locally configured users are always authenticated against the local database. PINs of all end users are always checked
against the local database only.
1. Navigate to System > LDAP > LDAP Authentication.
2. Check the box next to Use LDAP Authentication for End Users.
As you will notice, the rest of the configuration has been pre-populated. This is because during the setup and testing of this lab
these settings were configured. Keep in mind that on a brand new system you would have to fill in this information.
Cisco dCloud
3. Click Save.
Verify that the users synchronized successfully.

4. Navigate to User Management > End User.
5. Click Find.
The information for each user in the User Status column should now read Enabled LDAP Synchronized User. Because the
usernames of the local accounts matched those of the users configured for LDAP, the information was just updated for each
corresponding local user account instead of creating 12 new users.
Endpoint Provisioning
In this next section, you will manually configure one of the phones in your endpoint kit to show you how everything works together.
After that, to save time, you will turn on auto registration and use Self-Provisioning to provision the rest of your endpoints. Self-
Provisioning was preconfigured for you. The following steps will add a DX80 to the lab and assign it to Adam McKenzie. If you do
not have a DX80 in your endpoint kit, substitute the settings to match the type of endpoint you have.
1. Navigate to Device > Phone and click Find.
There is pre-configured a Jabber device for each user. You will manually configure one of your devices. Again, the steps will walk
you through adding a DX80. Substitute your device type were applicable.
2. Click Add New. For Phone Type, choose Cisco Telepresence DX80 (or your phone type) and then click Next.
3. Use the table below to configure the endpoint.
Table 8. Endpoint Configuration
Setting Input
MAC Address Enter the MAC Address of your endpoint
Description Adam McKenzie +19725555016
Device Pool RCDPhoneVideo
Phone Button Template Standard Cisco Telepresence DX80
Calling Search Space USEmergency
AAR Calling Search Space PSTNReroute
AAR Group Default
Owner User ID amckenzie
Under Protocol Specific Information: Device Cisco Telepresence DX80 – Standard SIP Non-Secure Profile
Security Profile
SIP Profile FQDN
5. To the left, click the Line [1] – Add a new DN link.
6. For Directory Number, enter \+19725555016.
7. Click within the Description box. Your page should refresh with pre-configured line information.
Most of the configuration has been done for you. Table 2-66 in the CVD contains all of the recommended configurations for a Line.
8. Scroll down the page to the Line 1 on Device section.
Cisco dCloud
9. For Display (Caller ID), enter Adam McKenzie.
10. For External Phone Number Mask, enter +19725555XXX.

11. Click Save.
Next, associate this device with Adam’s user account.
12. Navigate to User Management > End User. Click Find.
13. Click the amckenzie link.
14. Scroll down to the Device Information section and click Device Association.
15. Click Find.
16. Check the box next to your newly configured endpoint and then click Save Selected/Changes.
17. Next to the Related Links drop-down menu at the top right of the page, click Go.
18. Click Line Appearance Association for Presence in the same Device Information section.
19. Click Find, check the box to your newly configured endpoint, and then click Save.
20. Scroll down to the Directory Number Associations section and verify that \+19725555016 in DN is configured for Primary
Extension. If it is not, configure the setting now and then click Save.
Your endpoint should register now. If not, erase the ITL/CTL file on your endpoint. For a DX80, tap Settings > System
Information > Settings > Factory Reset > Reset. You will then need to choose Get Started > Other Services at the Welcome
screen. When you see the message "The system has detected a CUCM to register with 198.18.133.3 would you like to activate it?"
choose Activate and then the device registers.
On other endpoints, such as an 88x5, go to Settings > Administrator Settings > Reset Settings > Security Settings > Reset.
Endpoint Self-Provisioning
Self-Provisioning is not covered in the CVD; however, to save time use Unified CM Self-Provisioning to register any other
endpoints. First, turn on auto registration so your devices will register to Cisco Unified Communications Manager.
1. Navigate to System > Cisco Unified CM and click Find.
2. Click the CM_ucm-sub1 link.
3. Configure the Auto-registration Information section using the table below.
Table 9. Auto-registration Settings
Setting Input
Universal Device Template AutoReg_UDT
Universal Line Template AutoReg_ULT
Ending Directory Number 2000
Auto-Registration Disabled on Cisco Unified Communications Manager Unchecked
4. Click Save.
Cisco dCloud
Your endpoints should start auto registering. If not, you may need to delete the ITL/CTL file on your phone. Once your endpoints
auto-register use the steps below to assign your endpoint to a user.

NOTE: If you want to continue with the lab guide and come back later to self-provisioning your phones instead of waiting for all
your phones to auto-register you can do so.
5. Refer to the user table at the beginning of the lab guide and take note of the Self-Provisioning ID number listed for the user for
whom you are configuring the phone. You will need that in a moment.
6. Use the speed dial configured on your endpoint to call the Self-Provisioning number or just dial 1111.
7. When prompted for your self-provisioning identification number, enter the one from the user table and then press pound (#).
Press # once more to complete the self-provisioning. Your phone will restart with the correct settings assigned to that user.
ILS Configuration for Multi-Cluster Deployments
When the Intercluster Lookup Service (ILS) is configured on multiple clusters, ILS updates Unified CM with the status of remote
clusters in the ILS network.
The ILS cluster discovery service allows Unified CM to learn about remote clusters without the need for an administrator to
manually configure connections between each cluster.
The ILS cluster discovery service enables UDS-based service discovery for Jabber clients in multi-cluster environments. ILS is the
foundation for global dial plan replication (GDPR), which allows the exchange of reachability information for both alphanumeric
URIs and numeric destinations between Unified CM clusters to enable deterministic intercluster routing for those destinations.
To create an ILS network of multiple Unified CM clusters, perform the following tasks:
 Assign Unique Cluster IDs for Each Unified CM Cluster in the Network
 Activate ILS on the First ILS Hub Cluster in the Network
 Activate ILS on the Remaining ILS Clusters in the Network
 Consider UDS Certificate Requirements
In this lab, you have two clusters, US and EMEA. The EMEA cluster has already been configured for ILS and GDPR. You will
configure the US cluster so it and EMEA can share updates and the global dial plan.
US ILS Configuration
1. Navigate to System > Enterprise Parameters.
2. The Cluster ID needs to be configured. In the lab, this is pre-configured as USCluster. Keep this setting as is.
3. Navigate to Advanced Features > ILS Configuration.
The EMEA cluster is already activated for ILS, which made it the first node in the cluster. You will now activate the US cluster in the
deployment.
Cisco dCloud
4. Use the table below to configure ILS.
Table 10. Auto-registration Settings

Setting Input
Role Hub Cluster
Exchange Global Dial Plan Replication Data with Remote Clusters Checked
Advertised Route String us.route
Use TLS Certificates Unchecked
Synchronize Clusters Every 2
Use Password Selected
Use Password and Confirm Password box dCloud123!
5. Click Save.
6. In the pop-up window, configure ucm1-pub.dcloud.cisco.com for the Registration Server and then click OK. Since the
EMEA cluster has already been activated for ILS, thus making it the first node, you are registering this US second node with it.
7. Click OK to restart ILS.
8. After the page refreshes, click the Refresh button until you see EMEACluster show up in the ILS Clusters and Global Dial
Plan Imported Catalogs section at the bottom of the page.
ILS Clusters and Global Dial Plan Imported Catalogs
UDS Certificate Configuration
To enable UDS-based service discovery, the UDS process on each Unified CM cluster tries to establish connectivity with the UDS
processes running on remote Unified CM clusters to learn about the remote clusters’ UDS nodes. For this server-to-server
communication, TLS connections between the Unified CM clusters’ publishers are established and the remote peers’ certificates
are validated during TLS connection setup. To prevent this validation from failing, the Tomcat certificates of the Unified CM
publisher nodes of all Unified CM clusters must be exchanged.
The US Tomcat certificates have already been uploaded to the EMEA cluster. You will now perform the same tasks to import the
EMEA Tomcat certificates to the US cluster.
1. In Firefox, open another tab.
2. From the menus, choose Collaboration Server Links > Cisco Unified CM Publisher (EMEA).
3. Click the Cisco Unified Communications Manger link.
4. Change the Navigation drop-down menu to Cisco Unified OS Administration and then click Go.
5. Log in as administrator with Password: dCloud123!.
6. Navigate to Security > Bulk Certificate Management and click Export.
Cisco dCloud
7. Keep Tomcat selected and click Export. After the page refreshes, click Close.
8. Go back to the tab for the US cluster publisher and from the Navigation drop-down menu, choose Cisco Unified OS
Administration. Click Go. dCloud: The Cisco Demo Cloud
9. Log in as administrator with Password: dCloud123!.
10. Navigate to Security > Bulk Certificate Management and click Export.
11. Keep Tomcat selected and click Export. After the page refreshes, click Close.
12. You should now see both certificates listed at the bottom of the page and a new Consolidate button will appear. Since there
are only two clusters, you can consolidate these certificates. If you had more clusters, you would go to each cluster and export
the Tomcat certificate as you did for these two.
13. Click Consolidate.
14. Keep Tomcat selected and click Consolidate.
15. Click Close after the page refreshes.
16. You will see another certificate show up in the list at the bottom. This is the consolidated certificate of all clusters. Click
Import.
17. Keep Tomcat selected and click Import. Click Close after the page refreshes.
18. Navigate to Security > Certificate Management and click Find.
19. In the list, you will see the FQDN of the EMEA cluster listed next to tomcat-trust.
EMEA Cluster Certificate
20. You now need to import this same consolidated certificate to all clusters. This has already been completed for you on the
EMEA cluster, so no other configuration is needed.
GDPR Configuration
When Global Dial Plan Replication (GDPR) is enabled across an ILS network, remote clusters in an ILS network share global dial
plan data, including the following:
 Directory URIs
 +E.164 and ESN patterns
 PSTN failover number
GDPR allows you to create a global dial plan, including intercluster dialing of directory URIs and alternate numbers that span
across an ILS network. GDPR allows you to quickly configure the global dial plan across the ILS network without the need to
configure each dial plan component on each cluster separately.
Cisco dCloud
Configuring GDPR requires the following steps in addition to activating ILS as described in the previous section:
 Advertise URIs
 Configure Advertised Patterns
 Configure Partitions for Learned Numbers and Patterns
 Configure Intercluster Trunks
 Configure SIP Route Patterns
Advertise URIs
This action is completed by default on every URI in each directory number. To prevent individual URIs from being advertised, you
could go into the directory number and uncheck the box under Advertise Globally via ILS for the URI in the Directory URIs
section. In the lab, all URIs should be advertised so there is not anything to be configured in this section.
Configure Advertised Patterns
To keep the route plan small on remote clusters in this design, only summary patterns are advertised for each +E.164 and ESN
range hosted on each cluster. The patterns for sites RCD and RTP as well as the EMEA cluster have already been pre-configured.
You will now configure the patterns for SJC on the US cluster.
1. Go to Navigation at the top Right and choose Cisco Unified CM Administration from the drop down menu and click Go.
2. Log in as administrator with password dCloud123!.
3. On the US publisher, navigate to Call Routing > Global Dial Plan Replication > Advertised Patterns and click Find.
4. The patterns for RCD and RTP have already been pre-configured. These are based on Table 2-70 of the CVD. You will
configure the SJC patterns. Click Add New.
5. For Description, enter Site SJC DID range.
6. For Pattern, enter +14085554XXX.
7. Choose the radio button for +E.164 Number Pattern.
8. Choose the radio button for Use Pattern as PSTN Failover Number.
9. Click Save.
10. Using the table below, configure two more patterns for site SJC.
Table 11. SJC Advertised Patterns
Description Pattern Advertised Pattern Settings
ESN range of SJC DIDs 81404XXX Enterprise Number Pattern selected

Apply Strip Digits and Prepend Digits to pattern and Use for PSTN Failover selected
PSTN Failover Strip Digits 4
PSTN Failover Prepend Digits +1408555
ESN range of SJC non-DIDs 81405XXX Enterprise Number Pattern selected

Don’t use PSTN Failover selected
Cisco dCloud
The figure below lists all of the Advertised Patterns you have configured. Next to the Related Links drop down, click Go to return to
the Advertised Patterns and see this image.
US Advertised Patterns dCloud: The Cisco Demo Cloud
Configure Partitions for Learned Numbers and Patterns
Numeric patterns (+E.164 and ESN) learned from remote clusters are added to the local route plan into predefined partitions. The
Partitions for Learned Numbers and Patterns menu in Unified CM Administration allows you to define differentiated partitions for
each type of learned information. In this design, we do not need this differentiation and will simply configure GDPR to learn all
remote numeric patterns in a single partition, onNetRemote.
1. Navigate to Call Routing > Global Dial Plan Replication > Partitions for Learned Numbers and Patterns.
2. Use the table below to configure the GDPR partition settings.
Table 12. GDPR Partition Settings
Setting Input Comment
Partition for Enterprise Alternate Numbers onNetRemote (drop-down menu) Description Field
Mark Learned Numbers as Urgent unchecked
Partition for +E.164 Alternate Numbers onNetRemote (drop-down menu) Marked as urgent to avoid inter-digit timeout on +E.164
Mark Learned Numbers as Urgent checked on-net intercluster calls.
Partition for Enterprise Patterns onNetRemote (drop-down menu)

Mark Fixed Length Patterns as Urgent unchecked
Mark Variable Length Patterns as Urgent unchecked
Partition for +E.164 Patterns onNetRemote (drop-down menu) Marked as urgent to avoid inter-digit timeout on +E.164
Mark Fixed Length Patterns as Urgent checked on-net intercluster calls.
Mark Variable Length Patterns as Urgent unchecked
Cisco dCloud
The figure below displays what your GDPR settings should look like.
GDPR Partition Settings

Configure Intercluster Trunks
The GDPR exchange only makes sure that all URI and numeric reachability information is exchanged between Unified CM clusters
and associated with a SIP route string as the location attribute. Sessions between clusters need SIP trunks to be established. In
this design, we assume full-mesh SIP trunks between all Unified CM clusters, with a maximum of three Unified CM clusters. The
maximum of three Unified CM clusters ensures that the topology of the full mesh of SIP trunks is manageable. If more than three
Unified CM clusters are required, then adding Unified CM Session Management Edition (SME) is recommended to simplify the
topology to a hub-and-spoke topology with SME as the hub and all other Unified CM clusters as spokes or leaf clusters.
These trunks are pre-configured in the lab based on the first row of Table 2-72 in the CVD.
Configure SIP Route Patterns
SIP route patterns tie together the SIP route strings learned via GDPR and the SIP trunk topology. Think of it as if a GDPR route
strings tells us "where" a learned URI or numeric pattern is located, and we need route patterns matching on these route strings to
tell how to get to this destination.
To achieve full GDPR reachability, we need to make sure that each SIP route string advertised via GDPR can be routed according
to the provisioned SIP route patterns.
1. Navigate to Call Routing > SIP Route Pattern and click Add New.
2. Configure the SIP route pattern using the table below.
Table 13. GDPR SIP Route Pattern Settings
Setting Input
IPv4 Pattern emea.route
Route Partition onNetRemote
SIP Trunk/Route List RL_UCM_EMEA
3. Click Save.
Cisco dCloud
Verify the route patterns that are being advertised to the US cluster from the EMEA cluster:
4. Navigate to Call Routing > Global Dial Plan Replication > Learned Patterns.
5. Click the Find.
There are 9 patterns being advertised from the EMEA cluster. You can also log in to the EMEA publisher and see the patterns
being advertised from the US cluster to EMEA. You should see 7 pre-configured patterns plus the 3 you configured earlier.
Cisco dCloud
Scenario 3: Conferencing
Configure Call Manager SIP Profile to Enable Conferences with CMS dCloud: The Cisco Demo Cloud
1. In Firefox, open a new tab and go to Collaboration Server Links > US Publisher Unified CM Administration (US).
2. Log in as administrator with password: dCloud123!.
3. First, create a SIP Profile to use on the trunks to Conductor. Go to Device > Device Settings > SIP Profile and click Find.
4. Click the copy icon [ ] next to Standard SIP Profile for TelePresence Conferencing.
5. Configure the new SIP Profile using the table below. Leave the rest as default.
CMS SIP Profile
Setting Input
Name Standard SIP Profile for CMS
Description Default SIP Profile For Cisco Meeting Server
Timer Invite Expires (seconds) 100
Under Trunk Specific Configuration: Early Offer support for voice and video calls Best Effort (no MTP inserted)
SIP OPTIONS Ping: Enable OPTIONS Ping to monitor destination status for Trunks w/ Service Type "None (Default)" Checked
6. Click Save.
Configure SIP Trunks for CMS on CUCM
You will configure the trunk to connect to Cisco Meeting Server. A trunk is a communications channel on Unified CM that enables
Unified CM to connect to other servers. Using one or more trunks, Unified CM can receive or initiate voice, video, and encrypted
calls, exchange real-time event information, and communicate with call control and other external servers.
1. Navigate to Device > Trunk and click Add New. Set Trunk Type to SIP Trunk and leave the rest as default. Click Next.
2. Enter the following values. Leave the rest at default.
IP Trunk Settings
Setting Input
Device Name SIP_TRUNK_CMS1
Device Pool Trunks_and_Apps

AAR Group Default
Transmit UTF-8 for Calling Party Name Checked
Run On All Active Unified CM Nodes Checked

Under Inbound Calls: Calling Search Space TelePresenceConferencing
Calling and Connected Party Info Format Deliver URI and DN in connected party, if available
Under SIP information: Destination Address cms1.dcloud.cisco.com
SIP Trunk Security Profile Non Secure SIP Trunk Profile
SIP Profile Standard SIP Profile for CMS
Cisco dCloud
4. Click Reset, you will get a new pop-up. Click Reset again and then Close.
5. Click Add New.
NOTE: You must repeat this step for each call bridge in the Cisco Meeting Server cluster nodes. For example, if there are three
call bridges in the cluster, there should be three SIP trunks configured.
In this case, you need to create a second SIP_Trunk for CMS2
6. Navigate to Device > Trunk and click Add New.
7. For Trunk Type, choose SIP Trunk and leave the rest as default. Click Next.
8. Enter the following values. Leave the rest at default.
IP Trunk Settings
Setting Input
Device Name SIP_TRUNK_CMS2
Device Pool Trunks_and_Apps
AAR Group Default
Transmit UTF-8 for Calling Party Name Checked
Run On All Active Unified CM Nodes Checked
Under Inbound Calls: Calling Search Space TelePresenceConferencing
Calling and Connected Party Info Format Deliver URI and DN in connected party, if available
Under SIP information: Destination Address Cms2.dcloud.cisco.com
SIP Trunk Security Profile Non Secure SIP Trunk Profile
SIP Profile Standard SIP Profile for CMS
9. Click Save then OK.
10. Click Reset, you will get a new pop-up. Click Reset again and then Close.
11. Return to the list of trunks at Device > Trunk and verify they show as Full Service. This may take few minutes to show active.
CMS Trunks should show in Full Service
Configure Media Resources for the CMS Bridge
1. From the main menu, navigate to Media Resources > Conference Bridges.
2. Click Add New.
3. From the Conference Bridge Type drop down menu, choose Cisco Meeting Server.
Cisco dCloud
4. Complete the Conference Bridge configuration as follows:
a. Conference Bridge Name: Adhoc-CMS1

b. Description: Conference Bridge CMS1
c. SIP Trunk: SIP_TRUNK_CMS1
5. Under HTTP Interface Info, enter:
a. Username: admin
b. Password: dCloud123!
c. HTTPS Port: 445
NOTE: This is the network port used by CMS webadmin.
6. Click Save.
7. Click Reset.
8. Click Reset on the Device Reset pop up window.
9. Click Close.
10. Click Add New.
11. From the Conference Bridge Type drop down menu, choose Cisco Meeting Server.
12. Complete the Conference Bridge configuration as follows:
a. Conference Bridge Name: Adhoc-CMS2
b. Description: Conference Bridge CMS1
c. SIP Trunk: SIP_TRUNK_CMS2
13. Under HTTP Interface Info, enter:
a. Username: admin
b. Password: dCloud123!
c. HTTPS Port: 445
14. Click Save.
15. Click Reset.
16. Click Reset on the Device Reset pop up window.
17. Click Close.
18. From the Related Links, click Go Back to Find/List.
19. Click Find.
20. Verify that the Conference Bridge is registered to Unified CM
NOTE: You may need to wait up to one minute or more to see the conference bridge registered.
Cisco dCloud
Create a Media Resource Group
1. If disconnected from Workstation 1, RDP to it (198.18.133.36) and if necessary log in as Adam McKenzie with username:
dcloud\amckenzie and Password: C1sco12345.
2. Open a web browser and browse to Unified CM (https://198.18.133.3/ccmadmin). Alternatively, using the links on the dCloud
browser home page navigate to Collaboration Admin Links > Cisco Unified Communications Manager.
3. If required, click on the Cisco Unified Communications Manager link.
4. Log in as Username: administrator and Password: dCloud123!.
5. From the navigation menu, go to Media Resource > Media Resource Group.
6. Click Add New.
7. Enter CMS-Video in the Name box.
8. From the Available Media Resources drop down menu, choose Adhoc-CMS1 and Adhoc-CMS2 and move them using the
down arrow to the Selected Media Resources box.
Create a Media Resource Group
9. Click Save.
Create a Media Resource Group List
1. From the navigation menu, go to Media Resource > Media Resource Group List.
2. Click Add New.
3. Enter CMS-Video_MRGL into the Name box.
Cisco dCloud
4. From the Available Media Resources Groups drop down menu, choose CMS-Video and move it using the down arrow to
the Selected Media Resource Groups box.
Create a Media Resource Group List dCloud: The Cisco Demo Cloud
5. Click Save.
6. From the main navigation menu, go to Device > Phone.
7. Click Find.
8. From the search result, click on Adam Mckenzie’s Phone (Phone Model might change).
Search Result Selection
9. Under Device Information from the Media Resources Group List drop down, choose CMS-Video_MRGL.
Set the Media Resource Group List
10. Scroll down to the Product Specific Configuration Layout section.
Cisco dCloud
11. Verify that Web Access is set to HTTP + HTTPS, if it is not, enable it.
NOTE: This setting is needed later in the lab, but you are setting it here since you are already on the configuration page.
HTTP+HTTPS Enabled
12. Click Save.
13. Click Apply Config.
14. Click OK.
15. Click the Reset button on the top to load the new configuration.
16. Click the Restart button on the pop up and wait until the phone re-registers.
17. Click Close.
18. Change the Media Resource Group list on the other registered phones as well, so you can do a Test Ad-hoc Conference.
Test Ad-hoc Conference Escalation
1. In order to test this feature you will need three endpoints, such as Jabber for Windows/Mac, DX/70/80, or Cisco 88x5 Phones.
If you did not self-provision your endpoints earlier, now is the time to do so.
1. On the selected device, make a call to one of your other registered phones and Answer the call.
2. Press the + sign on the bottom of the DX70 screen.
3. Enter the number for a second device and place the call.
4. Answer the call on the second device.
5. Click Merge on the DX70. This results in a conference on all three devices with video.
Enable Clustering and Redundancy

CMS can cluster its database across three or five servers ensuring all user data, trunks, meeting info, and configuration is backed
up across all locations. This lets each server assume full control of the cluster in a failure event with no loss of configuration data.
In this section, you configure the database (db) clustering on Cisco Meeting Server (CMS). Cisco recommends you have at least 3
Conference Bridge nodes to create a viable db cluster, but this lab uses just 2 nodes to create the database clustering.
Cisco dCloud
Create Database Master on CMS1
1. From the Desktop, launch PuTTY . dCloud: The Cisco Demo Cloud
2. SSH to 198.18.134.185 (CMS1) and log in as: Username: admin with Password: dCloud123!.
3. At the cms1> prompt, enter the command: database cluster localnode a
NOTE: Use network interface a for database cluster communication.
4. Then enter the command: database cluster initialize
NOTE: Initialize CMS1 as the database master.
5. When requested to confirm enter Y. (Must be capitalized.)
CMS1 Initialize Clustering
6. When returned to the cms1> prompt, enter the command: database cluster status
NOTE: Checking the database initialization status: The result (Success) indicates the database cluster has initiated successfully.
Database Status
Cisco dCloud
Connect Second CMS To Master
TIP: Type syslog follow in the CMS1> prompt to keep the session active, type ctrl-c to return to the dCloud:
command line. Demo Cloud
The Cisco
1. Open another PuTTY session to CMS2 (198.18.134.147).
2. Log in as Username: admin with Password: dCloud123!.
3. At the cms2> prompt, enter the command: database cluster localnode a
NOTE: Use network interface a as database cluster communication.
4. Enter the command: database cluster join 198.18.134.185. This IP is CMS1 where you created the Master Database.
NOTE: Join the database cluster master at 198.18.134.185.
5. Confirm the join by entering Y. (Must be capitalized.)
Initialize Database on Second CMS
6. When returned to the cms2> prompt, enter the command: database cluster status
7. Run Command database cluster upgrade_schema.
NOTE: Checking the database initialization status: The results (In Sync) and (Success) indicate the database was successfully
connected as a slave and joined the database master. See figure below.
Second CMS Connected and in Sync
Cisco dCloud
Create Call Bridge Cluster
1. Return to the browser session connected to cms2 at https://198.18.134.147:445.

2. Click OK to log in.
4. From the main menu, navigate to Configuration > Cluster.
Configured Clustering on CMS
5. Set the Unique Name to cms2.
NOTE: This is the CMS2 call bridge identity.
6. Click Submit.
Add Unique Name to CMS2
7. Open a new tab in the browser window and browse to CMS1 https://198.18.134.185:445. Alternatively using the links on the
dCloud browser home page, navigate to Collaboration Admin Links > Cisco Meeting Server 1.
8. Click OK to log in.
10. From the main menu, navigate to Configuration > Cluster.
Cisco dCloud
11. Set the Unique Name to cms1.
NOTE: This is the CMS1 call bridge identity.

Add Unique Name to CMS1
12. Under the Clustered Call Bridges heading, configure the following two CMS servers:
a. Unique Name: cms1
NOTE: Ensure that this matches the call bridge identity configured in CMS1 above. **CASE MATTERS**
b. Address: https://198.18.134.185:445
NOTE: CMS1 webadmin URL will need to include the webadmin port as it was configured on the cms1 :445
13. Click Add New.
a. Unique Name: cms2
NOTE: Ensure that this matches the call bridge identity configured in CMS2 above. **CASE MATTERS**
b. Address: https://198.18.134.147:445
NOTE: CMS1 webadmin URL will need to include the webadmin port as it was configured on the cms2 :445
Added Clustered Bridges
Configure Outbound dial rule for Callbridge
To create an Outbound dial rule you need to use an API. In this case, you will be using PostMan that is installed on Workstation 1.
1. On Workstation 1, first verify the Outbound calls in CMS1. Open a new tab in Firefox, and go to cms1.dcloud.cisco.com:445.
Log in as admin with password: dCloud123!.
Cisco dCloud
2. Go to Configuration > Outbound calls.
Outbound Calls
3. Confirm that there is no Outbound Dial Plan configured yet.
Outbound Dial Plans
Cisco dCloud
4. Go to the taskbar and open PostMan . Click Import, it will open a new pop-up, click Choose Files.
Choose Files
5. Look for Lab Files Folder on the Desktop, click CallBridge Outbound Dial Plan.json, and click Open.
Lab Files
Cisco dCloud
6. In the left Column, click Get Call Bridges IDs, and click Send. Enter the username as api and the password: dCloud123!.
Get Call Bridge IDs

7. You will receive a response similar to the figure below. The Callbridge ID will always be a unique ID. Confirm that the cms2 id
is listed before the cms1 id. If you get an error, try a second time.
Call Bridge IDs
8. Write down the 2 Call Bridge ID’s and save them, you will need them for the next steps.
9. Return to the PostMan window and click Create Outbound Dial Plan CMS1, and click Body. You will see the following text:
domain=198.17.134.147&sipProxy=198.17.134.147&callBridge=4570d559-1dea-444f-8ff1-
9ccfee9c2502&localFromDomain=cms1&trunkType=sip&sipControlEncryption=auto&priority=200&failureAction=stop&scope=
callBridge
10. Replace the highlighted part of this text with your CMS1 Call Bridge ID you got from the previous step, and Click Send. You
should receive the response Status: 200 OK in the upper right. If you get an error try several times.
Status: 200 OK Message
Cisco dCloud
11. Click Create Outbound Dial Plan CMS2, and click on Body, you will see the following text:
domain=198.18.134.185&sipProxy=198.18.134.185&callBridge=27a3a7fb-5458-46f7-a592-
f987970b4842&localFromDomain=cms2&trunkType=sip&sipControlEncryption=auto&priority=200&failureAction=stop&scope=callB
ridge
12. Replace the highlighted part with the CMS2 Call Bridge ID you got from the previous step, and Click Send. You should
receive the response Status: 200 OK in the upper right. If you get an error try several times.
Status: 200 OK
13. Using Firefox, browse to cms1.dcloud.cisco.com and log in as admin with password: dCloud123!. Go to Configuration >
Outbound calls. You will now be able to see the two different Outbound Rules.
Outbound Calling Rules
Configure TMS for Scheduled Conferences
In this section, you will configure Cisco Meeting Server, Unified CM, and TMS for scheduled conferences. In the previous section,
you configured instant meetings and laid the groundwork for scheduled conferences.
You created a trunk for scheduled conferences in Unified CM, which points to the rendezvous interface on CMS. Now you will
create a Route Group, which contains that trunk.
1. 1. Open a web browser and browse to Unified CM (https://198.18.133.3/ccmadmin). Alternatively, using the links on the
dCloud browser home page navigate to Collaboration Admin Links > Cisco Unified Communications Manager.
2. If required, click on the Cisco Unified Communications Manager link.
4. On the Unified CM Administration page of the US Publisher, navigate to Call Routing > Route/Hunt > Route Group.
5. Click Add New.
Cisco dCloud
6. For Route Group Name, enter RG_SPACE_SCHED.
7. Highlight SIP_TRUNK_CMS1 and SIP_TRUNK_CMS2 from the Available Devices list and click Add to Route Group.
8. Click Save.
9. Navigate to Call Routing > Route/Hunt > Route List and click Add New.
10. For Name, enter RL_SPACE_SCHED and choose CM_1 from the Cisco Unified Communications Manager Group drop-down.
11. Click Save.
12. Click Add Route Group.
13. Choose RG_SPACE_SCHED-[NON-QSIG] from the Route Group drop-down menu. Click Save and then OK.
14. Check the box next to Run On All Active Unified CM Nodes.
15. Click Save.
Add CMS Cluster to TMS
1. Open a new tab in the web browser and go to TMS (https://198.18.133.158/tms). Alternatively, using the links on the dCloud
home page, navigate to Collaboration Admin Links > Cisco TelePresence Management Suite.
2. If prompted with the message This Connection is Untrusted,click I understand the Risks.
3. Click Add Exception.
4. Click Confirm Security Exception.
5. Log in to TMS server as Username: administrator with Password: C1sco12345
NOTE: TMS uses the password C1sco12345.
6. From the main menu, click Systems.
7. Click on the Infrastructure folder on the left panel.
Cisco dCloud
8. In the right panel, click Add Systems. As you can see, Unified CM is already added for you.
Add Systems
9. In the Specify Systems by IP Address section, type cms1.dcloud.cisco.com:445 in the top field.
Specify Systems by IP Address
10. Under Advanced Settings, type username admin and password dCloud123!.
Cisco dCloud
11. At the bottom of the screen, click Next.
12. Click Finish Adding Systems.

Finish Adding Systems
NOTE: No Name is the CMS that was just added. Its name is still blank and a ticket is raised for this. The next steps will fix this.
13. In either the right or left panel, click on No Name (cms1.dcloud.cisco.com:455).
14. Click the Settings tab and click on Edit Settings.
Edit Settings
Cisco dCloud
15. Set the following:

a. Name: Meeting Server
b. Alternate IP: 198.18.134.147:445 dCloud: The Cisco Demo Cloud
NOTE: The Alternate IP dropdown will be enabled only if the added CMS is part of a cluster. Although CMS allows for more than
two peers in the cluster, TMS only supports one cluster peer for failover. If both master node and alternate IP are down, TMS will
not use other clustered call bridges that are part of a CMS cluster.
c. Alternate IP Username: admin
d. Alternate IP Password: dCloud123!
Settings for Cluster
16. Click Save.
NOTE: If the added CMS is part of a cluster, there will be the Clustering tab in TMS that shows the cluster peers’ information.
Clustering Tab
Cisco dCloud
Add Endpoint to TMS
1. Return to the Systems Navigator, and in the left pane click the Endpoints folder and click Add Systems again.
Adding Endpoint to TMS
2. Click on the Add from Unified CM or TMS tab.
3. Click Adam Mckenzie (Cisco Telepresence DX70SIP) and click Next.
Add Endpoint to TMS
4. TMS will find the system, but give an error of Wrong system settings. Ignore the warning and click Edit System.
Edit System
5. Click on Add system despite warnings.
6. Click Finish Adding Systems.
Cisco dCloud
Configure Conference Default Settings

1. Continuing in TMS. From the navigation menu, go to Administrative Tools > Configuration > Conference Settings.
2. Under the Conference Creation parameters, change the Default Reservation Type for Scheduled Calls to One Button to
Push.
NOTE: TMS will default the type to One Button to Push whenever a conference is scheduled.
One Button to Push
3. Under the Advanced parameters, make sure the Preferred MCU Type in Routing is set to Cisco Meeting Server.
NOTE: TMS will use Cisco Meeting Server as the default MCU to schedule meetings.
Preferred MCU Type
4. Click Save.
5. From the navigation menu, navigate to Administrative Tools > Configuration > WebEx Settings.
6. Make sure is set the Add WebEx to All Conferences to No.
WebEx Setting
NOTE: When the Include WebEx option is checked during scheduling meeting, Cisco Meeting Server will not be available as an
MCU. Cisco Meeting Server does not support WebEx.
Cisco dCloud
7. Click Save.
8. Do not log out of TMS as it will be used in the next Task.

Set up Dial-in Numbers for Scheduled Conferences

In the following section, the numbers that participants dial to join the scheduled conferences will be configured. Administrators can
configure a range of numeric IDs here. For each number created, TMS will create an inactive Space in CMS. When users schedule
meetings, TMS will choose an available Space to host the meeting and return the dial-in number to the organizer. When it is time
to start the scheduled meeting, TMS activates that Space and participants can call the number to join the meeting on that Space.
1. From the main menu, navigate to Systems > Navigator.
2. Click on the Infrastructure folder and then click on the Meeting Server.
3. Click the Settings tab and then click on the Extended Settings link.
4. Configure the Extended Settings as follows:

Domain: dcloud.cisco.com
Numeric ID Base: 80991001
Numeric ID Quantity: 1
NOTE: The route pattern configured in Unified CM should match the numeric ID base and quantity defined here.
Parameters set for Extended Settings
5. Click Save.
6. Return to the browser tab connected to CMS1 https://cms1.dcloud.cisco.com:445.
7. If logged out, click OK to log in.
9. From the main menu, navigate to Configuration > Spaces.
Cisco dCloud
10. Using the navigation numbers at the bottom of the page, click on the 4. Observe that there is a new space called
TMS_Scheduled_Meeting_80991001.

NOTE: This is the space created by TMS when the numeric ID 80991001 was configured. TMS will use this space to schedule
meetings.
New Space Created by TMS
Next, configure a route pattern that matches an alias you will configure on TelePresence management Suite in the steps ahead.
11. Return to the Unified Communication Manager US Publisher at https://198.18.133.3/ccmadmin.
12. Navigate to Call Routing > Route/Hunt > Route Pattern and click Add New.
13. Configure the new pattern using the table below.
Table 41. Scheduled Conference Route Pattern
Setting Input
Route Pattern 8099[12]XXX
Route Partition ESN
Description Scheduled Conference on TMS
Gateway/Route List RL_SPACE_SCHED
14. Click Save and then OK twice.
Schedule a Conference
Scheduling a Conference Call in TMS
1. Return to the browser tab connected to TMS (https://198.18.133.158/tms).
2. If requested to, log in as:

Username: administrator
Password: C1sco12345
Cisco dCloud
3. From the main menu, navigate to Booking > New Conference.
New Conference in TMS

4. Make sure that One Button To Push is selected in Type dropdown list.
NOTE: This lab shows the experience of joining the meeting using One Button to Push.
5. Set the Duration to 1:00 (1 hour).
6. At this first screen, click Add Participants.
Set Meeting Parameters
Cisco dCloud
7. Click the Endpoints tab. Click the DX70, which allows that user to join via OBTP on this device.
NOTE: The DX70 is running CE software and supports OBTP. Add this to create the OBTP joining method.
Choose Endpoints
8. Click the right arrow .
9. Click on the External tab and specify:

Protocol: SIP
Qty: 2
NOTE: This allows two participants to dial in to the conference using the numeric alias.
Add 3 Dial-in SIP Participants
10. Click the right arrow .
11. Click OK to return to the previous menu.
12. Click Save Conference.
13. Observe as the screen refreshes to display the conference information (such as dial in number and conference ID).
Conference Details
NOTE: The information shows the Conference Title, Conference ID, CMS used, and two dial-in participants allowed with numeric
ID 80991001.
Cisco dCloud
Make a Test Call
1. A green Join button should appear on the DX70. Press the button to join the conference.
2. On any 8800, dial 80991001 to join the conference.
3. On the second 8800, dial 80901001 to join the conference.
4. All three devices should be able to join the conference.
5. End the conference by hanging up each endpoint.
Cisco dCloud
Scenario 4: Collaboration Edge

In this scenario, you will configure Mobile and Remote Access (MRA) and Business-to-Business Communications (B2B) using
Cisco Expressway. The last part of this scenario will cover deploying Cisco Unified Border Element (CUBE).
MRA allows endpoints like Cisco Jabber to have their registration, call control, provisioning, messaging, and presence services
provided by Cisco Unified CM, IM & P, and Unity Connection when the endpoint is not within the enterprise network. The
Expressway-C and Expressway-E servers provide secure firewall transversal and line side support for Unified CM registrations as
well as IM & P XMPP traffic and Unity Connection HTTP messaging traffic.
B2B allows seamless voice and video communications between two or more organizations without the need for local device
registration. Combined with URI dialing, Joe at companyA.com can make a video call to Alice at companyB.com simply by dialing
her URI address alice@companyb.com. In this lab, Expressway-E is not publicly reachable so there is no validation test you can
run after configuration is complete. This scenario is for you to get hands-on experience in B2B configuration so you can implement
this in a live production environment.
In the lab, the Expressways have some pre-configuration on them. The steps taken to complete most of the pre-configuration are
listed in the Appendix E.
If you want to take the time now and close some of the Firefox tabs you have open, you can close all of them except for the
Unified CM Publisher tab for the US cluster.
Mobile and Remote Access Configuration
Configuration of Traversal Zones on Expressway-E and Expressway-C for MRA
Configure the Transversal zones between Expressway-E and Expressway-C so they can communicate across firewalls.
1. Open a tab in Firefox and go to Collaboration Server Links > Cisco Expressway-E. Log in as admin with password:
dCloud123!.
2. Navigate to Configuration > Authentication > Devices > Local database and click New.
3. Configure the following:
Table 42. Local User Configuration
Setting Input
Username TraversalAdmin
Password dCloud123!
4. Click Create credential.
5. Navigate to Configuration > Zones > Zones and click New.
Cisco dCloud
6. Configure the following information. If a setting is not mentioned then leave it at the default setting.
Table 43. Expressway-E Zone Settings

Setting Input
Name TraversalServer (MRA)
Type Unified Communications traversal

TLS verify subject name exp-c-1.dcloud.cisco.com
7. Click Create zone.
8. Open a tab in Firefox and go to Collaboration Server Links > Cisco Expressway-C. Log in as admin with password:
dCloud123!.
10. Configure the following information. If a setting is not mentioned then leave it at the default setting.
Table 44. Expressway-C Zone Settings
Setting Input
Name TraversalClient (MRA)

Type Unified Communications traversal
Password dCloud123!
Port 7001
Peer 1 address exp-e-1.dcloud.cisco.com
12. To verify the connection on each expressway, navigate to Configuration > Zones > Zones and click on the zone you created.
13. Scroll to the bottom of the page to the Status section.
14. The State on both Expressway Zones should be .
15. On Expressway-E, Connection 1 should show .
16. On Expressway-C, under the Location section, Connection 1 should show .
Jabber Client Internal and External Test on Workstation 2
In this section, you will validate the configuration on the Expressway servers. Right now, both workstations are connected to the
internal network. You will test the connectivity internally first when both clients are internal. Then you will move Workstation 2 to the
mock external network and verify you still have connectivity when you are connecting from the outside.
1. Open Cisco Jabber [ ] on Workstation 1. Accept any certificate warning and continue.
2. RDP to Workstation 2 (198.18.133.37) and log in with username dcloud\cholland and password C1sco12345.
3. Open Cisco Jabber on that workstation as well.
Cisco dCloud
4. Call Adam from Charles’ Jabber client. Answer on any registered device for Adam to verify connectivity. End the call.
5. On Workstation 2, click the gear icon [ ] in Jabber and choose Help > Show connection status.
Wkst2 Jabber Connection Status
6. Note the Address you are connected to in the Softphone section. You should be either connected to the address of ucm-
pub.dcloud.cisco.com (CCMCIP) or ucm-sub1.dcloud.cisco.com (CCMCIP).
Wkst2 Jabber Softphone Address
7. Close the Connection Status window.
Next, you will connect Workstation 2 to the external network to test the Expressway configuration. There are two batch files located
on the Workstation 2 desktop. One reads External Network On and one reads Internal Network On. These are what you will use
to switch from the Internal to External network and back.
Wkst2 Internal/External Batch Files
8. Double click on the External Network On icon. You will lose connectivity and have to reconnect to the External IP address.
9. Open a new RDP session to Workstation 2 using the external IP address (198.18.2.37). Log in with the same credentials:
(dcloud\cholland/C1sco12345).
Cisco dCloud
10. Exit Cisco Jabber and the re-open.
Exit Client
11. Click the gear icon [ ] in Jabber and choose File > Help > Show connection status.
12. Note the Address has changed in the Softphone section. Now it is connected to either ucm-pub.dcloud.cisco.com
(CCMCIP - Expressway) or ucm-sub1.dcloud.cisco.com (CCMCIP – Expressway).
Wkst2 Jabber Softphone Address (Expressway)
13. Make a call from Charles’ Jabber client to Adam McKenzie. The call should still connect, but this time it is routed through the
Expressway. Keep the call connected.
14. Go back to the Firefox tab for one of the Expressway servers on Workstation 1.
15. Navigate to Configuration > Zones > Zones and click on the link of the zone with the text “MRA“ at the end.
16. Scroll to the bottom of the page and notice there is 1 call to this zone.
Expressway-C Zone Status
Expressway-E Zone Status
17. End the call and refresh the zone page. The number of calls drops to 0.
18. Double click on the Internal Network On icon to re-enable the internal network connection for Workstation 2.
Cisco dCloud
Business-to-Business Communications Configuration

Some of the B2B configuration is already completed. Most of the pre-configuration steps are in Appendix E.dCloud: The Cisco Demo Cloud
NOTE: You configure an external Expressway server, but it is not a functional part of the lab. In order to demonstrate a working
external Expressway server for B2B calls you need the Cisco Business Video On-Premise Experience 11.6 v1 demonstration.
Configure neighbor zone on Expressway-C for Unified CM for B2B
1. Open the tab to the Expressway-C server on Workstation 1 and log in if needed as admin with password: dCloud123!.
3. Enter the following into the relevant fields.
Table 45. Expressway-C Unified CM Zone Settings
Setting Input
Name Unified CM Neighbor Zone (B2B)
Type Neighbor
H.323 mode Off
SIP mode On (default)
Port 5560
Transport TCP
Peer 1 address1 198.18.133.3
Zone profile Cisco Unified Communications Manager (8.6.1 or later)
Configure Traversal Client Zone on Expressway-C for Expressway-E for B2B
There is already a traversal connection established between Expressway C and E for MRA traffic. However, we will create a
parallel traversal connection using the Traversal Client and Traversal Server zone types that will allow both encrypted and non-
encrypted B2B video traffic. The Unified Communications traversal zones established for MRA always enforce signaling and media
encryption, which is good for MRA traffic, but can be limiting if the same encryption policy is enforced for B2B video.
1. Click New.
2. Enter the following into the relevant fields, leaving the other fields at their default values.
Table 46. Expressway-C to Expressway-E Zone Settings
Setting Input
Name TraversalClient (B2B)
Type Traversal client
Username b2badmin
Password dCloud123!
H.323 Port 6011
SIP Port 7011

Transport TLS (default)
Peer 1 address exp-e-1.dcloud.cisco.com
Cisco dCloud
NOTE: This Zone will be in a failed state until you configure the relevant zone on the Expressway-E server.
Configure Search Rules on Expressway-C for B2B
1. Navigate to Configuration > Dial plan > Search rules and click New.
Table 47. Search Rule Settings
Setting Input
Rule name B2B-to-external
Description B2B calls to external
Priority 101
Mode Alias pattern match
Pattern type Regex
Pattern string (?!.*@%localdomains%.*$)(.*)
Pattern behavior Leave
On successful match Stop
Target TraversalClient (B2B)
State Enabled (default)
3. Click Create search rule.
4. Click New.
5. Enter the following into the relevant fields, leaving other fields at their default values.
Setting Input
Rule name B2B-from-external
Description B2B calls from external to Unified CM
Priority 100 (default)
Pattern type Regex
Pattern string (.*)(@dcloud.cisco.com).*
Target Unified CM Neighbor Zone (B2B)
Cisco dCloud
Configure Transform on Expressway-C for B2B
1. Navigate to Configuration > Dial plan > Transforms and click New.
Table 49. Transform Settings
Setting Input
Priority 1 (default)
Description Stripping out port info from URI
Pattern type Regex
Pattern string ([^@]*@[^@]*)\:\d\d\d\d.*

Pattern behavior Replace (default)
Replace string \1
3. Click Create transform.
Configure Traversal Server Zone on Expressway-E for Expressway-C for B2B
1. Open the Expressway-E tab and log in if needed as admin with password: dCloud123!.
2. Navigate to Configuration > Authentication > Devices > Local database and click New.
Table 50. Expressway-E Local User
Setting Input
Name b2badmin
Password dCloud123!
4. Click Create credential.
Table 51. Zone Settings
Setting Input
Name TraversalServer (B2B)

Type Traversal server
Username b2badmin
H.323 Port 6011
SIP Port 7011
Transport TLS (default)
Cisco dCloud
Configure DNS Zone on Expressway-E for B2B
For a B2B call, Expressway-E does not know where to route the call for a different domain. It does not have a neighbor created for
that domain. Because of this, it routes all the calls via the public DNS server.
1. Click New.
Table 52. DNS Zone Settings
Setting Input
Name DNS Zone (B2B)
Type DNS
Fallback Transport Protocol TCP
Configure Search Rules on Expressway-E for B2B
1. Navigate to Configuration > Dial plan > Search rules and click New.
Setting Input
Rule name B2B-internal-to-external

Description B2B calls to external domains
Priority 101
Pattern type Regex
Pattern string (?!.*@dcloud.cisco.com.*$)(.*)
Target DNS Zone (B2B)
4. Click New.
Cisco dCloud

Setting Input
Rule name B2B-external-to-internal
Description B2B calls from external domains to internal

Pattern type Regex
Pattern string (.*)(@dcloud.cisco.com).*

Target TraversalServer (B2B)
Configure Transform on Expressway-E for B2B
1. Navigate to Configuration > Dial plan > Transforms and click New.
Table 55. Transform Settings
Setting Input
Description Stripping out port info from URI
Pattern type Regex
Pattern string ([^@]*@[^@]*)\:\d\d\d\d.*
Pattern Behavior Replace
Replace string \1
3. Click Create transform.
Configure SRV Records on the External (public) DNS Server for B2B
The last item to configure is the public DNS server. This ensures that the public DNS server has the correct SRV records so that
the endpoints can discover Expressway-E to route business-to-business calls. There also needs to be an A record created for the
Expressway-E server that was pre-configured for you.
1. Open an RDP session to the external DNS server (198.18.2.11).
2. Log in with Username: administrator and Password: C1sco12345.
3. Open the DNS Manager using the icon [ ] on the desktop or taskbar.
4. Expand AD2 > Forward Lookup Zones and click on dcloud.cisco.com.
5. Right click on dcloud.cisco.com and choose Other New Records… from the pop-up menu.
Cisco dCloud
6. Choose Service Location (SRV) in the record type list and then click Create Record….
7. Fill in the following information:

Table 56. Expressway-E _tcp SRV Record
Setting Input
Service _sip
Protocol _tcp
Priority 10
Weight 10
Port number 5060
Host offering this service exp-e-1.dcloud.cisco.com.
8. Click OK and then click Create Record….
9. Fill in the following information.
Table 57. Expressway-E _udp SRV Record
Setting Input
Service _sip
Protocol _udp
Priority 10
Weight 10
Port number 5060
10. Click OK and then Done.
11. Close DNS Manager and exit the RDP connection to AD2.
Cisco Unified Border Element (CUBE) Configuration

In this section, you will configure CUBE as a SIP-to-SIP gateway to the pre-configured mock PSTN router. When CUBE is
configured correctly, the call will go out to the PSTN router and hairpin back to Unity Connection and play a pre-recorded message.
There is one CUBE that all dCloud datacenters share.
There has been some pre-configuration to give the router IP connectivity and allow SSH access. The lab guide will give you
commands to copy and paste and explain what you are doing with the commands.
1. On Workstation 1, open PuTTY with the Desktop icon [ ] and double click US-CUBE in the Saved Sessions list.
2. Log in as admin with Password: C1sco12345.
3. Once logged in, type conf t.
Cisco dCloud
4. Enter the following commands:
Table 58. CUBE Commands

Prompt Command
(config)# voice service voip

(conf-voi-serv)# no ip address trusted authenticate
The voice service voip command is where you will configure the global configurations for CUBE. The no ip address trusted
authenticate command disables trusted addresses. This new feature in IOS 15.x is a toll-fraud prevention mechanism. In your
private network, you can provide specific IP addresses from which you wish to permit this device to establish calls. For the purpose
of this lab, this feature is disabled with that command.
Next, you need to add some additional CUBE-specific configuration to the router. First, you will enable the border element
commands. With this particular router, it is not needed but is good to know and it does not hurt to configure. You can safely ignore
the reboot message. Second, you will enable sip-to-sip connections. By default, Cisco IOS does not permit a call to both originate
and terminate on a VoIP call leg. At least one party in the call must be a POTS port. With this command, you are allowing VoIP to
VoIP connections as long as both call legs are SIP.
Prompt Command
(conf-voi-serv)# mode border-element

(conf-voi-serv)# allow-connections sip to sip
Next, enable address hiding. This will force the CUBE to utilize its own IP addresses for each of the call legs so that the service
provider does not have visibility to your internal IP addressing.
Prompt Command
(conf-voi-serv)# address-hiding
Enable header and mid-call signaling pass-through. When CUBE receives a SIP INVITE, SUBSCRIBE, and NOTIFY message, the
header passing command enables passing SIP headers associated with these messages to the other party in the call.
The error-passthru command allows a received error response from one SIP leg to pass transparently over to another SIP leg.
The early-offer forced command helps speed up SIP trunk codec negotiations by the initiator sending its capabilities in the initial
SIP invite message.
Prompt Command
(conf-voi-serv)# sip
(conf-serv-sip)# header-passing
(conf-serv-sip)# error-passthru
(conf-serv-sip)# early-offer forced
The supported codecs are configured via the voice class codec. Many customers prefer to use G.729 as the preferred codec to
conserve bandwidth to SIP trunks to service providers. Some services only accept G.711. You can define different codec classes
and apply them to the different dial-peers based on call flow direction to handle different call types, for example Fax pass-through.
In our case, we will prefer G.711 but still allow G.729 so that Unified CM can negotiate G.729 if necessary.
Cisco dCloud
Prompt Command
(conf-serv-sip)# voice class codec 1
(config-class)# codec preference 1 g711ulaw
(config-class)# codec preference 2 g729r8
Before the release of CUBE 10.0, the options ping configuration was performed on an individual dial-peer basis using the voice-
class sip options-keepalive command and all the relevant parameters like timers and retry counts had to be configured on each
dial-peer. This configuration is still possible if you are not using the server-groups capability. However, when using server-groups,
you must use the new options-keepalive profile construct to enable OPTIONS ping. This profile is then applied to each dial-peer.
To enable OPTIONS ping, first create a sip-options-keepalive voice class. Then you will apply it to the dial-peer pointing to
Unified CM later. It is possible to configure many parameters, such as the ping interval when a server is up and running, and the
interval when it is down (set to 30 and 60 seconds, in this example)
Prompt Command
(config-class)# voice class sip-options-keepalive 1

(config-class)# transport tcp
(config-class)# down-interval 30
(config-class)# up-interval 60
(config-class)# retry 5
(config-class)# description Target Unified CM
It is best practice to configure the media inactivity timer to tear down calls that are not transmitting RTP in the network. This can
happen if there is a failure in the network somewhere that leads to CUBE not being notified that the call has ended. By detecting
whether or not the CUBE has received RTP packets for a specified number of minutes, CUBE can automatically tear down
orphaned connections. Note that IP phones still send RTP packets even if they are on Mute, so leaving a call muted for an
extended period will not cause the call to drop.
Prompt Command
(config-class)# gateway
(config-gateway)# media-inactivity-criteria all
(config-gateway)# timer receive-rtcp 5
If you have worked with IOS voice configuration, you may be familiar with dial-peer configurations where a dial-peer exists with a
destination pattern for each of the UC Manager nodes that CUBE wants to send calls. As an example, with a cluster of Unified
Communication Manager of eight call-processing nodes, you would have to configure eight dial-peers for each pattern you want to
send to Unified CM. This means if you had three different patterns pointing to the cluster, you would need twenty-four dial-peers.
A new feature introduced in CUBE release 10.0 will significantly reduce the count of dial-peers in a Border Element. This feature is
called a destination server group. This feature is configured as a voice class function outside of the dial-peers and then assigned
to a dial peer, instead of a session target pointing to an individual IP address. You will configure a group to the two US Unified CM
servers in the lab. If no preference commands are used, then a round-robin algorithm is selected and the Unified Border Element
will share the load between multiple servers.
In this lab, we are not specifying any preference such that the round-robin algorithm is selected and some inbound calls will be
routed to the Publisher node. Normally you would not route inbound calls to the Publisher node.
Cisco dCloud
Prompt Command
(config-gateway)# voice class server-group 1
(config-class)# ipv4 198.18.133.3
(config-class)# ipv4 198.18.133.219
(config-class)# hunt-scheme round-robin
First, configure the incoming dial peer for calls coming from Unified CM. You also want to anchor calls that originate from your
network to this dial-peer. To accomplish this, you will utilize the incoming called configuration command on the dial-peer. Every
call that traverses CUBE has an inbound and outbound dial- peer match. The inbound peer determines any settings relevant to the
inbound call leg, such as codecs, and DTMF configuration. The outbound dial peer does the same for the outbound call leg.
It is a good practice to ensure calls are assigned (or anchored) to a configured dial-peer. If not, you risk matching the default dial-
peer, dial-peer 0, which may not have the parameters you want to apply for that session. This is why you use the command
incoming called to catch the inbound call leg. Repeat this to anchor the inbound calls from the PSTN on the second dial-peer.
Prompt Command
(config-class)# dial-peer voice 100 voip
(config-dial-peer)# description *Inbound from UCM
(config-dial-peer)# incoming called-number *T
The variable *T indicates any numeric string of any length, since calls from Unified CM might be sent to any destination in the
world. A closer match might help, but when the Unified Border Element is centralized, it provides the service for multiple locations.
It starts with a * because you are sending a * at the beginning of the called number from Unified CM. You will need to strip that star
off later with a translation pattern before sending to the PSTN. You will do that in a moment. Make sure that for any calls matching
a dial-peer the only protocol used is SIP. The command is session protocol sipv2.
Prompt Command
(config-dial-peer)# session protocol sipv2
Two additional commands are important: the DTMF relay configuration and the maximum connections. For the purpose of this lab,
the maximum number of connections is five and you will be using RFC2833 as the DTMF transport. You will also assign the voice
class codec you configured previously.
Prompt Command
(config-dial-peer)# max-conn 5
(config-dial-peer)# dtmf-relay rtp-nte
(config-dial-peer)# voice-class codec 1
(config-dial-peer)# no vad
Now, you can configure the bind between the dial-peer and the interface. There are two commands you will be using on each dial
peer. Media and signaling each are configured with separate bind commands.
Cisco dCloud
Prompt Command
(config-dial-peer)# voice-class sip bind control source-interface GigabitEthernet1
(config-dial-peer)# voice-class sip bind media source-interface GigabitEthernet1
Now, you will configure the outbound dial-peer to the PSTN.
Prompt Command
(config-dial-peer)# dial-peer voice 201 voip

(config-dial-peer)# description *Outbound WAN to SP
(config-dial-peer)# destination-pattern *T
(config-dial-peer)# session target ipv4:10.0.0.1
Before you address the translations needed on this dial-peer, configure the dial-peers from the PSTN and outbound to UCM. They
are very similar to the ones you configured earlier.
Prompt Command
(config-dial-peer)# description *Inbound WAN from SP
(config-dial-peer)# incoming called-number .T

(config-dial-peer)# description *Outbound to UCM
(config-dial-peer)# destination-pattern .T
(config-dial-peer)# session server-group 1
(config-dial-peer)# voice-class sip options-keepalive profile 1
There are two more items left to complete the CUBE configurations. The first is the voice class dpg command. This is used to
bind the outbound dial-peer to the inbound dial-peer. First, you create the dpg’s and then assign them to the correct dial-peers.
Cisco dCloud
Prompt Command
(config-dial-peer)# voice class dpg 101
(config-class)# dial-peer 101
(config-class)# voice class dpg 201
(config-class)# dial-peer 201
(config-class)# dial-peer voice 100 voip

(config-dial-peer)# destination dpg 201
(config-dial-peer)# destination dpg 101
The last item is the voice translation. As mentioned earlier in Unified CM, you are sending a * at the beginning of the called number
on outbound calls which enables the router to distinguish the direction of the call. This character must be stripped as well as a
leading + added before it is sent out to the PSTN. Further, according to the configured dial plan, the calling number has to be
normalized with the "+". This will be taken care of by rule 4. The rules are applied to the called number. Two rules might be created
for this, one for the called number and one for the calling number. However, since the called number always matches the first rule,
and the calling number always matches the second rule, it is possible to use a single voice translation rule.
Prompt Command
(config-dial-peer)# voice translation-rule 1

(cfg-translation-rule)# rule 1 /^\*9$911$/ /\1/
(cfg-translation-rule)# rule 2 /^\*$911$/ /\1/
(cfg-translation-rule)# rule 3 /^\*/ /+/
(cfg-translation-rule)# rule 4 // /+/
(cfg-translation-rule)# voice translation-profile SIPtoE164

(cfg-translation-profile)# translate called 1
(cfg-translation-profile)# translate calling 1
(cfg-translation-profile)# dial-peer voice 201 voip

(config-dial-peer)# translation-profile outgoing SIPtoE164
(config-dial-peer)# exit
(config)# exit
US-CUBE# copy running-config startup-config
Destination filename [startup-config]? Press the Enter key.
Cisco dCloud
This completes the CUBE configuration. The figure below provides a visual representation of what you just configured.
CUBE Dial-Peer Diagram

5. Finally, make some test calls to the PSTN. The call will be routed to Unity Connection and you will hear a message “You have
successfully completed a PSTN call” if configured correctly. Reference the table below for numbers to dial. Note that
internationally dialed numbers will have a five second delay.
Table 74. Sample Dialed Numbers
Number
911
9911
+1 646 555 1234
9 1 646 555 1234
+49 2241 555 1234
9 011 49 2241 555 1234
Cisco dCloud
Scenario 5: Bandwidth Management

This section deploys bandwidth management for the Preferred Architecture. It covers all aspects discussed in the bandwidth
management chapter of the Preferred Architecture for Enterprise Collaboration Cisco Validated Design, including identification and
classification, WAN queuing and scheduling, provisioning, and call admission control. The only area that it does not include is
identification and classification on the switches. In this lab only identification and classification of the WAN ingress is covered.
Endpoint QoS Configuration

Endpoint QoS is configured in the Unified CM admin pages. In version 11.x this is done via the SIP Profile.
Configuration of the Jabber SIP Profile
SIP Profile specifically for all Jabber clients to use the Separate Media and Signaling Port Range value of 3000 to 3999 for audio
and 5000 to 5999 for video. The SIP signaling port of 5060 is used for SIP signaling and 5061 for secure SIP signaling. The SIP
signaling port is configured in the SIP Security Profile in Unified CM.
Jabber Endpoint QoS
Table 75. QoS Parameter Settings in SIP Profile for Jabber Endpoints
QoS Service Parameter Name (SIP Profile) Default Value Changed Value
DSCP for Audio Calls EF No Change
DSCP for Video Calls AF41 AF42
DSCP for Audio Portion of Video Calls AF41 EF
DSCP for TelePresence Calls CS4 AF41
DSCP for Audio Portion of TelePresence Calls CS4 EF
Table 76. UDP Port Settings for Jabber Endpoints
Media Port Ranges > Separate Port Range for Audio and Video Value
Audio start port 3000
Audio stop port 3999
Video start port 5000

Video stop port 5999
Cisco dCloud
For Jabber on mobile devices, we recommend copying the Standard SIP Profile for Mobile Device when building a new SIP
profile for these devices, because the default standard SIP profile for mobile devices includes recommended timer values for
maintaining Jabber registration on Android and Apple iOS devices. These timers are required for any SIP profile assigned to dual-
mode and tablet Jabber client devices.
1. Return to the tab for the Unified CM Administration page and log in if needed as administrator with password: dCloud123!.
2. Navigate to Device > Device Settings > SIP Profile and click Find.
3. Click the Copy icon [ ] next to FQDN.
NOTE: The FQDN SIP Profile was preconfigured for you based off the settings found in the Preferred Architecture CVD.
4. Configure the following settings:
Table 77. Jabber SIP Profile Settings
Setting Input
Name Jabber-QoS
Description SIP Profile for Jabber Endpoints (non-mobile)
Media Port Ranges (Parameters used in Phone section) Separate Port Ranges for Audio and Video
Start Audio Port 3000
Stop Audio Port 3999
Start Video Port 5000
Stop Video Port 5999
DSCP for Audio Calls 46 (101110 – EF)
DSCP for Video Calls 36 (100100 – AF42)
DSCP for Audio Portion of Video Calls 46 (101110 – EF)
DSCP for Telepresence Calls 34 (100010 – AF41)
DSCP for Audio Portion of Telepresence Calls 46 (101110 – EF)
5. Click Save.
Configuration of the Desktop and TelePresence SIP Profile
The SIP Profiles for all IP phones, smart desktop, and TelePresence endpoints use the common Media and Signaling Port Range
value of 17000 to 17999 for audio and video. The SIP signaling port of 5060 is used for SIP signaling and 5061 for secure SIP
signaling. The SIP signaling port is configured in the SIP Security Profile in Unified CM.
Desktop and TelePresence endpoint classification summary:
• Audio streams of all desktop and TelePresence endpoint calls (voice-only and video) are marked EF.
• Video streams of desktop and TelePresence endpoint video calls are marked AF41.
Cisco dCloud
For the desktop and TelePresence endpoints, the default QoS values and UDP port ranges must be changed in the SIP Profile as
shown in the tables below:
Table 78. QoS Parameter Settings in SIP Profile for Desktop and TelePresence Endpoints dCloud: The Cisco Demo Cloud
QoS Service Parameter Name (SIP Profile) Default Value Changed Value

DSCP for Video Calls AF41 No Change

Table 79. UDP Port Settings for Desktop and TelePresence Endpoints
Media Port Ranges > Common Port Range for Audio and Video Value
Media start port 17000
Media stop port 17999
1. Navigate back to Device > Device Settings > SIP Profile.
2. Click the Copy icon [ ] next to FQDN.
Table 80. Desktop and TelePresence SIP Profile Settings
Setting Input
Name Desktop_TelePresence-QoS
Description SIP Profile for Desktop and TelePresence Endpoints
Start Media Port (Parameters used in Phone section) 17000
Stop Media Port 17999

DSCP for Audio Calls 46 (101110 – EF)
DSCP for Video Calls 34 (100010 – AF41)
DSCP for Audio Portion of Video Calls 46 (101110 – EF)
DSCP for Telepresence Calls 34 (100010 – AF41)
DSCP for Audio Portion of Telepresence Calls 46 (101110 – EF)
4. Click Save.
Applying the SIP Profile to a device
Now you will apply the SIP profile you just created to Adam’s Jabber device.
1. Navigate to Device > Phone and click Find. Click the amckenzie device link.
2. Scroll down to the Protocol Specific Information section.
3. Change the SIP Profile setting to Jabber-QoS and then click Save and then OK.
4. Click Reset, Reset, and then Close.
Cisco dCloud
5. You can change the SIP Profile for Charles’ Jabber device as well. If you have physical endpoints, you can change the SIP
Profile for those to Desktop_TelePresence-QoS. You will not be able to test the settings in the lab, so changing these other
devices’ SIP Profile settings is optional and for practice.
Application Server QoS Configuration

Unified CM Configuration
You will configure QoS on all media originating and terminating applications and MCUs across the solution. This section covers
non-default configuration on all application servers in the PA. It is also equally important to ensure that the switch ports to which
the application servers are connected trust the QoS set by the servers. Some switches such as the Cisco Catalyst 3850 Series
trust the QoS by default so verify the switch configuration to ensure that the switch port is trusted by default or enable QoS trust.
You must change the default QoS values in Unified CM System Parameters for the CallManager service to what is shown below.
Table 81. QoS CallManager System Parameters Settings Unified CM
QoS Service Parameter Name Default Value Changed Value
DSCP for Video Calls AF41 No Change
1. In Unified CM, navigate to System > Service Parameters.
2. Choose ucm-pub.dcloud.cisco.com—CUCM Voice/Video (Active) from the Server drop-down menu.
3. For Service, choose Cisco CallManger (Active).
4. Complete a search (Ctrl+F) for qos and locate Clusterwide Parameters (System – QOS).
5. Configure the following settings: (NOTE: Click OK on the prompt after changing each setting)
Table 82. Desktop and TelePresence SIP Profile Settings
Setting Input
DSCP for Audio Portion of Video Calls 46 (101110)
DSCP for Telepresence Calls 34 (100010)
DSCP for Audio Portion of Telepresence Calls 46 (101110)
Unified CM QoS System Parameters
Cisco dCloud
6. Click Save.

Unity Connection Configuration
The default QoS values must be changed in the Unity Connection Telephony page as shown in the table below.
Table 83. QoS CallManager for Unity Connection
Differentiated Service Code Point (DSCP) value for the RTP (audio) connection 46 / EF No Change
Differentiated Service Code Point (DSCP) value for call signaling connections 24 / CS3 No Change
Differentiated Service Code Point (DSCP) value for the RTP (Video) connection 46 / EF 34 / AF41
1. Open a new Firefox tab and navigate to Collaboration Server Links > Cisco Unity Connection.
5. Click the Cisco Unity Connection link.
7. In the menu, navigate to System Settings > Advanced > Telephony.
8. Change the setting for Differentiated Services Code Point (DSCP) value for the RTP (Video) connection to 34.
9. Click Save. After a successful update message, you can close the tab to Unity Connection.
Expressway Configuration
The default QoS values must be changed in the Quality of Service page as shown in the table below.
Table 84. QoS CallManager for Unity Connection
QoS Mode None DiffServ
Tag Value 0 36
1. Go to the tab for the Expressway-C server. Log in if needed as admin with password: dCloud123!.
2. Navigate to System > Quality of Service.
3. Change the QoS Mode drop-down menu to DiffServ.
4. Enter 36 for the Tag Value and then click Save.
Expressway QoS Parameters
Cisco dCloud
5. Go to the tab for the Expressway-E server.
6. Log in if needed as admin with password: dCloud123!.

7. Navigate to System > Quality of Service.
8. Change the QoS Mode drop-down menu to DiffServ.
9. Enter 36 for the Tag Value and then click Save.
WAN Edge Identification and Classification

At the WAN edge on ingress from the enterprise to the service provider, it is expected that the packets arrive with a specific DSCP
value because the collaboration traffic has been re-marked at the access layer switch. On ingress, it is important to re-mark any
traffic at the WAN edge that could not be re-marked at the access layer, as a failsafe in case any traffic from the access switches
was trusted through the LAN or wireless LAN.
As mentioned earlier, this lab does not have an access layer switch. As such, the focus of identification and classification will be
performed on ingress into the WAN Edge router. Here you will have ACL’s that match media and call signaling for both endpoints
and servers.
In this lab, you will use the US_CUBE router configured earlier to represent the WAN edge router.
Configuration of Ingress Marking
1. On Workstation 1, open PuTTY with the Desktop icon [ ] and double click US-CUBE in the Saved Sessions list.
2. Log in as admin with Password: C1sco12345.
3. Type conf t. Each table below will have commands that you can copy and paste.
The next few sections, you will configure the ACLs to match the UDP port ranges and DSCP. The QOS_APP access lists will
match DSCP marked traffic of EF, AF41, and AF42 from Application Servers such as Expressway, UCM, Unity Connection,
TelePresence Servers, and Conductor.
The following table configures the ACL’s that match on the Application servers mentioned above.
Prompt Command
(config)# ip access-list extended QOS_APP_EF

(config-ext-nacl)# remark ACL for all UDP DSCP marked traffic from App Servers
(config-ext-nacl)# permit udp 198.18.133.0 0.0.0.255 any dscp ef
(config-ext-nacl)# ip access-list extended QOS_APP_AF41
(config-ext-nacl)# remark ACL for all af41 marked traffic from App Servers
(config-ext-nacl)# permit udp 198.18.133.0 0.0.0.255 any dscp af41
(config-ext-nacl)# ip access-list extended QOS_APP_AF42
(config-ext-nacl)# remark ACL for all af42 marked traffic from App Servers
(config-ext-nacl)# permit udp 198.18.133.0 0.0.0.255 any dscp af42
Cisco dCloud
The following table configures the ACL’s that match on the Endpoints.

Prompt Command
(config-ext-nacl)# ip access-list extended QOS_VOICE

(config-ext-nacl)# remark ACL for all ef marked traffic from ALL Endpoints
(config-ext-nacl)# permit udp any range 17000 17999 any dscp ef
(config-ext-nacl)# permit udp any range 3000 3999 any
(config-ext-nacl)# ip access-list extended QOS_PRIORITIZED_VIDEO
(config-ext-nacl)# remark ACL for all af41 traffic from ALL Desktop and Telepresence Endpoints
(config-ext-nacl)# permit udp any range 17000 17999 any dscp af41
(config-ext-nacl)# ip access-list extended QOS_JABBER_VIDEO
(config-ext-nacl)# remark ACL for all af42 marked traffic from ALL Jabber Client
(config-ext-nacl)# permit udp any range 5000 5999 any
(config-ext-nacl)# ip access-list extended QOS_SIGNALING
(config-ext-nacl)# remark ACL for all cs3 marked traffic from ALL Endpoints and Application Servers
(config-ext-nacl)# permit tcp any any range 5060 5061
(config-ext-nacl)# permit tcp any range 5060 5061 any
The following table configures the classes that match on the ACLs above.
Prompt Command
(config-ext-nacl)# class-map match-any VOICE

(config-cmap)# match access-group name QOS_APP_EF
(config-cmap)# match access-group name QOS_VOICE
(config-cmap)# class-map match-any PRIORITIZED_VIDEO
(config-cmap)# match access-group name QOS_APP_AF41
(config-cmap)# match access-group name QOS_PRIORITIZED_VIDEO
(config-cmap)# class-map match-any JABBER_VIDEO
(config-cmap)# match access-group name QOS_APP_AF42
(config-cmap)# match access-group name QOS_JABBER_VIDEO
(config-cmap)# class-map match-any SIGNALING
(config-cmap)# match access-group name QOS_SIGNALING
The following table configures the policy-map matching the classes configured above and sets DSCP for voice, video, and SIP
signaling on ingress. Note that the class-default sets everything that does not match the above to a DSCP of 0 (BE).
Prompt Command
(config-cmap)# policy-map INGRESS_MARKING
(config-pmap)# class VOICE
(config-pmap-c)# set dscp ef
(config-pmap-c)# class PRIORITIZED_VIDEO
(config- pmap-c)# set dscp af41
(config- pmap-c)# class JABBER_VIDEO
(config- pmap-c)# set dscp af42
(config- pmap-c)# class SIGNALING
(config- pmap-c)# set dscp cs3
(config- pmap-c)# class class-default
(config- pmap-c)# set dscp 0
Cisco dCloud
The following table applies the policy-map to the interface.

Prompt Command
(config-pmap-c)# interface GigabitEthernet1

(config-if)# service-policy input INGRESS_MARKING
WAN Edge Queuing and Scheduling

Configuration of Egress Queuing
This section covers interface queuing. The figure below shows the voice PQ, video CBWFQ, and WRED thresholds for CBWFQ.
Queuing and Scheduling Collaboration Media
• All audio from all endpoints marked EF is mapped to the PQ.
• Video calls and Jabber share the same CBWFQ.
– EF for audio streams of video calls from endpoints
– AF41 for video streams of video calls from endpoints
– EF for audio streams of all calls from Jabber clients
– AF42 for video streams of video calls from Jabber clients
• WRED is configured on the video queue.
– Minimum to maximum thresholds for AF42: approximately 10% to 30% of queue limit
– Minimum to maximum thresholds for AF41: approximately 45% to 100% of queue limit
Cisco dCloud
Weighted Random Early Detection (WRED) threshold minimum and maximum values are configured in the Video CBWFQ. To
illustrate how the WRED thresholds are configured, assume that the interface has been configured with a queue depth of 256
packets. Then following the guidelines above, the WRED minimum and maximum thresholds for AF42 and AF41 would be as
shown below:
Threshold Example for Video CBWFQ with WRED
The following table applies the policy-map classes to match media and signaling QoS.
Prompt Command
(config-if)# class-map match-any VIDEO

(config-cmap)# match dscp af41
(config-cmap)# match dscp af42
(config-cmap)# class-map match-any VOICE
(config-cmap)# match dscp ef
(config-cmap)# class-map match-any SIGNALING
(config-cmap)# match dscp cs3
Cisco dCloud
The following table configures for WRED in the Class-Based Weighted Fair Queue (CBWFQ) of a DS3 link (44 Mbps). For
examples of other high speed links, go to the Bandwidth Allocation Guidelines section in the PA for Enterprise Collaboration CVD.
Table 91. CUBE Commands dCloud: The Cisco Demo Cloud
Prompt Command
(config-cmap)# policy-map EGRESS-QUEUING

(config-pmap)# class VOICE
(config-pmap-c)# priority percent 10
(config-pmap-c)# class VIDEO
(config-pmap-c)# bandwidth percent 30
(config-pmap-c)# random-detect dscp-based
(config-pmap-c)# random-detect dscp 34 120 256 50
(config-pmap-c)# random-detect dscp 36 20 90 20
(config-pmap-c)# fair-queue
(config-pmap-c)# class SIGNALING
(config-pmap-c)# bandwidth percent 2
The following table applies the policy-map to the interface and saves the configuration on the router.
Prompt Command
(config-pmap-c)# interface GigabitEthernet2

(config-if)# service-policy output EGRESS-QUEUING
(config-if)# exit
(config-if)# exit
# copy running-config starting-config
Destination filename [startup-config]? Hit the Return Key
Enhanced Locations CAC
Admission control is not used in this case to manage the video bandwidth, but instead to manage the audio traffic to ensure that
the Priority Queue (PQ) is not over-subscribed. In this specific example, the Voice pool in Enhanced Locations CAC admits the
audio for both the voice-only calls and the video calls.
In Unified CM, this feature is enabled by setting the service parameter Deduct Audio Bandwidth from Audio Pool for Video Call
to True under the Call Admission Control section of the CallManager service. By default, Unified CM deducts both audio and video
streams of video calls from the video pool, because False is the default setting. This parameter changes that behavior and is key
to the QoS alterations in the Preferred Architecture.
1. Go to the Unified CM (US) Publisher Administration tab and log in if needed as administrator with Password: dCloud123!.
2. Navigate to System > Service Parameters.
3. Choose ucm-pub.dcloud.cisco.com—CUCM Voice/Video (Active) from the Server drop-down.
4. For Service, choose Cisco CallManger (Active).
5. Perform a search (Ctrl+F) for deduct audio.
6. For the Deduct Audio Bandwidth Portion form Audio Pool for a Video Call parameter, change the drop-down to True.
7. Click Save.
Cisco dCloud
The figure below illustrates the various call flows, their corresponding audio and video streams, and the queues to which the
streams are directed.
Provisioning and Admission Control dCloud: The Cisco Demo Cloud
Region and Device Pool Configuration
Administrators group video endpoints into classes of maximum video bit rate to limit bandwidth consumption based on endpoint
type and usage within the solution. Three regions are required in total (see table below), and three device pools are required per
site. This applies to a configuration where a single audio codec of G.722 is used across the entire organization, both LAN and
WAN.
Table 93. Example Region Matric for Three Groups
Endpoint Groupings Video_1.5MB Video_2.5MB Video_20MB
Video_1.5MB 1,500 kbps 1,500 kbps 1,500 kbps
Video_2.5MB 1,500 kbps 2,500 kbps 2,500 kbps
Video_20MB 1,500 kbps 2,500 kbps 20,000 kbps
1. Navigate to System > Region Information > Region and click Find.
2. Click the Default link.
3. In the Name* box, enter the new name of Video_20MB.
4. In the Regions box, within the Modify Relationships to other Regions, choose Default.
Cisco dCloud
5. In the Maximum Session Bit Rate for Video Calls column, click the button next to the empty box and enter 20000 in the box.
Video_20MB Region Configuration

6. Click Save and then click OK.
7. Click Add New.
8. Enter Video_2.5MB for the Name and then click Save.
9. In the Regions box, choose Video_2.5MB and Video_20MB using the Shift or Ctrl key and clicking the names.
10. In the Maximum Session Bit Rate for Video Calls column, click the button next to the empty box and enter 2500 in the box.
Video_2.5MB Region Configuration
Cisco dCloud
11. Click Save.
12. Click Add New.

13. Enter Video_1.5MB for the Name and then click Save.
14. In the Regions box, choose Video_1.5MB, Video_2.5MB, and Video_20MB.
15. In the Maximum Session Bit Rate for Video Calls column, click the radio button next to the empty box and then enter 1500
inside the box.
Video_1.5MB Region Configuration
16. Click Save.
Now that you have the three regions created, you will create device pools to match these regions.
17. Navigate to System > Device Pool and click Find.
You should have a Device Pool for each site and one for Conferencing and another for Trunks and Apps. You will setup just the
device pools for the RCD site in this lab. However, in a production environment you would create three devices pools for every site.
18. Click on the RCDPhoneVideo link.
19. In the Device Pool Name* box, enter RCDPhoneVideo_20MB and click Save.
20. After the save, click Copy.
21. Change the Device Pool Name* to RCDPhoneVideo_2.5MB.
Cisco dCloud
22. For the Region setting, choose Video_2.5MB from the drop-down menu.
2.5MB Device Pool Configuration

23. Click Save.
24. After the save, click Copy.
25. Change the Device Pool Name* to RCDPhoneVideo_1.5MB.
26. For the Region setting, choose Video_1.5MB from the drop-down menu.
27. Click Save.
You have completed the device pool configurations for the RCD site. As mentioned earlier, in production you would complete this
configuration for every site, however to save time it is not required to configure the other sites’ device pools in this lab. You will now
move on to the locations configuration.
Cisco dCloud
Location Configuration
Next, you will configure five locations and create a link between them. In this lab, there are two regional clusters, one in the US and
one in EMEA. Each cluster is connected to an MPLS network within the region. The link between the SJC site and the BER site will
be created so the two clusters can share information. Below is the diagram of the topology you are creating. The first image
illustrates the network topology that is being modeled with Locations and Links, while the second one below that illustrates the
Locations and Links topology that maps to the physical WAN topology above it.
Lab Network Topology/Locations and Links
The first step is to start the Cisco Location Bandwidth Manager Service on every node that is running the Cisco CallManager
service. To save time, this was completed for you on the Publisher and Subscriber in the US cluster as well as the Publisher server
in EMEA. Next, you will configure the locations. Remember to limit video calling based only in areas of the network where
bandwidth resources are restricted beyond AF41 marked traffic; otherwise, video bandwidth in the Location links should be
unlimited.
1. Within Unified CM navigate to System > Location Info > Location and click Find
2. Click the Hub_None link.
3. Change the name from Hub_None to RCD and click Save.
4. Click Add New.
5. For Name, enter MPLS_US.
6. For Audio Bandwidth, click the radio button next to the box for kbps and enter 1500.
Cisco dCloud
7. Click the radio button next to Unlimited for both the Video Bandwidth and Immersive Video Bandwidth options.
MPLS_US Location Settings

8. Click Save.
9. Click Add New.
10. Enter RTP for the name.
11. In the Links box, choose MPLS_US.
RTP Location Settings
Cisco dCloud
14. Click Save.
15. Click Add New.

16. Enter SJC for the name.
17. In the Links box, choose MPLS_US.
20. Click Save.
Now that you have the four locations created for the US, you can create a site for the EMEA cluster in order to link the two clusters
together to share information. The EMEA cluster already has locations configured.
21. Click Add New.
22. Enter BER for the name.
23. In the Links box, choose RTP.
26. Click Save.
27. Click Go next to the Related Links drop-down. You should see the new locations for BER, MPLS_US, RCD, RTP, and SJC.
Now you need to assign the locations to their respective device pools.
28. Navigate to System > Device Pool.
29. Click on the RCDPhoneVideo_1.5MB link.
30. Under Roaming Sensitive Settings, choose RCD for the Location setting, and then click Save.
RCDPhoneVideo_1.5MB Device Pool Settings
31. Click Go next to the Related Links drop-down menu.
32. Update the location setting for the rest of the device pools as shown in the table below.
Table 94. Device Pool Location Settings
Device Pool Location Setting
RCDPhoneVideo_2.5MB RCD
RCDPhoneVideo_20MB RCD
RTPPhoneVideo RTP
SJCPhoneVideo SJC
Cisco dCloud
Configuration of the Location Bandwidth Manager (LBM) Intercluster Replication Group
The last task is configure the LBM Intercluster Replication Group. An LBM Intercluster Replication Group enables an LBM service
to participate either directly or indirectly in an Intercluster replication of configured and dynamic Location Bandwidth data. LBMs
assigned an LBM hub role participate directory in Intercluster replication of Location Bandwidth data. LBM hubs discover each
other through their common connections and form a fully meshed replication network. LBMs assigned a spoke role participate
indirectly in Intercluster replication through the LBM hubs in their cluster.
The lab environment is very small and only consists of a few servers. Most likely your cluster configuration will be much larger.
Follow the guidelines under the Intercluster Configuration section in the Preferred Architecture CVD when setting up your
production network. The lab guide will give you the steps necessary to start the replication between the two clusters in the lab.
Also, note that part of the configuration is to make sure the Cluster ID is unique in all clusters. This has been completed for you
already in the lab. The configuration is located in System > Enterprise Parameters.
1. In Unified CM, navigate to System > Location Info > Location Bandwidth Manager (LBM) Intercluster Replication Group.
2. Click Add New.
3. For Name, enter LBM_Replication_Group.
4. Under Bootstrap Servers in the Server 1 box, enter ucm1-pub.dcloud.cisco.com.
For this lab, the EMEAR publisher is the bootstrap server. For redundancy, you can define up to three hub servers as bootstrap
servers. The bootstrap servers are responsible for informing the hub network of the LBM hub servers. Any hub in the network can
act as a bootstrap server.
Next, you will assign the subscriber as the hub for the US cluster and leave the publisher as a spoke.
5. Choose ucm-sub1.dcloud.cisco.com from the LBM Services not Assigned to Hub Role box.
6. Click the up arrow [ ] to move the ucm-sub into the LBM Services Assigned to Hub Role box.
LBM Intercluster Replication Group Configuration
Cisco dCloud
7. Click Save.
You can now verify that location information is passing between the US and EMEA clusters by going to the serviceability page.
8. In the Navigation drop-down menu, choose Cisco Unified Serviceability and click Go.
9. Navigate to Tools > Locations > Topology and click Find.
In the search results, you should see locations you configured on the US cluster as well as the locations that were pre-configured
on the EMEA cluster. You can expand each location to get more information. If the sites from the EMEA cluster (BER, FCO, AMS,
and MPLS_EMEA) are not listed, wait a few minutes for the clusters to synchronize.
Deploy Device Mobility for Mobile and Remote Access (MRA)
The figure below illustrates an overview of the device mobility configuration. Although this is a minimum configuration requirement
for Device Mobility for ELCAC to function for Internet-based devices, Device Mobility can be configured to support mobility for
these same endpoints within the enterprise. See the Cisco Collaboration SRND for more information on Device Mobility for devices
within the enterprise.
Device Mobility Configuration and Location Association
The figure above shows a simplified version of device mobility for the example deployment of ELCAC. The IP addresses of the
Expressway-C servers are configured in the device mobility information. In this example, there is a redundant pair of Expressway-
C servers for each of the three sites: RTP, BLD, and SJC. RTP_EXP1_DMI and RTP_EXP2_DMI are configured with the server IP
addresses of the RTP Expressway-C servers. These two are associated to a new device pool called RTP_EXP_DP, which has the
location RTP configured on it. Each site is configured similarly. With this configuration, when any device enabled for device mobility
registers to Unified CM with the IP address that corresponds to the device mobility information in RTP_EXP1_DMI or
RTP_EXP2_DMI, it will be associated with the RTP_EXP_DP device pool and thus with the RTP location.
Cisco dCloud
With the above configuration, when an Internet-based device registers through the Expressway to Unified CM, it will register with
the IP address of Expressway-C. Unified CM then uses the IP address configured in the device mobility information and associates
the device pool and thus the Internet location associated to this device pool. This process is illustrated in the figure below.
Device Mobility Configuration and Location Association
In the figure above, the client registers with Unified CM through the Expressway in RTP. Because the signaling is translated at the
Expressway-C server in RTP, the device registers with the IP address of that Expressway-C. The device pool RTP_EXP_DP is
associated to the device based on this IP address. The RTP_EXP_DP pool is configured with the RTP location, and therefore that
location is associated to the device. Thus, when devices register to the Expressway, they get the correct location association
through device mobility. When the endpoint relocates to the enterprise, it will return to its static location configuration. In addition, if
the endpoint relocates to another Expressway server in SJC, for example, it will get the correct location association through device
mobility.
Configure Device Mobility Information (DMI) for Expressway-Cs:
• Create two DMIs per Expressway-C group (two Expressway-C nodes in a pair)
• Add the IP address of the Expressway-C node in a subnet with a mask of 32 bits (this matches the IP address exactly)
• Add the site device pool to the respective DMIs. This is the device pool of the site where the Expressway pairs are located,
which should contain the correct region and location
In this lab, there is only one Expressway-C server so you will configure only one DMI.
1. Return to the Cisco Unified CM Administration page.
2. Navigate to System > Device Mobility > Device Mobility Info and click Add New.
Cisco dCloud
Table 95. RCD DMI Info Configuration

Setting Input
Name RCD_EXP1_DMI
Subnet 198.18.133.152
Subnet Mask (bit size) 32
4. From the Available Device Pools box, choose RCDPhoneVideo_1.5MB and use the down arrow [ ] to move it to the
Selected Device Pools box.
RCD DMI Info Configuration
In order to use device mobility it needs to be enabled. This can be set on each device individually, using the Bulk Administration
Tool, or it can be set globally in the Service Parameters for the Cisco CallManager service. The setting for Device Mobility Mode
should be set to On. It is turned off by default. In this lab, device mobility has been turned on in the service parameters.
Cisco dCloud
Scenario 6: Security
Configure Secure Connection between Unified CM and the Enterprise LDAP Directory dCloud: The Cisco Demo Cloud
Now that you completed Unified CM tomcat and CallManager certificate signing and uploaded these certificates and the enterprise
CA root certificate to the appropriate Unified CM trust store, you will secure the connection between Unified CM and the enterprise
LDAP directory. This ensures traffic between Unified CM and the Active Directory (ad1.dcloud.cisco.com) is encrypted using TLS.
1. Browse to the Unified CM Administration portal at https://ucm-pub.dcloud.cisco.com/ccmadmin/) and login as administrator

with password: dCloud123!.
2. Navigate to System > LDAP > LDAP Directory and click the Find button load the LDAP directory list.
3. Click on Local (LDAP Configuration Name) to bring up the configuration page, scroll to the bottom of the page, and check the
‘Use TLS’ checkbox. Change the ‘LDAP Port’ field from the default 389 to 636 as shown below.
4. Click Save and then Perform Full Sync Now. Click OK to acknowledge the LDAP sync warning and initiate the sync.
Securing the LDAP Directory Connection with TLS
Cisco dCloud
Unified CM is now communicating securely with the LDAP directory (ad1.dcloud.cisco.com / 198.18.133.1) and is able to validate
the certificate from Active Directory because it is signed by the Enterprise CA (dcloud-AD1-CA) and you already loaded the
Enterprise CA root certificate to the tomcat-trust trust store.
5. Next, configure the same thing to secure LDAP authentication with TLS by navigating to System > LDAP > LDAP
Authentication. Check the Use TLS checkbox and change the ‘LDAP Port’ field from the default 389 to 636. Click Save.
Securing Authentication Connections between Unified CM LDAP Directory with TLS
Now when end users authenticate against the LDAP server, the authentication traffic is encrypted between Unified CM and the
LDAP directory.
Unified CM Certificate Authority Proxy Function (CAPF) Enrollment for Hardware Endpoints
In preparation, for enabling secure calling with encrypted media and signaling, you will Certificate Authority Proxy Function (CAPF)
enroll the desk phones in this section. This process generates and installs LSC certificates on the phones. Begin by activating and
starting the CAPF service and then setting the phones for CAPF enrollment. Finally, confirm CAPF enrollment is successful for the
hardware endpoints.
Activate and Start CAPF
1. On Workstation 1, using Firefox, go to the Unified CM Serviceability portal at https://ucm-pub.dcloud.cisco.com/ccmservice/

and log in (if required) as administrator with password: dCloud123!.
Cisco dCloud
2. Navigate to Tools > Service Activation and in the Select a Server drop down, choose ucm-pub.dcloud.cisco.com. Click
Go and then scroll down to the Security Services section.
3. Check the box next to Cisco Certificate Authority Proxy Function and then click Save to activate and startThe
dCloud: theCisco
CAPFDemo Cloud
service. Click OK when prompted to proceed.
Activating Cisco Certificate Authority Proxy Function (CAPF)
4. When activation is complete, you will see the message “Update Operation Successful”. Confirm the service has started by
navigating to Tools > Control Center – Feature Services and in the Select a Server drop down, choose ucm-
pub.dcloud.cisco.com. Click Go and then ensure the Cisco Certificate Authority Proxy Function service has a status of
Started and the Activation Status is Activated as shown in the Figure below.
Certificate Authority Proxy Function (CAPF) Service Activated and Started
5. After confirming that the Cisco Certificate Authority Proxy Function service has started, restart the TFTP. Do this by
clicking the Cisco TFTP radio button on the same page and clicking Restart. Click OK to confirm restart.
NOTE: After restarting the TFTP service, the CAPF certificate is added to the ITL file. The endpoints do not automatically
download the new ITL file. In the next step, when you configure the devices for CAPF enrollment and apply the new configuration,
the phones will restart and download the new ITL file.
6. Proceed to the next step while the TFTP service is restarting.
Configure Hardware Endpoints (88x5 and DX) for CAPF Enrollment via MIC Authentication (88x5) and Authentication
String (DX) and Confirm LSC Install Indicating Successful CAPF Enrollment
The hardware endpoints and clients must have a certificate to enable secure encrypted calling. While you can use the factory
installed manufacturing certificate (MIC) of the hardware endpoints for authentication and encryption, this is not recommended.
MICs pose a security risk given that a common Certificate Authority (CA) is used across all manufactured Cisco phones. Further,
MICs are only valid for 10 years from manufacturing date and they cannot be renewed, customized, updated, revoked, or deleted.
Finally, Cisco software clients such as Jabber and some Cisco hardware endpoints do not have/expose a MIC. A Cisco DX running
CE is an example of this.
Cisco dCloud
For these reasons, Cisco’s best practice is to rely on a locally significant certificate (LSC). To install LSCs on the endpoints,
perform CAPF enrollment for the devices. Since the CAPF service was started in the previous step, proceed to CAPF enrollment.
First, verify that the desk phones do not already have LSCs by looking at the security settings information on the phone:
7. On the 88x5, Press (Settings) > Admin settings > Security setup. Note that LSC is “Not installed” as shown below.
88x5 Security Setup Information
Now begin the enrollment process.
8. From the Firefox web browser on Workstation 1 (198.18.133.36), log in to the Unified CM Administration interface (https://ucm-
pub.dcloud.cisco.com/ccmadmin/) as administrator with password: dCloud123!.
9. Navigate to Device > Phone. Locate the two desk phones by searching for devices that “begin with” SEP.
Finding Desk Phones for CAPF Enrollment
NOTE: The device Name/MAC addresses of the endpoint and the endpoint model) may be different than shown above.
Cisco dCloud
10. Choose the 88x5 device and on the configuration page, under the Certification Authority Proxy Function (CAPF) Information,
choose Install/Upgrade in the Certificate Operation drop down. Specify a future date in the “Operation Completes By” fields.
CAPF Enrollment Settings for the 88x5 Endpoint dCloud: The Cisco Demo Cloud
NOTE: Depending on the date of this session, the default Operation Completes By and configured values may be different from
those shown above.
11. Finally, click . Click OK and then click . Click OK to apply the configuration changes. The 88x5 will
restart and re-register after the CAPF enrollment is complete.
NOTE: Setting By Existing Certificate (precedence to LSC) as the CAPF “Authentication Mode” for endpoint CAPF enrollment is
preferred because it generally applies to the largest number of devices.
With this setting, if an endpoint has only a MIC certificate, this certificate is used for authentication to CAPF. If the endpoint has an
LSC certificate (whether or not the endpoint also has a MIC), then the LSC certificate is used instead for authentication to CAPF.
This is a good general setting for most hardware endpoints for both the initial enrollment and then subsequent CAPF operations.
For those endpoints that do not have a MIC, such as the DX running CE firmware and Cisco Jabber clients, you must authenticate
the CAPF server during initial CAPF enrollment using either the By Authentication String or By Null String (no authentication)
modes. After initial enrollment, By Existing Certificate (precedence to LSC) mode may be used for all subsequent CAPF
operations.
Next, CAPF enroll the DX with similar settings. Since DX endpoints running CE code do not expose the MIC, use CAPF
Authentication Mode for DX enrollment with an authentication string.
12. Go to Device > Phone and choose your DX device. On the configuration page, under the Certification Authority Proxy
Function (CAPF) Information, choose Install/Upgrade from the Certificate Operation drop down.
Cisco dCloud
13. First, choose By Authentication String from the Authentication Mode drop down. Next, enter 12345 in the Authentication
String field and specify some date in the future for the Operation Completes By fields.
CAPF Enrollment Settings for the DX Endpoint dCloud: The Cisco Demo Cloud
NOTE: The default Operation Completes By and configured values may be different from those shown above.
14. Click . Click OK and then click . Click OK to apply the configuration changes.
15. The DX endpoint displays a Cisco UCM Authentication dialog on screen. Enter Authentication String 12345 in the PIN code
field on the DX endpoint screen. Touch OK and the DX will complete CAPF enrollment and re-register to Unified CM.
NOTE: You may ignore the reference to the “10 digit PIN code required by Cisco UCM” this is a cosmetic issue. The 5-digit PIN
(12345) we configured previously will work fine.
Once both phones have completed CAPF enrollment and re-registered to Unified CM, verify that CAPF enrollment was successful
and that the hardware endpoints now have LSCs installed. You can verify the endpoints have successfully enrolled with CAPF and
received an LSC by looking at the security settings information on the endpoints:
16. On the 88x5, press (Settings) > Admin settings > Security setup. Note the LSC is now “Installed” as shown below.
88x5 LSC Installed
Cisco dCloud
17. For the DX, go to the endpoint web interface using the IP address http://<Endpoint_IP_Address>/. Log in as admin with
password: <blank>. Once logged in, go to Setup > Status > Provisioning and note that an LSC is installed on the endpoint.
DX LSC Installed dCloud: The Cisco Demo Cloud
Cisco dCloud
You can also view the 88x5 phone status log to confirm that the LSC was updated/installed by navigating as follows:
18. On the 88x5, press (Settings) > Admin settings > Status > Status messages.
88x5 Phone Status Messages
NOTE: The MAC address and status message sequence on your phone may be different than shown above.
An easy way to monitor the status of CAPF enrollments for multiple endpoints is to search for endpoints based on the status or
issuer of the LSC (if present).
19. On Unified CM (https://ucm-pub.dcloud.cisco.com/ccmadmin/), navigate to Devices > Phone, do a search where (‘Find phone
where…’) ‘Device Name’ ‘begins with’ SEP and ‘LSC Issued By’ ‘begins with’ is blank and click Find to search for the LSC
issuer of hardware endpoints on the system.
As shown below, the endpoints show an LSC Status of Upgrade Success.
Unified CM Device Search Based Device Name and LSC Issuer
NOTE: The device names/MAC addresses may be different from the ones shown above.
Cisco dCloud
NOTE: You can confirm that the CAPF operation was successful by returning to the phone configuration page on the Unified CM
Administration interface (Devices > Phone). After choosing one of the phones, scroll down to the Certification Authority Proxy
Function (CAPF) Information section and confirm the CAPF Operation Status is “Upgrade Success” as shown below:
NOTE: Because the 88x5 and DX endpoints support the Initial Trust List (ITL), CAPF enrollment can be done while the Unified CM
cluster is in non-secure mode. On the other hand, Jabber clients DO NOT support the ITL and as such during CAPF enrollment
cannot verify the identity of the CAPF server. In order to CAPF enroll the Jabber client, it requires a Certificate Trust List (CTL),
which will not be available until you move the Unified CM cluster into mixed-mode in the next section.
Move Unified CM Cluster to Mixed-Mode via CLI (soft e-Token) Method
In this section, you move the Unified CM cluster from non-secure to mixed-mode, a prerequisite for enabling encrypted calling. You
will use the Unified CM CLI soft e-Token method (also referred to as Tokenless) to move the cluster to mixed-mode. After moving
to mixed-mode, you will confirm the operation and ensure that the desk phones download the new Certificate Trust List (CTL) file.
Move the Unified CM cluster to mixed-mode using the system CLI
1. SSH to the Unified CM (ucm-pub.dcloud.cisco.com) command line interface by using Putty on Workstation 1 (198.18.133.36).
2. Double-click the PuTTY icon. Enter ucm-pub.dcloud.cisco.com in the “Host Name (or IP Address)” field. Click Open.
4. At the command line prompt, verify there is no CTL file with the command show ctl. This confirms that the Unified CM cluster
is in non-secure mode. A CTL file would be present if the cluster was in mixed-mode.
Unified CM CLI – Show CTL on Non-Secure Cluster
5. Enter the utils ctl set-cluster mixed-mode command on the CLI and press enter to move the cluster to mixed-mode. Confirm
that you want to continue by typing ‘y’ and pressing enter.
NOTE: If the console is unresponsive, you may need to press Ctrl-C to cancel the command and re-enter the command again.
Unified CM CLI – Utils CTL Set-Cluster Mixed-Mode
Cisco dCloud
6. Re-run the show ctl command to confirm the CTL file is now present.
Unified CM CLI – Show CTL on Mixed-Mode Cluster

NOTE: The checksum, serial numbers, and other values of the CTL file on your system may be different from the ones shown
above.
7. Enter exit command on the CLI to clear the SSH session and close the Putty client.
Verify cluster has moved to mixed-mode and that the desk phones have downloaded the new CTL.
8. Return to the Firefox web browser on Workstation 1 (198.18.133.36) and browse to the Unified CM Administration interface at
https://ucm-pub.dcloud.cisco.com/ccmadmin.
10. Navigate to System > Enterprise Parameters, scroll down to the Security Parameters area and verify whether the cluster
was set to mixed-mode. A value of 1 indicates mixed-mode.
Unified CM Cluster Security Mode
11. Next, restart TFTP and CallManager services. Browse to the Unified CM Serviceability portal at https://ucm-
pub.dcloud.cisco.com/ccmservice/ and log in as administrator with password: dCloud123!.
Cisco dCloud
12. Go to Tools > Control Center – Feature Services and select ucm-pub.dcloud.cisco.com -- CUCM Voice/Video from the
Server dropdown, then click the Cisco TFTP radio button and click Restart. Click OK to confirm.
13. After the TFTP service restarts and you see the message “Cisco Tftp Service Restart Operation was Successful”, click
dCloud: The Cisco theCloud
Demo
Cisco CallManager radio button and click Restart. Click OK to confirm restart.
NOTE: In the Enterprise PA, the TFTP and CallManager services are not activated on the publisher. Best practice
recommendation is to have dedicated redundant TFTP service nodes and to run CallManager services on dedicated Subscriber
nodes. In this lab, for ease of use we have two Unified CM cluster nodes so all required services are running on both nodes
including TFTP and CallManager.
14. Repeat the Cisco TFTP and Cisco CallManager service restart operation for the Unified CM subscriber cluster node (ucm-
sub1). From Tools > Control Center – Feature Services, choose ucm-sub1.dcloud.cisco.com -- CUCM Voice/Video from
the Server drop down and then restart both services.
The subscriber node Cisco CallManager service restarts, then desk phones reset and re-register after they download the new CTL.
Next, confirm that both phones now have a CTL file by viewing the phone status logs.
15. On the 88x5, press (Settings) > Admin settings > Status > Status messages. You should see the output below:
88x5 Status Message – CTL Installed
NOTE: The MAC address and status message sequence on your phone may be different than shown above. Also, you may need
to scroll down in the status messages window to see the “CTL and ITL installed” message.
16. You can also view the CTL file on the 88x5 endpoint by navigating to (Settings) > Admin settings > Security > Trust
List > CTL and examining the CTL file as shown in the figure below:
88x5 CTL Trust List
Cisco dCloud
NOTE: The CTL signature and CAPF server name shown above may be different on your phone.
17. On the DX, navigate to the endpoint web interface using the endpoint IP address http://<Endpoint_IP_Address>/. If prompted,
log in as the default username admin with password: <blank>.
18. Navigate to Security > CUCM Certificates and note that as shown below the CTL is installed on the endpoint.
DX: CUCM Certificates – CTL Installed
NOTE: The fingerprint, serial numbers, and other values of the CTL file on your DX may be different from the ones shown above.
Cisco dCloud
19. As shown in the figure below, you can also review CTL information and file contents on the page at Setup > Security >
CUCM Certificates.
DX – CTL File Content dCloud: The Cisco Demo Cloud
NOTE: The fingerprint, serial numbers, and other values of the CTL file on your DX may be different from the ones shown above.
Unified CM CAPF Enrollment for Jabber Client
With the Unified CM cluster now in mixed-mode, a Certificate Trust List (CTL) is available which allows us to CAPF enroll the on-
premise Jabber client (Workstation 2 – CHOLLAND). After CAPF enrollment for the Jabber client is complete, confirm that the
operation was successful.
Configure On-premise Jabber Client (CHOLLAND) for CAPF Enrollment and Confirm Enrollment via Authentication String.
NOTE: Before proceeding, ensure that Jabber for Windows (CHOLLAND) on Workstation 2 (198.18.133.37) is not running.
1. From the Unified CM Administration interface (https://ucm-pub.dcloud.cisco.com/ccmadmin/), navigate to Device > Phone
and choose Charles Holland CSF device: CHOLLAND.
NOTE: You may need to clear previous search filters in order to get the Jabber (CSF) devices to display.
2. On the configuration page, choose Universal Device Template - Model-independent Security Profile from the “Device
Security Profile” drop down under the Protocol Specific Information. This automatically configures the Authentication Mode,
Key Order and RSA Key Size settings under the Certification Authority Proxy Function (CAPF) Information section.
Authentication Mode is set to By Authentication String, Key Order is set to RSA Only, and RSA Key Size is set to 2048.
Cisco dCloud
3. Next, choose Install/Upgrade from the “Certificate Operation” drop down, choose By Authentication String in the
Authentication Mode, enter 12345 in the “Authentication String” field, and specify some date in the future for the “Operation
Completes By” fields.
Configuring CAPF Enrollment with Authorization String for On-Premise Jabber for Windows Client (WKST2)
4. Click . Click OK on the next dialog and then click to enable the CAPF enrollment for the on-premise
Jabber client. Click OK to apply the configuration changes.
5. On Workstation 2 (198.18.133.37), start Jabber, log in as cholland with password: C1sco12345. You should see a pop-up
window that prompts for the authorization string. Enter the authorization string specified previously: 12345. Click OK.
Cisco dCloud
6. The Jabber IP phone service will not connect until after the user has entered the authentication string and the CAPF
enrollment operation has completed.
CAPF Enrollment with Authentication String – Jabber for Windows dCloud: The Cisco Demo Cloud
7. Verify that the Jabber client registers correctly. You should see the icon . Alternatively, under the Connection status
at Settings ( ) Help > Show Connection Status, the Softphone status should show connected.
As before, you can also confirm that the CAPF enrollment for the on-premise Jabber client was successful by searching for
endpoints based on the LSC issuer.
8. Navigate to Unified CM Administration interface at https://ucm-pub.dcloud.cisco.com/ccmadmin/ and go to Devices > Phone,

then choose LSC Issued By from the “Find phone where” dropdown menu.
Cisco dCloud
9. Click Find to search for the LSC issuer of all endpoints certificates on the system. As shown below, the on-premise Jabber
client (CHOLLAND) has successfully completed CAPF enrollment and now has an LSC, just like the desk phones.
Unified CM Device Search Based on LSC Issued By dCloud: The Cisco Demo Cloud
NOTE: The device names/MAC addresses may be different from the ones shown above.
At this point, all on premise devices are provisioned, have completed the CAPF enrollment, and have an LSC installed. Further, the
cluster is now in mixed-mode. You are now ready to enable and test secure encrypted calling.
10. Before proceeding, shutdown Jabber for Windows by clicking Settings ( ) > Exit in preparation for tasks later in this lab.
Create Secure Phone Security Profile and Apply to On-Premise Endpoints
The final step for enabling and configuring secure encrypted calling is to enable the endpoints for secure calling. You will create a
set of Phone Security Profiles based on the Universal Device Template - Model-independent Security Profile with encrypted
configuration and calling enabled. Then you will apply the appropriate profiles to the endpoints and Jabber client (CHOLLAND).
Create Encrypted Phone Security Profiles
As documented in the Security chapter of the Cisco Preferred Architecture for Enterprise Collaboration CVD
(http://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/116/collbcvd/security.html), there are four
recommended device security profiles. These should be configured on the system. Table 4 below lists the recommended profiles
Table 96. Enterprise Collaboration PA Recommended Secure Phone Security Profiles
TFTP Encrypted Authentication Mode for

Phone Security Profile Name1 Device Security Mode
Config CAPF Enrollment
UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com2 Encrypted Enabled By Existing Certificate (precedence to LSC)

3
UDT-Encrypted-LSC.dcloud.cisco.com Encrypted Disabled By Existing Certificate (precedence to LSC)
UDT-Encrypted-NullString.dcloud.cisco.com3 Encrypted Disabled By Null String
UDT-Encrypted-AuthString.dcloud.cisco.com Encrypted Disabled By Authentication String

1 All profiles are based on the ‘Universal Device Template - Model-independent Security Profile’
2 The domain portion of these security profiles (dcloud.cisco.com) matches the domain of our system.
3 These profiles have already been pre-configured for you.
1. Browse to the Unified CM Administration interface (https://ucm-pub.dcloud.cisco.com/ccmadmin/) from the Firefox web
browser on Workstation 1 (198.18.133.36).
Cisco dCloud
2. Navigate to System > Security > Phone Security Profile and perform search:” Name” “begins with”, enter “UDT”; click Find.
Phone Security Profiles: UDT

Notice that two of the PA recommended Phone Security Profiles listed in the Table above have already been configured for us:
UDT-Encrypted-NullString.dcloud.cisco.com and UDT-Encrypted-LSC.dcloud.cisco.com.
3. Click (Copy) next to the UDT-Encrypted-LSC.dcloud.cisco.com profile to create a copy. Rename the profile UDT-
Encrypted-LSC-TFTPenc.dcloud.cisco.com, change the Description field to UDT Encrypted Profile with LSC auth mode
and TFTP encryption, leave Encrypted selected for the Device Security Mode and check the TFTP Encrypted Config.
Leave By Existing Certificate (precedence to LSC) selected in the Authentication Mode drop down. Leave the rest of the
settings at default values. Note that since you have already CAPF enrolled ther endpoints, the CAPF settings of the profile will
have no impact unless or until a new CAPF operation is performed.
UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com Phone Security Profile
4. Click .
Cisco dCloud
5. Return to the Phone Security Profile list and click (Copy) next to the UDT-Encrypted-NullString.dcloud.cisco.com
profile to create a copy. Rename the profile UDT-Encrypted-AuthString.dcloud.cisco.com, change the Description field to
dCloud:
UDT Encrypted Profile with AuthString auth mode, leave Encrypted selected for the Device Security The Cisco
Mode, chooseDemo
ByCloud
Authentication String from the Authentication Mode drop down. Leave the rest of the settings at default values.
UDT-Encrypted-AuthString Phone Security Profile
6. Click .
7. Return to the Phone Security Profile list and confirm all of the Phone Security Profiles have been configured as shown below.
Phone Security Profiles: All Preferred Architecture Recommended UDTs
Cisco dCloud
Apply Encrypted Phone Security Profile to Hardware Endpoints (88x5 and DX) and Workstation 2 Jabber client
(CHOLLAND)
Next, you will apply the encrypted phone security profiles to the endpoints. Because you have configured security profiles based
on the universal device profile, you can apply the appropriate encrypted security profile to all the on-premise devices.
1. Go to Device > Phone and choose the 88x5 hardware endpoint. Under Protocol Specific Information in the Device Security
Profile field, choose the encrypted security profile UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com that you just created.
Applying the UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com Device Security Profile to Hardware Endpoints
2. Click . Click OK and then click . Click OK to apply the configuration changes. The 88x5 endpoint will
re-register in encrypted phone mode.
You will repeat this procedure for the DX endpoint; however, besides changing the Device Security Profile, you will also begin
managing the web interface administrative credentials from the Unified CM device configuration page. Since you are enabling
encrypted TFTP configuration files you no longer have to worry about the web interface admin account credentials being readable
in the TFTP configuration file.
Cisco dCloud
3. On the DX configuration page, after setting the Device Security Profile to UDT-Encrypted-LSC-TFTPenc.dcloud.cisco.com,
scroll down to the Product Specific Configuration Layout section. Under the Admin username and password area, enter admin
in the ‘Admin Username’ field and enter dCloud123! In the ‘Admin Password’ field.
Setting DX Web Interface Admin Username and Password
4. Click . Click OK and then click . Click OK to apply the configuration changes.
Once both desk phones are enabled for encryption and re-registered to Unified CM, confirm that the phones are running in
“Encrypted” mode:
5. On the 88x5, navigate to (Settings) > Admin settings > Security setup.
88x5 Encrypted Security Mode
Cisco dCloud
6. On the DX, navigate to the DX endpoint web interface using the endpoint IP address http://<Endpoint_IP_Address>/. If
prompted, log in with the configured Admin username and password. Once logged in, navigate to Setup > Status >
Provisioning and note that the Provision Security field indicates Encrypted indicating the endpoint is in secure mode.
DX70 Encrypted Security Mode
NOTE: The IP address of your DX may be different than shown above.
Cisco dCloud
You should also confirm that the phones have downloaded encrypted configuration files by reviewing status messages:
7. On the 88x5, navigate to (Settings) > Admin settings > Status > Status messages.
88x5 Encrypted Configuration File (xml.enc.sgn)
NOTE: The MAC address and status message sequence on your phone may be different than shown above.
NOTE: You may need to scroll down in the status messages window to see the encrypted configuration” message
The .enc.sgn portion of the configuration file name shown in the status message indicates that Unified CM signed the file (.sgn)
and that the file is encrypted (.enc).
NOTE: Before proceeding, ensure that the Jabber for Windows client (CHOLLAND) on Workstation 2 (198.18.133.37) is not
running.
8. Finally, you will assign the appropriate encrypted universal device security profile to our on-premise Jabber client. Return to
the device list under Device > Phone and choose CHOLLAND.
Cisco dCloud
9. Choose UDT-Encrypted-LSC.dcloud.cisco.com as the Device Security Profile.
Applying the UDT-Encrypted-LSC Device Security Profile to On-Premise Jabber Client (CSFMCHENG)
This is an encrypted device security profile without TFTP configuration file encryption and ensures the Jabber client can be
registered both when on-premise and if connected over Expressway Mobile and Remote Access.
Encrypted TFTP configuration is not supported over Expressway Mobile and Remote Access. If the Jabber client will always be
registered on-premise (or via VPN), then you would choose the same security profile used for the hardware endpoints earlier UDT-
Encrypted-LSC-TFTPenc.dcloud.cisco.com.
10. Click . Click OK and then click . Click OK to apply the configuration changes to the Jabber client
(CHOLLAND).
You will confirm that Jabber is in secure mode when we make secure calls in the next section.
Confirm Secure Calling (Phone to Phone, Jabber to Phone)
Confirm that you have properly configured secure encrypted calling by making a set of calls and verifying the encrypted “lock” icon
is shown at each endpoint.
Place a call between the desk phones and confirm the encrypted “lock” icon is present
1. Place a call from Anita Perez’s 88x5 to Charles Holland’s DX by dialing +19725555016
Cisco dCloud
2. Answer the call at the DX and confirm that the encrypted “lock” icon is visible on both phones as shown below.
Secure Encrypted Call Verification – 88x5 and DX

3. Hang up the call before proceeding to the next step.
Place a Call from Jabber Client to Hardware Endpoint and Confirm the Encrypted “Lock” Icon is Present
4. Launch Charles Holland’s Jabber client on Workstation 2, log in again, and place a call to Adam’s Mckenzie DX by typing:
+19725555018 or amckenzie@dcloud.cisco.com in the call field and clicking the button
Cisco dCloud
5. Answer the call at the DX and confirm that the encrypted “lock” icon is visible at both endpoints as shown below.
Secure Encrypted Call Verification – Jabber for Windows and DX

6. Hang up the call.
Cisco dCloud
Cisco Meeting Server Secure Integration
You generated certificates in Scenario 1: Certificate Management. Now you will enable TLS/Encryption for the conferences.
1. Open a new tab in Firefox, and go to cms1.dcloud.cisco.com:445. Log in as admin with password: dCloud123!.
2. Navigate to Configuration > Call settings. Choose required from the ‘SIP media encryption’ drop down.
Cisco Meeting Server: Encrypted Calling for Secure Conferences
3. Click to save this configuration change.
4. You can close the connection to the Cisco Meeting Server administrative web interface, as you do not have any more
configuration changes to make there.
Configure Secure (TLS Encrypted) SIP Trunk Profile and Apply to SIP Trunk toward Cisco Meeting Server
1. From the browser on Workstation 1 (198.18.133.36) go to the Unified CM Admin Portal at https://ucm-
pub.dcloud.cisco.com/ccmadmin/ and log in as administrator with password dCloud123!. Navigate to System > Security >
SIP Trunk Security Profile.
Cisco dCloud
2. Click Add New to configure the new secure SIP trunk security profile. As shown below, enter the following:
 Name: Secure_CMS_Trunk_Profile
 Description: Secure SIP trunk security profile for CMS
 Device Security Mode: Encrypted
 Incoming / Outgoing Transport Type: TLS / TLS
 X.509 Subject Name: cms1.dcloud.cisco.com AND cms2.dcloud.cisco.com (separate lines)
 Incoming Port: 5061
Cisco Meeting Server: Secure SIP Trunk Security Profile
3. Click .
Cisco dCloud
4. Next, configure the existing SIP trunk toward Cisco Meeting Server for secure integration enabling encrypted signaling
between Unified CM and Cisco Meeting Server as well as encrypted media between endpoints and the Cisco Meeting Server.
Go to Device > Trunk. Click Find.
5. Choose the trunk named SIP_TRUNK_CMS1 that you configured in scenario 3 from the list of SIP trunks on the system. As
shown, make the following changes to the configuration page for this trunk:
 SRTP Allowed: Checked
 Destination Port: 5061
 SIP Trunk Security Profile: Secure_CMS_Trunk_Profile
Cisco Meeting Server: SIP Trunk to CMS1
6. Click . Click Reset and then Click OK to reset the trunk and apply the configuration changes. Repeat the steps
above to secure the SIP trunk to CMS2 (SIP_TRUNK_CMS2). Proceed to the next step, but periodically check back to ensure
the SIP trunk returns to full service. It must return to service before permanent video conferences will be possible.
Make a test call to show operation of the secure permanent space
Verify that calls to the Cisco Meeting Server permanent space with URI/DN of 80991000 are encrypted.
7. From the DX, touch the Call button and then dial 80991000 from the touchpad. Once your call is connected to the space, from
the 88x5, touch the New Call softkey and dial 80991000 using the keypad.
Cisco dCloud
8. Once the 88x5 is connected to permanent space, move to the Jabber for Windows client on Workstation 2 (198.18.133.37). If
required, RDP to Workstation 2 (198.18.133.37) as DCLOUD\cholland with password: C1sco12345 and launch Jabber.
9. Once registered, type 80991000 in the Call window and click the Call icon. As shown in the following figures, lock
dCloud: The icons
Cisco at Cloud
Demo
each endpoint indicate the Cisco Meeting Server permanent space conference call is encrypted between all three endpoints.
DX: Joined Cisco Meeting Server Permanent Space with Encryption
88x5: Joined Cisco Meeting Server Permanent Space with Encryption
Jabber: Join Cisco Meeting Server Permanent Space with Encryption
10. Hang up the call at each endpoint before proceeding to the next section.
Secure Unified CM Integration with Unity Connection Next Generation Encryption
In this section, you will enable secure integration between Unified CM and the Unity Connection voicemail system. Begin by
investigating Unity Connection certificates and then CA-signing the Unity Connection tomcat certificate. After this, enable
encryption on the Unified CM SIP trunk to Unity Connection and make the necessary configuration changes on Unity Connection to
enable end-to-end encryption between Unified CM and Unity Connection as well as between the endpoints and Unity Connection.
Cisco dCloud
Make Preliminary Voicemail Calls to Confirm Functionality and Unencrypted Calling

Begin by making a couple of quick calls to verify basic voicemail operation and to confirm that calls are not encrypted.
1. Place a call from the 88x5 to Adam McKenzie’s DX. The call will ring at the DX. Allow the call to forward to Adam McKenzie’s
voicemail box on the Unity Connection voicemail system.
2. Touch Decline on the incoming call dialog to push the call to voicemail immediately. The redirected call to the Unity
Connection voicemail system is not encrypted as evidenced by the absence of a lock icon for the call on the 88x5. Leave a
brief voice message and end the call.
3. Once the message waiting indication is displayed on the DX, touch Messages to retrieve the message from the Unity
Connection voicemail box using the voicemail pilot (2000).
DX: Voicemail Message Waiting Indicator
Cisco dCloud
4. Once the call connects to the voicemail system pilot, notice that the DX indicates the call is unencrypted.
DX: Unencrypted Call to the Unity Connection Voicemail System.

5. On the DX, hang up the call to Unity Connection.
Secure SIP Trunk between Unified CM and Unity Connection
In this task, configure Unified CM with a secure SIP trunk security profile and choose that profile for the existing SIP trunk to Unity
Connection. Then configure Unity Connection to use encryption between Unity Connection and Unified CM.
6. Using the Firefox web browser on Workstation 1 (198.18.133.36), navigate to the Unified CM Administrative interface:
https://ucm1.dcloud.cisco.com/ccmadmin and log in as administrator with password: dCloud123!.
7. Click System > Security > SIP Trunk Security Profile. Click Find, locate the CUC SIP Trunk Security profile Unity
Connection and click (copy icon) to copy this profile to a new profile.
Cisco dCloud
8. Enter CUC Encrypted_SIP_Trunk Security Profile in the “Name” field, Unity Connection Encrypted SIP Trunk Security
Profile in the “Description” field, choose Encrypted from the “Device Security Mode” dropdown. The fields Incoming Transport
Type, Outgoing Transport Type, and Incoming Port are automatically updated to TLS, TLS, and 5061 respectively. For the
X.509 Subject Name, enter the common name (CN) used in the Unity Connection tomcat certificate: cuc1.dcloud.cisco.com.
Click Save to create the new profile.
Unified CM Encrypted SIP Trunk Security Profile for the Unity Connection SIP Trunk
NOTE: The certificates signature verification is used for authentication and allows the SIP trunk to be in full service. The SIP Trunk
security profile X.509 Subject Name field is used for Authorization. If the X.509 Subject Name field is incorrect, the SIP trunk may
still come up, but SIP requests to Unity Connection will fail.
Cisco dCloud
9. Secure the existing SIP trunk to Unity Connection by applying the new encrypted SIP trunk security profile. On Unified CM
(ucm1.dcloud.cisco.com) go to Device > Trunk and click Find. Locate the SIP trunk for Unity Connection: SIP-Trunk-CUC1.
10. Click the trunk name to open the configuration page. As shown, update the trunk configuration by first dCloud:
clicking the
The SRTP
Cisco Demo Cloud
Allowed check box. Next, choose CUC Encrypted_SIP_Trunk Security Profile from the “SIP Trunk Security Profile” drop
down and change the SIP Trunk Destination Port to 5061.
Unified CM: Securing the SIP Trunk to Unity Connection
11. Click . Click OK and then click . Click Reset to reset the trunk. Once the message “Reset request was
sent successfully.” is returned, click Close.
At this point, the SIP Trunk will not return to service until you complete security configuration on the Unity Connection server.
12. Go to the Unity Connection administrative interface (https://cuc1.dcloud.cisco.com/cuadmin/) and log in as administrator with
password: dCloud123!.
Cisco dCloud
13. Navigate to the Cisco Unity Administration > Telephony Integrations > Security > SIP Security Profile. Verify that the
5061/TLS profile exists.
Unity Connection: 5061/TLS SIP Security Profile dCloud: The Cisco Demo Cloud
14. Click the profile name and on the next page, confirm the “Port” field shows 5061 and that the “Do TLS” checkbox is ticked.
Unity Connection: Verifying the 5061/TLS SIP Security Profile
Cisco dCloud
Configure Encryption for the Telephony Integration on Unity Connection
To configure encryption, begin by configuring the Unified CM cluster TFTP server. This ensures Unity Connection will automatically
download the Unified CM CallManager certificate when you enable encryption. dCloud: The Cisco Demo Cloud
15. Go to Telephony Integrations > Port Group. Click the “PCP_PhoneSystem-Default” to edit the port group. Open the Edit
menu and choose Servers.
Unity Connection: Port Group Security Configuration - Servers
16. On the Edit Servers page, under the TFTP Servers section, enter the FQDN for the Unified CM TFTP servers: ucm-
pub.dcloud.cisco.com and ucm-sub1.dcloud.cisco.com then click Save.
Unity Connection: Adding the Unified CM TFTP Servers to the Port Group
Cisco dCloud
17. Prior to resetting the port group, enable security for the port group. Return to the main port group configuration page by
clicking the Edit menu and then clicking Port Group Basics.
Unity Connection: Securing the Phone System Port Group dCloud: The Cisco Demo Cloud
18. Enable security on the port group by choosing 5061/TLS for the “SIP Security Profile” drop down. This reveals the check
boxes: “Enable Next Generation Encryption” and “Secure RTP”. Tick both of these boxes to enable encryption and secure
calling.
19. Click Save to save the configuration.
Cisco dCloud
20. Finally, click on the Reset button to reset the port group.
Unity Connection: Reset the Phone System Port Group

21. Since you enabled encryption between Unity Connection and the Unified CM phone system (ucm-pub.dcloud.cisco.com),
when the port group resets, Unity Connection automatically retrieves the Unified CM CallManager certificate from the Unified
CM TFTP server and uploads to the local CallManager-trust store. Confirm this happened by returning to the Unity Connection
Operating System administration portal at https://cuc1.dcloud.cisco.com/cmplatform/.
22. Log in as administrator with password: dCloud123!. Go to Security > Certificate Management. Click Find to open the
certificate list and note the Unified CM CallManager certificate (ucm-pub.dcloud.cisco.com) is uploaded to CallManager-trust.
Unity Connection: Unified CM CallManager Certificate Automatically Uploaded to Local CallManager-trust Store
Cisco dCloud
23. After a few minutes, verify the trunk is in full service by returning to the Unified CM administration portal (https://ucm-
pub.dcloud.cisco.com/ccmadmin) and logging in if required as administrator with password: dCloud123!.
24. Go to Device > Trunk. Click Find to load/reload the SIP Trunk list and ensure the Unity Connection SIP Trunk
dCloud: Thehas returned
Cisco to
Demo Cloud
Full Service.
Unified CM: Full Service Secure SIP Trunk to Unity Connection
Verify Encrypted Calling Between Endpoints and Voicemail System (Leaving and Retrieving Voicemails)
Finish this section on Secure Unified CM Integration with Unity Connection by making a few calls to verify secure encrypted calling
between the endpoints and the voicemail system.
25. Place a call from Monica’s 88x5 to Adam Mckenzie’s DX by dialing: +19725555016 and going of hook. The call will ring at the
DX. Allow the call to forward to Adam’s voicemail box on the Unity Connection voicemail system. Touch Decline on the
incoming call dialog to push the call to voicemail immediately.
26. Notice the lock icon on the 88x5 endpoint indicating the redirected call to the Unity Connection voicemail system is encrypted.
Leave another brief voice message for Adam and end the call.
27. Once the message waiting indication is displayed on the DX, touch Messages to retrieve the message from the Unity
Connection voicemail box using the voicemail pilot (2010).
DX: Voicemail Message Waiting Indicator
NOTE: If you previously saved or deleted the voice message left at the beginning of this section, then your message count will be
different from what is shown.
Cisco dCloud
28. Once the call connects to the voicemail system pilot, notice that the DX displays the encrypted call icon indicating the call to
the voicemail system is encrypted.
DX: Encrypted Secure Call to Unity Connection dCloud: The Cisco Demo Cloud
29. On the DX, hang up the call to Unity Connection.
Collaboration Edge (Expressway MRA)

Assign Unified CM Device Security Profiles for MRA Devices and Confirm Non-Secure & Secure Calling
Now that MRA configuration is in place, you need to configure a secure device security profile for the MRA (outside) devices. After
configuring the secure MRA profile, assign a non-secure device security profile to the previously secured DX endpoint so you can
compare a standard MRA call with an end-to-end secure MRA call.
Assign a secure encrypted device security profile for MRA connected (“outside”) devices
1. Browse to the Unified CM Administration interface (https://ucm-pub.dcloud.cisco.com/ccmadmin/) from the Firefox web
browser on Workstation 1 (198.18.133.36) and, if required login as administrator with password: dCloud123!.
2. Navigate to System > Security > Phone Security Profile and locate the previously configured encrypted phone security
profiles. To do this perform search:” Name” “begins with”, enter “UDT-Encrypted”, click Find.
Cisco dCloud
3. Click the phone security profile for the MRA connected Jabber client: UDT-Encrypted-LSC.dcloud.cisco.com and note that
the name of this profile matches one of the SAN entries we used on the Expressway-C’s certificate. The profile enables
encryption (Device Security Mode = Encrypted) but the TFTP Encrypted Config checkbox is unchecked since encrypted
TFTP configuration is not supported with MRA-only endpoints. The CAPF settings are irrelevant in this case since you will not
use the CAPF service for the external Jabber endpoint.
UDT-Encrypted-LSC.dcloud.cisco.com Phone Security Profile used for Jabber MRA
4. Next, assign this phone security profile UDT-Encrypted-LSC.dcloud.cisco.com to user cholland’s Jabber client. Navigate to
Device > Phone and click Find to retrieve a list of endpoints on the system. Choose the device CHOLLAND.
Cisco dCloud
5. Scroll down to Protocol Specific Information and under the Device Security Profile, choose UDT-Encrypted-
LSC.dcloud.cisco.com.
Assign the UDT-Encrypted-LSC.dcloud.cisco.com Phone Security Profile to CHOLLAND dCloud: The Cisco Demo Cloud
6. Click , click Ok, and then click . Click OK to apply the configuration changes.
Assign a non-secure device security profile to the DX endpoint.
1. Navigate to Device > Phone and choose the DX video endpoint. Under Protocol Specific Information in the Device Security
Profile field, choose the non-secure security profile Universal Device Template – Model-independent Security Profile.
Assign a Non Secure Phone Security Profile to the DX
Cisco dCloud
2. Click . Click OK and then click . Click OK to apply the configuration changes. The DX video
endpoint will re-register in non-encrypted phone mode.
NOTE: You are moving one of the previously secure encrypted on-premise endpoints to non-encrypted mode to show that Jabber
can still connect securely to the enterprise without end-to-end encryption, even though the client is configured in encrypted mode.
Verify MRA Connectivity for “outside” Jabber client (CHOLLAND on Workstation 2)
1. Next, verify MRA connectivity for the “outside” Jabber client. RDP to Workstation 2 (198.18.133.37) using the username
DCLOUD\cholland and password C1sco12345.
2. On the Desktop, double-click the External Network On script .
3. Start Jabber by double-clicking the Jabber icon on the desktop and log as cholland with password C1sco12345.
NOTE: Be patient. It may take as long as a minute for the Jabber client to launch the first time.
Appropriate DNS records are in place in the public (“outside”) DNS to ensure that the Jabber client is able to discover the
Expressway MRA service and connect to enterprise on-premise collaboration services through the Expressway-E. The pertinent
public DNS records for this are as follows:
 SRV record: _collab-edge._tls.dcloud.cisco.com > exp-e-1.dcloud.cisco.com
 A record: exp-e-1.dcloud.cisco.com > 198.18.2.152 (“outside” interface)
Cisco dCloud
4. Next, verify the Jabber client is using the Expressway MRA solution by inspecting the Connection Status. Navigate to
(Settings) > Help > Show connection status. See the figure below for the expected results.
MRA Jabber Client’s Connection Status
NOTE: Be patient. It may take some time for the client to connect to Unified CM for voice and video services the first time.
Cisco dCloud
There are several clues on the connection status screen that confirm MRA connectivity. Notice the “Expressway” indication for the
Unified CM connection under Softphone status and the Expressway-E server (exp-e-1.dcloud.cisco.com) connection for Presence.
Finally, you should also see under Directory status that the client is now connected to Unified CM using User Data Services (UDS)
on our Unified CM. This indicates you are using an MRA connection because while you have configured corporate LDAP directory
as the Jabber contact source, when Jabber clients connect over MRA, it is forced to use UDS for directory services. Contrast this
with the Directory connection status for our on-premise Jabber client (CHOLLAND) where the directory source address is the
corporate LDAP server (ad1.dcloud.cisco.com) and the protocol in use is LDAP.
5. Click Close to close the connection status window before proceeding to the next step.
Call from MRA connected Jabber (CHOLLAND on Workstation 2) to non-secure on-premise DX endpoint and confirm
encryption from Jabber client to Expressway-C.
Next, confirm that the MRA (outside) Jabber client (CHOLLAND on Workstation 2) can make secure calls.
First, verify a call between the MRA connected Jabber client and a non-secure on-premise phone to ensure the call is encrypted
from the Jabber client to the Expressway-C. Then, verify a call between the MRA connected Jabber client and a secure on-premise
phone to confirm the call is encrypted from end-to-end between the Jabber client and the on-premise desk phone. Finally, you will
confirm a secure end-to-end encrypted call between the on-premise Jabber client and “outside” Jabber client.
1. Search for Adam Mckenzie on the MRA Jabber Client (CHOLLAND on Workstation 2), click the contact, and click the
button to place the call. Choose either of the two options: Work: +19725555016 or Work: amckenzie@dcloud.cisco.com.
Answer the incoming call on the DX. As the DX no longer has a secure phone security profile you will not see a lock icon on
either the desk phone or the “outside” Jabber client as end-to-end encryption is not enabled.
NOTE: The MRA leg of the call to between Jabber and Expressway-C is encrypted but the internal leg of the call is not.
Non Secure MRA Call between the MRA Jabber client and the DX
Cisco dCloud

Call from MRA connected Jabber (CHOLLAND on Workstation 2) to secure on-premise 88x5 desk phone and confirm end-to-end
encryption
3. Search for Monica Cheng on the MRA Jabber Client (CHOLLAND on WKST2), click the contact, and click the button.
Choose either of the two options: Work: +14085554030 or Work: mcheng@dcloud.cisco.com. Once the call is made,
answer on the 88x5. Because both the 88x5 and the “outside” Jabber client have secure phone security profiles you should
see a lock icon on both the desk phone and the “outside” Jabber client indicating end-to-end encryption is enabled.
Secure MRA Call between the MRA Jabber client and the 88x5
NOTE: Full end-to-end encryption is enabled for this call scenario as evidenced by the lock icons
Cisco dCloud
Make a call from MRA connected Jabber (CHOLLAND on Workstation 2) to secure on-premise Jabber Client
(CSFAMCKENZIE on Workstation 1) and confirm end-to-end encryption.
1. On Workstation 1 (198.18.133.36) launch the Jabber client (CSFAMCKENZIE). Log in as amckenzie with password:
C1sco12345.
2. Once the Workstation 1 Jabber client is connected, return to Workstation 2 and search for Adam Mckenzie on the MRA Jabber
Client (CHOLLAND), click his contact, click the button, and choose either of the two options: Work: +19725555016 or
Work: amckenzie@dcloud.cisco.com. Once the call is made, answer on Charles Holland’s Jabber Client (CHOLLAND on
Workstation 2). Both the devices have a secure phone security profile, so full end-to-end encryption is negotiated. If the
system configuration is correct, both Jabber clients will display the lock icon.
Full Encryption between the MRA Jabber client and the Internal Jabber Client
NOTE: Full end-to-end encryption is enabled for this call scenario as evidenced by the lock icons
3. Hang up the call and logoff /close the Jabber application on Workstation 1 and on Workstation 2.
Cisco dCloud
Appendix A: IM & Presence and Unity Connection CA Certificate

Installation
In this lab, all Certificate Authority (CA) signed certificates were pre-installed on IM & Presence and Unity Connection to save time.
The following section is for reference only. These replaced the default self-signed certificates on your UC servers in preparation
for use with Cisco Jabber as well as configuring Collaboration Edge. Cisco Jabber uses certificate validation to establish secure
connections with servers. When attempting to establish secure connections, servers present Cisco Jabber with certificates. Cisco
Jabber for Windows validates those certificates against certificates in the Microsoft Windows certificate store. If the client cannot
validate a certificate, it prompts the user to confirm if they want to accept the certificate. First, you need to prepare Unified CM, IM
& Presence, and Unity Connection by configuring Fully Qualified Domain Names (FQDN).
Configure Unified CM and IM & Presence with FQDNs
The reason for changing the Cisco UCM server names from hostname or IP address to FQDN is so they can be resolved by the
different services on the UC network. In addition, during the Jabber for Windows certificate validation process the FQDN is usually
called out in the CA signed certs.
1. On Workstation 1, open Firefox and from the homepage choose Collaboration Admin Links > Cisco Unified
Communication Manager.
3. Navigate to System > Server and click Find.
4. You will need to make sure the server hostnames reflect their fully qualified domain name as shown in the list below:
Server List
5. Open another Firefox tab and from the homepage, choose Collaboration Admin Links > Cisco Unity Connection Admin.
7. Under System Settings, click Cluster and then click Find.
8. You will also need to configure the FQDN of Unity Connection here.
9. Close the tab for Unity Connection.
Download CA Root Certificate from CA server (AD1)
Jabber clients no longer accept the self-signed certificates installed by default on the UC servers. In this section, you install CA
signed certificates. You can use publicly trusted CA signed certificates or ones you create. This lab uses the Certificate services
that are installed with the MS Certificate Authority Role on Windows Server to create signed certificates.
1. RDP to the AD1 (198.18.133.1) server, open Firefox, and choose the menu dCloud Certificates > AD1 Certificate Services.
2. Authenticate with Username: administrator and Password: C1sco12345.
Cisco dCloud
3. Click Download a CA certificate, certificate chain, or CRL.
4. Choose the radio button for Base 64 and then click Download CA certificate.
5. Click OK to Save File.
6. Minimize Firefox and open the Certificates folder on the desktop.
7. Rename the certnew.cer file to CARootCert.cer.
Renamed Root Certificate
NOTE: You will download and create multiple certificates. Rename these files as they are downloaded to keep better track of them.
Adding CA Signed XMPP Certificate to IM & Presence.
For this section, you will complete the same process as before with the XMPP certificate but just for the IM & Presence server.
Since the xmpp service is not on the Unified CM server, this must be completed on the IM & Presence server. Since you have
already downloaded the Root Certificate, you do not need to complete that step again.
1. Go to the IM & Presence OS Administration page and choose Security > Certificate Management.
3. Click Upload Certificate/Certificate Chain.
4. Choose cup-xmpp-trust from the drop-down.
5. For description, enter AD1 CA Root Certificate.
6. Click Browse and go to the Certificates folder on the Desktop.
7. Choose the CARootCert.cer and click Open.
Upload Root Cert
8. Click Upload and then Close after Successful upload.
Cisco dCloud
Generate and Download Certificate Signing Request (CSR)
1. Click Generate CSR.

2. Change the following values and keep the rest as default:
 Certificate Purpose: cup-xmpp
 Hash Algorithm: SHA1
3. Click Generate and then click Close after seeing the Success status.
4. Click Download CSR.
5. Verify cup-xmpp is selected and then click Download CSR.
6. Choose the radio button for Save File and then click OK.
7. Click Close.
8. Open the Certificates folder on the desktop. Since this is the only file you need to download with this name there is no need
to rename the cup-xmpp.csr file.
Submit and Download XMPP Signed CA Certificates for IM & Presence
1. Open the cup-xmpp.csr file you downloaded from the UC server in Notepad (default program).
2. Choose Edit > Select All.
3. Choose Edit > Copy.
4. Close Notepad.
5. From the Certificate Services tab in Firefox, choose the menu dCloud Certificates > AD1 Certificate Services.
6. Click Request a certificate and then click advanced certificate request.
7. Paste (CTRL-V) the information copied from the Notepad earlier into the Saved Request box.
8. Choose Web Server from the Certificate Template drop-down.
Certificate Request
9. Click Submit.
10. Choose the radio button for Base 64 encoded and click Download certificate. Do NOT choose chain.
Cisco dCloud
11. Make sure the radio button for Save File is selected and click OK.
12. Open the Certificates folder on the Desktop and rename the certnew.cer to CUP1-CAxmpp.cer.
XMPP CER File
Upload CA Signed XMPP Certificate to IM & Presence
1. Click the Firefox tab for the IM & Presence OS admin page and navigate to Security > Certificate Management. You should
already be there from earlier.
2. Click Upload Certificate/Certificate chain.
3. In the pop-up window, choose cup-xmpp from the Certificate Purpose drop-down and then click Browse.
4. Choose the CUP1-CAxmpp.cer file in the Certificates folder.
XMPP CER File
5. Click Upload and then Close after successful upload message.
6. Follow the same steps above to generate and sign CSRs for any other IM & Presence services such as cup-xmpp-s2s service.
When you upload the signed certificate, you would choose cup-xmpp-s2s instead of cup-xmpp.
Adding CA Signed to Unity Connection.
For this section, you will complete the same process as before with the XMPP certificate but just for the IM & Presence server.
Since the xmpp service is not on the Unified CM server this must be completed on the IM & Presence server. Since you have
already downloaded the Root Certificate, you do not need to complete that step again.
1. Go to the Cisco Unity Connection OS Administration page and choose Security > Certificate Management.
3. Click Upload Certificate/Certificate Chain.
4. Choose tomcat-trust from the drop-down menu.
5. For description, enter AD1 CA Root Certificate.
6. Click Browse and go to the Certificates folder on the Desktop.
Cisco dCloud
7. Choose CARootCert.cer and click Open.
Upload Root Cert

8. Click Upload and then Close after Successful upload.
Generate and Download Certificate Signing Request (CSR)
1. Click Generate CSR.
2. Change the following values and keep the rest as default:
 Certificate Purpose: tomcat
 Hash Algorithm: SHA256
3. Click Generate and then click Close after seeing the Success status.
4. Click Download CSR.
5. Verify tomcat is selected and then click Download CSR.
6. Choose the radio button for Save File and then click OK.
7. Click Close.
8. Open the Downloads folder on the Desktop. Look for tomcat.csr file. Change the name to cuc-tomcat.csr
Submit and Download Tomcat Signed CA Certificates for Unity Connection
1. Open the cuc-tomcat.csr file you downloaded from the UC server in Notepad (default program).
2. Choose Edit > Select All.
3. Choose Edit > Copy.
4. Close Notepad.
5. From the Certificate Services tab in Firefox, choose dCloud Certificates > AD1 Certificate Services.
6. Click Request a certificate.
7. Click advanced certificate request.
8. Paste (CTRL-V) the information copied from the Notepad earlier into the Saved Request box.
Cisco dCloud
9. Choose Web Server from the Certificate Template drop-down menu.
Certificate Request
10. Click Submit.
11. Choose the radio button for Base 64 encoded and click Download certificate. Do NOT choose chain.
12. Make sure the radio button for Save File is selected and click OK.
13. Open the Certificates folder on the Desktop and rename the certnew.cer to CUC1-tomcat.cer.
Restart UC services on IM & Presence, and Unity Connection.
After you upload a certificate for each service, the service affected will need to be restarted before the certificate takes effect.
Some can be restarted via CLI; others will need to be restarted via the Serviceability web page. Below is the table of each service
that will need to be restarted and the command (if available) to restart via command line. You only need to restart if you uploaded a
certificate against that service.
Table 97. Service restart
Server Certificate Service Command

Installed
IM & Presence Tomcat Cisco Tomcat utils service restart Cisco Tomcat
IM & Presence cup-xmpp Cisco XCP Router utils service restart Cisco XCP Router
IM & Presence cup-xmpp-s2s Cisco XCP XMPP Federation Connection utils service restart Cisco XCP XMPP Federation Connection
Manager Manager
Unity Tomcat Cisco Tomcat utils service restart Cisco Tomcat

Connection
Cisco dCloud
Appendix B: Adding Client-Server Template to Certificate Services

In this lab, you generated your own certificates using the Microsoft CA role. However, the base install of the CA role needed to be
modified to support the type of certificate the Expressway servers require. In this appendix, you will find the steps to add the new
Client-Server template that was already pre-configured for you.
1. From within the RDP session to AD1, open the Certificate Authority application by going to Start > All Programs >
Administrative Tools > Certification Authority.
2. Click the plus (+) sign next to dcloud-AD1-CA to expand it and click on Certificate Templates below.
3. Right click on Certificate Templates and choose Manage from the pop-up menu.
4. Right click on Web Server and choose Duplicate Template from the pop-up menu.
5. Verify Microsoft Server 2003 Enterprise is selected and then click OK.
6. Configure the following parameters for the New Template.
 Template display name: ClientServer
 Template name: ClientServer (pre-populated)
 Click the Request Handling tab and click the checkbox for Allow private key to be exported
 Click the Extensions tab
 Verify that Application Policies is selected and then click Edit
 Click Add
 Click to highlight Client Authentication from the list, click OK, and then click OK to confirm the addition
 Click OK one more time to save the new template
7. Close the Certificate Template Console by using the X in the top right corner of the window.
8. Right click on Certificate Templates and choose New > Certificate Template to Issue from the pop-up menu.
9. Click ClientServer from the list to highlight it and then click OK.
10. Close the Certificate Authority (certsrv) console.
Cisco dCloud
Appendix C: Unified CM and Unity Connection Licensing with Prime

License Manager
After a new installation, the Cisco Unified Communications applications will be running in demo mode for 60 days. During this time,
the server will be fully functional. If the demo runs out and a license is not installed then certain services will no longer function
depending on the Unified Communications application. With version 10, you can license automatically through Prime License
Manager (PLM) or manually by sending a license key to Cisco through email. In this lab, you will install a license manually since a
key has already been generated for the environment. If your production system is connected to the Internet, you will use automatic
licensing. To save time in the lab, licensing was pre-installed.
Below are the steps that were accomplished for your reference:
1. Open another tab in Firefox and from the dCloud homepage (http://ad1.dcloud.cisco.com/dCloud/default.html) choose
Collaboration Admin Links > Cisco Prime License Manager.
2. Log in as username: administrator and password: dCloud123!.
3. From the main menu, click Product Instances and then click Add.
4. Input the following information into the dialog box and click Test Connection. Acknowledge the popup of the test result.
Table 98. Unified CM Instance
Setting Input
Name ucm-pub
Product Type Unified CM
Hostname/IP Address ucm-pub.dcloud.cisco.com
Username administrator (this is the OS admin account)
Password dCloud123!
5. After a successful test, click OK.
6. Click Add to add another instance of Unity Connection using the following input. Again, enter the information, click Test
Connection and acknowledge the popup of the test result.
Table 99. Unity Connection Instance
Setting Input
Name ucx1
Product Type Unity Connection

Hostname/IP Address ucx1.dcloud.cisco.com
Username administrator (this is the OS admin account)
Password dCloud123!
7. After a successful test, click OK.
8. Click Synchronize Now. View the Status after synchronization to be sure no errors occurred. Since there are no licenses
installed on the systems yet, it will read that Demo Licenses are in use. This is expected. Ignore this error and any Expiration
errors you see in the Status column.
9. From the main menu, choose Licenses > Fulfillment.
Cisco dCloud
10. You have several licensing options at this point, but as mentioned in the introduction to this section, you will be fulfilling
licenses by file upload. Click Other Fulfillment Options > Generate License Request.
11. If you were performing this action in a production environment, you would copy the highlighted text anddCloud:
put itThe
intoCisco
notepad.
Demo Cloud
Then you would go to the Cisco License Registration site, enter a PAK code, and upload the license request file to redeem
your license. Since that step is completed for you, there is no need to copy the text. Click Close.
12. Choose Other Fulfillment Options > Fulfill Licenses from File.
NOTE: The license file is located on Workstation 1. If you are using your local browser, you will need to RDP to Workstation 1
(198.18.133.36) and complete the following steps.
13. In the popup dialogue box, choose Browse, then go to the Desktop > Licenses folder and choose the file in this folder. It
starts with the characters 1b5. Click Open.
14. Click the Install button. You should receive a confirmation that the file is installed. Close the dialog box.
15. From the main menu, choose Product Instances. You should see a status of Synchronization Successful for each product
instance.
16. Navigate to Licenses > Usage to view the licenses that were installed. Once you start adding users and devices, you can
come back to this page to view how many licenses were used.
17. Close the Firefox tab for Prime License Manager.
Cisco dCloud
Appendix D: Common Phone Profile Configuration

Configure Common Phone Settings dCloud: The Cisco Demo Cloud
On a fresh install, you would need to configure these settings on Unified CM. To save time in the lab, the following steps were
completed for you already. This is for your reference only.
1. Navigate to Device > Device Settings > Common Phone Profile, click Find, and then click the Standard Common Phone
Profile link. Tech Tip: Use CTRL+F to search for the settings.
2. Under the Product Specific Configuration Layout section, change Cisco Camera to Enabled.
3. Change RTCP* to Enabled.
4. Verify Video Calling is set to Enabled and check the box next to it.
Call Settings
5. Check the box for RTCP for Video*. Leave Enabled.
Call Settings
6. Click Save.
Cisco dCloud
Appendix E: Collaboration Edge Pre-Configuration Steps

Configure public DNS server with relevant SRV and A records dCloud: The Cisco Demo Cloud
In this lab, there is an internal DNS server (AD1) and a mock external (public) DNS server. The lab is just using VLAN separation
to do this, so it is still not reachable from the Internet. For the purposes of this lab, it allows you to test the functionality of MRA on
the Expressway servers. The following is a summary of what A and SRV records you will create in this section on the internal and
external DNS servers. This section is for reference only.
Internal DNS Server
Create two A records and one SRV record:
 exp-c-1.dcloud.cisco.com. (A record) pointing to IP address of Expressway-C
 exp-e-1.dcloud.cisco.com. (A record) pointing to the LAN1 IP address of Expressway-E
 _cisco-uds._tcp.dcloud.cisco.com. (SRV record) pointing to Unified CM (created earlier in lab)

External DNS Server
Create one A record and one SRV record:
 exp-e-1.dcloud.cisco.com. (A record) pointing to the LAN2 IP address (NATted or “public” in this case) of
Expressway-E
 _collab-edge._tls.dcloud.cisco.com. (SRV record) pointing to Expressway-E (exp-e-1.dcloud.cisco.com)
1. Create an RDP session to the AD1 server (198.18.133.1). Log in as administrator with password C1sco12345.
2. Open the DNS Manager using the icon [ ] on the Desktop or taskbar. You may still have this open from earlier in the lab.
4. Right click on dcloud.cisco.com and choose New Host (A or AAAA)… from the pop-up menu.
5. Enter exp-c-1 for Name and 198.18.133.152 for IP address.
6. Click Add Host and then OK.
7. Enter exp-e-1 for Name and 198.18.1.152 for IP address.
9. Click Done.
10. You should now have two entries as shown in the screen shot below.
Expressway A records
11. Close DNS manager.
12. Next, open an RDP session to the external DNS server (198.18.2.11).
Cisco dCloud
13. Log in as Username: administrator and Password: C1sco12345.
14. Open the DNS Manager using the icon [ ] on the desktop or taskbar. dCloud: The Cisco Demo Cloud
16. Right click on dcloud.cisco.com and choose New Host (A or AAAA)… from the pop-up menu.
17. Enter exp-e-1 for Name and 198.18.2.152 for IP address. This is the IP address of LAN2 on the Expressway-E.
19. Click Done.
20. Right click on dcloud.cisco.com and choose Other New Records… from the pop-up menu.
21. Choose Service Location (SRV) in the record type list and then click Create Record….
22. Fill in the following information:
Table 100. _collab-edge SRV Record
Setting Input
Service _collab-edge
Protocol _tls
Priority 0
Weight 0
Port number 8443
23. Click OK and then Done.
Initial Configuration of Expressway-C and Expressway-E
Since both of the Expressway servers are deployed using the same OVA, the initial setup is nearly identical. Because of this,
instead of having one configuration section for C and one for E and repeating the same steps, you will use the same section for
both. Complete each of the following steps on both Expressway servers. If the configuration is different, it is noted in the step. We
recommend opening two tabs in Firefox, one tab to Expressway-C and one tab to Expressway-E and then complete each step on
both servers at the same time. If it is easier for you to complete one Expressway server at a time then complete the section once
on Expressway-C and then go back and complete the same steps on Expressway-E.
1. On the RDP session to AD1, open a Firefox tab. Go to Collaboration Admin Links > Cisco Expressway-C.
2. Open another tab in Firefox and on the dCloud homepage choose Collaboration Admin Links > Cisco Expressway-E.
NOTE: From here, you will be completing the same steps on both Expressways. Remember 198.18.133.152 is Expressway-C and
198.18.1.152 is Expressway-E. You will notice until you install the option keys that it will be hard to keep these apart because the
top banner will read Cisco TelePresence Video Communications Server Control for both servers.
3. Log in as username: admin and password: dCloud123!.
Cisco dCloud
NOTE: On the initial install, the password is TANDBERG.
4. There are four alarms present. You can click on the message This system has 4 alarms to view. You will resolve them in the
following steps. As you do, the number of alarms will decrease.
5. Navigate to System > Time.
6. For NTP Server 1, enter 198.18.128.1.
7. Clear the contents from the boxes for NTP Server 2 and NTP Server 3.
8. For Time Zone, choose US/Pacific.
9. Click Save. After a minute the State should show . You do not have to wait for these messages, you can just
continue with the lab.
10. Next, take care of another alarm and change the root account password. Minimize the Firefox browser.
11. Double click on the PuTTY icon on the desktop.
12. Enter exp-c-1 for the hostname and click Open. Click Yes on the Security Alert.
13. Double click on the PuTTY icon again to open another connection.
14. Enter exp-e-1 for the hostname and click Open. Click Yes on the Security Alert.
15. Continue completing the next steps in both windows.
16. Log in as username: root and password: TANDBERG.
17. Type passwd at the # prompt.
18. Type dCloud123! and press Enter. Perform this step a second time.
Successful root password change
19. Close both PuTTY windows after you make the password change on each server and then click OK to acknowledge.
20. Reopen your Firefox browser on AD1.
21. Navigate to Maintenance > Option Keys.
22. Copy and paste the following keys into the Release key box and then click Set release key twice. You will see an Invalid
Release key warning. If you click Set release key a second time it will turn into a restart message. Do not restart yet.
Table 101. Release Keys
Expressway-C Expressway-E
5756201107157457 7087859393247892
23. Ignore the restart messages. You will restart later after all keys are installed. After the restart, the error message goes away.
Cisco dCloud
24. Copy and paste the following keys into the Add option key box and then click Add option after each key is entered.
Table 102. Option Keys

Expressway-C Expressway-E Key Type
116341E00-1-F82FC842 116341E00-1-4A604324 Expressway Series Key – Note the name change at the top
116341G00-1-BDDB4852 116341G00-1-FD57CBB3 H323-SIP – Interworking Key

N/A 116341I1800-1-3B73AEF9 1800 TURN Relays
N/A 116341T00-1-AA79D66E Enables Expressway-E – Note the name change from C to E at the top
N/A 116341L00-1-4D0A6F4A Advanced Network for NAT and to enable LAN 2
25. Navigate to System > DNS.
26. Enter the following information:
Table 103. DNS Information
Setting Expressway-C Expressway-E

System host name exp-c-1 exp-e-1
Domain name dcloud.cisco.com dcloud.cisco.com
Default DNS servers - Address 1 198.18.133.1 198.18.2.11
27. Click Save.
Complete the next few steps on Expressway-E ONLY to configure a second LAN public facing interface.
28. Navigate to System > Network interfaces > IP.
29. Configure the following information. DO NOT change any other settings if it is not mentioned in the table below.
Table 104. Expressway-E IP Settings
Setting Input
Use dual network adapters Yes
External LAN Interface LAN2
LAN 2 IPv4 address NOT LAN 1 198.18.2.152
Cisco dCloud
Expressway-E IP Settings
30. Click Save.
Now you will restart both Expressway servers.
31. Click the link in the yellow message box at the top of the page.
32. Click Restart and then OK.
Download CA Root Certificate from CA server (AD1)
In this section, you will install CA signed certificates from the AD server. You can use publicly trusted CA signed certificates or
ones you create. This lab uses the Certificate services that are installed with the MS Certificate Authority Role on Windows Server
to create signed certificates.
1. Open a new Firefox tab and choose dCloud Certificates > AD1 Certificate Services.
2. Authenticate with Username: administrator and Password: C1sco12345.
3. Click Download a CA certificate, certificate chain, or CRL.
4. Choose the radio button for Base 64 and then click Download CA certificate.
Cisco dCloud
5. Click OK to Save File.
6. Minimize Firefox and open the Certificates folder on the desktop.

7. Rename the certnew.cer file to CARootCert.cer.
Renamed Root Certificate
NOTE: You will be downloading and creating multiple certificates. Rename the files as they are downloaded to keep track of them.
Configure the Expressway-E Server for Unified Communications
Only complete this section on Expressway-E.
1. Go back to the Expressway-E tab and after the restart, log in as Username: admin and Password: dCloud123!.
2. Navigate to Configuration > Unified Communications > Configuration.
3. Choose Mobile and remote access from the Unified Communications mode drop-down.
4. Click Save.
5. Navigate to Maintenance > Security certificates > Trusted CA certificate and click Browse.
6. Open the Certificates folder on the Desktop.
7. Click the CARootCert.cer certificate and click Open.
8. Click Append CA certificate.
Configuring the Expressway-C Server for Unified Communications
Only complete this section on Expressway-C.
1. Go back to the Expressway-C tab and after the restart, log in as Username: admin and password: dCloud123!.
2. Navigate to Configuration > Unified Communications > Configuration and set Unified Communications mode to Mobile
and remote access.
3. Click Save.
4. Navigate to Configuration > Domains and click New.
Cisco dCloud
Table 105. Domain Settings

Setting Input
Domain name dcloud.cisco.com
SIP registrations and provisioning on Unified CM On

IM and Presence services On
6. Click Create domain.
Next, you will discover the Unified CM and IM & Presence servers that provide registration, call control, provisioning, messaging,
and presence services to the Jabber clients. First, you need to upload the Root CA from AD1.
7. Navigate to Maintenance > Security certificates > Trusted CA certificate and click Browse.
9. Click the CARootCert.cer certificate and click Open.
10. Click Append CA certificate.
11. Navigate back to Configuration > Unified Communications > Unified CM servers and click New.
Table 106. Unified CM Server Settings
Setting Input
Unified CM publisher address ucm-pub.dcloud.cisco.com

Username Administrator
Password dCloud123!
13. Click Add address.
14. Observe that this time you received a Success message. You can ignore the Connection to port 5061.. warning.
15. Navigate to Configuration > Unified Communications > IM and Presence Service nodes and click New.
Table 107. IM & Presence Server Settings
Setting Input
Unified CM publisher address imp-pub.dcloud.cisco.com
Username administrator
Password dCloud123!
17. Click Add address.
Cisco dCloud
Configuration of Certificates to prepare for Implementing Traversal Zones
In this section, you will generate certificates to upload to the Expressway servers.
You will complete the exact same steps on both Expressway servers. We recommend completing the next section just as you did
in the initial configuration of the Expressway servers. Open a Firefox tab to each Expressway server and complete the
configuration simultaneously. As before, in the steps where the configuration differs it will be noted in the step. If you prefer, you
can complete the section for one server at a time. Just verify that you do indeed complete both servers.
1. In Firefox make sure there are two tabs open to the Expressway-C and Expressway-E servers and log in (if needed) as
Username: admin and Password: dCloud123!.
2. Navigate to Maintenance > Security certificates > Server certificate and click Generate CSR.
Table 108. CSR Settings
Setting Input
Additional alternative names UDT-Encrypted-NullString.dcloud.cisco.com, UDT- Encrypted-

AuthString.dcloud.cisco.com , UDT-Encrypted-LSC.dcloud.cisco.com, UDT-
Encrypted-LSC-TFTPenc.dcloud.cisco.com (Just on Expressway-E)
Unified CM registrations domains dcloud.cisco.com Format DNS (Expressway-E only. See figure below.)
Key length (in bits) 4096
Digest algorithm SHA256
Country US
State or province Texas
Locality (town name) Richardson
Organization (company name) Cisco Systems
Organization unit dCloud
Cisco dCloud
Generate CSR Settings
4. Click Generate CSR and then click Download.
5. Click the radio button next to Save File and then click OK.
6. Go to the Certificates folder on the desktop and open the CSR txt file you just downloaded.
7. Click Edit > Select All.
8. Click Edit > Copy.
9. Close the Notepad file.
10. Go back to the AD1 Certificate Services tab in Firefox.
11. Click Home in the top right corner of the page.
12. Click Request certificate and then advanced certificate request.
13. Right click in the Saved Request box and choose Paste from the pop-up menu.
14. Choose ClientServer from the Certificate Template drop-down menu.
NOTE: The ClientServer template is not installed by default within Certificate Services, it was pre-configured for you. The steps to
add this template are in Appendix B.
Cisco dCloud
15. Click Submit.
16. Click the radio button next to Base 64 encoded and then click Download certificate.
17. Verify Save File is selected and then click OK.
19. Rename the certnew.cer file to:
Expressway-C
 ExpC-Cert.pem (Make sure to change the .cer file extention to .pem as shown)
 Click Yes to rename the extension
Expressway-E
 ExpE-Cert.pem (Make sure to change the .cer file extention to .pem as shown)
 Click Yes to rename the extension
PEM Certificates
20. Go back to the tab for Expressway (C or E) and click Browse at the bottom of the Server Certificate page.
21. Go to the Certificates folder and open the .pem certificate for the Expressway.
Expressway-C
 ExpC-Cert.pem
Expressway-E
 ExpE-Cert.pem
22. Click Upload server certificate data.
23. Click I Understand the Risk, click Add Exception, and then click Confirm Security Exception, if prompted.
24. Click the link at the top of the page.
25. Click Restart and then OK to confirm the restart.
Creating a White List for Voicemail on Expressway-C for MRA
In this section, you will configure a white list entry for the voicemail server and internal active directory server that will allow Jabber
clients to access voicemail services and see directory photos.
Jabber client endpoints may need to access additional web services inside the enterprise. This requires an "allowed list" of servers
that the Expressway will grant access for HTTP traffic originating from outside the enterprise.
Cisco dCloud
The features and services that may be required, and would need whitelisting, include:
 Visual Voicemail
 Jabber Update Server
 Custom HTML tabs/icons
 Directory Photo Host
1. On the AD1 server (198.18.133.1) go to the Firefox tab of Expressway-C.
2. Navigate to Configuration > Unified Communications > Configuration.
3. Click Configure HTTP server allow list and then click New.
4. For Server hostname, enter cuc1.dcloud.cisco.com.
5. Click Create entry.
Configure SIP profile on Unified CM for Cisco Expressway-C for B2B
1. If not connected already, open an RDP session to AD1 (198.18.133.1) and log in as administrator with password:
C1sco12345.
2. Open a Firefox tab and choose Collaboration Admin Links > Cisco Unified Communications Manager.
4. Navigate to Device > Device Settings > SIP Profile and click Add New.
Table 109. SIP Profile Settings
Setting Input
Name Custom SIP Profile for Cisco Expressway-C

Description Custom SIP Profile for Cisco Expressway-C Server
Enable OPTIONS Ping to monitor destination status for Trunks with Service type “None (Default)” Checked
Allow Presentation Sharing using BFCP Checked

Allow iX Application Media Checked
Allow multiple codecs in answer SDP Checked
SIP Profile Settings
Cisco dCloud
6. Click Save.
Configure SIP trunk security profile on Unified CM for Cisco Expressway-C for B2B
In order to route B2B calls, you must create a SIP trunk between Unified CM and Expressway-C.
In this lab, Expressway-C is already configured for mobile and remote access. Port 5060 is used for line-side registrations of
endpoints in mobile and remote access scenarios. A SIP trunk cannot be formed between Expressway-C and Unified CM using
port 5060 because the UCM cannot accept line-side and trunk-side communication from the same device using the same port.
Because of this, the SIP trunk from Expressway-C to UCM has to use another SIP port on the UCM incoming side. This lab uses
5560 as the SIP trunk incoming port. You can change the SIP incoming port by creating a new SIP trunk security profile and
assigning this profile to the SIP trunk created between UCM and Expressway-C.
1. Navigate to System > Security > SIP Trunk Security Profile and click Add New.
2. Enter the following values in the relevant fields:
Table 110. SIP Trunk Security Profile Settings
Setting Input
Name Non Secure SIP Trunk Profile port 5560
Description SIP Profile with listening port 5560
Incoming Port 5560
Accept presence subscription Checked
Accept out-of-dialog refer Checked
Accept unsolicited notification Checked
Accept replaces header Checked
3. Click Save.
Configure SIP trunk on Unified CM for Cisco Expressway-C for B2B
1. Navigate to Device > Trunk and click Add New.
2. For Trunk type, choose SIP Trunk. Leave the rest as default and click Next.
3. Enter the following into the relevant fields. Leave the other fields at their default values. Use CTRL-F to search for the fields.
Table 111. SIP Trunk Settings
Setting Input
Device Name SIP_Trunk_ExpC
Description SIP_Trunk_ExpC for B2B Calls
Device Pool SJCPhoneVideo
In Outbound calls - Calling and Connected Party Info Format Deliver URI only in connected party, if available
In SIP Information - Destination Address and Port 198.18.133.152 port 5060
SIP Trunk Security Profile Non Secure SIP Trunk Profile port 5560
SIP Profile Custom SIP Profile for Cisco Expressway-C
DTMF Signaling Method RFC 2833
Normalization Script vcs-interop
Cisco dCloud
4. Click Save then OK.

Configure SIP route pattern on Unified CM for Cisco Expressway-C for B2B
The following SIP route pattern is configured to route all B2B calls toward Expressway-C, which does not match any existing route
patterns.
1. Go to the tab for Unified CM Administration on the US Publisher and navigate to Call Routing > SIP Route Pattern and click
Add New.
2. Use the table below to configure the new SIP route pattern.
Table 112. SIP Route Pattern for B2B
Setting Input
IPv4 Pattern *
Description Route for B2B calls to local Expressway-C
Route Partition URI
SIP Trunk/Route List SIP_Trunk_ExpC
3. Click Save.
Cisco dCloud
Appendix F: Installing a Unified Communications Application on an ESXi

Host
The following steps show what you would do to install your first Unified Communications application, Cisco Unified
Communications Manager. All other applications to be installed on the ESXi host would be deployed in a similar way. This
scenario is for information ONLY and does not run in this lab. If you have never deployed a new UC server into a virtual
machine you will be able to use the scenario to gain that experience on a server in your own test lab.
1. From the Desktop of Workstation 1, start the vSphere Client by using the shortcut on the task bar [ ].
2. Log in to the vSphere Client using the following credentials:
a. IP address/Name: vesxi1.dcloud.cisco.com
b. Username: labroot
c. Password: C1sco12345
d. Domain: dcloud
3. Maximize the window and click the Configuration tab.
4. Click on Storage in the Hardware frame, then right mouse click on datastore1 and choose Browse Datastore.
5. Expand the folders until the folder CUCM and CUC is opened. The ISO file used for creation of the Communications Manager
(Unifed CM) virtual machine (VM) has been uploaded. You will be using this file in a moment to create the Unified CM VM.
VM Folder Hierarchy
6. Close the Datastore browser window.
NOTE: On a purchased BE6k/7K, it will ship from the factory with all the software you will need to set up the server. Because this
is a lab, only Unified CM is uploaded.
7. From the menu bar in the vSphere client, choose File > Deploy OVF Template and click Browse.
8. In file browser window, choose the Desktop \ v11 Templates\ cucm_11.5_vmv8_v1.8.ova file and click Open.
9. Click Next twice.
10. Accept the Default VM Name Cisco Unified Communications Manager (CUCM) and click Next.
11. For configuration, choose CUCM 1000 user node - C200 (incl BE6K) and click Next.
NOTE: For BE7K deployments, you can choose anything above 1K. You will need to choose the option that is supported for your
server. However, for the purposes of this lab choose the CUCM 1000 user node option.
12. On the Disk Format window, choose Thin Provision and click Next.
Cisco dCloud
NOTE: Be sure you choose Thin Provision or the lab will fail. In a production system, always choose Thick Provision.
13. Click Finish.

14. Verify that the Deployment Completed Successfully and then click the Close button.
15. Double click the server icon in the left frame to see the new Unified CM VM.
16. Right mouse click on the VM and choose Edit Settings.
IMPORTANT NOTE: The following eight steps are for lab purposes ONLY. DO NOT modify these settings in a production
environment. You are changing these settings to save on lab resources. Since you will not be using this VM to complete the lab, it
is ok to lower these settings. If you do not change these settings in the lab then you will not be able to power on the VM later.
17. Choose Memory and use the arrow to bring down from 4 to 2 GB.
Memory Allocation
18. Choose CPUs and click OK on the warning.
19. Change the number of virtual sockets to 1.
CPU Virtual Socket Configuration
20. Click the Resources tab.
21. With the CPU selected, move the slider bar for Reservation all the way to the left to bring the number down to 0.
CPU Reservation
22. Choose Memory and move the slider bar for Reservation all the way to the left to bring the number down to 0.
Memory Reservation
Cisco dCloud
23. Click Disk and then click Unlimited under Limit – IOPs.
24. Type 500 in the box.

Disk IOPs
This marks the end of the settings you would NOT change in a production environment.
25. Click the Hardware tab.
26. Click on CD/DVD drive 1.
27. Click on the Connect at power on check box.
28. Choose the Datastore ISO File radio button, and click the Browse button.
29. In the browse popup window, double click datastore1. Double click on the ISO folder. Double click on the CUCM and
CUC folder. Choose the Bootable_UCSInstall_UCOS_11.5.1.12900-21.sgn.iso file and click the OK button.
30. Click OK to close the VM Properties Dialog Window.
31. Make sure the VM is selected and click the console window button on the menu bar [ ].
32. On the console popup window, click the green start icon [ ].
33. After a few moments, you should see the ISO file boot and the Disc Found message box.
34. Click anywhere in the window. You will see the message To release cursor, press CTRL + ALT in the lower left of the
window. Remember this message when you need to release your keyboard and mouse from this window.
Release Cursor Message
35. Press the Tab key to highlight the Skip button and press the Spacebar key to continue.
36. Press the Tab key to highlight the OK button and press the Spacebar key to install the selected product (Cisco Unified
Communications Manager).
37. Press the Spacebar key to choose Yes on the Proceed with Install screen.
38. Press the Spacebar key to choose Proceed on the Platform Installation Wizard screen.
39. Press the Spacebar key to choose No on the Apply Patch screen.
40. Press the Spacebar key to choose Continue on the Basic Install screen.
41. Accept the default Time zone by pressing the Tab key and highlighting the OK button. Press the Spacebar key to choose OK.
42. Press the Spacebar key to choose Continue on the Auto Negotiation Configuration screen.
43. Press the Spacebar key to choose No on the MTU Configuration screen.
Cisco dCloud
44. Press the Spacebar key to choose No on the DHCP Configuration screen.
45. Input the following on the Static Network Configuration screen, and then choose OK to continue.
 Hostname: cucm2
 IP Address: 198.18.133.219
 IP Mask: 255.255.192.0
 GW Address: 198.18.128.1
46. Press the Spacebar key to choose Yes to set up DNS.
47. Enter the following for the DNS Client Configuration.
 Primary DNS: 198.18.133.1
 Domain: dcloud.cisco.com
48. Tab to OK and press the spacebar.
49. Input the following on the Administrator Login Configuration screen and choose OK to continue.
 Administrator ID: administrator
 Password and Confirm Password: dCloud123!
50. Input the following on the Certificate Information screen and choose OK to continue.
 Organization: Cisco Systems
 Unit: dCloud
 Location: Richardson
 State: Texas
 Country: United States
51. Choose Yes on the First Node Configuration screen to continue.
52. Input 198.18.128.1 for NTP Server 1. Choose OK to continue.
53. Enter dCloud123! as the Security Configuration screen password.
54. Choose No on the SMTP Host Configuration screen and continue.
55. Choose Disable All Call Home on System Start on the Smart Call Home Enable Page screen and choose OK to continue.
56. Input the following on the Application User Configuration screen and choose OK to continue.
 Application User Username: administrator
 Application User and Confirm Password: dCloud123!
57. Choose OK on the Platform Configuration Confirmation screen to continue.
58. You have finished the installation for Unified CM. It will have taken approximately an hour to complete the install. You will
continue in the lab with different Unified CM virtual machines that have been pre-built for you.
Cisco dCloud
59. You may now close the vSphere client. Remember to press the CTRL + ALT keys to release your mouse and keyboard.

Les 1000 Verites Scientifiques Du Coran 1

Uploaded by

Document Information

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

Les 1000 Verites Scientifiques Du Coran 1

Uploaded by

Copyright:

Available Formats

Cisco dCloud

Cisco Preferred Architecture for Enterprise Collaboration 11.6

Last Updated: 01-SEPTEMBER-2017

About This Demonstration

 About This Solution

 Scenario 1: Certificate Management

 Scenario 2: Call Control

 Scenario 4: Collaboration Edge

 Scenario 5: Bandwidth Management

 Appendix A: UC CA Certificate Installation

 Appendix B: Adding Client Server Template to Certificate Services

 Appendix D: Common Phone Profile Configuration

 Appendix E: Collaboration Edge Pre-Configuration

 Appendix F: Installing a Unified Communications Application on an ESXi Host

About This Solution

 Instant messaging and presence

 High definition video and content sharing

 Rich media conferencing

 Enablement of mobile and remote workers

 Business-to-business voice and video communications

 Unified voice messaging

This Cisco Preferred Architecture Enterprise Training lab includes:

 Scenario 1: Certificate Management

o Generate a CallManager CSR

o Downloading the tomcat and Call Manager CSR

o Download the Enterprise CA Certificate

o Review Certificates on Subscriber, IM&P, and Unity Connection

o Manage Cisco Meeting Server Certificates for Secure Service Interfaces

o Review Enterprise CA signed server certificate on Expressway-E Server

 Scenario 2: Configuration of Call Control:

o Classes of Services and Calling Search Spaces

o Calling Party Information Display on Phones

o Lightweight Directory Access Protocol (LDAP) Provisioning

o Intercluster Lookup Service (ILS) Configuration for Multi-Cluster Deployments

o User Data Service (UDS) Certificate Configuration for ILS

o Global Dial Plan Replication (GDPR) Configuration

 Scenario 3: Configuration of Conferencing:

o Configure SIP Profile

o Configure SIP Trunks

o Create a Media Resource Group List

o Enabling Clustering and Redundancy

o Create Call Bridge Cluster

o Configure Outbound rule for CallBridge

o Configure TMS for Scheduled Conferences

 Scenario 4: Configuration of Collaboration Edge:

o Mobile and Remote Access (MRA)

o Business-to-Business Communications (B2B)

o Cisco Unified Border Element (CUBE)

 Scenario 5: Configuration of Bandwidth Management:

o Application Server QoS

 Identification and Classification

 Queuing and Scheduling

o Enhanced Locations Call Admission Control (CAC)

 Device Mobility for Mobile and Remote Access (MRA)

o Unified CM / Endpoints (Call Control)

 LDAP Encryption configuration (LDAPS) for directory sync and authentication

o CAPF enroll Hardware Endpoints

o Move Unified CM Cluster to Mixed-Mode via CLI (soft e-token) Method

o Unified CM CAPF Enrollment for Jabber

o Create Secure Phone Security Profile and Apply to On-Premise Endpoints

o Confirm Secure Calling (Phone to Phone, Jabber to Phone)

o Cisco Meeting Server Secure Integration

o Secure Unified CM Integration with Unity Connection Next Generation Encryption

Table 2. Server Information