User Profiles: Why do my changes not show in other sites?
A detailed look at how the Sync works
I was asked recently to advise on how to configure a MOSS 2007 installation to allow end users to update their display name as they had previously been able to do in 2003. My initial thoughts on this were that its a simple update of the profile properties to allow them to edit the Name field, however the results achieved in testing appeared inconsistent.
In this article I will show
- How to setup the profile properties
- What the user sees and can edit
- What services/timer jobs are involved in the Sync and how to speed this up for testing
- The conditions that need to be met to trigger the profile information to be replicated.
Setting Up Profile Properties
The first step is to setup the profile properties. In this example I will be looking at enabling users to edit the display name (”PreferredName”) field. This example assumes that you have MOSS 2007 and a Shared Service Provider has been setup and configured.
From Central Admin choose the Shared Service Provider from the left hand menu. This should display a screen similar to the one below.
Select the User profiles and properties option as highlighted. This will allow you to add new properties or as in this example edit an existing property.
Scroll to the bottom of the page and click View profile properties. On the list of properties select the Name field and choose Edit.
The profile properties page allows you to configure the profile property. Ensure that the field selected is the PreferredName field, this has default Display Name of Name.
Check that the field is checked for replication. You will note that the text suggests that properties that can be replicated cannot be edited by the user, however this does not appear to be the case.
Choose Allow users to edit values for this property, this will allow the user to change the value via MySite.
Change the mapping to ‘not mapped’. If you do not change this any modification the user makes will be overwritten at the next profile import.
Note: When a user firsts accesses a site the User Info is extracted directly from AD (or your provider, not tested) and it still pulls the AD based display name into this field as it is not related to the profile mapping.
We will look at the different states for the User Info and profile imports below.
The properties page should show the PreferredName field is no longer mapped.
That is all of the changes required to make the display name editable by the user.
What The User Sees and Can Edit
When the user navigates to a SharePoint site the initial view will show the information contained in AD (I assume this is the same for other providers but you will need to test) including the display name.
AD user with defined Display Name, this will be used initially when the user accesses a SharePoint site as shown below.
To edit the display name navigate to your My Site, this will initially look like the image below, notice that the Welcome message is not based on the display name from AD but the users account name. In this example I have blurred the domain name.
Click on the Details option under the My Profile Quick Launch and edit the Name field.
In order to test this I have used a time stamp so I could repeat the tests and identify what had changed.
Clicking on Save will take you back to the My Site home page and will show some of the fields have updated but others have not. The fields that have not updated are based on the User Info table and is updated by the Quick Profile Synchronization timer job (see below).
The Quick Profile Synchronization timer job is scheduled too run regularly (minutes) but I have found in testing, and this will increase as your number of users and sites increase, it can take a while for the changes to take place. You can force this timer job by running the STSADM operation SYNC.
stsadm -o sync
Note: this starts the job, the changes will not appear instantly.
After the sync has been performed the User Info table will be updated with the values from the My Profile details.
Why do some Team Sites not update with my details
The main reason for confusion around the updating (sync’ing) of My Profile details into team sites is that it is now based on if the user is Active. As part of the upgrade to V3 Microsoft introduced the idea of users being active in a site rather than just having access.
When you first visit a site a record is recorded in the UserInfo table of the sites Content Database. The field tp_IsActive is defaulted to false, which means you have visited but have not interacted with the site.
The Sync process uses this value to determine if the user info should be replicated from the My Profile details as edited above.
Following on from the example above you should be able to refresh your team site that you had only visited and see the user name is still the same, it was not updated when the My Site was updated.
If you now interact with the site, either add a document or edit a link, in effect become an active user of the site, and then run the stsadm -o sync command as above the My Profile changes to the user name will be replicated to the site.
Sync Timer Jobs and STSADM
The synchronisation of the profile properties and information are based on two timer jobs, and one stsadm command (as used above). These jobs are per web application so you may see multiple of these configured in your environment. Access to these is via Centra Admin -> Operations.
These timer jobs are part of the Microsoft.Office.Server.UserProfiles namespace and specifically
WSSProfileSynch
Handles the synchronization of user profile data in the Windows SharePoint Services user information list on each site, and the synchronization of Windows SharePoint Services members group membership in the user profile memberships. This class is not intended to be used directly from your code; use stsadm.exe instead.
WSSSweepSynch
Handles the incremental synchronization of user profile data in the Windows SharePoint Services user information list on each site. This class is not intended to be used directly from your code; use stsadm.exe instead.
I have yet to determine exactly which of these processes are triggered using the stsadm -o sync command.
Additional Information
Profile Synchronisation on MSDN
Sahil Malik has a good post on the high level information flow within MOSS here.
I have also included below some sample code that I used to try and speed up the timer jobs. You may want to use these to help understand what each timer job does. Note, changing the Profile Synchronization schedule will not remain, another time job appears to reset this to the installed defaults.
Error and Omissions
Warning: Access to the database directly is not supported, I performed this in my test environment to understand why things worked the way they did.
Using a famous Todd Bleeker line from TechEd Orlando - I reserve the right to be wrong! This is what I have found so far, but my knowledge and understanding of this may change over time.
So it seems that in situations where users are only Readers at the root site but have Contributor or greater access further down, they will never be considered active at the root. Their UserInfo can end up being different there than in their active sites where the Profile sync updates it regularly. Is there a way to flag a user as active without raising their permissions or resorting to database manipulation?
There is no way that I have found to update the Active status of the user without ‘making them active’ or as you say using an unsupported database update.
Hi Andrew. Firstly I’d like to thank you, great Post.
We are having a situation where a user got married (Changed surname) so account changed
from “domain\oldlastnameA”
to “domain\newlastnameA”
This user now logs on succesfully but the prefered name in the User Information List is still “lastname, oldlastname”. Why has the prefered name not been updated? Is there a bug or something I can check?
Thanks again
You need to use the command
stsadm -o migrateuser
-oldlogin [domain\name]
-newlogin [domain\name]
[-ignoresidhistory]
See technet article for more info.
I have the same problem as described above, however the domain name remained the same (we use a combination of letters and numbers) only the email address has been changed. The user information list shows the new email address, but the SIP address has not updated. When we add the user to a new site they weren’t a member of, the correct, new information is shown, it only seems to be sites they were already a member of. We’ve tried removing them from th esite and adding them back in, but that doesn’t work…. Does the above command still apply? How would we use it?
Great Post!
The problem I am having is that the information in active directory is not current and when an user changes his/her information under my site settings like telpehoneNumber the information is been updated in active directory. We got configure the Profile Import to run x time on the morning but the information is not been updated. Should I need to run the stsadm synch tool?
Once again thanks for this great post.
Sync is one way it takes information from AD and populates SharePoint, you really need to look at a solution for getting the AD information correct or reducing the information you sync where it is know to be incorrect in AD.
great post. Since you’ve looked at ssp and profile properties more than most, I’m hoping you’ll entertain my question.
I’m having trouble getting my ssp profile to reflect at the site level for seemingly active users. These are profile settings which should be replicating according to the ssp. It did work perfectly well for a day, which upsets me farther.
I did find a 3rd party sync tool on codeplex, which isn’t the most efficient, but it does get the job done–however it only works on old profiles, created before the ‘break’. Have you ever heard of any of this? it’s madness. both my ssp’s have the same issue, and there is no connectivity problem updating the ssp from the applications below it. No errors anywhere I’ve seen, sync jobs say they’re working fine.