Bill Baer /bɛːr/

Skip to main content

Banner

 
Bill Baer /bɛːr/
Bill Baer is a Senior Product Manager for Microsoft 365 at Microsoft in Redmond, Washington.

Bill Baer /bɛːr/

Posts

This post is a continuation on previous SharePoint Portal Server 2003 performace recommendations and details basic steps to improve the overall full-text search queries for large database tables. The steps detailed are most applicable to enterprise deployments and/or large databases with a large number of unique full-text index words. The steps detailed below should be applied to each back-end SQL server(s). This problem occurs frequently if the total size of all the catalog files exceeds 256 megabytes (MB).
I recently came across an issue with a customer that uses large files in WSS, notably, .CAD files; as a result these files were either - one, not indexed or two, indexing did not gather the required information from the file to provide useful search criteria. To remidy the issue MaxDownloadSize was increased to 64MB while leaving the MaxGrowFactor at 4, this will essentially permit the index filter to produce up to 256MB (64 x 4) of text from a given file, the default setting in SPS is 16MB MaxDownloadSize and 4 MaxGrowFactor, limiting the index filter to 64MB max.
Try IE7 - http://www.microsoft.com/windows/ie/ie7/default.mspx - dynamic security protection, tabbed browsing, streamlined user interface, printing advances, instant RSS feeds, toolbar search box and more…

SharePoint Portal Server 2003 Service Pack 2, by default, will disable some features previously distributed in service pack 1; this article will key in on feaures specific to search and indexing recommendations to improve crawl performance post-service pack 2 and correct features disabled in service pack 2. Prevent the indexer from enumerating local groups on WSS crawled content.

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following registry subkey:
Typically there is no real impact in the event a user profile is removed from the SharePoint profiles database; the profile will be restored during a full or incremental import. Though the statement is true for the most part when only considering Windows SharePoint Services sites, the behavior varies considerable when including My Site sites in the scenario. Since Windows SharePoint Services content is stored as a table in the sites database, the content can be easily recovered and archived; however, though My Site/Personal site content is similar in this respect many of the end-user facing customization exists as a shared service within SharePoint Portal Server.
I recently posted an article detailing how the Content Editor Web Part can be leveraged to display a menu based on the SELECT element, using hypertext markup and javascript to render hyperlinks in a manner that maximizes Windows SharePoint Services real-estate and promotes a positive user experience. Several requests and questions I received as a result of this post were whether or not the hyperlinks in the Content Editor Web Part could be harvested from a List.
  • I haven’t revisted this post in awhile and thought I would include some additional information on the topic; in response to dkbobe’s questions surrounding updating the user information; you can use the SPUserUtility to update the tp_Login column to reflect the new domain - more information on this tool can be found at Keith Richie’s blog @ http://blogs.msdn.com/krichie. I was pleased to see my mention in Joel Oleson’s SharePoint Blog on the Impacts of Renaming a Resource Forest on SharePoint Servers; I’m hoping to elaborate more here as there is little documentation on this topic; at least from the perspective of impacts to SharePoint services.
Skip to footer

Social Links