Metadata cleanup is one of the most serious task for network administrators as well as moving and seizing FSMO roles.
Before we talk briefly about metadata process I want to make sure you do understand the ADDS database ( .DIT) and its partitions. The ADDS database consist of below partitions
- Domain
- Configuration
- Schema
- Application
Now think about multi master replication model and what that mean is to you. When first domain controller introduced into forest/Domain , you now have domain controller which is authentication server waiting to provide ADDS directory services to its configured clients. Perfect when second DC is introduced into existing forest/domain ( DCpromo) now , .dit database from DC1 is copied into DC2 and DC2 become domain controller, authentication server as well.
So far so good, the replication amount these two domain controller keep both .dit database consistent and in sync stage and this is why when information is changed on DC1 reflects information on DC2 if the KCC on both domain controllers are happily replication delta changes.
What happen to FSMO roles, they got stuck on the first DC in this example and we will leave them there. Imagine you decided to have more redundancy and installed third DC into your forest/domain called DC3. Same story goes by .dit database is now reside on DC3 and thus DC3 become healthy domain controller.
What other services domain controllers provide, DNS, DHCP, WINS, File, Print service etc you name it and all these familiar to you.
Now imagine one day DC2 dies, due to hardware crash. Bad things happens and when they happen you release you never had any backup for the DC2, did I make you smile (-:
Okay how much we have to worry about losing DC2, if we are speaking of multi-master replication, can we purchase a new server and run DCPromo on it and replicate the .DIT database and its contend from DC1 or DC2?
Answer is of course this is why you would never have to worry about too much, because Active directory is redundant so does .dit database and its important contend.
Now you ordered new server name it DC2 just like the old one and you will run DCpromo to copy the .dit database from either one of the alive domain controller. You got couple problems doing this and you need to make some clean up if you are going to use same name for the new DC as DC2.
Let’s see why?
The simple answer will be, remember we talked about .DIT database and its partitions. In those partitions there are may references to each DC. simply failed DC2 still exist in the ADDS database even when it’s no longer physically connected to the network.
Just because it is no longer turned on does mean the database thinks it exist. Therefore replication from alive domain controllers to failed DC will be in trying state and will fail all the times. In a way thinking about pollution in the database.
why we need to clean this information? I just mentioned replication is having hard time, they try to locate the fail DC and obvious they cannot contact to it since it is not physically on the network. Many other dependency take will fail and you will end up having polluted .dit database.
So how we are going to get the garbage out the database is right thinking and metadata cleanup will be the way to do it for failed DC scenario.
once you clean up every information for the failed DC2 from .dit database, you will be able to bring new server with same name if you wish back to business with simple DCpromo
Now you know what "Clean meta data" mean is.
Clean up server metadata
Oz Casey Dedeal
MVP (Exchange)
MCITP (EMA), MCITP (SA)
MCSE 2003, M+, S+, MCDST
Security+, Project +, Server +
Http://smtp25.blogspot.com (Blog)
Https://telnet25.spaces.live.com (Blog)
Https://telnet25.worldpress.com (Blog)
