This post is going to discuss user profile synchronization, and how to update user profile information for users determined not to be active in SharePoint Server 2010. First we'll discuss what happens during the various phases of user profile synchronization, at a high level, and how SharePoint determines whether or not a user is active.
I was recently working with a customer on one of their internal helpdesk issues. A user had recently had a life event, which resulted in their last name being changed. When logging into a particular site collection, their user information (welcome user name) continued to display their previous last name. All other site collections showed their current last name. The customer had taken typical troubleshooting steps prior to my engagement. This included performing a user profile import, ensuring that the user profile information in the user profile service application was up to date, running the stsadm –o sync operation. All to no avail.
To understand why this was happening, we had to take a look at what was "supposed" to happen. Synchronizing user profile information in SharePoint Server 2010 is really a multi-step process. I'm going to break it down into two large processes – each of those processes could be broken down further, and of course many existing blogs do just that. Much of the information can be found in Spencer Harbar's blog. He actually has an entire category dedicated to user profiles
The first major step involved with having fully up-to-date user profile data across all site collections is to ensure that your user profile service application contains the most up-to-date information. In order for this to happen, your user profile service application must have the necessary synchronization connections. Once synchronization connections have been properly configured, a profile import must occur. Assuming all is configured properly and is functioning properly, performing a full import will ensure that the information in your user profile service application is the latest and greatest. If you're not really sure where to start, this is a great starting point:Configure profile synchronization (SharePoint Server 2010)
The second major step involved is synchronizing information from the user profile service application to SharePoint. There are two timer jobs responsible for this
When a user first accesses a site, a copy of some user information is copied to the site collection. To be more specific, it's copied into the UserInfo table in the content database in which the site collection exists. This helps speed up certain aspects of working with SharePoint sites, such as accessing list views. Since these timer jobs are responsible for keeping that information up to date, we need to make sure these timer jobs continue to run.
The thing that's a little obscure to many people, myself included at the time, is that these timer jobs are only responsible for updating user information for "active users". So – what exactly is an active user? Basically, an active user is any user who has modified any data within the scope of a site collection. The information is a little dated – but to the best of my knowledge it remains unchanged up to and including SharePoint Server 2010. I haven't yet investigated how this all works in SharePoint Server 2013 Preview, so I can't comment on that yet. The documentation that I'm referring to is the following, and you won't have to read too far to identify what an active user is: [MS-WSSFO3]: Windows SharePoint Services (WSS): File Operations Database Communications Version 3 Protocol Specification. As I said, the protocol documentation appears to reference WSS 3.0, however this does not appear to have changed in SharePoint Server 2010.
So – Now that we know what's happening, what do we do to resolve this issue? I'll discuss what I did first, and then I'll discuss a method that would have saved me a couple hours of work (if I knew then what I know now). If you've been following my blog this year, you may have guessed – I decided to write a PowerShell script. The meat of the script is really not complicated.
First we're going to use Get-SPUser to return the user object we're targeting. That's pretty simple.
As you can see, the display name isn't what I want it to be. Luckily DisplayName is a property which can be set using PowerShell. I can manually set this property by calling the object and setting the DisplayName property, as shown below.
Now when that user, or any user logs into the targeted site, the display name will reflect the value I had set manually.
Of course, scripting that didn't take me "hours", creating functions, performing error handling, etc. is what took me hours.
Now let's get back to what could have saved me hours of work. Apparently the SharePoint product group was aware that people would still want to update user information for accounts which are not "active" in the site. It's included with stsadm –o sync, it's just not documented very thoroughly (yes, that is a SharePoint 2007 lync, stsadm is deprecated in SharePoint Server 2010. There is no PowerShell equivalent to the sync operation, according to Stsadm to Windows PowerShell mapping (SharePoint Server 2010)). You will however find documentation about this hidden gem in this article: Troubleshooting User Profile Sync issues in Microsoft Office SharePoint Server 2007.
To save you even more reading, and to make a long story short – this all could have been avoided by simply running the following command:stsadm –o sync –ignoreisactive 1
Download UpdateUserDisplayNames.ps1 (zipped)
In the script, there is a constant. This would require you to put in your NetBIOS domain name. Asides from this constant, no further configuration is required. Simply make this edit, and run the script from a SharePoint server.
As always, if you have any questions or feedback, let me know. If you have any ideas to optimize the script, I'd like to hear that too. Thanks for reading!
You can also follow me on Twitter: