Resolving VMware OS Client Download Failures and SQL Server Database Access Errors in PCS 7

In virtualized SIMATIC PCS 7 environments (such as running an OS Client inside VMware Workstation or ESXi with the OS Server hosted on the physical machine), when downloading the target client project and the transfer carries out all file copies but terminates with 'An error occurred while downloading to the target system. SQL server cannot access database', the failure is caused by Windows network share permission restrictions, virtual network adapter misconfiguration, or Microsoft SQL Server database attachment security lockouts. To resolve this, configure the VMware virtual network adapter to Bridged mode (VMnet0), verify identical Windows user accounts and passwords across host and VM, grant the local 'SIMATIC HMI' user group Full Control over the target shared directory, and ensure Simatic Shell is bound to the Terminal Bus adapter.

Architecture of OS Project Download and Remote SQL Database Attachment

In distributed SIMATIC PCS 7 architectures, deploying Operator Station (OS) Clients as virtual machines inside VMware environments is a standard, cost-effective engineering practice.

When an engineer initiates PLC > Download from SIMATIC Manager to deploy an OS Client project from the Engineering Station / OS Server host to the virtualized OS Client:
1. Network File Copy: The Engineering Station connects to the shared folder on the target VM (e.g., \\VM_OS_CLIENT\wincproj\) over Windows Server Message Block (SMB / port 445) and copies project files, graphics (*.pdl), and database files (<Project>.mdf and <Project>.ldf).
2. Remote Database Attachment: Once the files reside on the target disk, the ES issues a Remote Procedure Call (RPC / DCOM) to the WinCC Project Manager service on the target VM.
3. Local SQL Server Ingestion: The local WinCC database service on the VM instructs the Microsoft SQL Server instance (MSSQL$WINCC) to execute sp_attach_db, attaching the .mdf database into the local SQL Server catalogue.

If the file transfer completes successfully but the subsequent SQL database attachment call is rejected, the process aborts with the signature error:
$$\text{An error occurred while downloading to the target system. SQL server cannot access database.}$$

Root Causes of SQL Server Access Denials During VMware Transfers

The failure of Microsoft SQL Server to attach the transferred database inside a VMware virtual machine stems from four distinct configuration deficits:

VMware Network Mode (NAT vs Bridged): If the virtual machine is configured with Network Address Translation (NAT / VMnet8) or Host-Only (VMnet1), the VM resides on a private subnet behind a virtual router. While file sharing may work over outbound NAT, bidirectional RPC/DCOM and Simatic Shell multicast broadcasts fail, preventing SQL Server coordination.
NTFS and Share Security Permissions on Target Folder: The folder hosting the WinCC project on the VM must be shared with full permissions. Crucially, the local Windows service account NT SERVICE\MSSQL$WINCC (or SQLServer2008 group) requires NTFS Full Control permissions on the folder. If permissions are restricted, the SQL Server engine cannot open the .mdf file.
User Account and Password Desynchronization: In non-domain workgroup environments, the Windows user account logged into the Engineering Station must exist on the virtual machine with an identical username and identical password. If credentials diverge, Windows authenticates the connection as Guest, which lacks SQL administrative authority.
Simatic Shell Adapter Binding: If Simatic Shell inside the virtual machine is bound to an inactive virtual adapter rather than the physical bridged network interface, inter-station synchronization fails.

Step-by-Step Resolution and Network Configuration

To resolve target OS download failures and restore seamless project deployment to VMware clients:

Step 1: Configure VMware Virtual Network Adapter to Bridged Mode

In VMware Workstation (or vSphere Client), open the virtual machine settings.
Select Network Adapter.
Change the network connection from NAT to Bridged: Connected directly to the physical network.
Check the box Replicate physical network connection state.
Assign a static IP address to the VM on the identical subnet as the physical Terminal Bus.

Step 2: Configure Identical User Accounts and Group Memberships

On both the physical host and the virtual machine, ensure the logged-in user has the identical username and password.
Open Windows Computer Management (compmgmt.msc) > Local Users and Groups > Groups on both machines.
Verify that the user account is a member of:
- Administrators
- SIMATIC HMI
- SIMATIC NET
- SQLServer2008 (or corresponding version group)

Step 3: Configure Shared Folder and NTFS Security Permissions

On the virtual machine, locate the target project directory (e.g., C:\wincproj).
Right-click the folder and select Properties > Sharing > Advanced Sharing....
Enable Share this folder. Set Share Name to wincproj.
Click Permissions: Grant Everyone and SIMATIC HMI Full Control.
Select the Security tab (NTFS Permissions):
- Click Edit, then Add.
- Add the local group SIMATIC HMI and grant Full Control.
- Add the local SQL group or service account and grant Full Control.

Step 4: Configure Simatic Shell on Both Stations

On both the physical host and the virtual client, open Windows Explorer.
Right-click Simatic Shell in the navigation tree and select Settings....
Under Network Adapter, select the physical network card dedicated to the Terminal Bus.
Ensure Encrypted Communication settings match.
In Simatic Shell, verify that both the host and the virtual client appear in the network neighborhood.

VMware Virtual Client Configuration Parameter Matrix

The following matrix outlines the required settings for deploying virtualized OS Clients in PCS 7:

Configuration ParameterRequired SettingImpact When MisconfiguredVMware Network ModeBridged (VMnet0)NAT mode blocks bidirectional RPC and multicast broadcastsTerminal Bus IP AddressingStatic IP on same subnetDHCP addresses cause stale NetBIOS name resolutionTarget Share PermissionsSIMATIC HMI = Full ControlFile copy succeeds, but database attachment failsNTFS File PermissionsSIMATIC HMI = Full ControlSQL Server cannot open <Project>.mdf fileSimatic Shell AdapterBridged Terminal Bus NICOS stations cannot discover each other in Simatic ShellComputer Name in WinCCMatches VM Windows hostnameProject fails to activate; claims name mismatch

Verification

To confirm that the target OS download succeeds:
1. In SIMATIC Manager on the Engineering Station, right-click the OS Client object and select PLC > Download.
2. Select Entire project (or Changes only).
3. The download wizard initiates: Observe that file transfer progresses through 100%.
4. The final stage ('Attaching database to target SQL Server') executes without throwing the error.
5. A confirmation message displays: Download to target system completed successfully.
6. On the virtual client, open WinCC Explorer: The project opens cleanly, showing the local computer name with runtime operational.

Limitations and Operational Precautions

Observe the following engineering precautions:
- Do Not Sleep or Pause VMs During Download: Pausing or taking a snapshot of the virtual machine while a project download is actively streaming files will corrupt the SQL database structure.
- Dedicated Terminal Bus Network Card: Do not route Terminal Bus traffic and Plant Bus traffic over a single shared virtual network adapter. Maintain strict architectural separation between Plant Bus and Terminal Bus.
- Firewall Exceptions: Ensure the standard PCS 7 firewall rules are applied on the virtual machine by running the PCS 7 Security Controller utility (s7seccnx.exe).

Engineer FAQ

Why did the file copy work if permissions were wrong?

Windows SMB file copying uses the Windows user credentials of the connection, which had write access to the folder. However, attaching the database requires the local SQL Server service account (NT SERVICE\MSSQL$WINCC) to open the file. If NTFS permissions exclude the SQL service, attachment fails.

Can I use VMware Workstation for production OS Clients?

Siemens officially supports virtualization using VMware vSphere (ESXi) for production installations. VMware Workstation is widely used and approved for engineering, simulation, and training environments.

Why must VMware network be set to Bridged instead of NAT?

NAT creates a one-way routing barrier. While the VM can access the host, the host cannot initiate inbound RPC connections or receive Simatic Shell multicast broadcasts from the VM, which are required for database attachment.