I had a requirement to cleanup the Inactive users in SharePoint 2010, The practice that we follow is – disable the user account on AD and move it to different OU, which means that SharePoint would remove the user profile from the profile store(Central) next day. Also it means that, users will not be able to access SharePoint as the account is disabled on AD which is the Authentication provider of SharePoint.

Internally, SharePoint keeps two stores to keep the User profile details.

  • Central store(SharePoint farm level) – User profile store which gets sync with AD on a daily basis.
  • Local store(Site collection/Database level) – User Information List which gets sync with Central store every 30mins or so.

In general, SharePoint does the cleanup at the Central store level(user profile sync service runs every morning), leaving local store untouched when the accounts are no longer present in the central store.

I seriously doubt, if we would ever remove the User’s Profile from the User information list at the site collection level because  – Local store is from where sharePoint gets profile Info., like Name, etc., If users are removed, SharePoint wil not be able to find the reference to show who has actually uploaded/modified the documents or list item.


However it also means that the disabled User profile would show up in the group and may potentially cause more on License, this needs to be cleaned up, not sure why Microsoft taken this into account.

Excerpt from the technet article:

In 2010 a profile is deleted by a timer job after it is missing from one User Profile Sync.  Unlike 2007 there is no scheduled full sync, so it will be deleted after one incremental sync.  It will be missing from the profile sync if the AD account was deleted or if you have set the profile sync to filter out disabled users.  In my opinion filtering out disabled AD users is the better practice.

As you pointed out the CreatedBy field is tied not to the user profile but to entries in the UserInfo table. This is because the UserInfo table is available in both Foundation 2010 and Server 2010 but profiles are only in Server 2010.  So when the Profile is automatically deleted in Server 2010 it does not delete the entry in the UserInfo table or any metadata stored in list/library items.

As you found deleting the UserInfo table entry also doesn’t change the metadata, but will lead to an error page when you click through the user name stored in the metadata.  If you don’t delete the UserInfo entry then clicking on the metatdata link will take you to a trimmed down UserInfo page since the profile no longer exists.  This is the same as for users whose profile hasn’t been imported or created manually.

The best practice is normally to delete or disable the user in AD and let SharePoint delete the User Profile, but leave the UserInfo table entry.  The user will not be able to logon because they won’t be able to authenticate to AD.  Historical entries in metadata will still exist and when clicked they will show basic information stored in the UserInfo table (because the profile has been deleted).  That means you shouldn’t delete the UserInfo table entry in order to maintain full history on the metadata.

Which means that SharePoint cleans up the User Profile Store but not the UserInfo table. So, how would we achieve this.

Remove-SPUser -Identity "demo.net\karthik" -Web http://demo.net -Confirm:$false

is the  easiest way of cleaning up the UserInfo table. More on Content DB tables.

However, do not try something like this

Get-SPSite “http://demo.net” | Get-SPWeb -Limit All | Remove-SPUser -Identity  “demo.net\karthik”

Remember all the sites(web) shares the same content DB.


What does it do?

  • It works like this, It finds the ‘tp_ID’ from [UserInfo] table and removes all those entries that are associated with this ID on the table [GroupMembership].
  • It marks the column ‘tp_isactive’ = 0 on the UserInfo table which says SharePoint that that user account is no longer valid.

A value specifying whether the principal is marked as deleted. If tp_Deleted is 0, the principal is not deleted. If tp_Deleted is not 0, the principal is marked as deleted, and the value is the User Identifier that was associated with this principal. The deleted state can be used for user information, rather than dropping entries from the table, to preserve list item ownership information. A user or domain group with the tp_Deleted value set to nonzero can be restored by setting the tp_Deleted value to 0 and updating other fields as necessary.

A bit set to 1 if the principal is an active user in the site collection.

C# ‘s way:



  1. UserInfo Table
  2. User Information List
  3. Cleaning up the User Profile Store
  4. MySite Cleanup