Resolving WinCC Project Duplicator Failures on Redundant Partner

Problem Overview

The Siemens WinCC Project Duplicator is the documented tool for mirroring a running WinCC runtime project from a master server onto its redundant partner server. In production environments running WinCC V7.0 SP2 Update 10, WinCC V7.4, or WinCC V8.0 with the classic redundancy option, the Duplicator frequently fails to complete the copy operation on a healthy redundant partner that already holds a previous project copy. The error presents as a generic "Error duplicating" dialog after several minutes of operation. The partial copy leaves the standby server in an unusable state: the WinCC project cannot be started because key files are missing, and the start routine demands that a migration be run first.

Field reports describe a 5 GB project that transfers roughly 700 MB before the Duplicator aborts. The same project copies correctly when the target folder on the redundant partner is fully deleted beforehand, but the redundancy manual states that an in-place update of the existing project copy is the expected behavior of the Duplicator. The combination of partial file copy + forced migration prompt + no meaningful log output is the typical symptom set that this article addresses.

Affected Versions and Components

How the WinCC Project Duplicator Is Supposed to Work

The Duplicator is invoked on the source server and copies the active runtime project to a target path on a remote computer. For redundant configurations, the source is the preferred/master server and the target is the redundant partner. The tool is documented in the WinCC Information System under Working with WinCC → Duplicating Projects and is summarized in Siemens Support entry 109824649 for WinCC V8.0.

Pre-flight checks the Duplicator performs:

1. Source project is closed on the target computer.
2. WinCC Runtime is deactivated on the target computer.
3. Target folder exists and is writable for the user running the Duplicator.
4. Target computer runs the same WinCC major version as the source.
5. Free disk space on the target ≥ size of the source project.
6. The Duplicating user has administrative rights on both machines.

If all checks pass, the tool sequentially copies the GraCS\, Library\, PRT\, Scripts\, Textbib\, WSP\, PAS\, DB\, and Redundancy\ subfolders together with the project database file (typically <Project>.mdf and <Project>_log.ldf). The redundant partner subsequently restarts Runtime and re-establishes the standby role.

Documented Failure Modes

Root Cause Analysis

Four root cause families cover almost every reported Project Duplicator failure in a redundant plant:

1. Network Share and SMB Permissions

The Duplicator does not always use the explicit administrative share; it can fall back to a UNC path that inherits the share ACL. If the calling user lacks Modify rights on inherited subfolders, the copy silently skips files, drops the connection mid-stream, and aborts with no log line beyond the dialog caption. Field evidence: a 5 GB copy aborts at 700 MB, which corresponds to the size of the uncompressed GraCS\ graphics cache — the exact boundary at which Windows enumerates the next subfolder and re-evaluates inherited ACLs.

2. Locked or Read-Only Files on the Standby

If the standby server still has the WinCC project open in the WinCC Explorer, or if the SQL Server holding the runtime database has not released its file handle, the Duplicator cannot overwrite the database files. The error is reported as a generic failure. The Reset_WinCC.vbs script (shipped in <Install>\WinCC\bin) is designed to clean up these states, but it does not always unlock MDF/LDF files if SQL Server Express is stuck.

3. Version Drift Between Source and Target

The Duplicator refuses to copy a project onto a target whose installed WinCC major/minor build is older. A V8.0 source cannot be placed onto a V7.4 SP1 target. The error symptom is identical to a permission failure. Conversely, copying a V7.x project onto a V6.x build forces the user into the V6 Migrator, which is incompatible with V7/V8 source data.

4. Redundancy-Specific State on the Standby

Files in the Redundancy\ subfolder, the ArchiveManager\ folder, and the Project.ldf transaction log are written to frequently while the standby is hot. If the Duplicator reads these files during a write burst, the copy truncates mid-file, leaving a half-written archive segment that crashes the standby at next start.

Pre-Flight Verification Checklist

Before opening the Duplicator, perform and document the following checks. The redundancy manual lists the first six; items 7–11 are field-validated additions that resolve the most common hidden causes.

1. Confirm Windows user is identical (same account name and password) on master and standby, and is a member of SIMATIC HMI and local Administrators.
2. Confirm UNC path: \\<Standby>\<WinCCProjectShare>$\ or \\<Standby>\<Folder>\ is reachable and writable.
3. Confirm free disk space on the standby ≥ 1.5 × project size (factor covers logs and swap).
4. Confirm WinCC Runtime is stopped on the standby: Start → Programs → SIMATIC → WinCC → WinCC Explorer → File → Exit WinCC, then close the WinCC Explorer window.
5. Confirm the WinCC service CCAgent and SQLSERVER ($WINCC) are running on the standby.
6. Confirm the source and target WinCC builds are identical (Help → About on both machines).
7. Open services.msc on the standby and stop SIMATIC WinCC ArchiveManager, SIMATIC WinCC Runtime, and SIMATIC WinCC AlarmManager to release file locks before invoking the Duplicator.
8. Clear read-only attributes recursively on the existing project folder: attrib -r "\\<Standby>\<Path>\*.*" /S /D.
9. Run Reset_WinCC.vbs on the standby as Administrator. This removes pending CCAgent tasks and temp files under %TEMP%\WinCC\.
10. Verify that the SQL Server instance on the standby is SQLEXPRESS for WinCC V7 or WINCC for WinCC V8 and that the database is detached: sqlcmd -S .\WINCC -Q "sp_detach_db '<ProjectDBName>'".
11. Disable antivirus real-time scanning on the project folder on both servers for the duration of the duplicate operation (Symantec, McAfee, Windows Defender Controlled folder access are common culprits).

Step-by-Step Resolution

Step 1 — Stop and Unlock Both Servers

1. On the standby: exit WinCC Runtime, exit WinCC Explorer.
2. Run services.msc and stop SIMATIC WinCC Runtime, SIMATIC WinCC ArchiveManager, and SQL Server (WINCC) (or SQLEXPRESS for V7).
3. Run Reset_WinCC.vbs as Administrator.
4. Restart only SQL Server (WINCC); leave the WinCC services stopped.

Step 2 — Clean the Target Folder

1. Rename the existing project folder: ren "C:\Projects\PlantA" "PlantA_backup_%date%".
2. Create a fresh target folder: mkdir "C:\Projects\PlantA".
3. Grant the Duplicator user Full Control on the new folder and propagate to subfolders (do not rely on inheritance from a parent share that may carry an old ACL).

Step 3 — Run the Project Duplicator

1. On the master server, start Start → Programs → SIMATIC → WinCC → Tools → Project Duplicator.
2. Select the source project from the list.
3. Enter the target computer and the freshly created target path.
4. Click Duplicate and monitor the progress dialog. The transfer should now complete without truncation.

Step 4 — Restore Standby Services

1. On the standby, start SIMATIC WinCC Runtime and SIMATIC WinCC ArchiveManager from services.msc or by double-clicking the WinCC project.
2. Verify in the WinCC Explorer status bar that the standby shows "Redundancy OK" and that the master is reported as the preferred server.

Handling the "Use Migrator First" Error

If the standby WinCC project start reports that a migration is required, you have crossed two valid WinCC versions (for example copied a V7.4 SP1 project onto a V7.0 base install) or you copied a V8.0 project onto a V7.x target. The fix is structural, not procedural:

1. Match WinCC major versions: V7.0 SP2 ↔ V7.0 SP2, V7.4 ↔ V7.4, V7.5 ↔ V7.5, V8.0 ↔ V8.0.
2. If you must move between versions, install the matching WinCC DVD on the target first, then run the appropriate version-specific Migrator from Start → Programs → SIMATIC → WinCC → Tools → Project Migrator.
3. The V6-era Migrator error "only for versions 6.xx" is a hard-coded message. Launch the correct V7 or V8 Migrator; do not run Siemens Automation → SIMATIC → WinCC → WinCC V6 Migrator.

Engineering Station Alternative

When the Project Duplicator is unstable in a given plant, the documented fallback is to use an Engineering Station (ES) with the WinCC Configuration Studio to download the project to both servers. The ES is connected to the redundant pair via the WinCC configuration channel. This workflow is supported in V7.0 SP2 and later and is more reliable on plants larger than 2 GB because it transfers the configuration database directly rather than enumerating 50,000+ files over SMB.

1. Connect the ES to the master server's project via the WinCC project tree.
2. Right-click the project → Download to Target System → select the master.
3. Repeat for the standby (redundant partner).
4. Restart Runtime on the standby in standby mode.

The ES workflow requires the WinCC option WinCC Configuration licensed on the ES and a working TCP connection on port 1433 (default SQL Server) plus the WinCC remote service ports.

WinCC RT Professional — Online Upgrade Path

For plants on TIA Portal with WinCC RT Professional, the upgrade behavior is fundamentally different. According to the Siemens TIA Portal V20 documentation for upgrading redundant plants during operation, the master and standby are upgraded independently, in sequence, and each server is rebooted individually while the other carries the runtime load. The Project Duplicator is not part of this workflow; instead, TIA Portal performs a project consistency check, recompiles the runtime, and pushes the new binaries to each target.

Plants experiencing repeated Project Duplicator failures on classic WinCC V7/V8 should evaluate a migration to RT Professional if the V20 release is supported by the rest of the control system; the online-upgrade flow eliminates the offline file-copy failure mode entirely.

Log File Locations for Diagnosis

When the Duplicator dialog offers no detail, the following log paths surface the underlying exception:

To enable verbose Duplicator logging, set the registry value HKLM\SOFTWARE\Siemens\WinCC\Duplicator\DebugLevel = 1 (DWORD) on the source server, restart the Duplicator, and inspect dup_log.txt for the last successfully copied file path. The file listed after the last entry is the file that triggered the abort.

Verification

After any Project Duplicator procedure, verify redundancy health with the following checks:

1. On the standby, open the WinCC Explorer and confirm the red/green redundancy icon in the status bar reads green.
2. Open WinCC Explorer → Tools → Redundancy Control and confirm the partner is reachable on the configured TCP port (default 5000).
3. Force a manual failover: Redundancy → Switch to Partner. The partner should take over within 2–4 seconds; the original master should return as standby.
4. Verify the archive sequence: Start → Programs → SIMATIC → WinCC → Tools → Archive Configuration — switch the archive back-up path and confirm the standby is writing the same time range as the master.
5. Check tag logging parity: stop Runtime on the master, confirm that all tags on the standby have current values within one cycle of the configured acquisition time.

Preventive Maintenance

• Maintain a documented redundancy mirror procedure that always begins with stopping the standby services and detaching the SQL database.
• Schedule Duplicator runs during plant pauses where archive write rate is < 10 KB/s.
• Exclude the WinCC project folder from real-time antivirus scanning on both servers.
• Keep both servers patched to the same WinCC Update level; Siemens releases cumulative fixes in Updates (e.g., Update 10 for V7.0 SP2 contained a Duplicator fix for ACL inheritance on long paths).
• For plants larger than 5 GB, evaluate the ES download workflow or migrate to RT Professional to avoid the file-copy path entirely.

Troubleshooting Matrix