SharePoint, OOTB, provides some very nice Active Directory integration in terms of acquiring a user’s sign in, display name (usually “Last, First”), and email address. While this is all fine and good in a very standard environment, some organisations just don’t have the ideal set up for SharePoint’s integration. What if your user information isn’t all in AD? What if it’s in a 3rd party LDAP solution… or something like PeopleSoft or other HR tools? Well, then you have an issue.
This issue recently came up and caused me to do some investigation. What I found wasn’t documented in the sources I checked, so I’m posting it (1) for my own reference in the future and (2) as a service to those who may come across the same missing knowledge.
WSS sites (including those within the sites collection of a portal) have something called a User Information list that keeps a limited amount of info about it’s users (sign in name, email, display name). When a user is granted access to a site, their info is put in a User Information list. When a user creates/edits an item in a list SharePoint creates a link to the user’s record in the User Information list so when the user is shown in “Created By” and “Modified By” indicators, the Display Name from the User Information list is shown
User Info
SharePoint Portal Server has something called a Profile Database. When you first visit a portal, SPS checks to see if it has a profile for you and if not, it creates one on the fly with your info from AD. You can also configure SPS to automatically populate the Profile Database with a full import, an incremental update, and optionally set it to pull objects with a custom LDAP query. Some downsides to the incremental approach is that objects no longer in AD are not removed from the Profile Database. Profile information is displayed on a user’s My Site and all alerts within the portal use the email address stored in the profile. But what about the “Created By” and “Modified By” indicators in lists? Let me digress for a second…
SharePoint Portal Server requires Windows SharePoint Services. Why? Because SPS is based off WSS. So much so, that the root of a portal is effectively the root of a special WSS site collection. Each area & subarea within the portal is another WSS site (makes sense why you can inherit the parent’s or have unique permissions in areas just like WSS site collections). In addition, the entire portal also has it’s own User Information list. “But the email is being pulled from the portal’s profile database… why does it need a User Information list?” For the “Created By” and “Modified By” indicators! When you edit an item, it’s pulled from the User Information list.
What does this mean? Let’s take the case of Jane Smith ([email protected]). When she’s granted access to a WSS site, she has a record created with that info in the site’s User Information list. When she hits a portal for the first time, a record is created in the portal’s profile database and portal’s User Information list. Now, let’s say she changes her name after marrying John Doe… we now have Jane Doe ([email protected]).
In the WSS site, all you’d have to do is go update her info in the User Information list and all “Created By” & “Modified By” indicators will be updated, and all alerts will be sent to the new email.
In a SPS portal, you update her info in the profile database. However, this only updates her alerts and her information on her My Site. You’d ALSO have to go into the portal’s User Information list and update her Display Name to update the indicators.
Don’t forget, as I mentioned above, the sites in the sites directory within a portal are not related to the portal in this context… they are treated as atomic site collections with their own User Information lists.
Now, why the profile database changes don’t propagate down to the portal’s User Information list I don’t know… I think it should, but it doesn’t, so it’s just something we have to address.