Grant Read/Execute permission at the drive root the built-in principal called "Interactive". Then no change to UAC is required.
This way people logged into the desktop remotely or "locally" (VM console or physical screen and keyboard) can still browse files and run programs even with UAC enabled.
For example, you could remove the default "Users can read and create everything from the root" permission to lock down the server sensibly, but avoid the inability to effectively logon, browse files and navigate to where you want to change settings as administrator.
As soon as you open the security dialog and want to change permissions, a button appears to change the settings as administrator. So you get the best of both worlds:
- No restriction to "local" admin/operator browsing of the structure and content of the disks.
- Protection against changes by non-administrators.
The only difference to the standard permissions, is we are not saying that only local "Users" accounts can read everything, but only people granted access to the Windows console, i.e. that logically means "physical" (or virtual) "interactive" server access, which is not just granted to anybody. This may not work for terminal servers unless there is a better way to distinguish between those types of sessions (suggest edit if you know that).
Of course the first advice is use server core/remote admin whenever possible. But when not, this helps avoid the common end-effect that a server were the default users permissions are removed end-up with dozens of personal user account permissions applied all over the place. And it's not really the fault of the administrator, they are just trying to do their job with standard tools without any special complexity (just use File Explorer normally).
Another positive effect of this solution, is by being able to lock-down the root drive permissions and still have the server "usable" for the administrator logged onto the desktop, the need to disable inheritance to remove unwanted permissions from above often disappears. The fact that all users can read and create whatever they want below your shared path by default is a common reason to disable inheritance when nobody wants to deal with the "root" cause ;-)