Key characteristics describe environmental factors, usage characteristics, and other considerations that are likely to be found in deployments based on this scenario. The key characteristics for this scenario include: User response times : Target user response times for common, uncommon, long-running, and rare operations are listed ...
By default, Search Services can crawl and filter a file with a size of up to 16 megabytes (MB). It will always crawl the first 16MB of a file. After this limit is reached, SharePoint Portal Server enters a warning in the gatherer log “The file reached the maximum download limit. Check that the full text of the document can be meaningfully crawled.” To increase the limit of 16 MB, you must add in the registry new entry MaxDownloadSize. To do this, follow these steps: Start Registry Editor (Regedit.exe). Locate the following key in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager Open Edit - New - DWORD Value. Name it MaxDownloadSize.
Here is a quick list of blog postings with introductory text by Joel Oleson. Why WSS 3.0 x64 and MOSS 2007 x64... What's the deal? Well the MOSS 2007 x64 downloads are available via MSDN and MVLS. On MSDN, the ISO contains both x86 and x64. The WSS x64 is on download center. Just last week I think I was asked when to use x64 over x86 at least 3-4 times. First off, there is no difference as far as features go. The feature set is exactly the same. The install is not different, just the fact that you should have already installed Windows Server 2003 x64 and the x64 of the .Net Framework 3.0 (X64 Redist Package). I did a post on why upgrade to SQL 2005 when it began to be supported with WSS 2.0 SP2 and SPS 2003 SP2... Resources and Recommendations for Upgrading Site Definitions and Site Templates This topic has come up more times than I can count. This is one of those sticky topics that IT Pros seem to have a hard time with. See the TechNet reference for how to handle customizations and you can see that it can't be handled at that layer for most deployments. There is one good light reference on TechNet for upgrading Site Definitions with references to the mapping files and upgrade definitions, but the MSDN/SDK goes into much more detail (links below). It's understandable since the development that was done on the platform has got them to this position, but most won't want to simply start over... Relationship between the IIS Metabase and SharePoint Configuration Database In SPS 2003 and WSS 2.0 the metabase stores the entire configuration for the IIS Web Site (IIS virtual server/IIS Web Application). In MOSS 2007 and WSS 3.0 this is true as well, but there are some slight differences that you should be aware of. The configuration database cares about all the databases used, all of the IIS Web Sites/Web Applications, solutions, web part packages, site templates, web application and farm settings specific to SharePoint technologies (like default quota, blocked file types, antivirus configuration, etc...) and many that are as well listed in the IIS metabase (such as host header configuration, SSL enabled, authentication, and ports)...
If you have a farm with 3 or more servers, you can configure a dedicated WFE for crawling, in a sense, imagine how much more efficient it would be to simply have your index server be a web front end as well. By saying that this server, the Index/WFE is then it can hit the web service locally to index the content thus reducing unnecessary network traffic. That's all and good but there are some issues. Daniel Webster has a very good write up on MOSS 2007 search issues you might have after dedicatiing a web front end for crawling. Here is a snippet: In Central Administration > Operations > Services on Server > Office SharePoint Server Search Service Settings, you may select one Web Front End (WFE) as the only one used by the index server during crawls. This sounds like a fine option when you have multiple WFEs in production and you want to reserve one for the index server to crawl so that the overhead is limited to one server. In a small farm, one would not normally change from the default selection above. However, on our small farm someone selected the second option and indexing failed. Error messages begin to appear in the crawl logs. When we pinged the sites to see if they were reachable from the index server, strange IP addresses responded. Since these addresses were not in DNS, we examined the HOSTS file. This revealed a undocumented SharePoint Search process. What happened, you ask? First, let’s discuss the logic. If you have multiple WFEs and you want to dedicate one of them for crawling, obviously the index server must be able to find the appropriate web sites on the dedicated WFE because the UI only specifies the farm member name. One might think that it would simply use DNS. However, DNS will resolve the target web sites to the production addresses. So a process was added to modify the HOSTS file on the index server which adds an entry for each web site to be crawled using the IP address of the WFE selected.
Joel Oleson just put up his list of Top 25 Tips to Lockdown your SharePoint Environment. Here are his top 5 security tips: Configure Firewall Rules Secure client communication with trusted SSL certificates Use IPSEC Require mode between servers Enable Kerberos Authentication SQL SSL encrypted Traffic Click here to get the full list ...
You may have noticed (maybe not) that SSP Timer Jobs such as user profile imports and audience builds, are not included in Central Administration --> Operations --> Timer Jobs Status/Definitions. You will notice 1 or more Shared Services Timer Jobs, 1 for each SSP in the farm. While you can disable the service as a whole, you cannot reset or clear timer jobs for an SSP individually. To accomplish this, run from the 12 Hive/bin directory:
Andrew Connell, our favorite blogger for 2006 has posted another excellent article on Creating your own Timer Jobs in MOSS. Here is a snippet of his post: Addressing this issue, Microsoft has added something called Timer ...