Implementing Directory Synchronization between a non-Exchange Messaging System and Active Directory

Article
07/25/2014

This section explains how to perform directory synchronization manually between an LDAP-conforming directory and Active Directory. For more information about how to create recipient objects programmatically, see Understanding Interoperability and Migration in Exchange Server 2003.

You must complete the following steps to perform directory synchronization between a non-Exchange messaging system and Exchange 2003:

Extract the source directory information into a migration file Directory information can usually be obtained from a messaging system in several ways. One way is to use directory export features included in the administrative tools included with the non-Exchange messaging system. Another way to obtain directory information from a messaging system is to use the Exchange Migration Wizard, as discussed earlier in this topic. For example, you can use the Exchange Migration Wizard to extract directory information from an LDAP-conforming directory. For detailed instructions about how to use the Exchange Migration Wizard to extract LDAP directory information, see How to Perform a Semi-Automated Directory Synchronization.

If you run the Exchange Migration Wizard against an LDAP directory other than Netscape Directory Server, you might notice that the migration wizard is unable to identify user objects correctly and thus is unable to perform the extraction. Some clues that this problem exists include users being listed as Internet containers on the Containers wizard page and an empty accounts list on the Account Migration wizard page.

By default, the Exchange Migration Wizard expects user accounts to have an object class of inetOrgPerson. If your directory uses another object class, the migration wizard cannot identify and migrate the user accounts unless you edit the .ini file called mlmigad.ini, located in the \Program Files\Exchsrvr\Bin directory and specify the object class of the user account in the ADSI_ObjectClass line. For example, Active Directory uses an object class of organizationalPerson for user accounts. Table 1 lists all settings that you can specify in mlmigad.ini.

Table 1 Mlmigad.ini configuration parameters for LDAP directory exports

Parameter	Default value (corresponds to Netscape Directory Server)	Active Directory equivalent	Description
ADSI_ObjectClass	inetOrgPerson	organizationalPerson	Used to determine which objects are mail users.
ADSI_UserID	uid	cn or sAMAccountName	When extracting LDAP information for a subsequent migration of IMAP4 mailboxes, this parameter is used by the IMAP extractor to log on to the IMAP mailbox. This is a required attribute.
ADSI_MailServer	mailhost	Mailhost	When extracting LDAP information for a subsequent migration of IMAP4 mailboxes, this parameter is used by the IMAP extractor to log on to the IMAP mailbox. This is a required attribute.
ADSI_EmailAddress	mail	Mail	When extracting LDAP information for a subsequent migration of IMAP4 mailboxes, this parameter is used as a secondary proxy address in Exchange. Mail sent to this address is routed to the Exchange mailbox. This is a required attribute.
ADSI_FullName	not specified	displayName	Used to create a display name in Exchange. If this is left blank, the display name is created from other attributes, such as the e-mail address. This is an optional attribute.
ADSI_FirstName	givenname	givenName	The user's first name. This is an optional attribute.
ADSI_LastName	sn	Sn	The user's last name. This is an optional attribute.
ADSI_Initials	initials	Initials	The user's middle initial(s). This is an optional attribute.
ADSI_NickName	uid	mailNickname	The user's short name, also used for the Exchange alias. This is an optional attribute.
ADSI_Title	title	Title	The user's title. This is an optional attribute.
ADSI_Company	not specified	company	The user's company name. This is an optional attribute.
ADSI_Department	ou	department	The user's department name. This is an optional attribute.
ADSI_Office	roomnumber	physicalDeliveryOfficeName	The location of this user's office. This is an optional attribute.
ADSI_PostalAddress	postaladdress	streetAddress	The user's postal address. This is an optional attribute.
ADSI_City	l	L	The user's city. This is an optional attribute.
ADSI_StateOrProvince	st	St	The user's state or province. This is an optional attribute.
ADSI_PostalCode	postalcode	postalCode	The user's postal code. This is an optional attribute.
ADSI_Country	not specified	Co	The user's country. This is an optional attribute.
ADSI_TelephoneNumber	telephonenumber	telephoneNumber	The user's business telephone number. This is an optional attribute.
ADSI_TelephoneNumber2	not specified	otherTelephone	The user's second business telephone number. This is an optional attribute.
ADSI_TelephoneHome	homephone	homePhone	The user's home telephone number. This is an optional attribute.
ADSI_TelephoneHome2	not specified	otherHomePhone	The user's second home telephone number. This is an optional attribute.
ADSI_TelephoneMobile	mobile	mobile	The user's mobile telephone number. This is an optional attribute.
ADSI_TelephonePager	pager	Pager	The telephone number of the user's pager. This is an optional attribute.
ADSI_TelephoneFax	facsimiletelephonenumber	facsimileTelephoneNumber	The telephone number of the user's fax machine. This is an optional attribute.
ADSI_AssistantName	secretary	assistant	The name of the user's assistant. This is an optional attribute.
ADSI_AssistantPhone	not specified	telephoneAssistant	The telephone number of the user's assistant. This is an optional attribute.
ADSI_AlternateAddress	mailalternateaddress	proxyAddresses	Used as an additional SMTP address for the user in Exchange. This is an optional attribute.
ADSI_Comment	description	Info	The comment for this user. This is an optional attribute.

Note

The Exchange Migration Wizard ignores nonexistent or misspelled directory attributes.

Format the exported directory information for directory import Running the Exchange Migration Wizard with a properly configured mlmigad.ini file against an LDAP directory creates a directory.pri migration file that contains all of the exported recipient information. Figure 1 shows a sample directory.pri file from an Internet mail system.

Figure 1 A sample directory.pri file

You can use the information from this file to format an import file in LDAP Data Interchange Format (LDIF) so that you can use Ldifde.exe to create or update recipient information in Active Directory. The following listing shows an LDIF file for importing three accounts into Active Directory. Importing this LDIF file creates mail-enabled contacts in a dedicated organizational unit named Remote SMTP Recipients. You must create the organizational unit before you import the accounts.

dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: add

objectClass: contact

cn: Ted Bremer

sn: Bremer

givenName: Ted

displayName: Ted Bremer

mailNickname: Ted

targetAddress: SMTP: Ted@legacy.fabrikam.com

mail: Ted@legacy.fabrikam.com

extensionAttribute1: Manual DirSync Process

dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: add

objectClass: contact

cn: Birgit Seidl

sn: Seidl

givenName: Birgit

displayName: Birgit Seidl

mailNickname: Birgit

targetAddress: SMTP: Birgit@legacy.fabrikam.com

mail: Birgit@legacy.fabrikam.com

extensionAttribute1: Manual DirSync Process

dn: CN=Kim Akers,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: add

objectClass: contact

cn: Kim Akers

sn: Akers

givenName: Kim

displayName: Kim Akers

mailNickname: Kim

targetAddress: SMTP: Kim@legacy.fabrikam.com

mail: Kim@legacy.fabrikam.com

extensionAttribute1: Manual DirSync Process

Note

For more information about how to use Ldifde.exe to create user accounts and how to convert a .csv file into an LDIF file using a Microsoft Excel macro, see Understanding Interoperability and Migration in Exchange Server 2003.
Import the directory information into Active Directory Importing a properly formatted LDIF file using Ldifde.exe is a straightforward process. Use the following commands at a command prompt: ldifde -i -f <import file> -s <Server>, for example, ldifde -i -f c:\importfile.ldf -s Server01.

If you attempt to create new accounts for users who already exist in Active Directory, Ldifde.exe reports an error and stops the import process. You might need to search Active Directory for existing user accounts that correspond to recipients in the non-Exchange messaging system and modify the import file to change attributes for those accounts instead of adding new accounts. Searching and updating Active Directory objects is explained below.

The following response indicates that an account already exists:

Importing directory from file "c:\importfile.ldf"

Loading entries.

Add error on line 1: Already Exists

The server side error is "An attempt was made to add an object to the directory

with a name that is already in use."

0 entries modified successfully.

In contrast, a positive response contains the following information:

Logging in as current user using SSPI

Importing directory from file "c:\importfile.ldf"

Loading entries....

3 entries modified successfully.

The mail-enabled contacts now exist in Active Directory and Exchange users can select these contacts from the global address list to send them messages. Figure 2 shows the contact objects in the Remote SMTP Recipients organizational unit.

Figure 2 Mail-enabled contacts imported for Internet mail users
Keep the directory information updated in Active Directory You might want to perform an update of recipient information whenever the address lists change in the source directory system, so that all directories contain consistent information. The simplest way to do this is to delete all previously imported recipient objects from Active Directory and then perform a new import with fresh information extracted from the source directory. You need to find only the previously imported objects. When you analyze the LDIF import listing shown above, you will find the following line in each account section: extensionAttribute1: Manual DirSync Process. This information is used to associate the user accounts with the manual directory synchronization process. You can create a filter based on this information to retrieve all objects that were previously created from Active Directory. For example, you can use the following command at a command prompt to search through an entire domain in a global catalog server for all recipient objects for which extensionAttribute1 has a value of Manual DirSync Process:

ldifde -f c:\Exportuser.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(extensionAttribute1=Manual DirSync Process)" -l "targetAddress"

Ldifde.exe writes the following results into the export file:

dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: add

targetAddress: SMTP: Ted@legacy.fabrikam.com

dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: add

targetAddress: SMTP: Birgit@legacy.fabrikam.com

dn: CN=Kim Akers,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: add

targetAddress: SMTP: Kim@legacy.fabrikam.com

To delete these accounts, you must change the exported file into an import file with the following LDIF content and import the file using an LDIFDE import command, such as ldifde -i -f c:\importfile.ldf -s Server01:

dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: delete

dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: delete

dn: CN=Kim Akers,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: delete

After you have deleted the outdated account information, you can re-import the new address list to re-create all contacts with fresh directory information. However, deleting and re-creating the entire address list each time changes occur might not be a good approach. The Recipient Update Service must assign all objects new e-mail addresses, all objects must be replicated to the global catalog again, and deleting the old accounts might not even be possible if your Internet mail users work with mail-enabled user accounts in Active Directory.

Important

If you delete a Windows user account and re-create it afterwards, you create an entirely new object with a different security identifier. In other words, your users will lose all special permissions to file shares and other resources that have been assigned to their old user accounts individually. Therefore, if your users work with mail-enabled user accounts, do not use the approach of deleting and recreating recipient objects in Active Directory to keep directory information synchronized.

A best practice when performing directory updates is to compare the address information from the source directory with the directory information that is in Active Directory. You can use the common name, e-mail address, or any other user attribute that supports a reliable association of directory objects to access the existing information in Active Directory. For example, the following LDIFDE command retrieves the display name and telephone number for all recipient objects that have an SMTP domain of legacy.fabrikam.com in their e-mail address from a global catalog server.

ldifde -f c:\Exportuser.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com"

-p subtree -r "(mail=*@legacy.fabrikam.com)" -l "displayName,telephoneNumber"

You can examine the resulting export file to determine all recipients with changed display names or telephone numbers, create a new LDIF file with updated values, and import this file into Active Directory to update the values for the existing accounts. The following LDIF file shows how to modify the display name for two recipients. To demonstrate how to modify two attributes for an account, the telephone number is also changed for the first object:

dn: CN=Ted Bremer,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: modify

replace: displayName

displayName: Ted

-

replace: telephoneNumber

telephoneNumber: 425 5550150

-

dn: CN=Birgit Seidl,OU=Remote SMTP Recipients,DC=fabrikam,DC=com

changetype: modify

replace: displayName

displayName: Birgit

-
Perform directory synchronization in the opposite direction You must also update the non-Exchange directory using the same principles discussed for Active Directory updates to implement directory synchronization from Active Directory to the legacy directory. As outlined earlier, the Exchange Migration Wizard can extract directory information from Active Directory into a directory.pri file. Ensure that you specify organizationalPerson for the ADSI_ObjectClass in the mlmigad.ini file. Otherwise, the Exchange Migration Wizard will not be able to identify the user accounts. You can also use Ldifde.exe to export all users with mailboxes in Exchange Server 2003, which enables you to export selected mailbox-enabled user accounts only. You must exclude all mail-enabled recipient objects that refer to users with mailboxes in the legacy messaging system. The following command retrieves all mailbox-enabled user accounts from a global catalog server:

ldifde -f Exportuser.ldf -s Server01 -t 3268 -d "dc=fabrikam,dc=com" -p subtree -r "(&(objectClass=User)(homeMDB=*))" -l "cn,mail,samAccountName"

Note

For information about how to import directory information for SMTP recipients, contact the vendor of your non-Exchange messaging system.

Implementing Directory Synchronization between a non-Exchange Messaging System and Active Directory

Table 1 Mlmigad.ini configuration parameters for LDAP directory exports

Additional resources