Category Archives: Multiple Instances

Managing multiple instances of TimeControl

HMS has long supported the notion of having both a production and a staging installation of TimeControl and do not charge additional licensing costs for such use of the system. It is common, for example, to have a staging instance to use for testing upcoming versions or to use for training or internal development of reports, filters and validation rules prior to making these enhancements available to production users. A number of clients have asked what the steps are to support promoting from one instance to another. Once a version or a feature has been tested in the staging environment, how do we then make this available in the new environment? We’ve outlined some standard steps in managing multiple instances in this post.

How to create a second instance of TimeControl

Create a 2nd instance in a virtual environment

Case 1:

TimeControl is installed in a Virtual Machine environment and the database server and database are on the same Virtual Machine. Steps:

  1. Copy the Virtual Machine
  2. Change the IP to be unique
  3. Change the name of the Database Server to be unique
  4. Modify TimeControl.ini to point to the new IP
  5. Modify TimeControl.ini to point to the new database server
  6. Modify TimeControlWeb.ini to change the server’s IP address
  7. Modify host-headers in IIS to be unique and other DNS information as required
  8. See the “Cautions” section below
Case 2:

TimeControl is installed in a Virtual Machine environment and the database server and database are on different Virtual Machines. Steps:

  1. Copy / Backup both the TCSecure and TIMECTRL databases/schemas
  2. Create unique database names for each of these two databases (e.g. TCSECURE_Staging and TIMECTRL_Staging) and copy/restore the database files/schemas
  3. Copy the Virtual Machine
  4. Change the IP to be unique
  5. Modify TimeControl.ini to point to the new IP
  6. Modify TimeControl.ini to point to the new database names
  7. Modify TimeControlWeb.ini to change the server’s IP address
  8. Modify host-headers in IIS to be unique and other DNS information as required

Create a 2nd instance in a separate physical environment

If you are not using a Virtual Machine environment and instead have physical servers and want to set up a 2nd instance of TimeControl on a separate server, this will be the procedure. We will assume the database is also installed on a separate server but even if it is on the original TimeControl server, there is no obvious requirement to install a completely separate instance of your database software. Steps:

  1. Copy / Backup both the TCSecure and TIMECTRL databases/schemas
  2. Create unique database names for each of these two databases (e.g. TCSECURE_Staging and TIMECTRL_Staging) and copy/restore the database files/schemas
  3. Install the identical version of TimeControl on the new server
  4. Use the TimeControl Database Configurator to attach the new instance of TimeControl to the new databases.

Create a 2nd instance in the same physical or virtual environment

Some organizations wish to install a 2nd instance of TimeControl on the identical physical server. (It is quite unusual to install multiple instances on a virtual server as it is so easily replicated). Installing a 2nd instance of TimeControl on the same physical server is possible however the standard installation modules and upgrade modules will only work on the default installation. In order to update multiple instances on the same physical server, a series of manual steps must be performed. HMS Technical Services can guide you through this process if you require it.  

Cautions

Once you have copied your 2nd instance, you may wish to check for scheduled and automated functions that were activated in your production instance that you may wish to disable in your 2nd instance. These may include the following:

  1. Project Management Links
    If there are links to a project management system, then the scheduled links you’ve created will activate on schedule if you don’t make any changes. The Connection Pool information in the Interface Definition will be pointing to your production project management tool. If there is a scheduled job pending then data will move in and/or out of the project tool as scheduled. If there is pending posted data for the pm system or if you enter any data in the 2nd instance, it will be sent to your project pm system. We recommend immediately disabling scheduled jobs and repointing the interface definition to a 2nd project management system instance.
    Caution: If you do not repoint these project links to a non-production instance of your project management tool or disable the links, then you may send duplicate timesheet entries to your project management system!
  2. Email notifications
    If you have scheduled automated email notifications of missing timesheets, the 2nd instance will start happily sending them out along with the production instance. We recommend disabling any scheduled jobs.
    Caution: Not disabling email notifications can cause confusion as users may receive email notices from the 2nd instance complaining of a missing timesheet which has already been completed by the user in the main instance.
  3. Triggers
    If you have made triggers within the database to move data in and/or out of TimeControl to link to finance, payroll, billing etc., these triggers will continue to function in the 2nd instance unless you disable them.
    Caution: Not disabling triggers which were designed to move data to finance for billing or payroll may result in data being sent twice!

How do we promote features between instances?

Once you have a 2nd instance implemented and you have checked the Caution section and taken the appropriate actions, you are able to start thinking of how to use the 2nd instance for testing and staging. There are some elements of TimeControl which were designed to be easily moved between instances. Other elements are more difficult.

What can be promoted easily

  1. Filters
  2. Validation Rules
  3. Language Definitions
  4. Reports

For all 4 of these categories, you can create a Export Package from the Links menu. Exporting a Validation Rule will also export any filters which are reference within it. Exporting a filter will also automatically include any “filters within filters” which are referenced. In the production instance, you can then Import a Package from the Links menu and this item will be successfully promoted and instantly available.

Categories of data that are more difficult to promote

  1. User Defined Fields
  2. Pop-up values for user defined fields
  3. Import/Export definitions
  4. Personal settings

For these categories, we assumed that this information would be updated directly in the production system. User Defined Fields are typically only created during the deployment. The Import/Export definitions carry an entire audit aspect of them which is managed behind the scenes and Personal settings are, well, personal. The best practice for almost all cases involving these 4 categories is to create them manually in the production instance.

Other methods of moving data from staging to production

There are several other methods of moving data from the 2nd instance back into production but each requires some skill.

  1. Export tables from staging and Import into production
    TimeControl’s standard export and import modules allow all kinds of data to be moved. Export from one system and Import to the 2nd system definitions can be created and saved and then the actual creation of the transaction file and its import is very quick.
  2. Triggers and custom code
    For those who have more intimate and long standing links required, creating triggers at the database level can be accomplished. This has the benefit of being hidden from the user and the disadvantage of being hidden from the user. When triggers move data automatically in the background, a best practice is to have solid process and procedure documentation that lets all relevant parties know what is happening to the data and why.

Maintaining a “Cold Server” for disaster recovery

Some organizations have a requirement to create a “Cold Server” and keep it in stand-by for disaster recovery. This is relatively simple to do. First, follow the instructions on creating a 2nd instance to ensure it has been updated correctly. You will need to update the 2nd instance each time you do a TimeControl Upgrade of the production instance. Once the instance is established, you can hibernate the Virtual Machine or turn off the physical server (if it is dedicated) or simply turn off the TimeControl ATS, TimeControl TTS and TimeControl Scheduler Services along with the TimeControl Website (In IIS) Second, ensure that regular backups of your production instance are occurring. Should a disaster occur, activating the Cold Server is very simply:

  1. Turn on the Virtual Machine, turn on the Physical Server or Start the TimeControl ATS, TimeControl TTS and TimeControl Scheduler as required.
  2. Restore the production database backup to the 2nd instance

Ask for help

HMS Services often assist our TimeControl clients with establishing and updating multiple instances.  Contact customer server at info@hms.ca to inquire about our services.