Restart/shutdown ignored in Windows 2019

[paraworlds2]

I just upgraded my server from Windows 2016 Standard to Windows 2019 Standard and now I can't restart/shutdown my computer using Open-Shell with any user except for the original user that installed Windows 2016 and Classicshell. When I click restart, nothing happens and I don't get any errors. I can, however, restart the computer using a command prompt (e.g. shutdown /r) or using the shut down tools from Ctrl-Alt-Del from any of my admin users. I'm guessing there's a permissions issue somewhere.

So after lots of testing, here is what I found:

I originally installed Windows 2016 and ClassicShell from a local admin account (let's call it LocalAdmin) but then I later upgraded to Open-Shell from a domain admin account (let's call it DomainAdmin). After Windows 2019 (which I did from the DomainAdmin account), I cannot restart the computer from DomainAdmin (or any other accounts, including other local admins, LocalAdmin2, and another domain account, AdminDomain2, that had never logged into the server before) but I can restart from LocalAdmin.

I uninstalled Open-Shell and was able to use the native start to restart from any account. I then installed Open-Shell from AdminDomain2 but nothing changed. Remnants of Classic-Shell might have remained with the LocalAdmin as their Owner or there might be other windows files that only work with the original installation account.

I did get this issue below after the Windows 2019 upgrade and I was able to recover from it by logging into the local Administrator account and clicking the restart button. I can't imagine the Windows Update feature being affected by Open-Shell, but now the only restart method that doesn't work is Open-Shell.
Note that I uninstalled the post-2019 cumulative update but that didn't help.
https://www.youtube.com/watch?v=x1WEppvzjgk
Error: "Awaiting restart to finish install the updates. When i click Restart now, error occurred. We're having trouble restarting to finish the install. Try again in a little while. Error code: 0x8024a112"

To make this even longer, I did get an "Access is denied" in my event logs and when I looked it up, I found this link regarding the start menu having an issue after an windows upgrade. Not sure if this is related.
https://answers.microsoft.com/en-us/insider/forum/all/critical-error-start-menu-and-cortana-arent/746d57f4-95b0-4c64-be92-2614e8c9584a?page=30
Here's the error in my event viewer. I got 7 of these but then they went away.
"ShellExperienceHost (10504,P,98) TILEREPOSITORYS-1-5-21-3460657350-6793805-2685302175-1839: An attempt to open the device with name "\.\C:" containing "C:" failed with system error 5 (0x00000005): "Access is denied. ". The operation will fail with error -1032 (0xfffffbf8)."

[paraworlds2]

I just upgraded a second 2016 server to 2019 and had the same issue as before, where none but my original user account can restart the server using Open-Shell. This time I upgraded the OS from the original user account that had installed windows and ClassicShell but there wasn't any difference. Note that it did pop-up that it needed to re-configure Open-Shell, which happens after every major upgrade.

[BobbyD-FNG]

I have the same issue. Originally using Classic Shell v4.3.1. Created a new VM template of Win2019. The first/local user worked fine, but after I added it to the domain, the shutdown/restart would not work for any other users.

So I upgraded to Open Shell hoping that would fix the situation, but it did not. I can select "Windows Security", use the command prompt, ctrl-alt-delete, or exit OpenShell and reboot/shutdown will work just fine. It just won't work with OpenShell. I don't see any errors in Event Viewer. Hoping someone can figure this out!

[paraworlds2]

BobbyD-FNG, I tried what you did and got the same results. From a fresh installation of Windows 2019, restarting the computer from Open-Shell worked fine on the first user (Administrator) but would not allow me to restart the computer on subsequent users. I don't have any Windows updates to see if it'll let me restart from that screen but I'm curious about that as well. I can't imagine Open-Shell actually affecting the reboot button of the Windows Update screen but perhaps it does. Either way, on my original post, neither way worked. I can still reboot with a command prompt.

[Ryushin]

I'm seeing the same behavior. Workaround for me is to click Start, Windows Security, then the 1/0 in the bottom right hand corner to reboot.

[BobbyD-FNG]

I built a non-VM Win2019 server from scratch to do some more testing. After building it, I did NOT install OpenShell until after I added the server to the domain. I installed OpenShell as domain\Administrator. I can reboot/shutdown with both domain\Administrator and local\administrator. But when I log in as a domain admin user or with a user that is in the local admin group, I can NOT reboot/shutdown.

So I put the reboot/shutdown issue off for the moment and installed Symantec Endpoint Protection (SEP) v14.2.1031.0100. What I noticed after installing SEP is that "Server Manager" (SM) will NOT start for any admin user EXCEPT for domain\Administrator and local\Administrator. If I start it with any other admin user, it just hammers 1 CPU to 100% and never starts. While looking into this issue, I discovered that a policy setting would fix both the SM and OpenShell issues...

Start GPEDIT and go to:
-Computer Configuration

• Windows Settings
  • Security Settings
    • Local Policies
      • Security Options
        • User Account Control: Run all administrators in Admin Approval Mode
          • Change from the default of "Enabled" to "Disabled"

Both the SEP and OpenShell issues seem to be related to "Admin Approval Mode". I'm not suggesting that it be left "Disabled" (this would make the OS less secure), I'm just providing info as to what might be causing the issue. Simply setting the UAC to the lowest setting does NOT fix either issue. I've experimented by toggling the GPEDIT setting from Enabled to Disabled and back and the behavior is consistent.

Hope this sheds some more light on the situation.

[Ryushin]

Good find. I set up a group policy for the domain and working great for Domain Admin users.

Same issue for me, not connected to a domain but also running SEP

[maraakate]

The reason this fails is because non-local Administrator account for some reason does not have SeShutdownPrivilege. Verify this with whoami /priv in a NON-ELEVATED command prompt.

I don't know how microsoft is making this work via explorer.exe.

[maraakate]

I found a work around for this problem without having to disable UAC:

Windows Server 2016 by default has the following privileges for an Administrator

• Shut down the system
• Remove computer from docking station
• Change the time zone

Go to gpedit.msc -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assessments

For each of the above mentioned privileges add your user to these. You probably could just add "users" if you wanted to make sure everyone has access to this. Do a gpupdate /force, then logoff and log back on. You should now be able to shutdown and restart (as well as be able to undock your machine and change the timezone). I noticed the timezone issue in Server 2019 when logged in as a domain admin.

It appears that Administrators group is broken for the non-built in for some of these privileges in 2019.

[maraakate]

I reported this on the feedback hub for Microsoft, please vote for it: https://windowsserver.uservoice.com/forums/295047-general-feedback/suggestions/37397422-seshutdownprivelege-seundockprivelege-and-setime

[BobbyD-FNG]

Great find. I feel much better about adding the specific users to the "User Rights Assessments" versus turning off the "Admin Approval". I have also put my vote in at the feedback hub.
Thanks!

As a side note, I found the issue with Symantec is only when the more advanced features are installed. If it is installed as basic "AV only", the Server Mangler will start fine.

[maraakate]

Hi Bobby,

I don't use Symantec. Honestly, don't really bother with the server manager. Usually use install-windowsfeature via powershell for most things. :)

[Ibuprophen]

This issue seems to be more of a Windows issue whereas someone has figured out a way to get the software to work...

Am I correct to assume that this is a resolved issue?

~Ibuprophen

[Moopere]

I don't think its resolved - I think a workaround is in place as per #125 (comment)

For mine, this was the last straw that broke the camels back - I've disabled UAC from all my servers now as it just creates a huge mess for little observable benefit.

There must be a reason why Win10 1809 doesn't suffer this problem yet Server 2019 does. Probably related to the default policy settings per the post above.

I wouldn't close this task just yet - it remains to be seen if MS will fix the brokenness surrounding the Administrators group in Server 2019. Its a pretty serious problem (for them) and I just threw my hands in the air as I say above and removed UAC. If they don't fix it though, and are not going to, then it will fall back on third party products (like openshell) to program in work-arounds for the base products failings.