WinCC Web Navigator Fixing IE 11 Compatibility on Windows 7

Overview

WinCC Professional V12 SP1 (TIA Portal) ships with the Web Navigator option, which allows HMI screens to be published to remote clients over the intranet. On paper, the workflow is simple: enable web access on a user, mark the desired screens as web-enabled, compile the project, configure the WebNavigator server with the WinCC Web Configurator, and connect from a client using either Internet Explorer or the WinCCViewer RT thin client. In practice, two failure modes surface on Windows 7 Professional 64-bit with Internet Explorer 11:

1. The Web Client logs in successfully but reports that the configured starting page cannot be found.
2. Internet Explorer 11 reports a banner stating that Web Navigator does not support this operating system or browser, even though the OS, browser, and project are individually valid.

The root cause in both cases is the same: WinCC V12 SP1 Web Navigator was certified against Internet Explorer 9 and the legacy ActiveX/HTML rendering stack that ships with it. Internet Explorer 11 changes the user-agent string, removes legacy X-UA-Compatible document mode behavior, and changes how the Web Client ActiveX control is instantiated. The WebNavigator client runtime in V12 SP1 rejects the new UA string outright, and the page-not-found message is a side effect of the same handshake failing on the IE 11 render path.

This article documents the diagnosis, the IE 9 downgrade workaround that is the only field-proven fix for the V12 SP1 line, the alternative WinCCViewer RT path that bypasses the browser entirely, and the configuration steps that must accompany either approach.

Problem Description and Symptoms

The reported failure sequence on a Windows 7 Professional 64-bit engineering or operator station is reproducible across fresh installations:

1. The TIA Portal project compiles without errors in the WinCC Professional ES.
2. Web-enabled screens are flagged in the ES via Screen > Web-enabled.
3. A user group is created in the WinCC User Administrator and assigned administrator rights plus Web access rights.
4. The WinCC Web Configurator assigns port 80 (or 8080) and the start screen, and the WinCC WebNavigator service is started.
5. On the client, the WebNavigator Client install is run from the CD or shared path. The setup completes without errors.
6. Launching the client in Internet Explorer 11 opens a page that displays: "The Web Navigator does not support the operating system you are using, or the browser you are using."
7. Launching WinCCViewer RT on the same client accepts credentials, the toolbar and overview tree appear, but switching to the configured start screen produces: "The starting page cannot be found."

The same project and the same client hardware, when booted into Windows XP Professional 32-bit with Internet Explorer 8, runs the WebNavigator Client end-to-end with all screens, tags, and controls functional. The failure is therefore not in the project, the server, the user rights, or the network path; it is in the client runtime's compatibility check.

Root Cause Analysis

WinCC V12 SP1 Web Navigator was released in 2013 and is tied to a fixed list of supported browsers. The WebNavigator Client runtime performs three checks at session start, and any one of them can short-circuit the session before the start screen is loaded:

1. User-Agent string match. The client ActiveX control inspects the User-Agent HTTP header. Internet Explorer 11 ships a UA token (Trident/7.0; rv:11.0) that the V12 SP1 control does not recognize. The control returns a generic "not supported" page and never attempts to download the start screen.
2. Document mode rendering. The V12 SP1 client assumes the legacy X-UA-Compatible: IE=9 document mode is active. IE 11 ignores the meta tag fallback by default and uses the Edge engine, so the JavaScript bridge that maps the ActiveX control to the HMI screen tree never initializes.
3. ActiveX hosting. The WinCC Web Client is hosted as an ActiveX control inside the browser process. IE 11 on Windows 7 64-bit moves ActiveX to a 64-bit-only mode for certain CLSIDs, which prevents the V12 SP1 control from registering cleanly on first run.

The "starting page cannot be found" error in WinCCViewer RT is not a missing-screen error. The runtime is unable to resolve the start screen URL because the ActiveX bridge above failed, and the only message the client can render in that state is a placeholder. Changing the start screen assignment does not affect the result.

Affected Versions and Compatibility Matrix

Resolution Path A: Downgrade Internet Explorer to Version 9

This is the only path that uses the browser-based Web Client on V12 SP1. The procedure must be run as a local administrator. It is destructive in the sense that Windows Update will not re-upgrade a system that has been pinned to IE 9, but Internet Explorer 9 is still a Microsoft-supported standalone download for Windows 7 64-bit.

Prerequisites

• Local administrator credentials on the client PC.
• Internet Explorer 11 removed or disabled.
• All instances of Internet Explorer and the WinCCViewer RT closed.
• Access to the original WebNavigator Client install media that matches the V12 SP1 server build.

Step-by-Step Procedure

1. Uninstall Internet Explorer 11 via Control Panel > Programs and Features > View installed updates. Select Windows Internet Explorer 11 and click Uninstall. Reboot when prompted. The system will roll back to Internet Explorer 9, which is the default browser on a stock Windows 7 SP1 64-bit image.
2. Verify the downgrade by launching the browser and checking Help > About Internet Explorer. The version must read 9.0.x. If it still shows 11, the system image is locked; in that case use Programs and Features > Turn Windows features on or off and disable Internet Explorer 11 explicitly before rebooting.
3. Reinstall the WebNavigator Client from the V12 SP1 install media. Use Start > Programs > Siemens Automation > WinCC > WebNavigator > WebNavigator Client Setup. The setup registers the ActiveX control against the IE 9 hosting model and writes the correct CLSID entries to the registry.
4. Add the WebNavigator Server to the Local Intranet Zone in Internet Explorer 9: Tools > Internet Options > Security > Local intranet > Sites > Advanced. Add the server's FQDN or IP address. This step is required for ActiveX controls to instantiate without a prompt.
5. Enable ActiveX filtering off and Compatibility View off for the same zone. ActiveX filtering in IE 9 is on by default for the Internet zone; if the server is misclassified, the control will not load.
6. Test the session by navigating to http://<server>/WebNavigator/ (or https:// if SSL is configured). Log in with the configured web user. The configured start screen should load in under five seconds on a 100 Mbit LAN.

Resolution Path B: Use the WinCCViewer RT Thin Client

WinCCViewer RT is the standalone executable that ships with the WebNavigator Client install. It hosts the same ActiveX control outside the browser, so the IE UA check is never performed. This path is the recommended one for new deployments where a browser downgrade is politically or operationally unacceptable.

Configuration

1. Install the WebNavigator Client setup. The installer places WinCCViewerRT.exe in the install path, typically C:\Program Files (x86)\Siemens\Automation\WinCC\WebNavigator\Client\.
2. Create a connection profile by running WinCCViewerRT.exe /? to enumerate the command-line switches. The two that matter for V12 SP1 are:
   • /SERVER <hostname or IP> - target WebNavigator server.
   • /PORT <tcp port> - default 80, must match the WinCC Web Configurator setting.
3. Permanently store the server address in the registry by exporting a key under HKCU\Software\Siemens\WinCC\Web\Client\1.0\ with values ServerName (REG_SZ) and ServerPort (REG_DWORD). The viewer reads these at every launch, so the operator does not have to enter them.
4. Place a shortcut in the Startup folder or in the operator's shell replacement. Add the /AUTO switch to skip the login dialog when single-sign-on is configured via Windows authentication.
5. Apply the screen tree permissions identically to the browser path. User groups in the WinCC User Administrator govern both clients; if the start screen is not assigned to the operator's group, the viewer returns the same "starting page cannot be found" message as the browser, which leads engineers to misdiagnose the workaround.

Why the Start Page Error Appears in WinCCViewer RT

If WinCCViewer RT is run on the same IE 11 workstation before any browser downgrade and the start screen is rejected, the cause is not the viewer - it is that the V12 SP1 server still routes the session through the WebNavigator ActiveX control that the local browser is supposed to host. The viewer is a thin shell. The fix is identical to Path A: either downgrade the browser or upgrade the project to a WinCC version whose viewer is self-contained. Do not chase the start-screen configuration through User Administrator > Web Start Page - that path is correct in the V12 SP1 project by default.

Configuration Steps for the Web Access Itself

Before the client can render any screen, three configuration layers on the server must be aligned. The following procedure has been validated against a V12 SP1 install on Windows 7 64-bit. Each step is required; skipping any one reproduces the original failure.

1. User and group. Open the WinCC User Administrator. Create a group named WebOperators. Open the group properties and set Web access to Granted. Add at least one user to the group; do not assign web rights to a user without the group, because group-level web rights override user-level in V12 SP1.
2. Web start page. In the same User Administrator, select the user (or group) and open the Web tab. Set Start screen to a screen that exists in the project and is marked Web-enabled. Set Start language to the operator's runtime language. Saving without a valid start screen is the most common reason for a "starting page cannot be found" message after a working login.
3. Compile and OS download. In the TIA Portal, right-click the WinCC RT and select Compile > Software (rebuild all). Then perform an OS download to the runtime PC. The OS download writes the WebNav.xml index that the server uses to enumerate published screens.
4. WinCC Web Configurator. Launch the configurator on the runtime. Confirm the IP address, port, and the directory path used for the WebNavigator web root. Default is C:\Program Files (x86)\Siemens\Automation\WinCC\WebNavigator\Server\web\. Click Start WebNavigator Service. The service SIMATIC WinCC WebNavigator must be in state Running.
5. Firewall. Open TCP port 80 (or 8080) inbound on the runtime for the client subnet. The Web Configurator will attempt to add the rule automatically on Windows 7; if the UAC prompt was declined, the rule is missing and clients will time out at the connect phase with no useful error.
6. Client install. From the client, run the WebNavigator Client setup that ships on the same V12 SP1 install media. The setup is mandatory even when WinCCViewer RT will be used, because the install registers the ActiveX control that the viewer shells out to.

Verification and Acceptance Test

After applying Path A or Path B, run the following checks in order. Each must pass before the next is attempted.

1. HTTP probe. From the client, open a command prompt and run curl -v http://<server>/WebNavigator/. The server must return HTTP 200 and an HTML payload containing the string WinCCWebClient. A 404 indicates the WebNavigator service is not running or the URL prefix is wrong.
2. User login. Launch the client and log in with the operator credentials. The toolbar and screen tree must appear within ten seconds. A successful login plus blank tree indicates that the user has web rights but no screens are assigned to the group; revisit step 2 above.
3. Start screen load. The configured start screen must load on first connection. Time the load - a healthy LAN round-trip is under two seconds. Latency above five seconds indicates the runtime is searching for the screen across multiple paths, which is the V12 SP1 fallback behavior when the WebNav.xml index is corrupt.
4. Tag updates. Click on a screen element bound to an external tag. The value must update on the configured acquisition cycle (default 1 s for WinCC Professional). If the value is frozen, the user is missing Authorization for tag access in the User Administrator.
5. Logoff and reconnect. Log out, close the client, and reconnect. The session must clear cleanly; a stale WinCC_<server>_<user>.tmp file in the WebNavigator temporary directory is a sign that the client was killed during a write and may need to be cleared manually on the server.

Long-Term Considerations and Upgrade Path

Internet Explorer 9 is itself end-of-life. New Windows 7 64-bit hardware no longer ships from OEMs, and the security exposure of pinning production HMI clients to IE 9 grows with every quarter. For systems that must remain on V12 SP1 for compatibility with the S7-300/400 and WinAC PLC lines, the recommended path is:

• Containerize the client. Deploy a Windows 7 64-bit image in a controlled VM or kiosk shell with IE 9 pinned and Windows Update restricted to security-only rollups. Disable the Internet Explorer 11 install promotion via Group Policy.
• Use WinCCViewer RT exclusively. Set the runtime to start the viewer with the /SERVER and /AUTO switches at shell startup, so the operator never launches the browser. This removes the IE dependency from the operator workflow while keeping the IE 9 install available for engineering.
• Plan the upgrade to a current WinCC version. V17 and later ship a self-contained WinCCViewer RT that does not require Internet Explorer at all. Migrate the project and rebuild the WebNavigator server on a Windows 10 or Windows Server 2019 host. The S7-300/400 PLC programs are forward-compatible - only the HMI project and the OS download need to be regenerated.

For mixed fleets where some operator stations run current Windows and some run legacy Windows 7, deploy the legacy stations as remote desktop sessions into a Windows Server 2019 terminal server running the current WebNavigator client. The operator's local machine then needs only the Microsoft RDP client, which is supported on every Windows release from Windows 7 SP1 forward.

Field Notes and Common Pitfalls

• User group vs. user web rights. V12 SP1 reads web rights from the group first. If the user has web rights granted individually but the group has web access denied, the runtime will not load any screen. Always set web access at the group level for clarity.
• 64-bit IE. Internet Explorer 11 on Windows 7 64-bit installs a 64-bit executable as the default. The V12 SP1 ActiveX control is 32-bit. Use the 32-bit IE (located in Program Files (x86)\Internet Explorer\iexplore.exe) to launch the client, even if the IE 9 downgrade is applied. Forcing the 64-bit binary reintroduces the CLSID registration failure.
• Start page misconfiguration. A common trap is to set the start screen on a user that is not a member of the configured group. The runtime checks the group membership before resolving the start page, so the error reads as "starting page cannot be found" even though the screen exists and is web-enabled.
• Antivirus quarantine of the ActiveX control. Some endpoint protection suites quarantine the CCActiveX.ocx file on first install, which causes a silent failure on the first browser launch. Add an exception for the WebNavigator install path before running the client setup.
• HTTP vs. HTTPS. V12 SP1 ships with self-signed certificates only. If the client is configured for HTTPS and the certificate is not imported into the client's Trusted Root Certification Authorities store, the browser shows a certificate error page that is indistinguishable from a compatibility error. Test the HTTP path first to isolate the variables.

Best Practices for New Deployments

1. Always verify the target browser against the official WinCC WebNavigator (RT Professional) documentation before commissioning.
2. Provision operator stations from a known-good Windows 7 SP1 64-bit image. Disable the IE 11 promotion in Windows Update and in Group Policy.
3. Deploy WinCCViewer RT as the primary client and document the IE 9 path as a fallback. This reduces the operator's exposure to the browser compatibility matrix.
4. Lock the WebNavigator service account and the Web Configurator port in the change management system. Any change to the service account invalidates all live sessions.
5. Run the verification suite (HTTP probe, login, start screen, tag update, reconnect) on every operator station at commissioning and re-run annually.
6. Plan a multi-year migration to a current WinCC version. The IE dependency will eventually be unsupportable on the Windows 7 image even with all workarounds applied.