Before you can deploy a custom template, you first need to know where to find the template information within Active Directory (AD). As noted in the main article, the data you need is in the Microsoft Exchange container in the Configuration naming context (NC). You can use the ADSI Edit tool, which Microsoft includes in the Support Tools on the Windows 2000 Server CD-ROM, to navigate within AD and examine properties of different objects. As Figure A shows, you can navigate to the container you need by going to Services, Microsoft Exchange, organization name (in this case, HP), Addressing, Display-Templates. This container holds several subcontainers, each of which represents the set of display templates for a specific language. The language code provides the name for each container (e.g., 409 is English, 410 is Italian). The Exchange System Manager (ESM) lists the values of the different languages.
After you locate the template data for the language you want to export, you can use the Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) Directory Exchange (Ldifde) tool to export the data in LDIF format. Ldifde is a Windows command-line utility that lets you import and export AD data and is equipped with a syntax that only its author could love. To export all the English language display templates, use the following command:
DC=qtest,DC=cpqcorp,DC=net" -p subtree -r
Typing such a long command without making mistakes is difficult, so I like to use Notepad (or another text editor) to create a batch file for the purpose. Using ADSI Edit, you can select the template container, view its properties, then paste the value of the distinguished name (DN) property into the text editor to ensure accuracy.
The important parameters of the Ldifde command are
- -f template.ldf—Pipes the output to a file called template.ldf, which you can then edit and prepare for import into the production system.
- -d distinguished name of container—Specifies the root of the LDAP search that Ldifde executes to find the desired data. In this example, you'll pass the DN of the container that holds the English language display template.
- -p subtree—Specifies the search scope for the LDAP query. In the example, you'll export from the subtree under the specified DN.
- -r "(objectclass=displayTemplate)"—Specifies the LDAP search filter. If you don't specify a filter, Ldifde returns all objects; you want to export only data about the display templates, so you'll specify the displayTemplate object type.
On my Exchange Server 2003 server, the command generated a 62KB LDIF export file. You'll likely want to run import and export commands after you log on to an Administrator account because Ldifde can then use the credentials of the currently logged-on user to authenticate to AD. The export file contains a lot of information, some of which you don't need and some that you must edit before you can import it into the production system. Figure B shows an edited version of the export data for one display template. You'll notice that the output contains two sets of display tables (DOS and 32-bit clients) in both original and changed variants. Exchange holds the actual data in an encoded format, so you can't make much sense of the information that Figure B shows.
To prepare the LDIF file to be imported to the production system, you must perform the following steps:
- Remove the objectGUID, uSNCreated, uSNChanged, whenCreated, whenChanged, and dSCorePropagationData information. You do so because AD will generate new system-specific data when you import the objects into the production system.
- Check the DN, distinguishedName, legacyExchangeDN, and objectCategory entries to ensure that they reflect the correct values for the production system. As you can see from the extract, Ldifde exports the values as set on the test server, and these might not match the values on the production system. For example, the name of the Exchange organization on the test server is HP (see legacyExchangeDN), but the name might be different in the production environment. The easiest way to make sure the names match is to run ADSI Edit to connect to a production domain controller (DC), verify the values that exist there, then edit the LDIF file to match.
- Save the updated file and give it a suitable name such as import.ldf.
Next, you'll prepare the production system to import the new values. Use ADSI Edit to navigate to the language-specific container for the display templates that you've customized. Right-click the container and select Delete from the context-sensitive menu to remove the existing templates from the configuration. It might seem strange to delete and then import the templates, but it's an effective way to get the job done. As a safeguard, you might want to export the existing template data before you delete it. Then, import the new templates by executing the following command:
Ldifde −i −f import.ldf
Ldifde reads in the commands contained in import.ldf and creates the custom templates in AD. If you have multiple DCs in your environment, the new templates won't be available to all users until replication is finished.