Resolving WinCC OS Station Download Access Denied Errors

Problem Description

When a SIMATIC WinCC V7 project is downloaded from the Engineering Station to a runtime PC Station, the OS startup sequence aborts with an “Access is Denied” dialog referencing the Microsoft SQL Server instance that hosts the WinCC runtime database. The error is emitted at the beginning of runtime initialization, before any operator screen renders, and it reproduces on every PC Station of the network, not only on the PC the engineer is using. Each PC can still open and run a locally created project without fault, which proves that the failure is specific to the project-distribution path from the ES rather than to the WinCC installation on the targets.

The same “Access is Denied” symptom is also reproduced after relocating the project folder, creating a brand-new project root, or changing the download target path. This pattern rules out a simple file-permission problem on the storage folder and points instead to a project-server identity mismatch inside the WinCC project metadata.

Affected Versions and Components

The configuration described in the source reproduces on WinCC V7 engineering and runtime environments when the project tree contains a PC Station whose name does not match the Windows computer name of the target machine. The component matrix is summarized below. Reference the Siemens Industry Online Support portal for current WinCC Readme and compatibility lists.

The fault is independent of whether the underlying project is single-user, multi-user, or distributed. The error only appears after the project has been downloaded from an ES that does not share the same computer name as the PC Station entry in the WinCC project tree.

Root Cause Analysis

WinCC embeds a server-name token inside every project to identify which SQL Server instance holds the runtime database. The token is set in WinCC Explorer via the Properties dialog of the PC Station node and reflects the Windows computer name (or the fully qualified domain name) of the OS host. When WinCC runtime starts, it asks the local SQL Server to attach the database by calling that name. If the name does not resolve to the local machine, the SQL client fails to log in using integrated Windows authentication, and the user sees “Access is Denied” before any operator screens render.

Three contributing root causes are commonly found on WinCC V7 systems that present the symptom described in the source.

1. PC Station Name Mismatch (primary cause)

If the WinCC project tree contains a PC Station named “Stand Alone Client” while the ES is configured under “Engineering Station”, the engineering download propagates the project with the Stand Alone Client computer name as the target server identity. On the local machine, WinCC then references a server whose name does not resolve to itself. The Kerberos / NTLM handshake cannot complete because the requested server principal is unreachable, and the SQL Server login returns an “Access is Denied” exception during project attach.

2. Insufficient User Rights on the Project Folder (secondary cause)

If the user accounts, passwords, and share permissions on the WinCC project folder are inconsistent across PCs, the OS load routine cannot read the project files even when the SQL connection succeeds. The administrators group and the special user group “SIMATIC HMI” must hold full control of the project root folder, and the share must be accessible with identical credentials from every station.

3. Missing SIMATIC NET Installation or Station Configuration Download

If SIMATIC NET is not installed on the OS, the Station Configuration Editor data is empty, and the OS does not have an S7 connection point. The yellow up-arrow icon on the ES in WinCC Explorer indicates the PC Station is in a modified state and requires its configuration to be downloaded. Until this is done, any project download to the OS fails because the WinCC server module has no configured interface.

Recognition in the WinCC UI

Inspect the yellow up-arrow next to the PC Station icon in WinCC Explorer on the ES. A modified station shows this icon, indicating that the local Station Configuration Editor on the target has not been re-synchronized with the latest ES configuration. Open the Windows share \\OS_PC\WinCC_Projects on the ES and verify that the user account used by the engineer has read-write permission to the share. Use the net share command or right-click > Properties > Sharing to inspect.

Network Topology and Data Flow

Figure 1 - WinCC ES to OS download flow with PC Station name mismatch and resulting SQL authentication failure.

Pre-Download Verification Checklist

Before opening a ticket or attempting corrective steps, perform the following verification on every PC in the WinCC topology. Documenting the result of each step avoids repeated round-trips with engineering.

1. Confirm hostname match: the name in WinCC Explorer's PC Station node is byte-for-byte equal to the Windows hostname of the target PC. Run hostname in cmd.exe and compare.
2. Confirm SIMATIC NET is installed: open Station Configuration Editor on every OS and verify that the WinCC application slot shows the project's PC station configuration.
3. Confirm user accounts are identical: the engineer and the runtime service must log on with the same Windows user name and password on every PC (or use domain accounts from Active Directory).
4. Confirm folder permissions: the project folder share must include administrators and the SIMATIC HMI group with full control.
5. Confirm SQL Server is reachable: open SQL Server Management Studio on the OS and connect to the local instance using Windows authentication.
6. Confirm yellow up-arrow: open WinCC Explorer on the ES; if the PC Station icon displays a yellow up-arrow, the configuration is modified and not yet downloaded.
7. Confirm Stand Alone vs Client selection: the project type matches the runtime role. An Engineering Station project cannot be run on a single OS without explicit conversion.

Diagnostic Procedure

Use the following ordered diagnostics to localize the failure before applying corrective steps.

Step 1 - Capture the Runtime Error

Trigger the WinCC Runtime on the target OS. Click OK or Cancel on the “Access is Denied” dialog and capture the dialog title and message text. Then exit the runtime. Open WinCC Explorer > Tools > Diagnostic Files and capture the WinCC_SysLog_*.txt file for the relevant time interval. Also inspect WinCC_Start.log in the same diagnostic folder for the cold-start sequence.

Step 2 - Compare Project Server Name with Windows Hostname

Open the project on the target PC and inspect the Properties of the PC Station node. Note the value in the Computer name field. Open cmd.exe and execute hostname. The two values must be identical, including case on case-sensitive filesystems. If they differ, the project was downloaded from an ES that holds a different reference name in its tree.

Step 3 - Inspect the SQL Server Connection Test

From the OS, open ODBC Data Sources (32-bit) from the Control Panel and open the WinCC system DSN. Press “Test” to verify the data source. A successful connection proves the SQL Server service is reachable; a logon failure pinpoints integrated Windows authentication failure.

Step 4 - Inspect Folder Shares and ACLs

From the ES, open File Explorer and navigate to \\OS_PC\WinCC_Projects. If the share is not reachable, verify the share exists on the OS using net share. If accessible, right-click the project root and inspect the Security tab. Both administrators and the SIMATIC HMI group must hold full control.

Step 5 - Verify SIMATIC NET Configuration

On the OS, run Station Configuration Editor. Verify that the station name matches the Windows hostname. If the row is empty, the SIMATIC NET component is installed but the station needs to be configured and the configuration downloaded from the ES.

Step 6 - Confirm WinCC Service Account

Open services.msc on the OS and inspect the logon account used by the WinCC Runtime Service (typically SIMATIC WinCC Explorer and CCMHelper). The same Windows account must be a member of the local administrators group and the SIMATIC HMI group, and it must exist with the same password on every PC.

Resolution 1 - Correct the PC Station Identity

The fastest fix for the symptom described in the source is to make the PC Station name in the project match the actual computer name. Follow the procedure below on the ES for every OS that exhibits the failure.

1. Open WinCC Explorer on the ES and load the project that is being distributed.
2. Right-click the PC Station node in the project tree and select Properties.
3. On the General tab, set Computer name to the Windows hostname of the target PC. Do not abbreviate with “localhost” or with an alias.
4. Click Apply and OK to commit the change. The PC Station icon briefly shows a yellow up-arrow.
5. Open Station Configuration Editor on the target OS. The list should now display the new PC station name.
6. From the ES, right-click the PC Station and select Download > PC Station. Confirm the download dialog.
7. On the OS, launch WinCC Runtime. The SQL connection should succeed and the operator screen will start.

Reference Parameter Mapping

Resolution 2 - Standardize User Accounts and Folder Permissions

On every PC participating in the WinCC project, perform the following.

1. Create a Windows user account with the same name and password on each PC, or use a domain account with the same name. Engineer, runtime service, and operators should all log on as that account.
2. Add the account to the local administrators group and to the SIMATIC HMI group on every PC.
3. Right-click the WinCC project root folder, select Properties > Security, and Add > administrators and SIMATIC HMI with full control. Tick “Replace all child object permissions”.
4. From the ES, try to read and write to \\OS_PC\WinCC_Projects\. If the test fails, verify the share permissions under Properties > Sharing > Permissions.
5. Re-attempt the project download from the ES.

Resolution 3 - Install SIMATIC NET and Download the PC Station

If the Station Configuration Editor is empty on the OS, the engineer missed installing SIMATIC NET or failed to download the configuration. Resolve as follows.

1. On the OS, run the SIMATIC NET installation media and select the OPC Server and S7 Protocol Suite components.
2. Restart the OS after install. Confirm the Station Configuration Editor opens without errors.
3. From the ES, open Station Configuration Editor (under Start > Siemens Automation > SIMATIC NET). Add a PC Station with the OS computer name. Save to the local project.
4. Right-click the PC Station entry and select Download to PC Station. Accept the UAC prompt on the OS.
5. Confirm in the Configuration Console of the OS that the S7 connection used by WinCC has reached status “connected”.

Resolution 4 - Repair SQL Server Authentication and Permissions

If the previous corrections have been applied and the access-denied error still appears, verify the SQL Server side.

1. Open SQL Server Configuration Manager on the OS. Confirm that the SQL Server (WinCC) service is running.
2. In SQL Server Management Studio, connect to the local SQL Server instance using Windows authentication as the engineer account.
3. Expand Security > Logins. Verify that the engineer account (or the SIMATIC HMI group) is present as a login with the public server role and db_owner on the WinCC project databases.
4. Open the SQL Server error log via Management Studio > Management > SQL Server Logs. Filter for authentication failures during the WinCC runtime startup timestamp. The error number 18456 indicates Windows authentication failure, mapped to “Access is Denied” at the WinCC layer.
5. If the account is missing, add it via Security > Logins > New Login. Map to the WinCC project database with db_owner.
6. Re-start the WinCC Runtime service on the OS.

SQL Server Error Mapping

Resolution 5 - Rebuild the Stand Alone Client Project Assignment

If the project tree was created with a generic node name like “Stand Alone Client”, the engineer should rebuild the node with the actual computer name. The rewrite ensures the host reference is propagated from the ES unchanged.

1. In the ES, right-click the PC Station node and rename it to the OS computer name, for example “OS-PC1”.
2. Save the project.
3. Open the project locally on the target PC to confirm WinCC loads it without identity mismatch.
4. Close WinCC Explorer on both ES and OS without saving any other changes.
5. Re-attempt the OS download using ES > Project > Download to PC Station.
6. Verify by starting runtime on the OS.

Resolution 6 - Re-create the Project Folder with Clean Share

If folder-level ACL corruption is suspected, create a brand-new project folder and re-target the download.

1. On the OS, create D:\WinCC_Projects\<ProjectName> as a new folder.
2. Right-click > Properties > Sharing > Advanced Sharing. Tick “Share this folder” and assign the share name WinCC_Projects$ for hidden sharing or WinCC_Projects for normal sharing.
3. Set NTFS permissions: administrators and SIMATIC HMI group with Full Control; CREATOR OWNER with Full Control for subfolders.
4. From the ES, point the project path to \\OS_PC\WinCC_Projects\<ProjectName> using WinCC Explorer > Project > Properties.
5. Re-trigger the OS download. Verify that WinCC Runtime starts cleanly.

Multi-Client Project Topology Considerations

In multi-station WinCC topologies the engineer commonly faces the choice between a Single-User project on each OS, a Multi-User server with thin clients, and a Distributed system. The ES-led download path is identical in all three, but the server-identity mismatch interacts differently with each topology.

Engineers moving from a Single-User setup to a Multi-User topology often inherit the misleading “Stand Alone Client” label that was originally a placeholder for a single-machine deployment. Rename the node immediately when converting the project type to prevent the issue from emerging.

Verification Procedure

After applying any of the resolution steps, perform the full verification sweep below before declaring the fix successful.

1. Confirm the WinCC Runtime starts without “Access is Denied”.
2. Open WinCC Explorer > Project > Status. Confirm that the project is in “Runtime” mode and the database attach timestamp matches the current download.
3. Confirm that operator screens render and graphics updates propagate from any PLC configured for the project.
4. From the ES, check the WinCC project state. The PC Station icon should no longer display a yellow up-arrow. If it does, repeat the PC Station download step.
5. Capture WinCC SysLog files from both the ES and OS for the next 24 hours and confirm no further “Access is Denied” entries appear.
6. Cycle the OS to simulate a power loss scenario and verify that WinCC Runtime starts cleanly on each cold boot.
7. Repeat step 6 on the ES to confirm the engineering workstation continues to load the project cleanly after the OS-side correction.

Preventive Maintenance and Best Practices

The following practices prevent the symptom from re-occurring in multi-station WinCC projects.

1. Establish a Windows naming convention for WinCC PC Stations that mirrors the Windows hostname exactly. Do not use placeholder names like “Stand Alone Client” in the project tree.
2. Use Active Directory accounts with identical names and passwords across all WinCC PCs. Add every account to the local administrators group and to the SIMATIC HMI group on every PC.
3. Document the central project share path in the project configuration. Avoid relocating the project share during commissioning.
4. Run the Configuration Console on every OS after every SIMATIC NET or PC Station change. Confirm that the WinCC slot and the S7 connections are downloaded.
5. Apply WinCC service packs and SIMATIC NET hotfixes together, never separately. Configuration mismatch between the two packages can reset the station configuration and reintroduce the name-mismatch symptom. Reference the WinCC Readme for the tested combination of WinCC and SIMATIC NET versions for your installed service pack.
6. Maintain SQL Server service account login name as the same Windows account used for WinCC login. Avoid SQL Server mixed-mode authentication if not required.
7. Before adding any new OS to the topology, perform the full Pre-Download Verification Checklist on the new machine.
8. Schedule a quarterly SQL Server error log review for error 18456 entries; treat any occurrence as a leading indicator of an authentication drift that requires immediate WinCC credential audit.
9. Keep the WinCC project file (.mcp) under version control in the engineering repository. This allows a quick rollback to a known-good state if a re-configuration attempt reintroduces the symptom.

Troubleshooting Matrix

FAQ