locked
username() returning old login RRS feed

  • Question

  • I have an Infopath2007 form hosted in InfoPath Forms Services on SharePoint 2007.  My form calls the username() function on form load.

    There are a few users who do not have the same login as when they stared with the company.  For these users, the username() function is returning their old login, even though they have not used that name in quite some time.

    I do not see this old account listed anywhere in Active Directory.  One user tried running the command "Infopath /cache clearall", but received an error that Infopath was not installed.

    Does anyone know where this old login might be coming from and how to correct this problem?

    Thursday, February 17, 2011 6:13 PM

Answers

  • Thank you for the suggestion, I took the same approach from the other end.  I hosted the form on a different SharePoint server, and it works for the user.

    Some more research revealed that although the user profile in shared services has been updated, the account in my site collection has not.  The Account field shows the old login, while the User Name field has been updated.  Clearly, the username() function in InfoPath pulls the Account field rather than the User Name field or AD login.

    We have run the command "stsadm -o migrateuser ...", which seems to have updated the Account field for the user in question.  I will follow up with them to confirm.  However, there must be a better way to automatically update user accounts before they call our help desk with a problem.

    • Marked as answer by Emir Liu Monday, February 28, 2011 2:54 AM
    Tuesday, February 22, 2011 7:23 PM

All replies

  • What happens when the affected user logs into a different computer? Do they have this issue there?

    This might help you narrow down the root cause, i.e. if it's related to specific computer only or not.

     


    Pman
    http://www.pmansLab.com/
    Saturday, February 19, 2011 4:47 PM
  • Thank you for the suggestion, I took the same approach from the other end.  I hosted the form on a different SharePoint server, and it works for the user.

    Some more research revealed that although the user profile in shared services has been updated, the account in my site collection has not.  The Account field shows the old login, while the User Name field has been updated.  Clearly, the username() function in InfoPath pulls the Account field rather than the User Name field or AD login.

    We have run the command "stsadm -o migrateuser ...", which seems to have updated the Account field for the user in question.  I will follow up with them to confirm.  However, there must be a better way to automatically update user accounts before they call our help desk with a problem.

    • Marked as answer by Emir Liu Monday, February 28, 2011 2:54 AM
    Tuesday, February 22, 2011 7:23 PM
  • I appreciate that Emir marked my response as the answer, and it did in fact resolve the problem for the user in question.  However, I consider this to be a poor solution.

    The "stsadm -o migrateuser" command must be manually run any time a login changes in AD.  I would define a good solution as one which automatically keeps the site collection account up to date with changes that are made to the global profile.

    Monday, February 28, 2011 5:33 PM
  • Andy, I am having the same kind of problem as you report. We too do not run stsadm -o migrateuser ... we have hundreds of changes a year and have over the 6 or more years that we have been running SharePoint.

    InfoPath's userName function is the first time it has turned up to bite us.

    You mention an "account" field; where is that located? Is there a way that I can get a list of all users and their account fields?

    After web searching the migrateuser option of stsadm I have grave concerns about using it to resolve these problems. Several blogs mention the fact that the user will likely lose permissions because their old id's permissions overwrite any new permissions that may exist for the new login.

    At least one blog warned that migrateuser can also leave a site (or perhaps it was site collection) without an owner and without any way to add a new owner.

    Thursday, November 29, 2012 2:41 PM
  • Sadly we are still wrestling with this issue.  Since posting this issue we have upgraded to 2010, but the issue remains.

    With further research we discovered that there is a master user profile maintained by your user profile service, and a copy of that profile is created in each site collection the first time that user accesses the site collection.  These copies are not kept in sync with the master.  This will affect anything that uses the site collection profile, including the InfoPath userName() function, but also things like the site's people picker.

    You can view the site collection profile copy's properties with this link: "https://sharepoint/sitecollectionname/_layouts/userdisp.aspx?ID=123&force=1" Substitute sharepoint, sitecollectionname and ID with appropriate values.  The only way I have found the ID is by managing permissions somewhere in the site collection where the user has explicit permissions, and looking in their profile link url.  On this page is where I see the two fields - account and user name, but I think my description was backwards before.  For a user that has changed network logon name, the account property shows this change, but all other fields including user name do not.

    One thing we have found is that SharePoint does not sync profile details for inactive users.  We found a way to remove this optimization and sync all users, but it doesn't not seem to have worked fully.  I am currently seeing a very active user whose profile still shows old values.

    Thursday, November 29, 2012 5:15 PM
  • What is the ID number?  I am not certain I know what that is.

    It is pretty amazing to me that this is still an issue after all these years

    Thursday, November 29, 2012 5:35 PM
  • Here is how I get to the site collection profile.

    1) Go into the site collection you want to test

    2) Manage the permissions on something.  Anything.

    3) Find a permission entry for a user you want to test.

    4) Their name is a link to their profile.  Copy that link.  This will include their ID for that site collection.

    5) Paste that link into the address bar.  Replace everything after ID=123 with "&force=1"

    6) Enter.  Note: If you don't include force=1, this will automatically redirect to their mysite profile, which is the master.


    • Edited by Andy Cobb Friday, November 30, 2012 12:05 AM spelling
    Thursday, November 29, 2012 5:42 PM
  • Thanks - that is very helpful.

    When I started along that path,
    I went into the site collection and the site, went to the permissions,
    and did a new user to add the developer to a group. The people browser
    shows me both the old and new login.

    If I wanted to _delete_ that old account (which is already gone in AD), does anyone have any ideas on how to do that

    We really don't want to move the old userid's permissions, etc. over top of his current id.

    Thursday, November 29, 2012 5:56 PM
  • If you don't want to preserve permissions, you can just remove the user from the site collection and then add them back.  Here is an article on how to do that, for the same reason as we are discussing.

    http://blogs.c5insight.com/Home/tabid/40/entryid/181/How-to-Remove-a-User-from-a-SharePoint-2010-Site-Collection.aspx

    Like you, I have found tons of people with the same problem of syncing accounts, each with their own way to work around it, but I have yet to find anyone who can make all accounts sync up all the time.  Seems like it should just be a switch, but I haven't found it.

    Edit: this article is for SP2010.  Not sure what version you are on, but the same general idea applies for 2007 as well.
    • Edited by Andy Cobb Friday, November 30, 2012 12:14 AM
    Friday, November 30, 2012 12:12 AM
  • Very interesting.

    I looked up my developer and clicked on his name. I was taken to a SharePoint list item form, which showed a variety of fields including the out of date "account" field.

    I deleted him from the all people, then re-added him. At that point, when I click on his name, I am taken to his my site, rather than to the previous display. In fact, I chose a random set of other people and saw that if the person was a current user, I went to their my site, but if they were no longer at the company, I went to the sharepoint list item view.

    With thousands of entries in the all people list it isn't something that I am interested in just sitting down and stepping through right now.

    What I am wondering is about the consequences of doing the deletes.

    For instance, what if there were lists, libraries, sites, or site collections which were created by the developer when he was using the old login. What happens to them now? If that entry was the link to the item's creator/owner, I would presume it no longer has an owner. I wonder how I would find those and resolve that?

    Friday, November 30, 2012 12:35 PM
  • The force=1 query string parameter will show to the site collection page.  Leaving this off of the url or clicking their profile without editing the url will redirect to their mysite profile page (if it exists).

    The consequences of removing and re-adding user accounts in this way is that all permissions the user had on the site will be removed.  This might be acceptable for former employees, but you certainly don't want to do this for active people.  

    I'm not sure what would show in the Created By field for items created by removed accounts.  Try it out.

    Friday, November 30, 2012 8:57 PM