This is part two of a technical discussion of Cisco WebEx Meetings Server 1.0.  You can find part one here.

In this post we’ll cover integration of CWMS to Cisco’s UC infrastructure, some advanced configuration, the deployment scenarios my peer Jon Nelson and I tested in the CDW EFT lab and some design principles we developed that help CDW’s UC Solutions Architects design deployments with customers.  We’ll also briefly touch on what Cisco Early Field Trials do for CDW, and by extension, our customers.

To get right to it, once CWMS is deployed and operational, configuration and administration begin.  CWMS integrates to CUCM 7.1(5), 8.6(2) and 9.0 via SIP trunks.  Both Call-In and Call-Back conferencing are available.  Larger installs with multiple Media VMs use SIP REFERs to perform load distribution.  CWMS supports IPv4 and limited IPv6 operations and encrypted media.

An SSL certificate for CWMS is highly advised, and the certificate must list all machine VM hostnames (internal and external) as well as the VIP hostnames as Subject Alternate Names (SANs) to prevent clients from getting security warnings.  CWMS can automatically generate a CSR listing all SANs after all virtual machines, including HA, are deployed.

With the system configured and trunked to CUCM and SSL in place, and after a round of testing, end-users can begin hosting meetings.  User accounts can be specified manually, imported via a .csv, or automatically created via Single Sign-On (SSO) integration with Microsoft ADFS 2.0, OpenAM or any SAML 2.0-compliant SSO solution.  One thing to note: if SSO is used, SSO must also be available to users beyond the firewall, for example via ADFS proxy or Microsoft TMG-protected access, or meeting hosts will be unable to use web services (e.g. sign in to host meetings, use the web scheduler or use WebEx Assistant).

Thankfully a basic SSO install is relatively straightforward for experienced engineers.  CDW offers a canned SSO implementation engagement that a client can easily tag on to a CWMS install engagement that implements ADFS 2.0 integration to CWMS.  This offering is based on solution development conducted in our EFT lab with our Advanced Technology Services (ATS) Microsoft Practice coworkers.

In our EFT lab Jon and I boiled the main design decisions for CWMS down to these elements:

  • Is there interest in an HA deployment? This affects the amount of compute resources required, especially high port deployments.
  • What about Internet Bandwidth, Firewall load and PSTN capacity? Enterprises should be prepared for the new load CWMS will introduce, potentially considerable for high port deployments.
  • Does the Enterprise use Split-Horizon DNS?  This affects the overall deployment and could affect Enterprise firewall load.
  • Does the Enterprise have 10-Gigabit connectivity for the UCS servers?  This is required in 800-/2000-port installs.
  • Does the Enterprise run a supported version of CUCM?  If an upgrade is required, CDW can scope it and implement with the same engineer who would install CWMS as part of a larger project.
  • Does the Enterprise currently utilize SSO? If there is an interest (and there should be, as it lightens administrative load), CDW has a canned solution ready to go.

These are key questions CDW UC Solutions Architects cover with our clients looking for a collaboration solution based on CWMS, along with some information Cisco requires during the pre-sales cycle to release a new product hold.

For testing we conducted three total deployments:

  • A 50-port HA system with Split Horizon DNS and Public IP addressing for IRPs.  This system also used SSO via ADFS 2.0 in cooperation with CDW’s Microsoft Practice.  This system was also “trashed” in order to test recovery from backups.
  • A 50-port non-HA system with non-Split Horizon DNS and NAT for IRPs.  This system also used SSO via OpenAM.
  • A 50-port HA system with Split Horizon DNS and a Cold Standby deployment in a remote CDW EFT lab.  This system used local accounts on CWMS.

Deployment of the first system followed reception of the first beta software.  One of the key challenges was actually receiving the software from Cisco, since it was delivered as a very large OVA rather than installed from an ISO/DVD.  Overall deployment was fairly straightforward, despite the fact that some documentation was not yet available and some bugs existed at this point.  One other key technical challenge was figuring out the SSO configuration on both the CWMS and ADFS 2.0.  We performed integration to CUCM and then tested features of the CWMS software including the WebEx client, WebEx Assistant, audio features, video features and changing the system settings from their installation defaults and verifying the correct responses.  It’s amazing how much functionality there is in WebEx Meeting Center that just never gets used day to day.  We also thoroughly tested functionality of the IRP with blended meetings between internal and external participants and use of web GUI and WebEx Assistant through IRP.  Finally, we performed HA testing.  We simulated individual virtual machine failure by changing network assignments, and whole server/host failure by changing network assignments on the server’s uplinks to the EFT lab LAN.  As we performed this testing Jon and I recorded our activities to form the basis of our CWMS Test Plan for use by CDW engineers on engagements.

After proving out many features in our first deployment, we proceeded to deploy and test the second system just as rigorously.  The use of NAT for the IRPs led to the development of some additional best practices, as this deployment is not well documented by Cisco and is not available in their PEC labs.  This is especially useful to CDW’s engineers, as many clients use NAT for their DMZs, and with our tests, we could prove the solution worked.

Prior to the third deployment, Jon and I spent additional time working on what CDW calls “Solution Development” – the creation of pre-sales materials (our contribution consisted of mostly templates for sales) with CDW’s Solutions Lead for Collaboration Ken Snyder and others from our UC practice.  Simultaneously Jon and I created project methodology lifecycle documentation for CDW engineers to use in the field on their engagements – everything from project plan templates for Project Managers to discovery and design templates to test plans and training.

During the third deployment Jon and I used these documents in a trial run, adding enhancements as we went, to simulate a true client project with Jon acting as “the client” and myself in the “CDW Delivery Engineer” role.  We recorded our time spent carefully to develop a set of engineering implementation estimates for CDW UC Solutions Architects.  We also tested the Cold Standby recovery features.

With these deployments complete and Solution Development concluded, CDW was ready for CWMS to reach FCS.

The lessons we learned in these test CWMS deployments are a key reason CDW participates in EFTs:

  • Early discovery of bugs, and resolution before FCS
  • Early submission of feature requests to enhance “real world” deployment by our engineers and usability/maintenance/support by our clients and CDW Hosted Managed Services (HMS) teams, and (sometimes) resolution before FCS
  • Development of CDW Best Practices for deployment above and beyond Cisco recommendations
  • Development of CDW project lifecycle documentation before FCS
  • Training of CDW engineers before FCS

As I mentioned above my peer Jon Nelson (CDW Technical Architect for UC) and I participated in the CWMS Partner Beta using resources from CDW’s Early Field Trial (EFT) lab.  Together we identified 59 bugs pre-FCS, the most of any Beta partner.  We also filed 27 feature enhancement requests for inclusion in the product’s future release roadmap.

Here are some of what we considered the most important caveats in CWMS 1.0 (CDW filed feature requests around all of these items):

  1. There are some features of MeetingPlace that clients may want in CWMS but are currently unavailable.  These include: ability to launch meetings straight from TUI (ie reservation-less audio-only meetings), continuous meetings, ability to change prompts, blast out-dial meetings.
  2. CWMS does not yet fully hook into Jabber UC clients for presence state changes.  IE joining a CWMS meeting will update the status, but upon exit status will not reliably revert.
  3. No native LDAP/AD integrations are possible today – all integrations for users/passwords are via SSO (e.g. ADFS or OpenAM).
  4. Site and email customization is somewhat reduced from WebEx SaaS.
  5. No support for Lotus Notes (WebEx Assistant only supports Microsoft Exchange).

Solutions to many of these concerns are targeted for future CWMS releases.

I hope you enjoyed this thorough rundown of CWMS. Let me know your thoughts in the comments below and if you have any other questions on how this product could work with your organization.

3 thoughts on “Putting Cisco’s WebEx Meeting Server to the Test – Part 2

Comments are closed.