I actually wrote this while I was in Malawi, forgot to post it until now though:

Earlier in my trip, while I was setting up Windows Sharepoint Services v3 for the folks at Tidziwe, I came across a problem that’s surprisingly common in the Sharepoint world.  They wanted an employee directory on their intranet homepage.  They also wanted department directories, with additional information in them on each of the department sites.  In my mind, the perfect situation would be pulling this information from Active Directory.  That way, the administrative effort is minimized, and there aren’t additional tasks that have to be done for each new user.

Unfortunately, the standard “People and Groups” list doesn’t work too well in this scenario because WSS only pulls the Active Directory attributes in once.  If changes are made in the future to the Active Directory object, those changes won’t be reflected in Sharepoint.  Also, instead of adding the AD user accounts directly in to the Sharepoint groups, I’m using existing AD groups as an intermediary.  (Again, this should cut down on the extra administrative work that has to be done to give a user access - once they are added to the department group in AD, they should have access to Sharepoint, any file shares, etc.)  The People and Groups list does not work at all in this case - it just shows the AD group that’s been added, and not the individual users.  It’s kind of disappointing that Microsoft releases products that integrate so poorly with Active Directory.

So, realizing that an out-of-the-box solution was not going to work here I started to look at custom webparts, and other means with which I could achieve what I wanted.  It appears that there are several expensive 3rd party webparts out there that try to fill this functionality gap.  Still, I felt I could solve this quicker (and cheaper) on my own, so eventually I realized how I can do this.

Our department directories don’t necessarily have to be pulled from the Sharepoint groups, instead I felt that filtering the users based on the “Department” attribute in AD would be sufficient here.  I realized that using DataViews in Sharepoint Designer can pull in data from a variety of sources, I eventually realized I could use a web service to pull the data from Active Directory and pass it in to the DataView.

I created a web service in ASP.NET that returns the user information (first/last name, department, email, phone, etc) from Active Directory.  The web service has a couple methods, one returns all the Active Directory users, the other only returns the users from a particular department.

On the main employee directory, I have a DataView WebPart that uses the web service as its data source.  It lists information for all users.  I have it grouping the employees by their department to make it easy to find.  Each department site also has a department directory for added convenience.  These ones use the second method that just returns the employee information for a particular department.  They both have clickable mailto: links for the email addresses.

Employee Directory Screenshot

Altogether this seems to work pretty well, it does what it’s supposed to.  There might be some performance issues in larger environments with more hits and more users since it doesn’t currently do any caching.  That shouldn’t be too hard to add if needed however.

If any one is interested in this, send leave me a comment or send me an email. What we’re using can filter the Active Directory users based on the Department attribute, though I tested using groups to do the filtering as well.