Fixing TIA Portal V15 License Step 7 Not Found Error

Problem Details

After installing TIA Portal V15 Basic on a Windows workstation and transferring a valid license key to the same drive (typically C:\), the engineering environment fails to recognize the license when the user attempts to add a device to a project. The dialog stalls with the error string "license step 7 was not found", and the Automation License Manager (ALM) itself launches with the first-line message "corrupt ALM" before partially opening. The license that was transferred never moves to the Used column; it remains stuck or is invisible inside the manager.

On a 64-bit Windows 7 Home Premium workstation the symptoms are repeatable across cold boots. A Repair installation triggered from the Windows Programs and Features applet, and a full Modify/Repair cycle from the original TIA Portal V15 setup, both fail to clear the fault. The license container is reported by the manager as damaged even though the underlying *.lic file and the C:\Program Files\Siemens\Automation License Manager\ tree are physically present on disk.

Affected Products and Versions

Observed Error Strings

• license step 7 was not found — surfaced when the Add New Device dialog checks for a valid TIA Portal / STEP 7 license in the local ALM vault.
• corrupt Alm — first status line of the Automation License Manager at startup when its internal license database (the axalerter.dat, keys.db, and binary index files) cannot be read.
• License entries remain in Not Used state and cannot be activated via the Activate context menu.

Root Cause

The Automation License Manager maintains three coupled data structures on disk: the binary license database (keys.db), a hash index file, and the per-key *.lic files. The error appears when the database is left in a partially written or schema-incompatible state, typically caused by one of the following:

1. In-place ALM upgrade gap. TIA Portal V15 was bundled with ALM V6.0 baseline. Siemens released ALM V6.0 SP1 (and later ALM V6.0 SP2, SP3, SP4, SP5) to fix database-corrupt defects present in the baseline. The original bundled ALM can produce the corrupt ALM status when it encounters license containers that were touched by a newer build of the manager.
2. Interrupted license transfer. Transferring a license key while the ALM service is still settling from the TIA Portal install — or while the License Manager Service (almservice.exe) holds a write lock — produces a torn write on the database file.
3. Damaged installation folder. A previous partial uninstall, antivirus quarantine, or a forced reboot after a Windows Update can leave the C:\Program Files\Siemens\Automation License Manager\ tree in an inconsistent state. A Windows Installer Repair will not purge and rebuild this folder — it only re-registers DLLs and COM components.
4. Concurrent ALM instances. Running two ALM versions in parallel (e.g. a V16 manager installed side-by-side with a V15 TIA Portal) can write to the same key store with different schema versions, corrupting the index.

The repair and re-install paths attempted in the original report are not sufficient because Windows Installer does not remove the orphaned folder contents, and it leaves the older ALM service binary in place. Only a full uninstall plus a manual folder delete restores a clean state for a fresh ALM V6.0 SP1 install.

Solution

Recover the workstation by performing a clean uninstall of the existing Automation License Manager, manually purge its installation folder and the per-user license cache, then install the current ALM build from the official Siemens Industry Online Support (SIOS) entry.

Prerequisites

• Local administrator account on the affected workstation.
• Original TIA Portal V15 setup media or a current TIA Portal installer (V16, V17, V18, or V19 will coexist with the V15 project files via the compatibility mode).
• Backup of all active license keys. Export the license list from ALM via Edit > Export License Usage before uninstalling, or re-stage the keys from the Siemens license web portal at Siemens License Web Portal.
• Stable internet connection to download the current ALM package (approx. 350 MB for the full bundle).

Step-by-Step Recovery Procedure

1. Stop the License Manager service. Open an elevated command prompt and run:
   net stop "ALM_1.0_service"
   If the command returns service not started, that is acceptable. Confirm the service is stopped with:
   sc query "ALM_1.0_service"
2. Close every Siemens process. Kill any residual almservice.exe, ALM.exe, and S7tgtopx.exe instances via Task Manager > Details. Leaving these running prevents the uninstaller from acquiring the file lock on the installation folder.
3. Uninstall ALM through Windows Settings. Open Settings > Apps > Apps & features (Windows 10/11) or Control Panel > Programs and Features (Windows 7). Locate Siemens Automation License Manager, select it, and click Uninstall. Confirm the UAC prompt and let the uninstaller complete.
4. Manually delete the ALM installation folder. Open an elevated cmd.exe and execute:
   rmdir /s /q "C:\Program Files\Siemens\Automation License Manager"
   On a 64-bit OS, also check the Program Files (x86) tree. If the folder is locked, boot into Safe Mode with Command Prompt and repeat the rmdir line, or use Sysinternals handle.exe to identify the holding PID.
5. Purge the per-user license cache. Delete the contents of the local user ALM cache:
   rmdir /s /q "%LOCALAPPDATA%\Siemens\AutomationLicenseManager"
rmdir /s /q "%APPDATA%\Siemens\AutomationLicenseManager"
   On Windows 7 these paths map to C:\Users\<user>\AppData\Local and Roaming.
6. Remove the ALM service registration. If the uninstaller left the service installed, force its removal:
   sc delete "ALM_1.0_service"
   Verify the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ALM_1.0_service is gone; if not, delete it manually with regedit after exporting a backup.
7. Restart Windows. This flushes any file handles held by antivirus, the Windows Search indexer, and the SMS Host service that may be monitoring the Siemens folder.
8. Download the current ALM build. Retrieve the latest supported Automation License Manager package from the official Siemens KB entry: SIOS entry 114358 — Automation License Manager download. The current shipping version at the time of this article is ALM V6.0 SP1 (or later SP). Save the package to C:\Temp\ALM\.
9. Install the new ALM. Right-click the downloaded Setup.exe and select Run as administrator. Accept the license agreement, leave the default install path (C:\Program Files\Siemens\Automation License Manager\), and complete the install. The installer registers a fresh ALM_1.0_service and writes a clean keys.db.
10. Re-stage the licenses. Open the new ALM, connect to the local service, and either drag the backed-up *.lic files onto the license list window or use Edit > License Management > Transfer License to push them back to the local key store from the License Web Portal.
11. Re-launch TIA Portal V15 and open the original project. Verify that Add New Device no longer raises the license step 7 was not found error.

Verification

1. ALM service health. Open services.msc and confirm ALM_1.0_service is Running with Startup type: Automatic.
2. ALM self-test. Launch the new ALM. The first-line status must read ALM service is running (or the localized equivalent) — not corrupt ALM. The right-hand pane should list the local computer as Local Host — Online.
3. License activation. In the ALM, right-click a Not Used license and select Activate. Within 2-3 seconds the status must flip to Used. If the status does not change, the service is still using a stale keys.db — repeat Steps 4 and 8.
4. TIA Portal device-add test. Open a V15 project, open the Project Tree > Devices & Networks view, and click Add New Device. The dialog should populate the catalog without raising license step 7 was not found. Add an S7-1200 CPU placeholder to confirm the licensing path is clean.
5. Log review. Inspect C:\Program Files\Siemens\Automation License Manager\Log. The newest ALMlog.xml should not contain entries tagged Severity=Error after the device-add test.

Troubleshooting Matrix

Preventive Practices

• Pin the ALM build to the TIA version. Use the same ALM SP for every workstation in a fleet. Mixing ALM V6.0 SP1 on one machine and V6.0 SP3 on another is supported but is the most common cause of cross-corruption when licenses are transferred between machines.
• Update the ALM before transferring license keys. On a fresh TIA install, the first action after setup is to download the current ALM, install it, restart, and only then begin any license transfer. This avoids the torn-write condition that produces the corrupt ALM status.
• Schedule periodic license backups. Export the license list to *.csv monthly. Siemens provides the License Management > Export function. The export is not a substitute for a license retransfer but it gives an auditable record of the keys present on each engineering workstation.
• Disable antivirus real-time scan on the ALM folder. Add C:\Program Files\Siemens\Automation License Manager\ and the per-user AppData paths to the AV exclusion list. Real-time scanning of the keys.db during a write is a documented cause of schema corruption on Windows 7 and Windows 10.
• Avoid in-place major TIA upgrades. When moving from TIA V15 to V16, uninstall the previous TIA version and the ALM, perform the manual folder delete, then install the new TIA + bundled ALM. In-place major upgrades are not supported by Siemens for TIA Portal.

Compatibility with Later TIA Portal Versions

Automation License Manager V6.0 SP1 and later service packs maintain backward compatibility with TIA Portal V13 SP1 through V19. The same repair procedure applies when the corrupt ALM symptom appears on any of these versions. The official download entry — SIOS entry 114358 — is updated whenever a new ALM build ships; always validate the version banner in the ALM About dialog against the SIOS page before declaring the workstation clean.

Alternative Recovery Paths

When a workstation cannot be reconnected to the Siemens License Web Portal — for example, on an air-gapped machine — the recovery path differs slightly:

1. On a clean reference workstation, install ALM V6.0 SP1, transfer the licenses from the License Web Portal, then perform License Management > Export to File. This creates a *.wibuCmContainer archive.
2. Copy the archive to the air-gapped workstation via approved removable media.
3. After completing Steps 1-9 of the main recovery procedure on the air-gapped machine, open ALM and use License Management > Import from File to load the archive.
4. Verify activation in the ALM, then open TIA Portal V15 to confirm the license step 7 was not found error is resolved.

This is the standard Siemens procedure for license redistribution across isolated networks and is fully supported by SIOS entry 114358.

Why a Standard Reinstall Fails

Many engineers attempt a Modify/Repair or a fresh Install over existing cycle as a first resort. Both are inadequate for the corrupt ALM condition because:

• Windows Installer caches the original install state in C:\Windows\Installer and uses it to compute the Repair payload. A corrupted license database is treated as user data and is not rewritten.
• An over-install places the new binaries on top of the old ones but the ALM_1.0_service continues to hold the old keys.db file handle. The new service DLL may load the old file schema and immediately mark it corrupt.
• Only a full uninstall that removes the ALM service registration, plus a manual deletion of the install folder and per-user cache, gives the new install a clean slate.

This is the structural reason the original report's Repair attempt and the standard re-install both left the workstation in the license step 7 was not found state.

FAQ