WinCC Server Redundancy Failure: Resolving .PCK File Corruption

Problem Definition: WinCC Redundant Server Pair Not Failing Over

A redundant SIMATIC WinCC V7 server pair (one Master, one Standby) is failing to negotiate redundancy. Symptom signature: the redundant partner server (Server 2) reports no client connections in the WinCC Channel Diagnostics or in "Client connection status", the operator stations cannot subscribe to Server 2 after a forced failover, and the generated .PCK file inspected on Server 2 does not contain the redundancy configuration block. The user has correctly verified that the package files exist on both stations but the redundancy data segment is missing from the standby package.

This article applies to WinCC V7.0 through V7.5 SP2 running on Windows Server 2012 R2, 2016, 2019, or 2022 in a Microsoft Workgroup or Active Directory domain. The same root cause and recovery procedure also applies to WinCC Professional (TIA Portal) V16/V17/V18 when configured for PC-station redundancy, with minor differences in the package regeneration path called out where relevant.

Architecture of WinCC Server Redundancy (V7.x)

WinCC Redundancy is implemented as a software-level option that runs on top of two identical PC stations. Both stations must hold the same WinCC base license and at least one WinCC Redundancy (option package) license, typically identified as 6AV6371-1CF07-0AX0 in the SIMATIC License Manager for V7.x.

Master and Standby Roles

• Master (Server 1): Actively acquires process data from PLCs/field devices and serves WinCC clients. Maintains the write-authoritative archive and the alarm log.
• Standby (Server 2): Subscribes to the Master via TCP, mirrors the runtime database, and remains hot. On detection of Master loss (default heartbeat timeout 5 s, configurable up to 30 s) the Standby promotes itself and begins serving clients.

Data Paths

1. Process data: PLC → WinCC Channel (S7, OPC, Modbus, etc.) → Server 1 runtime DB.
2. Redundancy mirror: Server 1 → internal redundancy protocol (TCP port 4410 by default for partner sync) → Server 2 runtime DB.
3. Client subscription: WinCC Client → whichever server currently owns the Master role → process data.

Files That Matter

If the .DCF on Server 2 is older than the Master’s or was edited offline, the redundancy partner definition can be stripped, which causes the exact symptom observed: package generated but containing no redundancy data, client connection status empty.

Root Cause Analysis: Why the .PCK File Loses Redundancy Data

The redundancy block in the .PCK file is a derivative of the in-memory project state on the Master server at the moment Create Server Package is invoked. If any of the following preconditions are violated, the package is created successfully but is functionally incomplete.

Condition 1: Stale or Corrupt DCF on the Source Server

The .DCF holds a CRC-protected view of the redundancy configuration. When the Master’s .DCF is regenerated by a partial save or by an abrupt process exit, the redundancy partner section can be lost. The Explorer will still create a .PCK because the on-disk graph is valid; the redundancy metadata is reconstructed only at runtime activation. If the activation never completed on the partner, the partner reads a non-redundant package.

Condition 2: SIMATIC Shell Cannot Resolve the Partner

WinCC uses SIMATIC Shell for partner discovery. If the standby server name does not appear in SIMATIC Shell → My Computer → Microsoft Windows Network on the Master, the redundancy partner binding is silently downgraded to “undefined” during package creation. This is the most common cause of “redundancy data missing from PCK” in a brownfield plant where DNS or NetBIOS has been reconfigured.

Condition 3: WinCC Redundancy License Not Detected

If the WinCC/Redundancy license is missing, expired, or installed on the wrong license container (e.g. moved from a removed USB dongle to a new SLM 2 dongle), the redundancy engine refuses to write the redundancy segment into the package. The package is still produced but lacks the partner synchronization block.

Condition 4: Time Skew Between Servers

Redundancy negotiation uses time-stamped heartbeat frames. Windows time drift greater than 60 s between partners will cause one side to reject the partner. Configure both servers to the same NTP source; this is documented in the WinCC V7.5 system manual.

Condition 5: Firewall or Port Block

Windows Firewall or a network ACL blocking UDP 137/138 (NetBIOS name resolution), TCP 139/445 (SMB), or WinCC-specific ports will cause SIMATIC Shell to fail silently. See the port table in the diagnostic section below.

Diagnostic Procedure

Work through these checks in order. Stop and fix the first failure before moving to the next.

Step 1 — Verify SIMATIC Shell Visibility

1. On Server 1 (Master), open SIMATIC Shell from the desktop icon or Start → Siemens Automation → SIMATIC Shell.
2. Expand My Computer → Microsoft Windows Network → <Workgroup or Domain>.
3. Confirm that Server 2 is listed with its short NetBIOS name.
4. Repeat from Server 2 looking back at Server 1.

If either side does not see the other:

• Verify that Network Discovery and File and Printer Sharing are enabled on both servers (Control Panel → Network and Sharing Center → Change advanced sharing settings).
• Verify that the Computer Browser and Server services are Running and set to Automatic.
• Verify that no GPO is blocking inbound NetBIOS. On Windows Server 2019/2022, the legacy Computer Browser service is disabled by default; SIOS provides a documented workaround using Function Discovery Provider Host and Function Discovery Resource Publication services set to Automatic.

Step 2 — Validate the WinCC Redundancy License

1. Open Automation License Manager on each server.
2. Confirm WinCC/Redundancy appears as Valid.
3. If the license is detected on Master but not Standby, transfer it from the License Key USB or rehost it via the License Key function of Automation License Manager.

Step 3 — Inspect the .PCK File Contents

On the Master, regenerate the package with verbose logging:

1. WinCC Explorer → right-click Server Data → Create Server Package.
2. Note the timestamp on <ServerName>\Packages\<Project>_<DateTime>.pck.
3. Open WinCC Diagnostic Viewer (Start → Siemens Automation → HMI System Diagnostics) on Master and Standby.
4. Filter to category Redundancy. Look for events:

Step 4 — Compare DCF Files on Both Servers

Use a file-level comparison, not a content comparison; both files should have the same modification timestamp within a tolerance of the same project save event.

1. On Server 1: dir <ProjectPath>\<ProjectName>.dcf
2. On Server 2: same command.
3. If the Server 2 DCF is older by more than the last save cycle, it is stale and must be regenerated.

Step-by-Step Recovery Procedure

Execute these steps with both WinCC servers stopped. Begin by stopping all WinCC services: WinCC Explorer → File → Exit; if Runtime is active, use Stop Runtime from the system tray icon or via the command-line tool WinCC.exe /stop.

Step A — Delete the Stale DCF on Server 2

Per the official SIOS FAQ “How do you delete the DCF file of your WinCC project?” (entry referenced from the WinCC V7.5 system manual):

1. On Server 2, navigate to the WinCC project folder.
2. Locate <ProjectName>.DCF and any *.ldf log file.
3. Right-click the file, choose Properties, clear the Read-only attribute.
4. Delete <ProjectName>.DCF. Leave <ProjectName>.MDF untouched.
5. Confirm deletion by checking the folder.

Step B — Re-Copy Project and Redundancy Configuration to Server 2

1. On Server 1, open the WinCC project in the Explorer.
2. From the menu: Project → Duplicate Project → As Master, or use Project Duplicator with the “redundant server” profile.
3. Select the target path as Server 2’s project root, e.g. \\SERVER2\Siemens\Automation\WinCC\WinCCProjects\MyPlant.
4. Transfer the project. The DCF will be regenerated on Server 2 at first activation.

Step C — Configure the Redundancy Partner

On Server 1 (Master):

1. Right-click the project name → Properties → tab Redundancy.
2. Set Redundancy partner computer to the NetBIOS name of Server 2 (e.g. SERVER2).
3. Set Synchronization to Active.
4. Optionally adjust heartbeat (default 5 s) and timeout-to-failover (default 25 s).

Save the project. The DCF is rewritten with the partner binding. The redundancy engine registers a partner entry in RedundancyState.txt in the project directory.

Step D — Regenerate the Server Package

1. WinCC Explorer → Server Data → right-click → Create Server Package.
2. Confirm the package now contains the redundancy segment by checking the package size: a redundant package is typically 5–15% larger than a non-redundant one because of the partner sync tables.
3. Copy the new .PCK to Server 2’s Packages folder, overwriting the old one.

Step E — Activate Both Servers

1. On Server 2, open the project. WinCC regenerates <ProjectName>.DCF from the new .MDF.
2. On Server 2, click Activate from the WinCC Explorer toolbar.
3. Wait for Server 2 Runtime to enter Running state.
4. On Server 1, click Activate.
5. Verify that Server 1 logs a Redundancy partner found event within 10 s.

Port, Service, and Firewall Requirements

Create a Windows Firewall inbound rule on both servers to allow the WinCC executable C:\Program Files\Siemens\Automation\WinCC\bin\WinCC.exe and the redundancy engine CCReduncyAgent.exe (path varies by version). On Server 2019/2022, use the Windows Defender Firewall with Advanced Security MMC snap-in.

Verification and Stress Testing

After recovery, verify redundancy under controlled fault conditions before declaring the system healthy.

Test 1 — Passive Verification (No Fault)

1. On Server 1 Runtime, observe the status bar: Redundant operation: Active.
2. In the Redundancy tab of WinCC Channel Diagnostics, confirm both servers report each other as Online.
3. From a WinCC client, confirm that process data updates occur and that the active server indicator reflects Server 1.

Test 2 — Forced Master Failover

1. From Server 1, deactivate Runtime: WinCC Explorer → Stop Runtime.
2. Within timeout-to-failover seconds, verify that Server 2 promotes to Master.
3. Verify that the client reconnects transparently (current view should remain populated).
4. Verify that no archive gap exists in the Tag Logging archive; the redundancy engine back-fills any data the standby received while in standby.

Test 3 — Standby Restart

1. Reboot Server 2 from the OS while Server 1 is active.
2. On reboot, Server 2 should auto-rejoin as Standby within 60 s.
3. Confirm that the alarm log entries written during the outage are present in Server 2’s archive after resync.

Test 4 — Package Re-Distribution Check

Force a project change on Server 1 (add a dummy internal tag, save, recreate package) and verify that the next client login downloads the delta. This validates the .PCK regeneration chain.

Event Log and Diagnostic Traces

WinCC writes redundancy events to the Windows Application Event Log under source WinCC and to the local log files:

• <ProjectPath>\<ServerName>\Diagnostics\Redundancy.LOG
• <ProjectPath>\RedundancyState.txt
• C:\Siemens\Automation\DiagLog\WinCC_Service_<Timestamp>.txt

Enable verbose redundancy tracing via WinCC Explorer → Tools → Trace → Redundancy → Level 3. Capture at least 30 minutes of trace during a failover test. Disable trace when finished — level 3 logging consumes disk at roughly 50 MB/min on a busy plant network.

Preventive Maintenance and Best Practices

1. Synchronize time: Configure both servers to the same NTP source with a maximum 5 s drift tolerance. Use w32tm /query /status to verify.
2. Central license storage: Move all WinCC/Redundancy licenses to a redundant Automation License Manager server so a single dongle failure does not strand the partner.
3. Back up DCF daily: Include *.DCF in the project backup job. Although WinCC regenerates it, having a known-good snapshot reduces recovery time from hours to minutes.
4. Document partner binding: Maintain a controlled document listing server names, roles, package generation timestamps, and the engineer responsible. Drift between documentation and reality is a leading cause of late-night escalations.
5. Test failover quarterly: Schedule a planned forced failover every 90 days. Redundancy that is never tested fails when first needed.
6. Patch coordination: Apply Windows cumulative updates to both servers on the same maintenance window. Windows Server 2022 cumulative updates have caused temporary NetBIOS resolution failures; always reboot both servers together after patching.
7. Avoid project editing on the Standby: Only modify the project on the Master. The Standby should be read-only outside of maintenance windows.
8. Network segmentation: Place both redundant servers on the same VLAN/subnet. Cross-subnet redundancy works but adds DNS dependencies that frequently break during DHCP lease renewals.

WinCC Professional (TIA Portal) Notes

For TIA Portal WinCC Professional V16/V17/V18 redundancy configured as PC station with redundancy:

• The project is compiled and downloaded, not packaged as .PCK. The file analogous to the DCF is the *.ap16/*.ap17/*.ap18 project archive.
• Redundancy configuration lives under HMI device configuration → Redundancy editor. The partner name is the engineering station name, not the runtime computer name.
• For WinCC Professional, recovery is performed by re-downloading the project to the affected PC station rather than by editing files directly.
• Ensure that the TIA Portal project and the runtime PC station are at the same TIA version — mismatched firmware causes silent failure of the partner handshake.

Common Pitfalls and Field-Proven Caveats

• Antivirus quarantine of DCF: Several endpoint protection suites flag .DCF files as suspicious because they are binary integrity-protected blobs. Add an AV exclusion for C:\Siemens\Automation\.
• Project opened read-only on Standby: If the Standby is opened with WinCC Explorer in Open read-only mode, the DCF is not regenerated and the partner binding never materializes.
• Windows long path: Project paths longer than 260 characters without the long-path-aware manifest cause silent failures in package creation. Keep the project root under C:\Siemens\Automation\WinCC\WinCCProjects\.
• User rights on service account: The WinCC service account must be a local administrator on both servers and must own the project folder. Using SYSTEM as the service account breaks SIMATIC Shell discovery.
• DCF from WinCC V6 migrated to V7: Projects migrated from WinCC V6 carry a legacy DCF structure. Always run Project Migrator before opening a V6 DCF in V7.5 to avoid silent corruption of the redundancy block.

When to Escalate to Siemens Support

Open a service request with Siemens Industry Online Support if:

• All diagnostic steps above pass but the .PCK still lacks the redundancy segment after regeneration.
• The WinCC Diagnostic Viewer reports 0x80072EE7 or other DNS resolution errors that persist after ipconfig /flushdns on both servers.
• The license is reported valid by Automation License Manager but the redundancy engine logs 0x40004004.

Attach the WinCC_Service diagnostic log, the redundancy trace, and a screenshot of Server Data → Properties for both servers. SIOS typically responds within 24 business hours for production-down cases logged with severity High.