WinCC V7 Client Alarm Logging: Fix No Connection to Data Server

Problem Definition

A WinCC V7 (classic) configuration running a multi-user SCADA project reports functional process pictures and tag connections on remote client stations, but every WinCC AlarmControl, WinCC OnlineTableControl (used for archive/protection lists), and WinCC EventControl instance on the client returns the runtime error "No connection to the data server". On the same client, the Computer properties > Startup > Alarm Logging Runtime checkbox in WinCC Explorer is greyed out and cannot be toggled.

This symptom is specific to projects that load from a WinCC server using the standard WinCC server-client topology (1 server, ≥1 client). The same project opened locally on the server displays all alarm, event, and protection messages correctly. The fault is therefore not a tag, message class, or color configuration issue; it is a service / connectivity fault between the client workstation and the server-side Alarm Logging Runtime plus its underlying SQL archive.

WinCC V7 Alarm Logging Architecture

Alarm Logging in WinCC V7 is a stand-alone subsystem running in parallel to Graphics Runtime and Tag Logging. At runtime, every configured message is written to a Microsoft SQL Server database belonging to the WinCC instance. The relationship is:

The Alarm Logging Runtime database uses a dedicated, project-specific SQL Server instance called <ServerName>\WINCC by default. On a WinCC client, Alarm Logging Runtime can be started in three legal modes configured in WinCC Explorer > Computer properties > Startup:

1. No Alarm Logging Runtime – alarm list disabled on this machine.
2. Alarm Logging Runtime (local) – client owns an independent archive (requires local SQL instance and a local project).
3. Alarm Logging Runtime from server – client reads messages and the archive from the configured WinCC server.

Mode 3 is the correct selection for a server-client project where the client must display messages originating on the server. If the checkbox is greyed out, WinCC Explorer is preventing the user from selecting it because one or more prerequisites are not satisfied.

Root Causes of "No Connection to Data Server"

The error text "No connection to the data server" is generated by the WinCC Alarm Control OCX when its data provider cannot bind to a live Alarm Logging Runtime. The binding can fail for four reasons, listed in order of frequency observed in the field:

1. Alarm Logging Runtime is disabled or set to local mode on the client – the control has no runtime to subscribe to. Manifests as a greyed-out checkbox in WinCC Explorer when the loaded project on the client was not authored or imported as a multi-user client project.
2. WinCC client license missing – Alarm Logging is a chargeable runtime option. Without a valid WinCC RT Client or WinCC RT Server license the runtime refuses to activate, including the Alarm Logging Runtime, and WinCC Explorer greys the checkbox to reflect the unavailable option.
3. SQL Server (WINCC instance) on the server is unreachable from the client – either the SQL service is stopped, the WinCC Firewall is blocking inbound connections, or name resolution / route to the server is broken.
4. DCOM / Windows security – the WinCC client user account does not have access to the server's COM objects or shared Alarm Logging memory. Less common with WinCC V7 SP3+ where DCOM is largely replaced by .NET remoting, but still relevant on legacy SP0/SP1 installations.

License Requirements on the Client

Alarm Logging Runtime requires an explicit license key on the station where it executes. For a multi-user client the relevant license tag stored in the SQL configuration database is the AlarmLoggingRT license, granted by the WinCC RT Client (16, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768 or unlimited Power Tags) or by the WinCC RT Server license on the server-side. The license is enforced via the Automation License Manager (almsrv.exe).

To inspect the currently bound license, open Automation License Manager > WinCC V7.x > Runtime on the client. If AlarmLoggingRT shows "Missing" or is dimmed, the Alarm Logging Runtime cannot start and the startup checkbox is greyed out by design.

SQL Server and Network Configuration

The Alarm Logging Runtime talks to SQL Server using TCP/IP on port 1433 by default, or on the dynamically assigned SQL Browser port 1434 when a named instance is used. WinCC V7 uses a fixed instance named WINCC; therefore clients must reach the server over UDP 1434 and TCP 1433 (or the configured static port).

Verify SQL reachability from the client

1. Open a command prompt on the client and run telnet <ServerName> 1433. A blank screen means TCP 1433 is reachable.
2. Open SQL Server Configuration Manager on the server (or via remote MMC) and confirm SQL Server (WINCC) and SQL Server Browser services are running and set to Automatic.
3. Confirm the WINCC instance is listening on TCP by reviewing Protocols for WINCC > TCP/IP > Properties > IP Addresses > IPAll > TCP Port. Forcing it to 1433 instead of dynamic simplifies firewall rules.
4. Open UDP 1434 and TCP 1433 inbound on the server's Windows Firewall profile used by the plant network.

WinCC V7 SP3 and later install a dedicated WinCC Firewall service that auto-creates rules for ports 1433, 1434, and the internal WinCC ports. If this service has been disabled, manual rules are required.

WinCC Project Type and Computer Properties

The greyed-out Alarm Logging Runtime checkbox is almost always a project-type symptom. A WinCC client receives the project either:

• As a multi-user client project – created on the server and pushed via Server data > Configure. This is the only project type that exposes the Alarm Logging Runtime from server option on the client.
• As a stand-alone client project – copied manually. The client then sees Alarm Logging as a local option only and the server-mode entry is unavailable.

To verify, open WinCC Explorer on the client and inspect the project path. If the .MCP file path is a redirected network share (\\<Server>\<ProjectPath>) the project is running in remote-server mode. If it is C:\<...>, it is a stand-alone project, and Alarm Logging from server is intentionally disabled.

Step-by-Step Resolution Procedure

Prerequisites

• Local administrator on both server and client.
• WinCC V7 project file (.MCP) and the matching server-side project archive (.zip) used for Load Online Changes.
• Automation License Manager with valid WinCC RT Client + AlarmLoggingRT licenses.
• Server name resolution: ping <WinCCServer> must resolve from the client.

Procedure

1. Stop WinCC Runtime on both server and clients. Close WinCC Explorer.
2. Verify licenses. On the client, open Automation License Manager. Confirm WinCC RT Client is present and not expired, and that the AlarmLoggingRT sub-license is checked. If either is missing, transfer the license from the license pool or USB stick and re-check.
3. Verify project type. On the server, open the project in WinCC Explorer and select Server data > Configure. Confirm the affected client is listed and its Computer type is set to WinCC Client with the desired startup parameters. Re-save the configuration and ensure the client picks up the latest project during the next boot.
4. Enable Alarm Logging Runtime from server on the client. On the client, open WinCC Explorer, right-click Computer, choose Properties > Startup. Under Alarm Logging Runtime select Activated. If the radio button is still greyed out, the project file loaded on the client is not the multi-user client project – re-install from the server package.
5. Restart WinCC Runtime on the server first, wait for Alarm Logging Runtime is running status in WinCC Explorer, then start the client.
6. Open a WinCC picture containing an AlarmControl. Confirm the message list populates and no "No connection to the data server" dialog appears.
7. Activate a test message by triggering a configured tag change. Verify the message timestamp, status, and acknowledgment update on both server and client.

Verification

• In WinCC Explorer on the client, the bottom status bar shows green traffic-light indicators next to Graphics Runtime, Tag Logging Runtime, and Alarm Logging Runtime.
• In the server's Windows Event Viewer > Application, the WinCC service writes Event 4900 / 4901 on Alarm Logging start/stop with the connected client list.
• Run WinCC Project Duplicator > Status on the client; the Alarm Logging status must read Connected to Server.

OPC A&E Server Considerations

Where WinCC alarm data is forwarded to a third-party SCADA, OPC, or historian (for example Ignition 8.1 consuming S7-1500 alarms, or an MES aggregating multiple WinCC servers), the WinCC OPC A&E Server is a separate component. The OPC A&E Server uses Condition Related Events by default; each configured WinCC alarm is sent to OPC A&E clients as a Condition Related Event that carries the additional Alarm attribute.

Reference: OPC A&E types of event (RT Professional) – WinCC.

When integrating WinCC V7 with non-Siemens historians such as Ignition, the typical data path is:

1. WinCC Alarm Logging Runtime writes to SQL Server (WINCC instance).
2. OPC A&E Server or OPC DA Server exposes the runtime data via DCOM.
3. Third-party client connects using OPC DA (tag values) or OPC A&E (alarm events).

If step 3 fails with "No connection to the data server" on a non-WinCC client, the root cause is almost always DCOM permissions, not the Alarm Logging Runtime. Treat this as a separate troubleshooting path.

Troubleshooting Matrix

Operational Best Practices

• Always store the canonical WinCC project on the server. Distribute via WinCC Load Online Changes or the Project Duplicator; never copy .MCP files manually to clients.
• Lock the SQL Browser and SQL Server (WINCC) services to Automatic (Delayed Start) to avoid race conditions on multi-reboot events.
• Document license keys in the Automation License Manager and replicate them off-server. A missing client license is the single most common reason Alarm Logging fails to activate on a remote station.
• When commissioning a new client, perform the Alarm Logging smoke test: trigger one message, acknowledge it, and confirm the acknowledgment propagates back to the server archive.
• Avoid dynamic SQL ports. Pin the WINCC instance to TCP 1433 to keep firewall rules static.

Field-Proven Diagnostic Commands