Administrator Privileges problems

I don't think there's any account on W10 that can directly do everything. No matter you're a member of the administrators group, the administrator user or the system user... and this was the case with W2000 already, and probably WNT4 too.

Now back to your case, it's very possible that disabling UAC is the cause of the problem. The UAC-elevated environment is somehow "normalized", i.e. doesn't depend on the calling user for the most part. As an example, in the old pre-UAC times (before Vista), suppose you had two admin accounts Alice and Bob, creating a file in a directory such as Program Files wasn't different than creating one on your desktop, it would have a different security descriptor (i.e. owner and ACL) depending on the admin account used. Disabling UAC makes this happen again.

Anyway, you should have a look at the ACLs of 1:the file you're trying to remove and 2:its parent directory. Unlike it seems, the parent directory is likely not your desktop, but the public desktop : "C:\Users\Public\Desktop". You can check the ACLs either from the security tab in the file/directory properties, or from the command line, typing icacls <file/directory path>, e.g. icacls "C:\Users\Public\Desktop". The advantage with an icacls output is that it's easier to copy/paste here.

Knowing the owner of the file and its parent directory can be useful too, since the owner can modify the ACL of the owned file/directory at will, no matter what the explicit ACL is (except in one case, if the OWNER RIGHTS special entry denies that). You can get the owner from either the advanced button of the security tab, or from the command line with the dir /Q command.

Mystere said:

Well, that may in fact be your problem. When you disable UAC, or enable and disable it at various times, different objects are created with different permissions, and you can basically end up with an unmanageable mess of ACL's assigned to things, with varying degrees of accessibility.

I'm not sure where you are getting this, but if you feel this is true, you may have some other issues going on. Disabling UAC can expose a user to threats, but it doesn't cause any issues with the existing system.

DeaconFrost said:

I'm not sure where you are getting this, but if you feel this is true, you may have some other issues going on. Disabling UAC can expose a user to threats, but it doesn't cause any issues with the existing system.

It can. The reason is related to how UAC works. It has a function called "folder virtualization" among others. Let's say you install an app that assumes it can write to the System folder, or to Program Files. UAC causes these file writes to be redirected to a different location, that is "virtualized". If you then turn off UAC, the app tries to read the files from the real locations instead of the virtual ones, causing a number of kinds of problems. This is just one example, there are tons of other situations in which UAC subtly changes the way permissions are created, ACL's are created, etc..

I have to say this is honestly the first I've ever heard of this, and haven't found anything on line to back up the claim. I've disabled UAC on some systems long after the system has been installed and have never come across a single issue...and I'm probably talking about roughly 100 systems from 7 up to 10.

What Mystere mentions does exist, it's called UAC Virtualization. That feature was designed to keep legacy programs running, since programs that try to write to protected areas are considered legacy. UACV is automatically activated for some programs only, the criteria are :

1. The program must be 32-bit
2. It must have either no manifest, or a manifest with no RequestedExecutionLevel tag

Then UACV is activated. You can notice that in the task manager, under the Virtualization column. The failed writes to some directories (among which are Program Files (x86) and Program Data) are then redirected to a per user location, which on the system drive is %LOCALAPPDATA%\Virtualstore. Failed writes to selected registry places such as HKLM\Software are redirected too, the redirection is made to HKCU\Software\Classes\Virtualstore.

It can even be forced on non automatically eligible programs, and the list of designated directories/registry keys can be extended too.

Exists, maybe, but it has never caused a single issue across those 100 or so machines I have mentioned. UAC being enabled has caused issues with some legit programs, but haven't had any issues with it disabled.