I am following the Post Installation document for a cumulative patch in an environment which is configured as 'Conventional' - that is, it has a primary server and one (or more) secondary servers.
The document is the file named "Post_Installation_and_Backout_Steps_for_Conventional_for_Windows_Cumulative.txt".
In my test environment, with Version Control enabled by default, all updates to NX.env on the Primary are propagated to the Secondary's NX.env after the restart. The order of services restart is per best practices: stop service on primary, stop service on each secondary, start service on each secondary, start service on primary).
In the post-install instructions, for every step that would have the effect of updating the NX.env file, such as by running the pdm_options_mgr command on the primary server, the instructions recommend manually updating the NX.env file on the secondary. This seems unnecessary. Why is this being advised?
The reference is to the following Note in the "Post_Installation_and_Backout_Steps_for_Conventional_for_Windows_Cumulative" document:
For each secondary Service Desk server you have configured,
please manually add or update the NX variable above in each
secondary Service Desk server machine within its NX.env file
located under $NX_ROOT directory.
A Service Desk product recycle is normally needed for the new
NX variable to take effect.
Following the note could prove to be unnecessary. In fact, it is not generally advisable to manually edit the NX.env file.
The note is more of a caution. It should cause the reader to at least review and verify the NX.env file of the secondary servers in order to be sure that the environment variable has been propagated. This is due to some potential situations which may occur. (It is also advisable to check that the NX.env_nt.tpl file on each secondary has been correctly updated.)
One situation that could cause missing entries on the secondary server after a re-start, is that version control could be currently disabled in the environment, as the result of an earlier administrative decision and action that turned it off.
Another potential situation is that some users may have manually edited the NX.env and the NX.env_nt.tpl files on the primary server, instead of running the pdm_options_mgr commands which are set out in the instructions.
Manually editing the files is not recommended. Running the pdm_options_mgr command is the recommended method because when that command is run, it not only updates the local NX.env file, but it also sets up the propagation of the variables to the remote files on the secondary server. It does this by updating the $NX_ROOT\site\client_nx.env file on the local server. The propagation to the secondary servers is completed by version control during startup.
A copy/paste of the pdm_options_mgr command from the Post Install document could be a good habit to adopt. Be careful with the copy/paste though - if the command spans multiple lines in the document, you would need to combine the lines into a single line before running the command. The copy/paste should help to avoid mistakes related to the following extension to the note that is included in the Post Installation document:
We are seeing instances of NX_ being added to the variable
specified in the pdm_options_mgr command which is incorrect.
The pdm_options_mgr command will automatically append NX_ in front
of the variable when executed.
The final advice is that the pdm_options_mgr command should be run when the CA Service Desk Manager service on the primary server is up and running, since it attempts a back-end synchronization with the Options table in the mdb database and that can only occur if the database can be accessed.