Resolving PCS 7 Installation Network Unavailable Error in VMware

Problem Overview

Installing SIMATIC PCS 7 V7.0 SP1 inside a Windows XP SP2 guest running on VMware workstation or ESXi halts at the very beginning of the setup routine with the dialog "Network is not available". The installer terminates before any components are extracted, even though the Windows XP guest can ping physical Ethernet devices on the host's LAN. The same error appears with both VMware Workstation 7.x and older VMware ESX/ESXi 4.x hosts paired with a Windows 7 (64-bit) host operating system.

This symptom is unique to legacy PCS 7 versions (V6.x, V7.0, V7.0 SP1) whose setup bootstrap inspects the Windows network stack in a way that the newer Winsock LSP catalog inside VMware's virtual NIC driver chain can no longer satisfy. The error is not a TCP/IP reachability problem - it is a setup prerequisite gate that fails the moment Winsock catalog integrity or DHCP client service state cannot be verified.

Approved Virtualization Configurations for PCS 7

Before troubleshooting the legacy V7.0 SP1 install, validate that the planned virtualization platform is actually approved by Siemens. The PCS 7 Virtualization manual enumerates the supported hypervisors, host OS combinations, and guest OS combinations. Running PCS 7 outside this matrix may produce the same setup failure or, worse, an install that completes but fails field commissioning because of timer drift on virtual clock sources.

The SIMATIC PCS 7 Virtualization - Project Engineering and Configuration manual is the canonical reference for which ESXi build, which vSphere version, and which guest OS SKU is approved for each PCS 7 release. Always consult the version-specific entry before commissioning a virtualized PCS 7 system.

Root Cause Analysis

The "Network is not available" message during PCS 7 V7.0 SP1 setup is raised by the setup.exe bootstrap when it calls IsNetworkAlive() from the Win32 Internet API. That function inspects the Winsock catalog and the active network adapter bindings. If any of the following conditions is true inside the guest, the bootstrap fails the check:

1. Winsock LSP catalog is empty or corrupted. The VMware VMCI or vmxnet virtual NIC driver may not have registered an LSP on a clean XP SP2 install.
2. DHCP Client service is disabled or set to Manual. Windows XP defaults the DHCP Client to Automatic; VMware's NAT stack depends on it.
3. Network adapter binding order has only the MS Loopback at the top. The setup bootstrap enumerates GetAdaptersInfo() and rejects the call if the only enabled adapter is the loopback.
4. VMware Tools is not installed. Without VMware Tools the vmxnet driver is replaced by the legacy vlance or e1000 emulated NIC, which lacks Winsock registration hooks required by older PCS 7 setup routines.
5. Windows Firewall blocks the setup bootstrap's network probe. XP SP2 introduced the Windows Firewall on by default; the probe is rejected silently.
6. VMware NAT service on the host is stopped. If the guest NIC is in NAT mode and the VMnetNAT service has crashed, the guest loses its virtual DHCP lease and Winsock returns no live adapters.

The setup routine does not differentiate between these conditions; it simply reports "Network is not available" and exits. Each must be ruled out sequentially.

Pre-Installation Network Validation

Before re-launching the PCS 7 setup, validate the guest network stack from inside the XP SP2 console. Run the following commands in cmd.exe:

ipconfig /all
netsh winsock show catalog
net start | findstr /I "dhcp nlasvc"
ping 192.168.1.1

Expected results:

• ipconfig /all shows an IPv4 address, subnet mask, and default gateway on the virtual NIC (typically 192.168.x.x in NAT mode, host subnet in Bridged mode).
• netsh winsock show catalog lists at least one entry under Winsock Service Providers and one under Name Space Providers. An empty catalog indicates a corrupted Winsock install.
• net start | findstr "dhcp" returns DHCP Client with state Started.
• ping to the host default gateway returns four replies with sub-millisecond latency.

If netsh winsock show catalog is empty, reset the Winsock catalog with:

Reboot the guest after the reset. XP SP2 re-registers the base LSPs on next boot.

VMware Virtual Network Configuration

The PCS 7 V7.0 SP1 setup bootstrap is most reliable when the guest NIC is in Bridged mode and bound to a physical NIC on the host that has link. NAT mode introduces an extra dependency on the VMnetNAT user-mode service on the host, which can be a source of intermittent failure.

Recommended virtual NIC settings

To switch to Bridged mode in VMware Workstation 7.x: open VM > Settings > Network Adapter, select Bridged, choose the physical NIC from the dropdown, and confirm Connected and Connect at power on are both ticked. Power-cycle the guest so the NIC renegotiates DHCP.

If Bridged mode is not permitted by host policy

Some corporate networks disable promiscuous mode on switch ports, which prevents Bridged mode from receiving frames. In that case use NAT but explicitly verify the host-side service:

sc query "VMnetDHCP"
sc query "VMnetNAT"

Both services must show state RUNNING. If VMnetDHCP is stopped, start it:

net start "VMnetDHCP"
net start "VMnetNAT"

On Windows 7 hosts, VMware installs these services as VMnetDHCP and VMware NAT Service. If the latter is missing entirely, repair the VMware install via Control Panel > Programs > VMware > Repair.

Step-by-Step Resolution Procedure

1. Snapshot the guest. Before any change, take a VMware snapshot so you can roll back if the install corrupts XP SP2.
2. Install VMware Tools if not already present. From the VMware menu: VM > Install VMware Tools. Reboot the guest. This installs the vmxnet driver and the Winsock LSPs that the PCS 7 setup inspects.
3. Set the virtual NIC to Bridged mode. See the table above. Power-cycle the guest.
4. Verify an IP address. From the XP guest, run ipconfig /all and confirm a valid IPv4 address. If no address is present, run ipconfig /release && ipconfig /renew.
5. Reset Winsock if the catalog is empty. netsh winsock reset, then reboot.
6. Start the DHCP Client service. sc config dhcp start= auto && net start dhcp
7. Disable the Windows Firewall temporarily. Control Panel > Windows Firewall > Off. The setup bootstrap may otherwise drop its own probe packets.
8. Disable automatic updates in the guest. The XP wuauserv service can hold an LSP exclusive lock. Run sc config wuauserv start= disabled && net stop wuauserv.
9. Disable IPv6 on the virtual NIC. PCS 7 V7.0 SP1 setup does not bind to IPv6 and a stale v6 binding can suppress v4 detection. Uncheck Internet Protocol Version 6 in the NIC properties.
10. Re-launch the PCS 7 setup as Administrator. Right-click setup.exe > Run as. The setup bootstrap should now pass the IsNetworkAlive() check.
11. If the error persists, capture the setup log. Launch with setup.exe /log:"C:\Temp\pcs7setup.log" and inspect for HRESULT 0x800704CD (no network) or HRESULT 0x80070005 (access denied on the NIC key).

Alternative: Microsoft XP Mode

If the VMware path continues to fail, Microsoft Windows XP Mode is a free add-on for Windows 7 Professional, Enterprise, and Ultimate SKUs that runs a fully licensed XP SP3 image inside a Virtual PC-based hypervisor. It uses a different NIC stack (the legacy DEC 21140 emulated adapter) and the Winsock LSP chain is initialized from a clean XP SP3 base, which avoids the empty-catalog failure seen on freshly deployed XP SP2 VMware guests.

To deploy XP Mode:

1. Download and install Windows Virtual PC and Windows XP Mode from the Microsoft download center. Both packages are required.
2. Launch Windows Virtual PC from the Start menu.
3. Click Create virtual machine, allocate at least 1.5 GB RAM and 20 GB dynamic VHD.
4. Boot the VM, apply XP SP3 updates, and install PCS 7 V7.0 SP1.

XP Mode is acceptable for engineering and FAT (Factory Acceptance Test) but not for long-term runtime because Virtual PC lacks the vSphere management tooling required for production PCS 7 virtualization per the Siemens compatibility matrix.

Working Around the Bootstrap Gate

Two undocumented workarounds exist for legacy PCS 7 installers that refuse to proceed without a "live" network:

Workaround A: Add a route to a non-existent gateway

This forces GetAdaptersInfo() to return a default-gateway-bearing adapter even if the upstream is offline. The setup bootstrap sees a valid route table and passes the check.

Workaround B: Install offline from a mapped ISO

Mount the PCS 7 V7.0 SP1 ISO on the host, share the folder, map a network drive inside the guest, and run setup from the share. The setup bootstrap sometimes misclassifies a local CD-ROM as offline because the mounted virtual CD uses the VMware vmci channel rather than an emulated SCSI adapter.

Both workarounds are unsupported by Siemens and should be used only as last resorts when the engineering deadline does not permit a migration to PCS 7 V8.x or later.

Verification

After setup completes, verify the install with the following checks:

Confirm the Automation License Manager recognizes all licensed components before proceeding to project engineering. A clean license check is the strongest indicator that the install reached a usable state.

Troubleshooting Matrix

Migration Recommendation

If your project timeline permits, migrate to PCS 7 V9.0 SP1 or later running on a Siemens-approved VMware ESXi release. The V9.x setup routines are virtualization-aware, do not call IsNetworkAlive(), and ship with vSphere-optimized guest additions. The supported virtualization matrix in the PCS 7 Virtualization manual lists the exact ESXi build number, vCenter version, and Windows Server SKU combinations that have passed Siemens' validation testing. Operating outside this matrix may yield a working install today but expose the plant to unsupported behavior at the next PCS 7 update.

FAQ