Like button doesn't always work

When I navigate to a newsfeed and click the "like" button I sometimes get an error:

Something went wrong: We're unable to like this post for you right now.

This only occurs for specific users. I can click the Like button for majority of users, but a few will generate this error.

Looking in the diagnostic logs, the error message is:

Exception occured in scope Microsoft.Office.Server.Social.SPSocialFeedManager.LikePost. Exception=Microsoft.Office.Server.UserProfiles.SPS2SAppContextException: Recursion check failed.   

That user gets a similar error when they click to delete that post. Anyone point me a general directon to troubleshoot this.

April 16th, 2013 7:14pm

I would start with Fiddler to see whats being passed back to the server, seems like something is being rewritten during transmissi
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2013 6:51pm

I do not see how this answers the question, it does give a troubleshooting process (which of course I had already investigated with no good results).
June 25th, 2013 3:02pm

More information. I have been able to to find the connection between the sites this works on and the ones it does not.

We have upgraded from 2010 (originally 2007) to 2013. The users were given the option of having thier MySites upgraded, or just a new one created. The sites that were upgraded have the problem, but the ones that are fresh sites do not show this symptom.

I am currently heading the direction of security, or "bad GUID" on the microfeed list of the MySite...

Has anyone else experienced this on upgraded My Sites? (I also only have RTM, so I working through our patch process to update that right now).

Thanks,

Free Windows Admin Tool Kit Click here and download it now
June 25th, 2013 3:08pm

I am running into a similar problem but with different scenario.  Mine was a fresh SharePoint 2013 farm.  I initially provision one web app with host header site collections for my sites.  E.g., http://intranet for primary path-based sites and http://mysite for my sites.  Decided to separate out my sites into its own web app because of the need to separate my sites contents into its own database.  Did a Backup-SPSite of all my site site collections, remove all my sites from original web app and then Restore-SPSite to the new my site web app.   All the contents were moved fine.   However, some users cannot post anything to the Newsfeed and all "like" failed.  The error is same as yours.

Microsoft.Office.Server.UserProfiles.SPS2SAppContextException: Recursion check failed

June 25th, 2013 10:32pm

I came across a similar issue when moving a user's MySite collection from a Staging Environment to a Production environment.

I did a Backup-SPSite from Staging and a Restore-SPSite to the new Production location (forcing an overwrite of the existing MySite).

The restored user was able to post items to the 'Everyone' Newsfeed, however all other users were unable to 'Like' or 'Reply' to their posts.  I was getting the same "Recursion check failed." error.

After much trial and error, I was able to do the following:

1) Delete the user's profile from the UPS (make note of any properties that aren't synced with AD)

2) Recreate the user's profile manually, and then do an incremental synchronization

3) Update any missing properties that didn't synchronize.

4) Ask the user to visit the built in 'Newsfeed' link (Root web URL for your MySite Host).

After a minute or so, their user profile will reconnect to their Restored Site Collection and any future posts will allow others to Like/Reply.

Hopefully this will help someone else who runs into the elusive "Recursion check failed."

-Xenox G.

Free Windows Admin Tool Kit Click here and download it now
July 24th, 2013 8:18am

I did try this process and the Mysite continued to say that it was configuring the site. This continued for at least a day... In other words, not sure that it fixed my issues. I have found a less intrusive resolution, see post below.
July 25th, 2013 2:54pm

OK, so after a ton of digging (in between real work), I have found the issue and a resolution. Original process for upgrade included moving My Site site collections to a new URL. The process that was used was as follows:

1. Create new content database in 2010 server on main URL

2. user the move-spsite command to move all the MySites to new content database

3. move main DB to 2013 main url

4. run powershelll to create My Sites for the specific users

5. Dismount database that contains all the my sites

6. Mount content database from the 2010 server (step 2). This of course upgrades the sites to 2013

Findings: the User profile services does not reprovision the MySite since is was already configured (as far as it knows) and thus has an incorrect ID reference for Web, Site and list ID. It stores this in a property on the USer profile service named: "Feed service provider defined identifier".

If you look at that long string, you can decipher it to [URL of MySite];[folder ID from list (in my testing always 1)].[Site ID].[webid].[listid].[unknown GUID that does not change]

If you use powershell to gatehr the ID, you can rebuild the string (remember to take out all dashes) and it will then reconnect to the feed list.

Hope this helps someone else also.

Free Windows Admin Tool Kit Click here and download it now
July 25th, 2013 3:07pm

Great find Eric and thanks for sharing! I stumbled upon the same when attaching a content database with MySites from another SharePoint 2013 farm to a new SharePoint 2013 farm. I couldn't delete my own posts on the social timeline and noticed in the ULS logs that it reported a similar error as you describe. Turns out its even easier to fix it than you describe. You can just empty the property in the user profile. Upon the first time when the user hits the MySite root again, it automatically reconstructs the property with all correct values.

For completeness, a step by step tutorial how to do this:

  1. Go to Central Administration
  2. Click on Manage Service Applications under Application Management
  3. Click on the service application which is marked as being your User Profile Service Application in the right column
  4. Click on Manage User Profiles under People
  5. Enter the name of the user for which you want to restore its profile in the Find profiles field and hit Find
  6. Click on the result and click on Edit My Profile
  7. Scroll down until you see "Feed service provider defined identifier:"
  8. Empty whatever it shows in the field behind this
  9. Scroll all the way up again and hot Save and Close
  10. Now have the user hit your MySite root again
  11. Go back into the User Profile and verify that the "Feed service provider defined identifier:" contains a value again

If for some reason it doesn't repopulate the field, the following PowerShell script will create the correct contents for you to put in the "Feed service provider defined identifier:" field in the User Profile:

$mySiteUrl = "https://my.zomers.eu/personal/koen"
$site = Get-SPSite $mySiteUrl
$microFeedId = ($mySiteUrl + ";1." + $site.ID.ToString().Replace("-", "") + "." + $site.RootWeb.ID.ToString().Replace("-", "") + "." + $site.RootWeb.Lists["Microfeed"].ID.ToString().Replace("-", "") + ".0c37852b34d0418e91c62ac25af4be5b")
$site.Dispose()
Write-Host "The microfeed ID:`n$microFeedId"


June 12th, 2014 12:39pm

Nice one Eric - you are a total legend.

Free Windows Admin Tool Kit Click here and download it now
December 18th, 2014 8:27pm

Very helpful!

I had this issue when mounting a prod-db in test-environment. Removing the FeedServiceIdentifier string solved it!

Thanks for sharing!

July 10th, 2015 2:57am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics