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.
static void Main(string[] args){ List<System.Uri> urls = new List<System.Uri>(); urls.Add(new System.Uri(“http://mysite_webapplication”)); urls.Add(new System.Uri(“http://portal_webapplication”)); for (int i = 0; i < urls.Count; i++) { SPWebApplication webApp = SPWebApplication.Lookup(urls[i]); foreach (SPJobDefinition job in webApp.JobDefinitions) { // “profsynch” = Profile Syncronisation // “sweepsync” = Quick Profile Syncronisation if (job.Name == “profsynch”) { SPMinuteSchedule schedule = new SPMinuteSchedule(); schedule.BeginSecond = 0; schedule.EndSecond = 59; schedule.Interval = 1; job.Schedule = schedule; job.Update(); Console.WriteLine(“Temporarily Updated Profile Sync for Web Application {0}”, webApp.Name); } } } Console.ReadLine();}
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.
