Unfortunately you are running into one of the more confusing areas of the
SP <-> AD connection. Distribution Lists (DL) can't be committed to the users
table for some particular reasons which include, but are not limited to, DLs not
having the proper security tokens.
Sending Alerts to a DL is a common request, but SP wants to enumerate the
security permissions of each User in a group in order to determine the User's
eligibility for access to the site that the Alert is coming from. DLs don't have
the security token required.
A common suggestion to mail-enable Security groups (SecGroup) is invalid in my
domain for security reasons; if emails were to go external, once you have the
name of a security account, you could potentially hack with it. That's what I am
told and it is gospel around here, DAGUMMIT!
My only problem with the limitation of disallowing DLs to be returned in the
People Editor control - for which it is perfectly capable, let me tell you - is
that I wanted to be able to write an SPDesigner workflow that takes a DL out of
a People and Groups column on a custom list and sends it an email.
I understand the security context when it comes to SP and the People Editor
control. In almost all of the places in SP that the control is used it is in a
security context: adding users (User) to SharePoint Groups (SPGroup), alerts on
lists, permissions for lists, etc. In my case I wasn't looking for a security
context, I just wanted the DL email address to dynamically choose groups for an
SPD workflow email. (It's an Infrastructure Change Control application; I need
to dynamically pick which groups get emails for various changes in our
environment.)
I finally figured this out, though it's a jQuery hack and not pretty. I built a
custom web part that is only the SP People Editor control. I set the
SelectionSet property to allow only two (User, DL) of the four (User, SecGroup,
SPGroup, and DL) enumerated types I described in parenthesis above. In all other
contexts in SP 'DL' is simply not set in the SelectionSet property. I added the
web part to the NewForm.aspx and EditForm.aspx pages. Using jQuery I hide it by
default and pop it up in a modal dialog box when the button I added (with
jQuery!) to the form is selected. The person is then able to return DLs as well
as Users (remember I am only trying to get email addresses; the other two don't
return entries with email addresses.) After they have what they want in the
modal dialog popup they click the Add button and it checks for each <div> tag
that contains the AD account (DOMAIN/user) of each returned User and DL,
separated by semicolons (;). When I later look up that field in my SPD workflow
I am able to add it to the email address portion of the 'Send an Email' action.
My Exchange server can then send to "DOMAIN/user" as an email address.
It's ugly and hacky. I don't like it and my (still) open service call with
Microsoft doesn't sound like it is going to return me anything I can use. Their
code monkeys are working on something that sounds like it's going to be as hacky
as my current solution.
Good luck and sorry for my extra long email! It helps to be able to share this
information with others as it solidifies my own understanding of the solution I
eventually built (O;
If I were to rebuild this in Visual Studio it would be a lot less hacky. I could
just flatten a DL and get the users out of it to send email.