Sysvol issues - Policies_NTFRS_xxxx folder correct - original policies folder has a lot of inaccessible folders?

Question

We have two Policies (and scripts) folders in our SYSVOL folder. It stays in sync on all six of our DCs. But I want to clean this up. How do I get rid of the oddly named "Policies_NTFRS_xxxx" folder and only have "Policies" folder? Same for Scripts as well...

It seems there are a lot of inaccessible folders in my correctly named Policies folder. I've tried running some icacls scripts I found in the forums here but it tells me it doesn't have permissions to run, even from an elevated PS prompt. I cannot take ownership of the folders at all either.

If I try to take ownership of the folders, it tells me I don't have permissions, even after attempting to take ownership with administrator permissions.

The script I tried to run is this:

$Policies = Get-ChildItem C:\Windows\SYSVOL\domain\Policies -Name -Filter "{*}"  
      
    foreach ($Policy in $Policies) {  
        icacls "C:\Windows\SYSVOL\domain\Policies\$policy" /remove:g "<domain>\Domain Admins"  
        icacls "C:\Windows\SYSVOL\domain\Policies\$policy" /grant "<domain>\Domain Admins:(OI)(CI)(F)"  
        icacls "C:\Windows\SYSVOL\domain\Policies\$policy"  
        }  

It works for every folder in my oddly named Policies folder, but when I run it on my normally named Policies folder I get a bunch of inaccessible files errors.

icacls : C:\Windows\SYSVOL\domain\Policies{2F8111C2-4632-4D12-B8BF-DFE08204C2DE}: Access is denied.

I went through my excess GPOs we no longer use and removed them via group policy manager and replication appears to work across DCs as the count of GPOs has increased and decreased accordingly. Just our ACL permissions are wrong according to GPMC.

What is the proper way to fix this? How can I take ownership, purge the bad folders, and get rid of the oddly named policies (and scripts) folders so I only have one main Policies and Scripts layout as intended with AD?

Currently, we are on Server 2012 R2 with plans to upgrade in a few weeks to 2019 possibly if time permits and I can get this sorted out ;)

Update: I also have tried to go into GPMC -> delegations -> advanced -> advanced -> restore defaults ... for each remaining GPO we have. Yet the GPMC still reports ACLs errors...

Answer 1

Ok, sorry, I did not understand the servers were still FRS. Unfortunately I got rid of the last domain controller that still had the old sysvol so I cannot look. When you do the FRS->DFSR migration a new sysvol_dfsr is created, then contents are migrated (copied) then as last step the SYSVOL share name is deleted from old sysvol folder and a new share SYSVOL is mapped to new sysvol_dfsr folder so this in effect might do the cleanup. Yes that's correct, the two prerequisites to introducing the first 2019 domain controller are that domain functional level needs to be 2008 or higher and older sysvol FRS replication needs to have been migrated to DFSR
https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Streamlined-Migration-of-FRS-to-DFSR-SYSVOL/ba-p/425405

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 2

Some more info on how it might have happened.
https://learn.microsoft.com/en-US/troubleshoot/windows-server/networking/ntfrs-added-to-folder-name

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 3

I think the reason it happened was during our 2003 to 2012 update many moons/years ago. Since it works, it's never bugged me until I noticed the ACL errors in the GPMC report. It's strange how FRS and replication all still work and I've compared specific folders inside the _NTFRS_xxxx folders between domain controllers and the permissions look identical so I'm not sure if this ACL error is really talking about the GPO's ACLs being out of sync, or if it is finding the junk folders with bad ACL permissions in the old "Policies" folder, which is why I can't delete the folders.

I read the link you posted previously which is how I found the AD Rep Status Tool and really liked that AD is clean and shows no errors - BUT I'm fearful that if I am to try the migration process to DFRS, it will ultimately fail when it tries to remove the old sysvol directory and hit all those bad ACL folders that I do not have permissions to access... maybe it will use some special account which still has permissions and that will clean things up - but I'm hesitant to try it without a solid plan. What happens if I migrate, it starts using DFRS, but then it can't delete the original folders in the current Sysvol directory - does it blow up, try to roll back (it says it can't roll back once DFRS takes over), nuke itself, etc...? :)

Part of me wants to demote every DC in every building we have, except our one main primary DC - make these changes to DFRS and then make a new 2019 server to add as the primary server and rebuild all the current DCs with a fresh install of 2019 AD and let them get a fresh copy when they are added to the domain. But that's risky too as all my eggs would literally be in one server, er I mean basket. :)

Answer 4

I'm fearful that if I am to try the migration process to DFRS, it will ultimately fail when it tries to remove the old sysvol directory

Could be an issue, here's an old screen grab of a 2012 R2 after migration.

Another option is to start a case here with product support.
https://support.serviceshub.microsoft.com/supportforbusiness

--please don't forget to upvote and Accept as answer if the reply is helpful--

Answer 5

Hello @Erik Tank ,

Thank you for posting here.

Based on the description above, I think your question is a bit complicated, and it’s hard to tell on the forum how to guide you to try to fix this problem.

I suggest you submit a service request to MS Professional tech support service so that a dedicated support professional can further assist you with this request.

The following web site for more detail of Professional Support Options and incident submission methods is for your reference:

https://support.microsoft.com/en-in/gp/contactus81?forceorigin=esmc&Audience=Commercial

https://support.microsoft.com/en-us/help/4051701/global-customer-service-phone-numbers

Then Microsoft engineers will guide you or help you try to fix this issue through the phone and remotely If the FRS problem is completely resolved and there is no problem in the AD environment, it is recommended that you migrate from FRS to DFSR. If you are currently migrating from FRS to DFSR, you may not be able to successfully migrate or there will be problems after migrating to DFSR.

Hope the information above is helpful.

Should you have any question or concern, please feel free to let us know.

Best Regards,
Daisy Zhou

============================================

If the Answer is helpful, please click "Accept Answer" and upvote it.