Configuring Multicast Proxy in WinCC v7.5 Simatic Shell

Problem Description

When deploying a SIMATIC WinCC v7.5 multi-user project, the Simatic Shell on the server PC fails to enumerate the client PC, and the Simatic Shell on the client PC fails to enumerate the server PC. The client runtime may still load graphics and the server package through a manual Autostart UNC path, but browser-style project integration through Simatic Shell is broken. The two systems cannot discover each other through the WinCC terminal bus multicast mechanism even though:

• Both PCs are Windows 10 Pro 64-bit in the same Active Directory domain.
• Both use identical user credentials and the account is a local administrator.
• The account is a member of the WinCC user groups (SIMATIC HMI, SIMATIC NET) on each machine.
• IP addressing uses a single /24 subnet (e.g. 10.4.120.1 and 10.4.120.2).
• ICMP ping succeeds in both directions.
• DNS and the local hosts file both resolve the computer names.
• Network Discovery and File and Printer Sharing are enabled.
• Idle secondary network adapters are disabled, leaving only one active NIC per host.
• The server package on the client correctly references the server PC name.

The affected configuration reported in the field is WinCC V7.5 SP1 Update 2. Later updates (notably Update 4 and Update 5) ship corrections to the terminal-bus discovery stack and should be considered part of the resolution path.

Environment and Prerequisites

Review the following prerequisites before changing settings. Mismatches in any single item are enough to reproduce the symptom.

Root Cause Analysis

Simatic Shell discovery in classic WinCC v7.5 is implemented as a UDP/IP multicast service on the configured terminal bus adapter. When a client or server starts, CCAgent.exe registers itself on a well-known multicast group and listens for heartbeats from peer stations. If no heartbeats arrive within the discovery window, the peer does not appear in the shell, even though L4/L3 reachability and SMB file sharing work fine.

The condition is most often caused by one or more of the following:

1. The terminal bus is bound to the wrong network adapter when the host has more than one NIC (or has had an adapter disabled/re-enabled leaving a stale binding).
2. Multicast datagrams are silently dropped by Windows Firewall, by an intermediate switch that has IGMP snooping configured without a querier, or by a Hyper-V/virtual switch in the path.
3. Remote Communication is disabled in the WinCC Communication Settings, which prevents the discovery channel from being opened.
4. The CCAgent.exe service on either host cannot publish its hostname to the multicast group because the local routing table forces the multicast onto the wrong interface (a known corner case even on a single-NIC host when a VPN virtual adapter is present).
5. Stale multicast-IGMP state in network gear when a host has just been rebooted or moved between switches.

Each of the items above maps to a documented WinCC installation requirement. The canonical Siemens reference is the support entry SIMATIC WinCC FAQ: What are the requirements for operating SIMATIC WinCC in a Windows network?, which itemises the terminal bus, the remote communication flag, and the firewall expectations.

Solution 1 - Bind the Terminal Bus to the Correct Network Adapter

Even when only one NIC is enabled, Windows can still report a phantom interface from a virtual adapter, VPN client, or Hyper-V switch. The terminal bus binding in WinCC must point to the physical adapter that actually carries the terminal-bus traffic.

1. Open WinCC Explorer on both server and client PCs.
2. Right-click the project name and choose Properties.
3. Switch to the Graphics Runtime tab and click Terminal Bus.
4. Confirm the Network adapter dropdown lists the active physical NIC (e.g. Intel I219-LM) and not Hyper-V Virtual Ethernet Adapter, VPN-Tunnel, or a disabled interface.
5. If the wrong adapter is shown, select the correct one and click Apply. Restart CCAgent from services.msc (service name SIMATIC WinCC CCAgent) on both PCs.

To verify the binding from a command prompt:

netstat -ano | findstr :5000
route print
netsh interface show interface

The first command should show the WinCC terminal bus socket bound to the IP of the selected adapter. The third command confirms that no other interface has a higher metric that could steal multicast traffic.

Solution 2 - Enable Remote Communication

The Remote Communication flag opens the channel that the Simatic Shell uses to enumerate peer stations. If this is disabled, the shell can list local stations only.

1. On both PCs, open Start > Siemens Automation > Communication Settings.
2. Select the Remote Communication tab.
3. Check Activate remote communication.
4. Confirm the configured port (default TCP 5000 for terminal bus).
5. Click OK and restart the WinCC CCAgent service.

Solution 3 - Configure the Multicast Proxy

This is the resolution that restored visibility in the field case. The Multicast Proxy in Simatic Shell explicitly tells CCAgent the IP address of a peer station to register with the discovery group. It is normally only required when the client and server are on different subnets, but it is also an effective workaround when the local subnet cannot propagate multicast properly (common with IGMP-snooping switches that have no querier, or with VPN overlays that break multicast forwarding).

1. Open Simatic Shell on the server PC (Start > Siemens Automation > Simatic Shell).
2. In the right-hand pane, right-click and choose Multicast Proxy > Insert IP Address.
3. Enter the IP address of the client PC (e.g. 10.4.120.2).
4. Click OK. The new entry appears in the proxy list.
5. Open Simatic Shell on the client PC.
6. Insert the server IP address (e.g. 10.4.120.1) in the same way.
7. Restart the SIMATIC WinCC CCAgent service on both PCs.

After both proxies are populated, the server PC should appear in the client's shell and vice versa within a few seconds. The same entries persist across reboots.

Solution 4 - Allow Multicast and WinCC Services Through Windows Firewall

Windows Firewall is the single most common reason for Simatic Shell to fail while file sharing still works. SMB operates over TCP/445, which is allowed by the default Windows profile rules, but the WinCC terminal bus uses UDP multicast and TCP 5000. Both must be permitted.

1. Run the Siemens Security Controller tool from %ProgramFiles%\Siemens\Automation\WinCC\bin\SiemensSIMATICSecurityController.exe (path varies by installation) on both PCs.
2. Let the tool modify the Windows Firewall rules and the registry. Export the resulting ruleset to a text file for the change-log.
3. Confirm the following inbound rules are enabled on the active profile (Private or Domain):
   • SIMATIC WinCC CCAgent (UDP, any port)
   • SIMATIC WinCC CCServer (TCP 5000)
   • SIMATIC WinCC RT (TCP 5000 and UDP discovery ports)
   • File and Printer Sharing (SMB) - normally already enabled
4. For ad-hoc validation, temporarily disable the firewall on both PCs to confirm whether rules are the cause. If discovery returns, re-enable the firewall and tighten the rules with the security controller tool.

If a third-party endpoint protection product is installed (Symantec, CrowdStrike, Defender for Endpoint with attack-surface reduction), add explicit exclusions for CCAgent.exe, CCServer.exe, and WinCCExplorer.exe in the product's process allow-list.

Solution 5 - Apply the Latest Update

WinCC V7.5 SP1 Update 2 carries known issues in the discovery stack that were corrected in subsequent updates. The release notes for Update 4 and Update 5 explicitly mention improvements to terminal-bus reliability. Update both server and client to the same baseline before commissioning.

Always patch server first, then client, and reboot both before relaunching WinCC.

Verification Procedure

After applying the solutions, validate the discovery path end-to-end.

1. On the server PC, open Simatic Shell and confirm the client PC name appears under the server's domain node.
2. On the client PC, open Simatic Shell and confirm the server PC name appears with its published server package listed.
3. From a command prompt on both PCs, run netstat -ano | findstr :5000 and confirm the listening PID belongs to CCAgent.exe.
4. From the client, run wmic /node:<server> process where name="CCAgent.exe" get ProcessId (with appropriate DCOM rights) to confirm the agent is reachable over RPC.
5. Remove the UNC Autostart path from the client startup. The client should still load its graphics from the server through the shell-discovered path.
6. In WinCC Explorer on the client, right-click Server Packages and verify the server's package is listed and active.
7. Trigger a screen changeover, a tag write, and a valve toggle to confirm runtime I/O is unaffected by the configuration change.

Troubleshooting Matrix

Field-Proven Caveats

• Multicast Proxy is the only setting that worked in the field case even though the two PCs shared a /24 subnet. The IGMP snooping configuration on the access switch was the root cause; the proxy is the reliable workaround when the switch cannot be reconfigured.
• Do not rely solely on the UNC Autostart path. It bypasses Simatic Shell entirely, which means diagnostics, redundancy failover, and redun-dancy partner configuration all silently degrade.
• If you must use the UNC path as a stop-gap, document it in the project README. Future engineers will otherwise mistake the configuration for a real shell integration and waste hours debugging a non-existent fault.
• Always keep the server and client on the same WinCC V7.5 SP1 update level. Mixed update levels are a known source of discovery failures that look identical to network faults.
• Disable NIC power management on industrial PCs. Windows can power down the adapter during idle, which drops multicast group membership and makes Simatic Shell look intermittent.

Related Network and Security Checks

1. Confirm SMB signing is not blocking the session. WinCC does not require SMB signing, but some hardened Windows 10 builds enable it by default and reject unsigned sessions.
2. Confirm the Windows Network Profile is set to Private or Domain, not Public. A Public profile silently blocks all discovery traffic regardless of firewall rules.
3. If a VPN client is installed (Cisco AnyConnect, GlobalProtect, WireGuard), the virtual adapter can hijack the route table. Set the physical NIC metric lower (e.g. 1) and the VPN adapter metric higher (e.g. 100) in ncpa.cpl > Advanced > Advanced Settings.
4. Verify that Network Discovery is enabled for the current profile via net view \\\\localhost. If the local host cannot see its own shares, the firewall is blocking discovery.

Summary of Resolution Path

1. Bind the WinCC terminal bus to the correct physical NIC on both PCs.
2. Enable Remote Communication in Communication Settings.
3. Insert the peer IP address in the Simatic Shell Multicast Proxy on both PCs.
4. Re-run the Siemens Security Controller to open CCAgent/CCServer ports on Windows Firewall.
5. Update both PCs to the same WinCC V7.5 SP1 update level (Update 4 or newer).
6. Remove the UNC Autostart workaround and verify discovery through the shell only.