I was recently called into do some reviews of several server farm deployments. As part of our services we offer server health checks for current deployments of SharePoint. In some situations I have had the very unfortunate task of telling system administrators that their server farm is either in a unsupported scenario or have to be re-installed. The latter is mostly due to lack of planning while the former is a combination of customisations done to SharePoint by using unsupported development methods.
For example all SharePoint installations should be version 22.214.171.12439.
Update 21 March 2008: Note that MOSS SP1 and WSS SP1 installes should be: 126.96.36.19919.
You can check if your server farm has been applied with the latest updates released in October 2007. Go to Central Administration > Operations > "Topology and Services" > Servers in farm. You should see the version numbers as per the below screen.
Note that if your deployment uses a dedicated SQL server the server role of "Windows SharePoint Services Database" will show [ 188.8.131.5218 ]. This should be left as it is. The binary updates are only done to existing SharePoint instances.
The latest update which was released on 9th October is a must do update for all deployments. This update is available from the following links.
WSS 3.0 Update
Security Update for Windows SharePoint Services 3.0 x64 Edition (KB934525)
Security Update for Windows SharePoint Services 3.0 32 bit (KB934525)
MOSS 2007 Update
Security Update for Microsoft Office SharePoint Server 2007 x64 (KB937832)
Security Update for Microsoft Office SharePoint Server 2007 32 bit (KB937832)
Once you have downloaded the correct version you will need to run the WSS update first and then the MOSS update if you are running MOSS. Once both updates have been installed you will need to run the SharePoint Configuration Wizard. There are some known issues that you may encounter once this update has been configured. These have been posted by MSFT engineer Bill Baer in his blog. [ Troubleshooting KB 934525 and 937832 ]
The KB articles associated with these updates are here.
WSS 3.0 http://support.microsoft.com/kb/934525/
MOSS 2007 http://support.microsoft.com/kb/937832/
Your SharePoint installation will need to be looked after if your organisation is going to benefit from your deployment. If you install and then forget all about keeping your server farm updated you will not be able to provide services for your business units. Typically I get called to investigate because an end user will note that "SharePoint is too slow". My recommendations for IT Pros who are looking after a SharePoint farm is to follow these guidelines at a minimum for maintaining your Server farm.
Document your install. Don't really need to tell how important this is but it's surprising the number of "dodgy" installs that are in production without no documentation whatsoever. Sometimes the server administrator themselves don't know the account user name(s) and password(s) and who installed SharePoint. Example: my previous blog post on how to Install SharePoint using databases created by database administrators.
Add more than one Site Collection Administrator to Central Administration web site. It's all good that you are there today, but what happens if you leave? Use a service account as per recommended guidelines. Add at least two other "real people" accounts just in case. Central Administration site is basically the nerve centre for managing your SharePoint deployment.
Ensure that your Shared Services Provider web application also has more than one Site Collection Administrator.
Use "Quiesce Farm"mode when applying updates. What the heck is "Quiescing" you may ask?. Well basically it's an ueber word for taking your Farm Offline and stopping the farm from responding to sessions.
When initiating Quiescing a SharePoint farm there are three states.
Normal is the active state and the server farm will handle all incoming requests. In the Quiescing state the farm only provides requests to existing sessions. In Quiesced state no new sessions are started.
Basically "Quiescing" is there to allow maintenance updates happen whilst preventing any data loss when your deployment uses Session-Aware applications such as InfoPath form services. Note that when you Quiesce your farm users are still able to view your web sites. So it's important to inform that users should not access sites between the times you are doing your updates. Also certain background services such as Search Indexing will still run. Good rule of thumb is to schedule updates after hours.
To Quiesce the farm follow these steps.
1. From Central Administration, Operations, select "Quiesce Farm."
2. Enter the number of minutes in which you want the farm to be fully quiesced and click "Start Quiescing."
3. The page will display the quiescing status
Once updates are done you can "Reset" so the farm can operate normally.
Another option is to use Microsoft Operations Manager and the associated add-ons for SharePoint. Information on MOM for SharePoint is available on TechNet. The System Center Information Centre has more detailed information on the solutions offered.
Turn on Logging and Event Throttling. If you don't have this turned on then things can get very very tricky to diagnose what's wrong with your farm. Even better is the "Log Viewer" feature that can be deployed to Central Administration Web Site. The following CodePlex project has very handy feature pack. http://www.codeplex.com/features/Release/ProjectReleases.aspx?ReleaseId=2502 The one to download for viewing Log files via central administration is called "Log Viewer Feature".
In your install you should plan to store SharePoint log files to a separate disk and consider archiving old log files. The default location of the log files are: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS. The location can be changed via Central Administration > Operations > Diagnostic logging. For example I typically change the server logs location to E:\SharePointLogs\Logs\
Do a regular backup test via Central Administration. I always test that the whole Farm can be backed up using Central Administration after a base install of SharePoint. This ensures that your farm install has been correctly done. If you experience any errors in your backup these errors will need to be reviewed prior to creating web applications or joining new servers to the farm.
Schedule a site level scripted backup using PowerShell + STSADM. Or consider implementing the Site Delete capture feature from MS IT. The "Governance" project on CodePlex has very useful add on features.
Check your Event log for errors prior to deploying web applications. In some cases your server build may register event log errors. Check the event viewer and do a filter for "Source" > "Office SharePoint Server", "Office Server Search", "Windows SharePoint Services 3". It is important to clear and fix these before you hand over your deployment.
Event viewer typical errors (Event IDs 7888, 6482) in some environments.
Create a dead web cleanup policy. As an administrator you may want to establish that your sites are actually being used. For example in a Collaboration scenario when end users can create sites (Self service site creation) certain sites will have a lifecycle that will need to be reviewed. If a site is used for ad-hoc collaboration such as collating information (Document workspace) the site created may not be used by end users after a period of time. As an administrator you can schedule alerts to notify end users as to archive or delete the site when it is not required anymore. Such actions actively allow you to monitor site growth and change Quotas applied to sites.
Create a SQL maintenance plan to backup databases. This is where you will need to liaise with your SQL server administrator or DBA if your organisation has a dedicated managed SQL environment. The typical "groan" I get from DBA's is SharePoint created a crazy database with a GUID and I don't like it. Or why does SharePoint need so many databases. If you follow my post "Does your SQL server look like this after a SharePoint install" you will see how to have human readable databases in your install and what these databases are used for.
The following post from Joel shows where database mirroring can be used for high availability in SharePoint deployments.
Come up with a schedule to Check Database, Shrink Database, Reorganize Index, Clean up the History as well as Defragmenting your databases. All of these can be done using SQL Management Studio on your SQL server deployment which hosts your farm environment.
Establish practical maintenance downtimes. The following table identifies how you can plan for business requirements and critical applications which are deployed in your server farm. When coming up with an "Acceptable Uptime" policy review this in relation to your deployment and business.
|Acceptable uptime percentage
||Downtime per day
||Downtime per month
||Downtime per year|
As you can see for an environment which is critical for a business to be able to provide service significant investments will need to be made in terms of availability. I have been in situations where business users demand 100% uptime and when put into context and explained the investments in hardware and availability solutions to support such SLA's basically opt for "well if it works between business hours it's enough". The key is to come up with a balance in your environment so that you can gracefully recover in case something goes wrong. In some cases such as where you are provisioning an Internet facing deployment you may need to consider having full redundancy for your farm.
Establish deployment guidelines for developers. This is essential for ensuring that your server deployment does not have any "unsupported" code deployed or has any modifications done to actual application pages. This itself is a topic of it's own. Look at MSDN and TechNet. There is lots of online tutorials and guidelines for developers to follow.
Anyways it's up to you as a SharePoint administrator to read up and adopt a suitable plan for maintaining your farm. As a reference my previous post on my TechEd session (OFC 418 MOSS Deployment and Advanced Administration Topics) has a bunch of links that may be helpful.