in administer account and when clicking property on the notification area it gives this app cant open, setting can't be opened using the Built-in Administrator account. When click close it will open setting . This problem was not in 10240. Any idea if there is registry tweak can solve this?
One solution would be to recognize that running the shell with admin privileges (i.e. UAC off) is a stupid idea.
Anyway that problem is frequent also on Win Server 2016, were the use of the admin account is the norm
I read somewhere it's because elevated and non-elevated programs/apps can not talk to each other, for security reasons Something along those lines, I think someone made a hack to fix it though, at least for 8.x
Well using BUILTIN\Administrator isn't really "the norm" in an AD environment (or at least shouldn't be), but I suppose setting UAC to elevate without prompting would take care of that if you really need to run any apps. However, with Server Core now being the preferred way of deployment admins really shouldn't depend on local GUI operations for server management.
Server aren't just servers in big environments, there are the home servers, the storage servers, the essentials and so on. The most concerned admins just rename the Administrator account as something else but hardly are using them with the UAC. frankly, nowadays that even an epilator is powerful enough to run any windows version, the core mania is more a way to impress the clients and to make the admin work to look more difficult than it is. After two decades of inferiority complexes over the *nix colleagues, that's pretty understandable. But really isn't worth the effort, even in virtual environments where the deduplication makes negligible also the space gained. Personally I always install the full version and, if it's the case, I just use cmd.exe or powershell as system shell, to get the best of both worlds.
I didn't mention the metro apps. Simply the new setting doesn't work, and there isn't any justification for that. It's a just a stupid bug, period. I know perfectly the reasons (and the supposed reasons) behind the core usage. But still I have to find any decent reason that makes the core only superior to the disabled gui, once all the configs are done. I'm still one of the people who thinks that the computers should be built to help the humans, sysadmins included. And frankly pushing the voice/face recognition on one side while removing the GUI on the other, to me seem just a contradiction, pushed for reasons that has a lot of to do with trends and little to do with the real evolution. Removing the gui as a security reason is something like removing the stering wheel from a car as an anti theft measure.
Well they certainly consider app containers only working with UAC behavior by design. That's not going to change, except that maybe I could see them make an exception for Settings; actually that would make sense. We'll see. Really? Here's what comes to mind to me: Fewer potential security vulnerabilities due to reduced attack surface Increased VM density due to lower OS overhead Less work spent on maintenance and patch testing, due to fewer serviceable components Less downtime due to fewer reboots "Once all the configs are done" what use does the GUI have on a server that runs headlessly? Anyway, you've still got graphical interfaces for management tasks in the form of remote management tools or web UIs. It's not really a contradiction though since the two approaches apply to different usage scenarios; you're still free to choose anyway. And the more appropriate car metaphor to me would be to remove the GPS receiver and nav screen for drivers who know their way. Or to remove a tow-bar if they aren't ever going to haul a trailer. Just less unnecessary stuff to have around.
Absolutely agree with these guys, who said - "there is no solutions", only clean reinstall, because Your Windows is damaged and there isn't really any other solution. Also sfc or dism does not help you, if you have Windows 10.
Yeah that is the only solution to your problem in my opinion ! I have been strugling with this problem on server 20116 it is a pain in the ass and in the latest build they fixed it I believe
Only fix I know is to lower the account that defeats the propose. New to windows 10586 to allow right click of admin with no error message (lowers the account and not much sense) Local Security Policy - Run "secpol.msc" Local Polices / Security Options / User Account Control: Admin Approval Mode for built-in administrator account: Enable As you mention it does not exist in 10240. It opens after it throws the blue error screen. Not much of a security feature if it opens and more of a bug that it throws the blue screen before it opens. I see it as being implemented to deter people from using the administrator account. Anyway how many times do you go into settings each day after you toggle 600 privacy settings that even exist in the administrator/server set up . Now that is more of a security issue to me than running the settings GUI. Regards
It is a bit funny that it runs no problem through the start menu it is just the right click on desktop/toolbar that gives the error. Regards
This depends on what's running, not on what's installed on disk. And anyway if the server OS are sold with the GUI must work and must be secure with the GUI enabled. Shifting the responsibility of the server safety from MS to the Admins is a way too handy of doing business. As I said this is not a problem at all, the space spared is negligible, the other resources spared are inexistent if you disable the GUI, when needed That's debatable. I saw people who spent days trying to configure the remote administration from clients outside the domain. Having days or months spent to learn how to solve a problem already solved, that's a waste of resources. No matter how much MS ape Unix, Windows is still not unix. The remote administration and the headless servers are still alien concepts, being stuck on the preexisting GUI environment and not born natively. That's true but it's usually a relative problem on SOHO environments, and is practically inextistent on larger scenarios, where the high availability is implemented since the beginning. No matter if a single server si down because an HW fault or because a scheduled reboot. But even w/o taking that in account, most servers are virtualized, there isn't any dead time because the BIOS self test, the SSDs and 15000 rpm platter disks are absolutely common and so on. The result is that 10 years ago a rebooted server could mean 10+ minutes of downtime, nowadays a server can reboot in less than 15 seconds, and can have all the services up and running again in less of one minute.
Try this (Works in Win8.x): Copy the code in notepad and make .reg file. Run it and reboot. Code: Windows Registry Editor Version 5.00 ; Enable Metro Apps to Work on In-Built Administrator Account with UAC Prompt Disabled (Requires Reboot) [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "EnableLUA"=dword:00000001 "FilterAdministratorToken"=dword:00000001 "ConsentPromptBehaviorAdmin"=dword:00000000 "ConsentPromptBehaviorUser"=dword:00000000 "PromptOnSecureDesktop"=dword:00000000
Hi you can try this one. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System •Create a DWORD value if it doesn’t already exist called FilterAdministratorToken •Set the value to 1 Next we need to navigate to the registry and make an additional change: •HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\UIPI\ •Change the Default string key to 0x00000001(1) then restart your computer.