Development Environment

SharePoint development environment configuration depends on the processes, type of engagements and type of work. The most popular solution that addresses the development scenarios is using local SharePoint farm, separated from the production servers, with the single installations of the SharePoint server on the development boxes. This provides isolation for builds, tests, and debugging across different teams, projects and production environments. The local environment is mostly isolated by development box and is installed on the host server or on virtual server. The following procedure is an overview of the steps that are required to create a typical SharePoint development environment.

Development Box installation

• Use Windows Server, Visual Studio, and SQL Server. Windows Server 2008, VS 2008 and .NET 3.5, SQL 2008, with TFS 2008 is officially supported environment for SharePoint development. Advantage of Windows 2008 is that it is fast in virtualized environments.
• Install SharePoint on development boxes and prefer not to connect to existed farm instances used on other stages. Development environment should stay apart, to develop and tests in isolated environment.

Chose development tools

There are varieties of tools that can make development fast and easy – from commercial to open source and Microsoft products.

Microsoft recommends to use “Visual Studio extensions for Windows SharePoint Services” (VSeWSS), which simplify code-up solutions for SharePoint (e.g. Web Parts, List Definitions, Site Definitions, etc) via UI and allows reverse-engineering existed site to extract definitions for SharePoint entities.

The disadvantages of VSeWSS are:

1) not intuitive for beginners;
2) doesn’t provide usability to change all properties of the features, and other SharePoint items easily
3) Cannot use VSeWSS projects without VSeWSS extension.

Others 3-rd party tools, which simplify development, are:

1. Management Tools

• SharePoint Spy (http://www.echotechnology.com)
• SharePoint Manager (http://www.codeplex.com/spm)
• SharePoint Analyser (http://community.bamboosolutions.com)

These tools help to manage services of SharePoint farm and get detailed information about configuration settings.

For example, screenshots of SharePoint Analyzer (left) and SharePointSpy (right)

2. Visual Studio Tools

• STSDev to create project files (http://www.codeplex.com/stsdev)
• SPSource to get site sources (http://www.codeplex.com/spsource)

These tools create Visual Studio projects with the SharePoint 12-hive structure, and provide build settings to build/deploy/retract WSP packages directly from IDE. STSDev is the best tools to create a variety of projects – from simple features and Web Parts to Custom Workflow projects:

3. Development Tools

• TypeMock Isolator – Writing test for the SharePoint is a hard task for the developers, due to number of internal, sealed and private classes that are used across all SharePoint objects. ”TypeMock Isolator” is the only unit-testing and mocking framework for SharePoint, which provide ability to fake recursively, and simulate collection easily.
• SPDisposeCheck – tool to check assemblies that use the SharePoint API to build the better code. It provides assistance in correctly disposing of certain SharePoint objects to help following the best practice.

4. Other Tools

• U2U CAML Builder – editor for CAML queries (http://www.u2u.net)
• SharePoint Feature – set of different development and debugging plugins (http://www.codeplex.com/features)

Such tools give your additional flexibility in everyday development stuff, providing different editors, log viewers and analysers to make SharePoint development easier and faster.

Setup Deployment environment

Configure Continuous Integration (CI) system to build SharePoint solution, compile output to WSP packages, prepare deployment scripts and deploy WSP to Test Environment. Team Foundation Server (TFS) is one of the recommended tool for this task. There are several articles describing how to adopt SharePoint solution for CI, setup builds and configure TFS Deployer to deploy SharePoint packages across different environments:
http://www.azsharepointpros.com/ShareAndEnjoy/Lists/Posts/Post.aspx?ID=10

As to SharePoint Visual Studio Templates, CodePlex has a “SPTemplateLand” project that provides “12-hive” structure for SharePoint projects and deployments.
This solution was slightly modified by Microsoft SharePoint Consulting Services guys to have single deployment package for multiple projects and support packaging additional SharePoint Artefacts (site definitions, root files). This project is published there http://blogs.msdn.com/gderun/archive/2008/01/11/sharepoint-visual-studio-project-and-deployment-templates.aspx

Configure testing environment

The following diagram depicts the most common development environment, which is recommended by “SharePoint Guidance patterns & practices” team.

1. Stand-alone SharePoint environment for development, unit testing and debugging of SharePoint project. Runs continuous integration and builds verification tests before deploying the SharePoint solutions to the test environment.
2. Source Control/Build Server to build SharePoint packages (WSP) and to deploy solution to test environment.
3. The test environment performs user acceptance testing, manual functional testing, automated functional testing, system testing, security testing, and performance testing. After the solution meets production requirements, the SharePoint solutions are deployed to the staging environment.
4. The Staging server uses to test the “production-ready” solution in an environment that closely resembles the production environment. The purpose of this environment is to identify any potential deployment issues. Although the Staging environment is optional for smaller applications where deployment failures are not critical

The staging environment represents the target production environment as closely as possible from the perspective of topology (for example, the server farm and database structure) and components (for example, the inclusion of the Microsoft Active Directory service and load balancing, where applicable).

Installation

The recommended Windows environment that offers the best performance for SharePoint is to have 64-bit servers. Such an environment provides significantly larger address space than 32-bit one; more room for SharePoint assemblies, CLR/Native APIs, Network Stack, IIS/ASP.NET and other components hosted in their respective tiers.

Windows Server 2008 and SQL Server

SharePoint install on the Windows Server 2003 and 2008. The recommendation is to use Windows 2008 because it has the outmost security. For the Windows 2008 you need to activate the following roles: Web Server role and the Microsoft .NET Framework 3.5.

Take into account that Windows 2008 Web Edition is not supported for farm roles, except WFE boxes, due to restrictions of non-Web editions of SQL Server on Windows 2008 Web Edition. The release of “SQL Server 2008 Web Edition” extends usage of Windows 2008 Web Edition for SharePoint. Refer to licence regulations and SQL Server 2008 Web Edition info for more details: http://tinyurl.com/b8nype

Do not install SharePoint on Domain Controller box in virtualized environment. DC role of Windows 2008 limits performance of hard drive by turning off caching to provide AD consistency. Any installations on virtualized DC might not work properly.

SharePoint installation supports  SQL 2005 and 2008 Servers (even SQL Server 2000 is supported, but there are not much advantages of its usage). SQL Exress edition is supported as well, but for basic MOSS installation, however basic install of WSS 3.0 will use Windows Internal Database (WID doesn’t have size limitation). SharePoint installs only on SQL Server, but you can use BDC use content from 3-rd party databases.

A few advantages of SQL 2008 over SQL 2005 are in performance, encryption, clustering, mirroring and etc. Moreover, it provides updated SharePoint Web Parts for Reporting Services and KPI. Detailed information about SQL 2008 and SharePoint can be found in the following post http://tinyurl.com/cdkcyw.

User SQL Aliases

When provisioning a new SharePoint farm, it is highly recommended to use an alias to connect to the Microsoft SQL Server, as this provides for greater flexibility to move the SharePoint databases to a new server. For example, using an alias during the installation will simplify the migration process of SQL database server from small environment to larger physical cluster during scaling out process.

Install Microsoft Office 2007 on farm premises (optional)

Office 2007 is not required on SharePoint server, but it might be  good to have it somewhere in you farm premises (not server box) for administrators, especially when you outsource your support or/and admins connect  remotely. In this case they might  need client apps installed somewhere to have access to

• Word and Excel for documents in Document Library
• PowerPoint for Slides in Document Library
• Access for “Edit in Datasheet” support in Document Library

Consider the same for Office SharePoint Designer(SPD), which is necessary for customisation purposes. (SPD is a  free product with is distributed as separate product that is not include into Office)

Install all Windows Updates

Make sure that all servers have the latest service packs and updates for Windows, SQL and Office prior installing SharePoint.

Choose the right edition of SharePoint

Be careful when use Enterprise edition of SharePoint, because Microsoft doesn’t provide the support if you decided to downgrade to Standard version, due to loss in features and functionalities. If you need Standard edition then consider a fresh installation.

Install SharePoint

Install SharePoint across all servers in farm. Start with WSS/MOSS slipstream package (with integrated latest Service Pack) rather then using basic WSS/MOSS installation and applying Service Pack later.

Follow the next order of installation:

• Application server where Central Administration site will be hosted
• All front-end Web servers
• The index server (if using a separate server for search queries and indexing)
• The query servers, if separate from the WFE servers
• Other application servers (optional)

Consider using scripts to automate SharePoint installation and configuration for the large farm deployment. SharePoint provides several configuration files and console commands that will do all deployment un-attendant. This will speed up installation and brings consistency of building and rebuilding servers in farm.

There are three commands to automate SharePoint installation:

• SharePoint Setup.exe + Config.xml – to script the setup questions
• PSconfig.exe – to script configuration wizard
• STSADM.exe – to script central admin UI for creating web apps and site collections

Alternative solution is to use already preconfigured Power Shell scripts. “SharePoint Deploy” tool on CodePlex provides the configured scripts for the standard installation, which can be adapted to any environments.

Refer to the following documentation for details about unattended installation http://go.microsoft.com/fwlink/?LinkID=135694&clcid=0×409, and info about installations scripting http://technet.microsoft.com/en-us/library/dd335964.aspx.

Take into account that SharePoint does not uninstall properly and additional steps are required to clean remaining files and remove database tables, which are kept for the security reasons (http://nehasinha.wordpress.com/2008/02/01/uninstalling-moss-2007-manually). It might be better to reinstall everything from the scratch if something went wrong, including Windows Server – because it will save a lot of time trying to fix potential issues that might be caused by files from the previous installation. In this scenario, using virtualization and snapshots feature saves a lot of time.

Detailed information about SharePoint installation guidelines are published on TechNet http://go.microsoft.com/fwlink/?LinkId=106632

Check Office Web Service availability

Sometimes, SSL protocol of Office SharePoint Web Service is broken.  To test it, go to IIS Management Console and open SharePoint Office Web Service in browser via https://. If it doesn’t work – don’t process further till fix it. This is very critical stuff, because SharePoint roles cannot be assigned on other services in farm. (I’ve seen such issues across several clients, when you can’t use other boxes in farm and only Application boxes are available for Index and Query roles, because SSL was broken).

No known fix at this moment, except reinstalling SharePoint.

Install SharePoint updates

Install all SharePoint updates (Infrastructure Updates and/or Cumulative Patches) after farm is deployed. Check the release notes of the latest cumulative patch if it includes all previous patches and updates. Sometimes you need to install previous updates manually. Cumulative patch releases each 2 months. Follow the official documentation “Deploy software updates for Office SharePoint Server 2007” for the processes of how to deploy infrastructure update (WSS Upgrade needs to be installed first and only then MOSS upgrade).

Be careful with SharePoint hot fixes

There are several hot fixes, for example “Coreserver.msp” package, which are released after Cumulative Patch.  However, be careful with these fixes, because they are temporary solution before the next official update, and they are not properly tested. Install hot fixes for specific problems only.

Configuration

Enable SharePoint Features

Navigate to the Central Administration site and enable Enterprise SharePoint features, if necessary. The default settings is Standard features.

Assign roles to servers

Navigate to the Central Administration site and assign SharePoint roles across all farms servers, according the infrastructure design and topology.

Configure administrative tasks

Configure administrative tasks across servers, like email settings, blocked type, logging and etc. Setup SharePoint Shared Services and configure all related services like Search, Query, Application Services, Profiles and etc.

Disable “Central Administration” role

Navigate to the Central Administration site and disable “Central Administration” role for all servers in farm, except application servers. This action will disable “Central Administration” site and IIS won’t use additional resources to host this application.

Configure Warm-Up scripts

Install site “warm-up” scripts. Those scrips will compile each page of SharePoint site collections when box restarts or after IIS poor restarts. This script improves the response time when users request pages first time.

Those warm-up scrips use STADM command to “warm-up” the administrative interfaces and hit each page in the portal to force their JIT. The collection “warm-up” scripts available there http://blogs.msdn.com/joelo/archive/2006/08/13/697044.aspx

Recycle IIS application pool at different time

Make sure that the application pools are set to recycle at different times on different Web servers, in case of multiple Web servers in the farm.

Recycle different IIS Web sites at different times to avoid peaks on the Web servers. When recycling more than one application pool on a specific Web server at the same time, temporarily remove that Web server from the load balancer to avoid bad user experience.

Following these steps helps to install SharePoint and configure basis settings with the minimum amount of time and avoid most common pitfalls, which usually happens when SharePoint installs in the wrong order