O great problem solvers, Last week our Enterprise MOSS implementation's AD import stopped compiling audiences. People's profiles import fine, but now the process never kicks off to compile the "Membership and BDC import status". So there are no more loggings for the "PEOPLE_DL_IMPORT" content source, which keeps track of your group membership, hence no more users are being added to any AD audiences you may have been using. Has anyone seen this behavior before? I can get this to work in staging, but not in production with the exact same settings (read: WIERD). S/W version is 12.0.0.6017. There are no event log errors and even with granular logging on I don't get any errors.I'd be more than happy to supply any more information. Thanks in advance if anyone had any ideas to kick around. -Eben Shantz

I'm having the same issue. We don't have our production environment up yet but this isn't working at all. The profiles are imported but the next step to compile membership never starts.

I may have the same sort of issue. Profile imports are working perfectly on the default SSP, however, on a secondary SSP, only users are imported. So on my secondary SSP, like you said, "PEOPLE_IMPORT" contains users import logs, but "PEOPLE_DL_IMPORT" does not contain any groups import logs. On my default SSP, both show logs. I noticed that on the secondary SSP User Profiles and Properties page, the "Membership & BDC import status:" category only shows "idle" where as the same page on my default SSP shows "Idle - Completed in 0h 0m 40s". I have no idea how to start it. Any help would be appreciated.

Looks like there are alot of people with this issue. After much troubleshooting, it's not yourAD-custom connection string that is causing theissue, it's actually the SEARCH service that compilies your audiences after the AD import completes that is failing. If you don't have any People_DL_Import events, it is thecase that you are not compiling audiences. It could be that the password for your search account changed or simply the database has become corrupt and uncompilable. Anyways, here's the "shotgun" method I used tosolve the problem: 1. Deactivate the Search service (query) on your query servers 2. Deactivate the Search service (indexing) on your indexingServer (important) 3. Stop/Start the Office Search service on each box. 4. Start the search service for the indexing server. 5. Reset the Crawl index. 6. Start a full import of all your content sources. 7. Start the search service for querying on your WFE's as you'd like. Literally that easy, but still takes you some time if you have alot of indexes (we have 1M+). Hope this helps someone else, Eben

Can you give me the exact instructions to thesteps you outlined, especially 1 and 2? Is that the same as Windows SharePoint Services Search? Thanks.

I meant from the Admin GUI, deactivate each service assigned to each server. Not the Windows Service, although I'm sure it wouldn't hurt you to stop/start that.

We are also having this problem. I have tried the above, it has worked in the past, but this method is not working now. It is happening in our evironment with SP1 December CU and SP2 April CU.Has anyone had success in resolving this problem using a different method, or have any pointers to finding a solution.Thanks

I have found a solution for this problem. A timer job appears to be stuck and resetting all of the timer definitions fixes it and user profiles will be crawled correctly again.On the server which is hosting the search indexer: Open Services and stop the Windows SharePoint Services Timer service Start > Run > %ALLUSERSPROFILE%\Application Data\Microsoft\SharePoint\Config Open the folder whose name is a GUID Delete all files except cache.ini Open cache.ini and change the number to 0 Start the Windows SharePoint Services Timer service Once all of the job definitions have been recreated, user profiles will be crawled again automatically.

I have found a solution for this problem. A timer job appears to be stuck and resetting all of the timer definitions fixes it and user profiles will be crawled correctly again.On the server which is hosting the search indexer: Open Services and stop the Windows SharePoint Services Timer service Start > Run > %ALLUSERSPROFILE%\Application Data\Microsoft\SharePoint\Config Open the folder whose name is a GUID Delete all files except cache.ini Open cache.ini and change the number to 0 Start the Windows SharePoint Services Timer service Once all of the job definitions have been recreated, user profiles will be crawled again automatically. Thank You Daniel. This did the trick for me.

We have a situation now on prod in sharepoint 2007 based intranet platform and it shows thousands of records under people_dl_import category with format spsimport://?$$dl$$/domain1/domain2/domain3/ Also import was not stopping and added millions of records in database and was on verge of disk full. On other servers like dev we have very less data in this category. I need to know the cause of this garbage data and how to fix it. I tried resetting content source and I will do full import in this weekend to see if this garbage data gets cleared. Any idea on cause for thiss issue?

Amit, we've got the exactly same problem. Were you able to resolve this issue?