Since I wrote last month's commentary about Active Directory (AD) forest merges (see "AD Must-Haves Continued: Forest Merges," at http://www.windowsitpro.com/article/articleid/43804/43804.html ), Microsoft has again delayed the next major version of Windows, code-named Longhorn (Longhorn Server might not ship until 2007). Therefore, permit me to continue offering suggestions for Longhorn's AD implementation. In earlier articles, I've suggested AD aliases, whereby you could place any AD object in more than one container by using a feature similar to a file shortcut; reflectivity, a tool that causes AD GUI tools to reveal how to mimic their functions through command-line tools; and more flexible forest structures. This month, I take on one of the most perplexing AD shortcomings of all: the schema. I call the schema perplexing because its limitations just don't make sense. Let's see why.

First, what is the schema? AD is a database, and all databases have a list of fields, attributes, or columns. These terms all mean the same thing--different database programs simply use different names for them. An unmodified Windows 2000 AD contains about 1000 fields. To look inside an AD schema, just open Microsoft Management Console (MMC) and add the Active Directory Schema snap-in. If you don't see the AD Schema in the list of snap-ins, then close the MMC, open a command prompt, and type

regsvr32 schmmgmt.dll

(You'll need to be a member of the Enterprise Administrators group to work with the schema.)

Open the Active Directory Schema object in the snap-in, and you'll see two folders: classes and attributes. The classes folder lists the types of objects that AD supports (e.g., user accounts, computer accounts, DNS zones, and Group Policy Objects--GPOs).

You'll be surprised by how many types of objects AD supports; my production AD (a Win2K-based AD with Microsoft Exchange Server 2003) has 312 different classes. To find out how many types of objects yours has, open the Active Directory Schema snap-in, then open the Active Directory Schema object. Right-click the Classes folder, select "Export List ...," choose a file name, then click OK. Close the Active Directory Schema snap-in. Open Notepad and open the Classes file that you exported. Move to the last line in the file and click Edit/Go to... to find the line number. Subtract one number (the first line is the header) to find out how many classes your AD's schema includes.

Each record in the AD database can have a different class: A user account record might sit next to a record that describes an organizational unit (OU). Each record has items that some databases call fields and others call columns. AD calls them attributes and stores them in the Attributes folder in the Active Directory Schema snap-in. You can export the list of attributes to see how many possible items can describe a given AD record. My Windows 2000 Server/Microsoft Exchange Server 2003 domain contains 1776 attributes, which brings me to my main point this month: the size and inflexibility of the schema.

Although my AD has 312 classes and 1776 attributes, it didn't always have that many. Before I installed Exchange on my network, my AD had only 142 classes and 863 different attributes. Exchange exploits the built-in machinery of AD, so when I installed the first Exchange server on my domain, the setup program created new classes and attributes. Exchange can then put its own data on the domain, piggybacking on AD.

Now, what if I decide that I don't want to keep Exchange and I take it off my system. How do I remove the hundred or so new classes and nearly a thousand new attributes? Well, as most of you know, I can't. What goes into the schema, stays in the schema.

This inflexibility seems so odd. I'm not a database expert, but I've worked with many databases over the years and all of them let me remove fields, columns, or attributes when I didn't need them any more. (Microsoft didn't include this column-delete functionality in its SQL Server product until SQL 7.0.)

Therefore, here is my Longhorn AD wish: Give me the ability to delete attributes and classes! I mean, if dBase II allows it, then surely ....

Reader Comments

Not sure you can legitimately comapre AD & a database such as SQL Server due to: a) distributed nature and multimaster access of AD b) SQL is insatlled as single instance. I do agree that the ability to remove objects from the schema is desirable. I would also like the ability to merge forests.

Mark is being (perhaps deliberately)naive. AD is a relational database and the attributes are storedin a differaent table to the objects. Deleting an attribute would delet it from all objects. Deleting and object could have a cascade effect on multiple other objects. However I agree a "cleanup" programme to remove the remnants of Exchange would be a good idea. Lastly if he wants Forest merges he may have to wait for some time as Novell's NDS was release 5 (I think).