Installing SQL Server


Download the ISO, extract it with 7-Zip or mount it in your VM and then run the setup, simple. Sure there is more to this but I will complete this later....


It is strongly recommended that you apply the latest Service Pack when doing an installation, unless you have some very good reasons. There are things called Cumulative Updates, which are like hot fixes, these should only be applied if you have the specific errors that are fixed, or if something like SharePoint depends on it and is documented in its requirements or installation documentation.


This is a great way of making life easy. So for example if you are doing several installs of SQL Server 2008 R2 for example, rather than keep applying Service Pack 2 every time you "slipstream" SP2 into the installation, which then means you just do the install and it gets SP2 from the word go. See the following links for more information:


When installing SQL Server into a cluster be extra careful when reading Hardware and Software Requirements for Installing SQL Server 2014. In addition you should carefully read Before Installing Failover Clustering which provides important information. In general most problems occur because people have not read the two articles referenced. Here follows some key things to do or consider before installing SQL Server into a cluster:

  • Build a Windows Server Cluster first
  • Check your Windows Server Cluster fails over correctly and is fully functional
  • Make sure the cluster dependencies are all correctly set
  • Make sure Cluster Verification works before you start
  • Make sure the shared storage is presented to the cluster correctly, especially with a SAN
  • Consider the drive letters to be used: I recommend mounting SQL Server related mount points to directories
  • Check .NET 3.5 SP1 is installed on all nodes, the installer will deploy .NET 4.0 for you (Except Express which you need to do manually), this is in the links above but is a common oversight [SQL2014]
  • Create service accounts before installing
  • Consideration also needs to be given to installing with "mixed mode" authentication, ideally this should be avoided
  • Consider how much memory the SQL Server instance should use and set this specifically
  • Plan your hostnames, fitting in with any naming conventions
  • Consider fixing the SQL Server port number, this will avoid dynamic allocation and make firewall rules easier
  • Do failover testing, with SQL Server installed but without your application
You will note above I recommended mounting storage to directories not drive letters, the problem with drive letters is you can easily run out within the cluster. You might not think so today but clusters can be added to, even if you don't believe so when you start. My suggestion would be to use four mount points as follows, although the sizes are clearly just an example

Description Path Size
Master, Model & MSDB Databases (Data & Logs) R:\ 10 GB
Temp Database (Data & Logs) R:\TempDB 100 GB
Database Files R:\Data 200 GB
Transaction Files R:\Log 50 GB

I also suggest naming your standby node 00, so that your first active node name ends 01. Whilst this seems odd at first, when you start adding more nodes it then makes perfect sense. I have seen cluster built with the first active node name ending 01 and the standby as 02 but this was only okay for a time! You might not think the cluster will be added to now or ever but it might be!