Allocate Endur Reference Data to the Environment

Now that we have the reference data configured in emdash, we can now build the Allocations – mapping the reference data items to the Environment entity we created earlier.

This is fairly straightforward. Navigate to Home Screen and find the environment in the sliding panes. Then click on it to bring up the Environment Details page. We will then work through each section, adding data as needed.

Environment Wide Settings

Add the following Env Wide Settings (at a mimimum for Endur):



At a minimum, the Administrator and all Appserver users need to be mapped to the environment. Administrator should be set up to have the ‘Administrator’ role when creating the User Allocation. Appserver users only need the ‘Normal’ role.

These users are all set up in Reference Data Manager –> Users already. They are all set up as a type of ‘Endur System Account’. This type is important as emdash does not try to add them to any AD Groups through the add/remove user process.

Note: If this is the first time that these Users have been allocated to an Environment on a new database instance, emdash will set a default password. Once you have set up the environment in its entirety and have a GUI up and running, you will need to ‘log in without encryption’ for each appserver using the provided default password, and then you will be prompted to reset the password (select the yellow triangle on the login screen to see this option). This will then encrypt the SQL Login in line with the Endur application’s requirements, and can match what you put into the Endur Runsite configuration (olfwizard.exe)

Note 2: Check the status of the Endur database at this point. We haven’t restored Endur onto the shell database we created earlier, so the adding of Users using emdash will fail in the workflow – the process for manipulating User data in Endur will not function as the Endur database schema is not present. This is fine at this point and we will fix it by way of an Env Refresh later.



You will need to add the following Applications to the environment for the Endur application to function completely. It is recommended that you select the latest Code Version available to each when you assign the Application to the Environment:

  1. Endur
  4. EndurConfigTemplates
  6. APM
  7. DMS
  8. ECMS
  10. MAIL
  13. UTM

Note: At this point, you can use the Admin Tools -> Clone Environment function to replace the versions with one cloned from a source environment (e.g. PROD). The Clone process will update the version of Endur to match the source environment, and it will also map all applications of Type ‘Endur Component’ to the target environment. Failure to map the highest level ‘Endur’ application in the first step will mean that the cloning process skips the application and does not function, however.


Database Components

There is no need to map Database Components to an Environment at this point. As these components are stored in the Endur database, the labels associated with them are replaced when the Env Refresh function runs.


The servers set up now needs to be mapped to the environment. For most, all that is required is 2 servers – one of type ‘Endur x64’ and one of type ‘Endur x86’. Multiples can be added.

Note: emdash will deploy code to all of the servers of type ‘Citrx Server’ as held in the Reference Data Manager –> Servers list. There may be occasions where you want to limit an environment to be held on only a subset of servers. If this is the case, you can map them to the Environment as Server Allocations.


This is where we map the Services (runsites) to the Servers that they are going to run on, and the service accounts that they are going to run as.

At a minimum the Environment needs to have at least one Spread service running on a server – preferably two (one per server as allocated above).

Mapping Endur services should follow the standard that we have set to allow ease of identification and troubleshooting:

  • Endur services that are ‘odd’ numbered should be x64 runsites (e.g.OpenLink_Endur1, OpenLink_Endur3, etc)
  • Endur services that are ‘even’ numbered should be x86 runsites (e.g.OpenLink_Endur2, OpenLink_Endur4, etc)
  • X64 runsites should be mapped to ‘Odd’ numbered servers
  • X86 runsites should be mapped to ‘Even’ numbered servers
  • Service Accounts should be mapped to the relevant numbered Endur service – e.g. Endur Service Account 2 should be mapped to OpenLink_Endur2. This is important if you want to run multiple runsites on a single application server.



Map the EndurDev<EnvName>Access group that was set up in step above. This is used during the add/remove user process and Env Refresh to make sure that any Users allocated to the environment above have the Citrix icon re-enabled for them. (For users of type ‘Endur User’).

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk