Welcome to the ITFreeTraining video on how DNS data is stored in Active Directory Partitions.
Understanding how this works will help you understand how DNS data stored in Active Directory
is replicated. It will also increase your understanding of how Active Directory Partitions
work, in particular, how Application partitions work.
Before I get started on how DNS data is stored in Active Directory, I will first have a
look at the Active Directory partitions. Let’s consider a typical Domain Controller. Every
Domain Controller has a file on the Domain Controller that holds the NTDS.DIT file. This
file holds the Active Directory database. As shown here, there are five different partitions
that are created by default when Active Directory is first installed. The data is divided up
like this for organizational reasons and for replication.
In this particular case, I am going to be looking at only the application partition
since this holds the data that is used for DNS. Application partitions hold information
that is used by a particular application. In the case of DNS, when you create an Active
Directory Integrated zone, the data for this zone is stored in the appropriate application
partition. You did hear me correctly, the appropriate application partition. This can be as many
application partitions as needed. The other partitions type are limited to one per database.
I will now change to my Windows 8 computer with Remote Server Administration Tools to
have a closer look at how the application partitions are used with DNS.
First of all I will open ADSIEdit to have a look at what exactly is stored in the database.
To do this, I will open charms by moving to the top right corner and then select administrative
tools.
Once Administrative Tools is open, the next step is to select the icon ADSI Edit. ADSI
Edit is a low level tool for editing the data in the Active Directory database. For making
day to day changes to the Active Directory database, I would recommend using the administrative
tools. ADSIEdit should only be used in rare troubleshooting cases and in this case I am
only using ADSIEdit in order to have a better understanding of how Active directory stores
data, not to make changes.
Once ADSEdit has opened, I next need to connect to the Active Directory database. To do this,
I need to right click on ADSIEdit and select Connect to. To start with, under “Select
a well-known Naming Content” I will select the pull down option Configuration. Configuration
partitions does not contain any DNS data, however looking at it will give us a better
understanding of how the Active Directory database is partitioned.
For the configuration partition, I will expand down through configuration until I get to
partitions. In here, you can see all the partitions that are created in Active Directory.
At the bottom, you can see the standard partitions for the domain and forest created when Active
Directory was first installed. Application partitions are named differently from the
standard partitions. You can see above the standard partitions is the application partitions
which use an identifier rather than a standard name. Since there can be multiple application
partitions, it is not possible to use a standard name as each partition must have a unique
name.
If I select the first application partition, you will notice the name of the partition
is ForestDNSZones. DNS data that is stored with all Domain Controllers in the forest
is stored in this application partition. Above this is the application partition for ITFreeTraining.
This partition is shared with all Domain Controllers in the Domain ITFreeTraining. If there were
other domains like child domains, then there would also be application partitions listed
in here for those child domains.
To have a look at the data in these application partitions, I will once again right click
on ADSIEdit and select connect to and this time, I need to enter in the distinguished
name for the application partition. In this case I will connect to the Forest Application
partition.
Once I have connected to Forest Application partition, I can now see all the data that
is stored at the forest level. To see the DNS data, I will expand down through the containers
until I get to the Microsoft DNS container.
Here you can see all the DNS data that is shared at the forest. In this case, notice
that the zone HighCostTraining.local is stored in here. HighCostTraining in this case is
not a child domain but another company. In this case, HighCostTraining has been configured
as a stub zone and thus this is why it appears in here.
To see what DNS data is stored at the domain level, I need to use the connect to command
once again and this time connect to DomainDNSZones using its distinguished name. Once connected,
I will expand down to Microsoft DNS and then down to the container ITfreeTraining.local.
In here you can see all the data for the ITFreeTraining zone. Even though you could edit the data
in here, it is recommend that you use the DNS Manager tool rather than edit the DNS
data directly.
If you now go back to Administrative Tools, and open DNS Manager, I can expand down to
the ITFreeTraining zone and see the same data that I saw in ADSIEdit displayed in a friendlier
format.
If I now right click the zone and open the properties, you can see that replication is
currently configured to all Domain Controllers in the domain. If I press the change button,
I can change this to the option “To all DNS servers running on domain controllers
in this forest”. Once I press o.k. and exit out of the properties, the changes to the
zone data will be made.
If I now go back to ADSIEdit and back to the Domain application partition, notice that
the ITfreeTraining.local partition is still here. However, when I press the F5 key to
refresh the view, notice the partition disappears.
If I select the Forest Application partition, notice once again the ITfreeTraining zone
is not visible, however, once again when I press F5, the missing zone appears. You should
now understand how Active Directory keeps DNS records stored in the default partitions
for domains and forests. Now I need to look at creating a custom partition to store DNS
data in.
To do this, I need to open a command prompt by opening charms, selecting the search option
and then selecting the command prompt icon.
The commands that I am going to run I have placed in the batch file. The link to download
the batch file can be found in the description of this video, or you can view the commands
in the description of this video if you prefer.
I have stored the batch file on the flash drive so I will now change the drive to the
flash drive and run the batch file.
The first command that I will run is DNSCmd with the parameter EnumDirectoryPartitions.
This command will show all the current application partitions that are in the forest. Notice
the first one is the Domain Application partition. The second one if the Forest Application partition.
These are the only Application partitions that are created by default when Active Directory
is first setup.
The next command that I will run with DNSCmd is to create an additional application partition.
The first parameter is the Domain Controller I want to create the application partition
on. The next parameter is CreateDirectoryPartition to tell DNSCmd that I want to create a partition.
The last parameter is the name of the application partition that I want to create. You can use
a short name here if you wish, in this case I have used a fully qualified domain name
to make it easy to recognize.
Since I have made changes to the Active Directory Configuration, I next will run a command to
replicate the changes to all Domain Controllers. Otherwise I need to wait until the next scheduled
replication in Active Directory.
If I scroll up to the top, you can see the command is RepAdmin with the parameter SyncAll
followed by the Domain Controller I want to run it on and lastly the flags A P e d. In
this case, it is important to make sure you use the same upper and lower case characters,
as the flags in this command are case sensitive.
The flag upper case A flag performs a sync of all name contents held in the Domain Controller.
If you run this command without this flag only the domain partition will be replicated.
The change we just made was to the configuration partition so the A flag is required.
The Flag upper case P flag, tells the Domain Controller to push the changes out to all
other Domain Controllers rather than waiting for another Domain Controller to ask for changes.
The e flag forces a sync of all Domain Controllers in the forest. In this case, since I have
made changes to the configuration partition which is forest wide by adding an application
partition, it is a good idea to add this flag.
The d flag uses distinguished names in messages. This makes it easier to read the output from
the command.
Even though this command finished right away and with no errors, it is important to
remember that this just requested a background replication to be performed. If you have a
lot of data that needs to be replicated, it could take a while for the replication to
finish. You will need to check the event viewer to see if replication has completed.
Since I have made changes to partitions in Active Directory, the next command that I
will run is RepAdmin with the parameter KCC followed by the Domain Controller NYDC1. This
forces the Knowledge Consistency Checker or KCC to run on NYDC1. The KCC creates the connections
between Domain Controllers to ensure that data in each partition is correctly replicated.
Since I have added a partition it is a good idea to make sure these connections are made,
otherwise the partition data may not get replicated. The KCC will run automatically by itself at
set intervals, so just like the replication, you can wait for it to run or force it to
run like I have.
The next command does the same as the last command except it causes the KCC to run on
LADC1. The KCC uses the Active Directory database in order to make decisions about which connections
to create. Thus given the same Active Directory data it should always make the same connections.
For this reason, it is a good idea to always replicate the database like I have done, before
running the KCC. Currently I only have the two sites, New York and Los Angeles running.
If I had more sites configured I would need to run this command on one Domain Controller
in each site.
For the next command, I will run the replication command again. Since I have run the KCC and
the connections may have changed, it is not a bad idea to run replication again.
The next command I will run is DNSCmd again on the Domain Controller LADC1. Application
partitions can be replicated to as many or few Domain Controllers as required. In this
case, I want the data to be replicated to NYDC1 and LADC1.
Since the application partition was created on NYDC1, the data will automatically be replicated
to this Domain Controller. However, currently the data is not replicated to any other
Domain Controllers. The next step that I want to do is add LADC1 to the replication list
for this application partition. This is referred to as enlisting so this command will enlist
LADC1 to replicate the application partition that I have just created. This is done with
the next parameter EnlistDirectoryPartition followed by the application partition. This
command needs to be run for every Domain Controller that you want this application partition to
replicate with. This can be as many or few Domain Controllers as you want from any domain
in the forest.
Now that the application partition has been created, I can run the command DNSCmd followed
by a Domain Controller, in this case NYDC1, and lastly the parameter EnumDirectoryPartitions.
This will show all the partitions in the forest. Notice the partition CustomPartition. Also
notice this partition has been configured as Enlisted. This means that Domain Controllers
have to be manually added to it in order to receive changes in contrast to the other two
which have Domain Controllers added automatically.
Now that the application partition has been created, I will now go back to DNS Manager,
and open the properties for the zone ITFreeTraining.local. Notice this time that when I press the button
change for replication, I now have the option at the bottom available, “To all domain
controllers in the scope of this directory partition.” This is not available before
because there were no additional application partitions.
In the pull down list notice I can select the custom partition that I just created.
The data for the ITFreeTraining.local zone can now be stored in this partition if required.
On most networks you would not have the need to do this, however on some networks for additional
security an administrator may use this feature.
There has been a lot covered in this video so I will do a quick summary. An application
partition holds data for any application. The application partition type is used by
Microsoft DNS. This video has focused on using the application partition for DNS, however
it can also be used for non-Microsoft applications. The methods used in the video apply not only
to DNS, but also if you were using an application partition with other software.
Unlike the other partitions, once you create a custom application partition, you can decide
which Domain Controllers the data stored in this Application Partition will be replicated
to. This can be from 1 Domain Controller, that is, no replication performed, to all
Domain Controllers to anywhere in between. The Domain Controllers you choose can be any
Domain Controllers in the forest, you are not limited to only choosing Domain Controllers
in the same domain.
By default, when Active Directory is installed, there is one application partition created
for the forest and one application partition created for each domain in the forest. This
is used to store Microsoft DNS data in but can also be used to store other data from
other applications.
That concludes this video, I hope you have found this video useful, and I look forward
to seeing you in the other videos from ITFreeTraining. Thanks and see you next time.