Fix WinCC Unified kiosk mode stuck on establishing connection

Why does WinCC Unified kiosk mode hang at Establishing connection?

The hang happens because the configurator cannot open its HTTPS session to the runtime on port 443. On a terminal where a browser already loads the screens, the cause is almost always a mismatch between the configurator release and the runtime release.

Give the status a fair window before you call it a hang: a normal connection settles within 60 seconds. A status still on that same connecting message after 2 minutes is a failure, not slowness.

Three symptoms tell you where you stand:

• The screens load in a browser on the terminal, by name and by IP address. The runtime is serving the project, so the transfer and the runtime are fine and the problem sits in the configurator's session.
• The server configuration stays at "Establishing connection" for more than 2 minutes. The configurator's session is not being accepted; work through the version rule first, then the port check.
• The kiosk screen never appears at boot. Kiosk start is tied to a valid runtime connection in the documentation, so anything that blocks the connection blocks the kiosk too.

The configurator reaches the runtime over the same address your browser uses. When the browser works and the configurator does not, the address and the port are right, which puts the release pairing first in line.

Station Configurator kiosk or browser kiosk: which one should you use?

Use the Station Configurator's kiosk mode for a fixed operator terminal. It is a documented kiosk environment for the PC Runtime that starts the screens full screen at system start, with no browser address bar, update pop-ups or login prompts in the operator's way.

For a terminal bolted to a machine or a wall, the configurator route wins on every practical point. At system start the runtime comes up in kiosk mode on the device the configuration names, with no desktop and nothing for an operator to close. The browser kiosk profile is the fallback for a general-purpose PC where you cannot install runtime components. You point a browser profile at the runtime address and let the operating system lock the shell. That route carries the browser's own problems with it: update pop-ups, session expiry, and app assignment quirks of the kind described in why an app is missing from a Windows 10 kiosk profile. Page fit becomes your problem too, as content cut off at the bottom of a kiosk screen shows. Pick the configurator route whenever you control the software on the terminal.

Which versions have to match before the configurator will connect?

Three versions must sit on the same release and the same update level: the PC Runtime on the terminal, the Station Configurator, and the project. A V19 runtime takes the V19 configurator with its latest update installed.

The kiosk setup pairs each configurator release with its own runtime release, and it expects the update levels to line up as well. A V20 configurator against a V19 runtime is an unsupported pairing. Installing a V21 configurator on top will not cure a V19 runtime either. Move the configurator to the runtime's release, then bring it to the runtime's update level; for a V19 runtime with the current updates applied, that is the V19 configurator with update 3.

Read the versions before you touch anything. The project release shows in the engineering tool's project properties. The runtime release shows both on the runtime's info page and in the installed-program list. The pattern is the same one behind matching the installed build before an HMI software upgrade: know exactly what is installed before you add software next to it.

How do you check and free port 443?

Run the browser test first, then list every listener on the port with netstat. The process ID in the last column tells you whether the runtime owns port 443 or another program does.

Open a browser on the terminal itself and load the runtime address over HTTPS. If the screens appear, the runtime owns port 443 and the port is not your problem; go to the version rule. If the browser fails too, find the holder:

netstat -ano | findstr :443

TCP    0.0.0.0:443    0.0.0.0:0    LISTENING    4

That output is typical, shortened. A 0.0.0.0:443 line in the LISTENING state with a process ID of 4 is the Windows HTTP kernel driver, which means an IIS binding is holding the port. Open IIS Manager, walk the Sites tree to the site with an HTTPS binding on 443, and either stop that site or move its binding to a free port such as 8443. The runtime keeps 443. A documented case of the same shape is a port 443 conflict between WinCC Unified and a virtualization host service, where the host service had to give up the port. Any other process ID can be matched to a name on the Details tab of Task Manager. If the conflicting site belongs to another application the plant still needs, move that site's binding; never delete a site to win one port.

Example: how do you get a V19 panel from stuck to kiosk?

A V19 project on a V19 runtime loads its screens in Edge by IP address while the V20 configurator sits at the connecting status without getting through. The mismatch is the arithmetic, 20 against 19, and the fix is the matching V19 update package.

Situation: the project was built in V19, the runtime on the industrial PC is V19, and Edge on the terminal loads the screens at the runtime's IP address on port 443. The Station Configurator is V20 and its server configuration sits at "Establishing connection".

1. Read the three versions: project V19, runtime V19, configurator V20. The arithmetic: 20 against 19 is an unsupported pairing.
2. Remove the V20 configurator and install the V19 package with the update applied, SIMATIC_WinCC_Unified_Station_Configurator_V19_Upd3.exe. Re-enter the server configuration and retest. The status should leave "Establishing connection" within 60 seconds and reach connected.
3. If the status had stayed at "Establishing connection" past 2 minutes, the browser test decides the branch: screens still load means the update levels are still out of line, so align the configurator's update level with the runtime's; screens do not load means port 443 is held elsewhere, so run the netstat check and rebind the offending IIS site to 8443.
4. Add the Kiosk configuration, aim it at this terminal in Client settings, and reboot. The runtime starts in kiosk mode at system start.

Result: the operator terminal boots straight into the screens, with configurator and runtime on the same V19 update level and port 443 reserved for the runtime.

How do you configure kiosk mode once the connection is valid?

Once the configurator shows the runtime connected, add the Kiosk configuration in the Station Configurator, set the device it applies to under Client settings, and the PC Runtime then starts in kiosk mode at every system start.

You open the configurator from the PC station in the engineering environment with "Open Station Configurator", then work through its "Runtime Settings" section. Add the "Kiosk" configuration: it decides whether the runtime runs in kiosk mode on the device named in "Client settings", which is where you point the configuration at this terminal. The manufacturer's kiosk mode configuration guide in its support portal walks through the install and the settings screen by screen.

Starting kiosk mode requires a valid connection, and the Station Configurator documentation for starting kiosk mode describes the script call EnterFullScreen() that brings the running runtime into the full-screen kiosk view. In practice: get the server configuration connected, save the kiosk settings, reboot, and the screens come up full screen with no browser in the way.

What do you check when it still will not connect?

Work down three causes in order, each with its own test: an update level that does not match, another process holding port 443, or a runtime that is not serving the project at all.

1. Update level. The configurator is the right release but an older update level than the runtime. Test: compare the configurator's update level with the runtime's. Fix: install the matching update package, such as the V19 update 3 build against an updated V19 runtime.
2. Port 443. Another program or an IIS binding holds the port. Test: the browser on the terminal fails to load the screens, and netstat -ano | findstr :443 names the holder as the LISTENING line's process ID. Fix: stop or rebind the holder, keep 443 for the runtime, retest.
3. Runtime not serving. The project never loaded or the runtime is stopped. Test: no listener on 443 and no screens in the browser. Fix: start the runtime and confirm the project transfer from the engineering PC.

Each test separates one cause from the next, so you always know which line you are on.

Recommendation: for a dedicated operator terminal, install the Station Configurator release that exactly matches the installed runtime, with its latest update, and keep port 443 for the runtime; use a browser kiosk profile only on a general-purpose PC where runtime components cannot be installed. Judge every connection attempt against the 60-second window before you move to the next cause. Once the terminal is up, a separate screen for shift notices or line status beside it is a job for shop-floor signage, and the same version discipline applies to every piece of software you add to that terminal.

Questions