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 sales@netx.net. If you are a SaaS customer and would like to request a permanent test site, please contact your Account Manager.

The instructions below are intended as a general guide and reflect our practices 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 must engage our professional services team if further assistance is required.

Prerequisites

  • 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. Create a new repository location for the test instance. For example, if your production repository is a network share on \\Server1\share\repository, you could create a new location in \\Server2\share\repository.
  3. Copy the repository data from the production repository to the test repository. The repository path can be found in the database's location table where name is Internal repository, as well as the system property sys.repository_directory.

    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 asset.

  4. Create a new appFiles directory for the test server. For example, if your production appFiles directory is on a network share \\Server1\share\appFiles, you could create a new location in \\Server2\share\appFiles.
  5. Copy the appFiles data to the new location (thumbnails, zooms, pdf page views, constituents, versions). This location is determined by the system property image.fileDirectory which can be found in System > Properties.
  6. Take a full backup of the database from the production database server. For example, in mysql, you can use mysqldump to create a backup file.
  7. Create a new database for the test environment. Load the production data into the new test database instance.
  8. Run a query on the new test database to update the paths in the location table 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:

    SQL Server MySQL
    USE netx_test
    UPDATE location SET base_path = REPLACE(base_path,'\\Server1\share\repository','\\Server2\share\repository') WHERE base_path LIKE '%\\Server1\share\repository%'

    For NetX versions prior to 11, also update the path in the image table.

    UPDATE image SET path = REPLACE(path,'\\Server1\share\repository','\\Server2\share\repository') WHERE path LIKE '%\\Server1\share\repository%'
  9. 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.

    SQL Server MySQL
    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 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.
    • Disable any 3rd-party integrations to not interfere with what is running in production. Examples include Amazon S3 or Glacier integrations, etc. If you have any questions 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