Resolving Simatic Logon 1.6 Remote Access Service Failure

1. Problem Overview

When deploying Siemens SIMATIC Logon V1.6 as the central user administration for a Comfort-panel fleet (TP1200 Comfort, TP1500 Comfort, TP1900 Comfort, TP2200 Comfort), the typical symptom is a panel that refuses to authenticate domain users even though the matching Active Directory (AD) groups exist and the operator accounts are valid. The login dialog appears, the operator enters DOMAIN\username and a correct password, and the panel reports that it cannot read user/group data from the domain.

The root cause is almost always that the Windows service SIMATIC Logon Remote Access (display name) / SLRemoteAccess (service name) on the Logon server has failed to start. Because every Comfort HMI communicates with the Logon server through this service, a stopped service means the panel cannot query role memberships, cannot validate credentials, and falls back to the local HMI user administration (which is empty in a pure-central deployment).

2. Affected Components and Versions

For the official installation manual refer to the SIMATIC Logon V1.6 System Manual and the SIMATIC Logon V1.6 SP1 Update release notes.

3. Architecture: How SIMATIC Logon Talks to the Panel

SIMATIC Logon is a client/server application. The Logon server hosts a Windows service that exposes an OPC-DA-based or, since V1.6 SP1, an OPC-UA-based interface. Each HMI runtime on the Comfort panel starts a small SIMATIC Logon client component that opens a TCP connection to the server and pulls the user/role catalog.

Default ports used by SIMATIC Logon (configurable in the Logon Server Configuration tool):

4. Root Cause Analysis

The five most frequent reasons SLRemoteAccess will not start are documented in Siemens KB entry 109769926 and the consolidated Logon FAQ 89852222:

1. Dependency service is disabled. SLRemoteAccess depends on the SIMATIC Logon Service (display name) / SLogonSrv, the DCOM Server Process Launcher (DcomLaunch), and the RPC Endpoint Mapper (RpcSs). On a Windows Server Core image or on a host where the RPCSS service was disabled manually, SLRemoteAccess will fail with "The dependency service does not exist or has been marked for deletion" (Win32 error 1075).
2. Corrupt or missing SQL Server LocalDB instance. SIMATIC Logon V1.6 stores its user/group mirror in a SQL Server 2012 Express LocalDB instance (SIMATICLogon). If LocalDB has been uninstalled or the user profile under which the service runs cannot access %LOCALAPPDATA%, the service fails with a .NET exception recorded under Event ID 1026 (.NET Runtime).
3. Service Log On account has insufficient rights. By default, the installer sets the service to run as LOCAL SYSTEM. After an MSI repair or a domain migration, the account may have been switched to a managed service account that does not hold Log on as a service, Replace a process-level token, and Adjust memory quotas for a process.
4. DCOM launch and activation permissions broken. Logon uses DCOM to expose its interface to remote HMI clients. After a Group Policy push that hardens DCOM defaults, the Logon Application DCOM CLSID cannot be activated remotely, which appears as a service start failure during dependency resolution.
5. Antivirus / EDR quarantine of the Logon binaries. McAfee, Trend Micro, CrowdStrike, and Windows Defender have all been observed to quarantine SLRemoteAccess.exe or SLRemoteCfg.exe in %ProgramFiles%\Siemens\Automation\SIMATIC Logon\bin after a signature push.

5. Pre-Flight Checklist

Run the following diagnostics on the Logon server before changing anything:

1. Confirm domain membership: systeminfo | findstr /i "domain" should report the full DNS domain (e.g., CONTOSO.LOCAL).
2. Verify DNS resolution of the Logon server: nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain> must return at least one DC.
3. Open Event Viewer → Windows Logs > System and locate the most recent Service Control Manager event with source Service Control Manager and Event IDs 7000, 7011, 7013, or 7024. Capture the binary data of the event.
4. From the same log, search for source DCOM with Event ID 10010 (unmarshalling failures) and source SideBySide with Event ID 33 (manifest mismatch).
5. Open Event Viewer → Applications and Services Logs > SIMATIC Logon (only present if at least one Logon component has been launched). Look for entries tagged ERROR and FATAL.
6. Confirm the binaries exist and are not quarantined: dir "%ProgramFiles%\Siemens\Automation\SIMATIC Logon\bin\SLRemoteAccess.exe" and dir "%ProgramFiles%\Siemens\Automation\SIMATIC Logon\bin\SLogonSrv.exe".

6. Step-by-Step Resolution

6.1 Restore missing dependencies

1. Open regedit as Administrator and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SLRemoteAccess.
2. Inspect the DependOnService multi-string value. The canonical content is:

   DependOnService = RPCSS
   DependOnService = DcomLaunch
   DependOnService = SLogonSrv

3. If the value is empty or contains NetMan / NlaSvc only (legacy from an old WinCC flexible install), restore the three entries above.
4. Restart the server (services.msc dependency reload does not always re-evaluate COM components).

6.2 Repair LocalDB

1. Open an elevated command prompt and list LocalDB instances: sqllocaldb info. Expected: SIMATICLogon.
2. If missing, recreate it: sqllocaldb create "SIMATICLogon" 12.0 -s.
3. If present but in error state: sqllocaldb stop "SIMATICLogon" & sqllocaldb delete "SIMATICLogon" & sqllocaldb create "SIMATICLogon" 12.0 -s.
4. Validate connectivity with the SqlLocalDB CLI: sqlcmd -S "(localdb)\SIMATICLogon" -E -Q "SELECT name FROM sys.databases". The expected databases are SIMATICLogon and (after first migration) SIMATICLogon_Audit.

6.3 Reset the Service Log On account

1. In services.msc, open SIMATIC Logon Remote Access → Log On tab.
2. Select Local System account and tick Allow service to interact with desktop only if the operator is going to launch the Logon Configuration tool locally on the server.
3. For a managed service account, open secpol.msc → Local Policies > User Rights Assignment and add the account to Log on as a service, Replace a process-level token, and Adjust memory quotas for a process. Run gpupdate /force.
4. Clear the password fields (leave blank for LocalSystem) and click Apply. Restart the service.

6.4 Re-register DCOM components

1. Open an elevated cmd and execute:

   cd /d "%ProgramFiles%\Siemens\Automation\SIMATIC Logon\bin"
   regsvr32 /u SLogonCom.dll
   regsvr32 SLogonCom.dll
   SLRemoteAccess.exe /regserver

2. Open dcomcnfg → Component Services > Computers > My Computer > DCOM Config. Locate SIMATIC Logon Remote Access. Right-click → Properties > Security. Confirm the configured launch and access permissions include the local SYSTEM, Administrators, and (if used) the HMI service accounts.

6.5 Whitelist the Logon binaries in your EDR

1. Add the following paths to the AV exclusion list (replace with the actual install path if changed):

   %ProgramFiles%\Siemens\Automation\SIMATIC Logon\bin\
   %ProgramData%\Siemens\Automation\SIMATIC Logon\
   %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances\SIMATICLogon\

2. Restore any quarantined files. In Windows Defender, use Protection history > Allowed threats.
3. Reboot to confirm the service starts cleanly.

7. Mapping AD Groups to HMI Roles

Once the service runs, the group-mapping procedure referenced in the original report must be completed. There are two valid approaches; choose exactly one to avoid duplicate role assignments.

7.1 Approach A: Group names identical on both sides (recommended)

1. On the AD DC, create a global security group per HMI role. Example: G_HMI_Operators, G_HMI_Maintenance, G_HMI_Administrators.
2. Add the corresponding Windows user accounts as members of the group.
3. In WinCC Comfort (TIA Portal), open Runtime settings > User administration > SIMATIC Logon and add a connection to the Logon server.
4. Create local groups under User administration > Groups that match the AD group names byte-for-byte (the Logon server does a case-insensitive match, but always keep the same casing as the sAMAccountName).
5. Assign the appropriate authorizations (area pointers, screen call rights, tags, scripts) to each local group.

7.2 Approach B: Explicit LDAP mapping (mismatched names)

1. On the Logon server, open SIMATIC Logon Configuration.
2. Switch to LDAP mapping and enable Resolve Windows groups via LDAP.
3. Enter the BaseDN (DC=contoso,DC=local) and the BindDN with read-only credentials. Use a service account, never a personal account.
4. For each HMI group, click Add mapping and paste the full LDAP distinguishedName of the AD group.
5. Test the mapping with the Test connection button; a successful test returns the group's member count within ~2 seconds.

8. TIA Portal Configuration on the Engineering Station

1. In the TP1200 project tree, select Runtime settings > User administration.
2. Set User administration mode to SIMATIC Logon.
3. Under SIMATIC Logon > Connection, enter the Logon server address (FQDN preferred, e.g., logonsrv.contoso.local) and the port (default 4900, encrypted 4901).
4. Enable Encrypted connection and import the server certificate. SIMATIC Logon ships a self-signed certificate; replace it with a CA-issued cert in production. See the Logon System Manual section 6.4 for the cert export procedure.
5. Compile and download the project. After the first successful login, the panel will cache the role list locally for 24 hours. To force a refresh, open the panel's Service Menu (with finger swipe from bottom-right) and select Logon > Refresh cache.

9. Verification Procedure

1. On the Logon server, open services.msc. SIMATIC Logon Remote Access must show Status: Running, Startup Type: Automatic (Delayed Start).
2. From the TP1200, press the Log On button on the login dialog. The role dropdown should populate within 1-3 seconds.
3. Sign in with a domain user. The Last login field in the dialog should show the operator's full AD display name.
4. On the Logon server, run eventvwr.msc and look under Application > SIMATIC Logon. A successful login produces an INFORMATION entry with the username and the assigned role.
5. From a remote workstation, telnet to port 4900 of the Logon server: Test-NetConnection -ComputerName logonsrv -Port 4900 in PowerShell should return TcpTestSucceeded : True.
6. Generate a high-frequency login/logout storm (50 cycles in 60 s) using the operator station. Memory consumption of SLRemoteAccess.exe must stabilize below ~250 MB; if it climbs, the LocalDB instance is leaking connections and should be restarted (see KB 109779360).

10. Common Pitfalls and Edge Cases

11. Fault-Code Quick Reference

12. Field-Validated Checklist Before Calling Siemens Support

1. SLRemoteAccess.exe and SLogonSrv.exe exist and are not quarantined.
2. Service startup type = Automatic (Delayed Start); status = Running.
3. Dependencies RPCSS, DcomLaunch, SLogonSrv are all set to Automatic and running.
4. LocalDB instance SIMATICLogon exists and is Running.
5. DCOM AppID SIMATIC Logon Remote Access has SYSTEM listed in launch and access.
6. Ports 4900/4901 are reachable from the HMI subnet.
7. AD groups exist with identical sAMAccountName to the WinCC groups.
8. Time skew between Logon server and DC < 5 minutes.

If all eight items are green and the panel still fails to authenticate, collect the SIMATIC Logon diagnostic bundle (Logon Server Configuration → Help > Create support information) and open a ticket at the Siemens Industry Online Support portal referencing KB 109769926 and your Logon version (right-click SLRemoteCfg.exe → About).