Resolving PCS7 V7.0 SP1 Project Open Rights Error

Resolving PCS7 V7.0 SP1 "User Does Not Have Proper Rights" Project Open Error

When a SIMATIC PCS 7 V7.0 SP1 Engineering Station (ES) refuses to open a project with a dialog stating that the current user does not have the proper rights, the cause is almost always one of three classes of failure: a Windows security-group membership defect, an inconsistent or duplicate folder mapping pointing to the project directory, or a corrupted project container that no longer matches the rights baked into its SQL or DCOM configuration. This article walks through each root cause, the precise diagnostics to confirm it, the field-proven fix for each, and the log locations that let you prove the cause to a customer or integrator.

1. Problem Statement and Scope

Symptom: A user launches SIMATIC Manager (the V7.0 SP1 shell), opens the project file or .S7P archive, and receives a dialog similar to "The user does not have the required rights" or "You do not have permission to open this project." The error appears even when the user is verified as a member of the local Administrators group and of all SIMATIC-related Windows groups (SIMATIC HMI, SIMATIC NET, SIMATIC BATCH-IF, SQLServer2005MSSQLUser$<COMPUTERNAME>, SQLServer2005SQLAgentUser$<COMPUTERNAME>).

The error blocks both the AS (Automation Station) component (STEP 7 part) and the OS (Operator Station) component (WinCC part) from loading. After dismissing the dialog, SIMATIC Manager may leave a partial project object in the workspace, and the WinCC Explorer may also refuse to start with a parallel "insufficient rights" prompt.

This behavior is specific to PCS 7 V7.0 SP1 but the same class of failure recurs through V7.1, V8.0, V8.1, and V8.2, with the primary differences being the SQL Server version (2005, 2008 R2, 2012, 2014) and the exact Windows group naming convention. The diagnostics and resolutions documented here apply with minor adaptations to all V7.x and V8.x PCS 7 releases.

2. Affected Versions and Required Environment

3. Root Cause Matrix

The dialog text alone is rarely enough to point to a single cause. Use the matrix below to triage based on the environment.

4. Solution A — Resolve Duplicate Folder Mappings

The single most reported cause in V7.0 SP1 is two simultaneous mappings that both resolve to the same project directory. PCS 7 / WinCC stores absolute paths in the project database (the WinCC project file *.mcp and the WinCC user archive *.UDL). If the same folder is reachable through both W:\ (mapped from \\OSServer\Project$\Mario) and Z:\Mario (mapped from \\OSServer\Project$), WinCC's path resolution cannot decide which identity to use for the local user. The rights check fails because the SID recorded against one path does not match the SID of the other.

Step-by-step

1. Open cmd.exe on the Engineering Station.
2. Run net use and list all persistent and current drive mappings. Identify any pair that resolves to the same UNC target.
3. Determine which mapping is the canonical project path. Use dir W:\ and dir Z:\Mario to confirm both show the same .S7P file.
4. Disconnect the redundant mapping:

   net use Z: /delete /y

5. Close SIMATIC Manager and WinCC Explorer.
6. Reopen SIMATIC Manager using only the canonical mapping (e.g., W:\MyPlant.S7P).
7. Confirm the project opens without the rights dialog.

5. Solution B — Windows Group Membership Audit

Even when a user appears to be in the right groups, group membership in a domain environment can be stale due to Kerberos ticket caching, offline image cloning, or USMT migration that strips local group SIDs. Verify every required group is present.

Required local groups for PCS 7 V7.0 SP1

• Administrators (built-in; full local rights)
• SIMATIC HMI (created by PCS 7 setup)
• SIMATIC NET (created by PCS 7 setup)
• SIMATIC BATCH-IF (only when SIMATIC BATCH option installed)
• SQLServer2005MSSQLUser$<COMPUTERNAME>
• SQLServer2005SQLAgentUser$<COMPUTERNAME>

Step-by-step verification

1. Open an elevated cmd.exe.
2. Run whoami /groups | findstr /i "SIMATIC SQL".
3. For each missing group, add the user:

   net localgroup "SIMATIC HMI" %USERNAME% /add
   net localgroup "SQLServer2005MSSQLUser$ES-01" %USERNAME% /add

   (Replace ES-01 with the actual computer name shown by echo %COMPUTERNAME%.)
4. Log off and log on again so that new group SIDs appear in the access token.
5. Retry opening the project in SIMATIC Manager.

When a domain user is involved, perform the same audit on the domain controller via Active Directory Users and Computers and on the local SAM via the Local Users and Groups MMC snap-in. Membership in the local group is what matters at the resource check; domain membership alone is not sufficient.

6. Solution C — DCOM and Component Services

PCS 7's OS (WinCC) runtime and the AS (STEP 7) component rely on DCOM for cross-process calls to OPC servers, S7ONLINE, and WinCC runtime components. A default-allow DCOM configuration installed by the Siemens setup is sometimes overwritten by a Windows security hardening pass or a GPO. The rights dialog then manifests only when SIMATIC Manager tries to launch the WinCC Explorer host process.

Verification

1. Launch dcomcnfg.
2. Expand Component Services > Computers > My Computer.
3. Right-click My Computer, choose Properties, open the Default Properties tab.
4. Confirm Enable Distributed COM on this computer is checked.
5. Open the COM Security tab. Under Access Permissions and Launch and Activation Permissions, click Edit Default. Confirm the INTERACTIVE user, the engineering user, the SIMATIC HMI group, and SYSTEM are present with Allow on Local Access, Local Launch, Local Activation, Remote Access, Remote Launch, and Remote Activation.
6. Under My Computer > DCOM Config, locate OPC.Siemens.Net, WinCC Explorer, CCAlgCSHandler, and any S7DOS / S7ONLINE entries. Open Properties > Security for each and add the engineering user with full rights.
7. Restart the COM+ System Application service.

7. Solution D — SQL Server Service and Database Rights

The WinCC/OS side of the project stores runtime and configuration data in a SQL Server database named CC_<projectname>_<datetime> on a SQL Server 2005 instance typically called WINCC. If the SQL Server service is not running, or the engineering user lacks the db_owner role on this database, the OS portion of the project fails to attach and the rights dialog appears.

Step-by-step

1. Open SQL Server Configuration Manager.
2. Confirm the SQL Server (WINCC) and SQL Server Agent (WINCC) services are Running and set to Automatic.
3. If the service is stopped, attempt to start it. A failure citing a wrong service account means the account was changed after the PCS 7 setup; restore the original account (typically NT AUTHORITY\SYSTEM for the SQL Server service on a standalone ES, or a domain service account in a multi-user configuration).
4. Open SQL Server Management Studio Express and connect to \\.\WINCC with Windows authentication.
5. Expand Security > Logins. Confirm the engineering Windows account is present. If not, add it: CREATE LOGIN [DOMAIN\EngineeringUser] FROM WINDOWS.
6. Expand Databases, select the project database, open Security > Users, and add the engineering user as db_owner.
7. Retry the project open.

8. Solution E — Project Container Recompile or Recreation

If A through D have been exhausted and the rights dialog still appears, the project container itself is suspect. PCS 7 V7.0 SP1 projects store a rights signature derived at compile time from the user account that originally created the OS images. When the ES user account changes, or when the project is migrated from one domain to another without re-compilation, the stored signature no longer matches the current user's SID, and the rights check rejects the load.

Step-by-step

1. In SIMATIC Manager, open the project with a user account that previously had rights. If no such account exists, log in as Administrator after temporarily granting it SIMATIC HMI membership.
2. Select the AS object in the component view, right-click, choose Compile and Download Objects. Confirm that the AS recompiles cleanly.
3. Select each OS server, right-click, choose Compile OS. This regenerates the WinCC database and rebinds the rights signature to the current user.
4. If recompile is not possible due to source corruption, create a new PCS 7 project and copy the S7 program sources (blocks, symbols, CFC charts) into the new container, then re-add the OS components.
5. Save and reopen the project as the engineering user.

This is the same remedy that resolved field reports in the source: the integrator created a fresh project, recompiled the program, and the rights dialog disappeared.

9. Diagnostic Logging Locations

The original engineer who reported the issue asked explicitly for log locations so that future occurrences could be diagnosed without integrator involvement. The following paths capture the relevant trace data for PCS 7 V7.0 SP1.

Enabling verbose SIMATIC Manager tracing

1. Close SIMATIC Manager.
2. Open Registry Editor and navigate to HKEY_CURRENT_USER\SOFTWARE\Siemens\Automation\Simatic Manager\Trace.
3. Create a DWORD value named Level and set it to 0x00000003 (verbose).
4. Restart SIMATIC Manager and reproduce the failure.
5. Inspect the log directory listed above. The trace files are named SIMATIC_b_<timestamp>.log and contain a chronological list of API calls, rights checks, and SQL queries with the failing SID noted explicitly.

10. Verification Steps

Run the following checks after applying any solution.

1. Confirm the project opens in SIMATIC Manager without a rights dialog.
2. Open the OS component in WinCC Explorer. Confirm the project loads and the WinCC project tree is populated.
3. Activate the runtime (or simulate it on the ES) and verify that no alarm appears regarding rights or SQL connection.
4. Open Component Services (dcomcnfg) and confirm that the engineering user has both local and remote launch and access permissions on every Siemens DCOM application.
5. Run sqlcmd -S .\WINCC -E -Q "SELECT name FROM sys.databases WHERE name LIKE 'CC%'" and confirm the project database is listed and online.
6. Close SIMATIC Manager, reopen, and re-open the project. Repeat three times to confirm the fix is stable.

11. Prevention Checklist

• Publish all PCS 7 projects via a single UNC share and prohibit per-user drive mappings.
• Document the canonical project path in the project README and in the change-management system.
• Maintain a baseline user account image with all required SIMATIC and SQL groups pre-populated.
• Disable GPOs that overwrite local DCOM permissions or SQL service accounts on engineering workstations.
• After any domain migration or PC replacement, recompile the AS and OS in the affected projects before handing back to operations.
• Schedule nightly backup of the project container and the WinCC runtime database so that a corrupt project can be restored without integrator intervention.
• Retain trace logging for at least 14 days so that rights errors can be retroactively diagnosed.

12. Reference to Siemens Support Entry

Siemens Support Entry ID 19346272 ("Why can the user not open a PCS 7 project or why does the user receive a message about insufficient user rights?") directly addresses this class of failure. The entry enumerates the required Windows groups, the SQL Server roles, and the DCOM permission set that must be present for a user to open a PCS 7 project. Refer to that entry alongside this field-procedure article; this article adds the duplicate-drive-mapping cause and the diagnostic logging commands that the support entry does not detail.

Frequently Asked Questions