Unusual popup after moving files/folders
I'm having what I consider to be a very strange behavior with Window Server 2019 file and folder permissions. I've been moving lots of file shares around due to migrating a number of Windows 2008 R2 and 2012 R2 servers to Windows 2019. Although I don't think it's relevant, all the servers are VMs, and I'm migrating them from an ESXi 6.0 environment to ESXi 6.7. All the folders were set with the following permissions: BuiltIn\Administrators - F, System - F, BuiltIn\Users (or a specific user group) - M.
The unexpected behavior is that the first time I opened any of these folders logged on as the domain administrator, I get the following popup:
If I click "continue" I get access to the folder, and the Administrator account is added to the ACL with Full Control. I'm just confused as to why this would happen, when the domain admin account is already in the BuiltIn Administrators group and therefore should already have access.
I've administered some other Windows 2019 servers and I don't recall ever having this happen before. Has anyone else experienced this behavior? I'd love to hear any ideas as to why it might be happening in this environment when it didn't happen at other client sites.
The unexpected behavior is that the first time I opened any of these folders logged on as the domain administrator, I get the following popup:
If I click "continue" I get access to the folder, and the Administrator account is added to the ACL with Full Control. I'm just confused as to why this would happen, when the domain admin account is already in the BuiltIn Administrators group and therefore should already have access.
I've administered some other Windows 2019 servers and I don't recall ever having this happen before. Has anyone else experienced this behavior? I'd love to hear any ideas as to why it might be happening in this environment when it didn't happen at other client sites.
noxcho
Before you get this warning go to file or folder properties of the file or folder you want to open and check if your account is in the list of users who can edit the file/folder. The idea is that your account (even admin) is not in the list and by pressing continue you add it.
ASKER
Yes, I fully understand the contents of the popup. What I'm questioning is why the Administrator account that I'm using needs to be listed individually on the ACL to gain access. The domain administrators group is already there, and the standard Windows domain administrator account that I'm using is in that group. So by Windows security inheritance rules as I understand and have always experienced them, that account should already have rights to the resources I'm accessing.
It sounds like you are on the local server. This is an impact of User Account Control, which was introduced in Windows 2008. You are logged in, but the account process does not have administrator token unless you elevate the process.
If you do your administration from a remote workstation, you won't get the warning message.
If you do your administration from a remote workstation, you won't get the warning message.
You should not weaken the UAC protection settings.
What I like to do is give an additional group full control, and then put the groups of "file admins" into that group. It doesn't get blocked by UAC, and you don't need full admin rights.
What I like to do is give an additional group full control, and then put the groups of "file admins" into that group. It doesn't get blocked by UAC, and you don't need full admin rights.
Are you using the Storage Migration Service built-in to Server 2019?
My suspicion is this: Folder Permissions: Properly Disinheriting Folder Permissions.
My suspicion is this: Folder Permissions: Properly Disinheriting Folder Permissions.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
HAve you tried using runas Explorer++ as an administrator account? This really does sound like standard UAC behavior, and nothing you have posted indicates anything to the contrary. You also haven't said if this behavior is exhibited when doing file operations from a remote workstation.