I'm trying to solve an issue for a customer and I'm running out of ideas.

We've upgrading all the hardware and server OS's. The domain now has two new Server 2019 DC's. The old DC's have been decommissioned. The forest was at 2012 functional level and was brought up to 2016. Also, FRS was upgraded to DFRS just prior to adding the new servers. I don't know if any of that matters to the issue.

When logged into a DC, we can not write to the SYSVOL when using a UNC path such as \domain.local\netlogon. It gives an Access Denied error. By going to c:\Windows\SYSVOL\ we are able to write to the folder. This only happens when logged into a DC. If you demote the same DC, it works.

From one of the two DC's, I can write to netlogon when using \192.x.x.x\netlogon but this does not work from the other DC.

The errors show Access Denied in the SMB Server logs but not further information.

If I demote a DC, I can use SYSVOL via UNC path. When I promote it back, I lose the ability again. Also, any non-domain controller can access the SYSVOL via UNC normally.

I've tried the following: -Disabled firewall -Disabled UAC -Disabled SMB Signing offloading on the NIC -Disabled SMB Signing -Prefer IPv4 over IPv6 -Disabled IPv6 -Transferred FSMO roles and repromoted DC's -Changed NIC in ESX to VMX3 from the e1000 -Scoured GPO and Local Policies -Moved DC to Computers OU -Tried a new Domain Admin account -Cleaned up DNS

  • From one of the two DC's, I can write to netlogon when using \192.x.x.x\netlogon but this does not work from the other DC. What are the share permissions on the DC where it does not work? – Greg Askew Jan 10 '20 at 18:13
  • Creator - Full (Subfolders and files) Auth Users - Read & Execute (All) SYSTEM - F (All) Admin group - Full (subfolders and files) Admin group - Special - all but modify (This folder only) Server Operators - Read and execute (all) – Rhys W Jan 10 '20 at 19:22
  • Those aren't share permissions, those are NTFS permissions. – Greg Askew Jan 10 '20 at 19:51
  • Gotcha. Everyone has full access to share – Rhys W Jan 13 '20 at 13:21
  • There are just two things: Share Permissions and NTFS ACLs. When you are checking those, always remember UNC. The "administrator" is and will not be (at least in explorer) a "Domain Admin". You'd have to use other processes for that (a shell for example). – bjoster Jan 13 '20 at 14:21

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
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
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\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)
                        NT AUTHORITY\SYSTEM:(F)
                        NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
                        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.

  • Thanks for your helping! I'd already walked back all that stuff so no worries there. Also, these are new DC's, added to an existing domain. The old DC's were properly removed and that's been checked as well. 1. dcdiag shows no errors 2. repadmin /replsum shows no errors 3. SYSVOL shows in state 4, Normal 4. whoami /groups shows correct group membership 5. acls are identical to yours, including GPO Creator Owners 6. DC's had been bounced, including moving FSMO 7. Time is right 8. The firewall is disabled, it happens even when the client\server are the same. Again, ONLY happens on DC's – Rhys W Jan 15 '20 at 19:14
  • OK, so where exactly are you trying to copy your files to? Or are you just trying to open \\mydomain.com\NETLOGON and write something there? Which should work. And what about going via the drive share - assuming your SYSVOL is on C: - \\dc1\C$\Windows\SYSVOL\sysvol\mydomain.com\scripts ? I am assuming you've tested your file with the local path. Is your test copying an existing file, or are you creating a new one? – LeeM Jan 16 '20 at 6:44
  • Do you have ANY GPOs making changes to SMB security, NTLM, NetworkServer, NetworkClient for the DCs other than the defaults? Run GPResult to check. What about errors in Microsoft-Windows-SMBServer/Security and Operational or Microsoft-Windows-SMBClient/Security event logs? Is SMB2 enabled if you run Get-SmbServerConfiguration ? NullSessionPipes include netlogon,samr,lsarpc? EnableStrictNameChecking set to False? Finally, how about a brand new account outside of your standard OUs that's added to Domain Admins? – LeeM Jan 16 '20 at 7:33
  • I can't write\delete new files or save existing. From DC1 and DC2 to \\domain.local\netlogon. Both give the error. SMB events show Access Denied. If I drill to C:\Windows\SYSVOL*, it does work. ---SMB2 is enabled ---NullSessionPipes have the netlogon, samr, lsarpc ---EnableStrictNameChecking is set to True. – Rhys W Jan 16 '20 at 17:18
  • 1
    It's not why "I think" IPv6 is required, it's that disabling IPv6 is an unsupported configuration - it breaks LDAP over UDP. Disabling IPv6 has not been a security "best practice" anywhere I'm familiar with - we used to disable it to just not have the interface chattering away when it's not needed. If your routers aren't forwarding the traffic, you don't need to worry about it. IPv6 is used in the loopback interface on all modern Windows OSes. Also, you shouldn't have random software on your DCs. – LeeM Jul 10 '20 at 4:19

Basically, you are not supposed to do this. This is a security protection put in place to avoid unwanted modification of very critical domain files. The correct way to modify the SYSVOL contents is via the c:\windows\sysvol location on a DC that you mentioned in your post. The changes will replicate to other DCs with normal DFS-Replication.

You can see more information from duplicate question Bizarre - Domain Admin has no rights to modify domain scripts directory


Turn off UAC from registry. Enter regedit and click OK. ... Expand HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows > CurrentVersion > policies > system. Right-click EnableLUA, and then select Modify. In Value data, enter 0 and then click OK.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.