This article is now out of date and the HVD version of the Webex App can operate without CUCM registration.
The Problem: Centralized Servers
In a virtual desktop environment, centralized data centers with a “host pool” of servers are responsible for presenting virtual desktops to users. The servers are well equipped to process the typical business applications like Word, Outlook, and a browser. They are not however, equipped to handle the encoding and decoding of audio and video utilized in a conferencing service such as Webex, for hundreds or thousands of users.
Resulting nonoptimal media paths
When a user joins a Webex meeting via a “typical” desktop or laptop computer, the computer will transmit/receive video and audio by using the CPU and graphics card in the local computer. In the hosted virtual desktop environment, the device sitting on a user’s desk is not, by default, processing these media streams. Instead, the pool of servers in the data center are processing the data for every meeting participant.
The user, as a result, experiences terrible Webex audio and video quality because of two problems:
- The added load is not typically planned, as a result the host pools become overloaded.
- The network path is not always optimal. Instead of routing traffic directly between Webex and the end-user, traffic is forced to go through a data center. In many clients’ networks, and as SD-WAN grows, there are local Internet paths that are much more optimal than the data center path.
- Note, this problem is not solved natively with the deployment of the VDI app. But we feel strongly that eliminating issue #1 will drastically improve your performance. You still must ensure adequate bandwidth for your thin clients to send media through the Expressways in your data center.
The solution: Hosted Virtual Desktop app
Cisco released the Webex Meetings Virtual Desktop App specifically tailored for the virtual desktop environment in April of 2019. It isn’t necessarily new as it is built on the Virtualization Experience Media Engine (VXME) that was originally developed for Jabber. [Good read from Citrix on VXME here]
There’s been limited attention drawn to the feature and you’ll want to ping TAC to enable the feature before you proceed to test. We suspect Cisco is wanting to keep a close eye on the performance and any issues. Second, it is not a simple “turn it on” and forget it feature.
How it works in plain English
The Webex Meetings Virtual Desktop App will run within the virtual desktop and detect when you join a meeting.
The app will breakout a separate connection for audio and video (and desktop sharing) via the CUCM and Expressway, bypassing the central data center servers.
Your thin client sends its media to the Expressway-C, who then relays to the E, and then out to the Webex cloud, creating the most optimal method of connectivity for the clients.
This is identical to how a native Jabber client would place a SIP video call. See this excellent Cisco Live preso.
Similar to Jabber, the end result is spectacular. Users’ video/audio will no longer suffer.
Prerequisites
The list of prerequisites is extensive, but if you have Cisco Webex and Cisco Unified Communications Manager, you’re in luck. The most important items to look at will be the thin clients. You likely have many of the infrastructure pieces in place already to support this deployment.
If you don’t have CUCM, Webex, or Expressways, we can fix that! Click here to drop us a note!
Because prereq’s are subject to change, I’m linking to the release notes instead of listing them in this article: click here for release notes. Your VDI team needs to pay particular attention to the thin clients that are supported (not all are) and the releases of VMware/Citrix.
Implementation
First, you should grab yourself a copy of the admin guide [available here] and read through it start to finish.
The admin guide is presently in rough shape as they convert the documentation from Jabber VDI to Webex VDI. There’s a couple errors in there right now where they accidentally copied and pasted the wrong info!
Because of this, I strongly recommend reading the Jabber VDI guides as they are a bit more detailed than the Webex Virtual Desktop guide as it pertains to the installation process for the agent and client.
[Read the Jabber VDI guide here]Firewalls
Do you have firewalls on your internal network between branch sites, the data center, and your Expressway-C? If you use internal firewalls, refer to the admin guide to ensure you have rules enabled to support the flow of traffic between the affected devices. These communication paths were not previously required in your environment, so there is a high probability you will need to configure the new ports/protocols on your firewall.
No internal firewalls? Let’s move on.
CUCM configuration
In a nutshell, your CUCM needs a cop file, a reboot, and programming of the new Webex virtual devices. Follow along in the admin guide for the step-by-step as we’ll be discussing the activities as summaries.
Your CUCM is going to learn about a new device so we need to load a COP file and restart some services for it to be supported. Because the services are the important ones (CallManager, CTI, etc.) we think its probably easiest to just reboot the server. You’re free to just restart the individual services if you wish, but this could be a good time to get a proactive maintenance reboot on the schedule.
- Make sure your internal DNS entries are configured (SRV for cisco-uds pointing at CUCM).
- Download the COP file from cisco.com, and load it on your CUCM servers. Restart the services or restart the system, your call.
- Break out your Bulk Administration Tool skills and configure a new WSF device for each user that will participate in Webex meetings from their virtual desktop. We recommend using CSF naming conventions of WSF”FirstinitialLastname” such as WSFJDoe for Jane Doe.
- This WSF device is going to need a DN to register – so either reuse the user’s existing DN or create a separate DN just for WSF devices.
- Remember, this is basically a Jabber client!
- Setup the permissions for the user to include CTI enabled and CTI control of all devices. This is an atypical setting for seasoned CUCM administrators, so pay particular attention here. A bulk update is probably in order to make life easy.
- Make note of your SSO configuration. This is going to be a bear trap in deployment later because without SSO, your users are going to keep track of multiple passwords and we discourage that. In general you can think of the SSO situation as:
- If you don’t have SSO on Webex or CUCM, your users will have their Windows password, Webex password, and CUCM password to keep track of.
- If you have SSO on Webex and not on CUCM, your users will need their Windows password, and CUCM password.
- If you have SSO on Webex and CUCM, your users will need their Windows password.
- Grab some coffee with your friends that manage your virtual desktops.
HVD work
If you’re a telephony admin in a large company, this is going to require working with the team managing your HVD/VDI environment. If you’re a smaller shop, this work is probably on your shoulders. The good news is, you are likely familiar with loading apps in your HVD environment, so this will not be anything new.
Cisco has packaged up the apps for the supported platforms, and the admin guide gives the specific steps of loading it for your particular environment. [HVD-specific tasks]
We’ll assume you already have a domain-joined standard image (gold image).
- Install the Webex Meetings App Agent on the HVD
- Install the Webex Meetings client on the HVD
- Clone the image
You’re done with the data center now.
Thin client work
For Microsoft Windows and Ubuntu thin clients, deploy the app package (msi or pkg) on the thin client, deploy the Webex Meetings virtual app, and you’re done.
For Unicon eLux and HP ThinPro, you have a little extra work.
Unicon eLux clients require the use of Elias to build an image that includes the client. You then deploy that new image and your clients are ready to launch.
For HP ThinPro users, you need to get the applicable prerequisite files – “Cisco-Webex Meetings Virtual Desktop App <xx.x.x> -pre-reqs.xar” – from HP Support and install that before you install the client.
Note: Cisco’s instructions in the admin guide are suffering from a copy and paste error. Be sure to get the Webex Meetings pre-req’s and not the Jabber JVDI pre-reqs file.
You could deploy the app with a usb stick if you want to test it out in your lab, but larger environments are going to push the client packages via their package manager.
Webex desktop app
Phew!
We made it. Launch that client from your Thin Client and be expected to authenticate given one of the three scenarios covered in your SSO section earlier. Once you make it past authentication, the WSF client device should be registered in CUCM, and your thin client will be ready to join meetings and broker their SIP signaling and media through the CUCM + Expressway path, completely bypassing your HVD server pool.
MRA caveat
If you have remote (home worker) thin clients, you need to deploy Mobile & Remote Access (Collaboration Edge) in order to use the virtual app and redirect media through the Expressways. The deployment of the virtual app is essentially the same, but we do not cover the installation/configuration of MRA here.
Conclusion
This is one of the longer articles, but hopefully you have a decent picture of how Webex + VDI will work, the backstory of the JVDI roots, and you know the teams you need to engage within your company to get it deployed.
We’re here to help, so leave us a comment if you are encountering issues or if you want to brag that you got it done in one minute!
And as always, feel free to reach out to us if you’d like to discuss hiring Covene to help you with your implementation.