Open-shell-menu: 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.

[ghost]

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 https://github.com/Open-Shell/Open-Shell-Menu/issues/125#issuecomment-458180941

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.

[Ibuprophen]

@Moopere, I had just removed the label and, please keep in mind, to follow up with this within a reasonable amount of time to keep this issue open.

I just hate to have an issue open for a long stretch of time without any activity, discussion, etc...

Also, the OP Issuer, @paraworlds2, has not followed up on this issue for quite some time either.

Thank you very much for your time and understanding with this. 👍

~Ibuprophen

[MorleyGit]

Just to say I too have this problem and have used the group policy fix as a workaround. I've also voted in the MS feedback hub.

[freezerdev]

I am seeing this same issue, but on Windows 10 1903.

I'm glad I found this thread, at first I thought I was going crazy - why is OpenShell not shutting down or rebooting? At least now I know I'm not alone.

[Ibuprophen]

This issue is duly noted for looking into...

~Ibuprophen

[blackcrack]

@Ibuprophen
ibo, is this working with shutdown.exe or directly in code ?
Maybe it's better if we use by logout, powerdown and reboot the shutdown.exe
and therewith with onboard resources of winnt , if this directly as command for windows extra programmed, therewith can we exclude from the fact that is a bug, because winnt bord own resources should be in 100% works (nope, i don't look on the updates from M$ *g* ) and that in different version of windows.. ( is the shutdown.exe also in WinXP/Server2003 ? i guess .. uhhh should a bit work with XP too again *bg*)

best regards
Blacky

[Ibuprophen]

@blackcrack, sorry for the delay...

I believe that the following is where the registry entry is made that reflects the shutdown command...

https://github.com/Open-Shell/Open-Shell-Menu/blob/master/Src/StartMenu/StartMenuDLL/SettingsUI.cpp

... Maybe @ge0rdi, @coddec and/or @XenHat can confirm/deny/clarify this.

I've recently been bouncing on and off various items on the Repo.

~Ibuprophen

[blackcrack]

oh, 1006 around ..

holy, i had almost become a heartattack because the long waiting *BG* *giggle*
AAAAll okey Dude :)

edit: ^^ This was a joke !

[rhollenbeck700]

Open Shell 4.4.135 has the fix in place to shutdown 2019 server both that were migrated from 2016 and clean installs. While it is a beta it has been running fine.

[ge0rdi]

@rhollenbeck700
That is quite interesting, because I'm not aware of any such fix done in Open-Shell 😕

[bkraul]

@geordi Interesting, indeed. I have been using 4.4.135 for months now, and the issue has persisted for a while. Handling it through policy as it was originally reported for workaround.

[rhollenbeck700]

When I looked at my rsop on the 2019 servers, they were properly seeing the local administrators group which the domain admins are part of. So I didn't have to modify either the GPO or the local ones. However with 131 the problem was still there. Uninstalled 131 and installed 135, problem gone. The problem was also there with ClassicShellSetup_4_3_1 as well and uninstalling it and installing open 135 fixed it.

[Ibuprophen]

I'm just curious as to a little clarification for myself and @ge0rdi on the mentioning/reference to "Fixes"...

Is this actually some type of "Workaround" being referred to as a "Fix"?

Or even another, unrelated "Fix", that had possibly (inadvertently) resolved the issue somehow?

If there's any information on another issue and such that provided some type of workaround, please let us know.

I just don't want this to become a huge confusion...

~Ibuprophen

[rhollenbeck700]

I can only speak for myself. If I removed classic shell / open shell I could from the server console (both physical and virtual) shutdown the 2019 servers (migrated from 2016 and clean install). With ClassicShellSetup_4_3_1 or Open Shell 4.4.131 on the 2019 servers I could not. Installed Open Shell 4.4.135 and I could shut it down. Both my GPO and local policies were already correct. I also have the latest 2019 templates for GPO installed on my DCs. In most cases 2016 base code is Win 10 1607 and 2019's base code is Win 1809 with the GUI version not core.

[rhollenbeck700]

Oh and when doing the migration from 2016 to 2019 or Win 10 all versions before 1809 to Win 1809/1903 don't forget to cleanup the live tile keys not in use anymore and get rid of the 1534 error !

Code 1534, "Profile notification of event Load for component {B31118B2-1F49-48E5-B6F5-BC21CAEC56FB} failed, error code is See Tracelogging for error details"

is the tileobjserver, which is related to the tiledatasvc.

Now that last one, has been removed from 1809, its no longer a "feature".

1. Open Regedit and navigate to the following two keys
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileNotification
   HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\ProfileNotification

   1. Under ProfileNotification check if you have the TDL key
   2. Export the TDL key at each location
   3. Delete the TDL key at each location
   4. Reboot PC to verify

   Note:
   
   You'll need take ownership of the TDL Key to be able to delete it.1.Right-click on the key, select Permissions and add the current user with FC as well.