C/D/H Talks Tech

Author:

David Tappan

I have been working in IT for 12+ years and have spent the last 6 years with C/D/H.

My specialties have grown over the years, and now include:
Active Directory/LDAP/Directory Synchronization, Exchange and SMTP, Office Communications Server, and SharePoint, SharePoint, SharePoint!

When I’m not at work, my favorite activities are gardening, skiing and spending time with my wife and 3 kids.

More about David
Articles by David Tappan

The marketing literature for MOSS often touts “rich profile information” as one of the key benefits Office SharePoint Server has over its competitors-including the “free” option of using WSS.  But how is this rich profile information to be used?  One of most important ways is through audiencing.  This feature allows information on a web page to be shown or hidden, depending on almost any aspect of rich information that SharePoint possesses about each logged-in user.  However, in my use of audiences for various implementations, I’ve had to work through a number of “gotchas” before audiencing can be used effectively.  I thought I’d take the time to gather these together in one place, both for the good of all, and as a reminder for myself. 

The importance of profile imports

Most of the issues I’ve run into with audiences arise from not being clear about the importance of profile imports.  Audiences rely on what SharePoint knows about you, and essentially everything it knows is based on profile imports, so you have to get this right. 

• Audiences are not updated in real time.Far from it. The maximum frequency of import that can be configured in Central Administration is-disappointingly-once a day. Once that import occurs, audience compilation must be performed. Thankfully, this occurs once every fifteen minutes. Many, perhaps most, of my clients have found this to be far too infrequent-it means, for example, that a new employee, or one who changes department, will not see SharePoint content correctly for at least one full day from the time their properties are set in Active Directory. Fortunately, the estimable Gary Lapointe has written an STSADM command that allows you to kick off a profile import from the command line, so I usually create a batch script to do this, and schedule it to run several times a day.
• The profile import connection must be configured correctly. Profile import connections use LDAP to define the connection to Active Directory. The two most important settings are the Search base and the User filter.

o Set the search base to encompass all AD group audiences. The search base must be set to include all users for whom profiles should be generated, and importantly, every group which you intend to use as an audience. Each profile import consists of two phases: first, all the users in the search base are imported; then all the security groups and distribution groups. These latter two can be used as audiences.

o Use the user filter to… wait for it… filter users! Many of the problems I’ve seen with audiences have been caused by trying to control which users get user profiles by limiting the scope of the search base. This is not an effective approach. Instead, use the LDAP query in the user filter field to accomplish this task. Here are some examples:

Groups, groups, groups

There are several gotchas related to using groups-either AD or SharePoint-as audiences.

• Don’t put AD groups into SharePoint groups if you are using the SharePoint group as an audience.Both SharePoint groups and AD groups can be used as audiences; however, AD groups nested inside of SharePoint groups are ignored. In other words, if you are going to use SharePoint groups as audiences, only put individual users in them. Hey, I don’t make the rules.
• Don’t put users from one domain into local or global groups in another domain, if you want to use those groups in audiencing. This is critical to understanding how SharePoint collects information, from AD, about group membership. SharePoint does NOT import the membership of groups by directly querying those groups. Rather, SharePoint determines what groups a user belongs to by reading the user’s memberOf property. But the memberOf property will not show a user’s membership in local or global groups in another domain, so audiences based on those groups will be missing that user.
• If you want to use universal groups, be sure to connect to a global catalog. By default, the profile import connection selects a domain controller automatically. Based on my experience, there is no guarantee that it will select a global catalog. So if you want to use universal groups, you need to hard-code the connection to use a particular domain controller.
• New AD groups require a full profile import. You might think that if you create a new Active Directory group, it will be available as an audience after an incremental profile import. Unfortunately the incremental import process only picks up changes in group membership, not new groups. This is because the membership import in an incremental import only checks for changes in the groups it already knows about.

It’s a Bug, not a Feature

All the above gotchas are by design, and make some kind of sense.  But some problems you’ll run into with audiencing are bugs-or at least I think they are.  Unfortunately, Microsoft doesn’t seem to agree with me, so I don’t know when to expect them to be fixed.

• Beware of moving or renaming AD groups. SharePoint stores the full distinguished name of groups it imports. When a group is moved, SharePoint interprets this as a new group, and empties the membership of the original audience. This leads to two audiences-one of which is empty-and hides any items audienced with the original audience. I’d say this counts as a bug, but I haven’t seen a hot fix for this yet.
• Beware of using the DNS version of the AD domain.Here’s another bug in profile import connections: if your domain name is something like int.company.com, but your domain NETBIOS name is COMPANY, make sure you use COMPANY as the domain name when setting up your profile import connection. Why? Because if you use int.company.com, SharePoint falsely converts this to a NETBIOS name of INT, and attempts to use this to import groups. This causes the import of groups to fail. Again, I haven’t seen a hot fix for this, but I haven’t checked the newly released Service Pack 2. If I hear of a fix-or even an acknowledgement-of either of the above two bugs, I’ll update this post.

So, to summarize, the keys to getting audiences to work properly in MOSS are:  understand the profile import process, and understand how AD groups work.  Happy audiencing!