Extending Active Directory's GUI

Icons
When you use the ADUC tool to look at a container of objects, the ADUC shows you an icon that is appropriate to the specific class for that object. The icons for OUs look different from those for containers, users, and printers. You can also use the icon to represent different states of that object. For example, you can change the icon to show a disabled user or computer object. You can define 16 icons to represent different states for any object class. The first three represent the closed (the default state), open, and disabled states; you can define the last 13.

To modify the icon for an object class, simply use the Icon-Path attribute to store multivalued data, as Listing 2 shows. This modification sets the first four icon values. The number 0 sets the value to closed, 1 to open, and 2 to disabled; 3 through 15 are the values that you define. The code in the first line of Listing 2 uses a proper icon file with an .ico extension, so it doesn't need a third parameter. The code in the second, third, and fourth lines of Listing 2 uses the first (0), third (2), and eighth (7) icons from myicons.dll, which uses an index for the set of icons held in the DLL starting at 0. The icon path has to exist on the local machine for any client to properly display the icon, so you might need to deploy the icon files to all clients in an enterprise before they can properly display the icons.

Class and Attribute Names
You can alter the way class and attribute names appear within a GUI. To change the class name, change the text in the class-Display-Name property of the relevant Display-Specifier object. To change the attribute names, you need to modify the multivalued attribute-Display-Name attribute. Attribute values take the form of a comma-delimited string, which Listing 3 shows. The first value is the Lightweight Directory Access Protocol (LDAP) name that corresponds to the attribute in the schema; the second value is the name that it will display.

Leaf or container. When you view objects in the ADUC interface, some display as containers and some display as leaf objects. Most objects act as containers, even when they display as leaf objects. Let's look at a printer on a computer. If the computer is publishing the printer as a Print-Queue object to the AD, the object displays as a leaf object within the Computer object that is publishing the printer. In other words, the Computer object acts as a container for any print queues that it publishes.

User, Computer, and Group objects by default don't display themselves as containers. In fact, the ADUC tool has an option on the View menu called View Users, Groups, and Computers as containers that adds this capability. For other objects, you can go to the Display-Specifier and change the Boolean value Treat-As-Leaf to True or False to modify any object's default setting.

Object creation wizard. When you create a user, group, or OU, the system provides a simple wizard to let you specify the relevant data for that object. To modify the default behavior, you can replace the wizard or you can add pages to the wizard. You can have only one wizard, so you must create a new one or modify the existing one. Let's suppose you want the Languages-Spoken attribute for a user to be a mandatory attribute of the user class. This attribute forces you to define a value for Languages-Spoken for all new users on creation. The existing User creation wizard doesn't let you input data for this attribute, so you can replace the wizard or place a new page in the wizard to receive data for this attribute. The attribute doesn't have to be a mandatory attribute for you to add a new page; you can also provide wizard pages for any optional attributes. You can provide as many extra pages as you choose and in whatever order you prefer.

As you do with property pages, you need to create a new wizard or extend the creation wizard (the default wizard) as a COM object that supports the IDsAdminWizExt interface. A new wizard that replaces the default wizard is known as a primary extension. This wizard replaces the core set of pages that you would use to create the object. Primary extensions support the extension of the creation wizard, so you can define a primary extension for all users and later extend the creation wizard to add extra pages. You use the COM object UUID to identify the items in the AD. When you replace the default wizard with a primary extension, you modify the Creation-Wizard attribute of the relevant Display-Specifier object to hold the UUID of the COM object. When you provide creation wizard extensions, you specify the order in which the pages will appear, then add the UUID in the Create-Wizard-Ext multivalued attribute. The format is the same as for property pages.

Context menus. When you right-click an object in the ADUC tool, a context menu pops up. You can add your own entries to this context menu. The Admin-Context-Menu attribute on the Display-Specifier object holds the menu items for this context menu. You can also add entries to the context menus that appear in the shell for end users. The Shell-Context-Menu attribute on the Display-Specifier object holds these items. You need to put items that you want to appear in the shell and ADUC in the Context-Menu attribute.

The items that you add to the context menus can launch an application or create an instance of a COM object. The data takes form in the relevant attributes, which Listing 4 shows. The code in the third line of Listing 4 is a COM object. The UUID identifies the object. You must have created the COM object to support the IShellExtInit and IContextMenu interfaces. You can include a third parameter on the line to pass extra data to the COM object. The previous two lines of code are much more important to administrators. In the first and second line of code in Listing 4, you can see that I'm adding two extra items to the menu: an executable program and a VBScript script. You can add any type of application. The second parameter is the string that I want to appear on the context menu. Use of an ampersand (&) character before a letter identifies that letter as the menu selector. So, when the menu displays, typing D selects the first option (i.e., E:\myprog.exe) and E selects the second option (i.e., C:\myscript.vbs).

The ability to add scripts and programs to a context menu is a significant step forward. When you couple these scripts and programs with Microsoft Active Directory Service Interfaces (ADSI), you have a way to offer new functionality directly from the GUI. Let's say you want to extend the schema and include a new optional Languages-Spoken attribute for the user class. You can go to the user-Display Display-Specifier object and modify the Context-Menu attribute (so that the attribute is available to both users and administrators) to include an ADSI script that displays the languages spoken for that user in a message box. Listing 5 shows a Windows Scripting Host (WSH) 2.0 script written in Extensible Markup Language (XML) with an embedded ADSI VBScript script. To use that script as the program, simply save the file with a .ws extension (as a Windows Script—WS—file). For more information about how to use XML tags with WSH 2.0 to run scripts, see Dino Esposito, Windows Script Host Programmer's Reference (Wrox Press, 1999), or Bob Wells, Scripting Solutions, "Windows Scripting Host 2.0," December 1999.

The script binds to the object's ADsPath and passes to the program the object's ADsPath as an argument and displays the attribute in a message box, which Screen 5 shows, with an appropriate title. In the message box, I right-clicked the Guest user, and a context menu popped up that includes Languages Spoken. In the bottom left corner, you can see that the box's title is a display of the string

&Languages Spoken...

When I click the item or press the L key, Listing 4 generates and displays a dialog box. (The dialog box and the context menu don't display together.)

You can also write a script or program that lets you modify the Languages-Spoken attribute and have the attribute appear only on the administrator's context menus. Then, you can use the ADUC tool to manage your users and this extra attribute without developing a new interface. (For more information about how you can use personal customizations to extend the Win2K GUI, see the Microsoft article "Shell Extension Handlers" at http://msdn.microsoft.com/library/sdkdoc/shellcc/shell/shellext.htm and the Microsoft article "Extending the User Interface for Directory Objects" at http://msdn.microsoft.com/library/sdkdoc/adsi/gldispl1_06pf.htm.)

Next time, I'll discuss the extension-attributes idea further. I'll look at how to use Microsoft Excel 2000 to automatically generate Win2K reports.

Source: Adapted from Alistair G. Lowe-Norris, Windows 2000 Active Directory (O'Reilly and Associates, 2000).