WinCC Web Navigator 6.2 No Connection Fix on Server 2003 R2 SP1

Problem Overview

After deploying SIMATIC WinCC V6.2 together with the SIMATIC WinCC/Web Navigator V6.2 server component on a host running Windows Server 2003 R2 SP1, the typical field symptom is that the Web Navigator client running on a remote Windows XP SP2 workstation displays:

"WinCC Web Navigator reconnect..."
"No Connection to server"

The local Web Navigator client launched directly on the server host, however, connects and operates normally. The server itself continues to host other web applications (for example ASP.NET sites) that remain reachable from any client, isolating the failure to the WinCC/Web Navigator stack rather than to the underlying network or generic IIS service.

Because the failure appears only on the remote client and not on the local client, the root cause is almost always one of the following:

1. Use of a WinCC/Web Navigator version that is not released for Windows Server 2003 R2 SP1 on the server side.
2. A misconfiguration of the IIS 6.0 web site used by Web Navigator (application pool, anonymous authentication, ASP.NET version).
3. User-rights, domain-trust, or DCOM security restrictions blocking the WinCC runtime user from publishing graphics over HTTP.
4. Residual service-pack state of Windows Server 2003 R2 SP1 that interferes with the DCOM/COM+ components used by the WinCC server.

Officially Supported Operating Systems for WinCC/Web Navigator V6.2

For SIMATIC WinCC/Web Navigator V6.2 the released server-side and client-side operating systems are documented in the WinCC/Web Navigator V6.2 manual and the release notice linked above. The general matrix reproduced in the field discussion is:

According to Siemens entry ID 24369567, starting with Web Navigator V6.2 the operation under Windows Server 2003 R2 is released for the server side as well as the client side. The release covers the base R2 build; V6.2 SP-x updates must be cross-checked individually because Siemens only certifies combinations explicitly enumerated in the matrix.

Root Cause Analysis

The failure mode described — local client OK, remote client receives "No Connection to server", and an unrelated ASP.NET site on the same server still functions — is a textbook signature of one of the following three causes. Use the matrix below to isolate which one applies to your environment.

Why Local vs. Remote Behave Differently

The Web Navigator client opens an HTTP session to the IIS-hosted WebNavigatorClient virtual directory and then establishes a DCOM channel back to the WinCC runtime. On the server itself, both the HTTP and the DCOM leg traverse the loopback path, which bypasses several DCOM authentication checkpoints. On a remote client the DCOM leg is fully marshaled across the network, where DCOM checks the configured launch and access permissions of the calling user. If those permissions are missing, the HTTP leg succeeds (the ASP.NET site also works because it does not require DCOM) but the WinCC graphics channel silently fails, surfacing as "No Connection to server".

Pre-Flight Checklist

Before opening IIS Manager or DCOM configuration, gather the following evidence. Each item eliminates a category of fault in a single step.

1. Confirm exact OS build: run winver on the server and record the build string (for example 5.2.3790.3959 for Windows Server 2003 R2 SP1). Compare to the V6.2 matrix.
2. Confirm exact WinCC build: open the WinCC Explorer, choose Help > About, and record the build number (for example V6.2.0.0 with Hotfix level). Cross-reference with entry 24369567.
3. Validate the Web Navigator client URL: from the remote client, browse to http://<server>/WebNavigatorClient/start.asp. If the page fails with HTTP 404, the virtual directory is not registered. If 401/403, jump to the IIS section below.
4. Test the unrelated ASP.NET site: confirm that http://<server>/<yourapp> still resolves from a remote client. Its success proves network, DNS, and base IIS are healthy.
5. Verify domain membership: open System Properties > Computer Name on both server and client. Both must be in the same Active Directory domain, or the client account must be explicitly granted on the server.
6. Verify the WinCC service account: confirm the account under which CCWinSvc.exe and S7ONTOPX.exe run; this account must be added to the WinCC user group and to the local Impersonate a client after authentication user-right assignment (or equivalent SeImpersonatePrivilege).
7. Capture a baseline: open Control Panel > Administrative Tools > Event Viewer on the server. Export the Application and System logs before making any change so the failure state is preserved.

Solution Path A — Restore a Matrix-Released Configuration

This is the recommended fix when the audit in the previous section shows that the installed combination is not in the V6.2 matrix (the most common case in the field is Windows Server 2003 R2 SP1 paired with V6.2 without an explicit SR/DR).

Step-by-Step

1. Revert SP1 if Windows Server 2003 R2 (base, no SP) is the released row in the matrix. Use Add or Remove Programs, locate "Windows Server 2003 R2 Service Pack 1", and uninstall. A reboot is required.
2. Alternatively, upgrade WinCC to the latest WinCC/Web Navigator V7.0 or V7.0 SP1 revision whose matrix explicitly lists Windows Server 2003 R2 SP1. Apply the matching WinCC Hotfix package before reconnecting clients.
3. Reinstall the Web Navigator server component from the released media: Start > Setup > Web Navigator Server. Accept the default virtual directory WebNavigatorClient.
4. Run Simatic Security Control: from the WinCC DVD or installation image, launch Setup > Simatic Security Control and apply the recommended WinCC-specific DCOM and user-rights configuration. The wizard edits dcomcnfg, grants the WinCC users group the default launch and access rights, and sets the WinCC applications to run under the local system account or the configured WinCC service user.
5. Restart the WinCC runtime and confirm that CCWinSvc.exe reaches the "Running" state in the WinCC Service Control dialog.

Solution Path B — Repair IIS 6.0 Configuration

If the matrix check passes, the next most common cause is a broken IIS 6.0 configuration. WinCC/Web Navigator V6.2 ships its own IIS metabase script and registers a dedicated application pool; both can be damaged by IIS Lockdown Tool, URLScan, or by hand-editing the metabase.

Step-by-Step

1. Open Internet Information Services (IIS) Manager from Administrative Tools.
2. Expand Web Sites > Default Web Site and confirm that the WebNavigatorClient virtual directory exists, points to %ProgramFiles%\Siemens\Automation\WinCC\WebNavigator\Client, and that its ASP.NET version is set to 1.1.4322 (the .NET Framework 1.1 runtime that V6.2 requires).
3. Right-click WebNavigatorClient and choose Properties > Directory Security > Authentication and access control. Enable Enable anonymous access and set the username to IUSR_<servername>; clear Integrated Windows Authentication unless your client accounts are explicitly mapped.
4. Open Application Pool for WebNavigatorClient and confirm the pool identity has read/execute rights on the WinCC installation directory and on the project runtime directory.
5. From a command prompt, run iisreset /restart and re-test the local client first, then the remote client.

Solution Path C — Repair DCOM and User Rights

When IIS is correct but the remote client still hangs at reconnect, the failure is on the DCOM leg of the WinCC graphics channel. This is the path that matches the field symptom of a remote XP SP2 client failing while a local client succeeds.

Step-by-Step

1. Log on to the server as a domain administrator.
2. Launch dcomcnfg.exe from a command prompt. Open Component Services > Computers > My Computer > DCOM Config.
3. Locate the WinCC applications: WinCC Runtime, WinCC Taglogging, WinCC Alarmlogging, CCLicenseServer. For each, open Properties > Security.
4. Under Launch and Activation Permissions, click Edit and add the group SIMATIC HMI (or the local WinCC users group created by Simatic Security Control). Grant Local Launch, Remote Launch, Local Activation, and Remote Activation.
5. Under Access Permissions, add the same group with Local Access and Remote Access.
6. Close dcomcnfg and run CCWinSvc.exe /regserver from the WinCC installation directory to re-register the COM interfaces.
7. From the remote XP client, log in as a domain user that is a member of SIMATIC HMI on the server and launch the Web Navigator client again.

Solution Path D — Firewall, Antivirus, and Loopback Considerations

Although the original report states that the firewall is disabled and no antivirus is installed, in many production environments a corporate policy reinstalls the firewall or installs endpoint protection after commissioning. The Web Navigator DCOM leg uses dynamically assigned TCP ports in the range 1024–65535 and the legacy RPC port 135/tcp.

If the firewall cannot be disabled, create an inbound rule that allows 80/tcp, 135/tcp, and the RPC dynamic range from the client subnet. Apply the same rule for SMB (445/tcp) only between the WinCC server and the domain controllers, not to the broader network.

Verification

After applying one of the four solution paths, run the following verification sequence. Each step must succeed before moving to the next; a failure at any step re-opens the fault tree.

1. Local client smoke test: on the server itself, launch Start > Programs > SIMATIC > WinCC > Web Navigator Client. The client must load the start page without "No Connection".
2. Remote HTTP test: from the remote XP SP2 client, browse to http://<server>/WebNavigatorClient/start.asp. The login dialog must appear.
3. Remote graphics test: log in with a WinCC user and confirm that the configured start picture loads within five seconds. Anything longer indicates a residual DCOM or authentication delay.
4. Reconnect test: stop and start the WinCC runtime from the WinCC Service Control dialog. The remote client must transition from "Connecting" to "Connected" automatically without operator intervention.
5. Load test (optional): connect three concurrent Web Navigator clients (the maximum supported for the V6.2 workstation-class license on Windows Server 2003) and confirm that all sessions stay alive for at least 30 minutes.
6. Log review: export the server Application log and confirm no DCOM Error 10010, 10016, or 10017 entries appear within 10 minutes of client connection.

Troubleshooting Matrix

Preventive Hardening

Once the system is back online, lock the configuration to prevent recurrence.

• Document the installed WinCC build, hotfix level, OS build, and SP level in the project quality folder. Re-check the matrix before any Windows update.
• Disable automatic Windows Update on the WinCC server. Apply only the patches listed in the Siemens compatibility matrix.
• Schedule a quarterly export of the IIS metabase, the DCOM security descriptors (via sc.exe sdquery and dcomperm.exe), and the Automation License Manager configuration. Store offline.
• Restrict interactive logon to the WinCC service account; remove unnecessary domain users from the local SIMATIC HMI group.
• Capture a baseline of the Application and System event logs after a clean start so that future drift can be detected automatically.

Related References

• Siemens Support entry ID 24369567 — SIMATIC WinCC/Web Navigator V6.2 available now (SR/DR)
• Microsoft Learn — List of updates in Windows Server 2003 Service Pack 2
• Microsoft — Windows Server 2003 (Wikipedia background)

FAQ