Skip to main content

Cloud

TechEd – Tuesday

MOSS Search, InfoPath, and more SharePoint were on tap today. Here’s some highlights.
Search is one of the most powerful features of MOSS, but as a developer -even one with a ton of MOSS experience, thank you very much – it isn’t something I’ve spent too much time working with. It was great to get some exposure and advice on search configuration today.
Here’s the configuration basics as I understand it now – if anyone finds anything that needs correction, please leave a comment! The two key server roles in search are Indexer and Query. The Indexer creates the index, and the Query consumes it. With WSS, both roles live on the same box; with MOSS, you can split the Indexer from the Query server. If you do split them, the Index server must be dedicated – no other SharePoint services can run on it.
You can have multiple search servers in WSS, although each of your content DB’s can only connect to a single search server. This means that the search servers are not redundant, so this won’t improve availability. With MOSS, your search servers can connect to multiple content DB’s, so the redundancy improves availablity.
Some suggestions to improve performance include using 64 bit servers, separating the Query service from the WFE’s, and using dedicated load-balanced WFE’s. Optimizations to consider include the crawl, authoritative/demoted pages, weight of properties, the ranking formula, and managing metadata – for example, Title and Author are important fields for search, so consider making them required.
On to InfoPath. Did you know there’s an importer for Word and Excel documents? I didn’t, and I still haven’t tried it, but from the demo it looks like they may be useful to help convert existing paper forms into InfoPath. At least they’ll give you a start.
I’ve been pretty proud of some of the managed code I’ve written for InfoPath 2007 forms, but now I’m told it’s better to avoid managed code in InfoPath wherever possible – especially in On_Load. There’s still a place for it, but only when necessary. If you have a ton of managed code, consider skipping InfoPath in favor of a custom application.
Adding your InfoPath form to an ASPX page is farily straightforward. Just publish your form to a Forms Server (like SharePoint) and build an ASPX page with the XMLFormView control.
I also attended some discussions on MOSS implementations. One centered around using MOSS as a platform for building applications, something I guess we’ve been doing on our document management system project whether I realized it or not. People have encountered some common challenges, and I was very happy to realize that we did a pretty darn good job in resolving them.
Another good day – 3 more to go!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.