Resolving COMOS Remote License Service (RLS) and Dongle Errors on Terminal Server

The COMOS Remote License Service (RLS) is the centralized license daemon that serves floating COMOS licenses (dongle-based) to clients connecting through a terminal server / Remote Desktop Session Host. When the RLS refuses to hand a license to a Comos.exe process running on the same machine, engineers typically see one of the following signatures in the RLS window or in the Comos.log:

• LM_Error -2000 (undocumented numeric code emitted by the license manager).
• licence server will be ignored because local license file
• No license for module '...' available while the dongle is physically attached and the LED is on.
• ComosLicense*.xml artifact silently shadows the network server.

This reference walks through the field-proven diagnostic path, driver reinstallation, license-type validation (SERVER vs. LOCAL), and the interaction with Microsoft Remote Desktop Services (RDS) / Terminal Server CAL enforcement that frequently masks the real cause.

1. Environment and Affected Versions

The fault pattern has been reproduced on the following configuration envelope:

2. Root Cause Analysis of LM_Error -2000

The numeric LM_Error -2000 is not a documented public error code; it is an internal sentinel returned by the COMOS license manager (LMgr32) when one of the following pre-conditions is violated at session start-up:

1. No FneKey matching the dongle is reachable on USB / network.
2. A local ComosLicense*.xml overrides the network lookup, so the RLS is intentionally ignored.
3. The license type bound to the dongle is LOCAL and not SERVER, so it cannot be served by RLS / CLS.
4. The vendor driver (SafeNet HASP / WIBU CodeMeter) is missing, mismatched, or running under a session-0 service account that cannot see the USB stack forwarded to the user session.
5. USB redirection through RDP is blocked by group policy, so the dongle is invisible inside the terminal-server session even though it is visible to the local host.

The RLS does not crash; it logs the negative acknowledgement and falls back to the next candidate provider in the lookup order:

1. ComosLicense*.xml in %ComosInstall%\..\Config (always wins if present).
2. Local dongle via FneKey driver.
3. Remote License Service on the configured network host.
4. Comos License Server (CLS) for SERVER-type floating licenses.

Because step 1 silently pre-empts everything else, it is the single most common field cause of the failure.

3. Pre-Flight: Confirm the Dongle is Even Visible

Before touching the license server, prove the dongle is addressable from the terminal-server session. The fastest in-tool check is the bundled Dongle.exe utility that ships in the COMOS Bin directory.

1. Open an RDP session to the Terminal Server and log on with the same Windows account that will run Comos.exe.
2. Navigate to %ComosInstall%\Bin\Dongle.exe (default: C:\Program Files\Siemens\COMOS\10.5.0\Bin).
3. Launch Dongle.exe as Administrator. The window should display the Dongle ID (a 7- to 9-digit decimal) and the green Test button must return OK for every module listed.
4. If the ID field is blank and Test returns Failed, the vendor driver is the problem; jump to section 4.
5. If the ID is shown but Test still fails, suspect a license-type mismatch (SERVER vs. LOCAL); jump to section 5.

For terminal-server environments you can also verify visibility from the underlying host console (not the RDP session) by running Dongle.exe locally. If the dongle is visible on the host console but not from inside the RDP session, USB redirection is the culprit.

3.1 Verifying USB Redirection over RDP

USB dongles can reach the terminal-server session through one of two paths:

• Session-level redirection: mstsc.exe /admin does not support most redirection; use a normal RDP session and select Local Resources → More → Other supported RemoteFX USB device on the client.
• Device-level redirection: Use a Digitrust / Digi AnywhereUSB or a hardware network-USB bridge so the dongle is a network device, not a USB one.

Inside the session, validate with PowerShell:

If the SafeNet or WIBU device is not listed, USB redirection is disabled by Group Policy. The relevant policy is:

• Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection\Do not allow supported Plug and Play device redirection = Disabled
• Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection\Do not allow video capture redirection = Disabled

4. Driver Reinstallation: The Single Most Effective Fix

The vendor-supplied driver must match the dongle generation AND the COMOS version. A wrong driver returns no error in the RLS window beyond LM_Error -2000.

4.1 Identify the Dongle Generation

4.2 Clean Driver Reinstall (SafeNet)

1. Stop ComosRLS: net stop ComosRLS
2. Stop the SafeNet service: net stop "Sentinel HASP License Manager" (older) or net stop "Sentinel LDK License Manager" (newer).
3. Uninstall any pre-existing HASP / LDK run-time via Settings → Apps.
4. Delete residual hasplms.exe from %ProgramFiles%\SafeNet\ and %ProgramFiles%\Common Files\SafeNet Sentinel.
5. Reboot. Do not plug the dongle until prompted.
6. Download the matching Sentinel HASP HL Run-time installer from the SafeNet / Thales release portal matching your dongle generation.
7. Run the installer as Administrator. Plug the dongle when prompted.
8. Reboot, log on to the terminal server, and re-run Dongle.exe (see section 3).

4.3 Clean Driver Reinstall (WIBU-Systems CodeMeter)

1. Stop ComosRLS: net stop ComosRLS
2. Stop the CodeMeter service: net stop CodeMeter
3. Uninstall the existing CodeMeter Runtime through Settings → Apps.
4. Delete residual keys: reg delete "HKLM\SOFTWARE\WIBU-SYSTEMS" /f reg delete "HKLM\SOFTWARE\WOW6432Node\WIBU-SYSTEMS" /f
5. Reboot.
6. Download the matching CodeMeter Runtime from the WIBU-Systems website (use 7.10+ for COMOS 10.2-10.3, 7.50+ for COMOS 10.4-10.5).
7. Run the installer. Plug the dongle.
8. Verify visibility with the CodeMeter WebAdmin tool at https://localhost:22350 — the dongle should appear in the container list with a non-empty license entry.
9. Re-run Dongle.exe to confirm the test passes.

5. License Type Validation: SERVER vs. LOCAL

Every COMOS dongle is electronically stamped with a license type at provisioning time. The two relevant types are:

• LOCAL — License is bound to the workstation on which the dongle is physically attached. RLS / CLS will not serve it.
• SERVER — Floating license served by the Comos License Server (CLS) or the older Remote License Service (RLS) to any authorized client.

You can read the type directly from the dongle via:

1. Open the Siemens License Management Tool installed alongside COMOS (Start → Siemens → License Management).
2. Select the dongle in the left pane. The Type column shows SERVER or LOCAL.
3. For SafeNet HASP dongles, an alternative is the haspinfo CLI: "C:\Program Files\SafeNet\HASP HL\haspinfo.exe" -i — the line Type: SERVER confirms a network-servable license.

If the type is LOCAL and the dongle is attached to the terminal server, only the terminal-server session can use the license. RLS will refuse the request and the client gets LM_Error -2000. In that case, swap the dongle for a SERVER-type license, or move the LOCAL dongle to the user's workstation and run COMOS from a client install that points back to the terminal server for everything except the license.

6. The Hidden ComosLicense*.xml Override

COMOS searches the Config directory of the install tree for any file matching the wildcard ComosLicense*.xml. If such a file exists, the license resolver uses it as the authoritative source and never consults the RLS / CLS. This behavior is by design (it allows licensing to be frozen for offline or test environments) but it has caused most of the field tickets described in this article.

6.1 Locate the File

1. Open an elevated command prompt.
2. Run: dir /s /b "C:\Program Files\Siemens\COMOS\*ComosLicense*.xml"
3. Typical locations to check:
   • %ComosInstall%\Config
   • %ProgramData%\Siemens\Automation\COMOS\Config
   • %APPDATA%\Siemens\COMOS\Config (per-user)

6.2 Disable the Override

To re-enable RLS / CLS lookup, rename or move the offending file:

Then restart ComosRLS:

Re-launch Comos.exe and confirm that the RLS window now shows a successful license grant instead of licence server will be ignored because local license file.

7. Remote Desktop Services / Terminal Server Licensing Interaction

A frequent confusion in the field is between two completely independent license systems that both run on a terminal server:

1. Microsoft RDS CALs — issued by the Remote Desktop Services license server. Without valid Per User or Per Device CALs, the RDS Session Host will issue a 120-day temporary license and then refuse new sessions.
2. COMOS application license — the dongle- or CLS-served COMOS seat. RLS / CLS are the only COMOS-side components that grant this.

The two are independent: an RDS CAL does not grant a COMOS seat, and a valid COMOS dongle does not unlock RDS session quota. If the terminal server is in its temporary-license grace period and the COMOS dongle is also in a fault state, both errors can appear simultaneously and obscure each other. Always validate RDS licensing first.

7.1 Verify the RDS License Server

1. Open the Remote Desktop Licensing Manager (licmgr.exe) on the license server.
2. Confirm the server is Activated. If it is Not Activated, the wizard will refuse to issue CALs. Activate against the Microsoft Clearinghouse as described in the Microsoft activation guide.
3. Confirm the Session Host is pointing at this license server: gpresult /r | findstr "LicenseServer" or check the RD Licensing tab in tsconfig.msc.
4. Verify the CAL pack: Per Device CALs are best for shift-work terminal servers; Per User CALs for named-engineer access. Per Microsoft's terminal-server licensing reference, each client needs at least two licenses: a Windows NT Workstation license (in modern terms: a Windows client license) and an RDS CAL.

7.2 Common RDS Pitfalls That Mimic COMOS Errors

• Server 2022 CAL downgrade — Server 2022 RDS does not accept Server 2008 CALs. Re-issue CALs of the matching generation.
• Stale grace period — If the license server has been unreachable for > 120 days, sessions are rejected with a generic "out of memory" or "cannot load profile" error, which is easy to misread as a COMOS issue.
• Workgroup vs. domain — A workgroup license server cannot be discovered by the Session Host; configure the registry value LicenseServer under HKLM\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers explicitly.

8. Step-by-Step Resolution Procedure

Execute the following sequence on the terminal server. Each step has a measurable pass/fail criterion so you can stop the moment the failure is isolated.

1. Validate RDS licensing using the steps in 7.1. Stop if the license server is not activated — fix that first.
2. Search for stray ComosLicense*.xml per section 6. Rename any matches.
3. Stop RLS: net stop ComosRLS.
4. Reinstall the dongle driver per section 4 (match dongle generation to driver major version).
5. Reboot the terminal server (this re-enumerates the USB stack under session 0).
6. Run Dongle.exe as Administrator in the RDP session. ID must populate, Test must return OK on every module.
7. Confirm license type per section 5. If LOCAL, you cannot serve it; obtain a SERVER-type license.
8. Start RLS: net start ComosRLS. Watch the window for a clean start sequence (no LM_Error -2000).
9. Launch Comos.exe and connect to the database. The error dialog from step 1 of the symptom list should no longer appear.
10. Inspect the client.dat file on the local drive. It should be updated with the current workstation name and session ID; if it has not changed, the RLS is still being bypassed.

9. Verification Checklist

10. Troubleshooting Matrix

11. Field-Proven Hardening

Once the failure is resolved, harden the terminal server so the issue cannot reappear after the next patch cycle.

1. Lock down the Config directory: deny the local Users group write permission on %ComosInstall%\Config so deployment scripts cannot silently drop a ComosLicense*.xml there.
2. Pin the driver version in a GPO-managed device installation restriction rule so Windows Update cannot replace the SafeNet / CodeMeter runtime with an older revision.
3. Centralize the dongle behind a network-USB bridge. This removes the dependency on per-session USB redirection and survives Windows feature updates.
4. Monitor the RLS log with a scheduled task that grep's for will be ignored and LM_Error -2000 and emails the operations mailbox. Detection within minutes beats detection during the next engineering shift.
5. Document the license type (LOCAL vs. SERVER) in your asset register. A dongle swap without a license-type update is the single most common repeat-fault after a refresh.

12. When to Open a Siemens Support Ticket

If the matrix above is exhausted and the failure persists, escalate to Siemens Industry Online Support. The official ticket-creation procedure is documented in Siemens Support Entry 109474501. Include in the ticket:

• COMOS version and service pack.
• Dongle generation (HASP HL, HASP SRM, CodeMeter) and ID.
• Driver version installed (full version string, e.g. Sentinel HASP HL Run-time 6.93.2.0).
• RLS log file (%ProgramData%\Siemens\COMOS\Logs\RLS.log) for the failed session.
• Output of Dongle.exe showing the test result.
• Result of the dir /s /b search for ComosLicense*.xml.
• Screenshot of the License Management Tool showing the license type.
• Remote Desktop Licensing Manager screenshot confirming activation status.

Submitting all of the above in a single ticket reduces the mean time to resolution from days to hours, because the support engineer can rule out driver, license-type, and RDS issues without further round-trips.

FAQ