WinCC Server-Client Version Compatibility and Migration Guide

WinCC Server-Client Version Compatibility and Migration Guide

Siemens WinCC (Windows Control Center) is the SCADA/HMI runtime and configuration platform behind thousands of plant-floor visualization systems. In distributed installations, one PC acts as the WinCC Server while additional PCs attach as Clients to the same project. A recurring commissioning question is whether a mixed environment — older WinCC clients attached to a newer WinCC server, or vice versa — can stay online without project corruption, alarm loss, or tag-mismatch faults. This reference consolidates the rules, the parallel-installation restrictions introduced by TIA Portal, and the supported migration paths so that plant engineers can avoid the most common support-ticket pitfalls.

1. WinCC Distributed System Architecture Overview

A WinCC distributed system separates visualization, archiving, and alarm routing onto separate physical or virtual machines. The standard roles are:

• WinCC Server: Owns the project database, archive segments, alarm logging, and tag subscription. Runs the CCServer process.
• WinCC Client: Reads tags, alarms, and trends from the server. Runs the CCClient process with the multi-user project mode.
• WinCC Web Navigator Server: Publishes the visualization as HTML5/WebUX for thin clients.
• WinCC Standby Server / Redundancy Partner: Optional failover node synchronized through CCEServer.

The terminal bus connects clients to the server using TCP port 4900 (CCServer) and additional ports for archive replication. All nodes must be members of the same Windows workgroup or Active Directory domain; otherwise, the symbol resolution and the SIMATIC WinCC Explorer login fail with WCCOA: 0x80070005 (Access Denied).

2. WinCC Version Compatibility Matrix Requirements

WinCC server-client communication uses a project file (*.mcp) plus internal binary structures for tag lists, alarm classes, archive layouts, and graphic pictures. These structures change between major versions and occasionally between Service Packs. The compatibility matrix below summarizes the supported combinations as documented in the WinCC Installation & Configuration manuals and the TIA Portal parallel-installation notes.

3. Operating System Compatibility Across Network Nodes

While WinCC versions must match, the underlying Windows operating systems on server and clients can differ, provided each node meets its own minimum OS requirement:

A common field configuration is WinCC Server on Windows Server 2019 and WinCC Clients on Windows 10 IoT Enterprise LTSC 2021. This is supported as long as WinCC major version, Service Pack, and Update level match. Mixing Windows 7 clients with Windows Server 2022 is allowed for WinCC V7.5 SP2 because the server requirements are met; what is not allowed is mixing WinCC V7.0 (running on Windows 7) with WinCC V7.5 (running on Server 2022) in the same server-client project.

4. The V7.x Version Caveat: Avoiding Misidentification

A persistent question in support tickets is the existence of a "WinCC V7.1". Siemens never released a WinCC V7.1 in the V7 major line — the sequence is V7.0 → V7.0 SP1/SP2/SP3 → V7.2 → V7.3 → V7.4 → V7.4 SP1 → V7.5 → V7.5 SP1/SP2. When a user reports a "V7.1 server" the cause is one of:

1. Typo for V7.0 SP1: The installer reports WinCC V7.0 + SP1 in SIMATIC WinCC Explorer > Help > About; engineers commonly shorten this to "V7.1".
2. Typo for V7.2: Some engineers mis-type V7.2 as V7.1.
3. WinCC flexible 2008 SP1: A completely different product line for Comfort/Compact panels, occasionally confused with the WinCC V7 SCADA line.
4. WinCC (TIA Portal) V13 SP1: The TIA Portal engineering framework version, which is unrelated to the WinCC V7 SCADA runtime.

Before any compatibility work, confirm the version by opening WinCC Explorer > Help > About and reading the exact Version:, Service Pack:, and Update: fields. Do not rely on screen-captures or installer filenames such as WinCC_V75_SP2_Upd7.exe alone.

5. Parallel Installation Restrictions and TIA Portal Constraints

Siemens uses the term parallel installation to describe running two or more WinCC versions on the same PC. This is used for migration staging, where a new version is installed alongside the production version before the cutover. Parallel installation has strict rules:

• TIA Portal V21 parallel-install note: Parallel installation of WinCC V21 Comfort/Advanced with any WinCC version earlier than V7.3 is not permitted. See the official installation guide: TIA Portal V21 - Parallel Installation.
• Two SCADA-style WinCC versions (V7.x) of the same major version may be installed in parallel only if both are at the latest available update level on the same PC.
• WinCC V6.x and V7.x cannot be parallel-installed on the same PC because they share the same ODBC data sources and the same CCArchive service registration.
• WinCC (TIA Portal) Comfort/Advanced/Professional can be installed alongside WinCC V7.3 and newer (with restrictions per TIA Portal version).

6. Service Pack, Update, and Hotfix Alignment Rules

Even when the major version matches, mismatched Service Packs cause failure modes that are difficult to diagnose:

The recommended discipline: roll out hotfixes in batches, starting from the server, then the standby, then clients. Allow 10 minutes between each tier to verify alarm routing stability before the next tier.

7. Server-Client Configuration Procedure

Use this procedure to bring a homogeneous WinCC server-client network online. It assumes WinCC V7.5 SP2 Update 7 on Windows Server 2019 (server) and Windows 10 LTSC 2021 (clients).

7.1 Prerequisites

• Identical WinCC installation media (DVD or SIMATIC Automation License Manager).
• Each node joined to the same AD domain or workgroup with matching local user accounts if workgroup is used.
• Network firewall allows TCP 4900 (CCServer), UDP 4900, TCP 4901 (redundancy), and TCP 1433 (SQL archive) inbound to the server.
• WinCC project copied locally on each client; do not run from a UNC path.
• Time synchronization within 5 seconds across all nodes (W32Time or third-party).

7.2 Step-by-Step Configuration

1. Install WinCC Server. Run Setup.exe from the WinCC V7.5 SP2 DVD. Select WinCC Server install type. During installation, enter the server's hostname (PLANT-WCCS01) in the Computer Name dialog. Reboot when prompted.
2. Configure the project. Open WinCC Explorer on the server. Create or open the project (for example, TankFarm.mcp). Add all tags, alarms, archives, and graphics.
3. Activate the project. Right-click the project root > Activate. Confirm that the CCServer service is in Started state via Services.
4. Install WinCC Client. On each client PC, run the same installer and select WinCC Client install type. Enter the server's hostname PLANT-WCCS01 in the Computer Name dialog. Reboot.
5. Copy the project to the client. Use WinCC Explorer > Server Data > Configure or simply copy the project folder TankFarm.mcp via robocopy to C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\.
6. Set the client project mode. Open the copied project locally, then in Project Properties > Computer, set the property Server to PLANT-WCCS01 and select Multi-User as the startup mode.
7. Open the client. Launch WinCC Runtime. The client should authenticate against the server. If credentials are required, use the dedicated WinCC user (winccuser), not a domain admin.

7.3 Verification

1. On the server, open WinCC Tag Management; confirm tag SystemTag_ConnectedClients reads the expected number of clients (e.g., 10 for 10 PCs).
2. On each client, force a tag write (e.g., toggle HMI_Tag_TestBit) and confirm the value appears in the server's archive within 2 seconds.
3. Trigger a test alarm from the server. Confirm every client displays the alarm row within 1 second.
4. On the server, run netstat -an | findstr :4900 and confirm one ESTABLISHED socket per client.

8. Web Navigator and WebUX as Cross-Version Alternatives

When upgrading the entire WinCC client fleet is operationally infeasible, Siemens offers two web-based alternatives that decouple the visualization from the WinCC desktop client:

8.1 WinCC Web Navigator (V7.x)

The WinCC Web Navigator server publishes the runtime as a browser-delivered visualization. Client PCs only need a browser; no local WinCC install. The Web Navigator Server must match the WinCC Server version exactly. Supported browsers include Microsoft Edge (Chromium) and Firefox ESR for current versions.

8.2 WinCC WebUX (V7.4 SP1 onward)

WebUX uses HTML5 and SVG natively, no ActiveX, no plug-in. WebUX is licensed per 6AV6371-1HX07-5CX0 tags. The advantage for mixed-version estates is that legacy WinCC clients can continue operating against the V7.x server while new operators use WebUX on modern Windows 11 PCs.

9. Migration Path: Upgrading Mixed-Version Networks

When a plant has mixed WinCC versions, the standard migration path is a phased cutover:

1. Survey and inventory. Run WinCCVersionTool.exe /report (bundled with V7.4+) across all PCs and export to CSV. Identify nodes that are below the target version.
2. Build a parallel-installation test bed. On one client PC, install the target version in parallel to validate the existing project opens without conversion errors. Save a copy of the original *.mcp before conversion.
3. Convert the project. On the server, open the project with the target WinCC. Accept the conversion prompt. Review the conversion log (ConvertLog.txt) for warnings about deprecated tags or C-script API changes.
4. Update C-scripts and VB-scripts. Some legacy HMIRuntime calls changed in V7.3 and again in V7.5. Recompile and test.
5. Upgrade standby server first. Confirm redundancy failover works before touching clients.
6. Upgrade clients in batches. 3–4 clients per shift to limit operator impact.
7. Decommission old version. After 30 days of stable operation, uninstall the previous WinCC version from each PC.

10. Domain Controller, Permissions, and Network Security

The most common cause of "works in test, fails in production" in mixed environments is permission inconsistency. The Windows-level ACLs and share permissions for the project directory must be identical across server and clients.

Recommended setup:

• Create a dedicated WinCC domain group PLANT\G_WinCC_Operators and add all operator accounts.
• On the server, share WinCCProjects$ as a hidden administrative share accessible only to PLANT\G_WinCC_Admins.
• Each client has a local copy of the project under C:\Siemens\WinCCProjects\; no runtime UNC access.
• Disable SMBv1 on all nodes; SMBv1 is required by WinCC V6.x but causes intermittent failures on Windows Server 2019 if accidentally left enabled.
• Enable Windows Firewall rules WinCC Server (4900) and WinCC Archive (1433) only on domain profiles.

11. Verification and Troubleshooting Matrix

Use the following matrix when commissioning or troubleshooting a WinCC server-client network.

12. Best Practices Checklist

• Maintain a single source of truth for the WinCC project in source control (SVN or Git LFS for binaries).
• Document the exact WinCC build string on every node in a CMDB.
• Use a gold image (e.g., WDS capture) for new client deployments to guarantee version consistency.
• Schedule hotfix rollouts for the same maintenance window across server, standby, and clients.
• Subscribe to Siemens ProductCERT security advisories for WinCC; many advisories apply only to specific Service Pack levels.

Frequently Asked Questions