Replacing a WinCC V7 Client: Simatic Shell Setup and Package Import

Swapping a failed WinCC V7 operator client in a distributed Engineering Station (ES) / Operator Station (OS) / Standby OS / Client topology is a routine lifecycle task, but it trips up integrators when the new client cannot find the configured WinCC server. The visible symptom is the runtime error Project Manager for configured WinCC server is not already running, raised by the WinCC Client when it tries to attach to its preferred server. The root cause is almost always a missing or stale server data package on the client combined with an unresolved NetBIOS name resolution chain (LMHosts + Simatic Shell) on the Windows network. This guide documents the complete field-proven procedure to commission a replacement WinCC V7 client end-to-end, from pre-checks through verification, with troubleshooting matrix and licensing caveats.

1. WinCC V7 Distributed Architecture Overview

A WinCC V7 system with multiple clients is a client/server model where the WinCC server holds the project, archive, alarm, and tag database, and the clients are passive viewers that load a server data package (a thin project stub generated on the server) at runtime. The client never contains the full engineering project; it contains only the configuration required to find the server and to render its assigned picture tree.

2. Prerequisites Before You Touch the New Client

Verify the following before commissioning the replacement client. Skipping any of these items is the most common cause of first-time failure.

1. Identical WinCC version. The replacement PC must run the same WinCC V7 SPx as the server (e.g., V7.4 SP1, V7.5 SP2). Mismatched service packs cause incompatible database structures and silent connection drops. Confirm with HKLM\Software\Wow6432Node\Siemens\Automation\WinCC\Version.
2. Matching Windows language and region. Mixed MUI installs between server and client can corrupt picture loading on non-ASCII tags.
3. Network in the same subnet/workgroup. All stations must share a common subnet; the Simatic Shell uses NetBIOS over TCP/IP. The recommended pattern is a dedicated terminal network with no routed hops between ES, OS, Standby OS, and Clients.
4. WinCC Client license present. Confirm a valid RT license (e.g., WinCC RT Client or the legacy WinCC V7 Client softkey/authorization) is installed on the replacement PC. Without it, Runtime starts in demo mode for one hour.
5. Firewall rules defined. The Windows Firewall on the replacement PC must allow the Simatic Shell / WinCC ports. See Siemens FAQ 868014 — Requirements for operating SIMATIC WinCC in a Windows network for the official port list (default: UDP 137/138, TCP 139, TCP 102 for S7, and the WinCC-specific TCP range).
6. Local administrator account. You must be able to edit %SystemRoot%\System32\drivers\etc\lmhosts and to install the WinCC Client software.
7. Source of the server data package. Either an exported *.bck/*.zip package from the ES, or the folder \<ServerName>\<ProjectName>\Packages must be reachable. In redundant systems, export from the preferred server.

3. Configure NetBIOS Name Resolution (LMHosts)

Simatic Shell on the client resolves the WinCC server by its NetBIOS name, not by its IP address. If DNS cannot resolve the server hostname (common on plant networks without AD), you must add static entries to the lmhosts file. This is the single most skipped step and the dominant cause of the "Project Manager not running" message.

1. Open notepad.exe as administrator.
2. Navigate to C:\Windows\System32\drivers\etc\lmhosts.sam as a reference. Create a new file at C:\Windows\System32\drivers\etc\lmhosts (no extension).
3. Add one line per WinCC server using the exact NetBIOS name used in the project. Example for a redundant pair OSSRV01 (preferred) and STBYSRV01 (standby):
   10.20.30.41 OSSRV01 #PRE
10.20.30.42 STBYSRV01 #PRE
   The #PRE suffix preloads the entry into the NetBIOS name cache at boot.
4. If the names exceed 15 characters, add a second alias column:
   10.20.30.41 WINCCSERVER WINCCSERV01 #PRE
5. Save the file. Do not append .txt. Windows hides known extensions, so confirm with dir /a in the directory.
6. Validate from a command prompt:
   nbtstat -c  →  should list OSSRV01 and STBYSRV01.
   ping %COMPUTERNAME% from the server to the client, and vice versa, must resolve by name.
7. On the new client, also add entries for the other clients and the ES so Simatic Shell browse works.

4. Activate Simatic Shell and Verify Station Visibility

Siemens FAQ 868014 defines Simatic Shell as the component that exposes WinCC stations to each other over the Windows network. After WinCC Client installation, Simatic Shell is present as a Windows Explorer namespace and as a shell extension.

1. Open Windows Explorer on the new client.
2. Navigate to This PC → right-click → Add a network location, or simply expand Simatic Shell in the folder tree (path: \\SIMATIC Shell).
3. If the shell is empty, the SIMATIC Shell DCOM/COM+ components are not registered. Repair with:
   cd "C:\Program Files (x86)\Siemens\Automation\WinCC\bin"
Regsrv32 SIMATICShellExt.dll
Regsrv32 SCCShell.dll
4. After registration, restart the SIMATIC Shell service and the Server Browser service:

net stop "SIMATIC Shell"
net start "SIMATIC Shell"
net stop "Computer Browser"
net start "Computer Browser"

5. Reopen Explorer and confirm you can browse the WinCC folder of OSSRV01 and STBYSRV01. If the entries are greyed out, the workstation's Server service is not running or the firewall is blocking TCP 139 / UDP 137-138.
6. Ping the server by its NetBIOS name:
   ping OSSRV01  — must respond with the IP from LMHosts.

5. Create the Project Stub and Import the Server Data Package

This is the procedure that the original integrator used to recover. It sidesteps the broken Project Duplicator path and rebuilds the client project cleanly from an exported package.

5.1 Generate the server data package on the ES (one-time)

1. On the ES, open WinCC Explorer and load the project.
2. Right-click the project node → Server Data → Create Server Data Package (or Project Duplicator → Create Package in V7.4 and earlier).
3. WinCC creates a folder under <ProjectPath>\<ProjectName>\Packages containing *.pck, *.pdl (compiled pictures), and the alarm/tag stubs. The file <Project>.pck is the master copy.
4. Copy the entire Packages folder to a USB stick or a network share accessible by the new client.

5.2 Recreate the client project locally

1. On the new client, open WinCC Explorer. If prompted, start a new single-user project of the same name as the original client project (e.g., PLANT_CLIENT3) on a local drive. This is a throwaway shell — its database will be overwritten by the imported package in step 2.
2. Close WinCC Explorer. Stop the WinCC Server and WinCC Client services so the database files are not locked:
   net stop "WinCC Server"
net stop "WinCC Client"
3. Copy the contents of the exported Packages folder into the new client's project folder, overwriting any stub files. The critical file is the *.pck package; copying it restores the list of preferred servers, picture tree assignments, and the connection parameters.
4. Edit the client's ServerList.cfg (if present) and verify it lists the correct preferred server order. Sample for redundant failover:
   [Servers]
OSSRV01=1
STBYSRV01=2
   The numeric value is the priority; 1 = highest.
5. Restart the services:
   net start "WinCC Server"
net start "WinCC Client"
6. Open the project in WinCC Explorer. The picture tree should re-populate from the imported package; if the tree is empty, the *.pck was not placed in the project root.

6. Start WinCC Runtime and Confirm Server Attachment

1. In WinCC Explorer, click Activate (or run WinCCStart.exe in the project folder).
2. Within ~10 seconds, the client must log Connection established to server OSSRV01 in the WinCC Diagnosis window. If you instead see Project Manager for configured WinCC server is not already running, return to Section 3 and re-validate LMHosts and Simatic Shell.
3. Force a tag subscription: open the diagnostics tag @ServerName; it must return the NetBIOS name of the attached server. Force a redundant failover by stopping the WinCC Server on OSSRV01; the client must reconnect to STBYSRV01 within the configured timeout (default 30 s).

7. Configure Auto-Start for the New Client

After verifying that the new client can connect on demand, configure it to launch WinCC Runtime automatically at Windows logon, which is the standard behavior for operator stations.

1. Open Computer Management → Local Users and Groups → create or identify the operator user (e.g., WinCCUser).
2. Open regedit as administrator and navigate to:
   HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
   Add a string value:
   Name: WinCCStart_PLANT_CLIENT3
   Data: "C:\Program Files (x86)\Siemens\Automation\WinCC\bin\WinCCStart.exe" "C:\Siemens\WinCC\PLANT_CLIENT3\WinCCExplorer.exe" /Activate
3. Alternatively, drop a shortcut to WinCCStart.exe into %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup. This is the safer approach for locked-down operator accounts.
4. Use control /name Microsoft.UserAccounts to disable password-protected screen saver and to set the operator account to auto-logon via control userpasswords2. This is the standard practice for unmanned operator stations.
5. Reboot and confirm that the client auto-starts, attaches to the server, and renders the picture tree without user intervention.

8. Licensing Notes When Upgrading to WinCC Professional (V14+)

If the project will eventually migrate to TIA Portal / WinCC Runtime Professional (V14 or later), the legacy WinCC V7 client license does not carry over. The replacement client must be relicensed.

• Legacy V7 client → V7 client: same license type; if you re-image the PC, transfer the authorization using the Automation License Manager (ALM). See Clients and servers (RT Professional) — WinCC for the V14+ licensing model.
• V7 client → RT Professional (V14+): purchase new WinCC RT Professional and WinCC Client for RT Professional licenses. Existing V7 licenses remain valid only for the V7 server they were attached to.

9. Troubleshooting Matrix

10. Verification Checklist Before Returning the Station to Production

1. Name resolution: nbtstat -c shows all WinCC server NetBIOS names; ping OSSRV01 succeeds from the new client.
2. Simatic Shell browse: All three servers (OS, Standby OS, ES) are visible and not greyed out.
3. Server attachment: WinCC Runtime logs Connection established to <PreferredServer> within 10 s of activation.
4. Tag subscription: The diagnosis tag @ServerName returns the expected server name.
5. Redundant failover: Stop the primary server; client reconnects to the standby within the configured timeout and continues without operator intervention.
6. Alarm acknowledgment: Trigger a test alarm; confirm the operator can acknowledge it from the new client and the entry is removed from the server's alarm log.
7. Archive visibility: The Tag Logging and Alarm Logging views are populated with historical data from the server.
8. Auto-start: Reboot the client; it must log on, activate WinCC, attach to the server, and render the start picture without user action.
9. License health: ALM reports the client license as valid and not in the warning period.
10. Backup included: Add the new client's project folder to the plant backup policy; document the change in the change log.

11. FAQ