Before you start

Before you start, you need to make sure that your environment meets the requirements of Meeting Management. Also, you need to have some information ready, such as details about your network settings.

Meeting Management can manage anything from a single Call Bridge to multiple clustered deployments. The VM requirements depend on your deployment size. See the capacity table below to determine your deployment size.

Capacity

	Small to medium deployments	Large deployments
Call Bridges	1-8 Call Bridges run on Cisco Meeting Server 1000 or 1 Call Bridge run on Cisco Meeting Server 2000	9-24 Call Bridges run on Cisco Meeting Server 1000 or 2-3 Call Bridges run on Cisco Meeting Server 2000
Call legs started (at peak time, across all Call Bridges)	10 call legs started per second	20 call legs started per second
Users signed in to Meeting Management at the same time	15 concurrent users	25 concurrent users
Meetings per week (across all Call Bridges)	10,000	10,000

Note: The numbers of Call Bridges listed are primarily based on expected call volume. If all connected clusters have the meeting management functionality disabled, then the VM requirements for small deployments will be sufficient for any deployment size.

Requirements for the Meeting Management VM

Check that your VM environment can provide the needed specifications for your deployment size.

Requirement	Small and medium deployments	Large deployments
Server manufacturer	Any	Any
Processor type	Intel / AMD	Intel / AMD
Processor frequency	2.0 GHz	2.0 GHz
vCPU	4 cores	8 cores
Storage	100 GB We recommend thick provisioning and eager zeroing.	100 GB We recommend thick provisioning and eager zeroing.
RAM	4 GB reserved memory	8 GB reserved memory
Hypervisor	ESXi 6.5 P07, 6.7 P05, 7.0 U2a	ESXi 6.5 P07, 6.7 P05, 7.0 U2a
Network interfaces	1	1

Note: The VM is configured for small to medium deployments. For large deployments, you must change the sizing manually during setup.

Note: If you have a medium size deployment and think you may need higher capacity later, then configure your VM for a large deployment.

Resilience

To add resilience to your Meeting Management deployment, you can connect up to 2 instances of Meeting Management to the same Meeting Server deployments.

Decide if you want to set up 1 or 2 instances of Meeting Management. They must be configured independently; each instance gets its information directly from the connected Call Bridges and from TMS. No information is exchanged between them. We recommend that the 2 instances of Meeting Management are placed in different locations so for example power outages or connection issues will not affect both instances at the same time.

Also, decide how you want to direct users to the appropriate instance of Meeting Management.

Network details, CDR receiver, and NTP

You need to know the following details before you set Meeting Management up on your network (terminal setup):

• Hostname for your Meeting Management

• IPv4 and/or IPv6 address

  You can enter manually, or choose DHCP/SLAAC

• Default gateway, if not using DHCP/SLAAC
• IP address for 1 DNS server, if required

Other details can be added when you complete the first time setup:

• CDR receiver address

  The CDR receiver address is the FQDN that Meeting Management will tell Call Bridges to send CDRs (call detail records) to. The CDR receiver address must be set correctly for you to see meeting information in Meeting Management.

  Note: Make sure that you set up a DNS record for your Meeting Management. Also, make sure that any firewalls are open for Call Bridges to reach the FQDN you set up for Meeting Management as CDR receiver address.

  Note: If you disable meeting management for all clusters then you do not need a CDR receiver address, but Meeting Management will show an error notification.

• IP or FQDN for up to 5 NTP servers, and any corresponding NTPv3 symmetric keys

  We recommend that you use the same NTP server for Meeting Management as you are using for connected Call Bridges and for your TMS server.

• Optional: IP for an additional DNS server

Users

Meeting Management supports locally managed users as well as user authentication via LDAP. You can choose to have only local users, only LDAP users, or both.

• Local users are added and managed locally on the Meeting Management Users page. These users are authenticated directly by Meeting Management.

  One local administrator user is generated during installation, and you can add more users after you have signed in for the first time. Local users are useful for setup and test, and for making LDAP changes without getting locked out of Meeting Management.

• LDAP users are added via mappings to existing groups on your LDAP server. Meeting Management uses your LDAP server to authenticate these users by checking their group membership when they sign in.

  Authentication via LDAP is recommended for general use and administration.

We recommend that you have at least one local administrator user account. This is to make sure that you can still access Meeting Management if there are LDAP issues. For general use in production we recommend that users are authenticated via LDAP.

Note: Because we recommend using LDAP in production environments, Meeting Management will always display a warning if LDAP has not been configured.

Users can have two roles:

• Administrators have full access to Meeting Management. Administrators will typically set up Meeting Management, change configurations, add users, and monitor and maintain the system.
• Video operators only have access to the Meetings and Overview pages. Video operators monitor and manage meetings, and they perform basic troubleshooting related to ongoing meetings. For instance, they may try to call a participant who got disconnected or check the call statistics if someone has audio issues.

For local users, the role is assigned to their user profile.

For LDAP users, the role is assigned to the LDAP group they belong to. If one user is in several groups with different roles, then this user will be assigned the administrator role.

User access via LDAP

For general use and administration of Meeting Management we recommend that users are authenticated via LDAP, so you should set up an LDAP server with the LDAP groups you need. We recommend that you create at least one group for administrators and one group for video operators.

Note: Meeting Management does not support nested groups. If a mapped group contains other groups, the members of those nested groups will not have access to Meeting Management.

Supported LDAP implementations are:

• Microsoft Active Directory (AD)

• OpenLDAP

  Note: memberOf overlay must be enabled for OpenLDAP

You need the following to connect to your LDAP server:

• Protocol (LDAP/LDAPS)
• LDAP server address
• LDAP server port number

• LDAP server certificate, if you are using LDAPS

  Certificate requirements:

  • The certificate chain should include the certificate of the CA that signed the certificate, plus any certificates higher in the certificate chain, up to and including the root CA certificate.
  • Your LDAP server address should be included in the certificate.

• Credentials for your LDAP bind user

  For security and auditing reasons, we recommend that you create a separate bind user account for Meeting Management.

• Base distinguished name (DN)

• Search attribute

  This is the LDAP attribute you want users to enter as username when they sign in.

For adding groups, you need:

• Distinguished name for each group

Local user access

We recommend that you have at least one local administrator user to make sure you can still sign in if there are issues with your LDAP setup. You can also use local users for test purposes or for making changes to your LDAP setup.

Note: For general use in production, we recommend that all users, both administrators and video operators, are authenticated via LDAP.

During installation, Meeting Management will create a local administrator user account which you can use to sign in to the web interface and complete the setup. The username and a generated password will be displayed in the VM console when you have set up Meeting Management on your network.

Note: After you sign in to the web interface for the first time, the generated credentials are only displayed on the console until the first time you restart Meeting Management. We recommend that you change the password immediately after you sign in.

You need the following to set up more local users:

• Username for each user

  Note: A username cannot be changed after you have saved a user profile.

• Optional: First name for each user
• Optional: Last name for each user
• Role for each user

• Password for each user, if required

  If you choose to use the built-in passphrase generator, you can use the generated passwords instead of defining them yourself.

  Users can change their password after they sign in.

Security policy settings for local users

You can set up the following security policies for local users:

• Require a minimum password length

  This is disabled until you select it. The default minimum length is 8 characters

• Enable a built-in passphrase generator

  The built-in passphrase generator combines words from a dictionary to suggest new passwords. The default number of words in a passphrase is 5, and you can choose any number between 1 and 8.

  If you want to use the built-in passphrase generator, you need to provide a dictionary.

  Dictionary requirements:

  • The dictionary must be a text file with one word in each line.
  • Characters must be UTF-8 encoded.
  • The file must not contain any null characters .
  • Maximum file size is 10 MB.

• Restrict password reuse

  This is disabled until you select it. The input fields are blank until you enter a value.

Supported browsers

Cisco Meeting Management is supported with the latest released versions of the following browsers:

• Microsoft Internet Explorer

• Microsoft Edge
• Google Chrome
• Mozilla Firefox

• Safari

The following technologies must be enabled:

• WebSocket
• HTML5
• JavaScript

Note: Internet Explorer does not force updates, so we recommend that you manually check that you have the latest version.

System log servers

Log storage has been restricted on Meeting Management. However, syslog records can be sent to a remote location. You can configure up to 5 external syslog servers to collect system logs.

We strongly recommend that you set up external system log servers. System logs are required for troubleshooting and support.

You need the following for connecting your log server to Meeting Management:

• Server address and port number
• Protocol (UDP/TCP/TLS)
• Certificate, if using TLS

Note: TLS connections must support TLS 1.2

Note: If you want to see all messages in full length, you must use a system log server that can accept and show messages with a length of up to 8192 bytes.

Audit log servers

Audit logs contain information on users' actions in Meeting Management, such as signing in, changing Meeting Management settings, or performing video operator actions.

Log storage has been restricted on Meeting Management, and locally stored audit logs are only available with the local system logs. However, separate audit logs can be sent to a remote location as syslog records. You can configure up to 5 external syslog servers to collect audit logs.

Audit log servers are optional, but may be required in your organization.

You need the following for connecting your log server to Meeting Management:

• Server address and port number
• Protocol (UDP/TCP/TLS)
• Certificate, if using TLS

Note: TLS connections must support TLS 1.2

Note: If you want to see all messages in full length, you must use a system log server that can accept and show messages with a length of up to 8192 bytes.

Specific hardware or VM requirements for the syslog servers will depend on your Meeting Server deployment and your Meeting Management usage.

Licensing of the Meeting Server

Meeting Management is mandatory with Meeting Server 3.0 or later as Meeting Server depends on Meeting Management for licensing.

For each instance of Meeting Management, you can choose Smart Licensing or no licensing.

For resilient deployments, use only one instance of Meeting Management for licensing to avoid double reporting of usage. Set the licensing mode to Smart Licensing on one instance, and set it to no licensing for the other instance.

Note: All Meeting Server clusters must be connected to an instance of Meeting Management that has licensing enabled. Only disable licensing for one instance of Meeting Management if you have a resilient deployment and the other instance of Meeting Management has licensing enabled.

For Smart Licensing you need the following:

• You must have a Smart Account for your company with a dedicated Virtual Account that will be used by only one instance of Meeting Management.

  To request an account, talk to your Cisco account team or go to Cisco Software Central.

• The appropriate licenses must be allocated to the Virtual Account that Meeting Management will use.

  Note that one Virtual Account can be connected to one instance of Meeting Management. Also note that all licenses in one Virtual Account are shared between all the clusters that are connected via Meeting Management.

  If you wish to license a cluster separately, then connect it to a different Meeting Management deployment and Virtual Account.

• You need to determine whether you can connect directly to the Cisco Smart Software Manager, or if you need a proxy. You can use your own proxy server, or you can use the Cisco Transport Gateway.

  If are using a proxy server, then you must have address, port number, and certificate available so you can Edit Transport Settings.

• Optional: For purely on-premises environments it is possible to use Cisco Smart Software Manager On-Prem (SSM On-Prem) which only connects at specific times to exchange data. Meeting Management supports version 8-202008 or later.

  Note: If you try to connect to Cisco Smart Software Manager On-Prem and it refuses to authorize Meeting Management, log into your SSM On-Prem and check whether the authorization is failing due to the Active Call Bridge Node license. If yes, resynchronize SSM On-Prem to your Smart Account and the problem will be fixed.

  If you are using Smart Software Manager On-prem (satellite), then you must have address, port number, and certificate available so you can Edit Transport Settings. For gateway address, use the format http://<SSM onprem address>/SmartTransport or https://<SSM onprem address>/SmartTransport depending on your setup.

Certificate for Meeting Management

Meeting Management uses a certificate to identify itself to browsers and to Call Bridges.

During setup, Meeting Management generates a self-signed certificate which you can use during initial configuration. In a production environment, you must replace the self-signed certificate with a certificate signed by a CA (Certificate Authority). You can use an internal or external CA, depending on the requirements in your organization.

Certificate requirements:

• The certificate chain should include the certificate of the CA that signed the certificate, plus any certificates higher in the certificate chain, up to and including the root CA certificate.

• Your CDR receiver address, as well as any addresses your users will use for the browser interface, should be included in the certificate. You can use the SAN (Subject Alternative Name) field of the certificate if more addresses are needed.

  Note: When the SAN field is used, Meeting Management does not look at the Common Name. The CDR receiver address must be included in the SAN field.

Note: Meeting Management has no capability to create certificate signing requests. Use a dedicated tool, for instance the OpenSSL toolkit, to create your private key and a certificate signing request.

Note: If you are setting up 2 instances of Meeting Management, we recommend that each instance has its own certificate

Call Bridge or cluster prerequisites

Before installing and configuring Meeting Management, ensure your deployment meets these prerequisites:

• A user account on the Meeting Server API . Meeting Management connects to Cisco Meeting Servers via the API. For security and auditing reasons, we recommend that you set up a separate account for Meeting Management. If you are using more than one instance, then you need a separate account for each instance of Meeting Management.

  For information on how to set up an account, see "Accessing the API" in the Cisco Meeting Server API Reference guide. You can find it on the Programming Guides page on cisco.com.

• CDR capacity. To get information about meeting activity, Meeting Management configures itself as a CDR (Call Detail Records) receiver for each Call Bridge. Ensure the Call Bridge has suitable capacity for each instance of Meeting Management.

  Note: If you use Meeting Management only for licensing and provisioning for a cluster, then you do not need CDR capacity on Call Bridges in that cluster.

• NTP server. A time server must be configured for each Meeting Server in your deployment to make sure that Call Bridges and your Meeting Management are synchronized. We recommend using the same NTP servers for your Meeting Management and for your Meeting Server deployments. You may also require keys for your NTP server(s).
• Optional: Recorder. If you want to use Meeting Management to start and stop recording, a Recorder must be configured on a Meeting Server within the deployment.
• Optional: Streamer. If you want to use Meeting Management to start and stop streaming, a Streamer must be configured on a Meeting Server within the deployment.

• Optional: Settings required for Move participant. If you want to move participants between meetings, there are specific requirements to your Meeting Server deployment. In particular, note that participants using SIP endpoints cannot be moved if they are provisioned through Cisco Expressway. In addition, load balancing must be configured on the Meeting Server.

  For more information, see "Limitations when moving a participant" in the Cisco Meeting Server Administrator Quick Reference Guide: Moving a participant between conferences using the API

Supported Cisco Meeting Server version

Make sure that your Meeting Server version is supported with Meeting Management.

Meeting Management 3.4 is only supported with Cisco Meeting Server version 3.4.

Supported TMS versions

Recommended	Minimum
15.10 or later	15.9 or later

TMS prerequisites

Before installing and configuring Meeting Management, ensure your deployment meets the following requirements:

• Call Bridges connected to TMS. All your Meeting Server clusters must be connected to TMS.

  For instructions, see the "Cisco Meeting Server (Acano) / TMS Integration and Scheduling API Guide". You can find it under "Configuration Examples and TechNotes" on the Cisco Meeting Server Documentation page.

• A Site Administrator user account. For security , troubleshooting, and auditing reasons, we recommend that you set up a separate account for Meeting Management. If you are using more than one instance of Meeting Management, then create a separate account for each of them.

  For instructions, see the TMS API documentation, Cisco TelePresence Management Suite Extension Booking API Programming Reference Guide.

  Note: The same account is used for accessing TMS phone books and for getting information about scheduled meetings.

• NTP server. A time server must be configured for your TMS server to make sure that Call Bridges and your TMS server are synchronized. We recommend using the same NTP servers for your Meeting Management and for your TMS .

• Optional: Automatic MCU failover disabled . In case of failure, Automatic MCU failover moves scheduled meetings from one system in TMS to another. This could be from one Meeting Server deployment to another, but it could also be to a different type of system, such as MCU.

  As a result, a meeting may appear as scheduled in Meeting Management, but it will never become active, and video operators cannot monitor or manage the meeting using Meeting Management.

  For instructions, see the online help in TMS.

• Optional: Same names for clusters in TMS and Meeting Management. For administrators, it is helpful if you use the same name in TMS for the Meeting Server deployment as you use as cluster display name in Meeting Management. For operators, it is helpful if the name for the primary Call Bridge in Meeting Management can easily be associated with the name for the Meeting Server deployment in TMS.

• Optional: Phonebook contacts using supported protocols. if you want to use TMS phonebooks in Meeting Management, then make sure that all contacts in the phonebooks you assign to Meeting Management can be reached by your Meeting Servers.

No extra TMS license is required for you to connect Meeting Management to TMS.