Configuring WinCC Server/Client Systems in a Windows Active Directory Domain

Deploying a Siemens WinCC server/client architecture inside a Microsoft Active Directory (AD) domain requires deliberate user-account and group planning. Unlike workgroup installations, domain-integrated WinCC projects depend on SIMATIC HMI group membership, local Administrators rights on each runtime node, and consistent service-account credentials. This reference consolidates the requirements documented in the WinCC Release Notes and the Siemens Industry Online Support entry 78346833 - Installation and Operation of WinCC in a Microsoft Domain Environment, together with the WinCC TIA Portal v20 installation guidance at Installing WinCC - TIA Portal.

1. WinCC Domain Model: What Changes Versus a Workgroup

WinCC is generally authorized for use in a domain or a workgroup. The architectural differences that matter for the field engineer are:

Per the official installation note, WinCC must be installed before the PC is joined to the domain when a non-domain local administrator is preferred. After successful installation, the WinCC computer can be re-entered into the domain. This ordering avoids UAC and DCOM permission inheritance problems that occur when domain-joined machines are reinstalled.

2. Required User and Group Inventory

For a multi-zone WinCC server/client deployment, build the following account inventory before installing WinCC runtime. The source scenario describes three roles; the canonical mapping is:

3. The SIMATIC HMI Group Rule

The single most-asked question in this configuration is: Does every domain user need to be a member of SIMATIC HMI on the WinCC server, or only on the machine the user actually accesses?

The documented rule is unambiguous:

1. Create one domain global security group named SIMATIC HMI in Active Directory Users and Computers.
2. On every WinCC server and every WinCC client, the local group SIMATIC HMI (created automatically by WinCC Setup) must contain the domain global SIMATIC HMI group as a member.
3. Add the individual domain users to the domain global SIMATIC HMI group, not directly to every local group.

This nested-group design means each user only needs to be added once (in AD), and the local WinCC Authorization checker on each runtime node will resolve membership through the trusted group chain. The local SIMATIC HMI group also gives members the right to access WinCC-specific DCOM applications, registry keys, and the project directory under C:\Program Files\Siemens\Automation\WinCC\WinCCProjects.

3.1 PowerShell Setup Example

Run these commands on a domain controller or any machine with Active Directory PowerShell:

# 1. Create the domain global SIMATIC HMI group
New-ADGroup -Name "SIMATIC HMI" `
  -GroupScope Global -GroupCategory Security `
  -Path "OU=Groups,OU=Plant,DC=plant,DC=local" `
  -Description "WinCC runtime users - global membership"

# 2. Add WinCC Server Administrator
Add-ADGroupMember -Identity "SIMATIC HMI" -Members "winccsrvadmin"

# 3. Add Zone 1 client operator
Add-ADGroupMember -Identity "SIMATIC HMI" -Members "zone1_op"

# 4. Add Zone 2 client operator
Add-ADGroupMember -Identity "SIMATIC HMI" -Members "zone2_op"

# 5. Add WinCC runtime service account
Add-ADGroupMember -Identity "SIMATIC HMI" -Members "svc_wincc"

3.2 Local SIMATIC HMI Group Configuration

On each WinCC server and client, run as a local Administrator:

# Add the domain global group to the local SIMATIC HMI group
Add-LocalGroupMember -Group "SIMATIC HMI" `
  -Member "PLANT\SIMATIC HMI"

# Optional: verify
Get-LocalGroupMember -Group "SIMATIC HMI"

Replace PLANT with the actual NetBIOS domain name. The local group exists after WinCC installation; do not create it manually because WinCC Setup also sets DCOM launch and access ACLs on it.

4. Server vs. Client User Authority

WinCC differentiates between users who configure projects on the server and users who operate clients. Map them as follows:

Two operators working in different zones (e.g., Zone 1 and Zone 2) get the same SIMATIC HMI membership but different WinCC user authorizations. Zone separation is enforced inside the WinCC project through the User Administrator dialog, not through domain group membership.

5. Domain Group Policy Considerations

Domain Group Policy Objects (GPOs) will silently break WinCC if the wrong templates are applied. Lock down the following policies for WinCC runtime nodes only:

6. Service Account Selection

WinCC runtime uses several Windows services: CCAgent, SIMATIC WinCC Explorer, SIMATIC WinCC Runtime, S7DOS, and the redundancy/connectivity services. Each must start with a credential that has:

• Local Administrators membership on the WinCC server
• Read/write access to the project directory
• "Log on as service" advanced user right (assigned via GPO to SIMATIC HMI)
• For client-to-server: SeNetworkLogonRight ("Access this computer from the network")

Configure the service logon once in services.msc:

# Verify a service account has the right privileges
whoami /priv | findstr "SeServiceLogonRight"
whoami /groups | findstr "S-1-5-32-544"
# S-1-5-32-544 = BUILTIN\Administrators

6.1 Group Managed Service Account (gMSA) - Preferred for V16+

On Windows Server 2012 or higher, deploy a gMSA so password rotation is automatic. Add the gMSA to SIMATIC HMI and local Administrators. WinCC V16 and later support gMSA in documented configurations; for WinCC 7.5 SP2 and earlier, use a domain user with a non-expiring password.

7. Step-by-Step Configuration Procedure

1. Pre-install audit. Confirm each target PC is running a Windows version listed in the WinCC installation notes (WinCC V7.5 SP2: Windows 10 LTSC 2019 / Windows Server 2016/2019; WinCC TIA V20: Windows 10 LTSC 2021 / Windows Server 2019/2022). Remove any pending reboots.
2. Create domain accounts and groups. In AD, create the SIMATIC HMI global group, the WinCC Server Admin, the two zone operators, and the service account. Add them all to the global SIMATIC HMI group.
3. Install WinCC as local Administrator. Log on as the built-in local Administrator; install WinCC. Do not join the domain yet.
4. Apply local Administrators and SIMATIC HMI membership. While still in the local-admin session, add the three domain users and the service account to local Administrators, and add the domain global SIMATIC HMI group to the local SIMATIC HMI group.
5. Join the domain. Reboot, then join the machine to the domain. Confirm the local SIMATIC HMI group survived the domain join (re-add if necessary).
6. Set service logons. In services.msc, change every WinCC service Log On to the domain service account. Restart the services and verify the WinCC Explorer opens without UAC prompts.
7. Configure the WinCC project User Administrator. Inside the project, map the three domain users (referenced as PLANT\winccsrvadmin, etc.) to the appropriate WinCC authorization levels. Zone separation is enforced here, not in AD.
8. Configure clients. Repeat steps 3-5 on each client. Because the local SIMATIC HMI group already references the domain global group, zone operators do not need to be added on the server.
9. Enable WinCC Client/Server communication. In the server project, set the preferred server. On each client, verify the server name resolves in DNS (no WINS-only entries) and that the WinCC server's CCAgent service is reachable on TCP 2308/2309.
10. Validate with a test user. Log on to a client as zone1_op; confirm WinCC runtime starts and that the operator only sees Zone 1 authorizations.

8. Verification and Diagnostic Checks

After configuration, run these checks before going live:

9. Common Errors and Resolutions

10. Multi-Zone Deployment Topology

The diagram below represents a typical two-zone plant: one WinCC server pair, two distinct client sets, all domain-joined, all reading the same project with different operator authorizations.

   +-------------------+        +-------------------+
   | DC01.plant.local  |        | DC02.plant.local  |
   | (Domain Controller)        | (Domain Controller)|
   +---------+---------+        +---------+---------+
             |                            |
             +-------------+--------------+
                           |
            +------------------------------+
            |  Global Group: SIMATIC HMI   |
            |   - winccsrvadmin            |
            |   - zone1_op                 |
            |   - zone2_op                 |
            |   - svc_wincc                |
            +---------------+--------------+
                            |
        +-------------------+-------------------+
        |                                       |
+-------v-------+                       +-------v-------+
|  WinCC SRV-1  |   redundancy link    |  WinCC SRV-2  |
| Local Admins  | <----------------->  | Local Admins  |
| Local SIMATIC |                       | Local SIMATIC |
| HMI contains  |                       | HMI contains  |
| domain group  |                       | domain group  |
+-------+-------+                       +-------+-------+
        |                                       |
        +-------------------+-------------------+
                            |
       +--------------------+--------------------+
       |                                         |
+------v------+      +------v------+      +------v------+
| Zone 1 PC-1 |      | Zone 1 PC-2 |      | Zone 2 PC-1 |
| Local Admins|      | Local Admins|      | Local Admins|
| zone1_op    |      | zone1_op    |      | zone2_op    |
+------+------+      +------+------+      +------+------+
       |                                         |
       v                                         v
   Zone 1 equipment                      Zone 2 equipment
   (controlled by                        (controlled by
    zone1_op auth)                        zone2_op auth)

Notice that the server is a member of the same domain group, but the operators in Zone 1 are not added on Zone 2 clients and vice versa. The WinCC project itself, not the domain, enforces the zone separation through the Authorization editor inside User Administrator.

11. Operational Best Practices

• Use one global group. Multiple SIMATIC HMI groups defeat the purpose of central administration; add users to the single AD group and let nested local groups propagate.
• Disable UAC on runtime nodes only. Apply the GPO to a dedicated WinCC OU, not to the entire domain.
• Never recycle Domain Admin. Use a domain user with the minimum rights in SIMATIC HMI plus local Administrators.
• Document the service account in your password vault. Even with a gMSA, document the SPN and the OU location.
• Test after every GPO change. A new Windows update can re-enable UAC or revoke "Log on as service". Add WinCC OU GPO changes to your change-control checklist.
• Use DNS, not WINS or HOSTS files. WinCC server names must resolve forward and reverse in AD-integrated DNS, otherwise Kerberos will fail.
• Plan for DC outage. Operators should be able to log on with cached credentials and start runtime; validate this annually during disaster-recovery drills.

12. Frequently Asked Questions