When all the planets align, installing the RMS Server application is smooth and painless. But we live in a real world and things don’t always go to plan. Our old mate Murphy has a habit of intervening.
Here are some examples I’ve seen where the RMS has created pain:
· Not following the installation manual. I have witnessed IT people trying to install the various components out of sequence and hitting a brick wall. Java and Tomcat must be installed before the RMS application. And the configuration settings in the manual must be followed – they are there for a reason.
· Server hardware not meeting minimum specs – eg if the minimum RAM is stated as 4MB, having only 2MB available is sure to have consequences.
· Not having access to the right people. Part of the RMS installation process is to create a database on the SQL Server. Quite often this is under the control of a database administrator (DBA) in another section of IT, and the DBA will need to grant access to the server. If the right person is not available at the time of RMS installation, the process stalls. It cannot proceed without a SQL database.
· Poor communication or friction between AV and IT teams. RMS is a classic case of AV-IT convergence and the people in each team need to work together. That may take some ‘education’ to break down barriers and build trust – eg convincing a DBA that you are not going to compromise any of ‘his/her’ systems or requiring admin rights on the RMS server box or instance. Equally, AV people need to respect the need for IT-centric things like change management and security policies.
The other thing that causes an RMS installation to go badly is inadequate planning of the monitoring and reporting.
RMS is a hugely flexible system and can do almost anything you want – or more specifically the programmer can. The challenge when designing an RMS system for your university is to plan and specify exactly want you want. That may sound simple, but it isn’t for someone unfamiliar with RMS.
What often happens is that assumptions are made – by the university; and by the programmer. Typically the newcomer to RMS doesn’t understand RMS’s programming requirements; and the programmer doesn’t fully understand the university’s needs. The end result is often disappointment.
How can this be avoided? The best approach is to include AMX in the planning process – ie make it a 3-way partnership between the university, integrator and AMX. We have extensive experience with RMS and a thorough understanding of what works for universities, so are in a good position to guide an RMS system towards a successful outcome rather than disappointment.
One of my roles at AMX is to help universities develop and refine RMS systems to deliver real value. It’s one of my passions and I’m only too happy to help with anything RMS-related.