Test & Training Questions

Frequently asked questions related to Keyfax test & training installations.

Should I host a test or training installation of Keyfax on a production web server or on the same SQL Server as my production databases?

We would generally always recommend unique resources for each type of Keyfax environment (dev, test, staging, production etc). Each environment would generally have one or more physical or virtual machines with at minimum dedicated storage and compute resources.

This is necessary to ensure each environment is separate and isolated from one another. There are many benefits to this approach, and this helps mitigate several risks.

We would highlight the potential risks of running non-production sites such as a testing or training site alongside production sites on the same shared server.

These risks include but are not limited to…

• A shared server for testing, and production means shared resources: a shared disk, disk space & disk I/O, CPUs, network bandwidth. This can result in unwanted stress on the server.

• If internal staff need remote RDP access to the test environment, they will likely have full access to the production environment. ACL administration to protect production activities can be more complicated in this scenario.

• If the test database is hosted within the same SQL Server instance as the production database, the customer would need to be very careful that any changes intended for the test database are not accidentally applied to the production database. {should we mention support entitlement here?}

• If the wrong database is accidentally updated does the customer have a back-up & restore strategy in place for the production database

• Whilst it’s possible to isolate several installations of the Keyfax web application on a single web server and run multiple web sites from the same web server this does require specific configuration to ensure each web site is correctly isolated. At minimum you would generally create a unique web site within IIS pointing to a unique instance of the Keyfax files for each Keyfax installation. Each web site would have its own unique IIS application pool and configured permissions.

• Bench marking, security, or load testing any web site on a shared VM could inadvertently affect other web sites on the same web server, for example if compute or bandwidth limitations are reached.

• The servers up-time could be impacted when non-production sites are updated

• Troubleshooting can be more difficult as issues may be logged at the system level and not the application level

• System wide hot fixes and patches (for example OS updates) cannot be verified separately before they are applied on the production system.

• Non-production web applications should be kept up-to date with the latest security fixes to minimize any attack surface

If multiple environments are cost prohibitive and the customer is prepared to accept the known risks & limitations of using a single server for each environment there is no technical reason within Keyfax the customer cannot run both a test and production instance of Keyfax on the same server(s).

What are my options for setting up a test / training systems / scripts?

You should consider the purpose/goals of a Test/Training system, i.e. do you want to:

1. use a sandbox for occasional experimentation/practice

2. develop scripts and test them before deploying to Live (by ad hoc requests for manual script copying or rekeying minor changes)

3. test new Keyfax releases (and host integration)

4. test new HMS releases (and Keyfax integration)

5. use a separate Test database accessed through their Live Keyfax website and Live admin Tools

6. wholly segregate Live and Test environments

7. use separate SQL server(s)

8. have a system specifically for training

9. have a development/pre-production/live arrangement

or combinations of the above! Various scenarios are illustrated below:

Segregated DEVELOPMENT, TEST(aka PRE-PRODUCTION) and LIVE systems, each running on their own Web/SQL server(s)

Pros...

• Able to take HMS/Keyfax updates, reconfigure as required and perform full integration testing/UAT.

• Minimise possible/accidental impact on Live system or its interfaces.

• With guidance (and by prior agreement), Client may be able to migrate changes across platforms.

Cons...

• Additional initial setup cost (and possibly ongoing support/maintenance).

• May require documented procedures for migrating updates/changes between platforms; these are subject to change in every subsequent software release.

DEV/TEST instance configured within Live environment using a separate Test database

Pros...

• Enables administrators to test changes to scripts without impacting Live.

• Provides a sandbox facility.

• No separate Admin Tools required.

Cons...

• Cannot test software upgrades (different versions of Keyfax cannot co-exist on the same web server).

• If scripts are developed in a Test database with the intention of deployment in Live, other than re-keying into Live, this would require a manual migration of scripts. Currently, this procedure can only be carried out by by Omfax Systems Support.

• Test HMS system can become mismatched with Test Keyfax e.g. registered users or other settings.

• Where the Keyfax Client is used, and the HMS is not capable of passing Company (aka Configuration) codes, it will require a separate Client installation on designated fat/thin client machines.

Flag scripts as 'TEST' in the Live environment and only made available to production following local testing within Admin Tools.

Pros...

• No separate environment required.

Cons...

• Limited use, i.e. cannot test new versions of Keyfax or HMS software.

How can I keep my test & training scripts up to date (i.e. as per Live)?

A typical Keyfax environment may support up to 3 databases used by one or more webservers running Keyfax, e.g.

• Live

• Test (pre-production)

• Training

To maintain synchronisation between the scripts, the simplest way is to periodically restore a backup of the Live database over the Test and/or Live database(s). Typically databases names take the format:

• KF_SiteName_40

• KF_SiteName_40_TEST

• KF_SiteName_40_TRAIN

Restoring the database will also copy Users and History to the target database. It should be noted that if a restore takes place on a different SQL Server to where the backup was run, it will be necessary to run the following stored procedure on the newly restored database before it will become available:

utAutoFixKeyfaxUserLogins

In any event great care must be taken to ensure the direction of the restore and that the Live system remains untouched. Although it is technically possible to run backups/restores during the day, to ensure there is no impact on performance these jobs are best run out of hours. Before proceeding with any backup / restore activity detailed above, please advise Omfax Systems of your intentions.