SQL Server Magazine

Windows NT comes with the User Manager tool, which lets administrators manipulate the properties of users and groups within a GUI application. In Windows 2000 (Win2K), the Active Directory Users and Computers (ADUC) Microsoft Management Console (MMC) snap-in updates this tool's functionality.

Microsoft designed the ADUC to manage users and groups in a manner similar to the User Manager, except that ADUC also lets you manage the objects in any domain. ADUC lets you create an entire domain hierarchy of organizational units (OUs), user accounts, computer accounts, groups, and volumes. You can turn on Advanced View and install the Active Directory Connector to email-enable Active Directory (AD) objects and transfer them to and from Microsoft Exchange Server and view the ADUC pages (e.g., Terminal Services Profile, Exchange General, Exchange Advanced, Security) for a user object, which Screen 1, page 152, shows.

A computer object, which Screen 2, page 152, shows, has many fewer property pages. Are there fewer property pages because a computer object has fewer attributes than a user object? No, a computer object inherits its class structure schema from the user class and adds a few new computer attributes. So, the computer class contains all the attributes of the user class plus some new attributes. Although a computer object has more attributes than a user object, a computer object has fewer property pages because administrators don't need to use the GUI to manage most of the computer attributes. The computer object's description is its most important attribute.

ADUC can effectively manage only the properties that it knows about, which can cause problems. For example, suppose you decide to store all the languages that employees can speak in the AD. This attribute doesn't exist in the AD by default, so what do you do? You can use the Extension attributes or create a new attribute in the AD schema (i.e., the blueprint of all objects and attributes that you can create in the AD).

Each object in the AD has Extension attributes. The system doesn't use these attributes; Microsoft provides them so that you don't have to create them. Extension attributes have numbers that range from 1 to 15. To use these attributes, you need to add the data into the Extension-Attribute-1 attribute on every user object. But first, you'll have to get the data into the Extension-Attribute-1, and you'll need to manage the data in Extension-Attribute-1. You can't use the AD GUI because it doesn't manage these attributes by default.

You can also modify the schema to add a new attribute, such as Languages-Spoken, on the user object. But you still need to get the data into the schema. Suppose, instead, you decided to create a new object class, such as Finance-User, in the schema. How would you create a new class? The AD GUI knows nothing about your objects.

You need to consider the end users. Administrators can use the ADUC tool and the other main AD management tools (e.g., Active Directory Sites and Services Manager, Active Directory Domains and Trusts, Active Directory Schema Manager) to manage an AD. However, users search and query the data in the AD. If users, rather than administrators, need to determine the languages spoken, you need some way to display the information in the shell so that end users can see and interact with the information in the AD.

If the administrator's tools and the shell aren't extensible or customizable, the tools aren't much better than the static User Manager tool is. However, Microsoft has successfully solved the extensibility and customization problems. Now you can use scripts to customize an object's GUI to your liking. These scripts don't have to be complex. In fact, Microsoft provides extensions to the AD so that any properly written GUI to the AD (e.g., all the tools that Microsoft provides) can support these scripts.

Display-Specifiers
Since the early design of the AD, Microsoft has produced documentation about Display-Specifiers for the GUI. Display-Specifiers let you enhance any object type with information that an interface that properly understands the Display-Specifier can read and use.

Each object class in the AD schema has a set of predetermined Display-Specifiers. The Configuration naming context holds these Display-Specifiers in a path such as LDAP://cn=409,cn=DisplaySpecifiers,cn=Configuration,dc=mycorp,dc=com. The container, which Screen 3 shows, signifies the Display-Specifiers for the US English locale 409. If you want to create or manage Display-Specifiers for a different locale, create a new container with the relevant hexadecimal code for the locale and populate the new container with the relevant Display-Specifier objects. For example, 409 in hex format (1033 in decimal) is the US English locale. If you create a new container with 809 in hex format (2057 in decimal), you get the UK English locale, and if you create a container with 40C in hex format (1036 in decimal), you get the French locale. You can find the current installed locale values in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Control\ContentIndex\Language Registry key. Supporting different locales lets you have different Display-Specifiers for the different locales, so the AD objects can have different names, property pages, and menus depending on which locale and language settings a user has installed.

The container holds a series of Display-Specifier class objects. The user class has an object called user-Display, and the computer class has an object called computer-Display. To extend the interface for a language's object class, you simply modify the attributes on the Display-Specifier object that represents the class in that container.

For example, the class-Display-Name property exists on all Display-Specifier objects. Suppose you use the AD Editor (ADSIEDIT) tool from the Microsoft Windows 2000 Resource Kit to open the group-Display Display-Specifier object in the Configuration container. The group-Display Properties provides an attribute page that has a drop-down menu of properties, which Screen 4 shows. Next, find the classDisplayName property and remove the value that corresponds to the name Group and add in the value that corresponds to the name Moose. This change leaves you with the class-Display-Name attribute holding only the word Moose. Ordinarily, when you right-click any container in the ADUC tool, a context menu appears to let you create a new User, Group, or OU. Now the tool will let you create a new User, Moose, or OU. You have simply changed the name that the class uses for the display; the objects haven't changed. To change the display specifier to the French locale in addition to or instead of the US English locale, you create the 40C container and apply the change to a newly created group-Display Display-Specifier object in the 40C container. You can also make other changes to the interface.

Property Pages
An object has an array of property pages, which Screen 1 shows. You can add and display more property pages for an object. To add a property page, the page has to exist as a COM object that supports the IShellExitInit and IShellPropSheetExt interfaces. Therefore, you first have to create the property page in Visual Basic (VB), Visual C++ (VC++), or a similar language.

Creating the object is the hard part; telling the system to use the object is easy. After you create the property page COM object, it will have a universally unique ID (UUID), which is similar in concept to a globally unique ID (GUID). Then, you use a tool such as ADSIEDIT to access the Display-Specifier object that represents the class that you want to modify, and alter the Admin-Property-Pages or Shell-Property-Pages attributes. These attributes are multivalued and store data in the form that Listing 1 shows. The first value specifies the order in which the pages will appear. The second item represents the UUID. You can use an optional third parameter to store extended information, such as the instruction to pass data to the property page as it displays.

To add your property page to a class, edit either the Shell or Admin property page attribute, depending on whether you want to modify the shell or administrator UI, and add in a line similar to either the first or second line in Listing 1. The process is simple. You can even modify and resequence the existing pages.

   Prev. page   [1] 2     next page