How to Update Inactive User Profile Information in SharePoint

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

  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.


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)


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:


Comments (9)

  1. Kunal Kankariya says:

    How does a user become inactive? Is ther number of days or any other parameter which defines that?



  2. 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:…/dd358164(v=PROT.13).aspx

  3. Set DirtyFlag says:

    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….

  4. 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.

  5. In my case, the display name is not the issue I am trying to solve. We have cases where the user info table has the wrong Account name for the user. The rest of the user information does appear to be right, at least in the cases I have checked. In our situation, a user's account contains a domainlogin where the login has a user's initials and department number. When a name changes, or a person changes departments, the login changes, but it appears that the user info table is not updated.

    The account field is not an editable field in the site collection (or is it site?) > People and Groups > User Information sharepoint item details page (userdisp.aspx). In fact, when I try to edit something on this page (as a sharepoint admin), all I get is a read only single property, and buttons to delete the user or attach a file.

    I have not chosen to select the delete user from site collection because I have not found formal tech references that explains the consequences of that action – would the user in question lose all the permissions granted as well as ownership of all list items and library items?

    I am looking for others who have encountered this and who have found a solution.

    I have tried the suggestion of the stsadm -o sync -ignoreisactive 1 , and I am awaiting the next execution of the timer job to see if that helps in resolving things.

    Do I have to reset that flag after the timer job runs?

    Thank you!

  6. 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?

  7. Craig says:


    I am trying to use this script and within our environment we have numerous Web Apps. When I try to select many of them, it returns the following error…

    "Selection Invalid. Please Try Again"

    On four of the Web Apps, it tells me that the Web Application has been verified and lets me move on to updating the user…

    Any ideas? Thank you in advance!

  8. Christopher Buchholz says:

    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!

  9. Stephan Bren says:

    Excellent article.  Remains applicable to SharePoint Server 2013.

Skip to main content