PCS 7 V7.0 Windows 10 Migration OS Upgrade Paths and VMware

1. Problem Statement: PCS 7 V7.0 Locked to Windows XP

A single-station or redundant PCS 7 V7.0 Operator Station (OS) originally commissioned on Windows XP Embedded/Professional cannot be lifted to Windows 10 by a simple in-place OS upgrade. The PCS 7 V7.0 installation media, runtime components (WinCC Explorer 7.0, SQL Server 2005/2008, BATCH API, Route Control, OpenPCS 7), and the OS project itself are bound to the Windows XP / Windows Server 2003 R2 platform contract that was published in the PCS 7 V7.0 Readme and Siemens Support Entry 51401737. Windows 10 introduces NTFS permissions, UAC, driver signing, .NET 4.x, and SMB/CIFS dialects that break the V7.0 install path, the WinCC services, and the AS-OS coupling DLLs.

Field engineers face three realistic escape paths:

1. Full project migration to PCS 7 V9.0 SPx or V9.1 (the first version officially released for Windows 10 / Windows Server 2016 / 2019).
2. Keep PCS 7 V7.0 and lift only the host hardware/OS through a VMware virtualisation layer (PCS 7 V7.0 + XP is not virtualization-released, but V7.1 SP2 and later are).
3. Hybrid path: keep V7.0 on a virtualised XP image while rebuilding the OS long-term on a separate, current V9.x station.

2. Why a Direct In-Place Upgrade Fails

Net effect: attempting setup.exe /upgrade on a V7.0 install over a Windows 10 host leaves the SQL databases unmounted, the WinCC services unregistered, and the project editor unlicensed. The only safe exit is to rebuild the OS runtime on a supported code line.

3. PCS 7 Release Map and Virtualization Eligibility

The following matrix is the operational reference for any engineer evaluating a Windows 10 lift on an existing plant. The "Virtualization" column is taken from the official Siemens PCS 7 Readme/Compatibility Tool; it lists which code lines Siemens has performance-validated under VMware hypervisors.

4. Path A - Full Project Migration to V9.0 / V9.1

This is the only Siemens-supported route to land on Windows 10. The migration is a project conversion, not a runtime patch. The PCS 7 Engineering Tool (ES) handles the conversion; the OS runtime must be rebuilt and the AS firmware must be on a compatible SIMATIC S7-400 / S7-400H firmware level that V9.1 will accept.

4.1 Prerequisites

• Original V7.0 ES project fully backed up (multi-project database + global libraries + master data library).
• AS firmware: SIMATIC S7-400 CPU 410-5H or 416-3 with FW V6.0 or later (required for V9.x). CPUs below V6.0 must be firmware-upgraded first or replaced.
• PCS 7 V9.1 installation media (or V9.0 SPx for Windows 10 LTSB 2015 hosts).
• PC station hardware certified for PCS 7 V9.1 (see Siemens SIMATIC PCS 7 Compatibility Tool).
• Microsoft SQL Server 2014 SP2 (default) or 2016 for V9.0; SQL 2017/2019 for V9.1.

4.2 Migration Sequence (high level)

1. Open the V7.0 multi-project in the V9.x ES using the Project Migration Wizard. The wizard re-compiles S7 programs against the V9.x system data blocks (SDBs) and re-builds the CFC/SFC charts.
2. Run the included Migrator for PCS 7 V7.0 to V9.0 (entry 109751706 on Siemens Support) to port the OS pictures, archive tags, and user administration. Verify the resulting *.pdl count vs. the V7.0 baseline.
3. Re-link the OS server to the AS using the new AS-OS Engineering interface. Confirm the OPC.SimaticNET tunnel is reachable on TCP port 135 plus dynamic DCOM range 49152-65535.
4. Rebuild the OS runtime. Do not attempt to lift the V7.0 WinCCProject.7.0 onto V9.1; runtime files are not forward-compatible.
5. Recompile BATCH and Route Control if licensed.
6. Download the AS program. Cycle the AS in run once to let the new SDBs load, then verify redundancy on the H-system.

5. Path B - Virtualizing the Existing V7.0 Station

If the customer cannot justify a V9.x migration budget immediately, virtualization keeps the working V7.0 runtime alive on modern server hardware while the migration project is scheduled. The XP license is brought into the VM, the image is P2V'd, and the VM is hosted on a Windows 10 or Server 2016/2019 host.

5.1 Architecture Decision: Workstation vs. ESXi

For a single-station plant (one AS, one redundant OS pair is not in scope), VMware Workstation on a Windows 10 host is the lower-cost option: license is ~200-300 EUR per host, no extra server hardware, and the VM can be set to auto-start with the host. ESXi only pays off when the customer needs vMotion, centralised backup, or HA across two physical hosts.

5.2 Hardware Sizing for the V7.0 VM

The original XP station is typically an IPC547C/647C with 4 GB RAM and a dual-core CPU. A V7.0 OS runtime, including SQL Server 2008 R2, WinCC, OPC, and ~500 pictures, will run comfortably inside the following VM envelope:

6. Step-by-Step: P2V of a V7.0 OS Station into VMware Workstation

6.1 Prerequisites

• VMware vCenter Converter Standalone 6.2 (free, last XP-compatible release) installed on the source PC or on a third host that can reach the source over the network.
• Source PC backed up; PC shutdown scheduled.
• Target host: Windows 10 21H2 LTSC (or later) with VMware Workstation 16.x installed and licensed.
• Plant network port available for the VM (same VLAN as the AS).

6.2 Procedure

1. On the source PC, install VMware vCenter Converter Standalone 6.2 as a local agent. Accept the default credentials (the local admin of the source).
2. From the Windows 10 host, run Convert Machine with these inputs:
   • Source: This local machine or A remote machine using the source admin.
   • Destination: VMware Workstation 16.x on the Win10 host.
   • Data to copy: select Volumes to copy; exclude the page file and hibernate file.
   • Disk layout: thin-provisioned VMDK, SCSI virtual controller.
3. Power off the source PC when the P2V finishes. The resulting .vmdk + .vmx files are stored in the Workstation library.
4. Edit the VMX to set:
   • ethernet0.virtualDev = "e1000" (default for XP).
   • usb.generic.allowHID = "TRUE" so the license dongle is passed through.
   • monitor_control.restrict_backdoor = "TRUE" if anti-virus in the host is fighting time sync.
5. Boot the VM. Inside the guest, run vmwaretoolssetup.exe (Tools ship with Workstation 16.x and still install under XP). Confirm VMware SVGA II driver is loaded.
6. Re-attach to the AS: open WinCC Explorer on the VM, edit the Server-Data package, retype the AS IP, and re-download. Confirm green status in the Channel Diagnosis applet.
7. Schedule the VM to auto-start with the host: create a Windows Task Scheduler entry that runs "C:\Program Files (x86)\VMware\VMware Workstation\vmware.exe" -x "D:\PCS7_V70\PCS7_OS.vmx" at system start, running as a service account with Log on as batch job.

6.3 Verification

• WinCC Graphics Runtime starts within 45-60 s after VM boot.
• OPC tunnel to the AS reports OPC quality: good on at least one tag in the OPC Scout test panel.
• Tag logging is writing to C:\PCS7\OS\Archive\<DBName>.ldf with a 1 Hz scan rate.
• Redundant OS partner (if present) is in Standby and synchronises on the first event.

7. Step-by-Step: P2V of a V7.0 OS Station into VMware ESXi

7.1 Prerequisites

• ESXi 6.7 U3 (or 7.0 U2) installed on a server-class host with VT-x and AES-NI enabled in BIOS.
• vSphere Client 7.0 connected to the host (or vCenter 7.0 if a cluster is used).
• VMXNET3 supported in the guest OS - Windows XP needs the VMware Tools for Windows XP package; for long-term support prefer E1000 NIC driver in the VM.
• ESXi license covering at least Standard (2-socket bundle). Production PCS 7 OS servers on vSphere typically use Enterprise Plus to enable vMotion for OS server patching without downtime.

7.2 Procedure

1. P2V with vCenter Converter Standalone, choosing VMware Infrastructure as the destination and pointing at the ESXi host (or vCenter). The Converter uploads a temporary helper VM and copies the disks at block level.
2. On the resulting VM, attach a second VMDK on a separate SCSI controller for the WinCC archive volume. Set the disk mode to Independent - Persistent so vSphere snapshots do not corrupt the SQL transaction log.
3. Set the VM options:
   • VM version: 13 (ESXi 6.5 compatibility) for the widest guest support matrix.
   • Firmware: BIOS (not UEFI) - XP cannot boot UEFI.
   • CPU: 2 vCPUs, hot-add disabled.
   • Memory: 4 GB, no over-commit.
4. Install VMware Tools (Windows XP flavor) inside the guest. Re-activate the Windows XP license; reactivation is normal and does not invalidate the OEM key.
5. Configure the auto-start: ESXi host > Manage > System > Autostart > Edit. Set the V7.0 OS VM to start with a 30 s delay and a 60 s wait between guest start and the next VM.

8. AS-OS Coupling Over the VM Network

The most common failure mode after a P2V is the AS-OS connection dropping once an hour. The root cause is SMB1 being disabled in the Windows 10 / Server 2016 host kernel, even when the VM itself is XP. The fix is in the VM, not the host:

• Inside the XP VM, confirm net view \\\<AS_IP\> returns the S7 share.
• If the host has SMB1 disabled, ensure the VM's network adapter is on a private VLAN or a dedicated NIC bridged to the plant network, not on a virtual NAT that the host inspects.
• Use a static IP on the VM's NIC; do not rely on the host's DHCP relay.
• Disable Windows Firewall on the XP guest, or open TCP 135, 49152-65535, and UDP 137/138 explicitly.

9. License, Cybersecurity and Audit Implications

• Windows XP license: P2V'ing an XP image does not consume a new license; the original OEM key reactivates. Re-activation may need a phone call to Microsoft (no online activation server for XP since 2014).
• SIMATIC license: The CodeMeter dongle binds to the USB port, not the VM. The license server (CoDeSys, WinCC License Server) must be reinstalled on the VM and the dongle mapped via USB passthrough.
• Cyber security: XP is past end-of-support. The customer must isolate the VM on the plant network with a stateful firewall, restrict outbound internet, and apply the Siemens PCS 7 Security Configuration Guide for the ES and OS, even though the V7.0-specific Windows hardening baselines are no longer updated by Microsoft.
• Audit trail: For ISA 99/IEC 62443 sites, the deviation note ("V7.0 OS run on an unsupported hypervisor, scheduled migration by <date>") should be filed in the plant cybersecurity register.

10. Risk Matrix and Field-Proven Caveats

11. Cost Comparison (Indicative, Western Europe, 2024)

The full migration to V9.1 dominates the budget but eliminates the long-term XP risk. The Workstation route is the lowest-cost bridge but should be treated as a 6-24 month tactical measure, not a permanent state.

12. Verification Checklist Before Sign-Off

1. AS-OS connection green for at least 24 h continuous operation.
2. Tag archive file size growing at the expected rate (1-10 MB/day typical for a small plant).
3. Alarm log writing to disk, audible alarm sound device functional in the VM.
4. Time sync verified - drift < 1 s/day.
5. Redundancy partner: failover test executed, standby takes over within 4 s, primary returns to standby without operator intervention.
6. Cyber: outbound internet blocked at firewall, USB storage devices blocked by group policy in the VM, audit log enabled on the host.
7. Backup: vSphere (or Workstation) snapshot taken with WinCC services stopped, then SQL transaction log re-backed up via WinCC maintenance.