Freigeben über

How to Update Inactive User Profile Information in SharePoint

  • Artikel

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.

Background

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.

Approach

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

  1. User Profile to SharePoint Quick Synchronization – this job is responsible for synchronizing user information from the user profile service application to SharePoint users recently added to a site and occurs by default every 5 minutes.
  2. User Profile to SharePoint Full Synchronization – this job is responsible for both synchronizing user information from the user profile service application to SharePoint users and synchronizing site memberships from SharePoint to the user profile service application. This runs every hour by default.

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.

Solution

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 the Script

 Download UpdateUserDisplayNames.ps1 (zipped)

Usage

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.

Feedback

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:

 RCormier_MSFT

Comments

  • Anonymous
    September 26, 2012
    How does a user become inactive? Is ther number of days or any other parameter which defines that? Thanks, Kunal

  • Anonymous
    September 26, 2012
    I get into that just a little ways into the article; however.  An inactive user would effectively be any user which has not updated any content within the scope of a site collection, based on my understanding of the documentation posted here: msdn.microsoft.com/.../dd358164(v=PROT.13).aspx

  • Anonymous
    November 15, 2012
    Adversely, rather than forcing property changes from you, couldn't you force the profile sync to update the inactive profile by setting the DirtyFlag?  In other words, if you could loop through all the webs that contain a given profile, and set the email property, for example, back to itself?   Thus properties would be pulled from the Domain, which should be considered the true source....

  • Anonymous
    November 15, 2012
    That won't actually work if the user account is not active, that's why it's not updating in the first place.  If SharePoint determines that an account is not active (using the method mentioned above), it just skips updating the account altogether, regardless of the state of the profile.  It does this due to the cost of updating accounts which have relatively little visibility (not created by, modified by, etc. peppered throughout the site). What you could do, is just run the following stsadm command: stsadm –o sync –ignoreisactive 1 Then SharePoint won't even check if the profile is for a user that is or isn't "active", it will just overwrite it.

  • Anonymous
    January 25, 2013
    The comment has been removed

  • Anonymous
    January 25, 2013
    Hi Iwvirden, It looks more like you may have a use for Move-SPUser, as opposed to stsadm -o sync, depending on your scenario.  Have you tried using the Move-SPUser PowerShell cmdlet?

  • Anonymous
    January 09, 2014
    The comment has been removed

  • Anonymous
    April 28, 2014
    This is a few months old but I have also found you can force it to sync a single user by adding the user to a security group on the site. I have a group called "User Rename Group" that has permissions "None" on the site collection, and if I add a user to that then it pulls in all the data. That also seemed to fix the user if the login itself changed (sometimes with a namechange they will change the login as well). The only time I have a problem is when they re-use an old login that was deleted some time ago in AD. Then I have to actually delete the old user from the site collection. However that -ignoreisactive flag is what I have been looking for for years!

  • Anonymous
    February 15, 2016
    Excellent article.  Remains applicable to SharePoint Server 2013.