Introducing the ADSI Edit Utility

Getting inside the Active Directory

Exchange Server 5.5 administrators know that they can gain insight into the internal workings of the Exchange Directory Store by specifying the /r switch to run admin.exe, the Exchange administration program, in raw mode. Raw mode lets the administration program display the Directory Store schema and reveal the properties of objects without the regular user interface (UI).

Working with raw directory data is a double-edged sword because the UI serves two purposes. First, it protects and assists administrators by ensuring that they don't inadvertently enter illegal data for object properties or delete important information. Second, the UI hides some Directory data that the product needs to work properly and administrators usually don't need to work with.

The Heuristics property of a server object is an example of data that the UI protects for good reason. Microsoft uses the Heuristics property to define some basic server capabilities, such as whether the server is part of a cluster. The UI offers no option to manipulate this property because changing a server's heuristics is dangerous; if you enter an illegal value in this property, the server can stop operating properly.

Does the fact that Exchange 2000 discards the Directory Store in favor of the Active Directory (AD) mean that you lose the chance to interact with Directory data at a low level? The answer is no, but the route for this interaction is different. You access the AD through the Lightweight Directory Access Protocol (LDAP) and the Active Directory Services Interface (ADSI). Microsoft intends LDAP primarily for client access, although it can manipulate directory contents. However, in an Exchange 2000 environment, you use LDAP chiefly for access to the AD from clients such as Microsoft Outlook Web Access (OWA) or Outlook Express or to synchronize the Exchange Server 5.5 Directory with the AD through the Active Directory Connector (ADC).

Microsoft used ADSI to build most Windows 2000 utilities that work with the AD. ADSI is a standard set of COM interfaces that supports any directory for which a suitable ADSI provider is available. A provider is an interface to a specific directory. The AD is only one of the directories that currently support ADSI. The others include

LDAP is the name of the ADSI provider for the AD, but this naming scheme doesn't mean that ADSI is built on top of LDAP. Instead, it means that the AD is the default LDAP-compliant directory that you find on Win2K computers. If you're programming ADSI, you need to reference the LDAP provider, but you're still going through ADSI to get to the AD. Think of LDAP as the way users can retrieve information from the AD and ADSI as the preferred programming interface.

Microsoft provides many Microsoft Management Console (MMC) snap-ins to access AD data. Exchange 2000 administrators get most use out of the Users and Computers snap-in, a tool for managing users, contacts, and groups. This snap-in includes functions such as mail-enabling a user, moving a mailbox, or adding a new mail address to a user, contact, or group.

ADSI Edit, which Figure 1 shows, is a utility built on ADSI. ADSI Edit provides the equivalent of raw mode access to the AD; it lets Exchange 2000 administrators bypass the UI that the MMC enforces. However, be as careful using ADSI Edit as you are using raw mode: Don't make any change unless you know precisely what you're doing and the effect the change will have. ADSI Edit is not a utility that you start playing around with on a live production server just for fun. A change to the wrong object or the input of invalid data could have catastrophic effects.

Using ADSI Edit
ADSI Edit installs automatically when you install the Microsoft Windows 2000 Resource Kit. You invoke ADSI Edit from Programs, Windows 2000 Support Tools, Tools, ADSI Edit. Figure 2 shows how you can use ADSI Edit to view the properties for a user object that also has an Exchange mailbox. This example shows the legacyExchangeDN attribute, which the ADC uses when it replicates data from the Exchange Server 5.5 Directory. (This attribute appears in the AD Schema MMC snap-in by its display name, Legacy-Exchange-DN.)

Although you can use this dialog box to edit properties, I can't think of a good reason for doing so. You can use it, for example, to change a part of a distinguished name (DN) to either alter the display name of the object or move the object to another container; however, no guarantee exists that the change will be valid or completely effective. If you use ADSI to make changes, work on a test system to verify the long-term effect before you attempt to alter anything on a production system.

Because Exchange 2000 publishes all its configuration data in the AD, ADSI Edit can reveal this information. Figure 3 illustrates the Exchange container in the AD configuration naming context expanded to show the type and scope of the data maintained for Exchange 2000. In the subcontainers under the Exchange configuration container, Exchange stores the shape of the organization (Administrative Groups) and settings for an individual server, such as the mailbox and public stores in a storage group. Remember that here the AD replicates this data as part of the configuration naming context to all Global Catalog (GC) servers in a Win2K forest to allow servers to route messages to one another. If AD replication doesn't work properly inside a forest, Exchange 2000 can't function correctly. ADSI Edit can help by showing you information about the contents of the AD, but it won't help you determine whether replication is occurring according to plan. For that information, you need to go deeper.

The LDP Utility
If you want to get even closer to raw data, use the LDP utility. Although ADSI Edit can perform brain surgery on the AD, LDP can examine individual nerves. LDP is a good utility that works brilliantly in the hands of software engineers or people who know their way around LDAP and need to retrieve diagnostic information. However, LDP is too dangerous for just poking around in the AD's innards.

Figure 4 shows the LDP utility connected to a domain controller. As soon as the utility makes the connection, it immediately retrieves a great deal of information about the domain controller and displays it in the right pane. This information includes update sequence number (USN) values, which help track synchronization status within a Win2K forest; the domain controller's synchronization status; and its GC server status. The Browse menu lets you add, delete, or modify items. You can also view security descriptors. The Replication option lets you see replication meta data. This information is valuable if you need to provide it to Microsoft Product Support Services (PSS) to help solve a complex problem, but it's not usually useful in day-to-day administration.

Because the AD supports ADSI as its COM-compatible programmable interface, programmers can use ADSI to perform operations against the database. The same caveats apply as for ADSI Edit. Always perform multiple tests and understand the results and consequences of the changes before you work with production data.

Capability Retained
Administrators can rest easy in their beds, safe in the knowledge that they can still interrogate the internal workings of the AD to discover information about users and other objects, including Exchange configuration data. This capability is useful, but remember the double-edged sword. Fools rush in where experienced administrators fear to mess with the Directory Store, and this maxim holds true for the AD and Exchange 2000.