We recently heard from members of our intranet team that they wanted to start using the content targeting features within SharePoint. Basically this allows you to target specific content to users based on various criteria. So you could target a tab on the home page of your corporate intranet with HR related news that would only be viewable by users that are members of the HR Team’s DL or Security Group. Content Targeting can be done using SharePoint groups, Global Audiences, Distribution Lists, and AD Security Groups. This is a really cool feature within SharePoint – when it works.
Soon after implementing this feature we began to receive reports that some users were unable to see the targeted content, while others were able to see it just fine. After verifying that the users having problems were in fact members of the groups being used, it was time to take a deeper dive and figure out what was going on. I ran some tests with one specific DL that contained a total of 120 users according to Active Directory, but when looking at this DL within the SharePoint people picker it showed that there were only 10 users. I then went into Central Admin and created an Audience based on members of this DL, so that way I could see exactly which users were being populated, and which were missing. What I eventually realized was that user accounts that were located in the primary domain (which the SharePoint servers were also in) were showing up in the DL and were able to view the targeted content with no problem. It was the other 110 users that are located in child domains within our AD forest that were not showing up in the list. Since I had configured the profile import connections to import the ‘Entire Forest’, I found this really odd. To add to the confusion, I was able to search and find users from these other domains within SharePoint and assign permissions to them just fine – They just weren’t being populated into the groups, DL’s, etc.
After finding a few more people with this same problem online but no resolution, I eventually opened a call with Microsoft. It took some time, but I’m happy to say that today we have finally come up with a resolution. To fix the issue, you simply need to configure your import connections to point to Domain Controllers that are acting as Global Catalog servers, rather than just going with the default of ‘Auto-Discover.’ If you don’t administer AD, you’ll need to get the names of the global catalog servers from one of the guys that does. Once you have that info, simply log into your SSP website—> User profiles and properties—> View import connections. Then click on ‘Specify a domain controller’ and choose a known GC server from the dropdown list.
After configuring this for all of my import connections, I then re-compiled the audience that I had been testing with and it is now showing all 120 users. I also verified that this fixed the population issue for both security groups and distribution lists. I have encouraged Microsoft to document and post this fix publically, since I know that many others have wasted countless hours on this same issue and eventually given up. Luckily once you have the fix it’s quite simple to implement.
