Configuring Windows Users for PCS 7 V9.1 Operator Stations

Overview

PCS 7 V9.1 operator stations (OS) run on Windows and rely on Windows authentication for several services, including WinCC Explorer, the Graphics Runtime, SIMATIC Logon, and the redundant OS partner handling. Leaving every station signed in as the built-in administrator account is permitted during installation and commissioning, but is not a sustainable operating posture: it bypasses the audit trail, removes accountability for operator actions, exposes the runtime to accidental shutdown, and conflicts with the standard SIMATIC security model.

This guide consolidates the published Siemens guidance for setting up additional Windows user accounts on a PCS 7 V9.1 OS, joining the required local and domain groups (SIMATIC HMI, SIMATIC Logon, Users), and integrating those accounts with SIMATIC Logon so that the Graphics Runtime authenticates operators per session while a low-privilege service user keeps WinCC Runtime online.

Why a Permanent Administrator Account Is a Problem

PCS 7 is engineered around a layered security concept. The OS runtime, the alarm logging, the time synchronization, and the SIMATIC Logon service assume that the operator session is non-administrative. The most common field issues caused by running only as administrator:

• Uncontrolled Windows updates. A privileged user can install patches or change group policy at the OS, restarting the box and breaking the redundant partner handover.
• Runtime shutdown. A privileged user can stop the WinCC Runtime or the SIMATIC Logon service from the desktop without leaving a trace in the audit log.
• Loss of operator accountability. WinCC operator actions are tied to the Windows account logged in. If every session is administrator, you cannot determine who acknowledged an alarm or who issued a control command.
• Conflicts with SIMATIC Logon. SIMATIC Logon maps Windows credentials to WinCC user groups (e.g., @Administrators, @Operators). A single shared administrator login defeats the role-based authorization model.

Siemens therefore requires at least one additional, non-administrative Windows user per OS once the system is handed over to operations. The PCS 7 Readme V9.1 SP2 (Online) specifies that every Windows user who should have access to the PCS 7 OS must be added to the SIMATIC HMI group using their Windows credentials.

Prerequisites

Before you start reconfiguring user accounts on a live OS, confirm the following:

1. The PCS 7 project is fully commissioned, archived, and backed up. The user changes described here do not modify the project itself, but a restore point is good practice before touching local security groups.
2. You are still logged in as a Windows user that retains local administrator rights. The built-in Administrator or a domain admin with local equivalence is acceptable for the setup phase; you will demote or remove it afterward.
3. You have the SIMATIC Logon license available. On PCS 7 V9.1, SIMATIC Logon is part of the standard PCS 7 license envelope, so no separate purchase is required for the basic per-user login functionality.
4. Domain accounts are preferred for plant-floor operators. If the OS is in a workgroup (no domain controller), plan for local accounts and document the password vault location.
5. The relevant Siemens manuals are available: PCS 7 - PC Configuration (section Setting up user groups and users) and PCS 7 Compendium Part A (section User administration). The Compendium is the primary reference for how Windows accounts map to WinCC roles and for SIMATIC Logon.

Required Windows User Groups

PCS 7 V9.1 expects each Windows user that interacts with the OS to be a member of the following groups, in addition to any default groups Windows assigns:

The SIMATIC HMI group is created during PCS 7 installation. The PCS 7 Readme V9.1 SP2 explicitly lists this group as the entry point for granting OS access.

Step-by-Step: Creating a Non-Administrative OS User

The following sequence creates a standard operator account and joins it to the required groups. Run each step on every OS (server, single station, or client) that the operator must access.

1. Open Computer Management. Sign in as an administrator. Press Win + X, choose Computer Management. In the left tree, expand Local Users and Groups > Users.
2. Create the user. Right-click Users and choose New User. Enter the operator's full name and a Windows-style logon name. Set a strong password. Clear User must change password at next logon if the account is to be used by the runtime autostart; check Password never expires only for the dedicated runtime autostart account described in the next section.
3. Add the user to SIMATIC HMI. Double-click the new user, select the Member Of tab, click Add, type SIMATIC HMI, and validate. The Readme states that the user's Windows credentials are used by the runtime to authorize OS access.
4. Confirm default group membership. Make sure Users is present. For domain accounts, these memberships are normally inherited from the domain group policy; verify on a test station before rolling out.
5. Add to SIMATIC Logon if SIMATIC Logon is in use. This step is required so the SIMATIC Logon service will accept the user's credentials when the runtime prompts for a per-operator login.
6. Grant WinCC roles in WinCC Explorer. Open WinCC Explorer on the OS (as a Windows user that already has the SIMATIC HMI membership and the matching WinCC internal role), go to User Administrator, and add the new Windows account to the appropriate WinCC group, e.g., @Operators or @Administrators for the OS.
7. Configure the user's project authorization. In the PCS 7 plant view, right-click the OS and select Operator Authorization. Assign the WinCC group you just populated. This is what allows the operator to acknowledge alarms and issue commands at faceplates.
8. Propagate to redundant partner. On a redundant OS server pair, repeat steps 1-7 on the standby server. The WinCC user database is project-side, but the Windows local groups must be present on both nodes.
9. Sign out and sign in as the new user. Verify that the Windows logon succeeds and that WinCC Explorer launches without elevation prompts.

Step-by-Step: Enabling Per-Operator Runtime Login with SIMATIC Logon

SIMATIC Logon is the standard mechanism in PCS 7 V9.1 for authenticating the operator inside the running WinCC project while a non-privileged Windows user keeps the runtime online. The PCS 7 Compendium Part A, section User administration, is the authoritative reference. The condensed procedure:

1. Open the SIMATIC Logon Service Configuration (Start menu > Siemens Automation > SIMATIC Logon). On PCS 7 V9.1, the service is already installed; you only need to configure it.
2. On the User database tab, select the authentication source. Options are local SAM database, Windows domain, or an RFID card reader. For plant-floor operators, use the Windows domain. For standalone or workgroup installations, the local SAM is used.
3. On the Logon tab, enable Automatic logon for WinCC Runtime only if you are configuring a dedicated kiosk account (described next). Leave it disabled for operator accounts that should be prompted at runtime start.
4. On the Role assignment tab, add the new Windows account and assign the WinCC role (@Administrators, @Operators, @Viewers, etc.). These roles are evaluated by the runtime when an operator attempts a protected action.
5. Distribute the configuration. SIMATIC Logon can be operated centrally. On an OS server, the configuration is stored in the project; on OS clients, the SIMATIC Logon Service Configuration tool replicates the settings locally.
6. Reboot the OS. The SIMATIC Logon service must start before the WinCC Runtime so the runtime can detect the configured user database.

After the reboot, when an operator launches the runtime, the Graphics Runtime prompts for SIMATIC Logon credentials. The operator enters their Windows account, the runtime confirms membership in the assigned WinCC role, and the audit log records all subsequent actions against that operator's name.

Multi-User Access Patterns

The most common field deployments use one of two patterns. The choice depends on whether the OS is a single-user station at a control desk or a shared engineering/operator terminal.

Pattern A: Auto-Start Runtime with Dedicated Service Account

Create a low-privilege Windows account (for example svc_osruntime) whose password is set to never expire, add it to SIMATIC HMI and SIMATIC Logon, configure the WinCC Runtime for autostart under that account, and then have operators authenticate at runtime start using SIMATIC Logon. The advantages:

• The Graphics Runtime is always online; an operator cannot accidentally close it from the Windows shell.
• Operators can only stop the runtime by performing the documented logoff (Ctrl+Alt+Del is intercepted at the desktop level by group policy).
• Each operator's actions are auditable.

Pattern B: Shared Terminal with Multiple Windows Logins

Each operator has their own Windows account on the OS. The runtime does not autostart. Each operator signs into Windows, then opens the WinCC Runtime, which prompts for SIMATIC Logon. This is appropriate for engineering rooms or supervisor consoles but introduces the risk that a user signs out, the runtime terminates, and alarms stop being acknowledged. If you must use this pattern, set the runtime to remain active when the Windows session is locked, and configure a screen saver that does not return to the Windows logon screen.

Verification Checklist

Before handing the OS over to operations, walk through the following checks. Each row should be ticked off on the commissioning sheet.

1. The built-in Administrator account is renamed or has a strong, vaulted password. If local administrator rights are reserved for maintenance, ensure the account is not the one used for autostart.
2. Every operator account is a member of SIMATIC HMI. Confirm with net localgroup "SIMATIC HMI" from a command prompt.
3. Every operator account is a member of SIMATIC Logon (Pattern A or B). Confirm with net localgroup "SIMATIC Logon".
4. Each account has a WinCC role assigned in WinCC Explorer > User Administrator and the matching project-level operator authorization in the PCS 7 plant view.
5. The SIMATIC Logon service starts automatically and is running. Verify in services.msc: the SIMATIC Logon service status should be Running and the startup type Automatic.
6. A test logon by each operator succeeds, and an alarm acknowledgment is recorded with that operator's name in the WinCC Alarm Logging archive.
7. On a redundant OS server pair, fail over to the standby and confirm the operator can log in there as well. Repeat the group membership check on the standby node.

Troubleshooting Matrix

Operational Considerations

Beyond the mechanical steps of creating accounts and joining groups, two operational topics are worth flagging.

Domain vs. workgroup. If the OS is domain-joined, use a domain group such as DOMAIN\PCS7_Operators as a member of SIMATIC HMI on each OS. This avoids the need to maintain a per-station list of local accounts. If the OS is in a workgroup, every account is local and the SIMATIC Logon user database is the local SAM. Either is supported, but the change-management overhead is significantly higher in a workgroup.

Audit and password policy. PCS 7 inherits the Windows password policy. If your IT department enforces 90-day password expiry, the SIMATIC Logon service must be re-keyed when the dedicated service account's password rotates. Plan the password rotation schedule together with IT and document the procedure in the plant cybersecurity plan. The PCS 7 Readme V9.1 SP2 contains the current list of mandatory post-installation tasks; consult it during every major Windows patching cycle.

Field-Proven Tips

• Document the mapping of Windows account → SIMATIC Logon role → WinCC group → project-level operator authorization in the project administration sheet. This four-way mapping is the single most common source of authorization bugs.
• Use gpresult /r on a test OS to confirm that the domain group policy is applying the expected local group memberships. If group policy is overriding your manual additions, adjust the GPO rather than re-adding accounts.
• After any user change, archive a screenshot of net localgroup "SIMATIC HMI" and net localgroup "SIMATIC Logon" from each OS. The screenshot doubles as commissioning evidence and a baseline for audits.
• If you rename the original administrator account instead of creating a new one, remember that the SIMATIC Logon service and the WinCC autostart may still reference the old name. Reboot and check the event log for service start failures.
• For redundant OS pairs, schedule the user change during a maintenance window where both servers can be reconfigured. A half-migrated pair produces confusing half-states.

FAQ