Active Directory Scorecard
A year and a half has passed since Active Directory was unleashed, with the promise of simpler management and significant cost savings. Harry points to other less-than-obvious benefits.
- By Harry Brelsford
- June 01, 2001
Microsoft's directory service known as Active
Directory was released to the public Feb. 17,
2000. Although AD has been available for 18 months,
Microsoft had given ample hints to the coming
of AD with the Windows 2000 corporate preview
program during late 1999. Even then, MCSEs have
viewed AD as a solution waiting for a problem
to solve. Besides, not many applications were
compliant with it. Eighteen months later, where
do we stand with AD? When I started this column,
I made a point to highlight AD from planning and
This month I'll revisit AD so that you can see
just how far you've come in your knowledge of
the directory services solution in Win2K Server.
Specifically, let's focus on forest management,
schema modifications and application interaction.
My consulting niche is Microsoft Small
Business Server 2000. When it comes to AD forests,
I'm most comfortable discussing a single forest
with a single tree with a single domain. Clearly,
I'm not using AD to its advantage. I tip my hat
to you-the readers-for writing me and telling
me how you're implementing AD at the enterprise
level. I've learned many interesting things from
Some of your stories involved cases of business
acquisitions, where AD hasn't helped the companies
achieve "synergy," that hoped-for melding of disparate
corporate cultures which should have resulted
in huge cost savings. More importantly, keeping
separate forests with separate AD schemas (databases)
is often a top AD design goal, done under the
guise of keeping the namespace for the two entities
separate. (That goal can be thwarted in a few
ways, including creating recipient policies in
Exchange Server 2000). I was taught that two merged
companies typically operate as two separate companies,
a fact underscored by having two separate forests.
The point: AD doesn't have the tools to manage
and integrate two AD forests.
Some of you have also told me stories where the
goal was to avoid corruption of the directory
schemas from the two companies. After all, the
AD schema is a database, with each forest based
upon its own schema. You can add changes to the
schema but you can't remove them. If you have
applications that modify the AD schema in a way
that makes it fundamentally unsound for others
in the acquired organization, then you might be
looking at two forests.
At its basic level, the AD schema is nothing
more than a database with rows and columns. In
fact, the AD schema looks a tad like a Microsoft
Excel spreadsheet. You really want to think through
your modifications to the AD schema-once you add
fields, you can't remove them. More likely, you'll
have full confidence that the developers of your
AD-aware applications, (such as the accounting
systems of the future), knew what in the heck
they were doing when they modified AD.
So, how do you modify AD? One way is to create
"hooks" to AD via an application programming interface
(API). It's how independent software vendors (ISVs)
make their programs AD-aware. An API exists for
AD, called the Active Directory Services Interface
(ADSI), which Microsoft uses to "open" AD, allowing
the company to claim that its implementation of
AD is an open standard. Developers appreciate
ADSI because they don't have to create their own
AD APIs via software development kits (SDKs).
Other operating system developers can use ADSI
to integrate their operating system and directory
services offerings into AD.
MCSEs recognize that, as the collective comfort
level with AD increases over time, questions such
as "What can I do with it?" emerge. Perhaps you've
been asking yourself this if you've installed
Microsoft Exchange 2000 (see Figure 1). Exchange
2000, if you've noticed, modifies the AD schema
|Figure 1. In this Small
Business Server 2000 setup, the Exchange 2000
Server install process modifies the AD schema.
Maybe you asked what in the heck is going on
here and why is it taking so long? Exchange 2000
Server modifies AD so that Exchange itself can
slide into the schema and be managed, in part,
by AD (see Figure 2.)
|Figure 2. After Exchange
2000 Server modifies the AD schema, the property
sheet for a user in the AD Users and Computers
snap-in displays a few tabs related to Exchange
2000 Server and the use of e-mail.
Want to delve into the columns and rows of the
AD schema and see for yourself? Follow these steps
to implement the AD Schema snap-in to see what
the database structure looks like. First, it's
important to know that the AD Schema snap-in isn't
available by default. To use it, you must first
register the DLL with the operating system by
at the command prompt. Next, follow these steps
to use the snap-in:
- Assuming you're logged on as an administrator
at the Win2K Server machine, click Start, Run.
- In the Open field of the Run dialog box,
- From the Console menu, select Add/Remove
- Click Add in the Add/Remove Snap-in dialog
- Select Active Directory Schema in the Add
Standalone Snap-in dialog box.
- Click Add.
- Click Close to close the Add Standalone Snap-in
- Click OK to close the Add/Remove Snap-in
The AD Schema snap-in now appears (see Figure
|Figure 3. A data dictionary-like
view of the AD Schema. Be careful—with
an overdose of curiosity and this tool, you
can cause great harm to your Win2K network.
So, the question is, why modify the AD Schema?
Perhaps you want to add more data fields for some
user accounts, one that incorporates a floor plan
or an employee photo. (I first heard of the idea
of adding floor plans and photos to the AD database
in Bill Wade's excellent AD presentation at MCP
TechMentor Fall 2000 in San Francisco. While I
wouldn't want to bog down the AD database with
that type of data-nor did Bill Wade recommend
you do so-but it was interesting to know that
such possibilities abound.)
My third and final scorecard point on AD
is a peek and a poke at the not-to-distant future.
ISVs are slowly coming over to the AD camp. One
day you'll have a single sign-on experience with
your mission-critical business applications. For
example, your network logon will get you into
your business accounting application (such as
Great Plains) without another logon dialog box.
And you'll set Great Plains permissions in the
AD Users and Computers. You can bet this area
of discussion will be the primary focus of my
AD scorecard a year from now.