When you start building domain controllers, one of the simple ideas people bring up is that you always leave the Active Directory data (NTDS database, Sysvol and logs; also known as directory data) where the default in the windows directory.  The idea is they are tucked away and difficult to stumble across accidentally and start playing around with them.  Others simply say: it is where they belong.

I have been at this for so long that I hadn’t really thought about it till I received an email asking why I relocated the data stores in my blog post: A Visual Step by Step: Windows Server 2012, Active Directory 2012, time to build your first forest!

Well, it is probably obvious by now, that I disagree with the popular sentiment.

One of the problems is that most people confuse the Active Directory Domain Services role (making the server a Domain Controller) with the server. The reality is that the Active Directory Domain Services role is simply that: a role.  It is a role that when doing work in your lab, or troubleshooting and restoring your enterprise systems you need to be able to easily backup or even copy everything related to Active Directory.  Why hide it in the Windows directory with thousands of other files and folders?

When you isolate these folders and files into a single root level directory (I like C:\ADDS) you gain one directory to manage.  So it is one directory to manage.  One directory to isolate from antivirus; yes, you have to avoid the NTDS Database, Sysvol and Logs from anti-virus scanning (if you even put anti-virus on your domain controllers… another topic to discuss at a later date). It also allows you to easily copy everything to do with Active Directory with the right click of a mouse or a simple backup command (to get everything).  This is awesome when troubleshooting things like Journal Wrap or doing restoration of login scripts or even Active Directory itself.  It is a life saver for a quick directory restore operation.

The idea here is to make your management of Active Directory simpler.  Now comes some neat things you can do if you have additional physical volumes to move these files to.

In a large environment, placing the directory data (Sysvol, NTDS, Logs) on its own NTFS partition reduces disk I/O.  This can reduce some chances of error, such as FRS just not keeping up with changes.  Additionally, reducing disk I/O allows the Active Directory Domain Services server more efficiently as well.  This can be vital for an enterprise PDC Emulator.  More efficient, better I/O adds to the number of client requests that can be processed. From a performance point of view you could use three separate disk arrays. One disk array for your boot partition, one disk array for your Active Directory database and the Shared System Volume (SYSVOL) folder and one disk array for your Active Directory log files.

However remember, Active Directory is based on a database.  As such, if you want the absolute best performance possible… separate all three parts of the directory data onto three separate drives.  Granted, this is only done when an enterprise needs extreme responsiveness.  However, this starts to get to be a management headache, as you now have to backup three separate drives. Lets just keep it simple if we can, ok?

What are the negatives? If this is going to be a Domain Controller that is not going to be managed by trained staff… don’t do this.  Some administrators won’t realize that they should look for the directory data.  However, this is a situation where training can fix this.  Additionally, sometimes you may want to use simple step by steps found online… and will need the administrator to adjust the commands on the fly.

Is it doable with the negatives?  Yes.  Do I consider the advantages more valuable than the risks from the negatives? Absolutely.  It keeps things simple for backups, restores and troubleshooting.  You can isolate your directory data and make your life simpler.