SharePoint Users Missing from SharePoint Groups After Upgrade

The Problem

For our upgrade from SharePoint 2007 to SharePoint 2010, we ran into an issue with only one site collection where certain users are added to a SharePoint group in a particular site collection, they do not appear in the user list in the browser. If added outside of a SharePoint group (ie: given a permission directly), they appear normally.

They are added, as they can get access, and I can see them listed in the permissions in SharePoint Designer, however within the browser – they are not listed. There are no errors, messages, or warnings at any point. This only happens in one site collection, even though many other site collections use the same User Profile Synchronization Service.

The only similar situation I can find through Google is Cannot add user to SP group, SP 2010. We recently upgraded from 2007 to 2010, however we did not use any third party tool like Avepoint in the aforementioned thread – we used the database detach reattach option.

After some digging, we’ve found that the affected users are not listed in the “User Information List” (sitecollectionURL/_catalogs/users/simple.aspx), however it is possible to view the user’s entry in this list if you force-change the ID URL variable to their tp_id # from the UserInfo table in SQL (ie:http://sitecollection/_layouts/userdisp.aspx?ID=123.

Using PowerShell, we can found some commonalities in the users that are experiencing the problem:

  1. ForwardLinks and BackwardLinks contain empty arrays({}) in working users. Affected users contain nothing.
  2. FirstUniqueAncestorSecurableObject = “User Information List” for working users. Affected users have nothing.
  3. FirstUniqueAncestor = “User Information List” for working users. Affected users have nothing.

I’ve tried the following to resolve the issue:

  1. Full profile synchronization in central admin. (No Effect)
  2. stsadm -o sync deleteolddatabases 0 followed by a full User Profile sync in Central Admin (No Effect)
  3. Manually updating the missing properties in Powershell to match a working account (didn’t work, list is read-only).
  4. Deleting an affected user from the site collection and then re-adding their permissions. Issue persists.

The Solution

  1. Perform a full content deployment to  new content database.
  2. Detach the old database.
  3. Attach the new database.

Alternative

Stuart Pegg also offers an easier solution on SharePoint StackExchange using PowerShell, however we applied the above fix before Stuart’s response.