I'm happy to announce that TMS 14.4, TMSPE 1.2, and TMSXE 4.0 now are available on cisco.com.
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.
Links to additional documentation:
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.
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.
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.
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.
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?
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.
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
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.
What versions of IE are supported with TMS 14.4, I'm running IE11 in compatibility mode (because of other applications in our organization that require it), and I'm getting the bottom status bar that contains the login name/server time/serial number/server information at the top just below the TMS menu bar. See attached image.
There seems to be some other strange behavior with IE11 running in this mode as well, with the web interface, doesn't seem to like it. I didn't have any issue running IT outside of compatibility mode. Such as System Navigator appearing very small/short on the page, shadows from the system menus when expanding over them are showing in different places off to the side of the actual menu.
Would be very nice indeed if I could override TMS as far as maximum video calls goes when adding "Room" instead of locking it at "1".
Thanks, I'll see about updating IE on my computer, or use Firefox when needing to schedule recurring conferences in the mean time.
Have a question on the redundancy deployment and the URL probing. I noticed that when the URL isn't probed or visited that in the diagnostics it shows TMSWeb as offline, will that cause TMS to switch to the passive node? I'm waiting on one of our system admins to check if we can probe the TMS address provided with the NLB, if not, we have another monitoring application that can do it for us.
"[…] when the URL isn't probed or visited that in the diagnostics it shows TMSWeb as offline, will that cause TMS to switch to the passive node? […]"
It won't, at least as long as neither node is being probed. TMS is counting the number of active TMS services + IIS on both nodes, and if one node has more active services than the other, it will be promoted to being active. If no one is probing IIS, and all services are running, it will be 6 vs. 6, and no failover will be initiated.
As a feature request it would have been a good idea to incorporate load balancer functionality within TMS Server which would save additional administrative task of configuring F5 for probing
The functionality i am referring is similar to Polycom CMA 5000 which has inbuilt NLB with end user/endpoint referring to virtual IP which internally probes for active server
@jigneshjani, the user name is normally 'sa'.
@uddinabu1, are you sure you used the correct credentials, and that the database server is set up to accept remote connections?
I have two points for discussion:
1) I have a fresh installation of TMS 14.4 and I receive email notification that "Check for Software Updates" failed even though I disabled it in the Network configuration using "Automatically Check for Updates" set to No. After this I rebooted the TMS server but I receive this email every second day...
2) Do you plan to add support for "new" Polycom endpoints e.g. Group300/500/700?
I can find an answer to my second question:
But is there any plan to add the support?
1) That's not a known issue, I'll look into it.
2) There are no specific plans to add support for new Polycom endpoints.
1) CSCuq11686 - Cisco TMS checks for software updates, even when Network Settings > Automatically Check for Updates is set to "No".
I don't suppose there is a bug that states that TMS is not actually very good a checking for updates, even if "Network Settings > Automatically Check for Updates" is set to "Yes"!