SharePoint Project Series.

This is a series of blogs I am writing on SharePoint projects:

Part 1 - Design and Planning Part 2 - Implementation (Stage 1) Part 3 - Implementation (Stage 2)
Part 4 - Training Part 5 - Continued Support Part 6 - Suggested Continued Improvement

Tuesday, June 23, 2009

SharePoint Projects Part 2 – Implementation (Stage 1)

It has been a short while since the first part of the SharePoint Projects series, I have recently moved house and also found out that I am going to be a dad, so things have been fairly hectic to say the least. Now onto the good stuff: SharePoint project implementation. So far you have spent considerable time conducting a design/architecture phase with your client you both should have a 90% understanding of how the final solution is going to look. Due to the nature of business there will quiet often be ‘changes’ to the project, these will need to be gauged in relation to effort and charged accordingly. I will split this post into multiple headings to make referencing and reading easier:

Scope Variations

If you ever encounter a client that does not vary from the scope at all, continue doing projects for this client as these are the best kind of clients you can find. Indecisiveness is unfortunately part of human behaviour and there is not a lot that can be done about it. Business decisions may be varied by internal change and occasional bureaucratic power struggles and therefore can have negative impacts on your project. A vital project management skill is gauging when to and not to charge for these scope variations. Examples:

  • “We would like to add another Web Front End to the server farm as we can now afford the licence for it” – This would be a chargeable variation to the scope as it involves implementation of another server farm and potential re-architecture of the original solution depending on service assignment.
  • “We would like to change the banner on the home page to this new [supplied image] instead of this old [supplied image]” – This is obviously a non chargeable variation of scope as the work effort involved is negligible.

At the end of the day the decision is up to you. Just remember to be ethical with all your decisions you make.


A strategy to cope with fussy clients and also an important risk reduction strategy is to incorporate a ‘buffer’ or contingency into quoted hours. The old rule I learnt with information technology from one of my old university professors was that you would estimate the time it would take to complete a particular task and you triple it. For instance if you believe it would take you 30 minutes to configure search indexing and crawls it is probably a good idea to quote 1.5 hours instead. Now this is obviously a fairly generalized rule and by now you should have a fair understanding of how long a task may take, it is always a good idea to add some kind of buffer into your quotes. In a later part to this series I will go through some of my usual estimates for both WSS 3.0 and MOSS deployments.

Automated Scripts vs Manual Deployment

Scripting is something I have recently embraced and find it to be a fairly powerful ally. There is a fairly rational relationship between viability and deployment size I find. For instance if you have a single or twin server farm with WSS 3.0 or MOSS 2007 it may not always be the best option to deploy using scripts. On the other hand if you have a larger multi user farm with multiple environments for development, testing and production it may be viable to use scripts to deploy your environments. Bear in mind that scripts and associated documentation would count as a deliverable.


SharePoint farm methodology would denote that it is often a requirement to deploy corresponding farm environments for development, test and production. This methodology is relevant when there is going to be significant modification or development conducted to the solution. As mentioned before this development would be best suited in a separate project, however it must be planned for during your solution architecture.

Development Environment

The configuration of this farm is debatable. Some people will argue that this environment should mirror production as much as possible, however I believe that you would only need to replicate ‘hops’ in your production. By that I mean if you have a production which consists of 2 app servers, 3 web front ends and a database server, the development environment corresponding to this production environment would ideally be 1 app server, 1 web front end and a database server. It is not uncommon to use a single server development environment and any environmental issues that may result from this will be exposed within the test environment.

Test Environment

The test environment should be an exact mirror of the production environment. Data should also be replicated from production to test on a regular basis.

Production Environment

This is your live environment. No development is to be conducted at this level.

Implementation Stages

  1. Prerequisites Domain Controller
    1. DNS Entries created for all web applications and servers
    2. Active directory accounts created for SharePoint services (Accounts I commonly use)
  2. Prerequisites SharePoint Servers
    1. Application Server Role
    2. .NET Framework 3.0 minimum (3.5 SP1 recommended)
    3. Enabled ASP.NET 2.0 within IIS
    4. Configured SMTP service
  3. SQL Installation on SQL Server
  4. Permissions configured on SharePoint and SQL servers
  5. MOSS 2007 installation or WSS 3.0 installation
  6. If multiple server farm start with Farm Creation on Application (Central Admin) server.
  7. Initial configuration:
    • Incoming and Outgoing email settings
    • Establish Web Application for Central Admin Identity Account (usually same as farm service account)
    • Configure DCOM permissions (will be covered in future post)
  8. Diagnostic Logging
  9. Web Application General Settings

MOSS Only Configuration

  1. Create separate SSP and Mysites web applications
  2. Create SSP
  3. Configure Search, User Profile, InfoPath and Excel services
  4. Advanced Usage analysis processing
  5. Single Sign On (optional)

There are occasionally other configuration stages required depending on architecture of solution.

To be continued…

Thursday, June 18, 2009

Security Service Accounts

For both WSS and MOSS I like to use the least privileged account methodology for all my deployments. This is considered Microsoft best Practice.



SP_AdminSharePoint set up account, used to install SharePoint. Local administrator on web front end. DB Creator on SQL.
SP_FarmSharePoint Farm service account. DB Creator and Security Admin on SQL. Also used as the Central Admin application pool identity.
SP_WssSearchWSS search Account.
SP_MossSearchMOSS Search service Account.
SP_ContentSharePoint Content Crawl Account.
SP_ProfileUser profile import account.
SP_SSPAppPoolApplication pool identity for Shared Services Provider
SP_PortalAppPoolApplication pool identity for Portal web application.
SP_MyAppPoolApplication pool identity for Mysites web application.
SP_ExcelExcel Services service account.
SP_SSOSingle Sign On service account.

Above is a general guide of what I use when deploying WSS and MOSS environments. Some of the above accounts are not needed for WSS.

Friday, June 12, 2009

Well I'm Convinced

I have been using it now for just over two weeks and I love it. It's something fresh and although the relevance on certain keywords are not the same, I have adapted my keyword choices to suit. Bing is definitely worth giving a shot.

Since my ninemsn page is my homepage i just use it from there. I used to type a lot of 'questions' in google, however I find in Bing instead of typing 'what is the capital of France' I would just type 'France Capital' and get better relevance. Obviously in this extremely generalised example it wouldn't make too much of a difference, but hopefully you get the idea.

Go ahead and bing away! Fantastic integration with your live account also.

Im predicting we will see some hot integretion with version next of SharePoint! exciting stuff.