Tag Archives: AD

Active Directory: Wait, you relocate the data stores, moving the NTDS Database, Sysvol and Logs from default? Why?

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.

Active Directory, it just works?

By Robert Meyers, MCITP

We all love Microsoft’s active directory.   It just works.  You install it and walk away.  Right?  Nothing else to do.  Right?

If a car company built a car, but only protected the outer shell from rust. painting, bluing or annealing nothing but the outer shell, the body.  Not the under carriage.  No parts of the engine…  nothing but the outer shell.  That car would run.  It would run as well as any car with a bit better finishing.  Heck, initially it might even run a bit better since it is lighter.  But how long would it be till the rust literally ate the car apart from the inside out?  Ask anyone who has ever been in a cold climate, they know: it wouldn’t last very long at all.  Heck, it isn’t uncommon in areas that salt their roads for cars to last half a decade with complete sealing.

So why don’t people finish setting up Microsoft’s active directory?  Why not just setup sites and services, setup organizational units… and maybe ever group policies?  No, I don’t know the answer.  In this case I just know this is an industry wide problem.   This is what leads to a great many problems that most administrators either don’t understand or often, just have no idea it even can occur.

In general, systems administrators’ love active directory.  It is logical and it just works.  You install it and walk away.  Or at least that is the realization I have had after viewing nearly a hundred installations of active directory over the last decade.  People install active directory and say, “we’re done!”  This is a fallacy.

When you simply install active directory, and walk away, you haven’t really setup anything.  This is normally referred to as installation, not setup.  And this can also be referred to as a disaster in waiting.

As a specialist in active directory, I always check on errors and events.  Or as Microsoft states, troubleshooting active directory starts with: “an event reported in an event log;” an alert generated by a monitoring system, such as Microsoft Operations Manager (MOM);” or “a symptom reported by a user or noticed by IT personnel.”  Working from one of the first two are a lot easier than the last.  Granted, if you didn’t setup active directory… many alerts are worthless or just don’t generate.

When active directory is fully configured, you get to view a massive amount of information.  Often information to the point of information overload.  And yes, you read right: information not data.  When it isn’t configured, you basically give up on troubleshooting.  Why?  Because in general you don’t get the alerts that you should have had to work from.

When you setup active directory, when you completely setup active directory, things really begin to work.  Your alerts actually begin to mean something (and in many case, simply begin being available).  You can actually see when you are having issues.  And most importantly: when something does go wrong, you can fix it.

So, when you see that active directory is simply installed, ask yourself: why didn’t someone they finish it?  If it’s your work: why wouldn’t you finish it?  I always hear the same from every engineer or administrator I have asked have said the same thing: it works.

Of all the answers, “it works” is completely without merit.  Professionals I have great respect for have been included in this group.  “It works” is not the answer.  It is a disaster.

The old saying is that if you take on a job, work it till completion.  So I recommend finishing active directory.  Then it really works.

Tech Tip #1:

The command to run a general domain diagnostic of all domain controllers in your domain and export to a log are listed here.

DCDIAG /V /E >> “C:\DCDIAGLOG.TXT

This site is using Web Stats, created by emailextractor14.com