SharePoint 2013 – Architecting and Building

Hi Folks

Having architected and built many, many SharePoint farms, sometimes I’m the architect, sometimes the builder, occasionally both I thought it time I put down what I’ve learnt in the process.  These are not hard and fast rules but a set of guidelines worth bearing in mind.

Why should you listen to me?

People who only design and architect the systems can make decisions that are fantastic in terms of theory but when you try and implement them are possible but very, very difficult or although buildable are not maintainable.

People who only build the systems can make decisions that are very easy to implement but are horrendous in terms of the overall architecture and requirements.

People who do both basically get to suffer the mistakes from both sides and end up with a more balanced view, pragmatic but without sacrificing sound principles.

This topic is far too big for a single blog post so I’ve broken it down into a series which you can find here:

• Creating a SharePoint Farm

The bottom line is that Microsoft learnt a lot in running Office365 and that has come back into SharePoint 2013 On Premises.  A lot of what they learnt had to do with making SharePoint stable and responsive by essentially not messing with it and automating as many administration activities as possible.  They learnt from our mistakes, we should learn from how they avoided them.  If your final SharePoint farm feels a lot like Office 365 then that’s no bad thing.

Have fun

Sebastian

Creating a SharePoint Farm

This blog is part of a series of blogs outlining the lessons I’ve learnt creating many, many SharePoint farms.  You can see the other at SharePoint 2013 – Architecting and Building.

Other Options

You can sidestep this entire set of actions by using Office 365 which will give you an installed and configured tenancy without you having to do anything.

You can create a SharePoint farm on Azure using it as Infrastructure as a Service (IaaS) and there is a template available that will stand up a multiple server SharePoint farm for you.  You get all the benefits of cloud computing, except elasticity, but at a cost, those virtual servers are not small and hence not cheap.  However it may still be cheaper than hosting them yourself.  An interesting twist on this is to use the Windows Azure Pack which allows you to host a ‘private’ Azure cloud in your own data center, this could reduce the cost and deal with security and safe harbour issues.

Create the servers

Use your normal provisioning method to create the base servers.

If possible use virtual servers and a template to ensure they are built with the correct configuration and patches.

Allocate SQL Provisioning

If you have SQL as a Service then use it, you specify the IOPs you need and resiliency and let the service provider do the heavy lifting.

Otherwise you need to build SQL servers via your normal process.  These days virtual is fine as the modern VM hosts can all do client disk access at the speeds you need.

You should set the SQL servers up as a cluster for resiliency, even if you start with a single node cluster, however over the last three years running numerous SharePoint farms none of their outages have been due to SQL Server failure.

Install SharePoint

Install SharePoint on each server via AutoSPInstaller.  Its not worth doing it by hand.

• It uses a configuration file so you have a record of what you have done.
• All servers can use the same configuration file, even if they have different roles, so you know they are all in harmony.
• It handles all the services, including the content services (i.e. web applications).
• It will automatically handle patching.
• You can add servers later in confidence if you use the same configuration files again so make sure you store them securely.

When writing the AutoSPInstaller configuration file do use the AutoSPInstaller GUI to help you.  You can edit the file by hand but its easier in the GUI and all the GUI does is edit the file so you get an output you can store.

Accept the defaults unless you have a very good reason not to.  Premature optimisation continues to be one of the major crimes against actually getting a system into the hands of users.  Start with the defaults and modify them when you can show they are an issue not just because you think they are one.

Occasionally you may have strong previous experience that means you can confidently change a default, for example moving the log files off the system drive is definitely a good idea, but unless you can back it up with practical experience just take the defaults.

There is one issue that may make you change the defaults and that’s where you know that later changes will be difficult, expensive or impossible.  The most obvious examples are around search.  Search changes if they involve a full crawl can take a long, long time so its worth getting the search schema as good as you can as quickly as you can.

If you have to change a default and AutoSPInstaller supports it (and it supports a lot of them) then use it.  If it doesn’t support it or the farm is already built, either you built it earlier, someone else provisions it on your behalf, or you inherited it and users are using it then you need to configure the farm using other techniques.