This project has moved and is read-only. For the latest updates, please go here.

Full name gets reseted to i:0#.f|fbamember...

Feb 6, 2012 at 6:04 PM

We have a SharePoint site using FBA with various FBA accounts on it.

Recently, once in a while (Seems to be once a week at the moment) one of the users "Full Name" gets reseted to the fba user name "i:0#.f|fbamember...". Nobody has access to this and I haven't accessed the SharePoint site either. It seems to only happen to this user too, the other are correct. I correct the Full name when it happens, but eventually will come back again.


Feb 6, 2012 at 8:35 PM

I'm not sure what would be causing it. The full name is stored at the site collection level, so if the same login is used on a different site collection I can see them not having their full name at the other site collection. But i'm not sure why their full name would be reset to the sharepoint user name on the same site collection.  Do you have any other third party solutions installed on SharePoint that might be making changes to the user's profile?

You mention it's only happening for a certain user. Does he happen to remember what operation he performs just before his full name gets reset?  

Feb 10, 2012 at 6:54 PM

After monitoring the problem closer, I see that every morning at 8:00:04 exactly the user gets updated and then the name gets reset. It is too precise to be a human action. It always the same user, and there are 15 other users. They are all "active" users.

Feb 10, 2012 at 8:50 PM

I'd say check the timer job history to see what runs at that time. I'd also check your SharePoint log at that time. Hopefully from there you'll be able to find the process that's resetting the full name.

Feb 22, 2012 at 4:02 PM

I found nothing in the SharePoint job history at this time. I even tried to run some of the scheduled job that were around this time and could possibly update the user information.

I'm out of idea, taking a look at the log might be a big mess, those log files are huges.

Feb 22, 2012 at 4:18 PM

So I finally took a look at the SP logs. Here is an exception that happen at the exact time my user was changed this morning.

02/22/2012 08:00:02.18  OWSTIMER.EXE (0x2FB0)                    0x257C SharePoint 2010 FBA Pack       General                        0000 High     System.ArgumentException: Column 'Status' does not exist. It may have been deleted by another user.     at Microsoft.SharePoint.SPFieldCollection.GetField(String strName, Boolean bThrowException)     at Microsoft.SharePoint.SPListItem.GetValue(String strName, Boolean bThrowException)     at Microsoft.SharePoint.SPListItem.get_Item(String fieldName)     at Visigo.Sharepoint.FormsBasedAuthentication.MembershipReviewHandler.ItemUpdated(SPItemEventProperties properties) 

Feb 22, 2012 at 4:31 PM

I'm not sure about the error itself, but OWSTimer.exe means that this is being run as a timer job. The SharePoint FBA Pack doesn't include any timer jobs, so this is something created on your side. My guess is that the user has created an alert on the Membership Request list, and that is somehow causing the issue.

Feb 22, 2012 at 7:25 PM
Edited Feb 22, 2012 at 7:26 PM

How do you create an alert on the Membership Request list? I haven't been able to find that out.

Edit : found out

Feb 24, 2012 at 3:44 PM

Just when I find out a hint of what could be happening, the issue just stop occurring. I created two users on my site with the two possible scenario that could cause the problem.

So whenever I see it happen again and I have a better clue, I'll let you know. Thank for you help :)

Apr 17, 2012 at 3:01 PM

Problem has been occuring again for the past 2 weeks. 2 different user this time, and the one that was suffering of this issue is not suffering from this anymore.

I did see you other message regarding a bug with user alerts. I did test it with my user and nothing happened for 2 days still, and no user on the SharePoint has user alerts (cheked in site admin)

Apr 17, 2012 at 3:05 PM

If you're still getting the above error about the Status column, you can fix it by deleting the Membership Request list and redeploying the FBA pack. See here:

Apr 17, 2012 at 3:54 PM

Hi and Thank.

Do I have to use your UnDeploy and Deploy ps scripts? Or only Deploy? I guess I won't loose any of my members since they are stored in a DB (No SP side created entities)?

Also the "Review Membership Requests" was turned off on my system. Will the solution above will fix the problem? Because I read in another post that this might be working too,

Apr 17, 2012 at 3:59 PM

Deploy will automatically undeploy. You won't lose any existing members, but if you have pending members in the membership request list, they'll get lost when you delete it.

I would only expect you to get the above error if Review Membership Requests was turned on, so if it's turned off I don't think this will help at all.

Apr 18, 2012 at 3:13 PM

I will try. Let's hope :)

Apr 18, 2012 at 3:48 PM

I had version 1.1.0 installed on the SharePoint.

I deleted the Membership request list, undeployed the 1.1.0 and deployed 1.2.0.

Everything was fine, but when I go to Site Actions->Site Settings->Users and Permissions->FBA Membership Request Management and I get a "The webpage cannot be found".

Could it be a future problem (We don't user Membership Request). And is it normal that the list wasn't created?

Apr 18, 2012 at 3:50 PM

Nope, that's not normal. Were there any errors when you deployed? I'd deploy again. 

Apr 18, 2012 at 3:54 PM

"Invalid URI: The format of the URI could not be determined".

Here's what I typed :

Deploy.ps1 -URL


Apr 18, 2012 at 3:55 PM

There's no -URL


.\deploy http://demo2010a:13824/

Apr 18, 2012 at 4:02 PM

Ah my bad, I misread the error message the first time (The URL parameter was not set) but it was comming from SP Activate feature.

Worked fine this time and the List is here.

So let's see in the future if the problem persist.

I also installed a Cummulative update to the SharePoint because of a bug we had with our solution.


Thank for your help :)

Apr 18, 2012 at 4:21 PM
Edited Apr 18, 2012 at 4:21 PM

Wasn't long to see if it was working or not.

I verified "Review Membership Requests" is uncheck.

04/19/2012 01:00:01.77  OWSTIMER.EXE (0x1338)                    0x20C8 SharePoint 2010 FBA Pack       General                        0000 High     System.ArgumentException: Column 'Status' does not exist. It may have been deleted by another user.     at Microsoft.SharePoint.SPFieldCollection.GetField(String strName, Boolean bThrowException)     at Microsoft.SharePoint.SPListItem.GetValue(String strName, Boolean bThrowException)     at Microsoft.SharePoint.SPListItem.get_Item(String fieldName)     at Visigo.Sharepoint.FormsBasedAuthentication.MembershipReviewHandler.ItemUpdated(SPItemEventProperties properties) 


Why is the ItemUpdated of  the member ship review list triggering is nothing was added or modified in that list?

Apr 18, 2012 at 11:04 PM

I don't know - it looks like there's some type of timer job happening on your installation.  The FBA Pack doesn't install any timer jobs, so i'm not sure where it's coming from. 

If you're interested, you can pick up a support plan and we can do a screen sharing session - i'll take a look at your environment:

Apr 19, 2012 at 1:37 PM

It cannot be a timer job, the ItemUpdated gets triggered. It has to be an item in the list.
Also, why do we get the "Status" column does not exist.
And why when this exception raise the name gets reset?

I cannot give any access of some sort on this environment.

Apr 19, 2012 at 1:54 PM

Other information I can give you is that the users that get reseted dont have a "User information" page. The page that is opened when you on the user name in a list (Created By).

It wasn't manually deleted. So I cannot say if it doesn't exist because of the bug, or the bug occur because of this.

Apr 19, 2012 at 2:12 PM

Did you delete the list using SharePoint Designer before redeploying, as was mentioned earlier? If you have, I don't know why you'd be getting the exception. I also have no idea why ItemUpdated would be triggered if Review Membership Requests is off. And it looks like the update is happening via a timer/scheduled job of some sort, otherwise I wouldn't expect the source to be OWSTimer.exe.

You can always try a clean installation on a different machine and see if you run into the same issues.

It's strange they don't have a user information page - but I don't see that causing any of these issues with the FBA Pack.  It's more that it shows that there's probably other issues with your environment.

Apr 19, 2012 at 2:17 PM

I deleted the list from SP directly (Site Actions->Site Settings->FBA Membership Request Management then delete the list normally. Is something different happening if I didn't delete it from SPD?

I see in the error says OWSTimer, but in a event, that you created in your list handler, is not very likely to be triggered by a timer job you didn't create.

I have an environment which has the FBA and we were unable to reproduce the problem. I'm not even able to reproduce the problem on the prod environment for other users than the 2 that have been suffering the problem.

I'm still puzzled on which line of code is resseting the user name when the exception occur.

Apr 19, 2012 at 2:36 PM

I’ve had the issue with resetting the names from alerts created in SharePoint on any list (Not just membership request) – not sure why it happens.
As for deleting the list from the List Settings, that should be fine too.
The event should be triggered any time any item is updated on the list, by whatever process.

Apr 19, 2012 at 2:40 PM

I have an alert on a list and the problem didn't happen (Membership request is uncheck however).

I know the event can be triggered any time by an updated item by whatever process. But the list is empty, and what process is "Adding" an item in that list so the event trigger.

Apr 19, 2012 at 2:51 PM

No idea. I'd look into the rest of your environment. Maybe remove the list, undeploy the FBA Pack and see if you still get OWSTimer errors (They should be different now, as there's no list to update, but i'd think you'd still get the error).

Apr 19, 2012 at 4:42 PM

If I undeploy the FBA pack, I shouldn't be getting the exception anymore, since the list doesn't exist. I'll try this.

Apr 27, 2012 at 7:57 PM

Hi ccoulson,

So I finally found a bug in the FBA pack that could explain the exceptions I find in my logs and that might cause the Full name reset like me and other people have.

In your "MembershipReviewList" you have "MembershipReviewHandler". If you look at its Elements.xml you register this Receiver on the ListTemplateId 100.

<Receivers ListTemplateId="100">

However the ListTemplateId 100 is a Generic Type in SharePoint.

What happen is whenever a item in a list that is from the ListTemplateId 100, your event received trigger. That's why we see the "Column status not found...".

The proper way to fix this is to change the "Type" value in the ListTemplate, the "TemplateType in the ListInstance and of course the ListTemplateId in the Receiver to a custom value of yours. Something unusual of course, like "23231". This way the ItemUpdated will only trigger when items of MembershipReview are updated.


Now on WHY the fullname gets reset, I still don't know. But since the exception that raise at the same exact moment than the fullname (Exact day/hour/minute/second) gets resets, I highly suspect that this is responsible.



Apr 27, 2012 at 8:08 PM

That makes sense! Actually - there's already an issue raised for that - fix will be in the next version:

Apr 27, 2012 at 8:47 PM

Great. I'm still wondering why the fullname gets reset.

Apr 27, 2012 at 8:50 PM

Dunno. I've put a note on the issue to look into that when i'm fixing - to see if it's that event handler causing the issue - or if it happens with all alerts.

Apr 27, 2012 at 8:51 PM

Since I don't need the Membership Review I'll put all the code in comments in the event receiver for the weekend to see if this is responsible for the name reset.

Apr 27, 2012 at 8:52 PM

Good idea. Let me know the result.

Apr 30, 2012 at 2:05 PM

Not sure if it's a bad luck again, but the problem didn't happen since I deployed my custom version with the event handler code commented.

Apr 30, 2012 at 2:06 PM

Good to hear!