I had the FAST Search server 2010, SharePoint 2010 and SQL Server 2008 R2 installed on a single demo machine. Though this is not something which Microsoft recommends, it was very important when you visit clients for showing a demo showcasing the capacity of FAST.
When I tried to verify the memory and CPU consumption in the Task Manager, it did not took a long time to understand that the SQL Server and a FAST Search Server exe was one of the major culprits in bringing the system down on many of the occasions.
It appeared that continuously adding managed properties continuously across all the demos was leading to a continuous update in the index for the properties, which led to a high memory and CPU usage.
To overcome this, you should perform the following steps:
This should handle most of the issues related with high CPU and memory usage.
I had created a SharePoint 2010 Web Part which was using the ASP.NET List view. The code compiled fine and was deployed properly. However, when I was trying to add the web part to the Web part page, I was getting the following error:
Open the web.config and add the following entry in <Controls>
<add tagPrefix=”asp” namespace=”System.Web.UI.WebControls” assembly=”System.Web.Extensions, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35″/>
The limitation of indexing Files greater than 16 MB in size still exists in SharePoint 2010. The limitation was enforced to avoid network clogging and improve SharePoint performance.
In all such scenarios, where the file format is Compatible to SharePoint and the size of the file is larger than the max threshold size, the indexer is able to index the metadata of the file. however, the content of the file is not indexed.
For all files which are smaller than 16 MB in size and the file format is compatible to SharePoint, the content as well as the metadata of the file is indexed.
The major problem is that in SharePoint 2007, all such scenarios where the File Size was greater than 16 MB, were logged in as warning in the Crawl logs. However, there is no such warning generated in case of SharePoint 2010 and hence it is very difficult to understand the issue.
This whole behavior is guided by two registry values:
By default , the MaxDownloadSize is 16 MB and the MaxGrowthFactor is 4 MB in Size. This basically implies that:
Before SharePoint 2010, this settings were modified by modifying the registry information at
HKEY_LOCAL_MACHINE -> SOFTWARE –> Microsoft –> Office Server -> 12.0 –> Search –> Global –> Gathering Manager
However for some reasons these settings don’t persist when applied in SharePoint 2010 environment. you need to alter the settings using the PowerShell.
The max value supported by “MaxDownloadSize” is 2 GB.
The solutions developed in VSeWSS extensions are not directly portable into Visual Studio 2010.
To Run the VSeWSS Projects in Visual Studio 2010, an import tool has been released in MSDN which helps in executing the VseWSS Projects. This tool gets installed as a Visual Studio 2010 add in and provides a new SharePoint Project Template .
The tool is available at the following location:
All the discussions related with this tool is available at
During an in place upgrade process, the entire SharePoint 2007 box is upgraded to SharePoint 2010. The up gradation process upgrades the entire SharePoint 2007 installation.
For upgrading a SharePoint standalone installation, the process is as follows:
There are many types of migration opportunities available for migrating to Sharepoint 2010:
1. Migrate from Sharepoint 2003 to Sharepoint 2010
2. Migrate from Sharepoint 2007 to Sharepoint 2010
3. Migrate from other content management systems to Sharepoint 2010
There are many approaches of migrating from older version of sharepoint to sharepoint 2010.
1. In-Place Upgrade
2. Gradual Upgrade
3. Database migration (advanced)
4. Site and List Definition upgrade
However, till date there is no such pre defined approach for migrating to Sharepoint 2010. It mostly depends on the judgment of the administrator who is migrating the sharepoint site.
Feasibility verification for migrating to Sharepoint 2010
To understand the feasibility of migration, we can take the help of steam command. This command generates a HTML report for the same.
stsadm -o preupgradecheck
-[rulefiles <rule file>]
This command was first introduced with wss 3.0 sp2. This command is intended to run a set of rules that will assist the administrators to prepare the existing sharepoint 2007 installation to a future sharepoint 2010 version.
The parameter –rulefiles takes a valid rule file and is an optional parameter. It requires a quoted, delimited (comma or semicolon) list of rule file names. By default this command is run for all the available rule files. The rule files are available in the 12 hive\config\preupgradecheck folder.
The parameter –listrulefiles lists all rule files without executing the check routine. This is also an optional parameter.
The parameter –localonly is a required parameter and checks the local server with the rules marked as local only and evaluates them.
Once you run this command it creates a tmpdb_preupgradecheck_guid and stores all the analysis information over there before flushing out the information in the xml and html reports.
After the reports are generated and the command is completed, the databases are deleted by themselves.
Once the command is run, it generates an xml and html based report to guide you deeper in understanding the approaches for migration. It generates 3 files namely
What if any check fails
You can check the microsoft knowledgebase for corrective actions.