Just bringing you a few highlights about Conductor 2.3 which should align with Telepresence Server 4.0.

Conductor XC2.3 has a new API that will allow Cisco TMS to obtain conference information, capacity information, and provision conferences. The client can create a new ConfBundle with auto-dialed participants and conference aliases. It is important to note that these API provisioned conference details will only be available through the API and not the Conductor web interface. In short – you still need TMS for scheduling which isn’t a big deal.

Putting the pieces together the scheduling of TP conferences connecting TMS to Conductor is a welcome addition. I’m making an assumption that vTS 4.0 and TMS 14.4 will be available very soon. This should speed the adoption of the vTS and Conductor within the Be6000 and Be7000 platforms. I’m still not 100% positive how TMS and TMSPE with Exchange will play into this but I’m assuming those pieces will be available soon.

Most likely this will all align with announcements we’re going to hear from Cisco Live.

More Telepresence!

If you patch 8.1 to 8.1.1 and your Mobile and Remote Access stops working you need to regenerate your certificates.

During the patch from 8.1 to 8.1.1 the XCP/XMPP router service is being introduced. When modifying anything related to XCP/XMPP on VCS or Expressway you need to regenerate the certificates. The same applies when you modify or add XMPP chat node alias.

The certificates need to be regenerated on Core and Edge. Once applied a restart will have it take effect.

The documentation does not currently reflect that this is a required step and should be updated soon.

Upgrading a rather large Communications Manager cluster I needed to upgrade all of the subscriber nodes at the same time.

The general rule still applies when upgrading a Cisco CM cluster – Publisher upgrades first and do not switch to upgraded partition.

Now there is a certain point during the publisher upgrade that I can actually start upgrading on all the subscribers in parallel. Be sure you have the proper compute and MHz reservation because you don’t want to overload all subscribers at once.

1. SSH to your Publisher or get on the console
2. List the install logs
   1. admin:file list install install_* date
      
   2. install_log_2014-04-06.20.39.48.log
   3. dir count = 0, file count = 1
3. Search the most recent install log for “PRODUCT_VERSION”
   1. file search install install_log_2014-04-06.20.39.48.log PRODUCT_VERSION
      
      1. 04/06/2014 20:52:30 post_upgrade|PRODUCT_VERSION is 9.1.2.11900-12|<LVL::Info>
      2. 04/06/2014 20:52:30 post_upgrade|PRODUCT_VERSION_DISPLAY is 9.1.2.11900-12|<LVL::Info>
      3. Search completed
4. When the file search command finds the PRODUCT_VERSION string in the install log, you can start the upgrade of the subsequent nodes.
   1. If you want to upgrade the subsequent nodes in parallel with the publisher node, do not choose the Reboot to upgraded partition on either publisher node or subsequent nodes while configuring the upgrade options. If selected, the publisher node may complete its upgrade and reboot while the subsequent nodes are upgrading, which causes the upgrade of the subsequent nodes to fail.

When you are ready to activate the new version, you must activate the new software on the publisher node before activating it on all other nodes.