Setup created using Inno Setup 6.0.3 does not auto-restart Windows 2019 with default UAC settings

[vire...@gmail.com]

I have created a setup using Inno Setup 6.0.3 which requries to automatically restart Windows 2019 Server at the end.

However if the UAC setting are set as follows -

       User Account Control Setting: Notify me only when apps try to make changes to my computer (default)

And the user starts the setup by double clicking on the setup file in Windows explorer and then chooses  "Yes, restart the computer now" then I get the following error - 

      "Setup was unable to restart the computer. Please do this manually"

I have include the required [Setup] directives PrivilegesRequired and AlwaysRestart

[Setup]

PrivilegesRequired=admin

ChangesEnvironment=yes

AppName={#MyAppName}

AppVersion={#MyAppVersion}

DefaultDirName=test\MyProduct

AlwaysRestart=yes

The setup log does show that Inno setups code to restart Windows is called. 

2019-11-25 01:28:22.755   Process exit code: 1

2019-11-25 01:28:22.976   Need to restart Windows? Yes

2019-11-25 01:28:25.083   Deinitializing Setup.

2019-11-25 01:28:25.087   Restarting Windows.

2019-11-25 01:28:25.098   Log closed.

However the API ExitWindows fails since inno setup failed to elevate permission hence Windows does not start and the above mentioned error message is shown.

Note: 

• Also if I explicilty run the setup by right click "Run as admin" then the automatic works fine.
• If UAC is turned off i.e set to "Never notify..." then auto restart works even when user starts the setup by double clicking on the setup file in Windows explore.
  

Is this a known issue OR am I missing something in the [Setup] directives?

[abq...@gmail.com]

On Monday, November 25, 2019 at 2:44:35 AM UTC-7, vire...@gmail.com wrote:

I have created a setup using Inno Setup 6.0.3 which requries to automatically restart Windows 2019 Server at the end.

...

Also if I explicilty run the setup by right click "Run as admin" then the automatic works fine.

I don't know the answer, but I would guess that it has something to do with the difference between the installer relaunching itself elevated vs. the end user starting it elevated in the first place. I agree that the behavior you describe seems unexpected.

My other question is: Why does your installer demand a restart? (This would greatly annoy me as a system admin and would need a very strong justification.)

Bill

[Bernd Bührer]

Have you found a solution to the reboot not working issue by now?

[Eivind Bakkestuen]

Have you tested the latest version?

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/86ed530a-1d1b-4974-b5d3-e7affd5db5acn%40googlegroups.com.

[Bernd Bührer]

Yes, i have the latest version 6.5.3

[Bernd Bührer]

When I start the setup, I can see with the ProcessExplorer-Tool that it consists of an outer Setup.exe and an inner Setup.exe. The inner has admin rights, the outer doesn't! Could it be because the external setup wants to restart and doesn't have admin rights to do so? Then the problem would have to be solved by InnoSetup.

[Bernd Bührer]

On Windows11 it works with the restart (AlwaysRestart=yes), but under Windows Server 2025 it will not work! The user ist prompt to restart the computer itself.

How can i change this?

On all Windows-systems the windows should restart at the end of the setup.

[Eivind Bakkestuen]

To me, it makes total sense that a Server OS is *not* automatically rebooted when an installer runs. Are you sure your users really want their servers to unconditionally reboot?

To view this discussion visit https://groups.google.com/d/msgid/innosetup/3c44a003-c9e2-4ed3-af5b-8bf8d5514499n%40googlegroups.com.

[Jordan Russell]

On 10/1/2025 7:08 AM, 'Bernd Bührer' via innosetup wrote:
> When I start the setup, I can see with the ProcessExplorer-Tool that it
> consists of an outer Setup.exe and an inner Setup.exe. The inner has admin
> rights, the outer doesn't! Could it be because the external setup wants to
> restart and doesn't have admin rights to do so? Then the problem would have
> to be solved by InnoSetup.

Are you logged into the server with a standard user account or an
administrator account?

It is indeed the case that the restart is initiated by the outer,
non-elevated setup.exe process. I had *thought* that just being logged
in with an administrator account would be enough to restart, without
needing elevation, but maybe not. If you run "shutdown /r" from a
non-elevated Command Prompt, does it also fail?

-JR

[Jernej Simončič]

On Thursday, October 16, 2025, 11:40:01, Jordan Russell wrote:

> It is indeed the case that the restart is initiated by the outer,
> non-elevated setup.exe process. I had *thought* that just being logged
> in with an administrator account would be enough to restart, without
> needing elevation, but maybe not. If you run "shutdown /r" from a
> non-elevated Command Prompt, does it also fail?

On Windows Server you need to initiate restart from elevated prompt, otherwise you get back Access is Denied.(5)

--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >

A man should be greater than some of his parts.
-- Mother Sigafoos's Observation

[Bill Stewart]

On Thursday, October 16, 2025 at 7:49:22 AM UTC-6 Jernej Simončič wrote:

On Windows Server you need to initiate restart from elevated prompt, otherwise you get back Access is Denied.(5) 

IIRC, I believe you need the enabled SeShutdownPrivilege privilege to reboot, and the default group assignment of this privilege is different between a "server" (Administrators) and a "workstation" (Users).

[Bernd Bührer]

But why doesn't Innosetup use elevated privileges when i set the "PrivilegesRequired=admin"?

[Bernd Bührer]

I'm logged into the server (Windows Server 2025) with an administratir account.

When i run "shutdown /r" from a non-elevated Command Promt, then it fails with "acess denied".

So InnoSetup would have to request elevated-privileges when it starts and "PrivilegesRequired=admin" is set!

But it doesn't.

In my opinion this needs to be changed in InnoSetup.

[Bill Stewart]

On Friday, October 17, 2025 at 2:55:41 AM UTC-6 Bernd Bührer wrote:

But why doesn't Innosetup use elevated privileges when i set the "PrivilegesRequired=admin"?

It does. From the documentation[1]:

When [the PrivilegesRequired directive is] set to admin (the default), Setup will always run with administrative privileges and in administrative install mode. If Setup was started by an unprivileged user, Windows will ask for the password to an account that has administrative privileges, and Setup will then run under that account.

(The exception to this, I would think, is if the package was previously installed in non administrative installation mode.)

[1] https://jrsoftware.org/ishelp/index.php?topic=setup_privilegesrequired

[Bill Stewart]

On Friday, October 17, 2025 at 3:49:21 AM UTC-6 Bernd Bührer wrote:

When i run "shutdown /r" from a non-elevated Command Promt, then it fails with "acess denied".

This is normal and expected. 

[Jordan Russell]

On 10/17/25 4:49 AM, 'Bernd Bührer' via innosetup wrote:
> So InnoSetup would have to request elevated-privileges when it starts and "
> PrivilegesRequired=admin" is set!
> But it doesn't.

There are typically 4 processes running:

1. setup.exe, non-elevated (Started by the user)
2. setup.tmp, non-elevated
3. setup.exe, elevated
4. setup.tmp, elevated

Process 1 starts 2, 2 starts 3, and 3 starts 4.

The actual installation (including the wizard UI) runs in process 4,
which is elevated.

When the installation completes and you click Finish, process 4 exits,
then process 3 exits, then process 2 exits, then process 1 initiates the
restart.

Since process 1 isn't elevated, the restart fails on Windows Server.
This seems to be a new-ish problem, as Windows Server used to ship with
UAC disabled by default.

I see two possible solutions:

(1) If process 1 doesn't possess the shutdown privilege, then instead of
calling ExitWindowsEx directly, it could run "shutdown.exe /r" with
elevation. This would however cause a UAC dialog to appear, saying:

Windows Shutdown and Annotation Tool
Publisher: Microsoft Windows

(2) Process 3 could initiate the restart. This avoids showing another
UAC dialog, but is a more invasive change, because the processes would
have to exit in a different order (2, 1, 4, 3) to ensure that the first
2 processes don't block the shutdown and that all temporary files are
cleaned up properly.

But solution 2 still wouldn't work when PrivilegesRequired=lowest
because in that case no processes are elevated. So "shutdown.exe /r"
would be needed there, or that case could just be unsupported, because
why would a per-user install need to restart the whole system?

I kind of like solution 1 more because the processes still exit in their
natural order (4, 3, 2, 1). The extra UAC dialog is a little annoying,
but do users really care?

Will keep looking into it...

-JR

[Jernej Simončič]

On Saturday, October 18, 2025, 01:06:48, Jordan Russell wrote:

> Since process 1 isn't elevated, the restart fails on Windows Server. This seems to be a new-ish problem, as Windows Server used to ship with UAC disabled by default.

UAC has been enabled on Server at least since 2008 R2 (don't have any non-R2 to test); however the Administrator user gets special treatment with UAC being disabled for it (I think it's the same on desktop windows, except those ship with Administrator account disabled, so you don't notice that).

--
< Jernej Simončič ><><><><>< https://eternallybored.org/ >

For every credibility gap there is a gullibility fill.
-- Clopton's Law

[Bill Stewart]

On Friday, October 17, 2025 at 5:07:00 PM UTC-6 Jordan Russell wrote:

But solution 2 still wouldn't work when PrivilegesRequired=lowest
because in that case no processes are elevated. So "shutdown.exe /r"
would be needed there, or that case could just be unsupported, because
why would a per-user install need to restart the whole system?

FWIW, I would not expect a per-user installation to be able to reboot the system if the install wasn't running elevated.

I kind of like solution 1 more because the processes still exit in their
natural order (4, 3, 2, 1). The extra UAC dialog is a little annoying,
but do users really care?

This seems quite sensible to me. It seems to me that a UAC prompt to reboot would be expected if installing interactively.

(As a side note: The ability to reboot should be there, to be sure, but how many installs really need to reboot in the first place?)

[Gavin Lambert]

On Saturday, October 18, 2025 at 12:07:00 PM UTC+13 Jordan Russell wrote:

(2) Process 3 could initiate the restart. This avoids showing another
UAC dialog, but is a more invasive change, because the processes would
have to exit in a different order (2, 1, 4, 3) to ensure that the first
2 processes don't block the shutdown and that all temporary files are
cleaned up properly.

If the processes exit quickly enough after requesting the reboot, wouldn't it still be possible to exit them in the normal order?  Especially if process 3 sends some "I'm about to reboot, stop rejecting session exit requests" message to processes 1 & 2 -- though even that probably isn't needed, as Windows will ignore those if they take too long anyway, and the grace period it does allow should permit them to clean up and exit, I would think?