I really like using SharePoint Audiences to target pieces of content or pieces of pages to specific people based either on what active directory groups they are a member of, or based on specific criteria about the user, such as which city they work in. For example, it makes a lot of sense to show the latest news postings for each city on the homepage as targeted news items for members from each city.
Recently though we found one day that audience targeted items were no longer showing for specific people. After a bit of troubleshooting, we discovered that one of the active directory domain groups that we were using was in an Organizational Unit (OU) that had been renamed. It was a very simple change for the network guys, but they had no idea that it would break things in SharePoint — why should it?
After a bit more research, it appears that whenever a profile import occurs in SharePoint and the corresponding membership import occurs, SharePoint stores all the domain group membership in a database table in the SSP database called MemberGroup. This table stores all the groups with a corresponding count and the group's canonical name. When the group's canonical name changes in active directory SharePoint finds the new group and adds it as a duplicate entry into the table, and orphans the old record. However, the audience rules still point to the old record, which is no longer valid and the audience compiles without any members.
To make matters worse — when you then go into your audience rules to correct the problem, there are now multiple groups to select from, with only 1 group being the correct group. The problem is that there is absolutely no way to tell from the interface which one is correct unless the actual name of the group changed.
I've looked into the Audience and Membership API's but find nothing that will help. I contacted Microsoft just to find out that it is a "known issue" without any sort of timeframe as to when it will be fixed. The support rep actually suggested that I just clean out the table in the SSP, but when I asked if database operations like that were supported he had to retract that suggestion.
If anyone else finds a solution, please let me know. Otherwise I'll continue guessing which group names are correct while I watch the never ending fountain of hot fixes for a solution.
gruz