How do Active Directory transactions work?
You surely asked yourself this very same question before. If not, I’m going to write about that anyway, so feel free to check back later or stick with me, when we dive into the files Active Directory and how transactions in Active Directory work.
By reading “transactions” over and over, you probably think of “traditional” databases like those you use for housing your customer data or other stuff. If I told you to name some database server, you’d surely come up with mySQL, SQL Server, Oracle and a few others. For storing its data, Active Directory also uses a database you probably have heard of: ntds.dit. If you ever needed to move AD to another volume or restore objects in AD, you have come across it.
In order to get to know the files that are saved aside ntds.dit in the %windir%\NTDS folder (or whatever you configured using the DCpromo.exe wizard during AD installation), we need to look for what parts AD behaves like a database and where files are needed.
When changing data in a database (and so in AD), actions that you perform are called transactions. A well-known example of a transaction is a money transfer used in banks from bank account A to bank account B. When A transfers 100$ to B, two steps need to be performed: we need to substract 100$ from A’s account and add them to B’s account. Only when both steps are successfully performed, the transaction was successful. That’s one of transaction’s principles: atomicy. If we substract 100$ from A’s account and encounter some issue with adding the money to B’s account, we can’t just stop the action. That would leave us in an inconsistent state where A is 100$ lighter and B still waits for her money. We need to make sure that, if we fail in one of our steps, we roll back to a state in which we are consistent. In this case, we’d have to make sure that A gets her money back. Either all actions are performed or non of them (actions made will be rolled back if one of them fails).
To get that example into the AD world, image you want to move Betsy from her “Accounts”-OU to the “Sales”-OU. Moving accounts is made of two steps: deleting Betsy in the “accounts” OU and creating her in the “Sales”-OU. If one of those steps fails, we get into an inconsistent state: we either have Betsy somewhere between “not sure where” and “nowhere” or Betsy out of the sudden got a twin-sister. You should have seen by now that inconsistent states is nothing we want. In order to be able to “roll” back as I stated before, we don’t just write changes to the AD database.
