Resolving the WinCC "Network is Not Available" Installation Error on VMware Workstation

Engineers deploying SIMATIC WinCC V7.x inside a VMware Workstation or Oracle VM VirtualBox guest frequently encounter the setup-time error The Network is not available. Do you want to reestablish the connection to the network immediately before the OPC Core Components sub-installer is launched. The dialog halts the setup even when the guest OS has a healthy bridged or NAT adapter, and reproducing the failure consumes the better part of a working day when the actual cause is a configuration choice unrelated to the adapter itself.

This reference documents both confirmed root causes, the correct VMware network topology for the WinCC installer, the .NET prerequisite that the Siemens setup relies on, and the verification procedure that proves a clean install.

1. Problem Summary

The error string is generated by the Windows Installer bootstrapper that wraps OPC Core Components Redistributable (x86). The bootstrapper performs a WinHttpSendRequest call during component registration; if the call returns ERROR_WINHTTP_CANNOT_CONNECT (12029) or ERROR_WINHTTP_TIMEOUT (12002), the user-facing dialog is displayed regardless of whether the network is actually functional.

2. Root Cause Analysis

Two independent root causes have been confirmed in field deployments. Either can trigger the dialog, and both can coexist.

2.1 Root Cause A — Setup Launched from a VMware Shared Folder

When the WinCC install media is copied into a VMware shared folder (e.g. \\vmware-host\Shared Folders\WinCC_Install\) and Setup.exe is launched from that UNC path, the MSI bootstrapper attempts to resolve the working directory over the VMware shared-folder mini-redirector. The redirector presents the path as an offline network resource during the early phase of msiexec execution. The bootstrapper interprets the redirector's slow response or the LANManager session negotiation as "network not available" and surfaces the dialog.

Symptom signature:

• Setup runs from E:\WinCC\ (a VMware shared folder mounted as drive letter) but not from D:\WinCC\ (a virtual CD/DVD drive with the ISO mounted).
• Setup completes on the same VM if the source is relocated to a local NTFS volume, even with the same network adapter topology.
• The dialog appears only when the path prefix is \\vmware-host\ or \\.\vmware-host\.

2.2 Root Cause B — .NET Framework 3.5 Not Enabled in the Guest

WinCC V7.0 SP2 through V7.4 require the .NET Framework 3.5 feature (which provides the 2.0/3.0 CLR) even on Windows 7 or later guests, because OPC Core Components and the WinCC Configuration Studio rely on the 2.0 CLR. Windows 7 ships with .NET 3.5 disabled by default, and VMware guests are no exception. The WinCC setup checks the registry key HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5 before launching OPC Core Components; if the key is absent, the bootstrapper prompts the user, but if the key is present with an incomplete install, the bootstrapper instead triggers the network re-establishment dialog while it tries to download a feature update from Windows Update.

Symptom signature:

• Fresh Windows XP SP3 or Windows 7 guest with no other Siemens software installed.
• No antivirus in the guest; .NET 3.5 never enabled via Control Panel.
• Dialog appears regardless of which network adapter type is selected.

3. Supported VMware Configuration

4. Prerequisites

1. A valid WinCC V7.x install ISO built from the Siemens Automation License Manager or downloaded from the Siemens Industry Online Support portal.
2. VMware Workstation Pro or Player installed on the host.
3. A Windows XP SP3 or Windows 7 SP1 guest with at least 4 GB RAM and 60 GB disk, fully patched.
4. Local Administrator rights inside the guest.
5. The 24-character product key for WinCC RT (visible in ALM under "WinCC Runtime").
6. Hostname of the guest set to a NetBIOS-compatible string (15 chars or fewer, no hyphens in the first character).
7. Static IP address assigned if the runtime will be addressed by STEP 7 or a customer HMI panel.

5. Step-by-Step Resolution

5.1 Mount the ISO Instead of Using a Shared Folder

1. Power off the guest.
2. In VMware Workstation, open VM > Settings > CD/DVD (SATA).
3. Select Use ISO image file and browse to WinCC_V7.0_SP2.iso on a host NTFS volume that is not mapped as a VMware shared folder.
4. Tick Connected and click OK.
5. Power on the guest and verify Windows Explorer shows the ISO as drive D:\ (or the next free letter).

5.2 Disable VMware Shared Folders for the Session

1. In VMware Workstation open VM > Settings > Options > Shared Folders.
2. Set Folder Sharing to Disabled for the duration of the install.
3. Confirm with net use in the guest that no \\vmware-host\ mapping exists.

5.3 Configure the Virtual Network Adapter

1. Open VM > Settings > Network Adapter.
2. Select Bridged: Connected directly to the physical network.
3. Tick Replicate physical network connection state if the host moves between wired and wireless networks.
4. (Optional) Add a second adapter as NAT if Windows Update is needed for .NET 3.5.
5. From inside the guest, run ipconfig /all and confirm an IPv4 address on the same subnet as the host.

5.4 Enable .NET Framework 3.5 Inside the Guest

This step is the most frequently missed and is the reason some engineers see the same dialog even after switching to ISO install.

Windows 7 SP1 guest:

1. Open Control Panel > Programs and Features.
2. Click Turn Windows features on or off.
3. Tick .NET Framework 3.5 (includes .NET 2.0 and 3.0).
4. Click OK. If prompted, choose Download features from Windows Update.
5. Verify with reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" /v Install. Expected output: Install REG_DWORD 0x1.

Windows XP SP3 guest (offline):

1. Insert the Windows XP SP3 installation CD as a second ISO.
2. Open cmd as Administrator.
3. Run D:\dotnetfx35.exe /x:%TEMP%\net35 (extract to a temp folder).
4. Run msiexec /i %TEMP%\net35\wcu\dotNetFramework\dotNetFx35setup.exe /lang:ENU /norestart if a full redistributable is supplied, or copy dotnetfx35.exe from the Windows XP installation media if available.
5. Confirm with reg query "HKLM\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" shows the Install value of 1 and a Version of 3.5.30729.1 or later.

5.5 Disable Host-Side Real-Time Scanning of the Install Tree

1. On the host, open the antivirus console (ESET, Kaspersky, Defender, or third-party).
2. Add the folder containing the ISO to the real-time exclusion list.
3. Optionally, temporarily disable the real-time shield for the duration of the install.
4. Reboot the host to ensure the new exclusion path is loaded into the filter driver.

5.6 Begin the WinCC Installation

1. Inside the guest, browse to the mounted ISO drive.
2. Right-click Setup.exe and choose Run as Administrator.
3. Select Package Installation (not "Custom Installation") if only the WinCC runtime is required.
4. When the product selection dialog appears, tick WinCC Installation only and clear all other options such as WebNavigator, DataMonitor, or Connectivity Pack unless licensed.
5. When the OPC Core Components sub-installer starts, the previously failing dialog will not appear; the progress bar will complete without user interaction.
6. Continue through the WinCC Configuration and SQL Server 2008 R2 / 2014 prompts.
7. Transfer the WinCC RT license from ALM at the end of the install.

6. Verification Procedure

1. Open WinCC Explorer and load a sample project such as MyProject.MCP from C:\Program Files\Siemens\Automation\WinCC\WinCC Projects\.
2. Press the Activate button (the green traffic light) and confirm Runtime starts without OPC red-banner errors.
3. Open All Programs > Siemens Automation > SIMATIC > WinCC > Tools > WinCC Diagnosis.
4. Verify no yellow or red entries in Connections, Tags, or Alarms.
5. From the host, run winrs -r:<guest> -u:<admin> "reg query \"HKLM\SOFTWARE\Siemens\Automation\WinCC\" /v Version" and confirm a version string such as 7.0.2.0 is returned.
6. Reboot the guest twice in a row; WinCC Runtime must auto-start on both boots without manual intervention.

7. VMware Network Adapter Reference

For Step 7 + WinCC to communicate with a real S7 PLC over PROFINET, the bridged adapter must map to a wired Ethernet port on the host, not the Wi-Fi MAC, because PROFINET discovery uses Layer 2 multicast and most Wi-Fi drivers strip LLDP frames.

8. Installation Source Method Comparison

9. .NET Framework 3.5 Activation Detail

The WinCC V7.0 SP2 setup calls MsiGetProductInfo on the {2BC7B5F4-8C2D-4B9C-9C5E-3A2E1E2F1A3B} product code (placeholder; check your ALM for the actual GUID) to verify .NET 3.5 SP1 is installed. If the call returns ERROR_UNKNOWN_PRODUCT, the OPC bootstrapper initiates a feature-on-demand request over WinHTTP. With the VMware bridged adapter, this succeeds and the install proceeds. With NAT, it succeeds only if Windows Update is reachable. With Host-only or no network, it fails and produces the dialog.

The dism /online /enable-feature /featurename:NetFx3 /all /source:D:\sources\sxs command-line path is the most reliable for Windows 7 SP1 and Windows Server 2008 R2. For Windows XP SP3, .NET 3.5 must be installed from the XP redistributable or the WinCC install media, not from Windows Update (XP is out of mainstream support and the update channel is closed).

10. Troubleshooting Matrix

11. Common Pitfalls

• Assuming a network adapter change will fix the dialog. The bridged/NAT/host-only switch has no effect on root cause A (shared folder) and only a partial effect on root cause B (missing .NET 3.5 with NAT or no network).
• Re-enabling shared folders after Step 7 is installed. Some users disable shared folders for the WinCC install, then turn them back on. If the same VM is later used to add a redundancy partner or a WinCC/Connectivity Pack, the original dialog returns for the new sub-installer. Keep shared folders disabled for the full lifecycle of the project.
• Using a USB-Wi-Fi adapter for the bridged network. USB passthrough creates a separate virtual NIC that does not participate in the host's ARP table. Some PROFINET discovery tools will not see the S7 PLC.
• Installing .NET 4.x first and assuming 3.5 is covered. .NET 4.x is a separate CLR. WinCC V7.0 SP2 through V7.4 require the 2.0/3.0/3.5 CLR. They are side-by-side, not supersets.
• Skipping the host reboot after changing the antivirus exclusion. Some filter drivers (notably ESET's eamonm) do not reload their exclusion tables until the next boot, so the first install attempt after the change still fails.
• Using an ISO that was downloaded over HTTPS but extracted with a third-party tool that strips the UDF filesystem markers. WinCC ISOs are authored as UDF; tools that misinterpret them as ISO 9660 will produce a copy that the setup sees as corrupt. Use the original .iso and mount it natively with VMware Workstation's CD/DVD device.

12. Compatibility Notes for Newer WinCC Versions

For WinCC Runtime Unified (TIA Portal V16 and later) the install path is different: the setup is launched from the TIA Portal installation media and the .NET requirement is .NET Framework 4.7.2 or later plus .NET 6 for the Unified runtime. Refer to the TIA Portal V21 installation guide for WinCC Runtime Unified for the exact matrix. The shared-folder caveat from this article still applies: do not launch the Unified setup from a \\vmware-host\ path.

For Windows 11 24H2 hosts, verify the VMware Workstation build supports the WinCC install media. VMware Workstation 17.5.1 or later is recommended; older 17.0 builds may fail to power on the guest with an "Internal Error" when the WinCC Runtime service is registered.

13. Long-Term Hardening for Engineering Workstations

1. Create a base Windows 7 SP1 x64 VM with .NET 3.5 pre-enabled, sysprepped, and converted to a template (.vmtx).
2. From the template, deploy a new VM for each WinCC project, mount the ISO from the network share, and never copy the install media into the VM disk.
3. Use bridged networking on a wired Ethernet port and assign a static IP that is reserved in DHCP.
4. Snapshot the VM immediately after the WinCC install completes, before the project is loaded, to provide a known-good rollback point.
5. Document the VMware Workstation build, the host OS build, the guest OS build, and the WinCC SP in the project folder so future migrations are reproducible.