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

Just checking if there's any progress or updates?

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

Answer 3

Thanks, @Dave Patrick for the help - I did my idea of demoting all the other servers, having just the two DCs at our main site, and doing the DFRS migration cleaned up the inaccessible folders. It did NOT clean up the weirdly named folder - I had to go through a lot of individual back-ups and restore GPOs after deleting all the contents except the two default GPOs. But thankfully you were right the DFRS migration must have a service account that had permission to delete those inaccessible folders.

Side note: We had a randomly generated named file.exe file sitting in the root of our sysvol directory on one of our DCs. Somehow this did not copy to our other DCs thankfully as it turned out to be ransomware which I found out a few days after this post. Sorry for the lack of response! It was unplugged and forcibly removed from our domain infrastructure. We are still going through the follow-up process of all the questions surrounding its existence, but my initial question here has been solved - so thank you!

Answer 4

That's good news, and thank you for taking the time to post this follow-up.