R M S N e t w o r k :

Transcription

1 RMS NETWORK WHITE PAPER AMX R M S N e t w o r k : T e c h n o l o g y W h i t e P a p e r

2 Table of Contents Table of Contents 2 Overview: 3 Resource Management Suite (RMS) Requirements: 4 RMS Network Configuration: 7 Security 8 Network Bandwidth 10 NetLinx Master Network Details 14 Database Utilization 15

3 Overview: AMX Resource Management (RMS) is client/server applications where the NetLinx system acts as the client and the RMS server listens for connections from NetLinx systems. NetLinx and the RMS server communicate using TCP/IP sockets. In order to establish communication, the NetLinx system needs to have a routable and resolvable IP address for the RMS server. This can be accomplished with a variety of Network configurations including Intranets and Internet This white paper is designed for information technology (IT) professionals who are responsible for planning and designing AMX Resource Management Suite systems for their companies. This white paper provides details on RMS Program requirements, RMS Network configuration, how RMS and NetLinx consume bandwidth under different configurations and analyze the incoming and outgoing client traffic. System professionals can use the statistics and information contained in this white paper to better understand network bandwidth loading, AMX Resource Management Suite includes MeetingManager, ClassroomManager, WorshipManager, HomeManager, IntelligentManager, ExhibitManager, and VenueManager. The name RMS or RMS Server will be used to describe all these products in the remainder of the document.

4 Resource Management Suite (RMS) Requirements: Technical Details Available in multiple versions for specific vertical markets: Server details: Supports Windows Authentication for user and access management Users view may be managed by administrator Redundant server support with automatic failover using Microsoft Cluster Services Supports IPSec the new security standard network access and the Internet SNMPv3 for additional IT monitoring RMS Supported Scheduling Systems: Microsoft Exchange Server 2007 Microsoft Exchange Server 2003 (SP2) Novell GroupWise 8 Lotus Notes R8 Planon version FO-SE 4.33 matchcode g CollegeNET R25 v.1.8 PeopleCube Resource Scheduler 8.5 SP2 Dean Evans EMS Enterprise 5.0 EMS Professional 11.0 EMS Lite 7.0 EMS Campus 2.0 EMS Workplace 5.0 EMS Legal 5.0 System Requirements Microsoft Windows 2003 with IIS 6.0 or 2008 Server with IIS 7.0 or greater (32-bit only) Processor: Intel Pentium IV 3 GHz (x86) or Intel Pentium Dual/Quad Core 2.0 GHz Memory: 2 GB RAM Hard Disk: 500 MB Hard Drive allocation for RMS files Adobe Acrobat Reader MDAC 2.8 (included) Supported Databases Microsoft SQL Server 2008 Express Edition (for systems with less than 300 rooms only; download available free from Microsoft) Microsoft SQL Server 2008 Standard Edition Microsoft SQL Server 2008 Enterprise Edition

5 Microsoft SQL Server 2005 Express Edition (for systems with less than 300 rooms only; download available free from Microsoft) Microsoft SQL Server 2005 Standard Edition Microsoft SQL Server 2005 Enterprise Edition Supported Web Browsers Microsoft Internet Explorer 7 and 8(PC) Mozilla Firefox 2.0 (PC & Mac)

6 Additional System Requirements Microsoft.NET Framework 2.0 Internet Information Services (IIS) 5.0 (for Windows 2000 servers) Internet Information Services (IIS) 6.0 (for Windows 2003 servers) Adobe Acrobat Reader or later Microsoft Outlook 2000/XP/2003/2007 (only needed if RMS is configured to work with a MS Exchange scheduling system) Novell GroupWise Client 6.0/6.5 (only needed if RMS is configured to work with a Novell GroupWise scheduling system) Lotus Notes R5/R6 Client (only needed if RMS is configured to work with a Lotus Notes scheduling system) Technical Notes RMS must be installed on a dedicated server class machine. For RMS systems with more than 300 rooms, the database must be installed on an external database server and not installed on the same server machine as the RMS software. RMS is capable of supporting multiple (up to 12) instances of Scheduling on a single NetLinx Master. If you intend to run multiple instances of Scheduling on a Master, then that Master should be dedicated solely to RMS Scheduling only.

7 RMS Network Configuration: Client-Server Configuration In order to communicate with RMS, a NetLinx system must have the RMS modules added to it s programming by a qualified NetLinx programmer. The RMS module includes the core API and communication stack that allows Netlinx to communicate with RMS. Since each NetLinx system acts as the client, it must be configured to communicate to the RMS server using the 'SERVER-' command in NetLinx programming. NetLinx can accept either an IP address or a Hostname for the server. NetLinx supports DNS so if you are using a Hostname, the Hostname must be registered with the DNS server that NetLinx has been configured to use. The DNS server configuration will be picked up automatically through DHCP if the DNS servers are registered with the DHCP server. For more information on configuring DNS servers in NetLinx, see the NetLinx master s instruction manual. Optionally, the server IP or host name can be placed in a file called ServerInfo.txt and placed in the RMS directory of the NetLinx master's file system. If this file is present, the RMS communication module ignores the SERVER- command and uses the address supplied in the file. Enter the IP address or hostname on a single line using a text editor and FTP the file to the NetLinx master. If the RMS directory does not exist, you can create it can place the file in the directory. IP Port Options By default, NetLinx and RMS communicate using TCP/IP port Port 3839 is registered to AMX Resource Management Suite with IANA ( This can be changed to suite your particular facility but it must be changed in both the RMS server software and each NetLinx systems. In the RMS server, this is accomplished through the Configuration Wizard. In NetLinx, this is accomplished through the 'SERVER-' command in NetLinx programming. If using the ServerInfo.txt file, append a ":" and the port number to the server IP address or host name. MeetingManager 1.0 used port 9090 for communications. If you are upgrading from MeetingManager 1.0, you may wish to continue to use port During the upgrade process, you are prompted to change to port 3839 or continue to use port If you change to port 3839, you need to upgrade all NetLinx systems to use the modules from the RMS 3.3 SDK. You can use port 9090 with both MeetingManager 1.0 and 2.0 NetLinx systems. Once a NetLinx system has been programmed with the RMS modules and the server's IP address or Hostname, the NetLinx system automatically connects to the RMS server.

8 Security Application Security RMS can be configured to not require secure logins, require secure logins but allow for anonymous access or require secure login with no anonymous access allowed. RMS users are configured with a username, password and security level that determines their access to the system. The account management options are configured through the Configuration Wizard. The Configuration Wizard offers two options, Use Account Management and Allow Anonymous Access. RMS uses internal user management in order to track user rights. RMS utilizes MD5 challenge/response for validating user credentials. RMS user rights are not integrated with the rights assigned in the Windows Domain. If a user logs in with a valid username and password, their access to pages is determined by the role set for that user. A role is a collection of user permissions to which users can be assigned. At any point, a user can choose to log out. If a user closes the browser or does not access the server within the user's session timeout period, the user is automatically logged out. Any attempt to access an Admin page from a new browser session or a "stale" browser session will require the user to login again. NTFS Permissions Certain NTFS permissions are required for the users of the web pages to access resources on the MeetingManager server. The configuration wizard automatically creates the appropriate NTFS permissions for the web users. Windows Authentication The RMS ASP web application supports the use of Integrated Windows Authentication. The RMS services will automatically detect if the RMS web application is configured for Integrated Windows Authentication and apply the following behavior: Administrative Web Pages In the RMS administrative web pages, the web application will auto detect the integrated windows username and attempt to authenticate this user account to a user account in the RMS database. If the username is defined in the RMS database, the user is automatically logged on and the user's security permissions are applied to the user's session. If the integrated windows username is not found in the RMS database, a login prompt will be provided to manually log on to the RMS administrative pages. If using Integrated Windows Authentication, the user's password in the RMS database need not be synchronized with the actual domain account, this password will not be used in the authentication process. User Scheduling Web Pages: In the RMS user scheduling web pages, the web application will auto detect the integrated windows username and only allow appointment record modification to appointment records that the user created. Attempting to access or modify an appointment created by another user is restricted.

9 The integrated Windows usernames need not be defined in the RMS database. The web application will simply restrict access to appointments based on the appointment's organizer username.

10 Network Bandwidth Network Measurement Methodology The network traffic captures were done using Ethereal Network Protocol Analyzer, version Each data capture was performed according to the following steps: Start capture. Perform the action to measure. Wait until there is no more traffic. Stop capture. Save the capture. Report results. All test utilized the MeetingManager sample code distributed with the RMS SDK loaded into an NI Installation In this scenario, a network administrator installs and RMS application from CD or executable file. The installation wizard runs then prompts the administrator for various data. During the installation course, there are opportunities to run tests for connections to , paging, and scheduling servers. Each of the listed cases is expected to generate measurable network traffic. Use Case: Configuration Wizard Running Configuration Wizard Send Test Test mailbox connection for scheduling interface (Novell GroupWise) Total Sent by Server Sent by client Send Test Test Mailbox Connection Administration For these cases, the administrator will be accessing the RMS server from a remote PC through a web interface. These activities are expected to generate measurable network traffic. Use Case: Login Log In to web interface: Logon Logoff Use Case: Add User

11 Add a user and test notification Add User (HTTP) Test Notification (SMTP) Use Case: Reset Parameter Reset a parameter Reset Parameter (HTTP) Reset Parameter (RMS: 3839) Use Case: HTTP Connection Connect to a NetLinx system via HTTP Connect HTTP Use Case: FTP Connection Connect to a NetLinx system via FTP Connect FTP Use Case: Telnet Connection Connect to a NetLinx system via Telnet Connect Telnet Events

12 The Event Scenario does not necessarily require human intervention. Events occur either by a device triggering a threshold, a timed function occurring, or a system being brought on-line manually. Use Case: NetLinx System Connection New NetLinx system is connected NetLinx Connected Use Case: Parameter Notification Device parameter threshold exceeded with a single notification Parameter Exceeds Threshold (RMS: 3839) Notificatio n Use Case: RMS Communications Ping RMS Server Ping and Ping Response Single System Ten Systems Use Case: Appointment Synchronization Appointment synchronization between RMS and NetLinx with one appointment Appointment Synchronization Use Case: Appointment trolling Appointment trolling between RMS and Exchange Server 2003 No New Appointments One New Appointment

13 Scheduling & Help End Users are allowed access for the purpose of scheduling rooms, requesting room presets, and administrating electronic signage. An additional scenario places an end user in front of a touch panel with the ability to execute a preset, extend a meeting, request help, and send messages to the RMS server. For each of these cases, significant network traffic is anticipated. Use Case: New Appointment Web Interface: Save an appointment with recurring instances, presets, and welcome text/image. The welcome image is a 181KB PNG image. New Appointment (HTTP) Use Case: Extend Meeting Extend a meeting from the touch panel Extend Meeting (RMS: 3839) Use Case: Request Help Send a HELP request Send Help Request

14 NetLinx Master Network Details Ethernet Physical Interface The Ethernet interface supports 10 and 100 Mbps for both full and half-duplex modes of operation and is compliant with the IEEE BASE-T specification. The unit, by default, enters auto-negotiate mode, which automatically detects and configures itself for operation on the network to which it s connected. It is possible to force the mode of operation (10Mbps half, 10Mbps full, 100Mbps half, or 100Mbps full) via software configuration. Protocol Stack The NetLinx master s software runs a single protocol stack-the IP protocol. Of the IP protocol, both UDP and TCP are managed and utilized. The NetLinx master s IP address configuration may be either static or DHCP. The DHCP client conforms to RFC1541 with support for option 12 (Host name) of RFC1533. The inclusion of the Host Name option in the DHCP client allows DHCP servers that support updating dynamic DNS tables to add the NetLinx masters host name to the DNS. Application Protocols The NetLinx master implements the following protocols: ICSP (port 1319 UDP/TCP) The Internet Control System Protocol (ICSP) was developed by AMX to facilitate control system communication and management. The ICSP protocol has been registered with the Internet Assigned Numbers Authority ( and should not conflict with any other protocol used on the network. ICSP is a peer-to-peer protocol used for both master-to-master and master-to-device communications. For maximum flexibility, the NetLinx master can be configured to utilize a different port than 1319 or disable ICSP over Ethernet completely from either Telnet or the Program Port located on the NetLinx master itself. Telnet (port 23 TCP) The NetLinx telnet server provides a mechanism to configure and diagnose a NetLinx system. For maximum flexibility, the NetLinx master can be configured to utilize a different port than 23 or disable Telnet completely from either Telnet or the Program Port located on the NetLinx master itself. Once disabled, the only way to enable Telnet again is from the NetLinx master s program port. HTTP (port 80 TCP) The master has a built-in web server that complies with the HTTP 1.0 specification and supports all of the required features of HTTP v1.1. HTTPS (port 443 TCP) The master has a built-in SSL protected web server. (Firmware version 130 or above.) FTP (port 21/20 TCP) The built-in FTP server conforms to RFC959. Internet Inside (port TCP) The Internet Inside feature of the NetLinx master uses, by default, port for the XML based communication protocol. This port is connected to by client web browser s JVM when Internet Inside control pages are retrieved from the NetLinx master s web server. For maximum flexibility, the NetLinx master can be configured to utilize a different port than or to disable Internet Inside completely. For more details on the NetLinx master s Network Bandwidth Utilization, see AMX Technote #250

15 Database Utilization Database Measurement Methodology The database size measurements were done using SQL Server Enterprise Manager. Each use case was performed according to the following steps: 1. Determine Database size using the database size and space available properties on the general tab of the Database Properties dialog. 2. Perform the action to be measured. 3. Determine Database size from subtracting the space available property from the database size property. Report results. All test utilized the MeetingManager sample code distributed with the RMS SDK v3.0.7 loaded into an NI-700. Installation In this scenario, a network administrator installs the RMS application from CD or executable file. The RMS Configuration Wizard prompts the administrator for various data. During the installation, there is an opportunity to create an initial database. Use Case: Configuration Wizard Create New RMS Database using Configuration Wizard Create Database 0MB 4.00 MB 4.00 MB 4.00 MB Administration For these cases, the administrator will be accessing the RMS server from a remote PC through a web interface. Use Case: Add User Add a user with 3 phone numbers (phone, mobile, fax) and 4 addresses. Add 10 Users 4.00 MB MB.055 MB.0055 MB Use Case: Add User Notification Add a user Notification for All Rooms Add 10 Notification MB MB.15 MB.015 MB

16 Events The Event scenario does not necessarily require human intervention. Events occur either by a device triggering a threshold, a timed function occurring, or a system being brought on-line manually. Use Case: NetLinx System Connection New NetLinx system connects to the RMS server. Add 10 New Systems MB MB.34MB.034 MB Use Case: Room Added A new Room is created from connected NetLinx system. This includes device and parameter registration. Add 10 New Rooms MB MB.82 MB.082 MB Use Case: Help Parameter Notification The Help parameter threshold is exceeded. After each help request, the request is cleared so each new help request is logged and tracked in reporting history Help Requests MB MB 1.06MB.00106MB Use Case: Power On/Off System power is turned on and off. System power is only tracked in reporting history Power On/Power Off MB MB.7MB.0007MB Use Case: Basic Device Monitoring RMSBasicDeviceMod This module monitors basic devices. For each device, this module will register and monitor online/offline status, communication status and power. Communication status is registered only if the device is a two-way device. Power is only tracked in reporting

17 history. Communication Status and online/offline status are tracked in the internal log and reporting history Power On/Power Off MB MB.44MB.00044MB 1000 Offline/Online MB MB.5MB.0005MB 1000 Communicating/No t Communicating MB MB 1.18MB.0018MB Use Case: Projector Monitoring RMSProjectorMod This module monitors projectors. For each projector, this module will register and monitor all of the parameters from basic monitoring as well as Lamp Hours. Lamp Hours changes are only tracked in reporting history. If a Lamp Hour value exceeds its threshold, the change that exceeded the threshold is tracked in the internal log. Lamp Hours, 3000 changes MB MB.69MB.00023MB Use Case: Transport Devices RMSTransportMod This module monitors transport devices. For each transport device, this module will register and monitor all of the parameters from basic monitoring as well as Run Time. Run Time is only tracked in reporting history. If a Run Time value exceeds its threshold, the change that exceeded the threshold is tracked in the internal log. Run Time, 3000 changes MB MB.68MB.00022MB Use Case: Source Usage RMSSrcUsageMod will track the amount of time, in minutes, a given source is selected and logs this information to RMS when a new source is selected. Source Usage is only tracked in reporting history. Source Usage, 1000 changes MB MB 1.01MB.00101MB

18 Scheduling End Users are allowed access for the purpose of scheduling rooms, requesting room presets, and configuring electronic signage Use Case: New Appointment Save an Appointment with a preset, and welcome text/image through the web interface both with and without recurring instances. Note that Welcome Images are not stored in the database directly; the images are stored on the server and the file path is stored in the database. Ten New Appointments MB MB.04MB.004MB Ten New Recurring Appointments MB MB.04MB.004MB 2011 AMX LLC 3000 Research Drive Richardson Texas, Phone