If you are planning to deploy a new SharePoint server or need to re-evaluate your server hardware because of performance issues then you need to get hold of this tool.
The tool requires "System Center Capacity Planner 2007" which you need to install first. System Center Capacity Planner 2007 can be downloaded from here. Basically you can run this on your desktop PC and does not require to be installed on a Windows Server environment. Then you'll need to download the SharePoint Capacity Planning Tool and install it.
With the tool installed you can effectively create a Capacity model for your deployment. One thing to note though is that this models should be taken into context around what your environment is capable of. Trying to support 1000~ users on an existing single server SQL back end which can't scale is of course not a good idea.
For example in my sample I am creating a sample deployment model to support 1000 users in an intranet scenario with Search and Indexing. There are two Branch offices with Heavy Collaboration. You can choose between Intranet collaboration and Internet Publishing.
You can also change the usage profiles to cater for a specific scenario. Then you can add what type of Hardware you are planning to purchase and create your deployment model. Once configured hit "Run Simulation". You will get a comprehensive model to help you plan your own deployment. From the data that I inputted I was expecting a 5 server farm topology with high availability via SQL server mirroring and the tool was spot on!
I highly recommend that if you are an IT Pro to give this tool a test drive before planning to buy and provision your SharePoint hardware. Of course you can run virtualisation based on these and you should in all cases run your own tests relative to what's capable on your existing platform. There is no excuse not to use this tool since this runs on XP/Vista and installing this takes like 5mins.
I have been a fan of deployment diagrams such as above for a long time. Basically deployment diagrams save your bacon when it comes to understanding your overall topology. These are easy to do using Visio and I have usually do one for each SharePoint deployments I have carried out previously.
Platform Hygiene and User Adoption
Unfortunately one of the hurdles to proper SharePoint usage and adoption lies on partly on how users perceive the reliability of the platform. One of the frequent points of frustration in most cases that I get called to is complaints from end users that connectivity to SharePoint is slow. This coupled with errors in login and how your servers have been deployed can make or break your expected business outcomes and adoption of SharePoint in your organisation.
So who is actually responsible for platform hygiene and what do I mean by it?
From actual real world scenarios I have seen that most organisations don't put much emphasis on getting their SharePoint deployment's QA'd for the technical implementation and only bring in experienced consultants when things go wrong. Which in turn reflects badly on SharePoint because users get the impression that SharePoint is buggy.
In my opinion you should ensure that you have an Install guide and a deployment guide with enough detail to determine what your end deployment is going to look like. Installing MOSS on a server where other applications are already running and configured will need to be taken into consideration before you start installing. I am a fan of using scripted installs of WSS/MOSS via PSCONFIG and the STSADM tool. In one of my previous posts I have highlighted about the issues of deploying SharePoint in a Shared SQL environment.
Say for example you are installing MOSS for a collaboration and Search environment you'd need to ensure that your deployment caters for performance or Search Index and Querying as well as the load of doing Collaboration. Performance of your SQL server is also quite vital for the overall solution to work since without a proper SQL infrastructure your SharePoint deployment is not in very good shape.
As a minimum you will need to create the following guides for your deployment and assign an administrator to actually look after and administer the deployment before and after the project team walks away. As a reference I always insist that project teams provide the following key documents as part of the deployment.
- Installation Guide for the environment (Should cater for Small single server or two servers, Medium 2 plus up to 5 servers, Large 5 + servers with DR + backups). The guide should have application pool accounts, administration accounts and model and the install method.
- Solution Deployment Guide (Should document how load balanced scenarios are addressed, a logical diagram of the deployment and how that relates to your physical implementation)
- Backup and Recovery Plan (This is a biggie! and a LOT of people miss this and I don’t know why you would ever spend lots of money on a project but not put some effort to covering this off?).
From a business point of view project managers need to be aware up front that a SharePoint project has to have a QA point by an experienced IT architect in deploying SharePoint. From a management and governance point there are guidance and sample code provided on CodePlex. http://www.codeplex.com/governance/
The next step is keeping your servers updated with latest service packs and updates as they become available. Doing a Best Practice Analyser (BPA) check for your environment prior to any applications being deployed should/must be done for every install. The BPA exists for a reason and that reason is to ensure your deployments are done correctly.
So if you are an IT pro in an organisation where a SharePoint deployment is being planned you should insist that these guidelines to be followed. And to up skill yourself on SharePoint the following resources are highly recommended.
Joel's Blog: http://blogs.msdn.com/joelo