Overview of the Siemens Automation License Manager (ALM)
The Siemens Automation License Manager (ALM) is the central license administration service for the entire SIMATIC engineering stack, including TIA Portal (V13 through V19), STEP 7 V5.x, WinCC V7 and TIA WinCC, SIMOTION Scout, SINAMICS Startdrive, and the Safety Integrated engineering tools. ALM runs as a Windows service that brokers license keys between a license server, client engineering PCs, and virtual machines (VMS) over TCP/IP. Without ALM, every workstation would need a physical license (USB dongle, hardlock, or local license file) and engineering pools would either sit idle or be over-licensed.
ALM is delivered on the TIA Portal installation media (and as a stand-alone installer on the SIMATIC software DVD). When you double-click Setup.exe from the installation medium, ALM installs alongside the engineering tool, but you can also install only the ALM service on a dedicated license server that hosts no TIA Portal. This split installation is the typical architecture for a multi-VMS engineering environment, where the ALM service is consolidated on a hardware server while the engineering work happens inside VMware Workstation, Hyper-V, or ESXi VMs running on developer laptops and plant-floor stations.
The license keys themselves live in one of three storage types managed by ALM:
-
Local license file (.lic or .zip with .lic): bound to the PC's CPU ID or to a USB dongle. Stored under
C:\ProgramData\Siemens\AutomationLicenseManager\by default. - USB hardlock: a red Siemens license dongle, treated by ALM as a removable license container.
- Network/floating license: registered to the ALM service and shared out to clients. This is the only license type that supports Checkout and Transfer.
The Checkout and Transfer mechanisms discussed in this article apply exclusively to network (floating) licenses registered on an ALM server. Local license files and USB hardlocks do not participate in either process.
ALM License Models: Floating, Node-Locked, and Upgrade
| Model | Where the key lives | Sharing mechanism | Use case |
|---|---|---|---|
| Floating (concurrent) | ALM license server | Client connects to server, holds key for the session | Engineering pools, multiple VMS, office workstations |
| Node-locked (local) | Local .lic file or USB hardlock on one PC |
None - bound to one CPU ID | Lone field engineer, single-machine test bench |
| Upgrade | ALM license server, but tagged as "upgrade" | Auto-detected at startup; converts an old version license | Migrating from V15 to V17 while keeping V15 keys for legacy work |
| Counted (Count_X) | ALM license server | One server check-out consumes one count unit | Multiple seats per license (for example, 3-seat floating license) |
From the ALM main window you select the host in the left pane, open the License Keys tab on the right, and the status column shows whether each key is Available, Checked Out, or Transferred. Right-click a key to expose the actions available for that key. The actions offered by the context menu depend on the key type and on whether the target host is reachable on the network at the moment of the right-click.
License States in ALM
ALM tracks four states for each license entry. Understanding the transitions between these states is the key to choosing between Checkout and Transfer.
- Available: the license is on the server and idle. Any client can request it.
- In Use (server session): a client has a live TCP connection to the server on port 4410 and the server has granted the license for the duration of that connection.
- Checked Out: the license has been copied to a client machine and is locked to that client until the client returns it (either automatically when the engineering software closes, or manually via ALM).
- Transferred: the license has been moved off the server entirely. The server no longer holds a copy and cannot serve the license to anyone else until the client returns it. This is a permanent state change until reversed.
Critical distinction: a Checked-Out license still exists on the ALM server (as a record), but it is marked unavailable because a client holds the active lease. A Transferred license no longer exists as a server-side record at all - the bit pattern of the key has been moved to the client and the server's copy is invalidated. This is why a server crash followed by restore from backup can resurrect a Checked-Out license but cannot resurrect a Transferred one if the client never returns it.
License Checkout vs Transfer: Technical Comparison
| Aspect | Checkout | Transfer |
|---|---|---|
| License remains on server? | Yes - server keeps a record, marks it unavailable | No - license is moved to client, server has no copy |
| Return mechanism | Automatic when the engineering software (TIA Portal, WinCC, etc.) closes, OR manual via ALM Check In | Manual via ALM Transfer Back; never automatic |
| Network required while using license? | Yes - the client must remain in contact with the ALM server for periodic heartbeat/renewal (depending on ALM version, 0-30 minutes) | No - once transferred, the client is fully offline-capable |
| Server visibility of the lease | Continuous; server sees client online/offline status | None after transfer; server believes license is gone |
| Preferred scenario | Same LAN, VPN with constant connection, office work | Off-site work, customer sites without VPN, air-gapped test rigs |
| Failure mode if client is destroyed | License lease eventually expires and returns to the server (timeout depends on ALM build) | License is permanently lost unless the client machine (or its backup) is recovered |
| Visible in ALM UI | Listed under the client host with "Checked Out" badge | Not listed on server at all; visible only on client host |
| Multiple VM hosts in parallel | Yes - each VM holds its own checkout, server tracks N concurrent checkouts up to the license count | Yes - each VM can receive a transferred copy, but the license count is consumed on the server at transfer time |
Checkout Lifecycle: How the License Travels
The Checkout mechanism is implemented as a lease with auto-return. The sequence is:
- Engineer opens TIA Portal on VM-A, which makes a request to the ALM server for a floating license.
- The ALM server grants the license, marks the record as Checked Out to VM-A, and holds a TCP session open to VM-A.
- While the TIA Portal session is active, the lease is renewed in the background (silent TCP keep-alive on the ALM port).
- When TIA Portal closes cleanly, the client sends a Check In message to ALM and the server immediately releases the license.
- If the VM crashes, the network drops, or the client host is powered off without graceful shutdown, ALM waits for the lease heartbeat to expire (typical: 30 minutes, configurable in some ALM builds) before releasing the license back to the pool.
Because the license still nominally lives on the server, the server can show other engineers that the key is currently unavailable. This makes Checkout the right choice for a multi-VMS office where transparency into the license pool matters.
Transfer Lifecycle: How the License Travels
Transfer is implemented as a one-way move with manual return. The sequence is:
- Engineer opens ALM on the ALM server (or on a client with management rights), right-clicks the license, selects Transfer, and enters the target VM hostname or IP.
- ALM bundles the license key into a transport file and ships it to the target machine via the ALM port. The server-side record is invalidated.
- The target VM stores the license locally (typically under
C:\ProgramData\Siemens\AutomationLicenseManager\) and the engineer can now use TIA Portal with no network connectivity to the server. - When the engineer returns to the office and reconnects to the corporate network, they open ALM on the VM, right-click the transferred license, and select Transfer Back to Server.
- ALM deletes the local copy on the VM and re-registers the license with the server. Only at this moment is the license visible again in the server's pool.
Operational risk: if the VM hard disk is encrypted with BitLocker and the recovery key is lost, or if the VM snapshot is reverted to a state before the transfer, the transferred license is irrecoverable. Always image or back up the VM before transferring a license to it, especially for high-value keys such as the TIA Portal Professional or WinCC Comfort/Advanced suite.
Network Requirements and Failure Modes
| Scenario | Checkout behavior | Transfer behavior |
|---|---|---|
| Stable LAN, both VMs online | Works as expected; license returned at TIA Portal close | Works as expected; manual transfer-back required at end of engagement |
| VPN drops for 5 minutes mid-session | TIA Portal may show "License lost" banner, but the lease timer has not expired. Reconnect VPN and the lease resumes. | No effect - transfer is offline by design |
| VPN down for 4 hours | Lease timer (typically 30 min) expires, license returns to server. TIA Portal prompts for re-activation on the next user action. | No effect |
| VM snapshot reverted to pre-TIA state | VM loses the checked-out lease state. After timeout, server releases. Slight risk of double-allocation if another VM requests the same key before timeout. | VM loses the local transferred license. Server has no record of it either. Total loss unless backup is restored. |
| License server rebuilt from backup | Checked-out licenses may reappear with their original lessee if backup predates the checkout; otherwise checkout records are lost and licenses return to Available | No recovery - the moved license is gone forever from the server's perspective |
| USB hardlock used as ALM store | Not applicable - USB hardlocks are local and cannot be checked out or transferred | Not applicable |
Setting Up ALM as a License Server for VMware VMS
The recommended deployment for an engineering team running TIA Portal or WinCC inside VMware Workstation, ESXi, or Hyper-V is to put the ALM service on a dedicated Windows server (physical or VM) and let every engineering VM act as a client. The official Siemens procedure is documented in Siemens Support entry 18602618 - Set up a license server and operate the ALM as a license server for VMware Workstation. The condensed procedure is:
- Provision a Windows Server 2019/2022 (or Windows 10/11 if no server OS is available) host with a fixed IP address and a static DNS record, for example
alm-prod.plant.local. - Copy the ALM installer from the TIA Portal installation medium or download from the Siemens Industry Online Support portal. The installer name is typically
Siemens_Automation_License_Manager_Vx.x.x.x_setup.exe. - Double-click
Setup.exe, accept the license agreement, and choose Install Automation License Manager. Decline the TIA Portal components if the host is to be a license-only server. - When prompted, select Install as Service. This registers ALM as
Siemens Automation License Manager Serviceand starts it under the Local System account. - Open Windows Firewall with Advanced Security and create an inbound rule for TCP port
4410(default) and UDP port4410. If you change the port via the ALM settings dialog, update both the firewall and the client configuration. - Place the network license files (
.lic) or register the floating license CoL certificate in ALM on the server. Restart the ALM service. - On each engineering VM, install ALM in Client mode (this is the default when TIA Portal is installed). Open ALM, choose Connect to License Server, and enter
alm-prod.plant.localor the server IP. - Verify connectivity by opening TIA Portal on the VM and confirming the license status indicator in the bottom-right corner shows Valid license.
For VMware specifically, set the VM's UUID to a fixed value (VMware Workstation: vmware.uuid.action = "create" in the .vmx) so that license bindings tied to the VM's CPU ID remain stable across reboots. Some Siemens licensing keys include a host fingerprint that includes UUID-derived data, and a changing UUID will invalidate the license on every restart.
Checkout Procedure Step-by-Step
- On the engineering VM, launch Automation License Manager from the Start menu.
- In the left pane, expand the entry for the ALM server (for example,
alm-prod.plant.local [4410]). - Click the License Keys tab. Locate the floating license you need (for example,
TIA Portal Pro V17 Floating). - Confirm the status column shows Available. Right-click the license and select Check Out.
- ALM prompts for the target host. The target defaults to the local machine (the VM you are running ALM on); accept it and click OK.
- ALM copies the key to the local machine and updates the server record. The status changes to Checked Out to [VM-NAME].
- Launch TIA Portal. The bottom-right status bar shows the active license.
- On closing TIA Portal, ALM automatically returns the key. You can confirm by refreshing the License Keys tab on the server - the status reverts to Available.
To force a manual early return: on the VM, open ALM, switch to the local host node, click License Keys, right-click the checked-out license, and choose Check In. The key is immediately available on the server for the next engineer.
Transfer Procedure Step-by-Step
- On the engineering VM that will be taken off-site, install ALM (the client mode is sufficient).
- Connect the VM to the corporate network. Open ALM.
- In the left pane, select the ALM server. Click License Keys.
- Right-click the floating license you need and choose Transfer.
- ALM displays the target host dialog. Enter the VM hostname or IP. Confirm.
- Wait for ALM to confirm successful transfer. The license disappears from the server's License Keys tab and appears under the local host node.
- Disconnect the VM from the corporate network. Verify by disabling the network adapter or unplugging the VPN - TIA Portal should continue to run normally.
- When you return to the office, reconnect the VM to the network. Open ALM, click on the local host node, right-click the transferred license, and select Transfer Back.
- Confirm the target server. The license returns to the server's pool and is once again listed as Available for other engineers.
Tip: before transferring, click Show Details on the license entry and note the license certificate number. If the transfer-back fails or the VM is lost, this number allows Siemens support to issue a replacement CoL (Certificate of License) - but only if you have an active Software Service Contract for the license.
Verification and Diagnostics
After any Checkout or Transfer operation, run the following checks:
- Server-side ALM view: the license should be visible under License Keys with the appropriate status (Checked Out to VM-NAME for Checkout, or absent for Transfer).
- Client-side ALM view: the license should appear under the local host node.
- TIA Portal status bar: the bottom-right license indicator should show Valid license in green.
-
Command-line verification: on the server, run
netstat -an | findstr 4410to confirm active client connections. - Event log: ALM writes informational and error events to Windows Logs > Application with source Siemens ALM Service. Event IDs 0, 100, and 200 are informational; 400 and above indicate errors.
- Cross-check license counts: if your TIA Portal Pro license is Count_3 (3 seats), the ALM server should show three separate checkouts or transfers possible before reporting Not available.
Troubleshooting Matrix
| Symptom | Likely cause | Resolution |
|---|---|---|
| "License not available" in TIA Portal, but ALM server shows Available | Client cannot reach ALM server on TCP 4410 | Verify firewall rule, ping the server, confirm port via Test-NetConnection server -port 4410
|
| "License not available" in TIA Portal, ALM server shows Checked Out to OTHER-VM | Another VM still holds the lease | Contact the other VM's user; if VM is offline, wait for lease timeout (typically 30 min) |
| License disappeared from server after engineer returned from site | Transfer was used and transfer-back was never performed | Have the engineer connect to the network and run Transfer Back on the VM |
| VM was rebuilt from snapshot, license is lost | Snapshot reverted to pre-transfer state | If backup of the pre-snapshot VM exists, restore from backup; otherwise request replacement CoL from Siemens support with proof of original purchase and Service Contract |
| Multiple VMs report "License already in use" simultaneously | Count_X license is fully consumed | Close other instances or wait for them to release; verify the license seat count meets peak demand |
| ALM service stops unexpectedly on server | Service account lost logon rights, port conflict, or disk full | Restart service via services.msc; check Windows Logs > System for service control manager errors |
| VMware VM loses license on every reboot | VM UUID is changing on each power-on | Edit .vmx and set uuid.action = "keep"; re-apply the license |
| License file shows as "Defective" in ALM | License file mismatch with installed TIA Portal version | Verify TIA Portal version matches the license certificate; request version-correct CoL from Siemens |
Best Practices for Multi-VMS ALM Deployments
-
Centralize the ALM service on a dedicated host with UPS protection, scheduled snapshots, and a documented backup procedure. Back up the
C:\ProgramData\Siemens\AutomationLicenseManager\directory daily. - Prefer Checkout over Transfer for any engineer who has reliable network access to the server. Transfer should be reserved for site visits, customer demos, and air-gapped test rigs.
- Document every Transfer in a license log: who, when, which license, when expected back. Treat the transferred license like a physical asset.
- Size the license pool to peak concurrent demand rather than headcount. A team of 10 engineers may only need 6 floating seats if at most 6 work simultaneously.
- Use Count_X licenses instead of separate single-seat licenses where Siemens offers them. This reduces administrative overhead.
- Configure lease timeout appropriately. The default 30-minute lease can leave licenses stranded during long VM suspensions (for example, an engineer closes the laptop lid at a customer site for two hours). Lower the timeout to 10-15 minutes for high-utilization pools.
- Avoid Checkouts across slow WAN links. If your engineering site connects to the ALM server over a VPN with more than 100 ms RTT, consider a regional ALM server that mirrors the master server rather than direct Checkout.
- Test the failure path. Before relying on Transfer for a critical on-site engagement, transfer and untransfer a test license to confirm the workflow. Document the transfer-back credentials and steps on paper in case the engineer's laptop is unavailable.
- Keep TIA Portal and ALM versions aligned across the server and all VMs. Mixing ALM V6.4 on the server with TIA Portal V17 clients works, but mixing server-side ALM versions can cause silent compatibility issues with newer CoL certificates.
Differences from Other ALM Products
The term ALM is overloaded across the software industry. To avoid confusion:
- Microsoft Power Platform ALM (Microsoft Learn - ALM overview) refers to application lifecycle management for Power Apps, Power Automate, and Dataverse. It is unrelated to industrial automation licensing.
- Micro Focus ALM / Broadcom ALM (Broadcom TechDocs) is a quality and test management platform. It is unrelated to Siemens automation.
- Siemens Automation License Manager (ALM) is the product covered in this article. It is delivered with TIA Portal, STEP 7, WinCC, and the rest of the SIMATIC engineering suite.
When searching Siemens Industry Online Support, search for "Automation License Manager" (full phrase) to filter out unrelated results.
What is the difference between License Checkout and License Transfer in Siemens ALM?
Checkout keeps the license on the ALM server and grants a temporary lease to the client; the license returns automatically when TIA Portal closes. Transfer moves the license off the server entirely to the client, requires manual transfer-back, and allows fully offline use.
Which method should I use for VMware Workstation VMs in the office?
Use Checkout. The VMs are on the same LAN as the ALM server, so the lease is reliable, and the license returns automatically when TIA Portal closes. Reserve Transfer for engineers who take a VM off-site or to customer facilities without a constant VPN.
What happens to a transferred license if the VM is destroyed?
The license is permanently lost from the server's perspective. Restore the VM from a backup taken after the transfer, or request a replacement Certificate of License (CoL) from Siemens support - which requires an active Software Service Contract and proof of original purchase.
Can two engineers check out the same floating license at the same time?
Only if the license is a Count_X license with a seat count greater than one. A single-seat floating license can only be checked out by one client at a time; the second request will fail with "License not available" until the first engineer closes TIA Portal and the lease returns.
How long does ALM wait before reclaiming a checked-out license after a VM crash?
The default lease heartbeat timeout is approximately 30 minutes, depending on ALM build and version. During this window the license is shown as checked out to the offline VM. After timeout the server releases the license and marks it Available again.