cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4016
Views
25
Helpful
37
Replies

TMS 14.4, TMSPE 1.2, and TMSXE 4.0 are now available on cisco.com

Kjetil Ree
Cisco Employee
Cisco Employee

Hi,

I'm happy to announce that TMS 14.4, TMSPE 1.2, and TMSXE 4.0 now are available on cisco.com.

 

TMS 14.4

 

TMSPE 1.2

 

TMSXE 4.0

 

The deployment guides and other documentation are in the process of being published to the Product Support section of cisco.com; I'll post direct links to them as soon as they as available.

As always, please read the documentation carefully before upgrading production environments to the latest software. smiley

Best regards,
Kjetil
 

37 Replies 37

Hi Kjetil,

Just a couple of questions on the upgrade path and pre-requisites, based on the release notes and Deployment guides (and even the actual Upgrade Guide) as listed above.

  1. Assuming you are using TMSPE with TMS, then am I correct in thinking that the ONLY version of TMSPE that will work with new TMS 14.4 is this new TMSPE 1.2 (and vice versa) - so which should be upgraded first?
  2. In addition, in the Release Notes for TMSPE 1.2 (page 11 and 12) it says that a pre-requisite for this installation is not only VCSs on x8.1, but also TelePresence Conductor version XC2.3, so:
    1. Does this mean that you you have to HAVE to have TelePresence Conductor in order to use TMSPE now? In the TMSPE 1.2 Deployment guide (page 11), it mentions that TelePresence Conductor is a require for "Collaboration Meeting Room", but what it you are not going to use this feature?
    2. In addition, do ALL VCSs that have been added to TMS require that they are updated to x8.1, or is it just the one that require provisioning?

 

Cheers

Chris

Chris -

I think Conductor is only required for the TMSPE collaboration meeting rooms, you can choose to not install that feature when you install TMSPE.  Even if you do install that feature, it still has to be configured within TMS to point to Conductor, so as long as you don't configure it, you should still be fine.  Probably best to just simply not install it if you don't have Conductor, as if you do install it, someone might go into TMS and configure the Conductor settings without realizing they can't use that function.

You could deploy a single Conductor VM, it could allow you to use the collaboration meeting rooms, since you can use Conductor with a single conference bridge without a release key.

Hmm, interesting as I didn't know about the no licence Conductor option, however, I don't think this will work for us. We have an, er, unusual setup in that whilst we maintain a lot of endpoints and VCS infrastructure across multiple organisations, all the MCUs are actually maintained by a national organisation for the entire education community in the UK (JANET - which stretches even further than our involvement across just Wales). As such I don't have any access to them or their setup.

As such, I haven't really looked much into these products, but I have a sneaking suspicion that we will need access to areas we don't manage.

 

PS - Oh an in case your wondering how we then do our scheduling the answer is simple - we don't! We use TMS as simple a management tool, the scheduling is taken care of but this separate JANET through a custom built portal.

Cheers

Chris
 

Hi Chris,

1) Yes, TMSPE 1.2 is the only TMSPE version that will work with TMS 14.4 (see page 66 of the TMS release notes). Upgrade your TMS first, then your TMSPE.

 

2-1) As Patrick says, the Conductor requirement is only applicable if you want to use the new CMR feature. If you just want to use device provisioning, FindMe, and/or Smart Scheduler, you can do that without a Conductor.

2-2) Negative, the X8.1 requirement only applies to the VCSs that are used for TMSPE provisioning.

 

-Kjetil

Thanks Kjetil. Great response.

WRT to the VCS being on x8.1, this is on our roadmap, but due to the required firewall changes, it might take some time. Whilst we don't necessarily use ALL the provisioning features for our monitored VCS, we do poll for Phonebooks. As such, we won't be able to make this upgrade for a while, I think.

Kjetil -

  1. I noticed in the release notes that the start/teardown buffers were removed, and replaced with "Allow early join".
    1. We use that to connect our conferences a few minutes early for troubleshooting issues, and to keep them active longer just in case of running over.  Besides going through all conferences in TMS and manually changing the start/end times to put in that extra time due to the buffers being removed.
    2. Could it be possible in the future to change the early join time?  Also, making it possible to automatically connect participants during this early time, instead of just starting the conference and leaving the participants to join themselves?
    3. I know the automatic extension feature could replace teardown buffers, but does a Content Server get factored in when it and one other endpoint is connected in a conference when using this feature, what is to prevent a conference from being recorded longer than it should be (ie: someone just left the room connected, but it's empty etc)?
  2. I didn't see any mention of how TMSPE behaves similar to TMS in a active/passive mode when using in a redudant TMS deployment.  How does TMSPE behave in a redundant deployment if installed on both TMS nodes, it wasn't mentioned in the TMSPE guides?
  3. I compared TMS 14.3 and 14.4 redundancy instructions when configured with a network load balancer.  In 14.3 the gateway of the TMS servers was set to the NLB, however in 14.4 the gateway is not the router, is this correct with the new active/passive behavior of TMS?
  4. Something to note, when I use IE9 for me on my computer the recurrence popup when booking a new conference appears greyed out, similar to how the conference booking page gets greyed out in the background behind it.  Firefox 20.x displays the popup just fine.

Thanks

Hi Patrick,

1) "Could it be possible in the future to change the early join time?"

You mean making the five minute value configurable? If so, do you want it configurable on a per conference basis, or as a TMS wide setting?

"[...] making it possible to automatically connect participants during this early time [...]"

We have no specific plans to change the feature so that participants automatically connect during the early join phase. If that's important to you or your customers, please go through more official channels to raise a feature request.

"[...] does a Content Server get factored in when it and one other endpoint is connected in a conference when using this feature, what is to prevent a conference from being recorded longer than it should be (ie: someone just left the room connected, but it's empty etc)"

There is no such mechanism or safeguard. If only a Content Server is connected to a bridge, the conference will not be auto-extended, but if a Content Server and an endpoint are connected, we extend as normal. If would be quite hard for TMS to know that a connected room actually is empty and take corrective action. :-)

 

2) TMSPE is active/active. No special TMSPE configuration should be necessary, apart from probing the user portal.

 

3) That's correct, the TMS servers are no longer required to use the NLB as their default gateway.

 

4) I don't think that's a known issue. Which exact IE version are you using, and on which operating system?

 

Regards,
Kjetil

If the early join might be configurable in some manner, possibly TMS wide, but configurable on a conference basis if one would choose a conference to start earlier or later than the TMS wide setting.  Similar to how the start/teardown buffers were configurable.

Because TMS doesn't auto connect anyone during the early time, we'll have to edit all of our conferences that have been scheduled already for this year to add the extra time at the start.  Shame a feature request had to be opened to try to get something added that was removed.  Why couldn't the auto connect feature of the buffers remain?  We often have conferences with external organizations or people at the offices/homes, to which the call doesn't always get answered right away, leaving us to redial them, hence using the start buffer before a conference is really supposed to start.

You are basically asking for thew old setup/teardown feature to come back. That is very unlikely to happen, as there were strong engineering reasons for removing them.

It sounds like the new Early Join feature perhaps isn't that suitable for your organization, but I strongly believe that the buffer replacements (i.e. Early Join + Ignore resource availability check on extension) are better for most customers, especially those who are using an external scheduling interface like Microsoft Exchange.

Regards,
Kjetil

I can understand why they were removed, I know Smart Scheduler wasn't compatible with the buffers, etc.  Would be nice if we could get at minimum an option to auto connect users during the early time.

I can make the automatic extension work for the teardown buffer, now that you've allowed the use to limit the number of extensions, choosing an amount that is reasonable to the users.  At least that can prevent an extremely long recording if a Content Server was involved and for some reason the conference was left running with the minimum participants required for it to function.

 

Also, the specifics about my computer where the recurrence popup was greyed out as was the conference booking page when it was showing, the only way to get out of the popup was to refresh the entire page, as I wasn't able to click on anything.

Windows 7 64-bit
IE9 32-bit

I couldn't find a client computer that actually had IE 9, but the problem was easily reproducible using the IETester tool. We'll target a fix for TMS 14.5, and I'll post the bug number as soon as it is replicated to the public Bug Search tool. Thanks for letting me know.

Regards,
Kjetil

I forgot to post the bug number, but here it is:

https://tools.cisco.com/bugsearch/bug/CSCuo76802

-Kjetil

Hi,

We released a TMS 14.4.1 patch yesterday, where the IE9 bug has been resolved.

Regards,
Kjetil