NX 2212 and the Siemens Advanced Licensing Technology (SALT)
NX 2212 and the Siemens Advanced Licensing Technology (SALT)
Overview
In December 2022, Siemens released the latest installment of its industry-leading product development software, NX 2212. The new release is part of an effort by Siemens to re-engineer the licensing of EDA/DISW products by transitioning from Mentor Standard and Common Licensing to Siemens Advanced Licensing Technology (SALT). With nearly 100 different license generators for the EDA/DISW applications, SALT combines the best portions of each system to simplify license delivery and lessen administrative tasks in customer environments and will affect both EDA and PLM tools.
In this article, we will explore the new SALT licensing model, which includes new licensing software with an installer, new license files, and a new API to check out both legacy and SALT licenses. While exploring the new licensing model, we will also discuss some known issues users may encounter when migrating to SALT and provide some insight to help guide you through the transition.
Introduction to the new Siemens License Server
One of the main changes users will notice when transitioning to a SALT application like NX 2212 is the requirement to migrate to the new Siemens License Server version 2.1 or later. In previous versions of the Siemens License Server (<= v1.6 or SPLM), the installer installed the Siemens (saltd), Siemens PLM (ugslmd), and Mentor (mgcld) Vendor Daemons, with each being responsible for serving its respective license features. With the new SALT licensing model, the Siemens License Server v2.1 installer installs the combined Siemens Common Vendor Daemon, saltd, and consolidates existing license servers and vendor daemons (e.g., saltd, mgcld, ugslmd, cdlmd, and RCTECH), making certain that customers have a solution to manage their newly enabled SALT applications as well as legacy applications (Figure 1) (Siemens Advanced Licensing Technology (SALT) FAQ).
Figure 1 – With SALT, the new combined vendor daemon, saltd, will serve the features of legacy vendor daemons
Whether installing the Siemens License Server for the first time or upgrading from a previous version (SPLM or SLS), the Siemens License Server v2.1 installer will guide you through the installation and configuration of the license server. Download the platform-specific Siemens License Server v2.1 software from the Siemens License Server product center (Figure 2).
Figure 2 – Siemens License Server v2.1 for Windows and Linux platforms
Based on FlexNet™ v11.19 licensing technology, SLS2.1 is optional to use with NX releases up thru NX 2206 and is backward compatible with legacy daemons from older versions of NX and other PL products, back to NX 5.0 (NX 2212 licensing changes: Mandatory use of Siemens License Server).
The Siemens License Server v2.1 installer provides an easy way to install the license server as well as perform other tasks such as repairing or updating an existing installation, replacing an existing license file, adding a new license file, or uninstalling the licensing software.
What To Know Before Updating or Installing Siemens License Server
Administrative Access – It is important to note that some configuration tasks of the installer require elevated permissions. You must have administrative privileges to install or update licensing software. If you receive a warning that you do not have these privileges, exit the Siemens License Server installer and restart the installation process. On Windows, you must install the Siemens License Server as an Administrator (Figure 3). If on a Linux platform, install SLS as root (Pre-Installation Requirements and Considerations – Siemens Digital Industries Software License Server Installation Instructions).
Figure 3 – You must have administrative privileges to install or update licensing software
Changes to license file(s) – As part of SALT, the new Siemens License Server v2.1 will introduce a few minor changes to the structure of the license file that should be mostly transparent to customers. Whether upgrading from the existing legacy license server or having a new machine without a license server, the Siemens License Server v2.1 installer automatically modifies the imported license file with the following required edits:
License file before edits:
################################################################################
SERVER <your server hostname> <your composite ID> 28000
VENDOR ugslmd
License file after edits:
################################################################################
SERVER <your server name> <your composite ID> 29000
VENDOR saltd saltd PORT=29001
It is important to note that with SALT the license file you receive from Siemens does not change when imported. The Siemens License Server v2.1 creates a new file from the imported file, adds the required edits, and saves it in a default location.
Location of installed license file(s) – In addition to editing the license file, the Siemens License Server v2.1 renames and installs the imported license file to a default location. This behavior is similar to legacy versions of the license server (SPLM or SLS) and should be familiar to users. For example, when installing the Siemens PLM License Server v11 software, the installer prompts the user for the path to their license file and, when the installation is complete, creates a new file named “splm11.lic” and saves it in the root of the “PLMLicenseServer” installation:
Figure 4 – Legacy versions of the license server installed the license file in the root of the license server installation
With the new SALT Siemens License Server v2.1, the installer now installs the imported license file in a new default location outside the license server installation. On Windows, the default location is C:\ProgramData\Siemens\License Server\ActiveLicenses\<vendor_daemon>.lic. On Linux, the default location is /opt/Siemens/LicenseServer/ActiveLicense/<vendor_daemon>.lic.
Figure 5 – Siemens License Server v2.1 installs the license file in a new default location
This behavior differs from legacy versions of the license server by installing the imported license file outside the Siemens License Server installation and creating an “ActiveLicenses” folder that the license manager serves the license from.
What To Expect When Updating or Installing Siemens License Server
Upgrading from a previous version – If an earlier version of Siemens PLM License Server or Siemens License Server v1.2-1.6 has been installed and configured, running the new SLS2.1 installer will automatically upgrade the license manager, making any necessary changes to your license file and services to support the saltd vendor daemon (shown above). The Siemens License Server v2.1 installer detects any Siemens licensing products (SPLM License Server or Siemens License Server) currently installed and displays a message notifying the user that the current license server will be upgraded and prompt them to proceed. Clicking Yes will begin the upgrade.
It is important to note that upgrading the license server will permanently delete the server log files. If you need to retain the log files, copy them to a location outside the current SPLM or SLS installation before running the Siemens License Server v2.1 installer.
The first step in the upgrade process will introduce one of the main differences users will encounter when migrating to Siemens License Server 2.1, Port Changes. As noted above, during an upgrade or installation, the SLS2.1 installer defaults to port number 29000, which was 28000 in previous versions. Using the default port number is NOT REQUIRED when updating the license server. Non-default and unique port numbers validated by your IT team are permitted for outgoing (28000) and incoming (28001) ports. To override the default 29000/29001 port numbers, check the “Advanced Settings” checkbox and add the appropriate server and vendor daemon port numbers in their respective fields (Figure 4).
Figure 6 – Change the default port numbers by checking the Advanced Settings checkbox
Please note that if using the new default port number (29000), the SPLM_LICENSE_SERVER system environment variable on each user’s client machine will need to be changed. The port number value must match the value in the SPLM_LICENSE_SERVER system environment variable. We will discuss environment variables in a later section. If there is a need to change the port numbers after updating the license server, re-run the Siemens License Server v2.1 installer and follow the prompts in the Manage Software window.
Continuing with the upgrade,
Upgrading to the Siemens License Server v2.1 results in the migration of the mgcld, ugslmd, cdlmd, and RCTECH vendor daemons to the saltd vendor daemon. Upon completion of the upgrade
During the upgrade or installation process, users can choose to import a license file allowing the SLS to create the corresponding license manager service automatically.
Figure 7 – Importing a license with SLS2.1 creates the corresponding license manager service in LMTOOLS
If you do not want to import a license file, click Skip to move to the next step of the installation. Remember, if you do not import a license file, the corresponding license manager service is not created in LMTOOLS and will need to be configured and started manually (see Figure 5).
Figure 8 – With no license file imported, the corresponding license manager service is not created
If you receive a new license file from Siemens and have already installed the Siemens License Server 2.1, Siemens recommends using the SLS2.1 installer to import the new license file. Simply run the installer as administrator (root on Linux) and the Manage Software window opens with the Update License Server Software option selected by default. Select the Add/Replace License File option and click Next (Updating the License File – Siemens Digital Industries Software License Server Installation Instructions).
My name is Aaron Jackson, I’m a NX CAM Application Engineer and Technical Support Lead at Swoosh Technologies and Solutions. With nearly 20 years of experience in manufacturing, as both a CNC programmer and a CNC Machine Tool Applications Engineer, I bring a wealth of knowledge and experience from various manufacturing sectors, including the medical, defense, communications, and automotive industries.
Post by Aaron Jackson
My name is Aaron Jackson, I'm a NX CAM Application Engineer and Technical Support Lead at Swoosh Technologies and Solutions. With nearly 20 years of experience in manufacturing, as both a CNC programmer and a CNC Machine Tool Applications Engineer, I bring a wealth of knowledge and experience from various manufacturing sectors, including the medical, defense, communications, and automotive industries.
Port Forwarding the old service ports to the new consolidated SALT license service.
One of the challenges of migrating to SALT licensing is that all four of the old services must be migrated at the same time.
(It’s not allowed to run the old services on the same server as the new v11.19 saltd, as this would multiply the number of licenses available)
If you have many users, it can be a challenge to get all the software products redirected to look to the new consolidated service port for licenses.
Using port forwarding on the server, can be a stop gap measure, to keep old license service references working, while you get your user’s software reconfigured to look at the new SALT service ports. A powershell script, like the example below (not well tested. use at your own risk), might be used to setup port forwards on the server, from the old ports to the new ports.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
# This script creates port forwards from the old license service ports to the new Siemens License Service ports.
# These are the new port number for lmgrd ($ManagerPort default 29000) and saltd ($VendorPort default 29001)
# If needed, modify these port numbers for the Siemens License Service
$ManagerPort=29000
$VendorPort=29001
# This is the list of typical service ports for the old services .. mgcld, ugslmd, cdlmd, rctech
# The list is in pairs .. old port number and if it is to be forwarded to the $ManagerPort or the $VendorPort
# Compare these port numbers to the ports designated in the old license files, and modify, here, if needed.
$FwrPorts = @(
28000,$ManagerPort,
1999,$ManagerPort,
1717,$ManagerPort,
27027,$ManagerPort,
2099,$VendorPort)
# Also, the forwarding ports are open in the Windows Defender Firewall.
# Use a ‘-delete’ parameter, to remove the port forwards and their special firewall rules
# or a ‘-list’ parameter to just license current port forwards.
# Save this script to a .ps1 file and open a Powershell ‘..as Administrator’
# To allow running .ps1 scripts, you may need to manually run:
# set-executionpolicy -executionpolicy Unrestricted -scope Process
# then run this script.
# Check if the script is running in elevated Administrator mode
if (-not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
$thisscript = $MyInvocation.MyCommand.Definition
Write-Output “This script sets or removes port forwards to the new Siemens License Service.”
Write-Warning “This script requires elevated Administrator privileges.”
Write-Warning “Please run this script in a Powershell launched as an Administrator.”
Write-Warning “In that shell, you may first need to run: set-executionpolicy -executionpolicy Unrestricted -scope Process”
Write-Warning “Then run: $thisscript [-delete | -list]”
#Write-Warning “Start-Process powershell.exe -File `”$params`” -Verb RunAs”
Exit
}
# List all currently defined port forwards
Write-Output “Currently Defined Port Forwards:”
netsh interface portproxy show all
Write-Output “Firewall Rules for Siemens License Service”
Get-NetFirewallRule | Where-Object {$_.DisplayName -like “*Siemens License Service*”}
# for each port pair, define a port forwarding rule and open the forwarding port to the firewall
# firewall profile for non-restrictive connections: profile=Domain,Private,Public
$FirewallProfile = “Domain,Private,Public”
if ($args.Contains(“-list”)) {
Write-Output “Currently Defined Port Forwards:”
netsh interface portproxy show all
exit
}
for ($i=0; $i -lt $FwrPorts.Count; $i+=2) {
$fromPort = $FwrPorts[$i]
$toPort = $FwrPorts[$i+1]
if ($args.Contains(“-delete”)) {
# Delete the port forwarding of the old port number.
Write-Output “- – Removing Port Forward of $fromPort – -”
netsh interface portproxy delete v4tov4 listenport=$fromPort listenaddress=0.0.0.0 protocol=tcp
# Delete any previously created firewall rules for the old port#, in case script is run multiple times.
Write-Output “- – Removing Firewall Rule: Siemens License Service Forwarded Port $fromPort”
netsh advfirewall firewall delete rule “Siemens License Service Forwarded Port $fromPort”
} else {
# Create the port forward from the old port to the new port number.
Write-Output “- – Creating Port Forward of $fromPort – -”
netsh interface portproxy add v4tov4 listenport=$fromPort listenaddress=0.0.0.0 connectport=$toPort connectaddress=127.0.0.1 protocol=tcp
# Delete any previously created firewall rules for the old port#, in case script is run multiple times.
Write-Output “- – Removing Any Old Firewall Rules: Siemens License Service Forwarded Port $fromPort”
netsh advfirewall firewall delete rule “Siemens License Service Forwarded Port $fromPort”
# Add a firewall rule, allowing connections to the old service port#.
Write-Output “- – Adding Firewall Rule: Siemens License Service Forwarded Port $fromPort”
netsh advfirewall firewall add rule name=”Siemens License Service Forwarded Port $fromPort” dir=in profile=$FirewallProfile action=allow protocol=TCP
# Display the details of the new firewall rule for the forwarded port.
netsh advfirewall firewall show rule name=”Siemens License Service Forwarded Port $fromPort”
}
}
Write-Output “Firewall Rules for Siemens License Service”
Get-NetFirewallRule | Where-Object {$_.DisplayName -like “*Siemens License Service*”}
Get-NetFirewallRule | Where-Object {$_.DisplayName -like “*saltd.exe*”}
Get-NetFirewallRule | Where-Object {$_.DisplayName -like “*lmgrd.exe*”}
# List all currently defined port forwards
Write-Output “Currently Defined Port Forwards:”
netsh interface portproxy show all