Enabling Medianet’s Metadata on Endpoints Running TC6.0 Through TMS

If you would like to bulk-enable Medianet’s metadata on Cisco endpoints running software TC6.0 and higher, you can do so using TMS Configuration Template with a custom API command. Here’s how:

  1. Navigate to Systems > Configuration Templates > Configuration Templates.
  2. Create new configuration template or edit an existing one.
  3. Click on ‘Select Advanced Settings’ tab and use the filter to search for ‘custom configuration’ for ‘Cisco TelePresence TC Endpoints’:
    TMS Custom Configuration Template
  4. Select the ‘Custom Configuration’ setting and click ‘>’ to add it to the settings list.
  5. Switch to ‘Template Settings’ tab and paste the following string in the ‘Custom Configuration’ line:
    <Experimental item="1">
    <NetworkServices item="1">
    <Medianet item="1">
    <Metadata item="1">On</Metadata>
  6. Save the template. You’re done!

Test the configuration by applying the new template to a single endpoint and confirm that there were no errors and the setting has been changed successfully.

VCS Alarm: ‘RxPLIManager Line: 54’

We had one of the VCSes raise an alarm a few days ago that reads as follows:

An unexpected software error was detected in ivy[14753]: SIGABRT (tkill(2) or tgkill(2))

A closer look into details reveals the following:

Stack 0x0000000000c2c407 RxPLIManager ppcmains/ivy/b2bua/offeranswer/sdp/RxPLIManager.cpp:54
0x00007f032c66f2a5 (InstructionPointer)
0x00007f032c9fab30 (__builtin_return_address(0))

Cisco has confirmed that it is a new bug with X8.1.1. The application automatically restarts, so there is no need to do anything other than acknowledge the alarm for the notice to go away.

User accounts are automatically disabled in CWMS 2.0 MR4

Update #2 07-18-2014: A hotfix cisco-webex-meetings-server- has been released for customers who are affected by the defect CSCup62113. The hotfix is available via special download only; to obtain access to it, please contact Cisco TAC.

Update #1 07-08-2014: Apparently, another outcome of the bug is that the Personal Conferencing accounts have been removed from all user profiles after users were temporarily deactivated in CWMS. There is a way to re-enable the old host/participant access codes if a user creates a new Personal Conferencing account (regardless whether the same or a new PIN is specified). The old Personal Conferencing host/access codes will not show up in the users’ profile or WebEx Productivity Tools in Outlook.

So I have upgraded our CWMS 2.0 environment to the latest maintenance release (MR4 or Everything went well and the systems tested successfully post the upgrade. Time to remove pre-upgrade snapshots of your CWMS VMs (don’t ever forget to do this, as snapshots left behind do have an adverse effect on VM performance) and call it a night. Well, it turned out that the newest maintenance release is bugged and this time it is a big one. If you haven’t upgraded to the latest maintenance release, but plan to do it sometime soon, you’d likely want to reconsider. Read on…

So I have learned today that all but two of my 5000+ users were deactivated in CWMS with a status “disabled on LDAP” (which, of course, isn’t true). Users can still authenticate with the CallManager (with which CWMS synchronizes), so directory synchronization with LDAP and LDAP authentication isn’t a problem. Turns out, CWMS would disable any user whose record hasn’t been updated in the CallManager within the past few weeks (8 to be precise, as claimed by a Cisco TAC engineer). There is no patch or hotfix available at this point, but a workaround is as follows:

  1. Make a change (any change) for the affected end user object(s) in the CallManager (you’d likely want to make the changes in bulk using BAT).
  2. Synchronize the users in CWMS
  3. Disable periodic synchronization.

I found it easiest to bulk update user objects using a query (Bulk Administration -> Users -> Update Users -> Query). I have made a copy of an existing Service Profile and saved it under a different name, then switched all of my users to that Service Profile using a query in Bulk Administration. Use Job Scheduler to verify that all records have been updated successfully.

Job Scheduler


Once the batch job completes successfully and you have confirmed that all records have been updated, proceed with synchronization of users with CUCM in CWMS.

Important: Do not forget to disable periodic synchronization!

CWMS Directory SynchronizationHope you did not have to go through this. I will update the post once a hotfix or an update with a fix becomes available. You can also save the bug CSCup62113 and add email subscription to receive updates on it in Cisco’s bug tracker tool.