I've come across a curious situation with one of our domain controllers (DC). Our usual setup has the SysVol folder located on a separate data drive (D:), rather than the typical C:WindowsSYSVOL. Recently, we flagged one DC that seems to have older Group Policy Objects (GPOs) and when trying to reseed the SysVol, I discovered it had replicated to C:WindowsSYSVOL while sharing from the data drive location (D:). To resolve this, I'm thinking of demoting and rebuilding the DC to ensure it's set up correctly. However, if that plan gets vetoed, I could temporarily recreate the share to point to the C: location with the same permissions, but I'm struggling to find a way to get it replicating to the preferred D: drive without going through the whole demotion process again. Has anyone ever dealt with a situation like this before?
5 Answers
I've had some odd experiences with this but never this specific case. It seems you could potentially adjust some registry settings and directly modify the directory using tools like ldp. Here's a guide that might help: [Microsoft Docs on Relocating SysVol Tree](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/relocate-sysvol-tree-frs-for-replication). That said, I'm with you on the idea; I'd rather demote and rebuild to avoid the potential issues.
In my view, domain controllers are often better off being deleted and recreated rather than fixed. I've found that a delete and recreate resolves issues quicker and less painfully, especially if you already have server OS templates ready to go.
I appreciate the insight! It really feels like demoting and rebuilding is the safer choice at this point.
Keeping the ntds and Group Policy on a separate volume has its benefits, mainly due to write caching. It's generally a good idea, though I'm not sure what went wrong during the setup of that particular DC.
Yeah, we usually prefer that configuration as well, which makes this situation all the more confusing.
We had a contractor suggest making these kinds of changes a few years back, but we decided against it for various reasons. Not really sure what he was thinking.
It could be a way to avoid messing with AD integrity if you ever need to restore the OS. I've done it for larger DC setups and it worked well.
For anyone using Azure, it's recommended to create a separate virtual data disk for the database, logs, and SysVol for Active Directory, rather than placing them on the same disk as the OS. Just make sure to set the Host Cache Preference on the data disk to None. Here’s a more detailed article: [Azure DCs Best Practices](https://learn.microsoft.com/en-us/azure/architecture/example-scenario/identity/adds-extend-domain).
That's actually super helpful! I'm glad to have that resource to support my decision to demote and rebuild. The risk involved with trying to force this seems high.