March 2009
M T W T F S S
« Feb   Apr »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

23
Mar
09

User cannot be found

User cannot be found.   at Microsoft.SharePoint.SPUserCollection.GetByID(Int32 id)
   at Microsoft.SharePoint.Publishing.CommonUtilities.LookUpUser(SPWeb web, String userLookupValue)
   at Microsoft.SharePoint.Publishing.CommonUtilities.GetUserFieldValue(SPListItem item, Guid fieldId)
   at Microsoft.SharePoint.Publishing.PublishingPage.get_Contact()
   at Microsoft.SharePoint.Publishing.Internal.CodeBehind.PageSettingsPage.LoadValues()
   at Microsoft.SharePoint.Publishing.Internal.CodeBehind.BasePageSettingsPage.OnLoad(EventArgs e)
   at Microsoft.SharePoint.Publishing.Internal.CodeBehind.PageSettingsPage.OnLoad(EventArgs e)
   at System.Web.UI.Control.LoadRecursive()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

An odd thing can happened in SharePoint. If you add a user named Joe Smith to a server, then add that user to SharePoint. Later you need to completely remove that user. So you delete the user from the server and you completely remove the user from sharepoint. (removed them from the user collection, not just the site)

One day comes and low and behold you need to add Joe Smith to the server again. You create a new user account for Joe on the server and add Joe to SharePoint. The only issue is that SharePoint doesnt resurrect the user from SharePoint. It creates a new one. And now when you are in a page that was originally created by the 1st Joe Smith you get the error above. Yippy.

If you run the SQL below you will find the two Joe Smith accounts.

SELECT * FROM UserInfo WHERE tp_Login = ‘MYSERVER\Joe.Smith’

You will get results like this

 

No User SQL

No User SQL

 The field tp_ID is the SharePoint UserID. The field sp_Deleted tells SharePoint if the user has been deleted. When you manually flag a user as deleted, all you have to do is to put the user’s ID in the tp_Deleted field. Notice that the user 19 has 19 in the tp_Deleted field.

So to resurrect the user 19 I need to kill user 16 since they both have the same username. The way I do that is simple

UPDATE UserInfo SET tp_Deleted = 16 WHERE tp_ID = ‘16′
UPDATE UserInfo SET tp_Deleted = 0 WHERE tp_ID = ‘19′
 

The SQL above will set user 16 to deleted by adding 16 to their tp_Deleted field. Changing user 19’s tp_Deleted field to 19 makes them active and all pages will work when you try and view page properties.

 

 

 

 

I hope this help anyone who runs into the same issue. I was a pain to try and diagnose why it wouldnt work and I think there is a fix for it coming from MS. But this server is on SP1 and it still does it.
NOTE: This sinerio will work if you just delete a user from SharePoint completely and need to edit their pages. Just put a "0" in the tp_deleted.

2 Responses to “User cannot be found”


  1. 1 frosty Sep 2nd, 2009 at 2:25 pm

    Thank you for posting this as it was a critical piece to a resolution of a serious problem we had with our test users during AD migration. During our AD migration, we were given a tool that is basically a UI for the stsadm migrateuser. Much to our suprise after running the tool, several user profiles were abandoned entirely and the items that they had modified or created showed only “Person” when clicked on “User cannot be found”. We discovered that at one point, account names were changed from first initial last name (FLAST) to NewID. The result of not running migrateuser from olddomain\FLAST to olddomain\NewId was that several profiles were deleted in error (and those items were shown as “Person”). To recover the associated userdisp.aspx number, we used your posted solution to “undelete” them (fantastic by the way) and then ran migrateuser olddomain\FLAST to olddomain\NewID and then we ran migrateuser olddomain\NewID to newdomain\NewID and it resolved our “Person” issue where the profiles were abandoned. The user should not log in to SharePoint during the process.

    Definitely not something I would recommend if you don’t have to do it, but it did work with no issues. I never would have had the confidence to go in to the tables without your post, so thank you so much for posting this.

    I should note that permissions for these folks were lost in the first pass of migrateuser, but recreating their rights was secondary to the “person” issue.

    Excuse my shorthand for migrateuser etc. If you need additional info or for me to write out the exact code for migrate user etc, please let me know. I am all too aware on the lack of documentation out there on this particular subject.

  2. 2 Chris Auer Sep 2nd, 2009 at 2:29 pm

    A lot of the documentation on the User Objects seems to be a hidden secret. I hope a lot of these issues are resolved in 2010. SharePoint was designed to fit in one particular box. And as you know, the world is full of MANY different boxes.

    Thanks for the positive notes.