Troubleshooting OS Server Download Failures from a Replaced Engineering Station - Remote Control and Simatic Shell

When replacing an Engineering Station (ES) and discovering that OS project downloads to the OS Server fail—specifically where the ES fails to automatically deactivate WinCC Runtime on the server, transfer project files, and reactivate Runtime—the failure stems from broken remote administration communication. In SIMATIC PCS 7, automated remote OS management depends on three synchronized prerequisites: first, the network adapter bound to the Terminal Bus in Simatic Shell must match across the new ES and OS Server with encrypted communication settings aligned; second, the Windows user logged into the new ES must exist on the OS Server with an identical username and password and belong to the local SIMATIC HMI and Administrators groups; third, the Remote Control service (CCRemoteService.exe) and DCOM security permissions on the server must authorize the new ES machine.

Automated Remote OS Download Mechanics in SIMATIC PCS 7

In SIMATIC PCS 7, deploying changes to an operational plant does not require engineers to walk to physical server racks with USB storage. The Engineering System (ES) provides automated remote project deployment via the 'Target System > Download' command in SIMATIC Manager.

When downloading to a redundant OS Server or Single Station, the ES coordinates a multi-stage remote lifecycle:

Remote Deactivation Check: The ES connects to the OS Server via remote procedure calls (RPC/DCOM) and queries the runtime state. If an Entire Download is requested, it invokes the Remote Control Service (CCRemoteService.exe) to gracefully deactivate WinCC Runtime.
Database and File Transfer: The ES copies project pictures (*.pdl), scripts (*.pas, *.c), and re-attaches the compiled Microsoft SQL Server project database (*.mdf) over the Windows network share.
Remote Reactivation: Following successful file transfer and database registration, the ES issues a remote activation command, starting WinCC Runtime automatically without local manual intervention.

When an ES is replaced with new hardware or a fresh operating system image, this automated handshake frequently breaks.

Simatic Shell Network Adapter Binding and Encryption Settings

The foundational communication layer for all inter-station engineering operations in PCS 7 is Simatic Shell:

Network Adapter Selection: When Windows installs on a new ES, it may prioritize a secondary network interface (such as a corporate LAN, wireless card, or Plant Bus CP 1623 card) rather than the physical Terminal Bus adapter. If Simatic Shell binds to the wrong network adapter, the ES cannot broadcast or receive multicast discovery tokens from the OS Servers.
Encrypted Communication (PCS 7 V8.2 / V9.0): Modern PCS 7 releases feature encrypted Simatic Shell communication. If the new ES does not have the identical encryption key, migration mode, or port configurations as the existing OS Servers, all remote station discovery is blocked, and the servers appear with blue question mark icons in Simatic Shell.

Windows User Accounts, Group Memberships, and DCOM Security

Remote project deactivation and file transfer operate under Windows security tokens:

Identical User Credentials: In non-domain (workgroup) industrial networks, the Windows user account active on the ES must exist on the OS Server with the identical username and identical password.
Mandatory User Groups: On both the ES and OS Server, this user account must be an explicit member of:
SIMATIC HMI
Siemens TIA Engineer
Administrators
DCOM and Security Policies: If the user is missing from SIMATIC HMI, Windows DCOM security policies actively block the remote call to CCRemoteService, causing SIMATIC Manager to report: 'Cannot connect to the target computer' or 'Deactivation of Runtime failed'.

Network Share Permissions and Target Path Validation

File transfer during OS download requires access to the project share on the OS Server:

In SIMATIC Manager, right-click the OS Server object and select Object Properties > Target OS and Standby OS.
The target path must specify a valid UNC network path (e.g., \\OS_SRV1\OS_SRV1_PRJ\OS_SRV1.mcp).
On the OS Server, the shared folder must have Full Control permissions granted under both Share Permissions and NTFS Security Permissions for the SIMATIC HMI and Administrators groups.
If the new ES cannot write to this network share, file transfer will abort with access denied errors.

Comparative Fault Matrix: OS Server Remote Download Symptoms

The following table diagnoses root causes and remedies for common OS remote download failures after ES replacement:

Symptom / Error MessagePrimary Root CauseSubsystem AffectedEngineering Remedy'Cannot connect to target station'Wrong NIC bound in Simatic ShellSimatic Shell / MulticastOpen Simatic Shell -> Settings -> Select Terminal Bus NICBlue Question Mark on OS ServerSimatic Shell encryption mismatchSimatic Shell SecurityMatch encryption key or disable encryption across all stationsRuntime fails to deactivate automaticallyMissing user in SIMATIC HMI groupWindows DCOM / CCRemoteServiceAdd ES user to SIMATIC HMI and Administrators on OS Server'Access is denied' during file transferNTFS / Share permission lockWindows File SharingGrant Full Control to SIMATIC HMI on target share folderDownload finishes but fails to activateTarget OS path configured locally (C:\...)SIMATIC Manager PropertiesChange target path to UNC network format (\\Server\Share\...)

Step-by-Step Recovery Procedure After ES Hardware Replacement

Follow this step-by-step procedure to re-establish automated OS downloads from a new Engineering Station:

Align Windows User Credentials:
- On the new ES, verify your logged-in username (e.g., Engineer).
- Log onto the OS Server and open Windows Computer Management (compmgmt.msc).
- Under Local Users and Groups, confirm that user Engineer exists with the exact same password.
- Ensure Engineer is a member of Administrators, SIMATIC HMI, and Siemens TIA Engineer.
Configure Simatic Shell on New ES:
- Open Windows Explorer, scroll down to the navigation pane, and click Simatic Shell.
- Right-click Simatic Shell and select Settings...
- In the network adapter drop-down, select the physical network card connected to the Terminal Bus.
- Ensure encrypted communication settings match the OS Server.
- Click OK and restart the station if prompted.
Verify Simatic Shell Visibility:
- Open Simatic Shell. Verify that the OS Server appears without blue question marks.
- Right-click the OS Server in Simatic Shell and select Remote Communication Test.
Validate Target Path in SIMATIC Manager:
- In SIMATIC Manager on the new ES, open the project.
- Right-click the OS Server -> Object Properties -> Target OS and Standby OS.
- Click Browse and locate the shared folder on the OS Server via network neighborhood.
Execute Download:
- Right-click the OS Server -> Target System > Download.
- Select Entire Download or Changes only.
- Confirm that Runtime automatically deactivates, files copy, and Runtime reactivates.

Verification

Validate remote engineering capabilities through the following functional checks:

From the new ES, initiate an OS Changes Download to the standby OS Server.
Observe the OS Server monitor: confirm that a dialog appears indicating remote management and Runtime deactivates cleanly.
Monitor progress in SIMATIC Manager: verify that SQL database files and graphics transfer without errors.
Confirm that upon download completion, WinCC Runtime automatically reactivates on the OS Server without human intervention.
Verify redundant partner synchronization: confirm that the active and standby servers synchronize their internal databases.

Limitations and Operational Precautions

Redundant Server Download Sequencing: Never download an 'Entire project' to both redundant OS servers simultaneously. Always download to the standby server first, wait for full synchronization, perform redundancy switchover, and then download to the partner server.
Windows Firewall Exceptions: Ensure that the standard Siemens firewall rules (SimaticSecurityControl.exe) have been executed on the new ES. Blocking port 135 or dynamic RPC ports will prevent remote control actions.
Workgroup vs Domain Architecture: In corporate active directory domains, ensure the new ES computer object belongs to the same domain organizational unit (OU) to inherit necessary group policies.

Engineer FAQ

Why did my old ES deactivate the server automatically, but the new one does not?

The old ES had established DCOM permissions and security tokens. The new ES has a new security identifier (SID), requiring its user account to be properly populated in the SIMATIC HMI group on the target server.

Can I download the OS project if the server is in runtime?

Yes, using 'Changes Download'. Changes download updates pictures, scripts, and tags without deactivating WinCC Runtime. An 'Entire Download' mandates runtime deactivation.

What is `CCRemoteService.exe`?

CCRemoteService.exe is the Siemens WinCC Remote Control Service that runs in the background on OS servers to handle remote deactivation, activation, and project path management.

Why does Simatic Shell show a blue question mark on the server?

A blue question mark indicates that the station was detected via broadcast, but secure encrypted communication could not be established. Check Simatic Shell encryption passwords and migration settings.

Do I need to run Simatic Security Control on the new ES?

Yes. Running Simatic Security Control (Start > Siemens Automation > Security Control) automatically configures Windows Firewall, DCOM, and registry permissions required for PCS 7 multi-station engineering.

Technical References

Related Tags

OS Download
Simatic Shell
Engineering Station
CCRemoteService
DCOM
Terminal Bus
PCS 7 OS

6 respuestas

Troubleshooting OS Server Download Failures from a Replaced Engineering Station - Remote Control and Simatic Shell