In an InterOrg scenario, there is usually a corporate directive to represent all employees under a new single SMTP designation. The old SMTP address must be maintained for reply ability and routing behind the firewall.
The preferred solution is to create Custom Recipients (Foreign Entries) by using SMTP addresses for which the primary or reply SMTP address is the domain component that is common to the merged organization, but for which the target address is a proxy or routing SMTP address. This allows users inside or outside the company to reply to the new address while the Exchange server takes responsibility for routing the message by using the old SMTP address.
The objective is to use the MMS Exchange Lightweight Directory Access Protocol (LDAP) management agent (MA) to perform an InterOrg synchronization while reassigning primary and secondary SMTP addresses to allow for a routing solution behind the firewall.
Example
In the following example, an imaginary merger occurs in which two Exchange organizations, "Org1" and "Org2", are now to be represented as "company.com" in all future e-mail correspondence. In the following code samples, the Exchange format of the word "SMTP" in upper case denotes the primary reply address and the word "smtp" in lower case denotes proxy addresses. Based on the new requirements, all users now have a primary SMTP address showing the common domain name. To allow mail delivery to continue, the previous primary smtp address has been retained as a proxy address in the MMS otherMailbox attribute.
Organization1
Mailbox: Primary reply is the external address.
SMTP: John.Coake@company.com
smtp: john.coake@org1.com
Organization2
Mailbox: Primary reply is the external address.
SMTP: Jane.Clayton@company.com
smtp: jane.clayton@org2.com
In MMS, synchronize Custom Recipients to allow resolution and routing across organizations:
Under LDAP, the primary SMTP reply address is accessible as either the mail or the rfc822mailbox attribute. In the following example, the mail attribute is used. You can find the destination address on the
General property page of the Exchange Administrator tool, and is stored in the LDAP field target-address; additional proxy addresses are stored in the multivalued field otherMailbox. Use the following sample as a guideline when you are creating Custom Recipients in the target organizations:
Organization1
Custom Recipient: Target address is the routing address and the external address is preserved in the proxy addresses.
target-address = smtp:jane.clayton@org2.com
otherMailbox = SMTP:Jane.Clayton@company.com
Organization2
Custom Recipient: Target address is the routing address and the external address is preserved in the proxy addresses.
target-address = smtp:john.coake@org1.com
otherMailbox = SMTP:John.Coake@company.com
E-mail messages that are sent to one of these InterOrg Custom Recipients will route correctly using the old address, such as John.Fortune@org1.com. When the message arrives, it contains the company-approved reply address of John.Fortune@company.com. Both internal e-mail users and recipients outside the company network see the same corporate-approved e-mail address.
The first action to take is to change the Metaverse Add Parsing Template to import otherMailbox as a multivalued field rather than as a multilined field. Add the following changes to the template:
-otherMailbox: $i_read_attribute("$v_zvalue","multivalued:attribute:$cd.otherMailbox")
After this change, otherMailbox will import as a multivalued field. For example:
smtp$john.coake@org1.com
MS$postoffice/network/johncoake
When you write out the new otherMailbox field, use the dollar sign ($) to separate the address type and value designations. This creates a problem because in the template language, the $ character is used to signify that the characters that follow are a function or variable, and you cannot enclose the $ character in quotes to work around this problem.
For example, in the following Advanced Attribute Flow script, the intent is to evaluate to smtp$John.Fortune@company.com, which will not work, nor will any other literal use of the $ character.
$mv.othermailbox="smtp$"$cd.mail
To accomplish this, functions must be used instead of literals. The following code is an example of the use of functions in the Advanced Attribute Flow script:
# check for a proxy smtp address
$v_routing=$MULTI_VALUED("smtp",$cd.othermailbox)
IF $EXIST($v_routing)=T
THEN
# save the 'smtp$' from the original otherMailbox attribute
$v_prefix=$TRIM("$v_routing",5)
# merge the prefix and old mail attribute into the multivalued field<BR/>
$mv.othermailbox+=$v_prefix$cd.mail
# get the substring of the original othermailbox attribute without the prefix
$mv.mail=$GET_SUBSTRING("$v_routing","$v_prefix","")
ELSE
# we don?t want to trigger the $NULL unless there?s a change as this will force a change
IF $mv.mail=$cd.mail
THEN
ELSE
$mv.mail=$cd.mail
$mv.othermailbox=$NULL
ENDIF
ENDIF
In addition, the LDAP Exchange Foreign Entry templates are not set to export the otherMailbox attribute. The attribute is imported by default, but it is not exported by default; therefore, exporting the attribute must be configured manually.
In the following location in MMS
Design MA/Connected Directory Foreign Entries/Foreign Entries Output Templates
on the
Add and
Modify tabs, insert the following line:
($MULTI_VALUED("0",$otherMailbox,"-otherMailbox: "))
When the Foreign Entries process runs it sends out the swapped proxy address in addition to the target address.
Note: In the default configuration of the Exchange LDAP MA, the SMTP address of the user is used to build the Distinguished Name of the custom recipient. By using this procedure, the the SMTP address for the custom recipient is modified.
In deployments in which you do not modify the construction of the custom recipient Distinguished Names from the default, the duplication of previously-existing Custom Recipients as a new Distinguished Name is created based on the new SMTP address and each new Distinguished Name is then assumed to reference a new user.
Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific requirements.