VQ Conference Manager 4.5.1

This document provides guidance for :

• VQ Conference Manager VQCM 4.5.0
• Outlook Add-in for Office 2016 or Office 365
• Outlook Plug-in 3.1.34 for Outlook 2013 or above
• Appendix D provides a full list of VQCM documentation

Network Port Usage

VQ Conference Manager only accepts traffic on ports 443 (HTTPS), 80 (HTTP), 22 (SSH) (if SSH is enabled via CM-Admin), 6443 (Kubernetes API) and port 1234 (CM-Admin; see section “Conference Manager Admin (CM-Admin))

HTTP Port 80 is open as a convenience for browsers that default URIs to HTTP. A HTTP request on port 80 is automatically redirected to HTTPS on 443.

The Kubernetes API Port 6443 can only be accessed with a valid service account bearer token (signed JSON Web Token) derived from a certificate generated at system install.

CAUTION: The internet is a very unforgiving place. We do not recommend running VQCM with direct public access from the Internet. Please contact our support team if you have this requirement and we will advise on the possibility of service risk caused by the discovery of new CVEs.

What's new in VQ Conference Manager 4.5.1

4.5.1 is primarily a general patch release with fixes and improvements across Meeting Services, DMA, and Analytics. There also several customer requested/driven feature enhancements.

For a full list of changes, new functionality and bugs, please see the Changes in 4.5.1 and 4.5.0.

To upgrade, please mail support@vqcomms.com. We’ll then give you access to health-checks and, if all looks ok, the upgrade files. Customers ask, “why don’t you just give us access to the upgrade files?”. The answer is that when we did that, customers would do some very strange things and get could get themselves into a terrible mess. This way, we get very high upgrade success rates and a lot less stress on both sides.

What's new in VQ Conference Manager 4.5.0

 

The 4.x platform is performing well in the field. The installed base transition from 3.x to 4.x continues (and if you haven’t, you need to because 3.x is no longer supportable now that CentOS has gone end of support). The migration process works smoothly and big, complex, systems have successfully transitioned over to and deployed on 4.4.

4.5 builds on the 4.x story and begins the delivery of new DMA functionality beyond being a replacement for TMS; Certificate Management. The CUCM connector has a fantastic user interface and makes importing devices from CUCM into DMA a breeze.

As usual, there’s a good list of bug fixes and the on-going performance enhancement work has continued.

Metro 1.2 (including Metro for Teams) is available as a playbook install for 4.5 and it continues to improve.

The VQ Microsoft 365 Connector is available as a playbook, it will enable Hybrid Calendar functionality with Microsoft 365 Calendaring and external services such as Webex and Microsoft Teams (CVI) on the 4.5 platform. Please contact VQ Support for details and assistance.

For a full list of changes, please see the Changes in 4.5.1 and 4.5.0.

To upgrade, please mail support@vqcomms.com. We’ll then give you access to health-checks and, if all looks ok, the upgrade files.

Customers ask, “why don’t you just give us access to the upgrade files?”. The answer is that when we did that, customers would do some very strange things and get could get themselves into a terrible mess. This way, we get very high upgrade success rates and a lot less stress on both sides.

High Availability (“HA”)

Our path to HA has been long. We added HA at 4.3 and deployed to a very limited set of initial customers. Based on that experience, we’ve made further refinements to HA that support distribution between data centers. We expect to resume deployments of HA to an initial set of customers towards the end of March 2025 on VQCM 4.5. Our HA solution uses third party components for some of the most complex and highest-risk functionality. We’ve included the Enterprise version of Vault and the F5 BIGIP Virtual Edition Load Balancer. Our objective was to reduce risk by using market leading components. The HA system will consist of 4 nodes; two VQ 4.5 VMs and two F5 BIGIP VE load balancer VMs. The F5 BIGIP load balancers will be capped at 200 Mbps (million bits per second).

Customers who have ordered HA will be price protected; new pricing has been introduced for new HA Customers. Over time, we expect to be able to decouple the BIGIP VE components for customers who already have F5 BIGIP deployed. Initially, however, we are taking a very proscriptive position and all HA instances will include the BIGIP Virtual Edition VMs.

Migration policy for VQCM 4.x (US DOD Approved Product List “APL” certified)

VQCM 4.x is based on RedHat Enterprise Linux 8.4 and requires that customers migrating from the 3.x platform have a new VM and fresh install. The migration process will be to export data from VQCM 3.11.1 or 3.12.x and import it into VQCM 4.3 (or above).

Please also be aware that from VQCM 4.0, VQCM uses an updated license file format and legacy VQCM licenses will not be valid on VQCM 4. VQCM 4 includes RedHat Enterprise Linux 8.4 which has required the introduction of some new pricing options. The summary of the pricing changes are that the first non-HA node of VQCM 4 will be included as part of the purchase price (including 3.x purchases). Customers with Enterprise Agreements and multiple instances of VQCM will be charged for the second and subsequent VQCM nodes.

Details of the pricing model can be obtained via sales@vqcomms.com or via your Cisco partner. Cisco pricelists have been updated to reflect these changes.

Digitally signed install and upgrade images

Each release file (upgrade or archived appliance) comes with an associated OpenSSL digest file or Windows security catalogue file, both of which are created using a code signing certificate provided by DigiCert.

This is being done as part of our continually maturing security requirements and will provide customers and end users with the assurance that the product(s) they are downloading have not been altered.

NOTE: In the examples that follow, 3.6.1 has been used:

Downloading the correct files

As there are now multiple files to download it is worth clarifying the required files to avoid confusion, especially for those new to this process.

The image below shows the new layout of the download page. Under the VQ Conference Manager sections where users would normally find either the VM appliance or upgrade image file there are now two additional files. A .cat (Windows Catalog file) or .signed (A OpenSSL signed digest file). Each file has it’s extension type specified on the download button and the file description will state which OS this is intended for. Only the actual appliance files themselves (the VM or upgrade image) will have a user guide or release note download option, the two signing files will have these greyed out with n/a.

Figure 1: Download Page

If a user is running a Windows machine as their host, so the machine they will either be running the VQ Conference Manager instance from or checking the file integrity on, then they will need both the appliance image and the associated .cat signing file. If they are running Linux or Mac they will need the appliance and the associated .signed file.

It is important to note that these associated files are not required for the appliance to be run or used, only if users wish to ensure the integrity of the appliance file itself. The process for verification is covered in the sections below, please refer to the section which references your host OS for further details.

Linux and Mac

For Linux or Mac you will need the release file and associated digest file. This will follow the naming convention of the release file and end with the .signed extension. For example, for the file CM-3.6.1-appliance-upgrade.img the associated digest will be called CM-3.6.1-appliance-upgrade.img.signed.

You will also require the VQ Communications public key, which is available from the VQ Communications keybase profile (https://keybase.pub/vqcomms/code_signing_public.key). Simply download the public key to the same location as the release file and signed digest.

To verify the digest and release run the following OpenSSL command:

openssl dgst -verify <public_key_file> -keyform PEM -sha256 -signature <signed_digest> -binary <release_file>

So using the files mentioned above as our example the command would be:

openssl dgst -verify code_signing_public.key -keyform PEM -sha256 -signature CM-3.6.1-appliance-upgrade.img.signed -binary CM-3.6.1-appliance-upgrade.img

This should return the message Verified OK. If you receive a Verification Failure message there has been a problem and we would recommend contacting support@vqcomms.com before continuing with your upgrade or installation.

Windows

For Windows you will need the release file and associated catalogue file. This will follow the naming convention of the release file and end with the .cat extension. For example, for the file CM-3.6.1-appliance-upgrade.img the associated catalogue will be called CM-3.6.1-appliance-upgrade.cat.

For Windows verification there is no need to access the VQ public key. Opening the .cat file you will be able to view the signature and the certificate details.

To verify the signature against the release file you will need to run the following Powershell command:

Test-FileCatalog -CatalogFilePath <catalogue_file> -Path <release_file>

If we use the above example files the command would be:

Test-FileCatalog -CatalogFilePath CM-3.6.1-appliance-upgrade.cat -Path CM-3.6.1-appliance-upgrade.img

This should return Valid. If you receive a ValidationFailure message there has been a problem and we would recommend contacting support@vqcomms.com before continuing with your upgrade or installation.

If you are running PowerShell 5.0 or earlier than the Test-FileCatalog cmdlet will not be included as default in your Microsoft.PowerShell.Security module and you will need to update your PowerShell build to 5.1 or later.

CMS compatibility

CMS Version	VQCM 4.x Compatibility	VQCM 4.x Incompatibility
3.11	In Beta and currently being validated. No major changes impacting VQCM are expected
3.10	All versions from 3.10.0	-
3.9	All versions from 3.9.0	-
3.8	All versions from 3.8.0	-
3.7	All versions from 3.7.0	-
3.6	All versions from 3.6.0	-
3.5	All versions from 3.5.0	-
3.4	All versions from 3.4.0	-
3.3	All versions from 3.3.0	-
3.2	All versions from 3.2.0	-
3.1	All versions from 3.1.0	-
3.0	All versions from 3.0.0	-

NOTE:

• CMS versions below CMS 3.0 are not supported. Cisco stopped producing maintenance releases for CMS 2.x in March, 2022.

• If you try to connect to an incompatible version of CMS, the CMS node will not come online and you will see an error of "UnsupportedSoftwareVersion".

Browser Support

VQ Conference Manager's User Interface is browser based; it uses latest web technologies to ensure it is fast and responsive.

Evergreen browsers are recommended. We test and support the current stable release and 2 previous stable versions of Chrome, Firefox, Safari and Microsoft Edge. Internet Explorer 11 is supported but not recommended.

Kibana 7.10 does not support Microsoft IE 11.

Outlook OWA does not work with Safari on Mac. Use Chrome/Firefox

Outlook Plug-in 3.1.34

The changes in 3.1.34 covered improvements in how the plug-in interacts with the Identity Server during the authentication process.

If the plug-in is in idServerAuth mode, the plugin automatically opens a web browser (default browser) and there were some issue reported about the default browser not being able to launch. We added re-try steps to handle this condition.

This is the sequence the 3.1.34 plug-in uses:

• URI Opens in default browser

• if that fails try to open the URI in IE browser

• if that also fails we try to open the URI in browser with using shell to start the process (UseShellExecute = true)

Version 3.1.33 was not released. It was a build used for internal testing.

Version 3.1.34 can be controlled by a server-side manifest file to automatically upgrade if newer Outlook plug-in versions become available. Please read “Outlook Plug-in Automated Upgrades”.

Outlook Plug-in Virus Scanner compatibility

One instance of an issue has been reported where the plug-in would not display the authentication panel. The problem was isolated to the call-back-handler integrated with the plug-in being blocked by the virus scanner (Kapersky).

The solution was to exclude VQCallbackHandler.exe from the Kapersky virus scanner.

Standards based Authentication (OAuth2, OIDC and SAML2)

The authentication model changed at 3.1 and is now based on an Open Id Connect (“OIDC”) certified Identity Server that is now part of the standard VQCM product.

OIDC is an additional layer that “wraps” the OAuth2 model and makes it more appropriate (and secure) for use with modern web-architecture applications and services.

The onboard “Identity Server” is responsible for handling the question of whether a user is authenticated or not. It works with “Identity Providers” that are responsible for the authentication process. The supported Identity Providers that VQCM will work with are Active Directory/LDAP, Windows Authentication (Single Sign-On) and four variants of SAML 2: Okta, OneLogin, Duo and Microsoft ADFS (Active Directory Federated Services).

For details on configuring Okta, Duo and OneLogin SAML2, please see section “Configuring VQ-Admin to work with Okta, Duo and OneLogin SAML2” and for ADFS, please see section “”.

All of the VQCM API work with the OIDC authentication flows. The API clients are all the things that use the VQCM API namely: the web-based user interface, the Outlook Add-in, Outlook plug-in, Kibana and utilities such as Template Manager etc.

The default authentication mode is Active Directory/LDAP as the Identity Provider. However, the system can also authenticate against SAML 2 providers (Okta, OneLogin, Duo and Microsoft ADFS have been tested so far) and Windows Authentication.

With the introduction of Microsoft ADFS support from VQCM 3.3, the recommended path to enable Single Sign-On using Windows Authentication is to take the Microsoft ADFS route.

Microsoft ADFS is simpler to configure, requires less firewall port configuration and does not require software on an additional server.

VQCM Authentication and Expressway MRA

VQCM Authentication does not work with Expressway MRA (“Mobile and Remote Access”).

Expressway MRA does not pass all HTTPS headers transparently over the network boundary. OIDC authentication headers are included in the list of headers not passed through the boundary by Expressway MRA.

Enabling API Service Clients (Outlook Add-in/Plug-in)

By default, the Web based User Interface and access to Kibana are enabled.

The VQCM-Admin portal controls whether API clients such as the Outlook Add-in and Outlook Plug-in are enabled.

The default mode for the Outlook Add-in and Outlook Plug-in is disabled.

They must be explicitly enabled; this is performed from the VQCM-Admin Authenticate Clients page:

If you are running utility applications (such as TemplateManager, ImportEmailer or BulkEmailer), add new ClientID and Secret values which can then be entered into the config files for the utilities. Each utility can have their own API key or they can be shared; from a control point of view, each having their own is our recommendation.

If you do not enable the specific application (API Consumer), authentication requests from the application will fail with an error message "Unexpected authentication error" along with some explanatory text and an error instance number.

Fully Qualified Domain Names and Certificates

VQCM only works with FQDNs.

The OIDC authentication process and trust model is based on certificates; IP addresses are out and FQDNs are in.

VQCM will work with self-signed, non-trusted certificates and will detect and prompt for non-standard actions when they are used. We recommend, however, using trusted certificates; there is a growing trend by suppliers to only work with trusted certificates. A good example of this can be seen with the latest Chrome browsers. You can work with untrusted certificates but it will become increasingly difficult. It is also less secure.

DNS A-records will need creating before VQCM is installed; the install process prompts for them so please have them ready before you start installing.

If you enter FQDNs without having setup DNS A-Records, the install process will detect that no IP address has been defined on the A-Record but it does not check that the A-Record points to the IP address of the VM. If you have not setup the A-record or you set an incorrect IP address in the A-Record, this will result in Pods not being able to start and CM-Admin will show red Pod errors. You will need to restart the install process.

Three FQDNs are required:

FQDN	Description
vqcm.mydomain.com	User friendly URI for VQCM
login.vqcm.mydomain.com	Allows API clients to find the VQCM OIDC Identity Server
kibana.vqcm.mydomain.com	Admin friendly URI to access Kibana

The IP address associated with each FQDN should be the same.

NOTE:“login” and “kibana” are examples. You can use any value that are meaningful in your environment. For example, if a wild card certificate is being used, Subject Alternative Names (SANs) can be used

FQDN	Description
vqcm.mydomain.com	User friendly URI for VQCM
loginvqcm.mydomain.com	Allows API clients to find the VQCM OIDC Identity Server
kibanavqcm.mydomain.com	Admin friendly URI to access Kibana

In addition to the 3 mandatory certificates required, VQ also, by default, generates a self-signed signing certificate, that is used to sign authentication tokens. In most customer environments the self-signed authentication signing certificate is all that is required.

However, customers who want to upload a CA signed signing certificate can do so via the VQCM-Admin Certificates page:

CMS works with Fully Qualified Domain Names or IP addresses

VQCM connects to CMS nodes via IP address or FQDN and will accept trusted or self-signed, non-trusted, certificates.

If your CMS nodes use FQDNs, please ensure you have DNS A-records defined for each node. We do see the occasional support ticket where customers have issues connecting their CMS nodes with VQCM and the issue is that no DNS A-records have been defined for the CMS nodes.

The other problem that can cause issues is that the CMS nodes have not been configured with a DNS server. This causes problems because it means that CMS cannot resolve the address of VQCM when posting CDR records to VQCM.

Background: when a new Call Bridge node is added to VQCM, VQCM writes the FQDN address of its CDR Listener to the CMS node. The CDR events posted by CMS to VQCM pass state change information between the two systems; without them, VQCM does not know about call starts or participant joins/leaves with the result that nothing is displayed in the Activity page.

Outlook Add-in functionality

The Outlook Add-in requires Office 2016 or Office 365. It works on the Windows and macOS platforms.

Outlook Add-in screenshot showing active Spaces:

For information on how to install the Outlook Add-in, please refer to Outlook Add-in.

Additional Documentation

We continually add to our list of additional documentation. Please see Appendix D for the full list.

User Portal enhancements

The full set of documentation is now available online and is searchable. It provides a quick and easy way of finding what you are looking for.

Available from vqcomms.com; menu item “Resources and Knowledge Base”; no authentication is required to access the Knowledge Base.