NX, and several other Siemens products (TC, TCVIS, ...) are based on the SPLM_LICENSE_SERVER variable to allow client host to check out licenses from license server(s); hence, if the Siemens license manager is transferred to a different host, IT administrator will have to edit and adjust that single OS environment variable to reflect the new server setup.
For large sites this involves editing interactively that variable on each client hosts, this can be cumbersome and time-consuming.
Even if this has nothing to do with Siemens SW management and configuration it would be nice to be aware of some method available within the Windows OS to automate this operation to freely modify that or any other OS env. variable.
SolutionWindows OS makes available a suitable set of tools to manipulate system/user environment variable, the most powerful is the Powershell scripting language.
On the Internet, just 'google' around, you will find plenty, actually tons, of information about that, e.g. the official Microsoft guides here https://learn.microsoft.com/en-us/powershell/
A simple Powershell script that can (as administrator) simply achieve that target to automate tweaking the SPLM_LICENSE_SERVER variable is this single-line sample ('Machine' option at the end is there to set the variable at Machine/System level and not at User level).
[Environment]::SetEnvironmentVariable('SPLM_LICENSE_SERVER','29000@site_server','Machine')
The syntax is straightforward: the first argument is the name of variable to set (it creates a brand new variable if not existing), the second argument is the variable value and the third one is there to preset that variable at System level (not at User level).
Here how it appears in the Powershell ISE/IDE, that can be conveniently used to create any Powershell script (while it is a simple text file that you can create in any plain text editor and save with the standard .ps1 extension).
Once created you can either interactively run within the Windows Powershell ISE but most times it won't work unless you're running that tool as administrator.
However there are several ways, not detailed and investigated in-depth here, that IT administrators can exploit to automate the execution of that simple script, even remotely, on all their client hosts.
One simple way to get it working locally on your workstation(s) is to create a common batch file, e.g. with the same name of the Powershell script and in the same folder.
Something like this within the batch file will do the job to call the Powershell script.
Please notice the 2nd entry, powershell ..... , is on a single-line (word-wrap enabled in Notepad above).
@echo off
powershell -NoProfile -ExecutionPolicy Bypass -Command "Start-Process -Verb RunAs powershell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File \"C:\TEST\set_server.ps1\" -_vLUF %_vLUF%'"
TIMEOUT /T 10
Instead, as mentioned above, the Powershell scripts, will be that single-entry line, already commented above.
If you then run that batch file as administrator you'll be able to tweak the env. variable by the Powershell script: in any case probably an UAC alert will pop up (hit ok to proceed, of course) along with a quick Powershell window (at last a timeout window, the 3rd entry in the sample batch file, just to have some feedback to know the job is done).
Eventually you'll find out the job is done.
There are, as mentioned above, several other methods available to do that at higher level of automation and even remotely, e.g. the Task Scheduler as detailed below, but the basic Powershell script to use is always the simple sample detailed in this article.
In this last use-case we simply force that environment variable each time (several types of Scheduler Triggers are available for that, e.g. at user logon) any user unlocks that workstation.