Learn how to store application data in Active Directory with this tool from Microsoft.
Since the invention of directory services and of the LDAP protocol, many companies have figured out that a directory service database is a great repository for application specific data. Although it is very easy for software developers to write applications that store data in a directory service, there are a lot of problems that have been traditionally associated with using a directory service as a data repository. Microsoft's Active Directory Application Mode (ADAM) can help solve these problems.
The problems with using directory services for applications
Although the basic concept of using a directory service as a data repository is a good idea, there are some problems with doing so. One of the first problems that must be overcome is that of compatibility. Most directory services, including Active Directory, are based on the X.500 standard and applications often query the directory services through the LDAP protocol.
The problem though is that many software manufacturers implement directory services slightly differently, and some don't even support LDAP. For example, Novell released its directory service implementation, eDirectory/NDS, long before Microsoft. If a company had developed an application that made use of a NetWare 4.x directory service and then years later decided to switch to Windows 2000 or Windows 2003, there's a really good chance that the application might not work correctly in the new environment because of differences in the way that Microsoft and Novell implement directory services.
Even if an application does port easily from one directory service to another, there's the issue of support. Many software manufacturers will only certify their products to work under one or two network operating systems. Even if the product will function in a different environment, the product's manufacturer may deny support to those not running an approved network operating system.
As you can see, directory service standards can pose a problem, but using a directory service as a data repository can cause other problems as well. Suppose for a moment that a company already has Microsoft's Active Directory installed. If one of the business units within that company wanted to deploy an application that is designed to integrate itself into Microsoft's directory services, they could technically do so. Although the deployment would no doubt work as promised, doing so could lead to other problems.
One such problem is that adding an application to Active Directory almost always requires extending Active Directory schema. I have personally known a lot of network administrators who are very reluctant to allow anyone to extend the schema of their Active Directory. After all, a critical failure while modifying the schema could theoretically destroy the entire Active Directory forest.
Even if the administrator doesn't have a problem with extending the schema, what happens if another business unit wants to install a different Active Directory based application? There is a slim chance that the two applications could try to create identical object attributers, but use those attributes for different purposes. If this were to happen, it could result in corrupted data for both applications.
If you still aren't buying into the idea that having an application integrate itself into Active Directory might not be the safest thing in the world, then imagine that you had such an application and that the installation went perfectly and there were no conflicts with anything else. If this application updated data frequently, then it could lead to a whole slew of problems.
For starters, frequent updates might slow down your domain controllers. More importantly, though, any time that an update was made to the application's data, the update would have to be replicated to the other domain controllers. Depending on how frequently the data was updated and the number of domain controllers in your organization, the updates could lead to excessive replication traffic.
Why use ADAM?
Now that I have explained some of the problems behind using Active Directory as a repository for application data, you are probably wondering why using ADAM is any better. Imagine being able to have a separate Active Directory for every application. If an Active Directory integrated application has a catastrophic failure, it won't destroy the entire forest—it will only destroy its own individual directory. Likewise, there is no chance of two directory-enabled applications interfering with each other because they both use different directories.
When Microsoft released Windows Server 2003, it incorporated a feature into Active Directory known as an application partition. The idea behind an application partition is that the data related to a specific application could be isolated from other data within Active Directory. This would prevent application conflicts and replication nightmares. I still think that using ADAM is a better solution than using application partitions for several reasons: security, compatibility, and economy.
The first reason why I like ADAM more than Active Directory application partitions is security. Sure, Microsoft has made great strides in security with Windows Server 2003, but the fact remains that if a business unit wants to deploy an Active Directory integrated application, it would have to write data to Active Directory, and would usually also have to modify the schema. Being that Active Directory is the heart and soul of the entire enterprise network, I'm just not very comfortable with allowing a business unit to make a modification to Active Directory.
On the other hand, an ADAM instance is totally independent from Active Directory. A business unit could set up its own ADAM instance and deploy applications without ever having to touch Active Directory.
Another reason I prefer ADAM is compatibility. The truth is that not all Active Directory integrated applications will run in an application partition. Since you don't want to give your business units free rein over Active Directory, ADAM is the perfect solution. It allows applications that won't work inside an application partition to run in a completely isolated environment.
While I'm on the subject of compatibility, I want to address the issue of applications being compatible with ADAM. Any application that works with Active Directory will also work with ADAM. ADAM is a part of Active Directory, but is isolated from the normal Active Directory. ADAM uses LDAP queries just like the normal Active Directory, so even most of the management tools that you're used to using can be used to manage an ADAM environment.
Perhaps the best reason of all for using ADAM is economy. To see why this is an issue, consider that many organizations have a completely separate forest for their development staff to use as a test environment. Even my own lab is set up this way. This type of setup is expensive because it requires its own domain controllers, and a copy of Windows Server 2003 Enterprise Edition costs around $4,000.
Having this type of development environment is expensive, especially when you start needing multiple servers, but I have always thought that the cost was justified because this type of configuration guarantees that you will never accidentally trash a production environment with buggy code.
The beauty of ADAM is that it doesn't require a domain controller. ADAM can run on a Windows 2003 domain controller, member server, or standalone server. While this doesn't really help an organization get around the cost of a server license, the fact that ADAM works with Windows XP Professional does!
Yes, you read correctly, ADAM can run on a Windows XP Professional machine. Furthermore, a single machine can host multiple ADAM instances. Think about it for a moment. Imagine being able to host multiple Active Directory forests from a single Windows XP machine!
The implication is that not only will you save money on server licenses, but also that whenever a business unit wants to deploy an Active Directory integrated application, it could deploy the application onto a dedicated PC for a fraction of the cost of deploying the application to a server.
Setting up Active Directory Application Mode
You can download Active Directory Application Mode software from the Microsoft Web site. There are several different versions of ADAM, and the file size varies considerably depending on which version you download. The most important thing that you need to know about the download files is that there is a retail version and a redistributable version. Regardless of which version you want, you'll also have to decide if you want the X86 or the A64 version.
The main difference between the two versions is that the retail version has a license agreement similar to any other off-the-shelf software package. The redistributable version is licensed in a way that allows it to be bundled with applications that are being distributed commercially. Basically, if you're developing an application for internal use, you'll want to use the retail version. If you're developing an application that you intend to sell, you'll need the redistributable version. For the purposes of the article, I'll be demonstrating the X86 retail version, which has a download size of 8.26 MB.
The downloadable file consists of a self-extracting executable. When you double-click the file, it will create 169 different files. One of these files is called ADAMSETUP.EXE. Double-click this file, and it will extract even more files and will launch the Active Directory Application Mode Setup Wizard.
When the wizard starts, click Next to bypass the welcome screen, then accept the end user license agreement and click Next again. The wizard will ask you whether you want to install ADAM and the ADAM administration tools or just the administration tools. Since you don't yet have an instance of ADAM on your network, choose the ADAM And ADAM Administration Tools option. Click Next, and Setup will ask you if you would like to install a unique instance of ADAM or if you'd like to create a replica for an existing ADAM instance.
Again, there is no existing ADAM instance, so tell Setup to create a unique instance and click Next. You will now be prompted to enter a name for the new instance. The default name is Instance1, but I recommend using a name that tells something about what the instance will be used for.
I explained earlier that Active Directory queries are performed using LDAP, and this is also the case with ADAM queries. Like any other TCP/IP-based protocol, LDAP uses specific port numbers. By default, LDAP queries use port 389 and SSL queries use port number 636. I tell you this because the Setup wizard asks you to supply LDAP and SSL port numbers—the default port numbers being 389 and 636. Keep in mind, though, that these port numbers are not always appropriate. If the machine on which you're installing ADAM is a domain controller, you will not be able to use these port numbers.
Assuming that you aren't installing ADAM onto a domain controller, I recommend going ahead and using the default port numbers for the first instance of ADAM. Additional instances will have to use alternate port numbers, since a different port must be used for each instance of ADAM.
If you're installing ADAM onto a domain controller or if the machine already has another instance of ADAM, then you must choose an alternate port for LDAP and for SSL. You can use any available port numbers from 1025 to 65535. If you do end up having to use alternate port numbers, be sure to write down the port numbers that you choose.
Click Next, and Setup will ask you if you'd like to create an application partition within the ADAM instance. The appropriate selection here depends on the application that you will be installing. If the application that you plan on installing creates its own application partition, you won't need to create one.
Click Next, and you will be asked for the location of the ADAM data files and data recovery files. The default paths are based on the instance name that you assigned earlier, so assuming that the target drive has enough free disk space, the default paths are sufficient.
The next couple of screens ask you to select an ADAM service account and to assign user or group ADAM administrative permissions. The next screen allows you to import any desired LDIF (Lightweight Directory Interchange Format) files that you may need. Microsoft supplies five different LDIF files that you can import.
Unfortunately, Setup doesn't allow you to import other LDIF files, but you can do this manually later on. Click Next and you will see a summary of all of the options that you have chosen. Assuming that everything looks good, click Next, and Setup will install ADAM and configure it as you have instructed. The installation process only takes a couple of minutes. When installation completes, click Finish to close the setup wizard.
Pretty much any tool that uses LDAP queries can be used by ADAM. That means that most of the Active Directory related tools that you are already familiar with can be used to manage ADAM. Even so, ADAM does come with a few tools of its own. The Setup program creates an ADAM option on the computer's All Programs menu. This menu option contains a help file, an ADAM-specific version of ADSI Edit, and something called the ADAM Tools Command Prompt.
The Adam Tools Command Prompt is just a normal Command Prompt window that's set to open into the %SYSTEMROOT%\ADAM folder. This folder contains copies of many of the command line Active Directory management tools that normally come with Windows 2000 Server and Windows Server 2003.
That's all there is to it
Using ADAM as a repository for application data rather than using Active Directory frees you from having to deal with problems related to excessive replication, schema modifications, and some of the office politics that go along with these issues. If you want to use Active Directory to store information for your applications, ADAM can help you avoid these problems.