Fixing PCS 7 WinCC OS Second Complete Download Failure

Problem Statement

A Siemens PCS 7 operator station (OS) configured as a single station with a paired engineering station (ES/OS) accepts the first complete project download without issue, and WinCC Runtime activates correctly. The fault appears only when the engineer attempts a second complete project download: after WinCC Runtime is deactivated on the target OS, the "Download to Target System → Entire WinCC project" action returns a generic "an error occurred during download" message with no specific error code or sub-error. The Compile and Download dialog shows an empty log file. Subsequent attempts to open WinCC Explorer on the OS produce "configured server not available," and the OS remains in a corrupted project state. The only recovery path that engineers reach for is to delete the entire OS project folder on the target disk, which destroys the runtime archive (alarm history, trend logging, audit trail) and is unacceptable on a commissioning plant.

This article documents the root cause, the diagnostic procedure, and a resolution sequence that preserves the runtime archive while restoring the second-download capability on a single-station PCS 7 OS.

Affected Configurations and Symptoms

The fault is reproducible on the following PCS 7 layouts:

Configuration	Engineering station	Operator station	Topology
ES/OS + OS	WinCC Application (local)	WinCC Application Reference (remote)	Single station pair
Multi-OS plant with replacement OS	ES	New PC with new MAC	Most common trigger
Cloned OS image deployed to multiple stations	ES	Cloned image with same Windows name	Stale NetBIOS entries
Re-named OS station	ES	PC station renamed in Windows but not in WinCC project	Source/target identity drift

The failure has a consistent signature across all reported cases:

Stage	Symptom	Detail
Deactivation	WinCC Runtime Manager shows red state	Runtime stops cleanly
Direct download	"An error occurred during download"	No error code returned
Compile and Download	Same generic error, log file empty	Cannot pinpoint failure
Open WinCC Explorer	"Configured server not available"	Cannot start WinCC
Activate Runtime	Cannot activate, project unusable	Blocked
Re-attempt with deleted OS folder	First download works, runtime activates	Logging destroyed
Second re-attempt	Same generic error	Cycle repeats

The empty Compile and Download log is the most confusing aspect of the fault: there is no actionable diagnostic data. This is because the failure happens on the target OS, not in the engineering download dialog. The engineering station believes the download was issued; the target OS rejected the request before the engineering dialog could capture a useful event.

Network Topology

The relevant network is the PCS 7 plant bus. For a single-station PCS 7 deployment:

The key project fields that must match between the ES/OS project, the OS project, and the live Windows installation are summarized below.

Project field	Engineering source value	Target expected value	Verified at
WinCC computer name	ES-OS-1	OS-2 (matches Windows)	WinCC Explorer → Computer
PC station name	ES-OS-1	OS-2	SIMATIC Manager → PC Station
MAC address of CP1613	00:0E:8C:xx:xx:01	00:0E:8C:xx:xx:02	Station Configuration Editor → IE General
TCP/IP address	192.168.0.10	192.168.0.20	Station Configuration Editor
S7 subnet	Industrial Ethernet	Industrial Ethernet	NetPro
Project path	D:\PCS7\OS_Ref	D:\PCS7\OS_Project	WinCC Explorer → Computer → Properties
Subnet mask	255.255.255.0	255.255.255.0	Station Configuration Editor

Root Cause Analysis

The PCS 7 OS download mechanism is not a simple file copy. It performs a network-side validation against a token set the first time the OS is brought into the project tree. On the first download, no local reference exists on the target OS, so the download coordinator accepts any source station that resolves by Microsoft name service (NetBIOS) or by MAC address. As soon as the OS folder is created on the target disk, the local project state is frozen: subsequent downloads must match the previously recorded combination of source PC name, target PC name, and network identifiers, and the OS download service on the target performs the verification before unlocking the download dialog.

The verification state is held in two locations on the OS: the .xdb files inside the project folder, and the local SIMATIC Shell / WinCC station database. The engineering-side verification state is held in NetPro and in the S7 project database. Both sides must agree.

In practice four conditions cause the second download to fail silently:

1. PC name mismatch

Windows computer name was changed (often for cloning, or because the engineer station was renamed during plant reconfiguration). The new name was not propagated into the WinCC Explorer "Computer" property of the project, and the target project on the OS now sees an unknown source. The download coordinator on the OS compares the source PC name sent by the engineering station against the in-project value and rejects the connection.

Common triggers:

• Cloning a golden image to multiple OS stations without using sysprep to randomize the computer name.
• Renaming a replacement OS to match the failed OS without re-seeding the project with the new name.
• Renaming the engineering station for a project re-org and not updating NetPro.

2. MAC address drift

The CP1613 (or any Industrial Ethernet interface) was replaced. The new MAC differs from the value stored in the S7Net parameter files and the PC Station configuration. Standard onboard NICs cannot easily be reflashed from PCS 7, but the CP1613 can be reflashed via the Siemens CP1613 diagnostic tool. The OS download coordinator will reject the second download because the MAC presented by the live NIC does not match the in-project MAC. On a multi-OS plant where a spare PC station was deployed, the new MAC must be flashed to match the value the engineering project already holds for that station.

3. Insufficient share and folder rights

The D: drive of the target OS is not shared as D (data) and the project folder is not shared. The engineering user cannot write the project state files. The PCS 7 Security Concept states the ES user needs to be a member of Power User, SIMATIC HMI, and SIMATIC HMI CS groups on the server. On a hardened image with UAC enabled, the engineer account must temporarily be added to the local Administrators group to push the second complete download. The same applies for any client that needs a full WinCC project push.

The minimum share configuration on the target OS is:

• D shared as D$ (administrative) or D (engineer-visible) with read/write for the ES user.
• The project folder shared with full control for the ES user.
• The S7TraceServiceSrv and CCAlgTaskManager services running under an account with write access to the project folder.

4. PC name rewrite at end of OS download

The download function rewrites the "PC Name" at the conclusion of a download to the real destination name. After the first download, the on-disk OS project now contains the OS-2 computer name; a second download from the ES-OS-1 engineering station will not match the in-project value unless the engineer explicitly opens NetPro and re-asserts the source PC name. This is a documented behavior of the SIMATIC Manager download coordinator and is not a project bug.

For comparison, the S7-1200 / S7-1500 family behaves differently. When you trigger a download in RUN mode on those controllers, the TIA Portal applies its own consistency checks against the online / offline identity; the failure mode is described in the S7-1200 Failsafe manual collection – Downloading in RUN mode. The principle is the same: a "second pass" requires the controller's online identity to still match the offline project; once the online identity is captured, subsequent RUN-mode transfers enforce it.

Download State Machine

The OS download follows a strict state machine. The "second pass" is rejected at the verification gate:

The empty Compile and Download log is a direct consequence of this state machine: the engineering station never sees the rejection event because the target OS silently drops the request.

Diagnostic Procedure

Execute the following checklist before deleting the OS folder. The objective is to identify which of the four root-cause conditions is in play.

Step 1 – Verify Windows computer name

On the OS:

Start → Settings → System → About → Device name

On the ES/OS engineering station, open the WinCC project and compare against the value configured in:

WinCC Explorer → Computer → Properties → Computer name

On the OS, repeat the same comparison in the deployed copy of the project.

The strings must match byte for byte, including case. If they differ, write the Windows name into the WinCC Explorer "Computer name" property on both ES/OS and OS sides, recompile OS, and retry the complete download. A common pitfall is trailing spaces in the computer name string, which are easy to miss in the WinCC dialog and impossible to detect by eye.

Step 2 – Verify MAC address

On the OS, run:

ipconfig /all

Note the physical address of the Industrial Ethernet adapter used for S7 communication. Open SIMATIC Manager → PC Station → Configuration, expand the IE General slot, and compare. For CP1613 the value is normally hard-coded into the SIMATIC PC station configuration; if the CP1613 hardware was replaced, the MAC must be reflashed using the CP1613 diagnostic tool before the second download.

For standard onboard NICs the MAC cannot be reflashed from within PCS 7. In that case the project MAC must be updated to match the new hardware:

• Open SIMATIC Manager → PC Station on the engineering station.
• Open the IE General slot.
• Edit the MAC to match the new NIC.
• Save and compile NetPro.
• Re-attempt the complete download.

Step 3 – Verify shares and user rights

The OS D: drive must be shared as D and the project folder must be shared. From the ES/OS, in a Run dialog:

\\OS-2\D$
\\OS-2\<project_folder>

Both should be reachable. If not, set the share on the OS:

Computer Management → Shared Folders → Shares → New Share

Add the ES user account to the local Administrators group on the OS as a temporary measure, log off and back on, retry the complete download, and remove the account from Administrators once commissioning is complete. Do not leave the ES account in Administrators during production.

For hardened images with UAC enabled, the built-in Administrator account itself must be enabled and password-set before this procedure, because the engineering download coordinator spawns child processes that require the elevated token.

Step 4 – Verify NetPro source PC name

Open NetPro on the ES/OS, select the PC station entry, and read the "PC station name" property. The download coordinator uses this value to authenticate the source. If the engineer station was renamed (or cloned) without updating NetPro, the OS will reject subsequent downloads from the "old" source name even though the project files look identical.

NetPro → select PC station → right-click → Object Properties → General

Step 5 – Inspect the .xdb files

The OS download writes its network state into .xdb files inside the project. A corrupted .xdb will cause the same symptom. Before deleting the OS folder, archive a copy:

xcopy D:\PCS7\OS_Project\*.xdb C:\Backup\OS_xdb_%date:~10,4%%date:~4,2%%date:~7,2%\ /Y

On a repair attempt, after fixing the PC name / MAC, re-run NetPro "Save and Compile" so the .xdb files are regenerated on the ES side, and only then retry the complete download.

Step 6 – Check WinCC registry state

The OS download also writes to the registry under:

HKLM\SOFTWARE\SIEMENS\WinCC\RTOnly
HKLM\SOFTWARE\SIEMENS\WinCC\RTOnly\Computer

The Computer sub-key holds the in-project computer name. If this is stale, the OS will reject the second download. Read the value with:

reg query "HKLM\SOFTWARE\SIEMENS\WinCC\RTOnly" /s

Compare against the Windows computer name. If they differ, update the registry, restart the WinCC service, and retry.

Step 7 – Check SIMATIC Shell

Open SIMATIC Shell on the ES/OS:

Start → SIMATIC → SIMATIC Shell

The target OS should appear with the same name as configured in the project. If it does not, the OS NetBIOS name is not registering; the OS download will fail at the second pass because the source identifier cannot be re-resolved.

Step 8 – Check DNS and Microsoft connectivity

On Windows 11 and Windows Server 2022, the engineering station's first attempt to push a project can stall at 0% if the station cannot reach the Microsoft connectivity endpoints used by the SIMATIC Shell and the WinCC License Service. The Microsoft Learn Q&A – Win 11 first download stalls at 0% describes how DNS, proxy, and firewall restrictions cause indefinite stalls. Verify outbound DNS resolution and proxy bypass from the ES/OS before assuming a project-level corruption. From a command prompt on the ES/OS:

ping OS-2
nslookup OS-2
tracert login.microsoftonline.com

Both ping and nslookup must resolve the OS name. If ping works by IP but nslookup fails, the OS NetBIOS name is not registering. Use the IP address as a fallback in NetPro and re-attempt the download.

Resolution Procedure (Step-by-Step)

The following procedure has been field-validated to allow a second complete OS download without deleting the OS folder.

1. On the OS, deactivate WinCC Runtime and stop the WinCC service:

   net stop "SIMATIC HMI"
   net stop "CCAlgTaskManager"
   net stop "S7TraceServiceSrv"

2. Open WinCC Explorer on the OS and confirm the "Computer name" matches the Windows computer name byte-for-byte. Correct the field if needed and save.
3. Open SIMATIC Manager → PC Station → Configuration and confirm the MAC address of the Industrial Ethernet adapter matches the physical adapter. For CP1613, use the CP1613 diagnostic tool to reflash the MAC if necessary. For onboard NICs, update the in-project MAC to match the new hardware.
4. From the ES/OS, open NetPro. Select the PC station that represents the target OS. Open Properties → "Addresses" tab and re-enter the PC station name. Save and compile NetPro:

   NetPro → Save and Compile → check "PC Station" → OK

5. On the OS, open the deployed project in WinCC Explorer. Under "Computer" verify the source PC station name matches the engineering station's NetPro entry.
6. Add the ES engineer user to the local Administrators group of the OS. Log off the OS, log on again to refresh the token.
7. From the ES/OS, choose "PC Station → Download → Entire Station" (not "Download to Target System → Entire WinCC project" alone). This forces the S7 connection to be rebuilt. Wait for the "Download to PC Station" dialog to complete with a green check.
8. When prompted, confirm the overwrite of existing connections.
9. From the ES/OS, now choose "Download to Target System → Entire WinCC project". This pushes the WinCC project onto the OS. Monitor the progress bar.
10. After download, open WinCC Explorer on the OS, confirm the "Computer" property still matches, then start WinCC Runtime.
11. Verify the runtime activates without the "configured server not available" message.
12. Remove the ES engineer user from the OS Administrators group.

Alternate Resolution: Rebuilding the OS Identity Without Folder Deletion

If the complete download still fails after the procedure above, the OS local identity is corrupt at a level that the .xdb repair cannot reach. The next step is to preserve the archives and reset only the identity files:

net stop "S7TraceServiceSrv"
net stop "CCAlgTaskManager"
net stop "SIMATIC HMI"
ren D:\PCS7\OS_Project\*.xdb *.xdb.bak
xcopy \\ES-OS-1\OS_Project\*.xdb D:\PCS7\OS_Project\ /Y
reg delete "HKLM\SOFTWARE\SIEMENS\WinCC\RTOnly" /f

After this, re-attempt the complete download from the ES/OS. The archive database (D:\PCS7\OS_Project\ArchiveManager) is preserved, so logging continuity is maintained. The *.xdb.bak files can be deleted after a successful download and runtime activation.

Verification

After the fix, perform the following in order:

1. Open WinCC Runtime on the OS. Confirm the status indicator is green within 60 seconds. A red state after 60 seconds indicates the connection to the AS has not been established and is unrelated to the second-download issue.
2. From the OS, open WinCC Explorer → "Computer". Confirm the name is the Windows name, not the ES engineering station name.
3. From the ES/OS, force a delta download. It must succeed without intervention.
4. Deactivate the OS runtime, wait 30 seconds, reactivate. It must come back automatically.
5. Re-attempt "Download to Target System → Entire WinCC project". This must succeed and runtime must activate.
6. Verify the archive database is intact:

   dir D:\PCS7\OS_Project\ArchiveManager

   The file timestamps should predate the fix.

Troubleshooting Matrix

Symptom	Most likely cause	Diagnostic command	Fix
"An error occurred during download" with empty log	Target identity mismatch	ipconfig /all on OS	Match MAC in PC Station configuration
"Configured server not available" after first download	WinCC computer name drift	Compare reg query with hostname	Edit Computer name in WinCC Explorer
First download works, second fails, then again first works after folder delete	OS identity cache	reg query "HKLM\SOFTWARE\SIEMENS\WinCC\RTOnly" /s	Reset RTOnly registry key
Download stalls at 0% on Windows 11	Microsoft connectivity blocked	tracert login.microsoftonline.com	Open firewall / configure proxy
Delta download works, complete download fails	Source PC name not in NetPro	NetPro → PC Station properties	Re-enter source PC station name
Second download fails after CP1613 swap	MAC drift	CP1613 diag tool	Reflash MAC to match project
Second download fails after image clone	Windows computer name not randomized	hostname	Re-run sysprep or rename PC
ES user cannot push project	Insufficient user rights	Local Users and Groups	Add ES user to Administrators temporarily
Runtime starts but loses connection to AS after 5 minutes	S7 connection over TCP/IP rather than ISO	Station Configuration Editor → IE General	Switch to ISO-on-TCP
OS log shows "S7DOS: partner not found"	Subnet mismatch	NetPro compare	Align S7 subnet between ES and OS

Network Connectivity Considerations

Before applying the resolution procedure, eliminate environment-level blockers. On Windows 11 and Windows Server 2022, the engineering station's first attempt to push a project can stall at 0% if the station cannot reach the Microsoft connectivity endpoints used by the SIMATIC Shell and the WinCC License Service. The Microsoft Learn Q&A – Win 11 first download stalls at 0% thread describes how DNS, proxy, and firewall restrictions cause indefinite stalls.

Verify from the ES/OS:

ping login.microsoftonline.com
nslookup login.microsoftonline.com
nslookup go.microsoft.com

If these fail, configure a proxy exception in Internet Explorer / Edge legacy or open the firewall for *.microsoftonline.com and *.microsoft.com over 443. After this, retry the download.

The same applies to the S7 communication path. The plant bus must be reachable from the ES/OS to the OS. The S7 protocol uses TCP/102 (ISO-on-TCP) and ISO transport. The firewall on the OS must allow inbound 102, 161 (SNMP), 34964 (OPC UA), and 34980 (PNIO). From the ES/OS:

Test-NetConnection OS-2 -Port 102
Test-NetConnection OS-2 -Port 161

If any port is closed, the second download will fail because the engineering station cannot establish the S7 connection.

Preventive Configuration

Apply the following at project build time to prevent the second-download failure from ever appearing:

Setting	Location	Value
WinCC "Computer name" locked to Windows name	WinCC Explorer → Computer	Match Windows
PC station name locked	NetPro → PC Station	Match Windows
CP1613 MAC	Station Configuration Editor	Match hardware
D: drive shared as D	Computer Management → Shares	Yes, full control for ES user
Project folder shared	Computer Management → Shares	Yes, full control for ES user
ES user in SIMATIC HMI group	Local Users and Groups	Yes
ES user temporarily in Administrators	Local Users and Groups	Only during commissioning
NetBIOS over TCP/IP enabled	NIC Advanced Properties	Yes
Firewall exception for S7 protocol	Windows Defender Firewall	Allow 102, 161, 34964, 34980
DNS suffix appended	NIC → TCP/IPv4 → Advanced	Plant domain suffix
UAC remote restrictions	Local Security Policy	Configure for engineering users
LMHOSTS file entry	C:\Windows\System32\drivers\etc	OS-2 → 192.168.0.20

Additional field-proven caveats:

• The Compile and Download log will always be empty for this failure mode. The rejection happens on the target OS, not on the engineering station.
• The "configured server not available" message is generic WinCC Explorer text and is not specific to the download failure. It can also appear when the AS is offline. Check the AS connection first.
• Adding the ES user to the local Administrators group of the OS is a temporary measure. Leaving the user in Administrators after commissioning is a security violation under most plant security policies.
• On a multi-OS plant, do not reflash a CP1613 MAC to match a value already in use on another station. Each station's MAC must be unique on the plant bus. Use a one-time project-side edit instead.
• Do not rename the engineering station after the project is built. If the engineering station is renamed, NetPro will not pick up the change until a Save and Compile is run, and the OS will reject downloads from the new name until the in-project source PC name is updated.
• The OS archive database is not part of the WinCC project. It lives in D:\PCS7\OS_Project\ArchiveManager and survives a complete project re-download. It only dies when the OS folder itself is deleted.
• The "delta download" path uses a different code path than the "complete download" path in SIMATIC Manager and is more forgiving of PC name drift. If delta download works, the project identity is fine; the problem is specifically the complete download's full identity verification.

Frequently Asked Questions