Archive for the ‘SharePoint’ Category

SharePoint Diagnostics Tool
SharePoint diagnostics tool has just been released. It collects a lot of data about the sharepoint farm and provides a unified place to troubleshoot issues. It gathers information from performance counters, IIS logs, SharePoint logs, WMI, etc..
It is released as part of the sharepoint administration toolkit v3.0 downloadable here (http://www.microsoft.com/downloads/details.aspx?FamilyID=412a9ef1-3358-4420-b820-0ca3f4641651&displaylang=en)

Read Full Post »

Understanding SharePoint inter-farm communications: http://blogs.msdn.com/uksharepoint/archive/2009/01/05/sharepoint-ports-proxies-and-protocols-an-overview-of-farm-communications.aspx

The right and wrong ways to iterate through SharePoint List items: http://blog.dynatrace.com/2009/01/11/the-wrong-way-to-iterate-through-sharepoint-splist-items/

Read Full Post »

Application Lifecycle Management Resource Center for SharePoint Server : http://msdn.microsoft.com/en-us/office/cc990283.aspx

There you can find answers about (reference: http://blogs.msdn.com/pandrew/archive/2009/02/01/sharepoint-development-and-application-lifecycle-management.aspx)

  • Team Development
  • Source Code Control
  • Automated Builds
  • Continuous Integration
  • Build Testing
  • Unit Testing and Test Driven Development
  • Solution Versioning

Read Full Post »

Reserved SharePoint Query string IDs (FeatureId, ListTemplate, List, ID, VersionNo, ContentTypeId, RootFolder, View, FolderCTID, Mode, Type) : http://blogs.technet.com/stefan_gossner/archive/2009/01/30/querystring-parameters-you-should-not-use-in-your-sharepoint-application.aspx

SharePoint Dispose check tool, this tool will analyze assemblies that deal with SharePoint and tried to identify if all SharePoint objects used are correctly disposed: http://code.msdn.microsoft.com/SPDisposeCheck

Read Full Post »

The conventional wisdom for moving a SharePoint site collection between farms is to backup the site collection using the stadm -o backup on the source server and then use stsadm -o restore on the destination server.

This approach is very neat and straight forward and works very well in most cases. The problem is with large site collections ( starting from a few GBs); with sizes in the GBs, this process might takes a very long time.

An alternative and much quicker way to backup and restore a site collection is using SQL Server backup and restore for the content database. SQL Server backup restore is way faster than stsadm backup/restore for large site collections.

Here are the steps needed:

  1. Identify the content database for the site collection. (in case you are not sure, check central administration->applications management-> content databases).
  2. From SQL server, backup this database and restore it to a new database.
  3. On the destination server, create a new site collection using the same template. As a result, a content database for the newly created site collection is created. ( note its name as we will delete it later from SQL server)
  4. On the destination server, go to central administration -> application management, content databases, Select the site collection and then select the existing database and remove it. Now the site collection has no content database.
  5. go to command line and use the command stsadm -o addcontentdb to attach the restored database to the site collection.
  6. Bingo ! ( in a fraction of the time needed for stsadm backup/restore)


  • You must first remove the existing content database before adding a new one. This is because it seems that SharePoint is looking for the top level site on that one and you must delete it first to force it to look for the top level site in the newly attached database.
  • Trying to simply restore the database over the one just created by SharePoint with the creation of the new site collection will not work.

Read Full Post »

« Newer Posts