Recipe17.9.Mail-Enabling a User

Recipe 17.9. Mail-Enabling a User

Problem

You want to mail-enable a user.

Solution

Using a graphical user interface

Open the ADUC snap-in.

This needs to be run on a workstation or server that has the Exchange Management Tools loaded (see Recipe 17.6).
If you need to change domains, right-click on Active Directory Users and Computers in the left pane, select Connect to Domain, enter the domain name, and click OK.
In the left pane, browse to the parent container of the user, right-click on the user, and select Exchange Tasks.
On the Welcome screen, click Next.
Select Establish E-mail Address and click Next.
Verify the mail alias is what you want.

Click Modify, select the external email address type (generally SMTP Address), click OK, enter an external email address, and click OK.

There is an Advanced tab on the Internet Address Properties screen. On this tab, you have the option to override the default handling of email sent to this recipient. (e.g., you can force all email to be delivered as HTML or plain text, etc.)

On the Completion screen, click Finish.

Using a command-line interface

> exchmbx -b "<User DN>" -me <smtp email address>

Replace <User DN> with the user's distinguished name and <smtp email address> with the user's external email address.

To mail-enable user joe with the email address joe@unixmail.rallencorp.com, execute the following command. The command should be contained on one line.

> exchmbx -b "cn=joe,cn=users,dc=rallencorp,dc=com" -me joe@unixmail.rallencorp.com

For an alternative Microsoft native tool method, create an LDIF file called mailenable_user.ldf with the following contents:

dn: <User DN>  changetype: modify replace: targetAddress targetaddress: SMTP:<smtp email address> - replace: mailNickName mailNickname: <mail nickname> - replace: mAPIRecipient mAPIRecipient: FALSE - replace: legacyExchangeDN legacyExchangeDN: <legacy exchange DN> - replace: internetEncoding internetEncoding: 1310720 -

Replace <User DN> with the user's distinguished name, <smtp email address> with the user's external email address, and <legacy exchange DN> with the proper legacy exchange distinguished name value. Then run the following command:

>ldifde -i -f mailenable_user.ldf

Using VBScript

' This code mail enables a user. ' ------ SCRIPT CONFIGURATION ------ strUserDN = "<UserDN>"   ' e.g., cn=jsmith,cn=Users,dc=rallencorp,dc=com strEmailAddr = "<EmailAddress>"  'e.g., jsmith234@freemail.net ' ------ END CONFIGURATION --------- set objUser = GetObject("LDAP://" & strUserDN) objUser.MailEnable strEmailAddr objUser.Put "internetEncoding",1310720 objUser.SetInfo( ) Wscript.Echo "Successfully mail-enabled user."

Discussion

A mail-enabled user is a user who has at least one email address defined within Exchange, but does not have a mailbox. This does not give any access rights to the user within the Exchange system; it simply allows Exchange users to select the mail-enabled users from the global address list (GAL) and easily send email to them. You would use a mail-enabled user when you have a user who needs to log into the domain, but has an email address external to the forest's Exchange organization. The email address could be external to the company or it could just be external to the Exchange organization of that forest. Examples would be users with mailboxes on external email systems or users with mailboxes on internal non-Exchange servers.

Mail-enabling a user requires Exchange Data Administrator permissions. See the Discussion for Recipe 17.7.

When you create a mail-enabled user with the ADUC or with VBScript, you call out to the CDOEXM interface, which is the Microsoft-supported method of managing Exchange attributes on users, groups, and contacts. The specific method in this case is MailEnable. In the background, the specific changes made by the MailEnable method are on the user object in Active Directory and include changes to the following attributes:

targetAddress
mailNickname
mAPIRecipient
legacyExchangeDN

In addition to those attributes, the internetEncoding attribute should also be set for proper message handling. This is the attribute that is updated if you go into the Advanced tab of the Internet Address Properties screen. The default value for this attribute is 1310720, which tells Exchange to use the default settings of the Internet Mail Service. You can specify other values to force email to be converted to various formats. Table 17-3 lists alternate values for the internetEncoding attribute.

Table 17-3. internetEncoding attribute values
Value	Meaning
`1310720`	Use Internet Mail Service settings.
`917504`	Allow plain text.
`1441792`	Allow plain text or HTML.
`2228224`	Allow plain text/uuencoding.
`131072`	Allow plain text/uuencoding with BinHex.

Once all of those attributes are in place, the RUS sets additional attributes on the user object to make it usable for Exchange.

Using a graphical user interface

Mail-enabling a user is a little more confusing if you are creating new users because you don't get prompted to mail-enable them. To create a mail-enabled user from scratch, create the user and, when prompted to create a mailbox, clear the Create an Exchange Mailbox checkbox. Once the user is created, follow the directions described in the solution.

Using a command-line interface

Command-line administration tools for Exchange are rather rare. Luckily, the ExchMbx tool is available as a free download from Joe Richards' web site http://www.joeware.net. This tool can turn a difficult process into something simple. If you need to modify the internetEncoding attribute as mentioned above, add the -internetencoding option to the parameter list specifying the proper value from Table 17-3. For example:

> exchmbx -b <UserDN> -me <SmtpEmailAddress> -internetencoding 917504

If you prefer Microsoft native solutions, the LDIF solution I described will work, but it can be dangerous because there is the possibility of duplicating critical values within the Exchange organization. If you put duplicate mailNickname or legacyExchangeDN values into the system, you will have bad results in your Exchange organization, and almost certainly, start producing nondelivery reports (NDR) for the mail objects involved.

The mailNickname attribute generally can be set to be the same as the sAMAccountName, which has to be unique in the domain. But what should you do you with legacyExchangeDN? If you aren't tied to a legacy 5.5 organization, you can follow the simple format the system currently uses. If you have a legacy 5.5 organization, you need to follow the structure for that organization. For assistance with this, contact Microsoft PSS or Microsoft Consulting Services.

The general format of legacyExchangeDN is:

/o=<Org>/ou=<AdministrativeGroup>/cn=<RecipientContainer>/cn=<mailnickname>

Assuming your mailNickName is unique (it had better be) and you know the values for the other variables, you can quickly construct a legacyExchangeDN like:

 /o=CORPMAIL/ou=NORTHAMER/cn=Recipients/cn=NICOLEHANSKNECHT

You should always verify that the legacyExchangeDN you chose is not already used by searching Active Directory, because someone may have changed an existing user's mailNickname but, correctly, did not touch the legacyExchangeDN value. You could, of course, "fix" the legacyExchangeDN of that previously existing user so that it properly fits the pattern, but you would impact the user's email functionality.

The attribute legacyExchangeDN is used in Exchange internally for addressing email. If you try to respond to an email sent to you by a user within the same Exchange organization who has had her legacyExchangeDN changed, you will get an NDR and the mail will not be delivered. So if a user has a name change from Chris Smith to Chris Jones and her sAMAccountName and mailNickname both change from csmith to cjones, her legacyExchangeDN must remain the same so that anyone within the Exchange organization will be able to easily respond to emails she sent as csmith. The point is that you should always check that the legacyExchangeDN value you are setting is unique. The simple solution to follow if the value is already present is to append a -1, -2, or whatever dash value is required to get to a unique value.

You have the option of not specifying the legacyExchangeDN in the LDIF file. If the attribute is empty, Exchange will populate it for you. If there is already a value, Exchange will not change the attribute.

Unfortunately, if you are mail enabling an object that was previously mail- or mailbox-enabled it could have an existing value for legacyExchangeDN; this value may or may not be unique. One very specific case is that some tools will set the legacyExchangeDN value to ADCDisabled when an object is mail or mailbox disabled to alert the ADC to the object's status.

You can modify the internetEncoding attribute value in the LDIF file to any value in Table 17-3.

If you want to mail-enable multiple users at once, remove the -b option from the parameter list and pipe the distinguished names into ExchMbx from another tool or from a file. Run exchmbx /? for usage details.

Using VBScript

Creating a mail-enabled user from VBScript is quite simple; one call to the MailEnable method and the work is done. As I indicated in the CLI solution, you can modify the internetEncoding value to some other value in Table 17-3, depending on your needs.