Troubleshooting WinCC OS Client 'Download to Target System' Error

Problem Overview

The error message "Error Occurred During Download to Target System" is generated by the WinCC/PCS 7 Engineering Station (ES) when a project download is initiated toward a paired OS Client. The transfer of the compiled OS project (server and client packages) fails before, during, or just after the write operation to the client computer, leaving either a partial project directory on the client or, more commonly, no project at all.

After the failed download, opening the local WinCC Explorer on the new client often returns a secondary message: "Access to the project is currently not allowed." This second symptom is almost always a consequence of the first; the WinCC project service could not complete the registration of the project path with the SIMATIC Shell, so the project is in an indeterminate state.

Architectural Context

Before troubleshooting, confirm the components involved in a PCS 7 OS client download:

The OS Client download path is, in the standard PCS 7 flow:

1. ES compiles the OS Client package.
2. WinCC on the ES opens an SMB/CIFS connection to the OS Client's WinCCProjects folder using the client computer's local administrator account.
3. The package is transferred, then registered with the SIMATIC Shell on the client.
4. The client service CCAlgServices and the WinCC project manager validate the registration and start runtime.

Any one of the four stages above can throw the "download to target system" error. The solution must therefore address SMB, DNS/name resolution, Terminal Bus binding, and local service permissions together.

Root Cause Matrix

Pre-Diagnostic Checklist

Capture the following information on the ES and the affected client before changing anything. This will accelerate escalation if the problem persists:

1. PCS 7 version: read from C:\Program Files\Siemens\Automation\PCS7\bin\p7hwsetup.exe "About" or the SIMATIC Manager Help » About.
2. WinCC version: WinCC Explorer » Help » About. Common pairings: PCS 7 V9.0 = WinCC V7.4 SP1, PCS 7 V9.1 = WinCC V7.5, PCS 7 V8.2 = WinCC V7.3.
3. OS Client computer name (Windows): hostname and ipconfig /all.
4. OS Client name configured in the project: WinCC Explorer » OS » right-click computer » Properties » Computer Name field.
5. Active user on client during download: whoami /groups | findstr S-1-5-32-544 (must include local Administrators).
6. Most recent Windows event log entries on the client: eventvwr.msc » Application » source CCAlgServices, WinCC, S7.

Solution 1: Verify Shared Folder Write Access

The OS Client's project directory must be writable by the ES user account, normally the Windows administrator used on the ES.

1. On the OS Client, open \\localhost\WinCCProjects (or the actual project root) and confirm the share is listed. If the share is missing, recreate it via SmcSrvSetup or by re-running the WinCC Client setup in repair mode.
2. From the ES, open Windows Explorer and navigate to \\<ClientName>\WinCCProjects.
3. Right-click » New » Text Document. If creation succeeds, write permission is in place. If it fails, the ES user is not authorized.
4. If creation fails, on the client right-click the folder » Properties » Sharing » Advanced Sharing » Permissions and add the ES user (or Everyone for diagnosis) with Full Control. Also add the user under the Security tab and select the same rights; Windows requires both NTFS and share permissions to be aligned.

Solution 2: Align SIMATIC Shell Terminal Bus Assignment

SIMATIC Shell on both the ES and the client must be bound to the network card that physically connects to the Terminal Bus. A mismatch causes the engineering download to attempt routing over the wrong interface, and the connection times out, surfacing as the target-system error.

1. On the ES: open Windows Explorer » navigate to My Computer.
2. Locate the SIMATIC Shell virtual folder, right-click » Settings.
3. In the dialog, select the NIC connected to the Terminal Bus (commonly an Intel I219-V on a dedicated /24 subnet, e.g., 192.168.0.x).
4. Click OK and allow SIMATIC Shell to reinitialize.
5. Repeat steps 1-4 on the OS Client, selecting the matching Terminal Bus NIC.
6. Open SIMATIC Shell on the ES and confirm the client appears under Accessible Computers. The reported IP and computer name must match the client.

If the client does not appear, the Terminal Bus routing is still broken. Validate the following:

• Ping the client Terminal Bus IP from the ES and vice versa.
• Verify no VLAN mismatch on the switches; the Terminal Bus should be a single L2 broadcast domain.
• Verify Windows Defender Firewall allows the SIMATIC Shell service (SNMP and the WinCC discovery ports) on the Domain and Private profiles.

Solution 3: Configure the PG/PC Interface

The PG/PC interface defined in Configuration Console determines which card S7ONLINE uses for S7 communication. If this assignment is inconsistent with the SIMATIC Shell binding, the download to the client (which is itself an S7-styled transfer) can fail.

1. Start » SIMATIC » SIMATIC NET » Configuration Console.
2. Select the access point S7ONLINE.
3. Assign the same NIC that you selected in SIMATIC Shell on the ES. Save and close.
4. If the ES has a second card used for engineering (for example, a CP1623 or a Softnet IE S7 Lean), temporarily disable it and reattempt the download. This eliminates the race condition where the wrong card handles the connection.

Solution 4: Synchronize the OS Client Computer Name

The OS project on the ES stores the destination computer name. If the name in the project differs from the client's actual Windows hostname, the download either writes to a non-existent path or registers the project under the wrong name. The fix is to align them.

1. On the OS Client, open an elevated command prompt and run hostname. Note the exact output.
2. On the ES, open WinCC Explorer.
3. Right-click the OS in the project tree » Properties » Computer Name tab.
4. Change the computer name to exactly match the value from step 1, paying attention to case (Windows hostnames are case-insensitive, but the WinCC project treats them as case-sensitive strings).
5. Save, recompile the OS, and re-attempt the download. The download dialog will update the OS Client name automatically on the client side as part of the transfer.

If the ES and client are part of a Windows domain, the same step applies for the FQDN. Avoid pointing the OS computer name at a DNS alias (CNAME); use the A-record hostname only.

Solution 5: Set Correct Windows User and Group Membership

The WinCC OS Client services must run under an account that is:

• A member of the local Administrators group on the client.
• A member of the local SIMATIC HMI group (auto-created by the WinCC Client install).
• Allowed to log on as a service (secpol.msc » Local Policies » User Rights Assignment » Log on as a service).

1. On the OS Client, log in as the account that will receive the download.
2. Open lusrmgr.msc » Groups » double-click SIMATIC HMI. Confirm the user is a member; if not, add it.
3. Open services.msc and verify CCAlgServices, S7DOS, and WinCC Explorer are set to Automatic and that they are currently Running under the correct account.
4. If the project is a domain-managed system, the domain user must be a member of the local groups; AD membership alone is not sufficient because WinCC installs create local groups by design.

Solution 6: Reinstall the Network Adapter

If the project compiles, shares are writable, SIMATIC Shell shows the client, and the user permissions are correct, but the download still fails, the cause is often a corrupt NIC driver or stale binding. Reinstalling the network adapter is a proven recovery step.

1. On the OS Client, open ncpa.cpl.
2. Right-click the Terminal Bus NIC » Uninstall device. Tick Delete the driver software for this device.
3. Reboot the client. Windows re-detects the NIC and reinstalls a clean driver from the driver store.
4. Confirm the IP address, subnet mask, and DNS are restored, and that the Terminal Bus NIC has its original IP.
5. Reattempt the OS download from the ES. The error should no longer appear; if it does, the issue is environmental (firewall, AV) and not driver-related.

If Windows cannot reinstall a working driver automatically (common with industrial PCs that need a vendor-specific driver), use the OEM driver pack from the manufacturer (Siemens AG, Kontron, Advantech, etc.) and install it manually before continuing.

Verification Procedure

After applying any of the solutions above, run the following sequence to confirm the OS Client is fully operational:

1. From the ES, open SIMATIC Shell and verify the client appears with a green status icon and the correct IP.
2. Trigger a Download to Target System from WinCC Explorer. The dialog should complete without the error and report Download successful.
3. On the client, open WinCC Explorer » select the project » Activate. The runtime should start without the "Access to the project is currently not allowed" message.
4. Open the OS runtime and confirm process pictures load and the configured area selection is responsive. The Alarm Logging and Tag Logging services should both initialize cleanly; check the WinCC_Sys_<YYYYMMDD>_<HHMM>.LOG on the client for No errors.
5. Force a process tag change on the OS Server and verify it is visible on the new client within one refresh cycle (default 1 s, 2 s, or 5 s depending on the configured time base).

Troubleshooting Matrix

Preventive Measures for Future OS Client Adds

• Use a deployment checklist per new client: hostname pre-reserved in DNS, static IP assigned on Terminal Bus, local administrator created, antivirus exception list updated with C:\Program Files\Siemens\Automation\WinCC.
• After a Windows cumulative update, always validate the Terminal Bus connectivity with a manual SIMATIC Shell browse from the ES before triggering any download.
• Document the PG/PC interface assignment per ES in the plant's automation network register. A change in one ES can disrupt multiple clients.
• Maintain a golden image of the OS Client OS (with WinCC Client preinstalled) and the matching SIMATIC Shell configuration. Clone the image to new hardware to reduce per-install variance.

Frequently Asked Questions