Windows Server 2019 – Unable to Create File from Right Click

context-menuwindows-server-2019

Windows Server 2019.

I've created a new user account and added it to the Administrators Group.

I've disabled the built-in Administrator account for security.

When using the new Administrative user account it seems to be missing a lot of right click context menu actions such as Create Shortcut, Create File, etc. The only context action I can see is 'Create Folder'.

Additionally every time I try to do something Windows is asking for Administrative access even though I'm logged in with Administrative privileges.

Any idea how to restore these missing context menu actions?

Thanks in advance.

Best Answer

That is the expected behavior if UAC is enabled and the account only has permissions via a protected group like Administrators. If you assign permissions to the account or another group for which the account is a member, it should work.

Related Solutions

Server 2019 SMB Share EXE Files Slower Than Server 2008 – Solutions

It was MalwareBytes Cloud. Even with a whitelist entry for the path, EXE and local folder.

Windows – Access Denied to SYSVOL from DC when using UNC path

Can you please undo all of that stuff you've done to troubleshoot, especially with disabling IPv6 - it's required. And DCs in the the Domain Controllers OU. Just undo everything you've done, including the SMB signing stuff, firewall, etc.

You can't just treat DCs like any random server.

Firstly, where are you trying to write TO? Netlogon and SYSVOL actually point to different locations inside sysvol. They are also junction points on disk - you can't just write to random places in there. https://support.microsoft.com/en-au/help/324175/best-practices-for-sysvol-maintenance (it mentions FRS, but the structure hasn't changed).

You may have had customised perms on your legacy DCs, and now you're trying to do something that used to work, but won't with the out-of-box perms (which means you need to carefully consider what you're trying to do and how best to do so securely).

After your DFSR implementation, did you do thorough checks to see if replication was working properly? Actually, check these things:

Does repadmin /replsum show recent replication on each DC?
Does NET SHARE show SYSVOL and NETLOGON shared on all DCs?
Run dcdiag on each DC. Are there any errors? If there are, STOP and troubleshoot that!
Is the time on your DCs from an NTP source and are they within 5 minutes of each other?
Are there any firewalls between the dcs or whatever client you're using to open sysvol

Here's the share info on a minimally-changed DC install:

C:\>net share netlogon
Share name        NETLOGON
Path              C:\Windows\SYSVOL\sysvol\mydomain.com\SCRIPTS
Remark            Logon server share
Maximum users     No limit
Users
Caching           Manual caching of documents
Permission        Everyone, READ
                BUILTIN\Administrators, FULL


C:\>net share sysvol
Share name        SYSVOL
Path              C:\Windows\SYSVOL\sysvol
Remark            Logon server share
Maximum users     No limit
Users
Caching           Manual caching of documents
Permission        Everyone, READ
                BUILTIN\Administrators, FULL
                NT AUTHORITY\Authenticated Users, FULL

Here are my perms - you may have extras, but you should not have LESS - here we've specifically added the Group Policy Creator Owners to allow them to manage the logon scripts

C:\>icacls C:\Windows\SYSVOL\sysvol\mydomain.com\SCRIPTS
C:\Windows\SYSVOL\sysvol\mydomain.com\SCRIPTS CREATOR OWNER:(OI)(CI)(IO)(F)
                                            NT AUTHORITY\Authenticated Users:(OI)(CI)(RX)
                                            MYDOMAIN\Group Policy Creator Owners:(OI)(CI)(M)
                                            NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                                            BUILTIN\Administrators:(RX,W,WDAC,WO)
                                            BUILTIN\Administrators:(OI)(CI)(IO)(F)
                                            BUILTIN\Server Operators:(OI)(CI)(RX)

C:\>icacls C:\Windows\SYSVOL\sysvol
C:\Windows\SYSVOL\sysvol NT AUTHORITY\Authenticated Users:(RX)
                        NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(GR,GE)
                        BUILTIN\Server Operators:(RX)
                        BUILTIN\Server Operators:(OI)(CI)(IO)(GR,GE)
                        BUILTIN\Administrators:(RX,W,WDAC,WO)
                        BUILTIN\Administrators:(OI)(CI)(IO)(WDAC,WO,GR,GW,GE)
                        NT AUTHORITY\SYSTEM:(F)
                        NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
                        BUILTIN\Administrators:(RX,W,WDAC,WO)
                        CREATOR OWNER:(OI)(CI)(IO)(WDAC,WO,GR,GW,GE)

If there's something wierd with your SYSVOL share, this guide is a good place to start. Do NOT muck around with trying to "reset" perms using icacls or whatever if something important is missing. Just recreate SYSVOL. If you've added a custom permission, try removing it. Given what's been going on with your testing, I wouldn't be surprised if SYSVOL was in a dirty shutdown state. https://support.microsoft.com/en-au/help/2958414/dfs-replication-how-to-troubleshoot-missing-sysvol-and-netlogon-shares.

For further help, please ensure you've returned your DC configs to a proper state, that there are no DCDIAG or SYSVOL or time or replication errors, and where you're trying to write to in SYSVOL. Also do a whoami /groups to ensure you're really in Domain Admins and, if you're logged onto a DC, that it shows you're also a member of BUILTIN\Administrators. And that you've logged off and on again (or run klist purge) if you make any changes - I recommend bouncing the DCs. One at a time. Transferring the FSMO roles in between.

If you've got actual errors in the logs or DCDIAG, give the text.

Best Answer

Related Solutions

Server 2019 SMB Share EXE Files Slower Than Server 2008 – Solutions

Windows – Access Denied to SYSVOL from DC when using UNC path

Related Topic