Archive for the ‘Sharepoint’ Category

You’ve got the Lotus Notes connector in FAST configured – now what?

November 2nd, 2011 2 comments

A few lessons learned from implementing the Lotus Notes connector in FAST Search for SharePoint 2010

I found that the basic instructions from Microsoft were fine in setting this all up, but getting it to look nice and behave well was another matter. Here are the documents I referenced for the basic configuration:

  1. Basic Configuration – install the Notes client and JRE
  2. Set up the Extended Directory Catalog
  3. Configure the Security Connector. Make note of that warning in the middle. The user that runs the security and content updates must also be the one who encodes the password. This will typically be the FAST search service account.
  4. Configure the Content Connector
  5. Enable Authorization for Security Trimming

The Extended Directory Catalog

Start by making this catalog out of the pubnames.ntf template, not dircat.ntf, as you would expect. If you use the latter, the security connector can’t connect to it and extract the user information.

In the Extended Directory Catalog document, leave the ‘Additional fields…’ field blank. The fields it pulls in by default are more than adequate for this job. In my document I have ‘Remove duplicate users’ set to Yes, group types set to ‘Mail and Multipurpose’ (since I’m pulling in info from other domains, I can’t use ‘first directory only’), Incluce Mail-in Databases and Include Servers is set to No.

If you ever need to rebuild the Directory Catalog contents, just issue the following commands:

tell dircat q

load dircat dircat.nsf -r

When those commands are done, type ‘load dircat’ to re-enable scheduled background updates.

Scheduling Updates
Follow the instructions here to schedule updates using the task scheduler on the FAST administrative server.

That article does not cover the security update, but it’s similar. You’ll need to create two tasks in the task scheduler for this item. The first one will look like this:

Program/script: C:\FASTSearch\bin\lotusnotessecurity.bat
Add arguments: start -f ..\etc\DominoSecurityConfig.xml
Start in: C:\FASTSearch\bin

The second one needs to call the script below, stored in a command file

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe " & 'E:\FASTSearch\tasks\UpdateSecurity.ps1' "

UpdateSecurity.ps1 will look like this:

Add-PSSnapin AdminSnapIn

Add-PSSnapin Microsoft.FASTSearch.PowerShell

$FASTSEARCH = [environment]::GetEnvironmentVariable("FASTSEARCH","Machine")

$path = Join-Path -path $FASTSEARCH -childPath "bin"

$envpath = Join-Path -path $FASTSEARCH -childpath "etc"

Update-FormatData -AppendPath "$envpath\FASTSearch.Format.ps1xml"

cd $path


# Uncomment these next two if security trimming won't get in synch

# While you run these commands, FAST will not return results from Domino

# searches, even for anonymous content

# Remove-FASTSearchSecurityAliaser -Identity win2lnx -Confirm:$False

# New-FASTSearchSecurityXMLAliaser -id win2lnx -InputUserStoreId win -OutputUserStoreIds lnx -InputPropertyName '$PRINCIPAL_REFERENCE_ALIAS'

Set-FASTSearchSecurityXMLAliaser -id win2lnx -PathToXMLFile 'C:\FASTSearch\var\lotusnotesconnector\security\ssomapping.xml’

The last command is to take the ssomapping.xml file and upload it to the FAST security store.

Refiners are the items that appear in the left-hand column of the search results page. SharePoint and FAST can make the SharePoint URL’s appear just fine, but the Domino ones don’t show up because nothing is mapped to the managed property ‘sitename’ which is what appears in that column.

To fix this, we’ll use the FixedFields item in the Content Connector configuration document. In my case, I’m adding a new field called ‘dominoUrl’:


This will attach that field with that value to every entry that the content connector pulls in. You will need to clear the content store and reload it to make that happen. Map that new Lotus Notes crawled property to the managed property ‘sitename’. After that, do a full crawl of the FAST query and content sources.

Once that is done, the URL you inserted above will start to appear in search results on the left-hand side with a number next to it, denoting the number of hits that match that top-level URL.

Document Titles

One of the first things you notice in the Domino search results is that the document title is pretty flakey, even in documents that have an explicitly-defined title field. Sometimes it’s the title, more often than not it’s the name of the attachment on the document or, if there is none, simply the UID of the document. None of that looks pretty.

The property you want to display is really there, it’s just getting bumped in priority. To fix this, search for the managed property ‘Title’, and edit it. Find both of the items called ‘title(text)’ and move them to the top.

Search Scope

Using your Domino server as a search scope is pretty straightforward. It’s set up like any other scope, but I used Scope Rule Type of Web Address, then used the ‘Domain or subdomain’ option and entered the to-level URL without the HTTP; e.g., just

Categories: Sharepoint Tags:

Step by Step, how to propagate your MOSS index

December 5th, 2008 1 comment

Quite the head-scratcher this turned out to be. In my production SharePoint 2007 install, I have search turned on and my central admin box was doing the crawling as well as being the query server. In the interest of making things a bit more robust and scalable, I thought it best to have my web front ends be query servers as well.

[Note for those of you coming from Domino-land, like me: In Domino we go to each replica of a given application and build a full-text index. Not so with MOSS, as it’s a bit smarter than that: I can designate one server to do all the crawling for  a given SharePoint install (as well as external sites), then have the crawl server do a flat-file copy of the index files to designated query servers. In really big installations, you can have one or more servers doing the crawling, with one or more different servers doing the serving of those searches, or the ‘query’ function. I know, we can do that in Domino with the domain index as well, but that only really works with Notes clients. Working from a Domino-web-only perspective, I have to have this domain index created and maintained on each web server]

However, this is not as simple as just starting up Office Server Search on each WFE and checking off the query check box. This was the first problem I ran in to: If you have, as I had, a server set up both as Crawl and Query functions, the index will not propagate to the newly-designated Query servers until Query is disabled on the Crawl server. This will mean that for a time, search queries will not work if you have no other Query servers in your farm.

Once I figured out that, I apparently got bit by the proxy problem. I have a proxy server in my environment, and it is needed by us end-users to get to the Internet, but it isn’t needed by Sharepoint search, as all of the sites its crawling are internal. I had it enabled per the recommendation of one support tech, but my index files were still not propagating.

So, I had to disable it in two places: In the Central Admin GUI (Central Administration – Application Management – Search Service – Farm-Level Search Settings) and, oddly enough, I had log in to each of the servers in my farm (CA as well as all the WFE’s) and disable the proxy settings under Internet Options for the user profile associated with the MOSS service account. Seemed strange, but it sure did the trick.

So, in my case, here’s what worked:

  1. Make sure the proxy is disabled under Control Panel – Internet Options – Connections – LAN Settings for your MOSS service account on each server in the farm (though this setting on your SQL server shouldn’t matter)
  2. Make sure it is also disabled in the Farm-Level Search Settings above
  3. On your Crawl server, open the settings for Office SharePoint Server Search and make sure the box “Use this server for serving search queries” is UNchecked. If it is checked, uncheck it, then go to the Services control panel and restart the Office Server Search service. NOTE: make sure there is not a crawl going on at this time. Yes, you could use the stop/start links in the UI, but then you lose all your settings.
  4. For each of the servers you want to be a Query server, go to that server under Central Admin – Operations – Services on Server and select that server. Click on Office SharePoint Server Search and check off the ‘Use this server for serving search queries” box, then fill in the appropriate fields. Make sure the folder you designate to store the index flat files is on a volume with enough space.
  5. Back in Services on Server, click Start for Office SharePoint Server Search.
  6. Go to Shared Services Administration, SharedServices1 (where you are enabling search), click on Search Administration and check on the propagation status. You should also see files and folders under the folder you designated in Step 4, above.

That should do it. As always, YMMV, so you may need to call support

Categories: Sharepoint Tags:

Sharepoint Problems from Reboot

December 4th, 2008 No comments

Or, how I spent my Thanksgiving ‘vacation’.

In our environment, we have our Sharepoint servers using the Microsoft Rights Management Server SP2 for rights management of documents we post to certain libraries in Sharepoint. This has been working fine for months.

Last Monday night I rebooted the servers in futile attempt to get the External Collaboration Toolkit for Sharepoint installed (more on that later). This didn’t resolve that issue, but apparently caused a huge problem that ended up with me spending most of my weekend on the phone with Microsoft support. Numerous people wanted to head out of town for the Thanksgiving weekend here in the US, and had to update documents in a particular RM-enabled library; also, auditors needed to start uploading documents to a new RM-enabled library first thing Monday morning. So, Severity A ticket it is.

If you’ve called MS with a Sev A problem, you know you’re committed to being on the phone with them, or available by phone, 24×7 until the problem is resolved. Happy Thanksgiving!

Read more…

Categories: Sharepoint Tags:

SharePoint upgrades done

November 11th, 2008 No comments

Despite the lack of follow-up here Sunday night, I did finish the Sharepoint upgrades. For the most part, it went well, with some weird network hiccups. In trying to add the second WFE to the farm, behind the CSM, the networking wouldn’t take. Part of that process was giving both WFE’s all-new IP addresses. Worked fine on the original WFE, but not on the second one. We finally got that working Monday, though I had to re-install SP on that second server to get it to join the farm correctly.

Monday night I tested load-balancing, and found it worked great, as did fail-over, for all three sites it hosts. Also successfully re-installed Charts Plus 2.1 and licensed it for both servers.

Next up: Performace Point with SP1 on our development server.

Categories: Sharepoint Tags:

SharePoint upgrades and stuff tonight

November 9th, 2008 No comments

Here’s my task list:

Remove current WFE from from farm

Uninstall SharePoint

Re-install SharePoint on that server as a complete (not WFE-only) server so I can set it up as a query server.

Add it back in as a WFE in the farm

Add new server as additional WFE in the farm

Apply October cumulative updates and workflow update to all servers in production farm

Change IP addressing and put behind the CSM

Check everything, make sure bits still work: Custom pages, put the logo back, ChartsPlus

Categories: Sharepoint Tags:

Sharepoint tidbits

October 30th, 2008 No comments

Couple of things I found tonight:

From Stefan Gossner, the October Cumulative Update is out. You’ll need to have SP1, the Infrastructure Update, the August CU installed (though this is questionable), plus all the updates corresponding to those for any language packs you have installed, then apply that one. Kind of a pain, but it’s better than here-and-there software hotfixes they were doing before.

Of course, you do know how to create self-installing updates for any new servers you build, right?

  1. Copy the contents of the MOSS 2007 install CD to a file share. You will see there an empty folder called Updates
  2. Using the command line, extract the contents of each Service Pack 1 download (one for WSS, one for MOSS) to a separate folder (c:\temp\patchname.exe /extract:c:\temp\patchname)
  3. Do the same thing with the Infrastructure Updates (again WSS and MOSS), letting it overwrite any same-named files
  4. Then the same thing with the August, then October cumulative updates (one of each). Copy the resulting files to the Updates folder mentioned above.

Note that your mileage may vary, as I’m running on a 64-bit platform with no particular language packs.

Now, when you run Setup the installer will automatically pick up all the packages and install them for you.

Update: Some oddities – first, when you go to download these files, make sure you click on the text “Show hotfixes for all platforms and languages”, so you’ll see both the x86 and x64 versions of the hotfix, then choose the right one.

Also, the August CU is not needed. Not surprising, since that is the definition of a Cumulative Update.

From Bill English, a helpful hint – install the Office 2007 IFilters so you don’t need Office installed on your indexing machine.

I got a chance to meet Bill at the Mindsharp booth at the last Sharepoint conference here in Seattle. Great guy, really knows his stuff, and his book is highly recommended for all Sharepoint administrators.

Categories: Sharepoint Tags:

Moving the Sharepoint 2007 Index

October 30th, 2008 No comments

Despite other blog posts, and stuff to the contrary, I don’t think you can actually ‘move’ a Sharepoint index from one location on a server to another; e.g., in my case, from the C: drive (that was running out of room) to the D: drive. You can only change the index location settings, then build a new index. Plan on a little index downtime while this happens.

Here are the commands:

stsadm -o osearch -defaultindexlocation "D:\SPIndex"

If you are doing this on a query-only server, do

stsadm -o osearch -propogationlocation "D:\SPIndex"

If your server does both crawling and query serving, you can only use the former command; the latter will generate an error.

stsadm -o spsearch -farmcontenaccessaccount <accountname>
  -farmcontentaccesspassword <accesspassword> -indexlocation "D:\SPIndex"
stsadm -o editssp -sspadminsite http://sharepoint:2000/ssp/admin
  -indexlocation D:\SPIndex

This will update the relevant info for your shared service provider, which actually manages the crawl.

Next, go in to your shared services admin, click on Search Settings, then click on Content Sources and Crawl Schedules. Right-click on your content source, and choose “Stop Crawl”.

Go to the Services control panel and restart the Windows Sharepoint Services Search, as well as Office Sharepoint Services Search.

Go back to SS management, click on Search Settings, and ‘Reset all crawled content’, then click Reset Now to confirm.

Go back to Search Settings and confirm there are 0 items in the index. Then click Content Sources again, right-click on your content source, and choose “Start Crawl”.

Categories: Sharepoint Tags: