Software Upgrade; Statistics And Monitoring; Cisco Tms Configuration - TANDBERG TELEPRESENCE MANAGEMENT SUITE - ADMININSTRATION GUIDE 13.0 Administration Manual

Software upgrade

Software upgrade on remote systems is set up in the same way as software upgrade on internal
systems. However, the mechanism used to upgrade the system is different. When you have
scheduled the upgrade, Cisco TMS will say that the upgrade went successfully. What has happened is
that Cisco TMS has put the upgrade on hold until it gets a boot event from the system. When Cisco
TMS gets this boot event, it will see that an upgrade has been scheduled for that system. On the reply
to the boot event, Cisco TMS will send the endpoint a URL where it can get the software package.
This URL is defined in Administrative Tools > Network > General Network Settings. It is
recommended that the directory is left to the default (tms/public/data/software) as this is where Cisco
TMS populates its list of packages from (Systems > System Upgrade > Software Manager). In other
words, if you provide a different URL, you might end up scheduling an upgrade with a package found
in the list that is not found in the URL specified.

Statistics and monitoring

The statistics and monitoring of the remote systems will be made up the same way as systems that
are on the LAN, by sending event traps to Cisco TMS. As for retrieving status and detailed call
information ('status.xml' and 'history.xml'), these are sent every 15 minutes. The configuration of the
system ('configuration.xml') will be sent on demand (Clicking Force Refresh in Cisco TMS) or when
doing changes in Cisco TMS.
Ad hoc calls will not be shown for systems behind a firewall as the TMSLiveService service is not able
to contact the system to get information about the call.

Cisco TMS configuration

To allow for the remote systems to communicate with the Cisco TMS server, Cisco TMS needs to be
reachable from the remote system. There are several ways that this can be done:
Alternative:
Put the Cisco TMS in
public
Put the Cisco TMS in
DMZ
Use a proxy
Have two Cisco TMS
servers, one on the
inside and one in DMZ
talking to the same
database
Cisco TMS Administration Guide
Description
This option provides less security, and makes the Cisco TMS vulnerable for
attacks directly over the Internet.
This option provides a bit more security. Port 80 (HTTP) needs to be open in
the firewall to allow for incoming traffic.
This option provides the best security without having to have two separate
Cisco TMS servers, and is set up by having the proxy forward to the Cisco
TMS server requests that are made to the management address path of the
Cisco TMS server.
/tms/public/external/management/systemmanagementservice.asmx
/tms/public/feedback/code.aspx
/tms/public/external/phonebook/phonebookservice.asmx
/tms/public/feedback/postdocument.aspx
This will allow you to add and manage the internal and external systems
seamlessly, but requires some extra configuration of firewalls and the
external Cisco TMS server.
The Cisco TMS server in the DMZ should only be accessible on port 80 from
the Internet, and can also be limited to only respond to connections, but not
open any new connections. The Cisco TMS in the DMZ must be able to talk
to the SQL server on the inside of the network, but this can be limited to one
port only. It is recommended to use a limited user with only read/write
permissions to the tmsng database for this (doing upgrades of the Cisco
TMS server will require db_owner permissions to the tmsng database), and
to disable the XP_CMD_SHELL command on the SQL server for security
reasons.
All Cisco TMS services on the Cisco TMS server in the DMZ must be
disabled to prevent the Cisco TMS server in the DMZ from trying to contact
Support for remote systems
Page 17 of 37