Wednesday, November 14, 2007

MOSS User Profile Import - Why can't I find Distribution Lists? Why is my AD Import failing?

Today, working on a proof of concept, a coworker of mine was trying to add a distribution list to an audience. This doesn't sound like rocket science but every time he tried to add a list he knew was in our domain.... NO DICE. Nothing would be found.

So, every post I could find on the issue said "DO AN IMPORT".

Here's some posts that we considered:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1839430&SiteID=1

http://blogs.msdn.com/sharepoint/archive/2006/12/01/getting-started-with-personalization-in-moss-2007.aspx

http://rehmangul.wordpress.com/2007/01/22/personalization-in-moss-2007/

All of these links had some good suggestions - all of them suggesting somewhere that a full import was needed to make sure that distribution lists were imported.

We went to ran a full import and we got ERRORS! This is where we discovered something very interesting. In our company our active directory settings are managed like so:

FQDN:   int.company.com

AD DOMAIN NAME: COMPANY

Most companies would normally just have a situation like this:

FQDN: company.com

AD DOMAIN NAME: COMPANY

When the SSP for SharePoint was set up, an Import connection for the User Profile was automatically created. However, in our case, the domain it set up was called "INT" instead of "COMPANY". SHAREPOINT PARSES THE FQDN AND USES THE FIRST PART UP TO THE FIRST DOT. LOL.

Therefore, every time we tried to do a User Import from AD, we got ourselves an error that "No domain existed for that name".

The Fix

  • To fix the problem, simply recreate the Import Connection. This is REALLY SIMPLE.
  • To get to the Connections: Shared Services -> User Profile and Properties -> View Import Connections.
  • Create a new connection
  • For the name, use the actual domain name "COMPANY" instead of "INT" <or whatever your first part of your FQDN is> and use Auto Fill Root Search Base to pull the search base LDAP query string out.
  • Return to Manage Connections
  • Delete the other Connection
  • Return to User Profile and Properties
  • Start Full Import
  • View the log. There should be entries in there for PEOPLE_IMPORT and PEOPLE_DL_IMPORT.

Once you've done this.... Audiences should allow you to add any Distribution Lists and have the latest information from active directory. In large organizations, be careful. You might want to limit your query much more. One of the links above has information about reducing your crawl of AD.

Happy DL'ing.

Wednesday, November 7, 2007

Configuring MOSS as a Search Appliance with Keywords and Best Bets against a non-MOSS source

I have been working on a client project that involves replacing a SharePoint Portal Server 2003 Search solution with MOSS. One of the great things we sold to the client including the ability to do tuning on the searches using Keywords, Synonyms and Best Bets. However, when I started to look into this, it wasn't readily apparent how to accomplish this. I was concerned at a time that once we'd sold this functionality, I'd have to build a synonym engine and best bets because there is no configuration at the SSP level for Keywords & Best Bets.

As I looked around the net, no one seemed to have the answer either. I pinged some experts and they said "let me know when you find out". One expert showed how to configure keywords programmatically however it pointed at a site collection. This got me thinking and led me to the solution. If this was obvious to you, then this post is not for you.

To set up MOSS as a search appliance against your existing web site (in this case, a MCMS 2002 web site), you'll need to go through and set up your SSP and a source.

  1. Set up Microsoft Office SharePoint Server.
  2. Set up a Shared Service Provider site within MOSS. Make sure that all of the search technologies are turned on.
  3. Create a content source. In the content source, fill in the address to start from for the search of non-MOSS content.
  4. Create a scope so that you can specify just your desired content in the Web Service Search Query. Call it something like "MyScope" which I'll use for my example.
  5. Finally, you'll need to go back to Central Admin and create a site collection. THE SITE COLLECTION YOU CREATE IS WHERE YOU WILL CONFIGURE KEYWORDS/BEST BETS and will also be the URL USED FOR THE WEB REFERENCE OF THE WEB SERVICES.
  6. Go your new site collection -> site settings. Let's say that location is actually http://mymosssite:80.
  7. Under "Site Collection Administration", go to scopes and make sure your scope shows up. If it doesn't you didn't configure it for "Shared" or under your specific site collection.
  8. Under "Site Collection Administration", you can now configure keywords, synonyms and best bets under "Search Keywords"

To test all of this, you can use the "SharePoint Query Web Service Test Tool". This tool can be found here. This is an example of the tool below:

sharepointwstesttool500 

So, for our scenario here's the configuration of the tool to test out if its working:

  1. Click the MOSS button in the tool
  2. Click the SQL button right after
  3. Configure the URL. This URL will be the URL of the SITE COLLECTION you set up with keywords and best bets --- NOT THE SSP location. This is very important because keywords and best bets are bound to the site collection and not the SSP. An example URL based on above will be http://mymosssite:80/_vti_bin/search.asmx.
  4. Make sure "Include Relevance Results" and "Include Special Terms Results" are chosen.
  5. Then you can test it out (assuming you've created keywords, synonyms and best bets) by writing an Enterprise Search SQL Query. Here's an example for a phrase like "windows vista":
    select path from scope() where "scope"='MyScope' and FREETEXT('windows vista')
    Once you have the Query entered in the Query Text text box, you'll need to generate the request XML. Click "Build Request XML". You should see the XML created.
  6. Finally, click the "QueryEx" button. It should generate a table of results. To see your best bets, change the result type to "SpecialTermResults"

If you get back what you expected, you've gotten far! Now you'll obviously want to configure this as a part of your site... i.e., use the search web service. For this part, I'm going to point you at the SDK because it has all the code snippets you need.

In addition, Patrick Tisseghem has a wonderful chapter on using the Search Web Service in his book Inside Microsoft Office SharePoint Server 2007 by Microsoft Press.

51Oa29pDNrL._AA240_

Good luck with your search endeavors! Thanks to Stefan Goßner who gave me some good ideas on this whether he knows it or not.