Resolving WinCC V6.0 SP3a Multi-Client Package Update Failures

Overview

SIMATIC WinCC V6.0 SP3a Multi-Client stations rely on synchronised server data packages to render process pictures, tag values, and alarm logs from one or more WinCC servers. When a server project is edited, redeployed, or migrated, the matching packages on the Multi-Client must be regenerated; otherwise the client displays stale graphics, broken tag references, or refuses to open the project at runtime. The most common failure mode in this configuration is the diagnostic message Update only partially completed - see diagnostics files raised during the manual or implicit package update, accompanied by an apparently empty or merely connection-state-only entry in CCEClient_sys_xx.log.

This reference walks through the WinCC V6.0 SP3a Multi-Client update path, isolates the conditions that cause the partial-update failure, and provides step-by-step remediation procedures, including the PCS 7 V6.1 SP1 Assign OS Server function, stale *.pck file removal, SQL Server cleanup of orphaned server-name entries, and runtime prerequisites that are frequently missed in brownfield migrations.

WinCC V6.0 SP3a Multi-Client Architecture

WinCC V6.0 distinguishes two fundamentally different client types. Understanding which type is installed is the first diagnostic step because each uses a different package-distribution mechanism.

Because the Multi-Client holds its own project, it must continuously reconcile its *.pck files with the server packages. The Uni-Client, by contrast, opens the server's project directly via SIMATIC Shell and never stores a package locally; this eliminates the partial-update failure mode entirely but introduces a single point of failure on the server.

Package Update Mechanism in V6.0 SP3a

Server data packages are generated on the WinCC server when the project is compiled, then transferred to the Multi-Client during either:

1. Implicit update - performed automatically on client start-up when the corresponding checkboxes in the client's server-data configuration are enabled. This is the standard runtime behaviour in V6.0 SP3a.
2. Explicit (manual) update - initiated from WinCC Explorer on the client by right-clicking the server entry and selecting Update Server Data.

The implicit update depends on three conditions being true simultaneously:

• The server is reachable via TCP/IP (typically OTN / LAN) and visible in Windows Explorer and SIMATIC Shell.
• The WinCC server project is in Runtime; the WinCC.exe process must be active on the server. A server that is only configured but not running will reject the package-transfer request and produce the partial-update diagnostic.
• The server name referenced inside the client's WinCC project matches the actual computer name of the server. Mismatches are common after server renames, hardware swaps, or VM cloning operations.

Problem Description: "Update Only Partially Completed"

The reported failure presents as follows on the Multi-Client station:

1. Operator or engineer opens WinCC Explorer on the client and selects Update Server Data.
2. The progress dialog completes but a yellow-triangle message appears: Update only partially completed - please refer to the diagnostics files.
3. The engineer inspects CCEClient_sys_xx.log in the project's \<Project>\<Servername>\Diagnostics folder and finds only entries of the form:
   <Servername> Disconnected
<Servername> Connected
   No error code, no SQL state, no WinCC return value is recorded.
4. The implicit auto-update on subsequent restarts of the client also fails silently - the local *.pck files retain their stale timestamp.

The Information column visible in WinCC Explorer under Server Data is supposed to display the package build number, last successful transfer time, and the OS-assignment status of the corresponding server. When this column is empty or shows a name that does not match the current server computer name, the package update cannot be reconciled and falls back to a partial write.

Diagnostic File Locations

If CCEClient_sys_xx.log only shows Disconnected / Connected lines around the timestamp of the failed update, the package-transfer layer never received a coherent request. This is the diagnostic signature that points to OS-assignment, server-runtime, or server-name-mismatch root causes rather than a corrupt *.pck file.

Root Cause Analysis

Four root causes account for the overwhelming majority of V6.0 SP3a Multi-Client partial-update failures encountered in the field. Each is documented below with its specific signature and remediation.

Cause 1 - Server Is Not In Runtime

WinCC server data packages can only be exported while the server project's WinCC.exe process is active. When the server is closed in runtime but remains configured in SIMATIC Manager / WinCC Explorer, the client's implicit update silently fails because the share-and-locking semantics of the server's \<Project>\<Servername>\Packages folder require an active session.

Cause 2 - OS Server Not Assigned (PCS 7 Only)

Inside PCS 7 V6.1 SP1, the WinCC OS server must be assigned to the AS station via SIMATIC Manager -> WinCC OS -> Assign OS Server.... If this menu item has never been invoked or was reset after a project rename, the WinCC project on the OS lacks the logical binding that ties it to the AS project, and the package synchronisation falls into a degraded state. This was the explicit root cause in the originating V6.0 SP3a case.

Cause 3 - Stale *.pck Files After Server Rename

When a WinCC server is renamed (or its project is renamed and reconfigured), the package folder \<Projectname>\<Servername>\Packages accumulates orphaned *.pck files that retain the old server-name signature. WinCC V6.0 SP3a's package-merge logic does not always reconcile these entries cleanly, especially when SQL Server contains matching stale rows in the project database. The result is a partial merge: only the new server's *.pck is written, but the old one is not deleted, and the client receives a partial-update message.

Cause 4 - SQL Server Orphaned Entries

The WinCC project database on the server (and the local SQL Server Express instance used by V6.x clients) holds rows keyed by server name. After a rename, rows referencing the obsolete name persist and cause referential-integrity conflicts during the package merge. Removing only the *.pck files without cleaning the database leaves the merge in an inconsistent state.

Solution A - Verify Server Runtime and Assign OS Server (PCS 7)

Use this procedure first; it resolves the majority of V6.0 SP3a Multi-Client partial-update failures without any file-level intervention.

1. On the WinCC server, open WinCC Explorer and confirm WinCC.exe is running. If the project is closed, start Runtime and wait for the green status indicator.
2. On the engineering station, open SIMATIC Manager and load the PCS 7 project.
3. Select the WinCC OS station in the component view.
4. Open the menu Options -> WinCC OS -> Assign OS Server.... (In some localisations this is rendered as OS->Assign OS Server... or WinCC OS -> Assign Server....)
5. In the dialog, verify that the computer name listed in the Server column exactly matches the Windows computer name of the server (case-insensitive but otherwise exact).
6. Click OK to commit the assignment. SIMATIC Manager will recompile the OS project; allow several minutes for the operation to complete.
7. On the Multi-Client, restart WinCC Explorer and confirm that the Information column under Server Data now displays a valid build number and timestamp.
8. Trigger an explicit Update Server Data. The progress dialog should now complete without the partial-update message.

Solution B - Remove Stale *.pck Files

Use this procedure when the server was renamed, or when Solution A does not clear the partial-update warning.

1. Stop WinCC Runtime on the Multi-Client.
2. Close WinCC Explorer on the client.
3. Navigate to \\<Servername>\<Projectname>\<Servername>\Packages over the network share.
4. List all *.pck files. There should be exactly one *.pck per server computer name. Any file whose embedded server name does not match the current server computer name is stale.
5. Move stale *.pck files to a backup folder (do not delete immediately - keep them until the next successful update has been confirmed).
6. On the client, open \<ClientProject>\<Servername>\Packages and perform the same audit; remove any stale local copies.
7. Restart WinCC Explorer on the client and trigger Update Server Data.

Solution C - SQL Server Cleanup of Orphaned Server-Name Entries

When stale *.pck files have been removed but the partial-update message persists, the WinCC project database on the SQL Server still holds rows keyed by the obsolete server name.

1. Identify the SQL Server instance hosting the WinCC project. On a default V6.0 SP3a install this is WINCC (Windows-authenticated) and the database matches the WinCC project name.
2. Open SQL Server Management Studio (or the Express edition tool) and connect with Windows authentication.
3. Expand Databases -> <WinCCProjectName> -> Tables.
4. Run the following diagnostic query to identify stale entries:
   SELECT * FROM dbo.MCPictureFolder WHERE ServerName NOT IN (SELECT ComputerName FROM dbo.MCComputername)
   (Adjust the table names to match the V6.0 schema; in PCS 7 the typical tables are MCConfig, MCConnections, and MCParam.)
5. For each row referencing the obsolete server name, document the row contents to a backup SQL script, then delete the rows.
6. Re-run the explicit Update Server Data on the client. The package should now regenerate cleanly.

Solution D - Rebuild Client Project From Scratch

When Solution A through C are insufficient - typically after a major server rename, hardware swap, or partial PCS 7 migration - the most reliable remediation is to rebuild the client project.

1. Document the server-data configuration: server names, package types, alarm-routing settings, user-administration mappings.
2. Use the WinCC Configuration Tool to create a fresh Multi-Client project with the desired name on the client machine.
3. Add each server under Server Data, referencing the corrected server computer names.
4. Trigger the initial Update Server Data. The package baseline is now internally consistent.
5. Re-apply any client-specific graphics, scripts, and global libraries.

This procedure typically takes 30 to 60 minutes per client and is the recommended path when multiple root causes are stacked (rename + OS reassignment + stale database rows).

Verification

After applying any of the above solutions, validate the fix with the following checks:

1. Explicit update: Right-click the server in the client's WinCC Explorer and select Update Server Data. The progress dialog must close without the partial-update warning.
2. Log inspection: CCEClient_sys_xx.log must contain a Package transfer successful entry at the timestamp of the most recent update. A Disconnected / Connected pair without further entries indicates the transfer was not even attempted.
3. File timestamp: The local *.pck file under \<ClientProject>\<Servername>\Packages must reflect the most recent server-side compile time.
4. Information column: In WinCC Explorer on the client, the Information column for the affected server must show a valid build number, server name, and last-update timestamp.
5. Runtime: Open a process picture and confirm that tags from the affected server resolve correctly. Force a tag write to confirm write-back authorisation is intact.

Related WinCC V6.x Upgrade and Migration Notes

The V6.0 SP3a release sits at a junction in the WinCC V6.x lifecycle. Operators maintaining this platform should be aware of the following:

• Free-of-charge updates from WinCC V6.x to SP3 are documented in Siemens Support entry 21288784 for the Connectivity Pack; the same update-channel mechanism applies to the WinCC base system.
• Projects originated on V6.0 SP3a can be migrated forward to V6.2 SP3 and subsequently to V8.1 using the migration path described in Siemens Support migration guide (PDF). The migration tool inspects the project for V6.0 SP3a-specific structures and rewrites them to the target version's schema.
• Upgrades to V7.x or V8.x should be performed on a copy of the project before the production environment is touched; the package distribution and SQL schema differ materially between V6.x and V7.x.

Troubleshooting Matrix

Safety and Operational Considerations

All package-update operations on a WinCC Multi-Client must be performed during a planned maintenance window. Although WinCC V6.0 SP3a allows online updates, an interrupted package transfer can leave the client in a state where it cannot reconnect to the server until WinCC Explorer is restarted on the client. In PCS 7 environments where the Multi-Client drives an operator HMI, schedule the operation so that the operator panel is in Logged out state.