Today, at a customer site, I addressed a problem that annoyed users more than usual. It seems that they can't sign up for alerts or assign each other tasks, and they get an error screen that offers to fix the problem, but leads to a dead end. I evaluated it, and created this write-up:
Among the many pieces of information collected and presented by SharePoint, some of this information comes directly out of Active Directory. AD was always intended to be a directory first, a central repository for information about users, phone numbers, email, etc. I’ve seen phone systems that tap directly into AD, for example. But most places I’ve been, AD is simply treated as a place to store user accounts, and much of the information on each account is left blank.
SharePoint’s strength (or weakness, if you’re a cynic) is that is depends on AD for certain pieces of information. MOSS periodically queries AD and updates all user profiles with this information, such as who works for whom, phone numbers, department information, and email addresses.
Problem:It’s this last piece of information that, when missing, breaks some functionality in SharePoint. In order for people to be able to sign up for alerts (e.g. to be notified when a document is changed, an item is added to a list, or status changes on a task), or be assigned tasks, or a multitude of other collaborative processes, the email address field must be populated in AD. Otherwise, they get an error like this:
And if they click the friendly link to set their email address, they get this (sorry for all the redaction):
…which is to say, a completely useless page where they can’t change anything.
Snickering about Microsoft aside, this is an intentional design. SharePoint is supposed to pull this property from the user’s AD account, and even if I set the field to allow users to edit their email, it would be overwritten by default every time the AD query was run.
Sharepoint has extensive property mapping, and the “Work E-mail” field is mapped to the AD “mail” property, which is editable on the “General” tab of the user’s AD account:
You can see that even though I can bring up my non-administrator account, I can't edit most of the properties. It has to be done by someone with elevated permissions.
There are a lot of other pieces of information that SharePoint can use that are typically left blank, as well:
The Organization tab is used to bring a neat feature into SharePoint: it will use this information to create a mini-org chart on each user’s profile, so you can see a user’s supervisor(s) and peers at a glance.
So at this site, where there are a large number of users and administrators typically didn't bother to fill out the complete properties when creating users, the result is that SharePoint becomes less useful--or even broken. The organization recently installed an Exchange server, but it was incorrectly implemented. I believe the reason no one’s email address is current in their AD profile is a problem with the MS Exchange implementation at this company. When Exchange is installed, it adds numerous properties to a user’s profile, and I pretty am sure that this email field on the General tab is automatically populated when the user is assigned a mailbox.
Since this company isn’t set up with a typical configuration, this property has to be populated manually by an administrator. I proposed three possible solutions:
Undertake a project to do a mass-population from a CSV file, using CSVDE or a similar scripting tool.
Actually the company had been looking at a tool that would do this for them, but had not gotten a budget together.
Unmap the email field so that it is not refreshed whenever there is a profile import task performed by SharePoint (schedule is run once daily). Also, set SharePoint permissions to allow users to edit this field.
Problem: this will require a great deal of administrative overhead because email addresses are subject to change, and users may not be inclined to edit their own information, which will lead to an inconsistent user experience.
Allow users to submit a request for helpdesk to update their active directory profile information.
In the end, we chose option #3. Using InfoPath 2007, I created a simple web-based form to allow users to enter all the information (per the screenshots noted above) and submit it via (plain text) email to the helpdesk mailbox. I believe this is the most straightforward approach and it helps the IT staff because they won’t have to track down lots of contact and HR information. Since not everyone is using InfoPath 2007, I published the form to the MOSS site to be rendered as a web form, and specified that the form submitted via email not use an attachment; it was a static HTML table.
By and large, this took care of the problem. The MOSS site currently has light usage, so the volume of user requests for IT to update their profiles would also be light. When IT gets around to purchasing their AD-automation tool, this form method can be retired.
Once again InfoPath saves the day! I think I will write more about it in an upcoming post.
