It is usually a combination of an incorrect user profile import
connection and not crawling the sps3:// default content source. Verify
these are correct, and in this order. I will see if I can dig up some
old email threads I have on this.

You could also try creating  a custom connection to your LDAP (AD)
instead of using the default. Do not use a filter and select 'Active
Directory' as the source.

I'm having the same issue, My Profile import seems correct but I am
pretty new at this. The only question I have is the user filter which
is currently set to (&(objectCategory=Person)(objectClass=User))
should there be an entry there for groups?

How do I verify that sps3:// is being crawled? Everything I have
setup so far is default.

(These instructions are MOSS 2007, so hopefully they help.)

You can verify that sps3:// is being crawled by looking at your content
sources to ensure that they're configured or your search  crawl logs to
ensure that it's actually being crawled. Both of these require you to be on
the "Search Settings" screen in your SSA.

You can check content settings by looking at the content sources defined -
click on the link next to "content sources" under "crawl settings". Bring
up the menu under "Local Office SharePoint Server sites" and click "Edit".
Look at the start addresses for the content source - one of them should be
prefixed by sps3:// or sps3s:// (this should usually also be operating on
the same port as your MySites).

For crawl logs, under "Crawl Settings", click on "Crawl Logs". Your SPS3
connection won't be explicitly listed - you might have to check a few of
those items, since it doesn't list protocol in that list, but again, it's
likely under the same port number as your MySites.

Thanks, that got rid of some of my warnings but I still can't add AD
groups in Audiences when setting the rule to use the Operand and
Member Of Operator.

Any other ideas would be great.

I probably shouldn't show you the path to this bunny trail, but
here goes:

The last person (I remember) who had this issue was missing a SQL stored
procedure. Deleting and rebuilding the SSP did not solve the problem.
They contacted CSS (PSS) to resolve the issue.

proc_ar_BumpCacheInvalidationCounter stored procedure

These AD Groups. Are they SECURITY groups  or DISTRIBUTION groups (in AD
terms...) ?

Both, I don't see any of them............

This stored procedure is on my sharedservices DB, should it be anywhere else?

I am having the same issue. I have been working with Microsoft to try
to fix it, but have not had any luck?!

This usually works when I do it in class. Please post back when you
learn about what the problem/solution is.

Since security  Groups can be used directly as an audience, I have never
understood the need to build an audience  based upon security group
membership.

Perhaps if one wanted to build an audience combining several security
groups.

For me, the behavior was the same whether I tried an audience  or a
security group, to Daniel's point.

I had just set up the security  group, but had not added any users.
I then did a full profile import and an incremental crawl. The group
still did not show.

I added a user to the group  and did another full profile import and
an incremental crawl and the group became available in the People
Picker.

This seems to have fixed my issue.

In large implementations, creating  Global (SSP) audiences  increases
performance. The audiences are precompiled and therefore greatly reduces
the amount of traffic going to the Domain Controllers. I suppose if you
are using Kerberos, there could be little difference.

I create  audiences that consist of Security Groups, fwiw.