We have a new community! Please visit support.timextender.com

Configure Multiple Environments

This guide will give you an overview of the setup, configuration, and use of the Multiple Environments functionality in TimeXtender. 

Complete the following steps to configure multiple environment transfer. 

  1. Initial Server Setup
    1. Server Configuration & Reference Architecture
    2. Create a Repository Database for each Environment
    3. Create a Service User for Each Environment
    4. Configure the Server Service for each Environment
    5. Assign Each Service User to the Associated Environment's Project Repository
    6. Configure the Firewall
  2. Configure the Environments
  3. Create Additional Intermediate Environments
  4. Configure Global Databases
  5. Multiple Environment Security
  6. Multiple Environment Transfer
    1. Initial Steps Prior to Environment Transfer

Initial Server Setup

Server Configuration & Reference Architecture

In order to implement multiple environments, you must first decide on your server configuration for your environments. The below image is an reference architecture of TimeXtender configured with 3 Environments; Development, Test, and Production.

As you can see in the diagram, Development and Test are co-located on the same server. This can be done to save resource costs if desired. However, many organizations prefer to have the server specs of Test match the server specs of Production in order to analyze performance as well. Take the time to consider these and other factors before deciding on an architecture and, if necessary, consult your TimeXtender Partner to help make these decisions. 


Some important aspects to note in the diagram:

  • Share Resources: Any/all environments may share some resources if desired to save cost/consolidate resources such as the Application Server, SQL Server, and Analysis Services Server. 
  • Services: Dev only requires a scheduler service, Test requires both a scheduler service and a server service, and Prod requires the ODX, Scheduler, and Server service. 


Create a Repository Database for each Environment

You must create a new project repository database for each Environment. It can be helpful to follow a naming convention to clearly identify each database such as projectRepository_Dev | projectRepository_Test | projectRepository_Prod. These databases should reside on the associated environment server. To create another repository database:

  1. In TimeXtender Tools Menu > Options > Project repository Tab
  2. Indicate the correct server name.

  1. Type the desired database name for this new repository.
  2. Click Create.

Create a Service User for Each Environment

Each Environment (except for Development) needs an individual "Log-on As" user. This is typically the same "service" user used to run the Scheduler service. This user will be initiating the deployment and execution operations triggered through other environments, therefore, needs to have DbCreator security permissions on all associated databases for that environment. (e.g. projectRepository, ODX, DSA, and MDW).

Configure the Server Service for each Environment

Each environment (except for Development) needs to have an instance of the TimeXtender Server Service. You'll need to modify the service to use the "Log-on As" service created in the previous step. (Please note: you will be unable to start the service until you 1. Assign the service user to the associated environment's project repository[step below] and create the associated environment(s) in TimeXtender. [step covered in the first video below])

One instance of the TimeXtender Scheduler Service and TimeXtender Server service are installed when installing TimeXtender, so you may not need to create a new service.  However, if you are running two (non-dev) environments on the same machine, you will need to create another instance of the Server service. To create an additional service:

  1. TimeXtender Tools Menu > Windows Service Setup
  2. Options > Create Service
  3. Provide the necessary info for the service & click create. (You may need to complete the following step first.)

Assign Each Service User to the Associated Environment's Project Repository

When you start the Server Service, the "Log-on As" user opens an instance of the TimeXtender.exe process (TimeXtender without the UI) in the background. This process needs to know what repository to connect to. To assign the Service Account to the associated environment's project repository:

  1. Log into windows using the service account that will be used to run the service and launch DTimeXtender...   OR
  2. Navigate to the timextender.exe application file in the TimeXtender installation directory, Shift+Right-Click and choose Run as different user. 2020-12-25_09h24_52.png
  3. Enter the credentials for the Service Account and click OK. This will run the TimeXtender application as the Service Account user.


4. TimeXtender will ask you to enter the SQL Server and Database name for the project repository. Enter the server and database for the repository you want to associate with the service. Click OK/Next to confirm your settings. 


5. Close the instance of TimeXtender running as the Service Account.

Once you have completed the initial setup, you should now be able to create the Environments in TimeXtender, which we will cover in the following video. Please note, you will be unable to start the service until we create the environments.

Configure the Firewall

If configuring multiple environments across multiple servers it will be necessary to open the proper ports to allow TimeXtender to communicate across the servers. This will depend on the ports you define for each environment. The below diagram is an example of a Development-Production configuration and subsequent communication between the environments. 


Communication between the environments then works in the following way:

  1. The Developer client will attempt to reach the Production Server using the Remote Port specified and the Production Server will listen on this same port.
  2. The Production Server will then attempt to respond back to the Developer Client using the Local Port specified. 

So in the above example you will need to ensure the following Firewall Rules are created:

  1. Production Server: Inbound TCP Port 10025
  2. Developer Client: Inbound TCP Port 10020

While it is not typical, in some highly secure environments you should ensure all dynamic outbound ports are open on both machines as well.

Review this article to learn more about how Dynamic Ports are used during Multi-Environment transfer.

Configure the Environments

Watch the following video to configure your environments in TimeXtender.

  1. Create the Local Production Environment in the Production Repository
    1. Log into the Production Server
    2. Open TimeXtender & switch to the Production Repository
    3. Open Environment Properties
    4. Create the "local" production environment.
  2. Start the Production Server Service (using the Production Service user)
  3. Create the Local Development Environment in the Development Repository.
    1. Log into the Development Server
    2. Open TimeXtender & switch to the Development Repository
    3. Open Environment Properties
    4. Create the "local" development environment
  4. Create the Remote Production Environment in the Development Repository.
    1. In Environment properties, in the development repository & server.
    2. Create the "remote" Production Environment. 

The completed configuration of Development and Production should look something like this:


Create Additional Intermediate Environments

If you wish to create additional intermediate environments, you can do so by slightly modifying the previous instructions. For example, if you were to create a Test Environment you would follow these steps.

  1. Be sure to complete initial setup steps for this Environment.
  2. Create the Test Environment in the Test Repository (on the test server, if a separate server is being used).
  3. Create the Remote Production Environment in the Test Repository
  4. Start the Test Service (using the Test Service User)
  5. Create the Remote Test Environment from the Development Repository
  6. Adjust the Environment Sequence numbers by click in the environment name in the environment properties dialog.


Configure Global Databases

When using Multiple environments it's important to identify a separate set of databases (Data Sources, ODX, DSA, MDW etc.) for each environment. TimeXtender uses Global databases as a way to define dynamic database connections that are configured on a "per-environment" basis. 

Watch the following video to learn how to configure global databases. 

  1. Review all the databases that exist in your project and note the desired SQL server names and database names to be used in each environment. (e.g. ODX/DSA/MDW)
  2. Create the Global Database in Environment Properties in the Development Environment.
  3. Define the Server & Database Name for Development.
  4. Define the Server & Database Name for Production.
  5. Create new databases as necessary by right-clicking on "settings" in the desired cell.
  6. Click OK to exit the Environment Properties Dialog
  7. Right click on the desired database in your project and click Edit Database
    1. Click: Use Global Database
    2. Select the created global database from the drop-down.
    3. 2018-08-17_12h09_45.png
  8. Repeat these steps for any databases or data sources that are environment specific.

Multiple Environment Security

Once Multiple Environments are configured, you can assign which security groups have permissions to perform certain actions. 

Open Environment Properties

  1. Right-Click on the Environment name you wish to secure. 
  2. Click Environment Properties
  3. Assign the Active Directory group which you wish to have this permission. 


  • Admin: Can carry out all below actions. (Specifying a security group for the Admin role ONLY, will disable any of the following actions in the specified environment for users not in that group.)
  • Transfer: Can transfer projects to this destination environment through the Environment Transfer Dialogue.
  • Deploy: Can Deploy this destination environment through the Environment Transfer Dialogue. 
  • Execute: Can Execute this destination environment through the Environment Transfer Dialogue. 
  • Database: Can edit properties and perform the create databases action in this environment within the Environment Properties Dialogue. Users not granted the Database permission will be able to view all properties but will not be able to modify them. 

Multiple Environment Transfer

Now that you have configured multiple environments you may want to promote your project to the next environment.

Initial Steps Prior to Environment Transfer

  1. Deploy & Execute your entire project in the previous environment. 
    1. This can identify any potentially unresolved bugs. 
  2. Prepare an Execution Package to run after the transfer. 
    1. If you have made changes to any Incremental tables, be sure to select those tables for full-load in this package. 
    2. Be sure you name the package so you and others know it's for a one-time use. 
  3. Stop the scheduler service in the destination environment. 
    1. This will ensure no scheduled executions begin during the transfer. 
  4. Ensure no execution packages are running in the destination environment. 
    1. You can query the project repository database to return execution details

Watch the following video to see how to transfer a project to the next environment. 

  1. In the Development Environment, open Multiple Environment Transfer
  2. Click Transfer
  3. Deploy, Managed & Differential
  4. Run the desired Execution Package.
Was this article helpful?
3 out of 3 found this helpful


  • 0
    Peter Jensen


    How should we setup multiple environments in an Azure environment (repositories stored in Azure SQL DB's - 1 for each environment), and having 1 or more Azure VM's with TimeXtender application on it ?

    Best regards,


  • 0
    Jon Catt

    I was wondering about the manual intervention required on this part:

    Initial Steps Prior to Environment Transfer

    3. Stop the scheduler service in the destination environment. This will ensure no scheduled executions begin (in DEV environment) during the transfer. 

    Surely TX can automatically control the TX Scheduler Service via the service account created for that purpose?

    4. Ensure no execution packages are running in the destination environment.

    Surely TX can talk to the TX Server Service in Prod (Destination) and agree to pause the migration until any running execution packages have completed, then pause the TX Scheduler Service and complete the migration?

    Just thinking aloud, I'm fairly new to TX, but happy to discover why this couldn't be achieved.



  • 1
    Joseph Treadwell

    These are great suggestions Jon. We are always looking for great feedback like this and would encourage you to post them here: Product Feedback and Ideas – TimeXtender Support

  • 0
  • 0
    Joseph Treadwell

    Not at all Jon, These are great suggestions and we will be taking in all the feedback as we design an improved experience for our next release. Thanks!

  • 0
    Daniel Verbrugge

    Hi All,

    I've noticed that sometimes the Windows Defender (Firewall) can also block the trafic.

    The IT partner had changes the policies on the windows defender firewall so now the TimeXtender DEV / ACC environment was blocked from it's PRD Enviroment (on an other server)
    So if the firewall ports are open, but you still can't connect to the enviroment, check if Windows defender is on.
    If so, you can make new inbound and outbound rules for the TimeXtender program and allow the connections.
    Even better to have the IT department make changes in the policies.

    Take care!

    Edited by Daniel Verbrugge
  • 0
    Ramon Villanueva

    I would like to have similar documentation about the new version, because it's quite different.

  • 0
    Joseph Treadwell
Please sign in to leave a comment.