Force SMTP CreateRecipient() in Exchange environment

[Dick Watson]

I have a number of existing distribution lists that have lots of
resolved/resolvable Exchange display names/addresses.

The problem is we are reorganizing and all these users are moving Real Soon
Now to a new address. To ease the transition, I want to start sending emails
to their new addresses via SMTP for now until we swing over to the new
Exchange. (Some users are on the new Exchange and most are still on the old,
but SMTP inbound to the new Exchange environment is being forwarded to them
in the old. Fixing the dist lists one entry at a time as users swing is just
ugly. Better to convert everybody to the new addresses for now while the new
environment is being fleshed out.) So I want to copy the DistListItem
Recipients to a new DistListItem using code to CreateRecipient the new
Members using the current display name and a new SMTP address.

This seemed easy enough, but:

CreateRecipient(myRecipientWas.Name) just immediately resolves to the
current Exchange user. Once resolved, there doesn't seem to be any way to
coerce it to use the same "display name" but an SMTP address instead.

So, how can I add members to a DistListItem and CONTROL the address type and
address used for any given display name--even if it may be an Exchange-known
display name?

IIRC (not in the Exchange environment to re-visit this at the moment)
CreateRecipient(strRecipientNewSMTPaddress) is also getting resolved to the
current Exchange name (I think the LDAP/Exchange environment has knowledge
of both old and new SMTP addresses). I've tried CreateRecipient() with a
modified display name "User Displayname [new SMTP]" but it doesn't resolve
(of course) but I can find no way to assign an SMTP address/address type to
the unresolved Member entry.

So how can I complete an unresolvable AddressEntry once I've done a
CreateRecipient that couldn't be resolved? Is there any way to add/change an
uresolvable recipient to one that can be resolved (i.e., a valid SMTP
address type)? I can create these entries in the Outlook Contact
Distribution List UI for adding members just fine. I just need to do it
programmatically due to the volume involved.

Surely there's a way to solve one or the other of these problems?

 

[Ken Slovak - [MVP - Outlook]]

Unless Outlook is connected only to the GAL on the new server
CreateRecipient will always use the current EX address to resolve any name
you pass. Setting the recipient explicitly to the new SMTP address without
having a contact or GAL entry to match will create a one-off recipient in
the DL that won't end up matching later to the new EX settings.

I think you might have to wait for the roll-out to do what you want with the
DL's.

I have a number of existing distribution lists that have lots of
resolved/resolvable Exchange display names/addresses.

The problem is we are reorganizing and all these users are moving Real
Soon Now to a new address. To ease the transition, I want to start sending
emails to their new addresses via SMTP for now until we swing over to the
new Exchange. (Some users are on the new Exchange and most are still on
the old, but SMTP inbound to the new Exchange environment is being
forwarded to them in the old. Fixing the dist lists one entry at a time as
users swing is just ugly. Better to convert everybody to the new addresses
for now while the new environment is being fleshed out.) So I want to copy
the DistListItem Recipients to a new DistListItem using code to
CreateRecipient the new Members using the current display name and a new
SMTP address.

This seemed easy enough, but:

CreateRecipient(myRecipientWas.Name) just immediately resolves to the
current Exchange user. Once resolved, there doesn't seem to be any way to
coerce it to use the same "display name" but an SMTP address instead.

So, how can I add members to a DistListItem and CONTROL the address type
and address used for any given display name--even if it may be an
Exchange-known display name?

IIRC (not in the Exchange environment to re-visit this at the moment)
CreateRecipient(strRecipientNewSMTPaddress) is also getting resolved to
the current Exchange name (I think the LDAP/Exchange environment has
knowledge of both old and new SMTP addresses). I've tried
CreateRecipient() with a modified display name "User Displayname [new
SMTP]" but it doesn't resolve (of course) but I can find no way to assign
an SMTP address/address type to the unresolved Member entry.

So how can I complete an unresolvable AddressEntry once I've done a
CreateRecipient that couldn't be resolved? Is there any way to add/change
an uresolvable recipient to one that can be resolved (i.e., a valid SMTP
address type)? I can create these entries in the Outlook Contact
Distribution List UI for adding members just fine. I just need to do it
programmatically due to the volume involved.

Surely there's a way to solve one or the other of these problems?

 

[Dick Watson]

Thanks for the post.

The problem with waiting is we have, then, a flock of chicken-and-egg
problems. So I readily accept that this is a two-pass operation, first to
create all the one-off SMTP addesses and then to relink them to the GAL
addresses when the new GAL is available to all.

I did find that I can ALMOST get there using

....CreateRecipient(strDisplayName & "<" & strNewSMTPaddress &">")

(I.e., CreateRecipient("Richard N Watson<[email protected]>"))

The reason I say ALMOST is that I've run into one infuriating behavior in
CreateRecipient.

We have some email addresses with (qualifiers) after the display name that
list external organization (for contractors, etc.). E.g. "Schmoe, Bob
(MiracleTemp Inc.)". For reasons that I haven't figured out, CreateRecipient
swallows up the final parenthesis. E.g.

Set myRecipient = myOlApp.Session.CreateRecipient("Schmoe, Bob (MiracleTemp
Inc.)<[email protected]>")

creates a myRecipient.Name of "Schmoe, Bob (MiracleTemp Inc."

Any thoughts on where the final parenthesis went and how to get it to not
disappear? I've tried embedding a space ") <" using "\)<" and several other
variants. All to No Joy.

 

[Ken Slovak - [MVP - Outlook]]

I'm not sure why that final closing parenthesis is being swallowed up, I've
never run into that myself. I tried that line here in Outlook VBA on Outlook
2003 and got the following result:

"Schmoe, Bob (MiracleTemp Inc.)<[email protected]>"

So no missing closing parenthesis here.

Have you tried constructing that character in the string using Chr(41)?

Another possibility might be to create a dummy email message and using its
Recipients collection using the Add() method to get a recipient object, see
if that works.

 

[Dick Watson]

I haven't gotten back to this until just now. I may try the email path to
creating the Recipient.

I don't have problems getting to the right value for calling
CreateRecipient. (Or it doesn't appear so as I debug it, breakpoint it, and
add debug.prints to it.)

To characterize this, I wrote the following little test:

Sub TestCreateRecipient()

Dim myOlApp As Application, myNameSpace As NameSpace, myFolder As
MAPIFolder
Dim myOlItem As Object, myNewDistListItem As DistListItem,
myRecipientNew As Recipient

Dim x As Long

Dim strNameToTest As String, strSMTPaddress As String

strNameToTest = "Schmoe, Joe (WonderTemps, Inc."
strSMTPaddress = "(e-mail address removed)"

Set myOlApp = CreateObject("Outlook.Application")
Set myNameSpace = myOlApp.GetNamespace("MAPI")
Set myFolder = myNameSpace.GetDefaultFolder(olFolderContacts)

Set myNewDistListItem = myOlApp.CreateItem(olDistributionListItem)
myNewDistListItem.Subject = "test CreateRecipient"

For x = 0 To 255

Set myRecipientNew = myOlApp.Session.CreateRecipient(strNameToTest &
x & Chr(x) & "<" & Replace(strSMTPaddress, "@", x & "@") & ">")

myRecipientNew.Resolve

If myRecipientNew.Name <> strNameToTest & x & Chr(x) Then
Debug.Print "mismatch: name final character chr(" & x & ") Or " & """" &
Chr(x) & """"

myNewDistListItem.AddMember myRecipientNew

Next

' creating a 256 entry list fails here but we can look at the debug…
myNewDistListItem.Save

End Sub

results in

mismatch: name final character chr(0) Or " "
mismatch: name final character chr(9) Or " "
mismatch: name final character chr(32) Or " "
mismatch: name final character chr(34) Or """
mismatch: name final character chr(40) Or "("
mismatch: name final character chr(41) Or ")"
mismatch: name final character chr(60) Or "<"
mismatch: name final character chr(62) Or ">"
mismatch: name final character chr(64) Or "@"
mismatch: name final character chr(91) Or "["
mismatch: name final character chr(93) Or "]"

From which I conclude that the parser for these style recipient names really
doesn't like some characters that look vaguely like they could be email
address delimiters in the final character of the display name…

Sure would love to know where this is documented or how to escape one of
them. I've tried "\)" and it doesn't work. Note that ", (, ), <, >, @, [, and
] can all be entered as the final character of a display name from the
Outlook SMTP Address Email Properties UI. I conclude there must be a way. Off
to play some more…

 

[Dick Watson]

Simplified TC:

Sub TestCreateRecipientV1()

Dim myOlApp As Application, myNameSpace As NameSpace
Dim myOlItem As Object, myRecipient As Recipient

Dim x As Long

Dim strNameToTest As String, strSMTPaddress As String

strNameToTest = "Schmoe, Joe (WonderTemps, Inc."
strSMTPaddress = "(e-mail address removed)"

Set myOlApp = CreateObject("Outlook.Application")
Set myNameSpace = myOlApp.GetNamespace("MAPI")

For x = 0 To 255

Set myRecipient = myOlApp.Session.CreateRecipient(strNameToTest & x
& Chr(x) & "<" & Replace(strSMTPaddress, "@", x & "@") & ">")

myRecipient.Resolve

If myRecipient.Name <> strNameToTest & x & Chr(x) Then Debug.Print
"mismatch: name final character chr(" & x & ") Or " & """" & Chr(x) & """"

Next

End Sub

 

[Ken Slovak - [MVP - Outlook]]

I played with this some more and it's the address resolution that removes
that final closing parenthesis. If the address isn't resolved the string is
left intact, resolving the recipient is removing those end characters.

I'll report this to the Outlook product group, but I think you're going to
have to strip out those parentheses to get the recipients resolved and into
the DL's. If MS considers this a bug that should be fixed it might be fixed
for Outlook 2007, probably not for Outlook 2003 I'd think since it doesn't
involve any security or data loss issues. Even if they do fix it, it could
be a while, so I'd be looking for workarounds that are acceptable to get
your stuff up and running.

 

[Dick Watson]

That's where I got to as well. Thanks for trying the case and passing it on…
I'm betting it's "as designed" even if the design is broken. Been there
before, as, I suspect, so have you…

 

[Ken Slovak - [MVP - Outlook]]

I'll post back here when I hear back from the product group and let you know
what they say.

The bet I won't take

 

[Ken Slovak - [MVP - Outlook]]

Looks like "by design".

 

[Dick Watson]

Imagine my surprise.

Microsoft codes a square wheel and it's always "by design".