Resolving TIA Portal V16 Installer Reboot Loop After Privilege

Problem Overview

Engineers and integrators installing SIMATIC TIA Portal V16 (including V16 Update 1) on Windows 10/11 workstations frequently encounter a circular installation failure when running the setup under an account that does not have native Administrator rights. The Siemens Installer Assistant (SIA), which is the bootstrap process behind every TIA Portal, WinCC, STEP 7, and Startdrive install, requires elevated privileges to write to C:\Program Files (x86)\Common Files\Siemens and to update system services such as S7Help, ALM (Automation License Manager), and the Siemens PLM License Server.

When the SIA detects that a file replacement cannot be performed while the OS is running, it requests a reboot to complete the pending operation. The boot cycle, however, drops the elevated (UAC) token that the user obtained when launching the original installer. After the restart, the SIA starts under the standard user context, fails its privilege check, and the engineer is left with a dialog that again demands a reboot, or with a setup that silently rolls back. Re-running the assistant from an elevated shell with the documented start.exe parameters often re-arms the pending-file-rename list and produces the same loop.

This article documents the root cause, the exact registry mechanism that drives the loop, and the field-proven procedure to break the cycle and complete the install. It applies to TIA Portal V16.0, V16 Update 1, V16 Update 2, and similar SIA-based installation packages (build 407 of the SIA is referenced throughout the examples because it is the bootstrap version shipped with the TIA V16 media).

Symptoms and Error Behavior

The following reproducible symptoms characterize the elevation/reboot loop on TIA Portal V16 setup:

• The SIA starts, extracts the bundle, and displays a setup window that requests a Windows restart with the message "A system restart is required before continuing the installation."
• After the PC reboots, no SIA window opens automatically. The user has to launch the assistant manually.
• Launching the assistant by double-clicking start.exe in C:\Program Files (x86)\Common Files\Siemens\Automation\Siemens Installer Assistant\407\ fails silently or displays "You do not have sufficient privileges to start the service."
• Launching the same start.exe with Run as administrator and the original /afterreboot /bundlepath= parameters, for example:
  C:\Program Files (x86)\Common Files\Siemens\Automation\Siemens Installer Assistant\407\start.exe /I1033 /afterreboot /bundlepath="C:\Temp\SIMATIC_TIA_V16.0_Upd1\InstData"
  either re-arms the pending reboot, or returns immediately with another restart request, producing the infinite loop.
• Removing the /afterreboot switch from the command line has no effect because the SIA detects the still-pending PendingFileRenameOperations list in the Windows registry and re-inserts the request.
• Event Viewer » Application shows MSI Installer warnings with event ID 1004 or 1001 and source MsiInstaller indicating that a file could not be replaced because it was in use.

Root Cause Analysis

The TIA Portal bootstrap is a two-stage process. The SIA extracts the install bundle to a temporary path (commonly %TEMP%\Siemens\SIA or the path passed via /bundlepath) and then schedules a number of MoveFileEx calls with the MOVEFILE_DELAY_UNTIL_REBOOT flag. The MoveFileEx API causes the Win32 subsystem (specifically the Session Manager, smss.exe) to add entries to the multi-string registry value PendingFileRenameOperations located at:

When the user reboots, the Session Manager consumes that value during boot and renames/deletes the files. If the rename succeeds, the SIA normally resumes after the reboot and finishes the setup.

The loop is triggered by two independent issues that compound each other:

1. UAC token is not persisted across reboot. Even when a user is a member of the local Administrators group, the elevated token produced by consent.exe is not retained across a sign-out or restart. After the reboot, the SIA starts in the standard-integrity context and cannot perform the file replacement that the previous elevated run scheduled. The Session Manager then re-marks the rename as pending.
2. The PendingFileRenameOperations value is never cleared by the SIA itself. If the SIA cannot complete the rename (for example, because another process that holds the file has been respawned automatically, such as the ALM service, the S7DOS service, or an anti-virus product), the registry value remains in place. On the next SIA launch, the bootstrap reads the value, sees the operation is still pending, and re-issues the reboot request. This is why removing /afterreboot does not help: the SIA consults the registry, not the command line.

The correct resolution is therefore to clear the orphaned registry value while the SIA and all related services are stopped, then re-launch the bootstrap from a fully elevated shell. The SIA then runs through the install without re-arming the pending list, because the prerequisite file operations are no longer in the registry.

Affected Products and Versions

The same root cause applies to TIA Portal V15.1 (SIA 405/406), V17 (SIA 412), and V18 (SIA 415). The build number in the path increments with each major release.

Prerequisites

Before applying the resolution, confirm that the following prerequisites are met. Skipping these is the most common reason the loop re-occurs even after the registry has been cleared.

1. The installing user must be a member of the local Administrators group. Verify with:
   net localgroup administrators | findstr /i "%USERNAME%"
2. User Account Control (UAC) must not be set to the lowest notification level ("Never notify"). If it is, the SIA may launch with the standard integrity token and silently fail the privilege check. Use the default level 3 (notify on changes to the desktop) or level 2 (notify on program installs).
3. All Siemens services must be stopped before clearing the registry. Open an elevated cmd.exe and run:
   net stop "S7Help" /y
net stop "ALM" /y
net stop "s7oiehsx" /y
net stop "SimaticRackService" /y
net stop "StartdriveService" /y (only present on Startdrive installs)
   net stop "Siemens PLM License Server" /y
4. All Siemens processes must be ended. Open Task Manager » Details and terminate SIA407.exe, start.exe, Siemens.Automation.Portal.exe, S7WEBSRV.exe, almsrv64.exe, and any instance of MSBuild.exe started by the SIA.
5. Real-time anti-virus scanning must be temporarily disabled for C:\Program Files (x86)\Siemens and C:\Program Files\Siemens. McAfee, Trend Micro, and Sophos products are known to hold DLLs locked even when the OS reports the file as closed.
6. A full, restorable image of the workstation or a working Veeam/Acronis snapshot is recommended. Although clearing the registry is reversible, an interrupted install followed by an unwanted reboot can leave the TIA install in a partially registered state that is more time-consuming to repair than to roll back.

Step-by-Step Resolution

Apply the following sequence exactly. Each step has a verification check that must pass before continuing.

Step 1 - Stop all Siemens services and processes

1. Open Start, type cmd, right-click Command Prompt and select Run as administrator.
2. Run the following batch:
   net stop "S7Help" /y
net stop "ALM" /y
net stop "s7oiehsx" /y
net stop "SimaticRackService" /y
net stop "StartdriveService" /y
net stop "Siemens PLM License Server" /y
taskkill /F /IM SIA*.exe /T
taskkill /F /IM start.exe /T
taskkill /F /IM Siemens.Automation.Portal.exe /T
taskkill /F /IM almsrv64.exe /T
taskkill /F /IM S7WEBSRV.exe /T
3. Verify with sc query state= stopped | findstr /i "SERVICE_NAME: S7 SERVICE_NAME: ALM SERVICE_NAME: Simatic". The list must be empty.

Step 2 - Back up and clear the PendingFileRenameOperations value

1. Open Start, type regedit, right-click and select Run as administrator. The Registry Editor must run elevated; otherwise the SIA will later fail to read this exact value at startup and the loop will persist.
2. Navigate to:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
3. Right-click the value PendingFileRenameOperations and select Export. Save the .reg file to a path outside %ProgramFiles%, for example D:\Backups\PendingFileRenameOperations_<date>.reg.
4. Open the exported file in Notepad and inspect its content. Each line is a pair of paths: \??\C:\old\path.dll followed by \??\C:\new\path.dll. Files prefixed with !\??\ are scheduled for deletion. Confirm that all entries are paths under C:\Program Files\Siemens, C:\Program Files (x86)\Siemens, or the bundle path. If you see entries for Windows, Office, .NET, or non-Siemens products, do not delete the whole value. Instead, edit the value as a REG_MULTI_SZ and remove only the Siemens lines. The two extra empty lines that delimit a multi-string value must remain.
5. Right-click the value and select Delete. Confirm the prompt.
6. Refresh (F5) and verify the value is gone. The Session Manager will rebuild it on the next MoveFileEx call, so an empty value here is the expected state.

Step 3 - Re-launch the Siemens Installer Assistant as Administrator

1. Reopen the elevated cmd.exe from Step 1.
2. Run the assistant using the same command line the SIA originally produced, but with the /afterreboot switch kept (it is required so the SIA knows the bundle has already been extracted):
   "C:\Program Files (x86)\Common Files\Siemens\Automation\Siemens Installer Assistant\407\start.exe" /I1033 /afterreboot /bundlepath="C:\Temp\SIMATIC_TIA_V16.0_Upd1\InstData"
3. The SIA detects that the pending list is empty, skips the restart prompt, and resumes the install at the next setup dialog.
4. Complete the wizard. Do not cancel; if you cancel partway, repeat Steps 1 to 3 before launching it again.

Step 4 - Verification

After the setup finishes, verify that the install is healthy:

• The setup window displays "Setup was completed successfully." and writes a log to %ProgramData%\Siemens\Automation\Logfiles\Siemens.Automation.Portal.Install.log. The last entry of that log should be Result: Installation succeeded.
• The Start menu contains Siemens Automation » TIA Portal V16.
• The TIA Portal opens without the error "A default license could not be found." when no license is installed, or it accepts an existing license from the ALM.
• The following services are set to Automatic and are in the Running state:
  S7Help, ALM, SimaticRackService, Siemens PLM License Server, and StartdriveService on systems with Startdrive.
• The registry value PendingFileRenameOperations either does not exist or contains only empty lines (the default state).

Why Removing /afterreboot Does Not Help

The /afterreboot switch is a hint to the SIA, not a control switch. It tells the bootstrap "I am being resumed after a reboot that the previous run requested", which the SIA uses to skip the language/destination dialogs and to log into the same install session. The SIA still consults the Session Manager to verify that the prerequisite file replacements have been performed. If the value at PendingFileRenameOperations is non-empty, the SIA ignores the hint and re-arms the reboot. Removing the switch forces the SIA to treat the launch as a fresh run, which extracts a new bundle and overwrites the cached setup state, but it does not change the underlying file-rename backlog. The loop therefore persists.

Command-Line Reference for the SIA start.exe

Registry Key Reference

Alternative Approaches

If the registry-based fix cannot be applied (for example, the workstation is locked down by group policy and the user cannot edit HKLM), consider the following alternatives.

Use a dedicated Administrator account for the install

Create a local account named tiaadmin that is a member only of the Administrators group, sign out of the original user, and sign in as tiaadmin. Run the install from that account. Because tiaadmin has no standard-user session components that the UAC must elevate, the post-reboot context remains in the Administrators group and the SIA can complete the install. After the install, the tiaadmin account can be disabled or removed.

Use the TIA Administrator on EPM systems

On workstations managed by Ivanti / BeyondTrust / CyberArk EPM, the Siemens install is blocked because the EPM agent strips the elevated token at session start. Siemens documents a separate workflow for these systems in which the TIA Administrator V3 is installed first and the install is performed by a privileged account that the EPM has whitelisted. See the official Siemens support entry What do you need to consider when installing the TIA Administrator on Endpoint Privilege Management active systems? for the precise whitelist keys and account-creation steps.

Use Sysinternals PsExec to launch a System-level shell

As a last resort, launch the SIA from a SYSTEM-level shell using PsExec. This bypasses UAC entirely. The command line is:
PsExec64.exe -s -i -d "C:\Program Files (x86)\Common Files\Siemens\Automation\Siemens Installer Assistant\407\start.exe" /I1033 /afterreboot /bundlepath="C:\Temp\SIMATIC_TIA_V16.0_Upd1\InstData"
This approach is unsupported by Siemens and is only recommended when the workstation is destined for disposal after the install.

Preventing the Loop in Future Installs

1. Always launch the TIA setup with a right-click » Run as administrator from the original user session, even if UAC is configured to auto-elevate members of the Administrators group. Some Windows 10 builds (especially 21H2) fail to auto-elevate the SIA because its manifest does not declare requestedExecutionLevel as requireAdministrator.
2. Disable anti-virus real-time scanning for the duration of the install. Re-enable it after the setup completes.
3. Make sure no other setup (Windows Update, .NET cumulative, Office C2R) is running concurrently. Concurrent setups can each write to PendingFileRenameOperations and interfere with each other.
4. Free at least 25 GB on the system drive before the install. TIA V16 requires up to 22 GB of working disk space for the bundle, the install, and the cached MSIs.
5. Use a clean user profile (no roaming profile, no mandatory profile) for the first install. Profile redirection can prevent the SIA from writing the LastInstallResult value to HKCU, which causes the next launch to re-evaluate the pending list.
6. After the install, lock the workstation instead of signing out or restarting. The standard-integrity session is preserved across the lock and the install can be completed in the next run.

Troubleshooting Matrix

Frequently Asked Questions