SharePoint Knowledge Base

This blog post starts out with a story about what we have learned in the past. SimpleSharePoint has existed since 1990s and we used to manage networks and repair computers. Around 2005 we discovered that virus-infected computers were so problematic to repair that reinstalling Windows was far easier. To our surprise we discovered that our customers didn't object, and said "yeah just make it like it was new". Well that leads to SharePoint (which is all we do now) and how we consult for high-availability.

SharePoint is a highly complicated application with many possibilities for issues to crop up on a server. For example, SharePoint uses distributed timer jobs amongst the servers within a farm (which is what a bunch of SharePoint servers are known as). There are many data stores (each with their own security), synch services, caching, etc. And so the point is that if you have a SharePoint server that doesn't seem to be behaving well and is exhibiting odd signs of ill health than the easiest way to fix it is to replace it.

While that may seem like a radical idea, if you consider this aligns well with the concept of high-availability. At any given time hard drives can fail, server backplanes can fail, but in reality we know it's usually administrators that clicked the wrong button. Nevertheless, being able to know that you have business continuity by being able to very quickly replace a failing server is essential regardless of the reason. The image shown below is from a project SimpleSharePoint did where we were organizing many distributed SharePoint installations into one centralized location. Over the course of a weekend we built a 15 SharePoint server farm and it was really easy.

The not so secret "secret" is automated installation scripts. I will detail all the advantages they provide below after I explain where these originated. We have been using the AutoSPInstaller CodePlex solution since it was in its infancy. We take the already good solution and periodically enhance it further for our efficiency given the number of installs that we perform. We split out many parameters as variables which can be provided quickly in one location and the rest of it is standardized to fulfill the functions we wished. Essentially we polished it. Now when a client says they have a server that is ill we will do a health check and attempt all usual remediation steps. However if we have been managing the server for some period of time and it simply doesn't exhibit stable behavior we will replace it. Using an auto install script we can take a fresh VM and stand up SharePoint on it within two hours. And because we keep careful inventory of third-party add-ons we can bring it up to the same parity as the other servers. Then we transfer SharePoint services from the sick server to the new server and then the sick server is disjoined from the farm. It's a very good practice to do this at least once a year to be sure you can do it when needed.

The advantage of our scripts is that we get a full fidelity set up that eliminates human factors. Ironically we can generally tell the health of the server by observing how the script functions. And we have found many a poorly configured server just by going to the steps of installing SharePoint.

Our scripts do these things:

• Detect what is installed on the server and install what is missing
• Configure several key parameters that are suggested for best practices tuning
• Join a server to a farm with specified roles
• Configure services and standard settings

How does this relate to high availability? Imagine being able to spin up a whole replacement farm from scratch in 4 hours having nothing but SQL database backups! Imagine if standby VMs were already provisioned (and turned off to save resources). Imagine if SharePoint was already installed on these VMs and only needed to be joined to the farm. A WFE server could be replaced in 20 minutes! We're not talking about guaranteeing five 9's uptime here but having "warm" servers ready to go is a tactic that would suit many organizations that aren't ready to pony up for fully HA infrastructure and all the pieces that go along with that. Combined with our scripts, warm servers can become production servers in a very short timeframe.

Here is a real world example

We love helping with SharePoint and it's all we do so feel free to contact us!

Mention this post and we'll send you a white paper with all of the reasons why SharePoint is right for you!