Update: This issue does appear to have been resolved in the August 2011 Cumulative Update (build 6109). Although I have not validated this, I would defer to the product group for their fix if possible. If you have not yet, or do not yet have a plan to deploy the August 2011 (or later) CU, the solution below should continue to be effective.
While onsite with a customer I was recently shown an interesting situation where membership data (the list of links that you are considered a “member” of) does not appear to remove sites that no longer exist, and does not update the URL for sites that do exist. For example, pretend you have a temporary site at http://tempsite/ that you are in the Members group for. SharePoint will automatically create a link to that site for you in your profile within appx. 1 hour. Afterward, you either delete this site (it was temporary, after all), or you do a database move to attach it to http://realsite/ instead. You would expect that in the same way that SharePoint created the temp link, it would now remove it since it is no longer there. Unfortunately, this update never happens. Also, since the “real” site now has the same ID as the “temp” site (because you moved the site via a database move), the real link to the real site may never be updated/created.
There have been several cases opened on this issue, and the SharePoint Product Group is aware that people are experiencing the problem. My customer, however, was more interested in an immediate resolution than a formal fix, as they had recently done a significant migration and wanted to quickly remove the large number of incorrect links on profiles… and my job as a Premier Field Engineer is to make my customer happy, not recite dogma. 😉
In the attachments below is a VisualStudio 2010 project that contains a quick, brute-force solution to the problem. The code written creates a command-line utility that requests a web application and a search prefix. The web application URL should be a link to your My Site Host web application. The search prefix narrows which profiles should have the membership deleted. For example, if the My Site host is at http://mysite and you wish to purge all membership data for users in the Contoso domain, the following command would work:
SP2010RemoveMembershipData.exe http://mysite CONTOSO
Note that this is a brute force purge of all membership data and will delete all membership links, including those added manually by an end user.
In order to rebuild the membership data, all existing content database sync connections must be “reset” so that they do a full sync instead of attempt to update incrementally. The following STSADM command will cause all existing synchronization connections to be removed, and will cause SharePoint to rediscover and rebuild the data (perform a full sync) the next time the timer job is run:
STSADM -o sync -DeleteOldDatabases 0
If you are feeling impatient, you may force the sync job to run immediately by locating the “User Profile to SharePoint Full Synchronization” timer job in Central Administration and selecting to “Run Now”. Note that if you have a large number of site collections, this job could take time to run. You will not see new membership data immediately. Running the timer job manually simply expedites the process.
After the timer job completes, you should see the correct membership links in your user profiles. Keep in mind that the Membership link to a given site will only be created if the user is a DIRECT member of the group listed as the “Members” group for a given site. Being in the “Owners” group is not sufficient, nor is it enough to be in an Active Directory group that is in the Members SharePoint group (AD groups are not expanded by the sync process).
DISCLAIMER: This should be considered “sample code” and should be run at your own risk and only after your own testing. Source code is provided to allow you to review and modify the code to meet the needs of your situation and your environment. Feel free to modify, but please link back to this blog post if reposted elsewhere.