Mar 102017

We will be releasing our next major versions of eMRD (v4.0.0) and eMRD Companion (v4.0.0) around the end of March – early April 2017. Versions 4.0 of eLORA and eLSA will be released later on in the year.
This major version release coincides with a few key updates to the suite that we would like to bring to your attention.

Licensing and Maintenance Support Changes

Following a review of our software security and licensing procedures, we are making several changes that will affect all our customers.

  • v4.0.0 of the LES Suite of Tools will require a new license key. At the release of eMRD v4.0.0 and eMRD Companion v4.0.0, all customers that have current maintenance support contracts will be issued with new license keys that will work with version 4.0 of the LES Suite of Tools.
  • From v.4.0.0 onwards, we will be changing our licensing generation procedures to provide customers with license keys that are keyed to the duration of maintenance support contracts.
    • Upon renewal of the ongoing maintenance support contract, a new license key will be issued for the corresponding period.
    • If a customer chooses not to continue with the maintenance support contract, the customer will be issued with a non-expiring license key that is keyed to the version available at the time of expiry.

How does this change impact our customers?

  • This change necessitates that customers will have to replace their expired keys with the new keys provided as part of the maintenance support renewal process.
  • As with current maintenance support arrangements, customers are entitled application updates if they are currently paying maintenance support fees. When a customer decides to no longer pay maintenance support, they are no longer entitled to updates. This license change facilitates streamlined management of this policy.

LES believes that this conforms to industry standard practices from major software providers for software applications that have maintenance support contracts.

LES Suite of Tools and Microsoft SQL Server Connectivity

“Standard” Database Applications

"Standard" Database Applications

“Standard” Database Applications

The large majority of database applications have a front-end application that connects to a single database. The standard approach for such systems is to:

  • Create a database user (or users – admin and normal user) on the database server.
  • Application users are then created and managed via user tables within the database.
  • Application users are authenticated by the application via user tables, but database connectivity is provided by the database user login credentials.
  • It is important to note that in this scenario, application users never need to know the database user login credentials.

The LES Suite of Tools (eMRD, eMRD Companion, eLSA and eLORA)

eMRD - Connecting with Multiple Databases

eMRD – Connecting with Multiple Databases

Our tools are fundamentally different because the front-end applications connects to different instances of the same database, each containing its own unique dataset (e.g. users may use one database per EIAC). Further, each database is likely to have different sets of users and their associated permissions.
When eMRD was first developed in 2002, it worked exclusively with Microsoft Access DBs and we incorporated an internal user management system based on the signed-in Windows Login name.
In 2009, we introduced Microsoft SQL Server connectivity to eMRD. To facilitate this, we provided mechanisms for connecting to Microsoft SQL Server databases using mixed-mode authentication (Active Directory/Windows Authentication or SQL Server Authentication). Why did we do this? The answer is we wanted to provide the simplest solution that provides mechanisms for creating and managing multiple databases whether a customer was:

  • simply taking advantage of the benefits from using Microsoft SQL Server Express Edition on a standalone workstation, or
  • deploying eMRD on a centralised Microsoft SQL Server instance in a LAN/WAN environment for a number of concurrent users.

For the most part, and with some level of effort, mixed mode authentication works for nearly all of our customers, including us at LES.

Alternative Database User Management Systems (ADUMS)

Alternative Databse User Management System (ADUMS

Alternative Databse User Management System (ADUMS

In v4.0.0, we are introducing Alternative Database User Management System (ADUMS). The purpose of ADUMS is to:

  • provide an alternative mechanism for creating and managing groups of users for license seat allocation, and
  • decouple a user’s permissions for access to a Microsoft SQL Server database from the combination of Active Directory/Windows Authentication and/or Microsoft SQL Server Authentication. In a similar way to “standard” database applications, ADUMS will provide eMRD users with access to Microsoft SQL Server databases because ADUMS provides the database user login credentials.

ADUMS is an encrypted Access database (ACCDB) that sits in the MRDDATA share. It will play the intermediary role of facilitating Windows Users of LES Tools with the LES Databases hosted by Microsoft SQL Server that they require access to via Microsoft SQL Server database logins whose credentials are stored within ADUMS. These login credentials are stored in encrypted form (AES-256) within ADUMS.

  1. When ADUMS is in use, the database selection list for Microsoft SQL Server will be populated from data in ADUMS only.
  2. When a Windows User uses an LES Tool to open an LES Database, ADUMS will determine the role of the user via the user’s Windows Login.
  3. When the role has been determined, ADUMS will use the appropriate MS SQL Server database login (DBAdmin or DBUser) to access the LES Database on behalf of the Windows User.

ADUMS will allow the ADUMS administrator to perform the following functions:

  • LES Databases
    • manage LES databases running on Microsoft SQL Server, and
    • specify Database Logins (username and passwords) for each LES Databases
  • LES Application Users
    • manage users by Windows Login name,
    • specify application roles (superuser, manager, user, readonly) by database. If you want to use ADUMS but require the application roles applied at EIAC level, we suggest you create one database per EIAC, and
    • specify application access (eMRD, eLSA, eLORA, eMRDCompanion) by database.
  • Project Groups
    • manage project groups,
    • assign users to project groups,
    • assign databases to project groups, and
    • allocate number of licences for each project group.

Please note, ADUMS is an alternative option for managing users within the LES Suite of Tools. We would suggest that you have discussions with your IT department to decide whether ADUMS is appropriate for how you do business.

 Posted by at 2:13 pm