Although the Windows Server 2003 Active Directory closely mimics the Windows 2000 Active Directory, Windows Server 2003 does offer a few Active Directory features that are not present in Windows 2000. One such feature is the ability to host application partitions.
As you probably know, Active Directory is really nothing more than a distributed, relational database. Under normal circumstances, Active Directory is used primarily to store security principles (users, groups, computers, etc.). However, Active Directory is, and always has been extensible. The idea behind an application directory partition is that you can extend Active Directory database so that applications can store data directly within Active Directory.
Because Active Directory always has been extensible, it would theoretically be possible to store application data in a Windows 2000 Active Directory, and yet application directory partitions can only exist in a Windows Server 2003 Active Directory. The reason for the apparent contradiction is that an application directory partition has one special feature. It allows you to specify which domain controller or controllers application data is stored on. Here's how they work.
The benefits of application directory partitions
There are several benefits to the way that application directory partitions work. First, since you can designate a set of domain controllers to host application data, you create a distributed application environment. This means that if a domain controller should fail, the application can still function if the application's data has been replicated to another domain controller.
Another benefit of using an application directory partition is that you can control the amount of replication that occurs.Â In a normal domain environment, any time a change is made to Active Directory, the change is replicated to every other domain controller in the entire organization. If an application directory partition worked the same way, and your application's data was constantly being updated, then your network could end up being plagued by excessive replication traffic. While it's true that any change to the data on an application directory partition gets replicated, you get to choose which domain controllers act as replicas. There is no need to worry about application data being replicated to every domain controller in the organization, unless you define every domain controller in the organization as a replica.
One more advantage to using application directory partitions is in the way that Active Directory is accessed. The native protocol for directory access is LDAP (Lightweight Directory Access Protocol). LDAP is a well defined standard based on the DAP protocol (Directory Access Protocol). LDAP is designed to be easier to use than DAP. Since all Active Directory queries are LDAP based, it should be relatively easy for your in house development staff to code applications in a way that allows them to store data in Active Directory.
The application directory partition namespace
A lot of people seem to struggle with the concept of how an application directory partition works because it is a logical structure that behaves similarly to a domain. The easiest way that I can think of to describe an application directory partition is that it is like a domain with no security principles (users, groups, computers, etc.) and no domain controllers of its own. Instead, it piggybacks on another domain's domain controllers. The reason why I say that an application partition is comparable to a domain is because of the way that the partition's namespace works.
With one exception that I will talk about later on, you can place an application directory partition anywhere in an organization's DNS namespace that you could place a domain. For example, suppose that you had a small network consisting of a single domain called example.com. In an organization like this, you could create a new domain either as a child of the existing domain or as a new tree in the forest (parallel to the existing domain). If you were defining an application directory partition rather than a domain, your options would be exactly the same as they would be if you were creating a domain.
Let's go back to my example.com domain. If you wanted to create an application directory partition named application as a child of the example.com domain, then the application directory partition's DNS namespace would be application.example.com. Likewise, you could create the application directory partition as a new tree within the existing forest. In that case, the application directory partition's DNS namespace would be application.com.
Just as Active Directory allows you to create domain trees with many levels, you can do the same with application directory partitions. For example, if you wanted to create an application directory partition named application2, and make it a child of application.example.com, the DNS namespace would become application2.application.example.com.
Earlier I mentioned that there was one situation in which defining an application directory partition does not follow the same rules as defining a domain. The rule is that an application directory partition can exist as a root level tree, a child of a domain or as a child of another application directory partition. However, you can't create a domain that exists as a child of an application directory partition. Remember that an application directory partition is a logical structure that piggybacks off of an existing domain. You can therefore create a domain that is a child of the domain that's hosting the application directory partition, but you can't create a domain as a child of the application directory partition itself.
Creating and deleting application directory partitions
There are a variety of tools that you can use for managing application directory partitions, such as LDAP, ADSI, NTDSUTIL, or application specific tools. For the purposes of this article, I will be using the NTDSUTIL command line tool to manage an Active Directory partition.
Before you create an application directory partition (or perform any other related management activity), you must open the NTDSUTIL tool and connect to the target domain controller. To do so, open a Command Prompt window and enter the NTDSUTIL command, followed by the DOMAIN MANAGEMENT command and the CONNECTION command. Now, enter CONNECT TO SERVER servername (where servername is the name of the domain controller that you want to connect to). Enter the QUIT command to return to the Domain Management portion of the utility.
Now that you have attached to a domain controller, creating an application directory partition is simple. You would enter the CREATE NC command followed by the distinguished name of the application directory partition that you want to create, and the fully qualified domain name of the server that you want to create the application directory partition on. If the server that you want to create the partition on is the same server that you already connected to then you can replace the server's fully qualified domain name with the word null.
To demonstrate how this command works, let's go back to my earlier example in which we wanted to create an application directory partition named Application as a child of a domain named example.com. Let's also assume for demonstration purposes that the name of the server that will be hosting the partition is Server and that it exists in the example.com domain. In such an arrangement, the command for creating the application directory partition would be:
CREATE NC dc=application,dc=example,dc=com server.example.com
CREATE NC dc=application,dc=example,dc=com
Deleting an application directory partition works very similarly to creating it. To delete a partition, you must enter the DELETE NC command followed by the distinguished name of the partition that you want to delete. If, for example, you wanted to delete the partition that we just created, the command would be:
DELETE NC dc=application,dc=example,dc=com
Before you delete any real world application directory partitions though, there are a few things that you need to know. First, the deletion process is gradual. It takes some time for the partition to actually be removed from the server. You must avoid creating another partition with the same name until you can confirm that the original partition was actually deleted.
The other thing that you need to know about deleting an application directory partition is that doing so will cause data loss. Deleting a replica of an application directory partition from a single domain controller is no big deal as long as at least one replica remains. However, when you delete the last replica, you delete the partition and all of the data contained within it.
If you have an application that relies on an application directory partition, the application will usually contain a utility for creating and removing the partition. If you are using such an application, it is usually better to perform the creation and deletion process through the application rather than using the manual technique that I have shown you. Creating or removing an application directory partition through an application insures that the application is aware of the changes that you are making.
Creating and deleting replicas
The procedure for creating a replica of an existing application directory partition is almost identical to the procedure that you used to create the partition in the first place. To create a replica, you would enter the ADD NC REPLICA command, followed by the distinguished name of the application directory partition and the fully qualified domain name of the domain controller that you want to place the replica onto. Once again, you would replace the domain controller's fully qualified domain name with the word null if you are placing the replica onto the domain controller that you are currently connected to. For example, if you wanted to create a replica of the application.example.com partition on a server named Server2, you would enter the following command:
ADD NC REPLICA dc=application,dc=example,dc=com
ADD NC REPLICA dc=application,dc=example,dc=com
To delete a replica, you would use the exact command, except that you would replace the ADD portion of the command with REMOVE. For example, if you wanted to remove the replica of the application.example.com partition from Server2, you would use the following command:
REMOVE NC REPLICA dc=application,dc=example,dc=com
REMOVE NC REPLICA dc=application,dc=example,dc=com
Keep in mind that when you delete a replica, and data contained within the replica, which has not yet been replicated to the other replicas will be lost.
Defining a replication schedule
Earlier I mentioned that in many ways, application directory partitions behave similarly to domains. One of the ways that this behavior is the most obvious is in the way that data is replicated. Suppose for a moment that a user makes a change to a record in a dataset that's stored within an application directory partition. The change can be written to any available replica. Once the change is written to the replica, the replica begins sending out change notifications to the other replicas. Those replicas receive the change notifications and then download a copy of the changed data. As you can see, this process works almost identically to standard Active Directory replication.
The replication process works well as long as there aren't an excessive number of changes being made. If lots of changes are being made to the data though, the replication traffic can quickly become overwhelming. One way that you can limit the amount of replication traffic though is to add a delay to the notification process. For example, imagine that your users are updating the data set at a rate of one change every second.
In such a case, you would have update notifications being sent out every second. Rather than burden the network with all of this replication traffic, you could add a 60 second delay. This means that update notifications would be sent out at most once per minute. This would allow the replicas to download changes in batches rather than have to constantly download data. On the flip side though, adding a lengthy delay means that your data will seldom be perfectly synchronized. It also means that if a replica were to fail, you could lose all the data that the replica has collected since the last time the other replicas downloaded the updates.
If you do decide that you want to add a delay, then you will have to specify two different delay numbers. The first number is the amount of time (in seconds) that the replica should wait before contacting another replica. The second number is the amount of time (in seconds) that the replica should wait before notifying any other existing replicas.
To create a delay, you would enter the SET NC REPLICATE NOTIFICATION DELAY command, followed by the application directory partition's distinguished name and the two delay values that I talked about a moment ago. For example, if you wanted to set a ten second delay before the application.example.com partition contacted the first replica, and a fifteen second delay prior to contacting additional replicas, you would use the following command:
SET NC REPLICATE NOTIFICATION DELAY dc=application,dc=example,dc=com 10 15
If you later decided that you wanted to remove the delay, you would simply reissue the command, but set both values at zero.
Displaying replica information
Over time it can be easy to forget exactly which servers are acting as replicas for an application directory partition. If you need to determine which domain controllers are functioning as replicas, there is a simple command that you can use to display the entire replica set. The command is LIST NC REPLICAS. You would follow this command with the application directory partition's distinguished name. For example, if you wanted to see all of the replicas for the application.example.com partition, you would enter the following command:
LIST NC REPLICAS dc=application,dc=example,dc=com