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 implementation.

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.

Forest Management
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 you.

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.

Schema Modifications
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 during installation.

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 typing:

regsvr32 schmmgmt.dll

at the command prompt. Next, follow these steps to use the snap-in:

1. Assuming you're logged on as an administrator at the Win2K Server machine, click Start, Run.
2. In the Open field of the Run dialog box, type MMC.
3. From the Console menu, select Add/Remove Snap-in.
4. Click Add in the Add/Remove Snap-in dialog box.
5. Select Active Directory Schema in the Add Standalone Snap-in dialog box.
6. Click Add.
7. Click Close to close the Add Standalone Snap-in dialog box.
8. Click OK to close the Add/Remove Snap-in dialog box.

The AD Schema snap-in now appears (see Figure 3).

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.)

Application Interaction
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.