Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have observed on SharePoint 2010 that if you change the sAMAccountName of a user after the user has logged into a SharePoint site collection, the tp_Login field in the UserInfo table does not get updated. It still has the old user Id.

While the user can log into SharePoint under the new account, these new logins do not update the table. I have code that looks at the SPUser.LoginName and this value appears to be the tp_Login field value which is now old. The fact that this value is old causes my code to fail.

I suspect this behavior is identical in SharePoint 2007.

Is there any way to force SharePoint to recognize the new sAMAccountName? I suspect that profile synchronization might help, but I would like for my solution to work with WSS 3.0 and SharePoint 2010 Foundation.

I considered manually updating the database table, but I would like to stick with supported approaches.

share|improve this question
up vote 3 down vote accepted

This should solve it for you. It must be run as the sharepoint admin. In the past I have found that this doesn't work in every scenario and that occasionally the sharepoint dev team had to fix users manually.

stsadm.exe -o migrateuser -oldlogin -newlogin [-ignoresidhistory]

share|improve this answer
That looked promising, but I must be in one of the non-working scenarios :-(. The first error I got was "New user account does not have valid SID history" so I added the "-ignoresidhistory" param and then the error I get is "Value cannot be null. Parameter name: userProfileApplicationProxy". I don't have profiles imported, so maybe that is the problem (but I don't want that as a requirement). – Kirk Liemohn Feb 14 '11 at 20:01
I stand corrected. My operation eventually worked. Not sure if it was the one with or without "-ignoresidhistory" as there appeared to be a delay (timer job, I suppose). Also, here is a good link on this: – Kirk Liemohn Feb 14 '11 at 20:07
great glad it fixed your issue. – pablo Feb 14 '11 at 20:09

When I tried the following command

stsadm.exe -o migrateuser -oldlogin Domainname\Oldusername -newlogin Domainname\Newusername –ignoresidhistory

I received the same error:

"Value cannot be null. Parameter name: userProfileApplicationProxy"

However if I ignored that error and tested, it was successful.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.