White Paper
Abstract
This White Paper introduces the Microsoft® Windows NT® operating system’s Active Directory Display Specifiers. Display Specifiers are objects that hold user-specific interface information and provide a flexible UI mechanism to meet the needs of the various user groups in the distributed network.
© 1997 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Microsoft, he BackOffice logo, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
Other product or company names mentioned herein may be the trademarks of their respective owners.
Microsoft Corporation · One Microsoft Way · Redmond, WA 98052-6399 · USA
0997
Administrators and end users need different user interfaces. Many properties and actions have no meaning to end users and yet administrators need access to them. Moreover, in the Microsoft® Windows NT® 5.0 operating system, security and administrative policies prohibit end users from viewing or changing many attributes. Thus, the Windows NT 5.0 Directory will present a different UI to administrators and end users. The administrative UI will be presented through different Microsoft Management Console (MMC) snap-ins—specifically, the Microsoft Directory Service Manager, Microsoft Site and Replication Manager, and Microsoft Active Directory Schema Manager.
The end user, however, will see the directory through the Windows® operating system shell. For the user, the Network Neighborhood folder on the Desktop will lead to a folder titled “Directory.”
Although their User Interfaces and their experience with the Windows NT 5.0 directory service—or Active Directory—will differ, both administrators and users will require that directory service objects be displayed in the user interface. Therefore, a flexible UI mechanism is needed to meet the needs of the various user groups while still meeting the more general UI goals of localization, extensibility, and ease of customer modification.
User interface information is stored in the directory service (DS). This UI specification is done at the granularity of a DS object class, and DS object classes are defined in that portion of the directory known as the schema. These objects are called schema class objects. Each schema class object can have UI display specification information associated uniquely with it.
The Windows NT 5.0 Active Directory will be able to specify various UI elements on a per-class basis. These elements are property pages, context menus, class icons, class object creation wizards, and localized class names.
The display specification system stores information for property sheets, context menus, class icons, class object creation wizards, and localized class names. The display specification system uses this information to form different user interfaces for administrators and end users—one set of elements, such as property pages, context menus, and so forth, can be associated with the administrator class, while a different set of elements can be associated with end users. This UI information is stored in an Active Directory object called a Display Specifier . Each Display Specifier object contains attributes describing the various UI elements for the specific user interface to which it pertains.
Each property page for a DS object can be either a Component Object Model (COM) object or a HyperText Markup Language (HTML) file. The description of a COM object (its universally unique identifier, or UUID) or an HTML page (its URL) is stored in an attribute on a Display Specifier object. These property page attributes are multiple valued, with each element holding the description for a single URL or COM object. The administrative property pages for a class are stored in the Admin-Property-Pages attribute. The corresponding end user attribute is Shell-Property-Pages.
A class UUID registered with the system and activated through the standard COM instance creation methods names a COM property page. The object must implement two shell interfaces: IShellExtInit and IShellPropSheetExt.
The description of a property page COM object is stored in the Display Specifier attribute as a string with the following format:
<order-number>,<CLSID>,[optional data]
in which
Each COM object can implement more than one property page. One possible use of the optional data is to name the pages to display. This gives implementers a great deal of flexibility in determining the number of COM objects needed to create their required pages.
Each property page is described by a URL and activated using an HTML browser supplied by the DS UI framework. There will be specific conventions to be followed to allow the page to obtain the name of the object it is representing and to facilitate the page receiving an apply notification so that it can save the user-enter changes. These conventions will be described at a later date.
The description of a property page HTML object is stored in the Display Specifier attribute as a string with the following format:
<order-number>,<URL>,<page-title>
in which
There will be different context menus for administrators and end users. These attributes will be called Admin-Context-Menu and Shell-Context-Menu. In addition, there will be an attribute, Context-Menu, for menu items that are common to both. The menu item design is to be determined.
The iconic images used to represent a class object can be read from the Display Specifier. Moreover, each class can store multiple icon states. For example, a folder class can have bitmaps for the open, closed, and disabled states. The current implementation allows up to 15 different icon states per class.
The attribute is named Class-Icon and can be specified in one of two ways.
<ICO-file-name>
or
<DLL-name>,<resource-ID>
A wizard is a property sheet that uses Previous and Next buttons rather than tabs to navigate between the pages. Thus, a mechanism similar to that used for property sheets can be used to specify the pages of an object creation wizard. The only difference is the need for an additional convention to describe how the new object data is passed from page to page. This convention will be described at a later time.
When a class name is displayed in the UI, the application can fetch the localized version of the name from the Display Specifier. The name of the attribute for this is Localized-Class-Name.
There are three different options for storing user interface display information in the Active Directory:
Each of these options is discussed more fully in the following paragraphs, while the next section, “The Windows NT 5.0 Implementation,” describes the phased implementation chosen.
Sufficient new attributes could be added to the class object class to contain the UI display information. While this is a simple approach, it would require a great deal of schema modification. Moreover, not only would the original schema need extensive modification, but customers would need to modify the schema for all new and changed UI behavior. The schema is the data dictionary of the directory service, and an error in the schema could render the directory unusable.
The container that holds the schema objects is named Schema. The Schema container is in the Configuration container. With this approach, a new container called Display Specifiers could be added inside of the Configuration container, and inside of this new Display Specifiers container, a container could be added for each locale in the Enterprise. These locale containers could be named using the hex representation of that locale’s LCID. Thus the U.S.-English locale’s container would be named 409. Inside of each locale container would be a collection of objects of the class Display Specifier.
Each Display Specifier object has attributes containing the UI element specifications. Because some property pages are common to several classes, a Display Specifier object could be created for each common page or set of pages.
Each class object has an attribute called Display Specification. This is a multi-valued attribute that names zero or more Display Specifier objects.
With this approach, a container structure is set up that is identical to that discussed in the earlier section “Modifying the Schema with a Pointer to a Display Specification Object.” In each locale container, a Display Specifier object with the same name as the corresponding class object would be created. Thus, when you bind to an object of a particular class, you look up the Display Specifier object with the same name as the class in the container for the current locale.
Microsoft is using the approach described in the section “Modifying the Schema with a Pointer to a Display Specification Object,” through Beta 1.
Microsoft will be converting to the “Shadowing the Schema,” option after Beta 1. This approach was chosen for several reasons—simplicity, performance, and a desire to leave the schema untouched. Simplicity is obvious, as is the fact that there are no schema modification requirements. This approach will provide performance gains because fewer binds are required. With the Beta 1 implementation, for each object you must first bind to its schema class object to read the Display Specification. You then need to bind to and read each Display Specifier listed in the Display Specification attribute. The Post-Beta 1 option only requires one bind to the Display Specifier object for the class.
Note that while the Beta 1 option had a small efficiency advantage in that common pages would only need to be listed once, the space saved is not enough to outweigh the advantages of the “Shadowing the Schema” option.
The display information will be fetched when a new class is encountered and the results saved for displaying other objects of the same class. The cache is per-process and nonpersistent.
The Active Directory UI applications will first look in a locale container named after the locale identifier for the current user’s session. If a folder of that name is not found, the U.S.-English locale will be used.
COM objects can be localized either by having a separate binary for each language or by having multiple language resources in a single binary. HTML pages must be translated into separate pages for each language. Similarly, the class name will be translated. Different icons can be specified for each locale. Each locale container will hold Display Specifier objects that correspond to that locale.
Users of the Active Directory can customize it to suit their unique requirements. The user interface can also be changed to suit their needs.
Specifying a parent class and new attributes creates a new class. A Display Specifier object is created for the class (one for each supported locale). If the parent class already has an acceptable UI, that UI is specified and additional pages and menu items can be added for the new attributes. Otherwise, a completely new UI is created and specified. In either case, a new icon can be used.
New attributes can be added to an existing class. New UI components (pages, menu items) can be added or the existing UI replaced. It is also possible to design new property pages that expose fewer class attributes; it is also possible to create context menus with fewer actions.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/ntserver or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).