Emails of AD group members are not imported from AD

[Georgi]

Scenario:
Membership to a WSS Site is done through AD Groups (ex. Domain\Domain Users,
Domain\IT etc.).
Situation:
If an user visits the site, WSS checks the permissions and adds the user to
site users collection. (Site Users collection is visible under Site Settings,
last menu item "View information about site users"). Display Name and User
Name are imported correctly from AD, but E-mail Address not.
Effects: Users must enter their E-mail Address for every site collection
they have access to, which is annoying and can cause mistakes. Until then
they cannot make subscriptions to the site lists and also another users
cannot send them E-mails direct from WSS site.

Is it a bug in WSS or is so 'by design' ?
How can I fix it ?

[Asif Rehmani]

Georgi,

One thing it seems that you already realize is that a Display Name, and
Email for a user is kept at the site collection level. Meaning,
SharePoint's database keeps these fields once the user is added and
they are NOT synchronized with AD.

Second thing to note: In AD, a user object contains email in two
different places: "User Logon Name" and "Email Address" (you can see
both of these fields by opening up a user's property page in AD). Both
of these fields can be entirely different. The "Email Address" field
is optional and doesn't have to be filled. However, the "Email
Address" is the one that's pulled in when a user is entered in WSS so
if it's empty, nothing is pulled into WSS.

Please check to see if this is the issue here.

_______________________________
Asif Rehmani, MCSD.NET
Trainer / Solution Architect
SharePoint Solutions | Chicago Office
Mobile: 312-953-8475
as...@sharepointsolutions.com
SharePoint Training: www.sharepointsolutions.com/chicago
SharePoint 2007 Videos: www.rehmaniconsulting.com

[Georgi]

Thank you Asif,
both notes are known to me and they are not the reason for the problem ( by
the way all our domain users have email address).
Note: If I add a user directly to a site collection in format
domain\username, then SharePoint retrieves and proposes me his/her email from
AD. The only problem is with users, which have access to a site through
domain groups: their email is not imported.
I didn't find any KB which reports such behavior, and I don't know if this
problem is common or it is in "our house" only. In second case what can I do
to solve the problem?

[Asif Rehmani]

I'll take another shot at this.

There are two types of groups defined in AD. The first one is of type
"Security" and the second one is of type "Distribution List". Only
Security type of groups should be added to the sites and should have
all relevant info for the users contained within.

Please check to see if that could be causing the problem.

[Georgi]

I know about Security and Distribution groups, the groups I am spoking about
are global security groups, like Domain Users. I have the same behavior with
missing e-mail addresses on my development machine, on test server and on
production server also.
Can you test, please, in your environment:
1. Create a new site collection.
2. Add YourDomain\Domain Users as a member of newly created site.
3. Open the site under another login (not yours or of site owner).
4. Go to Site Settings/View information about site users.
5. Check if the user has -email address.

Thanks in advance,
Georgi Varbanov

[jms...@gmail.com]

Georgi,
Did you ever find a solution to your problem? We're having the exact
same problem. We're toying with the idea of fixing it manually and
then writing a SQL trigger to fix the problem going forward. I know
this makes our system non-support by Microsoft, but we don't really
expect support from Microsoft anyway...

Thanks for any updates,
Joe

[Georgi]

Hello Joe,
I didn't find any solution, so I had to write my own:
//----------------------------------------------------------
using System;
using System.Text;

using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint.Utilities;

namespace Georgi.SharePoint.Tools.AddMissingEmails {
class Program {
static string _serverUrl;
static void Main(string[] args) {

string appName = AppDomain.CurrentDomain.FriendlyName;

if (args.Length > 0) {
if (string.Compare(args[0], "-all", true) == 0) {
ScanAllServers();
}
else {
Uri serverUri = new Uri(args[0]);
SPGlobalAdmin globalAdmin = new SPGlobalAdmin();
SPVirtualServer virtualServer =
globalAdmin.OpenVirtualServer(serverUri);
ScanAllSites(virtualServer);
}
}
else {
SPGlobalAdmin globalAdmin = new SPGlobalAdmin();
Console.WriteLine(@"
Syntax:
{0} -all | <serverurl>

Example:
{0} -all", appName);

foreach (SPVirtualServer vServer in globalAdmin.VirtualServers) {
if (vServer.State == SPVirtualServerState.Ready) {
Console.WriteLine(@" {0} {1}", appName, vServer.Url);
}
}
}
}

private static void ScanAllServers() {
SPGlobalAdmin globalAdmin = new SPGlobalAdmin();
foreach (SPVirtualServer vServer in globalAdmin.VirtualServers) {
if (vServer.State == SPVirtualServerState.Ready) {
ScanAllSites(vServer);
}
}
}

private static void ScanAllSites(SPVirtualServer virtualServer) {
SPSiteCollection siteCollections = virtualServer.Sites;

for (int iSi = 0; iSi < siteCollections.Count; iSi++) {
using (SPSite si = siteCollections[iSi]) {
si.CatchAccessDeniedException = false;
SPWebCollection sites = si.AllWebs;
try {
for (int iSites = 0; iSites < sites.Count; iSites++) {
using (SPWeb site = sites[iSites]) {
AddUserEmails(site);
}
}
}
catch (Exception ex) {
Console.WriteLine("{0}\t{1}", si.Url, ex.Message);
}
}
}
}

private static void AddUserEmails(SPWeb site) {
string displayName;
string email;

foreach (SPUser user in site.AllUsers) {
if ((user.Email == null) || (user.Email.Length == 0)) {
try {
SPUtility.GetNTFullNameandEmailfromLogin(site, user.LoginName,
out displayName, out email);
}
catch {
displayName = string.Empty;
email = string.Empty;
}
if (email.Length > 0) {
user.Email = email;
user.Update();
Console.WriteLine("{0}\t{1}\t{2}\t{3}", site.Url,
user.LoginName, user.Name, email);
}
}
}
}
}
}
//----------------------------------------------------------

It is a console application, which should run on Front-End SharePoint Server
under an account with administrative privilegies. You can schedule it to run
regularly using Scheduled Tasks in Control Panel or schtasks.exe from command
line.

Meantime I had verbal confirmation for this problem by one of Microsoft
partners. He confirmed that he has another customers that have the same
problem.