How to Create an On-Premise Test Environment in Windows

This guide is meant to help an on-premise system administrator through the process of setting up a test server. Each on-premise license includes a complimentary test license that renews annually. Contact your Account Manager to request your test license or email If your site is hosted by NetX and you would like to request a *permanent* test site, please contact your Account Manager.

The instructions below are intended as a general guide and reflect the practices we use here at NetX. Your environment may vary, so some of the steps outlined below may need to be adjusted according to your needs and the technologies you are employing to host NetX. We strongly recommend that test site deployment be performed by experienced system administrators, DBAs, etc. Test sites are not covered under our Support Policy, so customers will need to engage our professional services team if further assistance is required.


  • New, separate VM/server with identical OS and specifications to run the test version of NetX
  • New, separate location of appFiles and Repository
  • New, separate database instance/server for test purposes.
  • Must be running version 7.3 or later (some paths have changed from older versions)

Prepare and clone data

  1. For best results, shut down the production NetX instance during this process. This will ensure that the database is in sync with the repository. If that is not possible, refrain from major import processes or system modifications during this time.
  2. Copy the repository data from the storage location on production (this can be found in System > Storage ). Double click on the default location to see its path. If it's a network share on \\Server1\share\repository, the new location may be \\Server2\share\repository.

    Note: Some users with very large datasets may omit this step, or may decide to only copy a subset of the repository. If the application sees a database record for an asset, but cannot locate the physical asset that matches the path listed in the database, users will still see the asset record and metadata but will not be able to download, repurpose, or perform certain actions on the assets.

  3. Copy the "appFiles" data to the new location (thumbnails, zooms, pdf page views, constituents, versions). For example, if these are on network share \\Server1\share\appFiles it could be copied to a new location called \\Server2\share\appFiles. This location is determined by the system property image.fileDirectory which can be found in System > Properties.
  4. Take a full backup of the database from the production database server. For example, for mysql, one would use something like mysqldump to create a backup file.
    Create a new database for the test environment. Load this data into the new test database instance.
  5. Run a query on the new test database to update the paths in both the "image" and "location" tables to match the location of the repository on the test environment.

    Example: If the production server is on \\Server1\share\repository and the test data is on \\Server2\share\repository
    MySQL example:

    mysql> use netx_test;
    mysql> UPDATE image SET path = replace(path, '\\Server1\share\repository', '\\Server2\share\repository');
    mysql> UPDATE location SET base_path = replace(base_path, '\\Server1\share\repository', '\\Server2\share\repository');

    SQL server example:

    USE netx_test
    UPDATE image
    SET path = REPLACE(path,'\\Server1\share\repository','\\Server2\share\repository')
    WHERE path LIKE '%\\Server1\share\repository%'
    UPDATE location
    SET base_path = REPLACE(base_path,'\\Server1\share\repository','\\Server2\share\repository')
    WHERE base_path LIKE '%\\Server1\share\repository%'
  6. Clear all entries out of the asset_path_journal table so that NetX's path repair job doesn't try to fix database paths when users try to access assets that have not physically been cloned to the test repository location. This is only an issue if the NetX service account running the test instance has access to the production repository, but better safe than sorry.
    MySQL example:

    mysql> USE netx_test;
    mysql> TRUNCATE TABLE asset_path_journal;

    SQL server example:

    USE netx_test
    TRUNCATE TABLE asset_path_journal

Install and configure NetX on a test server

  1. Make sure the prerequisite JDK version and any external engines are installed on the test server to match what is already on the production server.
  2. Run through the NetX Installation Guide for Windows on the test server up until step 2: "Verify that you can access  http://localhost  ....". (for this example, Windows is the assumed environment). Do not run the NetX Configurator.
  3. Shut down the NetX service on the test server. 
  4. Copy the appropriate JDBC jar file into C:\Program Files\NetXposure\webapps\ROOT\WEB-INF\lib\ on test server. This file should be available to copy from on the production instance. See  Supported JDBC Drivers for more information.
  5. Copy the license into C:\Program Files\NetXposure\netx\license\ on the test server.
  6. Create a zip archive of everything under C:\Program Files\NetXposure\netx\ on production and copy this to the test server.
  7. Unzip the archive created above on test and recursively copy this into C:\Program Files\NetXposure\netx\ on the test server. Overwrite any files if prompted.
  8. Navigate to C:\Program Files\NetXposure\netx\config\. Edit exogen-config.xml (additionally, update any files with the name exogen-config*.xml) update the following properties to reflect the new test environment (see Configuring Properties):
    • sys.site_domain - this should match the new DNS hostname or IP address of the test server
    • sys.docroot_url - this should match the full http URL of the new test server
    • sys.tomcatManagerUrl - this should match "http://[ip-address of test server]/manager/"
    • image.fileDirectory - this should match the path of appFiles folder that was created for test. Example: \\Server2\share\appFiles
    • sys.repository_directory - this should match the path of the repository that was created for test. Example: \\Server2\share\repository
    • database.url - this should match the JDCB URL of the new test database.
    • database.user - this should match an account with full access to the new test database.
    • database.password - the password that corresponds to the above account
    • Additionally, search the config files for any other references to the production URL. Make sure there are no additional path references that would apply only to production.
    • If there are any 3rd-party integrations, they should most likely be turned off as to not interfere with what is running in production. If there is a question about this, please contact NetX support.
  9. Update Tomcat settings such as heap on test to match production, using the C:\Program Files\NetXposure\bin\netxw.exe application. See  Java Memory Heap for more details.
  10. Start the NetX service.
  11. Go to  http://localhost/  from the test to verify that the application is loading. Assets may take some time to show up. See System > Jobs to determine if the Solr Index job is still running.
  12. Once Solr on test has finished its indexing jobs, the application should be ready to use. Do one final verification of thumbnails loading, ability to download, and ability to import new files.

Was this article helpful?
0 out of 0 found this helpful