Creating a Test Environment Based on Production Environment

Learn how to replicate your production environment to establish a reliable test setup for accurate development outcomes for OnPremise environments.

+ More

Table of Contents

Overview Prerequisites Steps First pass: bring the test environment online Second pass: finalize the cryptography key Post-setup tasks

Overview

This guide explains how to create a test environment based on a production environment, ensuring that all necessary data and configurations are available.

Disclaimer: Completing all the steps described in this article does not guarantee that the application will function correctly. While the application can be copied, its extensions may differ in logic, lack necessary uninstallation scripts, or come from third-party sources outside our control. As a result, proper reinstallation or full compatibility cannot be ensured.

 

Prerequisites

  • Windows Server 2016 or higher
  • SQL Server 2016 Standard / Enterprise SP3 or higher
  • Production environment with Enterprise Service Management v. 12.1.1 or higher used as a basis for copying
  • Enterprise Service Management version of the test environment is the same as the production environment

Steps

  1. If your Service Account in the test environment differs from the one in the production environment, prepare an account in the internal M42 Enterprise Domain with Administrative rights before proceeding to ensure that you still have access to the new test environment:
    1. In the production environment, go to the Administration application → Integration → Domains/Tenants and create a new domain.
    2. In the dialog, select Internal as a type and give it a name.
    3. After that, create a Person and an Account and assign it to the internal domain.
  2. Prepare the test server. See System Requirements
  3. Install on test server the Matrix42 Enterprise as usual. See Installation: Step by Step
  4. Back up the necessary databases of the production environment:
  5. Make sure the backups are accessible by the new test environment: 
    In SQL Server Management Studio, right-click on Databases of the new Database Server and select Restore Database…

    Select Device as a source and press the button [….] on the right. Select the path and the .bak file of the associated Database:

    Since your production databases are older than the just-created test DB, you must select these 2 options in the Restore Database window:
    1. Overwrite the existing database (WITH REPLACE)
    2. Close existing connections to the destination database
      Otherwise, you will be unable to restore the databases.
      Click OK to restore the necessary databases
  6. Execute the following SQL Update Statements in the M42Production database of your test instance.
    In the examples below, the DB Server of the productive environment is MA-ESM01\MATRIX42 but the Database Server of a new test environment is MA-ESM03 without an instance. Replace the example name MA-ESM03 with the Servername\Instance of your Test Environment Database Server.
UPDATE [PDRDwpConfigurationClass] SET [Value] = N'server=MA-ESM03;database=M42Production;integrated security=True' WHERE [Key] = N'update4u.SPS.DatabaseFileStorage-connectionString'

UPDATE [PDRDwpConfigurationClass] SET [Value] = N'database=M42WareHouse;server=MA-ESM03;integrated security=True' WHERE [Key] = N'update4u.DataWarehouse-databaseConnectionString'

UPDATE [PDRDwpConfigurationClass] SET [Value] = N'database=M42Archive;server=MA-ESM03;integrated security=True' WHERE [Key] = N'update4u.SPS.History-databaseConnectString'

UPDATE [PDRDwpConfigurationClass] SET [Value] = N'data source=MA-ESM03;initial catalog=M42Production;integrated security=True' WHERE [Key] = N'Matrix42.ServiceLayer-workerMonitoringConnectionString'

UPDATE [PDRDwpConfigurationClass] SET [Value] = N'data source=MA-ESM03;initial catalog=M42Production;integrated security=True' WHERE [Key] = N'Matrix42.ServiceLayer-workerPersistenceConnectionString'

The rest can be updated in the setup later in the Configuration Wizard under “Change Reporting and Analysis Services Server”.
If you want to update it now, you can adjust the example name and use these UPDATE statements as well.
The necessary parameters for the UPDATE scripts can be found in the Reporting Server settings of the test server:

UPDATE [PDRDwpConfigurationClass] SET [Value] = N'data source=MA-ESM03;integrated security=True;initial catalog=M42AnalysisServices' WHERE [Key] = N'update4u.DataWarehouse-cubeConnectionString'

--additionally adjust the value below by replacing http with https and port 443 if needed:

UPDATE [PDRDwpConfigurationClass] SET [Value] = N'http://MA-ESM03:80/ReportServer'  WHERE [Key] = N'update4u.SPS.ReportingServices-server'

UPDATE [PDRDwpConfigurationClass] SET [Value] = N'data source=MA-ESM03;integrated security=True;initial catalog=M42AnalysisServices' WHERE [Key] = N'update4u.DataWarehouse-cubeConnectionString'

While you have database access, also rename the worker entry so the test server doesn’t show up as a duplicate later, in Step 7:

UPDATE PLSLWorkerClassBase SET ComputerAlias = 'MA-ESM03'
UPDATE PLSLWorkerClassBase SET ComputerName = 'MA-ESM03'

(Replace MA-ESM03 with your test server’s name — same as above.)

First pass: bring the test environment online

Steps 7–11 below bring the cloned environment online for the first time. They are repeated a second time further below, in Second pass: finalize the cryptography key — read that section before you start, so you know what to expect.

  1. On the test server, open Matrix42.Setup.exe in the /bin folder to run the Configuration Wizard and select “Change Security Configuration”:

    • Enter the correct FQDN of your test environment:
    • Select Regenerate security keys in the next step. This writes a new entry to the securityCryptographyConfiguration.config file in /bin:
  2. Click “Configure Service Layer”, provide the password for your service user, and continue until the setup finishes.
  3. You should now be able to access your ESM test environment at the correct link. Open it and navigate to Administration → Services and Processes → Workflow Studio → Workers.
    • Thanks to the database rename in Step 6, there should now be only one Worker entry, already showing your test server’s name — confirm it looks correct.
    • If you see two entries instead — for example, because the rename in Step 6 didn’t take effect before the worker first registered — delete the entry that belongs to the production environment.
    • If you run into other issues — for example, the worker doesn’t register at all — update the worker token: go to the application path\worker\core folder on the test server and open updatetoken.cmd.
      1. In the test environment, go to Administration → Integration → Web Service Tokens → Generate API Token. Use the SYSTEM user for the API token.
      2. Paste the new API token into updatetoken.cmd and run it.
  1. Copy the cryptography key from your production environment and paste it into the test environment. It is stored in the application path \bin\securityCryptographyConfiguration.config file:

    In your new test environment, there should also be an empty key0 value. Store the cryptography key from your production environment there for backwards compatibility. More on that you can find here Database Security: Encryption Key.
    If you receive the error message to one of your Data Provider configurations that “padding is invalid”, even though you copied your cryptography key, go to your ActiveDirectory Data Provider and retype the password into every configuration you have, otherwise, the Data Provider will fail to run.
  2. If your Service Account in the test environment is different from the one in the production environment, open the Matrix42 Setup in /bin folder to run the Configuration Wizard and select “Change Service Account”. Provide the credentials for the service user that will be used in the test environment.

Second pass: finalize the cryptography key

After completing Steps 7–11 once, the environment is up and running — but the active cryptography key was freshly regenerated in Step 7. Restore the original production key, then repeat Steps 9–11 a second time, this time also finalizing the dispatcher configuration described below.

Re-insert the original cryptography key
Copy the original production cryptography key into securityCryptographyConfiguration.config, including the key0 backwards-compatibility value. The Change Security Configuration wizard you just ran in Step 7 may have overwritten or reset it.

Step 7 (second pass) — change the security configuration again
Run the Configuration Wizard’s Change Security Configuration once more: enter the FQDN and select Regenerate security keys again, exactly as in the first pass.

Step 8 (second pass) — reconfigure the service layer again
Run Configure Service Layer again, exactly as in the first pass.

Step 9 (second pass) — finalize worker & token configuration
Access the test environment and check the Workers list again, as in the first pass. This time, also complete the following steps:

  • Update appsettings.json in the \dispatcher folder with the new API token, the correct hostname, the connection string to the database server, and the Installation ID matching your production environment.
  • In the UI, update the API Token field as well, using the same new token you entered into appsettings.json.

The rename in Step 6 should mean only one Worker entry ever appears, so there is normally nothing to delete here. If a worker still doesn’t register correctly — or you’re finishing off an environment where Step 6 was skipped — fall back to deleting the stale production entry and reissuing a token through updatetoken.cmd as described above.

Post-setup tasks

  1. Go to Integration → Data Providers → Data Provider Pool, select the App Server, and make sure that the worker of your test environment is listed there.
  2. Check the Queue Task by making a SELECT statement on the table QueueTask in the M42Production database of the test server. If there are any entries where the Server name of the Productive Environment is written in the column Server, delete those entries.
Select * from QueueTask
  1. If you need working e-mailing, reconfigure the Email Settings in the Administration application → Global system settings because sending emails will fail with the error message: “Installation ID does not match. Message will not be sent”.
  2. Copy the application path\Licensing folder from the productive server and paste it into the path of the test server. This will prevent you from getting error messages regarding the license files, since license files are hardware-bound.
  3. If you receive an error message that mentions “no valid license”, you must check the PDRConfigurationPackageClassBase and search for duplicate entries which must be removed. This is because the license files are hardware-bound. If that doesn’t help, contact Matrix42 support.
  4. Copy all files for the installed Extensions from the/installedPackages application folder of the Production Server to the corresponding folder on the Test Server. 
    Then, in the Administration application, navigate to the Extension Gallery and reinstall each extension one by one. This is necessary because every extension that copies files into /wm or copies any .dll files will not work out of the box.

Related Articles