Exchange Server's messaging directory service has undergone quite a change since the introduction of Exchange 2000 Server. With that release, directory-service responsibilities moved from the Exchange Server 5.5 Directory Service (DS) to Windows 2000's Active Directory (AD). This change complicated a common Exchange administrative task: bulk manipulation of directory objects and attributes.
Exchange 5.5 provides the Microsoft Exchange Administrator Directory Export and Directory Import options (which you can also run from the command line as admin /e and admin /i) to accomplish this task, but these options no longer exist in Exchange 2000. You can continue to use that method as long as your Exchange organization operates in a mixed-mode environment (i.e., you still operate at least one Exchange 5.5 server); the Active Directory Connector (ADC) will synchronize changes between the DS and AD. (However, if you use Exchange Administrator to manipulate objects that belong to Exchange 2000, you must understand the attribute mappings that the ADC uses to synchronize the DS and AD—otherwise, you might overwrite necessary attributes or corrupt a mailbox object. Consequently, you should use Exchange Administrator to manipulate only those objects that are homed in the DS. For information about ADC synchronization, see Kieran McCorry, "How to Customize DS-to-AD Attribute Synchronization," March 2001, InstantDoc ID 19712.) When you introduce Exchange 2000 into your environment, you need a new method for managing bulk directory-export and directory-import of Exchange 2000 objects. Doing so will help you ensure that your organization's Microsoft Outlook Global Address List (GAL)—users' predominant view of AD—always contains up-to-date information and that AD contains the attribute objects you need to meet your Exchange organization's needs.
In Exchange 5.5, changes you make to the DS affect only Exchange objects. But in Exchange 2000, changes you make to AD are more far-reaching and can affect not only Exchange but also your network's basic Windows infrastructure. How can you safely and effectively apply bulk attribute-manipulation methods in AD? The Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, VBScript, and three Lightweight Directory Access Protocol (LDAP) 3.0compliant utilities—Ldp, Ldifde, and Csvde—can help you get the job done.
Before You Begin
This discussion assumes that you're familiar with Win2K, AD, and Exchange 2000 and that you have the required system privileges to access AD objects. By default, the Win2K Domain Admins built-in group has full control over every object in a domain; the Enterprise Admins built-in group has full control over every object in a forest. Users in the Account Operators, Administrators, or Domain Admins groups have full control over user objects and can read and modify all attributes, including mailbox location and other Exchange-related information. When you run Forestprep before installing the first Exchange 2000 server in your environment, Exchange 2000 Setup assigns Exchange Full Administrative account permissions to one account (either one you choose or the one you use to run Forestprep). This account then has authority to install Exchange 2000 throughout the forest and to run the Exchange Administration Delegation Wizard, which configures Exchange-specific roles for administrators across the forest. (For an in-depth discussion of Exchange roles and permissions, see the white paper "Microsoft Exchange 2000 Internals: Permissions Guide" at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/exchange/deploy/depovg/exchperm.asp.)
You must log on as an Administrator in the Exchange Administrator role for all procedures; otherwise, you might not be able to perform the necessary export or import operations. Carry out the procedures in a test AD environment, and apply the methods I discuss to your production environment only after you've mastered the procedures.
To begin, open the Active Directory Users and Computers snap-in on your test system. Create a sample organizational unit (OU) and give it an appropriate name (e.g., MSX-Testing). Right-click the OU object, then choose New, User from the context menu to create a new user object named AD-Test User; create an Exchange mailbox for the user. Open the new user object's Properties dialog box, and confirm that values exist for First Name, Last Name, and Title. You'll use this user account to explore the various approaches to bulk directory-manipulation methods. The following examples use the sample company name XYZ Company, with the Fully Qualified Domain Name (FQDN) xyz.com, the domain xyz, and the domain controller (DC) xyzDC. As you carry out your tests, replace the sample names with names specific to your test installation.
Using Ldp to View Attributes
Ldp is an LDAP client utility that comes with the Win2K Support Tools, which you can install with the Win2K CD-ROM's \support\tools\setup.exe program. The tool lets you view all the attributes of an AD object (similar to using Exchange Administrator's /r option to view the Exchange 5.5 DS in raw mode). The Support Tools also include the similar ADSI Edit tool. You can use either Ldp or ADSI Edit to modify and view AD. These utilities differ in the level of granularity available through each tool's UI. ADSI Edit uses a more developed UI that uses an MMC snap-in similar to Active Directory Users and Computers. You can access objects through context menus and select attributes from a drop-down box to view them one by one. Ldp's UI displays objects in the left-hand pane and attributes in the right-hand pane. When you select an object in the left-hand pane, all available attributes and values for that object appear in the right-hand pane. Therefore, Ldp provides a way to view all object attributes quickly and efficiently. (For a further comparison of Ldp and ADSI Edit, see Tony Redmond, "Introducing the ADSI Edit Utility," July 2000, InstantDoc ID 8901.)
You can use Ldp to view AD on a regular DC or on a Global Catalog (GC) server. A DC contains a read/write copy of all AD objects and attributes for the domain; a GC contains a read-only replica of every object in every domain in the forest but contains only a select set of attributes for each object. I suggest you stage your test environment so that you can view and validate AD data from both a DC and a GC. Before proceeding, read the Microsoft article "XADM: Browsing and Querying Using the LDP Utility" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q255602) for detailed instructions about using Ldp.
Select Windows 2000 Support Tools, Tools, Active Directory Administration Tool to open the Ldp utility. From the menu bar, select Connection, Connect to open the Connect dialog box, which Figure 1, page 12, shows. In the Server text box, enter the name of the DC (i.e., xyzDC) that owns the OU you created ; in the Port text box, enter 389 to connect to AD. Click OK and note the output that appears in the tool's right-hand pane. Note the value of the defaultNamingContext attribute, which appears near the top of the output. This value is equivalent to your FQDN. You'll need to remember this value and syntax. For the sample company, this value is
Next, you must bind to the directory (i.e., you must authenticate). From the Ldp menu bar, select Connection, Bind to open the Bind dialog box, which Figure 2 shows. Enter the domain credentials (i.e., User, Password, and Domain) of a privileged account, then click OK.
Next, select View, Tree from the Ldp menu bar. Enter the name of the test OU and the defaultNamingContext value, as follows:
Ldp displays the Tree value (i.e., ou=msx-testing,dc=xyz,dc=com) in the left-hand pane. Double-click the value to display the contents of the OU. From the Ldp menu bar, select Connection, New to clear the right-hand pane's contents; double-click the AD-Test object in the left-hand pane to display its attributes in the right-hand pane. Note that the only attributes that appear are those for which you've defined values.
Run Ldp again, but enter Port 3268 (instead of 389) to connect to AD through a GC. Notice that Ldp no longer displays attributes such as AccountExpires and HomeDrive for the tree value.
Web Table 1 at http://www.exchangeadmin.com, InstantDoc ID 24129, shows the AD attributes that affect what users see when they browse the GAL. This table is a useful reference to keep on hand when you're contemplating changes to AD. To make these changes, you can export object information from AD, edit the information, then import it back into AD.
Using Ldifde to Modify Attributes
LDAP Data Interchange Format (LDIF) is an Internet standard for the file format that you can use to perform batch operations against any LDAP 3.0compliant directory service. (Internet Engineering Task Force—IETF—Request for Comments—RFC—2849 defines the standard.) To support batch import and export operations, Win2K Server includes the Ldifde (ldifde.exe) utility in the \systemroot\system32 directory. (For detailed information about using Ldifde, including an explanation of the tool's command-line parameters, see the Microsoft article "Using LDIFDE to Import and Export Directory Objects to Active Directory" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q237677.)
First, use the tool to export the AD-Test mailbox attributes. Open a command prompt and type
ldifde -f test-xport.ldf -s xyzDC -d "ou=msx-testing, dc=xyz,dc=com" -l "sn, givenname,title,department"
Ldifde will report a successful completion with one entry. (If you omit the -l, or list, parameter, Ldifde will export all attributes with values.) Next, enter the following command to open the export file test-xport.ldf in Notepad.
This command will open Notepad and display the output that Figure 3 shows. The output includes the object's distinguished name (dn) attribute and defines the object's changetype attribute as add. The other attributes appear in alphabetical order; attributes without values don't appear in the output.
You must substantially edit the resulting output file before you can use Ldifde to import the file and implement changes to AD. You need to follow certain rules depending on whether you want to add, modify, or delete user objects. For each operation, the dn attribute and value must be present for each object and must be immediately followed by the changetype attribute, as Listing 1 shows.
To use the import file to add user objects, use the add changetype attribute (i.e., changetype: add). Each added object must include certain attributes and values (i.e., cn: value, objectclass: user, and samAccountName: value) followed by any optional attributes and values. Each attribute must appear on a separate line, and you must separate each object with one blank line.
To use the import file to modify user objects, use the modify changetype (i.e., changetype: modify). You must identify each attribute you want to modify with the syntax
replace: <attribute_name> <attribute_name>: <value>
After the first replace and attribute set, separate each set with a dash (-), as Listing 1 shows. Separate objects with a dash and one blank line.
To use the import file to delete user objects, use the delete changetype (i.e., changetype: delete). Separate each consecutive object with one blank line.
Edit the test-xport.ldf file, as Listing 1 shows. Save and close test-xport.ldf and import the changes to AD:
ldifde -l -i -f test-xport.ldf -s xyzDC
The program reports a successful completion with one entry modified. Use the Active Directory Users and Computers snap-in to open the AD-Test User object's Properties dialog box, and confirm that the procedure successfully modified the object's Title attribute and that the object now has a value for the Department attribute.
As you can imagine, using this manual editing technique to apply changes to hundreds of user objects is impractical. Alternatively, you can use VBScript to create the export file. The advantage is that you can use VBScript to output the replace value and the separating dashes. You can also use VBScript to export attributes that don't yet have a value.
In the Active Directory Users and Computers snap-in, create two more user objects (e.g., AD-Test OtherUser1, AD-Test OtherUser2). For both objects, define the Company attribute as XYZ Company; don't enter a value for the Department attribute. Also confirm that AD-Test User's Company attribute is empty.
Next, run the sample VBScript file test-vb.vbs, which Web Listing 1 at http://www.exchangeadmin.com, InstantDoc ID 24129, shows. To run the script, at a command prompt type
When the script finishes running, a pop-up message that reads Finished will appear. Open the output file test-vb-out.ldf to view the results, which Figure 4 shows. Note that for all three objects, the Department attribute is Testing; for AD-Test User, the Company attribute is empty; and for AD-Test OtherUser1 and AD-Test OtherUser2, the Company attribute is XYZ Company. You can edit this file to ensure that each attribute has a corresponding value, then use Ldifde to import the changes with the command
ldifde -i -f test-vbt-out.ldf -s xyzDC
Open the Active Directory Users and Computers snap-in. Confirm that the import operation and object modifications were successful.
Using Csvde to Modify Attributes
You can use the Csvde utility (in the Win2K \systemroot\system32 directory) as an alternative to Ldifde. You can use Csvde to export object attributes to a Comma Separated Value (CSV) file, which makes the information easier to edit, sort, and manipulate. The drawback is that you can use Csvde only for add operations, to create new AD objects. (For information about using Csvde, see the Microsoft article "XADM: How to Use CSVDE.EXE to Backup and Restore Connection Agreements" at http://support.microsoft.com/default.aspx?scid=kb;en-us;q276440.)
To see how user objects' attributes appear in a CSV file, open a command prompt and type
csvde -f test-xport.csv -s xyzDC -d "ou=msx-testing,dc=xyz, dc=com" -l "displayname, title,department"
Open the resulting test-xport.csv file in Microsoft Excel. Note that the output, which Figure 5, page 14, shows, includes the dn attribute followed by all other attributes in alphabetical order—including those attributes without values. The second row contains the container value (i.e., OU=MSX-Testing,DC=xyz,DC=com).
Although Csvde's use is limited, the tool can be useful in scenarios such as new Win2K implementations. Suppose that you've kept up-to-date user information in an Excel spreadsheet. You can modify this spreadsheet and use it as a Csvde import file to easily create mailbox-enabled users in the Win2K forest. Another possible use for Csvde is in a situation in which your company, which has an established AD, expands corporate operations and needs to update users' telephone-number, location, and manager attributes. You can use Csvde to export the data into an Excel file, update the file as necessary, then reformat the data into Ldifde format and use Ldifde to import the modified data. (To download a sample Excel spreadsheet that reformats CSV data into Ldifde-ready input, go to http://www.exchangeadmin.com, enter 24129 in the InstantDoc ID text box, and download the 24129.zip file.)
Know Your Options
The sample exercises in this article are simple, but they provide the basics of using Ldifde and Csvde to update your users' Exchange 2000 attributes. The best approach to changing existing objects will depend on the kind of change you need to make: A simple modification, such as a global company name change, is easy to accomplish by using Ldifde and VBScript; whereas changing each user's telephone number might require using Csvde and Ldifde. When you have a clear understanding of the strengths and weaknesses of the available tools, you can exploit them to your best advantage—whatever the situation.